[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

IAB  Programme                                              D. Lazanski
Internet-Draft                                         Last Press Label
Intended status: Informational                            July 13, 2020
Expires: July 13, 2021



              Security Considerations for Protocol Designers
             draft-lazanski-protocol-sec-design-model-t-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 13, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.



Lazanski               Expires January 13, 2021                [Page 1]


Internet-Draft Security Considerations for Protocol Designers July 2020


Abstract

   This document is a non-exhaustive set of considerations for protocol
   designers and implementers with regards to attack defence. This
   document follows on from the way forward outlined in draft-lazanski-
   users-threat-model-t-01. These considerations both supplement and
   support the work on threat models. They can be used as an aid to
   analyse protocol design choice and in turn to help combat threats
   and defend users of these protocols and systems against malicious
   attacks.

   First, we list well-known classes of attacks that pose threats, with
   relevant case studies and descriptions. Next, we give a list of
   defence measures against these attacks to be considered when
   designing and deploying protocols. Naturally, deployments of
   protocols vary greatly between use cases; therefore, some attacks
   and defensive measures outlined may require more consideration than
   others, dependent on use case.

   This RFC can be used by protocol designers to write the Security
   Considerations section in an RFC. The impact on attack defence of a
   protocol should be considered in multiple use cases across the
   multiple layers of the internet. Defence against malicious attacks
   can be improved and it can be weakened by design features of
   protocols. Designers should acknowledge the role of protocols in
   attack prevention, detection and mitigation; this document aims to
   be a useful guide in doing so.

Table of Contents


   1. Introduction...................................................3
   2. Attacks........................................................4
      2.1. Endpoint Compromise.......................................4
      2.2. Network Compromise........................................6
      2.3. Denial of Service (DoS) and Distributed Denial of Service
      (DDos).........................................................7
      2.4. Phishing..................................................8
      2.5. Malware Infection.........................................9
      2.6. Insider Threat...........................................10
      2.7. Hijacking Traffic........................................10
      2.8. Web-based Attacks........................................11
      2.9. Malware Free Attacks.....................................12
      2.10. Table of Attacks TODO...................................12
   3. Real World Impacts............................................12
      3.1. Remote Data Alteration...................................12
      3.2. Data Exfiltration........................................13
      3.3. Identity Theft...........................................13

Lazanski               Expires January 13, 2021                [Page 2]


Internet-Draft Security Considerations for Protocol Designers July 2020


   4. Defensive Measures............................................14
      4.1. Response to Attacks......................................14
      4.2. Recovery from Attacks....................................15
      4.3. Reporting of Attacks.....................................15
      4.4. Sinkholing...............................................16
      4.5. Firewalls/Middleboxes/Gateways...........................16
      4.6. Intrusion Prevention System (IPS) and Intrusion Detection
      System (IDS)..................................................17
      4.7. Upstream Filtering.......................................18
      4.8. Malicious Domain Monitoring and Takedown.................18
      4.9. Filtering................................................19
      4.10. Implementation of Trust.................................20
      4.11. Endpoint Security.......................................20
      4.12. Email Anti-spoofing Measures............................21
      4.13. Social/User Interface Interactions......................21
      4.14. Detection of Exfiltration and Data Leakage..............22
      4.15. Misuse of the Domain Name System........................22
      4.16. Attack and Defense Table TODO...........................23
   5. The Overall Security Picture..................................23
   6. Attack Defence in Security Considerations.....................23
   7.Security Considerations........................................24
   8. IANA Considerations...........................................24
   9. Conclusions...................................................24
   10. References...................................................24
      10.1. Normative References....................................24
   11. Acknowledgments..............................................27



1. Introduction

   This draft aims to give a non-exhaustive set of attack defence
   considerations for protocol designers and implementers to consider
   when designing and deploying protocols. These considerations are
   focused on informing the design of protocols so that protocols may
   better defend users and systems from malicious attacks.[1] This is
   essential information and should be considered for protocol
   development. No protocols should be finalised without security
   guidance just as no protocols should be designed without privacy
   considerations. This document is a useful and necessary reference
   and it is the intention of the authors that the IETF makes full use
   of all the security expertise in its community through the updating
   of this document.

   For protocol designers, it is important that a protocol's impact on
   different attack defence cases across the layers of the internet
   should be considered. Defence against malicious attacks can be
   either improved or weakened by the design features of protocols.

Lazanski               Expires January 13, 2021                [Page 3]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Designers should acknowledge that including  attack prevention,
   detection and mitigation is essential in protocol development.

   In Section 2, we list some of the many attacks that are a malicious
   presence on the internet today, with their methodologies, notable
   case studies and attack outcomes. This is not, and can never be, an
   exhaustive list; threats have been chosen based on their frequency
   and regularity, likelihood of occurring, and impact on victims. In
   Section 3, we describe some real world impacts following up on some
   of the attacks listed in Section 2.

   In Section 4, we document some known popular current defensive
   practice, giving a list of defence measures that can and are widely
   used against attacks from Section 2. These current practices should
   be considered when designing and deploying protocols to avoid
   obsoleting them unwittingly. Other possible defensive measures for
   protocol designs are included where relevant.

   Section 5 outlines the motivations and use of this draft, and
   Section 6 suggests the methodology by which considerations outlined
   in this draft may be consistently thought through in protocol
   design.

2. Attacks

   In this section we outline some attack types that are well-known in
   industry and in public. For each attack type, we give examples of
   how this attack is carried out, case studies of notable attacks
   where appropriate, and the outcomes that attackers are trying to
   achieve. Some considerations for protocol designers in relation to
   each specific attack are also listed.

   Throughout this draft the aim to use common industry references,
   taxonomies and terminology for types of attack to avoid confusion.
   Considerations for protocol designers and deployments in each
   section are summarised in a table in Section 2.11 for ease of
   reference.

2.1. Endpoint Compromise

   According to IDC 70% of successful cybersecurity breaches originate
   at the endpoint as their initial point of contact and penetration.
   Attack Description: Endpoint compromise is when a malicious an
   unauthorised attacker has control of an endpoint beyond their access
   and privilege level. Endpoint compromises not yet been mentioned in
   RFC 3552. However, they may be achieved through many attack vectors,
   such as: stealing legitimate credentials that give access to the
   endpoint, malware infection, a phishing attack, and insider threats.

Lazanski               Expires January 13, 2021                [Page 4]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Attackers have multiple motivations to compromise an endpoint, some
   of which we list here and include: to exfiltrate personal or
   intellectual proper data on the endpoint, to perform reconnaissance
   for other malware to deploy, to move laterally around a network, to
   harvest legitimate credentials, for financial gain, or for
   reputational or political reasons. See draft-lazanski-users-threat-
   model-t

   When an endpoint is compromised, it is common practice to utilize a
   communication channel (either a new one is opened or an existing one
   is leveraged) to exfiltrate data, communicate to the command centre,
   explore the network or propagate to other endpoints. Such a
   communication channel would typically attempt to "look like" a
   routine connection to a server or a peer. Furthermore, malware often
   disables any protection, if any protection exits, on the endpoint as
   part of its initial infection process allowing this to happen
   quickly.

   Case Study: Silex Malware

   In June 2019 a strain of malware was found that wipes the firmware
   of an IoT device. It does this by using known credentials for
   logging into IoT devices and completely wipes the system and removes
   the network configuration. It impacted thousands of devices by
   rendering them useless. [2]

   Protocol Design Considerations: A protocol design consideration
   against this attack would therefore preserve prevention mechanisms
   and allow for the detection of the abnormality of connections on
   host systems. This allows for network-based defence in depth.
   Abnormalities might include unusual traffic flow to a server,
   attempting to contact many IP addresses (scanning), or beaconing
   behavior patterns, which is when it 'calls home' at regular
   intervals.

   This is just one example of potential endpoint compromise situations
   and subsequent mitigations which can be considered and included in
   protocol development. More detailed consideration of endpoints,
   especially with respect to endpoint-only security solutions can be
   found in Capabilities and Limitations of an Endpoint-only Security
   Solution draft-taddei-smart-cless introduction-02 and a related
   taxonomy, Endpoint Taxonomy for CLESS draft-mcfadden-smart-endpoint-
   taxonomy-for-cless-01 which is a taxonomy of specific endpoint
   equipment, devices and applications. These drafts both highlight
   important points. In the draft-taddei-smart-cless-introduction-02
   researchers found that 5% of incidents were only detected by network
   based systems while the rest was detected by endpoint security. This


Lazanski               Expires January 13, 2021                [Page 5]


Internet-Draft Security Considerations for Protocol Designers July 2020


   is why the reliance on network-based protocols shouldn't be the only
   focus in protocol design.

2.2. Network Compromise

   Attack Description: Network compromise is where a malicious and
   unauthorised attacker has presence on or control of part of a
   network beyond their privilege level. An attacker may compromise a
   network to achieve any one of many objectives, such as: to obscure
   endpoint compromise, to move laterally around a network undetected,
   to perform reconnaissance, to gain information or data and to
   escalate privilege.

   Case Study: NotPetya

   The NotPetya virus initiated a series of global, sustained attacks
   in 2017 which originated in the Ukraine, but spread rapidly. A
   variant of Petya ransomware virus, NotPetya targets Windows based
   systems in order to infect the master boot loader which in turn
   encrypts the hard drive's file system. However, unlike Petya,
   NotPetya spreads on its own through network compromise and encrypts
   everything. Also, it looks like Petya ransomware, but is in fact not
   ransomware (hence the name NotPetya). Though the attack was global,
   the global shipping and logistics company Maersk lost their entire
   IT system which impacted their business. The estimated loss to their
   business was around 300 million Euros.[3]

   Protocol Design Considerations:

   If there is an unauthorised attacker accessing a passive inspection
   point in the network, a protocol design consideration would be to
   apply cryptography for confidentiality protection.

   A protocol design consideration for an attacker modifying contents
   of data packets on the network would be to apply cryptography for
   integrity protection.

   Finally, if an attacker engages in re-routing, re-ordering,
   replaying, delaying or dropping data on the network, which is
   arguably less well-handled by existing Internet transport protocols,
   then protocol design considerations would include development of
   strong sender authentication, integrity checks over whole sessions
   not just individual packets, replay detection, and out-of-order
   packet detection.





Lazanski               Expires January 13, 2021                [Page 6]


Internet-Draft Security Considerations for Protocol Designers July 2020


2.3. Denial of Service (DoS) and Distributed Denial of Service (DDos)

   Attack Description: Denial of Service (DoS) attacks intend to
   prevent any service and service delivery. Attackers usually select a
   high-profile, online web target that they intend to make unavailable
   in the short-term. Distributed DoS attacks utilise multiple
   compromised endpoints to distribute the DoS attack, removing the
   possibility of blocking the attack by removing the single device
   launching the attack.

   DDoS attacks can occur:

   1) at the network layer, known as a Layer 2 DDoS attack, launched
   via malformed packets, flooding or spoofing.

   2) at the application layer, known as a Layer 7 DDoS attack,
   launched via Ping of Death, HTTP floods, XDoS.

   3) a combination of both network and application services, resulting
   in amplification and reflection attacks.

   Common DDoS Attacks include:

   1) HTTP POST attack in which an attack floods an HTTP POST or GET
   request by exploiting an open connection and sending data to
   connected web servers, typically over a period of time. This takes
   place at Layer 7 and is successful because it is an asymmetric
   attack which leaves the connection open for a long duration. An
   update would be required to fix this issue.

   2) ICMP flood or ping flood is when an attacker takes down a
   computer by sending a large number of request packets. This is
   accomplished by knowing the destination IP address and sending the
   requests.

   A successful DDoS attack, where the service is inaccessible for a
   period of time, achieves the attacker objective include degradation
   of service. In some cases, this may be used by the  attacker as an
   opportunity for extortion.

   Case study: Dyn attack, Mirai

   The Mirai botnet was first identified in 2016. The Mirai botnet as
   well as variants target and infect Internet of Things devices. Those
   infected devices scan the Internet for IP  addresses of other
   Internet of Things devices, thus creating a multiplication of IoT
   devices which are infected. Though the bot still exists in various
   forms, the most serious attack took place on 21 October 2016 when

Lazanski               Expires January 13, 2021                [Page 7]


Internet-Draft Security Considerations for Protocol Designers July 2020


   the Domain Name System (DNS) provider Dyn was attacked by DDoS using
   a coordinated system of infected IoT devices. Much of the Internet
   was unreachable after three attacks occurred during the same day.
   The decentralised nature of the Internet helped to mitigate the
   severity of attack and the attack was eventually resolved on that
   day. However, the sheer size and scale of the attack is still viewed
   as one of the biggest attacks on the Internet to take place.. [4]
   Changes in the threat landscape, including risk of consolidation and
   IoT changes could upend these mitigations in future and promote
   over-reliance on one single security solution rather than a
   decentralized, resilient network.

   Protocol Design Considerations: Some people take the attitude of
   "DDoS attack? Welcome to the internet" and this is the approach of
   RFC 3552 as well. However, the use of the Internet and data that
   travels over it has increased exponentially. Protocol designers
   should be aware of potential issues that help DDoS attacks, such as:
   CoAP flooding, protocols that permit mass unscheduled deliveries,
   provision of the ability for an attacker to mask e.g. IP addresses,
   provision of the ability to amplify, a lack of sender
   authentication, a long time open request and an inability to filter
   at scale.[5] Assessment of protocol for abuse and DoS amplification
   should be a part of the security assessment during the design
   iteration process.

2.4. Phishing

   Attack Description: A phishing attack is where an unsolicited
   message with malicious content is received. Malicious content could
   be either in the message itself (email, messages), or directing the
   user to a malicious domain. Varieties of phishing exist, based on
   difference social engineering approaches, including: spear phishing,
   clone phishing and whaling. Phishing is cited as the initial attack
   vector for 91% of reported malicious attacks.[6]

   For a phishing attack to succeed, the user has to be unwittingly
   duped into an action, where they can't be assumed to have the
   knowledge to check their action. For example, users can be confused
   by domain names that render almost identically but are different at
   a binary level, such as internationalised domain names. Also users
   may see that a sender of an email to them is someone they know, but
   not realise that the email address is different.

   Case Study: Ukrainian Power Grid Attack

   The cyber attack on the Ukrainian Power Grid took place on December
   23, 2015. It was the first known cyber attack on a power grid.
   Around 250,000 individual customers were impacted. DDoS telephone

Lazanski               Expires January 13, 2021                [Page 8]


Internet-Draft Security Considerations for Protocol Designers July 2020


   attacks also prevented people from calling help centres to report
   the lack of electricity. All of this began with a spear-phishing
   campaign initiated 9 months before that was eventually successful.
   [7]

   Protocol Design Considerations: design protocols with strong
   authentications and identification/proof of ownership of domains
   required. Provide users with means to assist checking their actions
   are safe (or automate the means that can check a user's actions).

   Network infrastructure should be able to detect whether data has
   strong authentication and policies can be specified for handling
   unauthenticated data (e.g. SPF, DMARC). One defensive measure
   employed by domain owners to check for unauthorised usage of
   identical or similar domain names is to use Certificate Transparency
   logs [8] with automated notifications to the domain owner where
   domains with 'close' domain names log a certificate, indicating a
   malicious spoofed domain and therefore access is denied. [9]

2.5. Malware Infection

   Attack Description: Malware is one attack vector used to achieve
   network or endpoint compromise. As Lockheed Martin's Killchain
   describes,[10] there are many interactions between malware and
   protocols which allows for infection and attacks. In the case of
   Lockheed Martin there are seven distinct stages each with protocols
   associated with them. Malware comes in many different strains and
   flavours: exploit kits, ransomware, viruses, trojans, worms,
   rootkits and more. The attack outcomes are incredibly varied too -
   attackers might want to recruit bots, deploy that leaves behind
   physical damage, steal IPR material for corporate espionage,
   exfiltrate of credentials to gain accesses elsewhere in the system,
   perform reconnaissance for a later attack, or make some financial
   gains.

   Case Study: WannaCry

   In 2017, a ransom attack was launched by using a cryptoworm
   targeting computers running the Microsoft operating system. The
   attack encrypted person and computer data and then asked for a
   ransom in order to unencrypt the data. The attack was eventually
   stopped by a 'kill switch' that was discovered. DNS monitoring
   detected the infection, but not without infecting 200,000 computers
   first.[11]



Lazanski               Expires January 13, 2021                [Page 9]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Protocol Design Considerations: As malware is often carried to an
   endpoint by an Internet protocol, there are considerations for
   protocol designers. Moreover, once it's arrived at its destination,
   malware needs to use protocols for discovery of peers, for C2, for
   exfil. Therefore, such connections and the features from those
   protocols can be used to detect, track and mitigate outbreaks in
   real-time. For example, SMTP headers can detect malware spreading
   through e-mail, and other protocol connections can show the lateral
   movement of malware through a network.

   TODO: Details for detection for protocol design.

2.6. Insider Threat

   Attack Description: This attack involves social manipulation of an
   authorised person so that they knowingly attempt malicious actions,
   using their authorised privileges, credentials and accesses to
   achieve nefarious attacker objectives. This is different social
   engineering to phishing (Section 2.4), where the user is unwitting
   to their actions.

   The insider themselves might be the sole attacker, for various
   reasons - ranging from a desire to gain notoriety or to inflict
   deliberate harm on their employer. If the insider is manipulated by
   another attacker, their role is likely to provide information only
   accessible by an outsider, to enable further attacks. Eventual
   attacker outcomes are to gain access to the network or endpoints,
   potentially for insider trading, fraudulent transactions or IPR
   theft.

   Case Study: Anthem

   A contractor working for a consultancy employed by Anthem stole
   18,500 individual files with personal details and used them for
   personal gain.[12]

   Protocol Design Consideration: There is therefore a need for
   authorization to be a design consideration for protocols, and also
   provisioning the ability to create and manage logs, and to create
   audit trails for document access.

   TODO: Fill in authorization process and abnormality detection for
   protocol design.

2.7. Hijacking Traffic

   Attack Description: Border Gateway Protocol hijacking, or BGP
   hijacking is when a group of IP addresses are taken over maliciously

Lazanski               Expires January 13, 2021               [Page 10]


Internet-Draft Security Considerations for Protocol Designers July 2020


   by routing table manipulation and corruption. BGP hijacking is
   fairly common and is a frequent attack used against cryptocurrencies
   because hosting centralization makes it particularly vulnerable to
   attacks. As recently as June 2019 a large amount of European
   Internet traffic was re-routed through China because of a BGP route
   leak. However, instead of China telecom ignoring the leak it
   hijacked the routes as their own. [13]

   Case Study: In 2018 Amazon Web Services DNS offering called Amazon's
   Route 53 was hijacked by using BGP table updates which directed the
   traffic to a malicious server at an IXP in Chicago. The attack
   lasted two hours and resulted in stolen Ethereum cryptocurrency from
   myetherwallet.com [14]

   Protocol Design Considerations: Protocol design considerations
   should include authentication and handshake management when sending
   and accepting traffic. This will be an ongoing and iterative process
   so the protocol design must take into consideration the management
   of this repetitive process.  Protocol design should also take into
   account how to prevent DNS cache poisoning and route table
   manipulation and communicate that such a process occurred.

2.8. Web-based Attacks

   Attack Description: Web-based attacks are those that use web systems
   and services as the main surface for compromising the victim [15]
   including browser exploitations, like the Firefox zero day exploit
   found in the new version of Mozilla's browser in January 2020 [16]
   and injections, drive-by downloads, cross-site request forgery,
   water-holing, and more. Web-based attacks are on the rise and Web
   application attacks also continue in the form of malicious web
   applications, SQL injections and cross-site scripting. [17]

   Case Study: Chrome

   As recently as February 2020 a security vulnerability in older
   versions of the Chrome browser allowed for the exploitation of
   user's computers in a zero day attack scenario. Though the
   vulnerability has been fixed through updates, a number of attacks
   have taken place. Number unknown to date. [18]

   Protocol Design Considerations: Many mitigations to these attacks
   rely on endpoint security, such as patching. This may possibly
   explain the rise in this attack trend. One simple way to mitigate
   this attack vector is to make patching updates as easy and
   straightforward as possible. This includes clear communication for
   when updates are needed and how the user can safely and securely
   patch and update. Protocol designers should be aware of other

Lazanski               Expires January 13, 2021               [Page 11]


Internet-Draft Security Considerations for Protocol Designers July 2020


   mitigations, such as web-traffic filtering and web-traffic
   encryption, in order to take them into consideration.

2.9. Malware Free Attacks

   Attack Description: Malware-free attacks accounted for 51% of all
   global cyberattack types, according to Crowdstrike's 2020 Global
   Threat Report [19] for the first time since starting the report.  A
   malware free attack is one that does not employ or write a malicious
   file or fragment a computer disk. Instead, memory executed code or
   stolen credentials, running legitimate tools or executing code from
   memory are all possible types of attacks. Malware-free attacks are
   more difficult to detect unless actively looking for cyberattacks in
   systems.

   Case Study: TBD TODO

   Protocol Considerations: Building in resilience to malware-free
   cyber attacks. Allow for search and notification of potential
   cybersecurity issues as a pre-emptive measure.

2.10. Table of Attacks TODO

   This section will be a table of attacks, case studies and the
   relating protocol design considerations. It will updated once all of
   the case studies have been added.

3. Real World Impacts

   The following section focuses on the impacts and outcomes that
   happen as a result of cyber attacks. This section is by no means
   comprehensive, but will expand as examples are added through
   contributions and collaborations with those who are interested.

3.1.  Remote Data Alteration

   Attack Description: Alteration of data on a remote system, e.g. a
   Industrial Control System, to achieve an effect that would, for
   example, change the delivery of products in a supply chain or change
   the characteristics of a product during production may cause harm to
   people using that product intended for one use, but designed to
   malfunction. RDP allows cyber attacks to access the Internet-facing
   parts of an ICS from where they may able to move to the operational
   environment.

   Case Study: Industrial Control Systems or TBD [20] TODO



Lazanski               Expires January 13, 2021               [Page 12]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Protocol design considerations: Industrial Control Systems are
   expensive and are often patched in slower-time, and a defence-in-
   depth approach is advocated; endpoint security alone is not enough.
   Additional considerations include the ability to real-time monitor
   easily, and to note that internet protocols are used for high-
   threat systems.

3.2. Data Exfiltration

   Attack Description: Data exfiltration is a frequent outcome of
   compromise, where data is taken from a system by an unauthorized
   user. This information leakage includes customer data (often in
   high-profile breaches) or theft of IPR material from enterprises.

   Exfiltration of data can be:

   1) High-volume, where the attacker expects to be detected or wants
   to operate quickly.

   2) Low-and-slow, where data is siphoned off at a low level for a
   long period of time, in the hope of avoiding detection.

   Case study:  Equifax

   In March 2017, attackers searched the web looking for
   vulnerabilities that were known, but had not been fixed. Making
   patches easier to download would have easily solved this issues.
   These attackers targeted the dispute resolution portal at a credit
      ratings company called Equifax in the US. The hackers used a
      vulnerability in Apache Struts which allowed access and
      exfiltration of personal information on the portal. [21]

   Protocol Design Considerations: Endpoints can tag/watermark content
   so that leaked data can be identified and possibly stopped at a
   gateway, or at least traced back to the user that leaked the
   material. For this, protocol data could include a protective marking
   field that is visible to a firewall, even if the content is
   encrypted.

   Another issue to consider is the detection of data exfiltrated
   through covert channels. Protocols should be designed with this
   abuse in mind, with designers minimising existence and size of
   covert channels.

3.3. Identity Theft

   Attack Description: Fraud committed from the theft of personal
   identifiable information - such as bank details, home address and

Lazanski               Expires January 13, 2021               [Page 13]


Internet-Draft Security Considerations for Protocol Designers July 2020


   date of birth - strengthened by the massive digitisation and
   centralisation of people's personal data. Credential stealing and
   credential stuffing are two of many ways to obtain personal data.

   Case Study: JP Morgan Chase

   In 2014 JP Morgan Chase had over 83 million accounts compromised and
   hackers made over $100 million through fraud and identity theft. To
   date it is one of the largest data breaches in history.[22]

   Protocol Design Considerations: Provision and protect a way that
   allows breaches of personal data to be detected in real-time and
   stopped.

4. Defensive Measures

   Defensive measures broadly fall into three classes:

   1. prevention of attacks - stopping most attacks from achieving the
   attacker's objectives, i.e. from taking hold on a system, network or
   endpoint.

   2. detection of attacks - how attacks are detected quickly,
   efficiently, with a high-degree of confidence and accuracy.

   3. mitigation of attacks - once an attack happens, the capability to
   stop the damage done by the attack, e.g. preventing the spread of
   the compromise within an organisation, limiting the data exfiltrated
   or stopping the attack from being replicated globally on unaffected
   systems.

   All defences listed in this section relate to one or more attacks
   listed in Section 2.

   For each type of defensive measure, we categorise the method as
   prevention, detection, mitigation or a combination of these; we
   link to the type of attack in Section 2 that is prevented; and we
   describe how the defence work.

   Considerations for protocol designers (in relation to each defensive
   measure) are also listed throughout, and summarised in Table 4.16 to
   provide an easier reference.

4.1. Response to Attacks

   Defence Type: Mitigation



Lazanski               Expires January 13, 2021               [Page 14]


Internet-Draft Security Considerations for Protocol Designers July 2020


   A system can be designed to ensure availability under attack, e.g.
   by segregating classes of devices on a network, or considering
   system architecture. Components that are under attack have a channel
   for reporting that attack that is distinct from the channel used for
   launching the attack.

   Case Study: TBD TODO

   Protocol Design Considerations: Design protocols that allow such
   segregation in architecture in a simple and scalable way. Design
   protocols for reporting of attacks that use channels that are less
   susceptible to attacks.

4.2. Recovery from Attacks

   Defence Type: Prevention

   If organisations and individuals assume that a security breach will
   happen then defences will be optimised in or to allow for a quick
   response and minimal impact.  This is an important point that is
   missing from the current version of RFC 3552 because the scale and
   size of attacks has changed over the years since it was published as
   noted in draft-mcfadden-rfc3552-research-methodology.


   For example, encrypt data when stored so that if it is stolen, the
   attacker can't decrypt it. For another example, if data is backed up
   regularly and stored offline, then the threat held by ransomware is
   minimised.

   Case Study: TBD TODO

   Protocol Design Considerations: Design protocols that can deliver
   encrypted   payloads to capable endpoints. Practice strong
   separation of the keys used to encrypt data at rest from the data,
   with high levels of protection applied to the keys. Design protocols
   that allow for regular, automatic backup of data minimising the
   amount of user interaction required.

4.3. Reporting of Attacks

   Defence Type: Detection

   Logging is an important feature. Multiple logs allow cross
   referencing and establishing truth data, so it is important to
   provide logging in multiple places, to detect false reporting by
   compromised endpoints or networks. Logging allows strengthened

Lazanski               Expires January 13, 2021               [Page 15]


Internet-Draft Security Considerations for Protocol Designers July 2020


   forensics, which reduces the risk of similar attacks in future.
   Forensic analysis of logs makes it easier to detect and locate
   attacks, so can be a deterrent to attackers. For this same reason,
   malicious manipulation of logs to prevent detection is an attractive
   attacker objective.

   Reliable logging helps to find the source of an attack, its spread
   and what devices and networks have been compromised. Unreliable
   logging can slow attempts to mitigate it.

   Case Study: TBD TODO

   Protocol Design Considerations: How a protocol might help/hinder the
   ability to troubleshoot or have separate logging in multiple places
   (for truth data), allow for reliable logging across points in a
   network.

4.4. Sinkholing

   Defence Type: Mitigation

   Mitigation against where a DDoS attack has already been launched, to
   prevent a successful attack outcome (i.e. a denial of service).

   Case Study: Nitol Botnet

   Through counterfeit Microsoft products, Nitol malware infected over
   4000 Windows computers primarily in China. The botnet originated
   from the domain 3322.org which was a dynamic DNS service. The
   subdomains of 3322.org from which the malware originated, could
   redirect traffic to additional sites also infected with malware. The
   malware propagating itself through Internet traffic. [23] At least
   70,000 subdomains were infected. Microsoft attempted to disrupt the
   supply chain of the infected Microsoft products and block the
   subdomains. [24]

   Protocol Design Considerations: Ability to determine whether a
   connection is likely malicious or not, and filter out malicious
   connections at speed. Ability to reliably determine the source of a
   connection and verify that it is accurate and from an address
   authorised to make the connection. Ongoing monitoring and reporting
   is necessary.

4.5. Firewalls/Middleboxes/Gateways

   Defence Type: Prevention and detection



Lazanski               Expires January 13, 2021               [Page 16]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Firewalls, middleboxes and gateways can be used to inspect traffic
   and make decisions whether to allow, block or modify data content.
   These decisions can be based on simple IP address/port/protocol
   rules, or on deep packet inspection of individual data packets, or
   use artificial intelligence/machine learning techniques to make more
   complex decisions based on analysis of traffic over a period of
   time.

   Case Study: TBD TODO

   Protocol Design Considerations: Protocols should allow for selective
   and/or minimally intrusive analysis, balanced against the need to
   protect the privacy of the user content and any personally
   identifiable information. Minimally intrusive analysis could include
   the ability to block traffic that it associated with known insecure
   protocols or ports, known malicious activity or known malicious
   users. A protocol that makes all traffic look essentially
   indistinguishable forces the firewall into making an "all-or-
   nothing" decision, which would be ineffective for defending against
   attacks if it is still to allow some communications. Allowing for
   communication would be detrimental for privacy as well.

   A firewall should not be able to undetectably modify traffic; where
   it is necessary to modify traffic to prevent a threat, the
   modification should be apparent to the receiver.

4.6. Intrusion Prevention System (IPS) and Intrusion Detection System
   (IDS)

   Defence Type: prevention and detection

   These systems provide the abilities to prevent and detect malware
   infection, vulnerability exploits, and lateral movement on
   compromised networks and endpoints. Signatures for bad content -
   IPS/IDSs don't work on traffic if attacks have legitimate content
   but bad intent, e.g. DDoS. However, the IPS/IDS may detect the
   malware that compromised the endpoint to launch the DDoS attack.

   IDSs are passive systems that scan traffic and report to the traffic
   owner on threats; IPSs are inline, taking an active role and making
   automated decisions and applying these actions to traffic.

   Case Study: Vishing and Covid-19

   IDS and IPS are employed in companies and organisations especially
   in office and controlled physical environments. However, because of
   Covid-19 people are working from home or remotely. IDS is used in
   offices; now people working remotely or working from home don't have

Lazanski               Expires January 13, 2021               [Page 17]


Internet-Draft Security Considerations for Protocol Designers July 2020


   that protection. This has led to an upsurge in vishing. Vishing is
   when an attacker builds a profile and convinces the victim to
   download and use remote assistance software which becomes the way
   the attacker penetrates an organisation. In a remote environment
   without IDS or IPS this could happen without adequate defence. [25]

   Protocol Design Considerations: For IDS, protocols should allow for
   logging of data relating to the connection, which may include any or
   all of IP addresses, ports, protocols and payloads, balanced with
   the requirement to protect privacy of user data. For IPS, protocols
   should allow for signature/statistical anomaly detection, the
   ability to selectively drop traffic and respond at efficient scale
   and speed.

4.7. Upstream Filtering

   Defence Type: Mitigation

   Content is filtered through a "scrubbing" centre to forward only
   good traffic. This is provided as a service by e.g. Cloudflare,
   Akamai.

   Case Study: Akamai scrubbing

   In August 2019, Akamai opened a new scrubbing centre in Melbourne to
   compliment its other Asian regional centres in Sydney, Tokyo, Hong
   Kong, Osaka and Singapore. [26] Because of the surge or DDoS attacks
   in the region, the scrubbing capacity has increased at least three
   times to that of the largest DDoS attack. For all content delivery
   centres, traffic is redirected to scrubbing centres by making a BGP
   change. Upstreaming filtering or scrubbing is meant to prevent
   attacks before they reach data and applications in the cloud. The
   largest mitigated attack to date was Mirai at 1.3 TBPS. Distributed
   scrubbing centres aid in mitigation of such attacks.

   Protocol Design Considerations: allow for forwarding of traffic on
   this scale through robust internet infrastructure. Attack traffic
   should be easily recognisable through its externals, e.g. packet
   destination, traffic flow patterns, protocol type, signatures. This
   relies on being able to filter at speed and weed out malicious
   connections.

4.8. Malicious Domain Monitoring and Takedown

   Defence Type: Mitigation, detection and prevention

   We wish to detect the existence and determine the intent of
   malicious domains as soon as possible, and remove or deny access to

Lazanski               Expires January 13, 2021               [Page 18]


Internet-Draft Security Considerations for Protocol Designers July 2020


   them before most harm can be done. For example, removal of malicious
   domains that are created to receive clicks from phishing emails; if
   the domain can be removed before most emails are read, the links
   won't work and the harm is reduced with no effort from the user.

   Takedown services can levy copyright protections to request
   takedowns. Combined with techniques to use email authentication,
   these proactive measures rather than reactive ones have had
   considerable effect in UK government efforts to minimise phishing.
   [27]

   Case Study: TBD TODO

   Protocol Design Considerations: Protocols should allow users to
   determine the identity of the domain that they are connecting before
   they are exposed to data from that domain. Protocols should provide
   a means for users to verify the authenticity of a connection to a
   domain.  Protocols should minimise the opportunities for users to
   confuse malicious domains with legitimate domains. Protocols should
   provide a method for legitimate domain owners to recognize attempts
   by a malicious domain to masquerade as the legitimate domain.

4.9. Filtering

   Defence Type: Prevention and mitigation.

   Filtering of traffic can be done according to block lists of
   addresses, content types or signatures specified by malware threat
   feeds.  Filtering can also be done using statistical and machine
   learning techniques, e.g. for spam.  Filtering can prevent malware
   infection or mitigate it by stopping the further spread of malware.

   Case Study: Telstra and Covid-19 Scams

   The CEO of Telstra warned that Covid-19 malware scams are a boom to
   malware brokers and attackers. The rise and prevalence of Covid-19
   scams in the first six months of 2020 is not surprising, but the
   Telstra CEO said clearly that they are strengthening their screening
   and filtering activities on their networks. [28]

   Protocol Design Considerations: Protocols should allow for selective
   and/or minimally intrusive analysis of traffic in order to determine
   whether to allow data through the filter. Malware may try to shape
   malicious traffic to appear like benign traffic, so protocol
   specifications should minimise the opportunity for malicious
   payloads to masquerade as legitimate payloads. For example,
   encrypting all data so that it looks the same, then you're removing

Lazanski               Expires January 13, 2021               [Page 19]


Internet-Draft Security Considerations for Protocol Designers July 2020


   any discriminating features that filtering systems could use to base
   their decisions on.

   Protocols therefore should be designed with an awareness that hiding
   features that expose malicious traffic as malicious will enable
   malicious payload delivery, therefore it would be responsible to
   work out which, and preserve features that, would still allow
   effective detection.

4.10. Implementation of Trust

   Defence Type: Prevention.

   A trusted ecosystem is one in which a user or organization has a
   level of confidence in the security and reliability of the system.
   No ecosystem can ever be 100% secure, but trust is created when risk
   analysis and technical mitigations are in place.

   For example, content is filtered so that data from non-trusted
   sources is filtered out before it arrives. DMARC/SPF to prevent
   phishing, secure authenticated log-in, PKI certificate validity on
   TLS connections is enforce. Updates and patch

   Case Study: TBD TODO

   Protocol Design Considerations: Protocols should be resilient and
   should not prevent informed users from opting into services that
   protected delivery of only trusted content. Protocols should allow
   for verification of data source and integrity. Protocols should
   include policies for handling and management of non-trusted data.

4.11. Endpoint Security

   Defence Type: prevention, detection and mitigation.

   Security hygiene, like regular patches to fix the latest discovered
   software vulnerabilities, form an important part of the security of
   any system. However, some endpoints are unable to maintain their own
   security and can introduce vulnerabilities themselves.

   Case Study: Netgear

   Netgear is one of many examples available relating to prevention,
   detection and mitigation of endpoints. In July 2020 Netgear released
   security advisories for a number of its routers, modems, gateways
   and extenders. [29] Firmware updates to patch the issue are linked
   to the corresponding network device.


Lazanski               Expires January 13, 2021               [Page 20]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Protocol Design Considerations: Consider whether the protocol data
   is available for inspection by the endpoint security solution. At
   what point in the protocol stack is protected data decrypted and can
   be analysed or blocked by the endpoint security?

4.12. Email Anti-spoofing Measures

   Defence Type: Prevention

   These are preventive measures designed to prevent and reduce
   phishing emails. Configure anti-spoofing controls on a domain you
   own to prevent email spoofing, such as Domain-based Message
   Authentication, Reporting and Conformance (DMARC), Sender Policy
   Framework (SPF) and Domain-Keys Identified Mail (DKIM). [30]

   Case Study: Cosmic Lynx

   Cosmic Lynx is a new business email compromise cybercrime gang which
   has already had over 200 targets in 46 countries since July 2019.
   [31] The criminal gang focus their attack on companies which don't
   deploy DMARC by using a fake 'mergers and acquisitions' email. The
   emails are linguistically well thought out and uses words not seen
   in phishing scams normally. Throughout the email correspondence
   about the business deal, they can directly spoof reply-to email
   addresses in order to look legitimate. Recipients are scammed into
   participating in sales and payments to attackers' bank accounts.

   Protocol Design Considerations: Allow for strong authentication of
   source of user data. Create policies for delivery of non-
   authenticated data. Ensure authentication of all communication at
   the protocol level and enable security checks and communication at
   all stages of the process.

4.13. Social/User Interface Interactions

   Defence Type: Prevention and detection.

   Since phishing is a social engineering type of attack, there should
   be education and training for people to prevent phishing.
   Furthermore, presenting a user with a photo on log-in to prevent
   logging into a phishing domain and two factor authentication (2FA)
   are some of the mitigation strategies. Also reporting of abnormal
   behaviour/user mistakes should be encouraged and failed log-in
   attempts should be displayed to the user. Finally appropriate
   password policies should be in place.


Lazanski               Expires January 13, 2021               [Page 21]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Case Study: TBD TODO

   Protocol Design Considerations: Protocols should support secure
   communication of security-critical information to and from the user
   interface; this could include passwords, biometric information,
   other credentials, user activity logs, PKI certificate properties
   and validity, origin authentication using auxiliary information
   (such as identifying phrases or photos).

4.14. Detection of Exfiltration and Data Leakage

   Defence Type: detection and mitigation

   When a compromise of a network has occurred, either by malware
   infection or insider threat, it is important to be able to detect
   attempts to exfiltrate data from the network and stop exfiltration
   as soon as the leak has been reliably confirmed.

   Detection of exfiltration can be through packet metadata analysis,
   statistical analysis of data collected over a period of time, or
   content inspection on unencrypted data.

   Case Study: SamSam is a ransomware that infects and then attacks
   after a period of monitoring networks and/or users. [31]Instead of
   attacking right away like WannaCry, SamSam manages to infect, delay
   and then attack again with the goal of infection, data infiltration
   and ransoming.[32]

   Protocol Design Considerations: Encryption of data can make
   inspection of data at a gateway for malicious exfiltration less
   reliable.

   Statistical properties of traffic may be used to detect exfiltration
   occurring over an extended period of time; it would be very bad for
   attack defence in general if protocols sought to hide patterns of
   traffic that are be indicative of exfiltration. If data is
   watermarked to indicate the origin of protected content, protocols
   should not destroy the watermarks. Protocols should minimise covert
   channels that can be used for the exfiltration of data by malware.

   Additionally, designing a recurring monitoring and reporting
   mechanism within the protocol would allow for regular and consistent
   logging.

4.15. Misuse of the Domain Name System.

   TODO


Lazanski               Expires January 13, 2021               [Page 22]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Defence Type: Detection and mitigation

   Case Study: TBD TODO

4.16. Attack and Defense Table TODO

   This section will be a table with attack, defence type, case
   studies, links and comments on the impact to protocol designs. This
   will be completed once the case studies have been added.

5. The Overall Security Picture

   Deployments of protocols vary greatly and use cases show the variety
   and diversity of design, development and implementation of
   protocols; There are varying levels of risk and a variety of threats
   being more likely than others depending on context in which the
   protocol is deployed. Therefore, some attacks and defensive measures
   outlined in the above sections may be more frequent than others. For
   example, an enterprise might consider customer data exfiltration a
   greater threat than its resilience to zero-day vulnerability
   exploitation, but an individual user might be more concerned with
   their protection against phishing than with seeing all traffic
   leaving their network.

   There is no one-size-fits-all approach for protocol deployment; each
   specific implementation and use case should be considered
   separately, as deployments require a mature a whole-system security
   view. This allows for a system wide analysis so that the security of
   the protocol isn't the only security considered.

   For example, a user with a client that runs DoH might feel
   completely secure, as the information is encrypted and the user has
   a private connection to the DNS resolver. However, this could
   actually bypass defensive filtering protections, without the
   protection afforded blocking of malicious domains. Further, unless
   DNSSEC is also deployed, you have no trust that the resolver is
   returning the correct results and no passive auditor to check this.

   Another popular example is the padlock in most browsers that tells
   users they have a secure HTTPS connection. Users can conflate the
   meaning of the padlock, assuming that use of HTTPS automatically
   confers a legitimate connection - even if the domain being connected
   to is fake or malicious.

6. Attack Defence in Security Considerations

   The impact of new protocols on existing systems that defend against
   malicious attacks is not systematically considered in the Security

Lazanski               Expires January 13, 2021               [Page 23]


Internet-Draft Security Considerations for Protocol Designers July 2020


   Considerations sections in RFCs. This draft is the first step in
   developing a reference guide to enable a systematic and consistent
   assessment across different protocols with respect to attack
   defence.

   Hence, protocols should be assessed against a range of attacks and
   detections methods, such as those attack types listed in the Table
   in Section 2 and those defensive measures listed in the Table in
   Section 4, as a standard consideration in all protocol design, and
   to make the potential impacts clear to deployers.

   When writing the Security Considerations for a protocol, protocol
   designers should consider known attacks and prevention, detection
   and mitigation methods. As the type, kind and characteristics of
   attacks grow in complexity, it is important that protocol designers
   take into account attack types and mitigation strategies into their
   designs. In fact this should be backed into the security
   considerations from the start. This draft RFC is a helpful guide to
   those considerations.

7.Security Considerations

   This document is entirely about Internet security and is an input to
   the IAB Model T work.

8. IANA Considerations

   This draft has no actions for IANA.

9. Conclusions

   This draft is a work in progress, but is a set of considerations for
   protocol designers and implementors with respect to attack defence.
   Collaborations and contributions would expand this document to make
   it more robust.

10. References

10.1. Normative References

[1]   RFC 7252 Shelby, Z. et al, "The Constrained Application Protocol
(CAP)" RFC 7252, June 2014.

[2]   https://www.zdnet.com/article/new-silex-malware-is-bricking-iot-
devices-has-scary-plans/

[3] https://www.omdia.com/resources/product-content/maersk-ciso-offers-
important-lessons-three-years-after-notpetya-attack-int005-000068]

Lazanski               Expires January 13, 2021               [Page 24]


Internet-Draft Security Considerations for Protocol Designers July 2020


[4]   https://www.theverge.com/2016/10/21/13362354/dyn-dns-ddos-attack-
cause-outage-status-explained

[5]   https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-
thing-for-ddos-attacks/

[6]   https://www.darkreading.com/endpoint/91--of-cyberattacks-start-
with-a-phishing-email/d/d-id/1327704

[7]   https://www.wired.com/2016/01/everything-we-know-about-ukraines-
power-plant-hack/

[8]   https://developers.facebook.com/docs/certificate-transparency/

[9]   RFC 6962 Laurie B., et al, "Certificate Transparency" RFC 6962,
June 2013.

[9]   https://techcrunch.com/2019/05/12/wannacry-two-years-on/

[10] https://www.lockheedmartin.com/en-us/capabilities/cyber/cyber-
kill-chain.html#

[11] https://www.kaspersky.com/resource-center/threats/ransomware-
wannacry

[12] https://www.cnbc.com/2017/07/31/new-anthem-data-breach-by-
contractor-affects-more-than-18000-enrollees.html

[13]  https://www.zdnet.com/article/for-two-hours-a-large-chunk-of-
european-mobile-traffic-was-rerouted-through-china/

[14]  https://www.internetsociety.org/blog/2018/04/amazons-route-53-
bgp-hijack/

[15]  https://www.enisa.europa.eu/topics/threat-risk-
management/threats-and-trends/enisa-threat-landscape

[16]  https://www.welivesecurity.com/2020/01/09/mozilla-rushes-patch-
firefox-zero-day/

[17]  https://www.forbes.com/sites/emilsayegh/2020/02/12/more-cloud-
more-hacks-pt-2/#7c0c47d669b3

[18]  https://threatpost.com/google-patches-chrome-browser-zero-day-
bug-under-attack/153216/



Lazanski               Expires January 13, 2021               [Page 25]


Internet-Draft Security Considerations for Protocol Designers July 2020


[19] https://www.crowdstrike.com/resources/reports/2020-crowdstrike-
global-threat-report/]

[20]  https://www.computerweekly.com/news/252446423/Industrial-
controls-systems-a-specialised-cyber-target

[21]  https://www.cnet.com/news/equifaxs-hack-one-year-later-a-look-
back-at-how-it-happened-and-whats-changed/

[22]  https://www.wired.com/2015/11/four-indicted-in-massive-jp-morgan-
chase-hack/

[23] https://www.darkreading.com/risk/microsoft-hands-off-nitol-botnet-
sinkhole-operation-to-chinese-cert/d/d-id/1138455]

[24] https://www.darkreading.com/risk/microsoft-hands-off-nitol-botnet-
sinkhole-operation-to-chinese-cert/d/d-id/1138455]

[25] https://www.itproportal.com/features/how-it-can-combat-the-rise-
in-vishing-attacks-in-this-new-normal/

[26] https://securitybrief.com.au/story/second-akamai-scrubbing-centre-
opens-in-melbourne

[27]  https://www.ncsc.gov.uk/guidance/phishing

[28] https://www.smh.com.au/business/companies/weakened-defences-covid-
19-a-boon-for-malware-merchants-warns-telstra-boss-20200505-p54q2a.html]

[29] https://kb.netgear.com/000061982/Security-Advisory-for-Multiple-
Vulnerabilities-on-Some-Routers-Mobile-Routers-Modems-Gateways-and-
Extenders

[30]  https://www.ncsc.gov.uk/collection/email-security-and-anti-
spoofing

[31] https://threatpost.com/russian-bec-gang-cosmic-lynx-
uncovered/157166/

[32] https://www.infradata.co.uk/resources/what-is-samsam-ransomware/

[33] https://blog.malwarebytes.com/cybercrime/2018/05/samsam-
ransomware-need-know/

[34] https://www.informationsecuritybuzz.com/study-research/new-
intelligence-reveals-that-alina-point-of-sale-malware-is-still-lurking-
in-dns/


Lazanski               Expires January 13, 2021               [Page 26]


Internet-Draft Security Considerations for Protocol Designers July 2020


11. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.














































Lazanski               Expires January 13, 2021               [Page 27]


Internet-Draft Security Considerations for Protocol Designers July 2020


Authors' Addresses

   Dominique Lazanski
   Last Press Label
   London, UK

   Email: dml@lastpresslabel.com










































Lazanski               Expires January 13, 2021               [Page 28]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/