[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-ietf-netconf-reverse-ssh) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 RFC 8071

NETCONF Working Group                                          K. Watsen
Internet-Draft                                          Juniper Networks
Updates: 4253 (if approved)                             February 2, 2015
Intended status: Standards Track
Expires: August 6, 2015


                NETCONF Call Home and RESTCONF Call Home
                    draft-ietf-netconf-call-home-04

Abstract

   This document presents NETCONF Call Home and RESTCONF Call Home,
   which respectively enable a NETCONF/RESTCONF server to initiate a
   secure connection to a NETCONF/RESTCONF client.

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  Please note
   that no other RFC Editor instructions are specified anywhere else in
   this document.

   Artwork in this document contains placeholder references for this
   draft.  Please apply the following replacement:

   o  "XXXX" --> the assigned RFC value for this draft

   This document contains references to other drafts in progress, both
   in the Normative References section, as well as in body text
   throughout.  Please update the following references to reflect their
   final RFC assignments:

   o  draft-ietf-netconf-restconf

   o  draft-ietf-netconf-server-model

   Artwork in this document contains placeholder values for ports
   pending IANA assignment from "draft-ietf-netconf-call-home".  Please
   apply the following replacements:

   o  "PORT-X" --> the assigned port value for "netconf-ch-ssh"

   o  "PORT-Y" --> the assigned port value for "netconf-ch-tls"

   o  "PORT-Z" --> the assigned port value for "restconf-ch-tls"




Watsen                   Expires August 6, 2015                 [Page 1]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   The following two Appendix sections are to be removed prior to
   publication:

   o  Appendix A.  Change Log

   o  Appendix B.  Open Issues

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 6, 2015.

Copyright Notice

   Copyright (c) 2015 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Requirements Terminology  . . . . . . . . . . . . . . . .   4
     1.3.  Applicability Statement . . . . . . . . . . . . . . . . .   4
     1.4.  Update to RFC 4253  . . . . . . . . . . . . . . . . . . .   5
   2.  The NETCONF or RESTCONF Server  . . . . . . . . . . . . . . .   5
     2.1.  Protocol Operation  . . . . . . . . . . . . . . . . . . .   5



Watsen                   Expires August 6, 2015                 [Page 2]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


     2.2.  Configuration Data Model  . . . . . . . . . . . . . . . .   6
   3.  The NETCONF or RESTCONF Client  . . . . . . . . . . . . . . .   6
     3.1.  Protocol Operation  . . . . . . . . . . . . . . . . . . .   6
     3.2.  Server Identification and Verification  . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  12
     A.1.  00 to 01  . . . . . . . . . . . . . . . . . . . . . . . .  12
     A.2.  01 to 02  . . . . . . . . . . . . . . . . . . . . . . . .  12
     A.3.  02 to 03  . . . . . . . . . . . . . . . . . . . . . . . .  12
     A.4.  03 to 04  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   This document presents NETCONF Call Home and RESTCONF Call Home,
   which respectively enable a NETCONF/RESTCONF server to initiate a
   secure connection to a NETCONF/RESTCONF client.  The NETCONF protocol
   is described in [RFC6241] and the RESTCONF is described in
   [draft-ietf-netconf-restconf].

   Both NETCONF Call Home and RESTCONF Call Home preserve the client/
   server roles of underlying transport, as when compared to standard
   NETCONF and RESTCONF connections.  Specifically, regardless if call
   home is used or not, the SSH and TLS client/server roles are the
   same.  The SSH protocol is defined in [RFC4253] and the TLS protocol
   is defined in [RFC5246].

   Ensuring consistency in the SSH and TLS roles is both necessary and
   desirable.  Ensuring consistency is necessary for the SSH protocol,
   as SSH channels and subsystems can only be opened on the SSH server,
   which thus must always be the NETCONF server, in order to support
   NETCONF over SSH [RFC6242].  Ensuring consistency is desirable, for
   both the SSH and TLS protocols, as it conveniently leverages
   infrastructure that may be deployed for host-key or certificate
   verification and user authentication.

1.1.  Motivation

   Call home is generally useful for both the initial deployment and on-
   going management of networking elements.  Here are some scenarios
   enabled by call home:





Watsen                   Expires August 6, 2015                 [Page 3]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   o  The network element may proactively call home after being powered
      on for the first time in order to register itself with its
      management system.

   o  The network element may access the network in a way that
      dynamically assigns it an IP address and it doesn't register its
      assigned IP addressed to a mapping service, thus complicating the
      ability for a management system to connect to it.

   o  The network element may be deployed behind a firewall that
      implements network address translation (NAT) for all internal
      network IP addresses, thus complicating the ability for a
      management system to connect to it.

   o  The network element may be deployed behind a firewall that doesn't
      allow any management access to the internal network.

   o  The network element may be configured in "stealth mode" and thus
      doesn't have any open ports for the management system to connect
      to.

   o  The operator may prefer to have network elements initiate
      management connections, believing it is easier to secure one open-
      port in the data center than to have an open port on each network
      element in the network.

   As the NETCONF and RESTCONF protocols become increasingly popular for
   programatic management of networking elements, having call home
   support for these two protocols is particularly desirable.

1.2.  Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.3.  Applicability Statement

   The techniques described in this document are suitable for network
   management scenarios such as the ones described in Section 1.1.
   However, these techniques SHOULD only be used for NETCONF Call Home
   and RESTCONF Call Home, as described in this document.

   The reason for this restriction is that different protocols have
   different security assumptions.  The NETCONF and RESTCONF protocols
   require clients and servers to verify the identity of the other party
   before starting the NETCONF/RESTCONF protocol (section 2.2 of
   [RFC6241] and sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]).



Watsen                   Expires August 6, 2015                 [Page 4]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   This contrasts with the base SSH and TLS protocols, which do not
   require programmatic verification of the other party (section 9.3.4
   of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]).
   In such circumstances, allowing the SSH/TLS server to contact the
   SSH/TLS client would open new vulnerabilities.  Any use of call home
   with SSH/TLS for purposes other than NETCONF or RESTCONF will need a
   thorough, contextual security analysis.

1.4.  Update to RFC 4253

   This document updates the SSH Transport Layer Protocol [RFC4253] only
   in removing the "The client initiates the connection" statement made
   in Section 4 (Connection Setup).  This document assumes that the
   reference to "connection" refers to the underlying transport
   connection (e.g., TCP), which the NETCONF server would initiate in a
   call home connection using the SSH protocol, even though it will not
   take on the role of the SSH client.  Security implications related to
   this change are discussed in Security Considerations (Section 4).

2.  The NETCONF or RESTCONF Server

2.1.  Protocol Operation

   o  The NETCONF/RESTCONF server initiates a TCP connection request
      (SYN) to the NETCONF/RESTCONF client.  The server SHOULD default
      to connecting to one of the IANA-assigned ports defined in section
      Section 5, but MAY be configured to use a non-default port.

   o  The TCP connection request is accepted and a TCP connection is
      established.

   o  Using this TCP connection, the NETCONF/RESTCONF server MUST
      immediately start using either the SSH-server [RFC4253] or the
      TLS-server [RFC5246] protocol, depending on how it is configured.
      For example, assuming the use of the IANA-assigned ports, the SSH-
      server protocol is used for PORT-X and the TLS-server protocol is
      used for either port PORT-Y or PORT-Z.

   o  Once the SSH or TLS connection is established, the NETCONF/
      RESTCONF server MUST immediately start using either the NETCONF-
      server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf]
      protocol, depending on how it is configured.  Assuming the use of
      the IANA-assigned ports, the NETCONF-server protocol is used for
      PORT-X or PORT-Y and the RESTCONF-server protocol is used for
      PORT-Z.






Watsen                   Expires August 6, 2015                 [Page 5]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   o  The NETCONF protocol's binding to SSH and TLS is defined in
      [RFC6242] and [RFC5539] respectively.  The RESTCONF protocol's
      binding to TLS is is defined in [RFC7230].

2.2.  Configuration Data Model

   How to configure a NETCONF or RESTCONF server to initiate a call home
   connection is outside the scope of this document, as implementations
   can support this protocol using proprietary configuration data
   models.  That said, a YANG [RFC6020] model for configuring both
   NETCONF Call Home and RESTCONF Call Home is provided in
   [draft-ietf-netconf-server-model].

3.  The NETCONF or RESTCONF Client

3.1.  Protocol Operation

   o  The NETCONF/RESTCONF client listens for TCP connections from
      NETCONF/RESTCONF servers.  The client SHOULD default to listening
      for connections on the IANA-assigned ports defined in section
      Section 5, but MAY be configured to use a non-default port.

   o  The NETCONF/RESTCONF client accepts an incoming TCP connection
      request and a TCP connection is established.

   o  Using this TCP connection, the NETCONF/RESTCONF client MUST
      immediately start using either the SSH-client [RFC4253] or the
      TLS-client [RFC5246] protocol, depending on how it is configured.
      For example, assuming the use of the IANA-assigned ports, the SSH-
      client protocol is used for PORT-X and the TLS-client protocol is
      used for either port PORT-Y or PORT-Z.

   o  Once the SSH or TLS connection is established, the NETCONF/
      RESTCONF client MUST immediately start using either the NETCONF-
      client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf]
      protocol, depending on how it is configured.  Assuming the use of
      the IANA-assigned ports, the NETCONF-client protocol is used for
      PORT-X or PORT-Y and the RESTCONF-client protocol is used for
      PORT-Z.

   o  The NETCONF protocol's binding to SSH and TLS is defined in
      [RFC6242] and [RFC5539] respectively.  The RESTCONF protocol's
      binding to TLS is is defined in [RFC7230].








Watsen                   Expires August 6, 2015                 [Page 6]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


3.2.  Server Identification and Verification

   Under normal circumstances, a NETCONF/RESTCONF client initiates the
   connection to the NETCONF/RESTCONF server.  This action provides
   essential input used to verify the NETCONF/RESTCONF server's
   identity.  For instance, when using TLS, the input can be compared to
   the domain names and IP addresses encoded in X.509 certificates.
   Similarly, when using SSH, the input can be compared to information
   persisted previously.

   However, when receiving a call home connection, the NETCONF/RESTCONF
   client does not have any context leading it to know the connection is
   from a particular NETCONF/RESTCONF server.  Thus the NETCONF/RESTCONF
   client must derive the NETCONF/RESTCONF server's identity using
   information provided by the network and the NETCONF/RESTCONF server
   itself.  This section describes strategies a NETCONF/RESTCONF client
   can use to identify a NETCONF/RESTCONF server.

   In addition to identifying a NETCONF/RESTCONF server, a NETCONF/
   RESTCONF client must also be able to verify the server's identity.
   Verifying a NETCONF/RESTCONF server's identity is necessary under
   normal circumstances but, due to call home being commonly used for
   newly deployed NETCONF/RESTCONF servers, how to verify its identity
   the very first time becomes a prominent concern.  Therefore, this
   section also describes strategies a NETCONF/RESTCONF client can use
   to verify a NETCONF/RESTCONF server's identity.

   The first information a NETCONF/RESTCONF client learns from a call
   home connection is the IP address of the NETCONF/RESTCONF server, as
   provided by the source address of the TCP connection.  This IP
   address could be used as an identifier directly, but doing so would
   only work in networks that use known static addresses, in which case
   a standard NETCONF/RESTCONF connection would have worked just as
   well.  Due to this limited use, it is not recommended to identify a
   NETCONF/RESTCONF server based on its source IP address.

   The next information a NETCONF/RESTCONF client learns is provided by
   the NETCONF/RESTCONF server in the form of a host-key or a
   certificate, for the SSH and TLS protocols respectively.  Without
   examining the contents of the host-key or certificate, it is possible
   to form an identity for the NETCONF/RESTCONF server using it directly
   (e.g., a fingerprint).  This works because each NETCONF/RESTCONF
   server is assumed to have a statistically unique public key, even in
   virtualized environments.  This strategy also provides a mechanism to
   verify the identity of the NETCONF/RESTCONF server, in that a secure
   connection can only be established with the NETCONF/RESTCONF server
   having the matching private key.  This strategy is commonly
   implemented by SSH clients, and could be used equally well by TLS-



Watsen                   Expires August 6, 2015                 [Page 7]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   based clients, such as may be required when the NETCONF/RESTCONF
   servers have self-signed certificates.  This strategy is viable and
   useful when the NETCONF/RESTCONF servers call home using either SSH
   with standard RSA/DSA host-keys, or using TLS with self-signed
   certificates.

   Yet another option for identifying a NETCONF/RESTCONF server is for
   its host key or certificate to encode its identity directly (e.g.,
   within the "Subject" field).  However, in order to trust the content
   encoded within a host-key or certificate, it must be signed by a
   certificate authority trusted by the NETCONF/RESTCONF client.  This
   strategy's use of PKI enables a NETCONF/RESTCONF client to
   transparently authenticate the NETCONF/RESTCONF server's certificate,
   thus eliminating the need for manual authentication, as required by
   the previously discussed strategies.  Elimination of manual steps is
   needed to achieve scalable solutions, however one can claim that this
   merely pushes equivalent work to provisioning the NETCONF/RESTCONF
   servers with signed certificates.  This assessment is accurate in
   general, but not in the case where the manufacturer itself provisions
   the certificates, such as is described by [Std-802.1AR-2009].  When
   NETCONF/RESTCONF servers are pre-provisioned this way, NETCONF/
   RESTCONF clients can transparently authenticate NETCONF/RESTCONF
   servers using just the manufacturer's trust anchor and a list of
   expected NETCONF/RESTCONF server identifiers, which could be provided
   along with shipping information.  This strategy is recommended for
   all deployment scenarios.

   In discussing the use of certificates, it is worth noting that TLS
   uses X.509 certificates by default.  However, to use X.509
   certificates with SSH, both the NETCONF client and server must
   support [RFC6187].

4.  Security Considerations

   The security considerations described throughout [RFC6242] and
   [RFC5539], and by extension [RFC4253], [RFC5246], and
   [draft-ietf-netconf-restconf] apply here as well.

   This RFC deviates from standard SSH and TLS usage by having the SSH/
   TLS server initiate the underlying TCP connection.  For SSH,
   [RFC4253] says "the client initiates the connection", whereas for
   TLS, [RFC5246] says it is layered on top of "some reliable transport
   protocol" without further attribution.

   Not having the SSH/TLS client initiate the TCP connection means that
   it does not have a preconceived notion of the SSH/TLS server's
   identity, and therefore must dynamically derive one from information




Watsen                   Expires August 6, 2015                 [Page 8]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   provided by the network or the SSH/TLS server itself.  Security
   Considerations for strategies for this are described in Section 3.2.

   An attacker could DoS the NETCONF/RESTCONF client by having it
   perform computationally expensive operations, before deducing that
   the attacker doesn't posses a valid key.  This is no different than
   any secured service and all common precautions apply (e.g.,
   blacklisting the source address after a set number of unsuccessful
   login attempts).

5.  IANA Considerations

   This document requests that IANA assigns three TCP port numbers in
   the "Registered Port Numbers" range with the service names "netconf-
   ch-ssh", "netconf-ch-tls", and "restconf-ch-tls".  These ports will
   be the default ports for NETCONF Call Home and RESTCONF Call Home
   protocols.  Below is the registration template following the rules in
   [RFC6335].

   Service Name:           netconf-ch-ssh
   Transport Protocol(s):  TCP
   Assignee:               IESG <iesg@ietf.org>
   Contact:                IETF Chair <chair@ietf.org>
   Description:            NETCONF Call Home (SSH)
   Reference:              RFC XXXX
   Port Number:            PORT-X

   Service Name:           netconf-ch-tls
   Transport Protocol(s):  TCP
   Assignee:               IESG <iesg@ietf.org>
   Contact:                IETF Chair <chair@ietf.org>
   Description:            NETCONF Call Home (TLS)
   Reference:              RFC XXXX
   Port Number:            PORT-Y

   Service Name:           restconf-ch-tls
   Transport Protocol(s):  TCP
   Assignee:               IESG <iesg@ietf.org>
   Contact:                IETF Chair <chair@ietf.org>
   Description:            RESTCONF Call Home (TLS)
   Reference:              RFC XXXX
   Port Number:            PORT-Z

6.  Acknowledgements

   The author would like to thank for following for lively discussions
   on list and in the halls (ordered by last name): Andy Bierman, Martin
   Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David



Watsen                   Expires August 6, 2015                 [Page 9]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ
   Mundy, Tom Petch, Peter Saint-Andre, Joe Touch, Hannes Tschofenig,
   Sean Turner, Bert Wijnen.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4252]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5539]  Badra, M., "NETCONF over Transport Layer Security (TLS)",
              RFC 5539, May 2009.

   [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", RFC 6020,
              October 2010.

   [RFC6187]  Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure
              Shell Authentication", RFC 6187, March 2011.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, June 2011.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165, RFC
              6335, August 2011.






Watsen                   Expires August 6, 2015                [Page 10]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


   [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
              2014.

   [draft-ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ieft-netconf-restconf-04 (work in
              progress), 2014.

7.2.  Informative References

   [Std-802.1AR-2009]
              IEEE SA-Standards Board, "IEEE Standard for Local and
              metropolitan area networks - Secure Device Identity",
              December 2009, <http://standards.ieee.org/findstds/
              standard/802.1AR-2009.html>.

   [draft-ietf-netconf-server-model]
              Watsen, K. and J. Schoenwaelder, "NETCONF Server
              Configuration Model", 2014, <http://tools.ietf.org/html/
              draft-ietf-netconf-server-model>.






























Watsen                   Expires August 6, 2015                [Page 11]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


Appendix A.  Change Log

A.1.  00 to 01

   o  The term "TCP connection" is now used throughout.

   o  The terms "network element" and "management system" are now only
      used in the Motivation section.

   o  Restructured doc a little to create an Introduction section.

   o  Fixed reference in Applicability Statement so it would work
      equally well for SSH and TLS.

   o  Fixed reported odd wording and three references.

A.2.  01 to 02

   o  Added call home support for the RESTCONF protocol.

   o  Fixed paragraph 3 of Security Considerations to equally apply to
      the TLS protocol.

A.3.  02 to 03

   o  Tried to improve readability (issue #6)

   o  Removed "FIXME" in section 1.3 (issue #7)

   o  Added RFC Editor notes (issue #8)

   o  Removed "TCP session" term (issue #9)

   o  Improved language for usage of IANA-assigned ports (issue #10)

A.4.  03 to 04

   o  Replaced "verify credentials" with "verify identity" (issue #11)

Appendix B.  Open Issues

   All issues with this draft are tracked using GitHub issues.  Please
   see: https://github.com/netconf-wg/call-home/issues to see currently
   opened issues.







Watsen                   Expires August 6, 2015                [Page 12]


Internet-Draft  NETCONF Call Home and RESTCONF Call Home   February 2015


Author's Address

   Kent Watsen
   Juniper Networks

   EMail: kwatsen@juniper.net













































Watsen                   Expires August 6, 2015                [Page 13]


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