draft-ietf-netconf-tls-01.txt   draft-ietf-netconf-tls-02.txt 
NETCONF Working Group Mohamad Badra NETCONF Working Group Mohamad Badra
Internet Draft LIMOS Laboratory Internet Draft LIMOS Laboratory
Intended status: Standards Track February 15, 2008 Intended status: Standards Track May 27, 2008
Expires: August 2008 Expires: November 2008
NETCONF over Transport Layer Security (TLS) NETCONF over Transport Layer Security (TLS)
draft-ietf-netconf-tls-01.txt draft-ietf-netconf-tls-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 15, 2008. This Internet-Draft will expire on November 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Network Configuration Protocol (NETCONF) provides mechanisms to The Network Configuration Protocol (NETCONF) provides mechanisms to
install, manipulate, and delete the configuration of network devices. install, manipulate, and delete the configuration of network devices.
This document describes how to use the Transport Layer Protocol (TLS) This document describes how to use the Transport Layer Protocol (TLS)
to secure NETCONF exchanges. to secure NETCONF exchanges.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
1.1. Conventions used in this document.........................2 1.1. Conventions used in this document.........................3
2. NETCONF over TLS...............................................3 2. NETCONF over TLS...............................................3
2.1. Connection Initiation.....................................3 2.1. Connection Initiation.....................................3
2.2. Connection Closure........................................3 2.2. Connection Closure........................................4
3. Endpoint Authentication and Identification.....................4 3. Endpoint Authentication and Identification.....................4
3.1. Server Identity...........................................4 3.1. Server Identity...........................................5
3.2. Client Identity...........................................5 3.2. Client Identity...........................................6
3.3. Password-Based Authentication.............................5 3.3. Password-Based Authentication.............................6
4. Cipher Suite Requirements......................................7 4. Cipher Suite Requirements......................................7
5. Security Considerations........................................7 5. Security Considerations........................................7
6. IANA Considerations............................................7 6. IANA Considerations............................................7
7. Acknowledgments................................................7 7. Acknowledgments................................................8
8. References.....................................................7 A. Appendix - Test Vectors for the PSK Derivation Function........9
8.1. Normative References......................................7 B. Appendix - Enabling Third Party Authentication using Passwords10
Author's Addresses................................................8 B.1. Working Group discussion at the 71st IETF meeting........12
Intellectual Property Statement...................................8 Normative References.............................................13
Disclaimer of Validity............................................9 Authors' Addresses...............................................14
Intellectual Property and Copyright Statements...................14
1. Introduction 1. Introduction
The NETCONF protocol [RFC4741] defines a simple mechanism through The NETCONF protocol [RFC4741] defines a simple mechanism through
which a network device can be managed. NETCONF is connection- which a network device can be managed. NETCONF is connection-
oriented, requiring a persistent connection between peers. This oriented, requiring a persistent connection between peers. This
connection must provide reliable, sequenced data delivery, integrity connection must provide reliable, sequenced data delivery, integrity
and confidentiality and peers authentication. This document and confidentiality and peers authentication. This document
describes how to use TLS [RFC4346] to secure NETCONF connections. describes how to use TLS [RFC4346] to secure NETCONF connections.
Throughout this document, the terms "client" and "server" are used to Throughout this document, the terms "client" and "server" are used to
refer to the two ends of the TLS connection. The client actively refer to the two ends of the TLS connection. The client actively
opens the TLS connection, and the server passively listens for the opens the TLS connection, and the server passively listens for the
skipping to change at page 3, line 23 skipping to change at page 3, line 47
The peer acting as the NETCONF manager MUST also act as the TLS The peer acting as the NETCONF manager MUST also act as the TLS
client. It MUST connect to the server that passively listens for the client. It MUST connect to the server that passively listens for the
incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>. incoming TLS connection on the IANA-to-be-assigned TCP port <TBA>.
It MUST therefore send the TLS ClientHello to begin the TLS It MUST therefore send the TLS ClientHello to begin the TLS
handshake. Once the TLS handshake has been finished, the client and handshake. Once the TLS handshake has been finished, the client and
the server MAY then send their NETCONF exchanges. In particular, the the server MAY then send their NETCONF exchanges. In particular, the
client will send complete XML documents to the server containing client will send complete XML documents to the server containing
<rpc> elements, and the server will respond with complete XML <rpc> elements, and the server will respond with complete XML
documents containing <rpc-reply> elements. The client MAY indicate documents containing <rpc-reply> elements. The client MAY indicate
interest in receiving event notifications from a NETCONF server by interest in receiving event notifications from a NETCONF server by
creating a subscription to receive event notifications [NETNOT], in creating a subscription to receive event notifications [I-D.ietf--
which the NETCONF server replies to indicate whether the subscription netconf-notification], in which the NETCONF server replies to
request was successful and, if it was successful, begins sending the indicate whether the subscription request was successful and, if it
event notifications to the NETCONF client as the events occur within was successful, begins sending the event notifications to the NETCONF
the system. All these elements are encapsulated into TLS records of client as the events occur within the system. All these elements are
type "application data". These records are protected using the TLS encapsulated into TLS records of type "application data". These
material keys. records are protected using the TLS material keys.
Current NETCONF messages don't include a message's length. This Current NETCONF messages don't include a message's length. This
document uses consequently the same delimiter sequence defined in document uses consequently the same delimiter sequence defined in
[RFC4742] and therefore the special character sequence, ]]>]]>, to [RFC4742] and therefore the special character sequence, ]]>]]>, to
delimit XML documents. delimit XML documents.
2.2. Connection Closure 2.2. Connection Closure
Either NETCONF peer MAY stop the NETCONF connection at any time and Either NETCONF peer MAY stop the NETCONF connection at any time and
therefore notify the other NETCONF peer that no more data on this therefore notify the other NETCONF peer that no more data on this
channel will be sent and that any data received after a closure channel will be sent and that any data received after a closure
request will be ignored. This MAY happen when no data is received request will be ignored. This MAY happen when no data is received
from a connection for a long time, where the application decides what from a connection for a long time, where the application decides what
"long" means. "long" means.
TLS has the ability for secure connection closure using the Alert TLS has the ability for secure connection closure using the Alert
protocol. When the NETCONF peer processes a closure request of the protocol. When the NETCONF peer closes the NETCONF connection, it
NETCONF connection, it MUST send a TLS close_notify alert before MUST send a TLS close_notify alert before closing the TCP connection.
closing the connection. Any data received after a closure alert is Any data received after a closure alert is ignored.
ignored.
Unless some other fatal alert has been transmitted, each party is Unless a fatal error has occurred, each party is required to send a
required to send a close_notify alert before closing the write side close_notify alert before closing the write side of the connection
of the connection. The other party MUST respond with a close_notify [RFC4346]. The other party MUST respond with a close_notify alert of
alert of its own and close down the connection immediately, its own and close down the connection immediately, discarding any
discarding any pending writes. It is not required for the initiator pending writes. It is not required for the initiator of the close to
of the close to wait for the responding close_notify alert before wait for the responding close_notify alert before closing the read
closing the read side of the connection. side of the connection.
3. Endpoint Authentication and Identification 3. Endpoint Authentication and Identification
NETCONF requires that its transport provide mutual authentication of NETCONF requires that its transport provide mutual authentication of
client and server, so cipher suites that are anonymous or which only client and server, so cipher suites that are anonymous or which only
authenticate the server to the client MUST NOT be used with NETCONF. authenticate the server to the client MUST NOT be used with NETCONF.
This document specifies how to use TLS with endpoint authentication This document specifies how to use TLS with endpoint authentication,
in TLS can be based on either preshared keys [RFC4279] or public key which can be based on either preshared keys [RFC4279] or public key
certificates [RFC4346]. Some cipher suites (e.g. certificates [RFC4346]. Some cipher suites (e.g.
TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1 describes TLS_RSA_PSK_WITH_AES_128_CBC_SHA) use both. Section 3.1 describes
how the client authenticates the server if public key certificates how the client authenticates the server if public key certificates
are provided by the server, section 3.2 describes how the server are provided by the server, section 3.2 describes how the server
authenticates the client if public key certificates are provided by authenticates the client if public key certificates are provided by
the client, and section 3.3 describes how the client and server the client, and section 3.3 describes how the client and server
mutually authenticate one another using a password. mutually authenticate one another using a password.
3.1. Server Identity 3.1. Server Identity
skipping to change at page 5, line 21 skipping to change at page 5, line 46
dNSName field), then a match with any one of the fields is dNSName field), then a match with any one of the fields is
considered acceptable. considered acceptable.
If the match fails, the client MUST either ask for explicit user If the match fails, the client MUST either ask for explicit user
confirmation or terminate the connection and indicate the server's confirmation or terminate the connection and indicate the server's
identity is suspect. identity is suspect.
Additionally, clients MUST verify the binding between the identity of Additionally, clients MUST verify the binding between the identity of
the servers to which they connect and the public keys presented by the servers to which they connect and the public keys presented by
those servers. Clients SHOULD implement the algorithm in Section 6 those servers. Clients SHOULD implement the algorithm in Section 6
of [RFC3280] for general certificate validation, but MAY supplement of [RFC5280] for general certificate validation, but MAY supplement
that algorithm with other validation methods that achieve equivalent that algorithm with other validation methods that achieve equivalent
levels of verification (such as comparing the server certificate levels of verification (such as comparing the server certificate
against a local store of already-verified certificates and identity against a local store of already-verified certificates and identity
bindings). bindings).
If the client has external information as to the expected identity of If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. the server, the hostname check MAY be omitted.
3.2. Client Identity 3.2. Client Identity
skipping to change at page 6, line 7 skipping to change at page 6, line 32
The PSK can be generated in many ways and its length is variable. The PSK can be generated in many ways and its length is variable.
Implementation of this document MAY rely on [RFC4279] to enable Implementation of this document MAY rely on [RFC4279] to enable
password based user authentication. In this case, the password is password based user authentication. In this case, the password is
used to generate the PSK. It is RECOMMENDED that implementations used to generate the PSK. It is RECOMMENDED that implementations
that allow the administrator to manually configure the password also that allow the administrator to manually configure the password also
provide functionality for generating a new random password, taking provide functionality for generating a new random password, taking
[RFC4086] into account. [RFC4086] into account.
This document generates the PSK from the password as follow: This document generates the PSK from the password as follow:
PSK = SHA-1(SHA-1(password + psk_identity + "Key Pad for Netconf") + PSK = SHA-1(SHA-1(psk_identity + "Key Pad for Netconf" + password) +
psk_identity_hint) psk_identity_hint)
Where + means concatenation. Where + means concatenation.
The label "Key Pad for Netconf" is an ASCII string. The label "Key Pad for Netconf" is an ASCII string.
The psk_identity_hint is initially defined in section 5.1 of The psk_identity_hint is initially defined in section 5.1 of
[RFC4279]. The psk_identity_hint can do double duty and also provide [RFC4279]. The psk_identity_hint can do double duty and also provide
a form of server authentication in the case where the user has the a form of server authentication in the case where the user has the
same password on a number of NETCONF servers. If a hint is provided, same password on a number of NETCONF servers. If a hint is provided,
skipping to change at page 6, line 33 skipping to change at page 7, line 11
psk_identity_hint, the software could display the server's name and psk_identity_hint, the software could display the server's name and
ask the user to confirm. For automated scripts, the names could be ask the user to confirm. For automated scripts, the names could be
expected to match. It is highly recommended that implementations set expected to match. It is highly recommended that implementations set
the psk_identity_hint to the DNS name of the NETCONF server (i.e., the psk_identity_hint to the DNS name of the NETCONF server (i.e.,
the TLS server). the TLS server).
It is RECOMMENDED that users choose different passwords for the It is RECOMMENDED that users choose different passwords for the
different servers they manage. different servers they manage.
Note 1: The NETCONF over TLS implementation need not store the Note 1: The NETCONF over TLS implementation need not store the
password in clear text, but rather can store the value of SHA- password in clear text, but rather can store the value of the
1(SHA-1(password + psk_identity + "Key Pad for Netconf") + inner SHA-1 (SHA-1(SHA-1(password + psk_identity + "Key Pad for
psk_identity_hint), which could not be used as a password Netconf") + psk_identity_hint)), which could not be used as a
equivalent for applications other than NETCONF. Deriving the PSK password equivalent for applications other than NETCONF. Deriving
from a password is not secure. This construction is used because the PSK from a password is not secure. This construction is used
it is anticipated that people will do it anyway. because it is anticipated that people will do it anyway.
Note 2: [RFC4279] defines some conformance requirements for the Note 2: [RFC4279] defines some conformance requirements for the
PSK, for the PSK identity encoding and for the identity hint. The PSK, for the PSK identity encoding and for the identity hint. The
same requirements apply here as well; in particular on the same requirements apply here as well; in particular on the
password. Moreover, the management interface by which the password. Moreover, the management interface by which the
password is provided MUST accept ASCII strings of at least 64 password is provided MUST accept ASCII strings of at least 64
octets and MUST NOT add a null terminator before using them as octets and MUST NOT add a null terminator before using them as
shared secrets. It MUST also accept a HEX encoding of the shared secrets. It MUST also accept a HEX encoding of the
password. The management interface MAY accept other encodings if password. The management interface MAY accept other encodings if
the algorithm for translating the encoding to a binary string is the algorithm for translating the encoding to a binary string is
skipping to change at page 7, line 32 skipping to change at page 8, line 9
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a TCP port number that will be the IANA is requested to assign a TCP port number that will be the
default port for NETCONF over TLS sessions as defined in this default port for NETCONF over TLS sessions as defined in this
document. document.
IANA has assigned port <TBA> for this purpose. IANA has assigned port <TBA> for this purpose.
7. Acknowledgments 7. Acknowledgments
A significant amount of the text in this document was lifted from A significant amount of the text in Section 3.1 was lifted from
[RFC4642]. [RFC4642].
The author would like to acknowledge David Harrington, Miao Fuyou, The author would like to acknowledge David Harrington, Miao Fuyou,
Eric Rescorla, Juergen Schoenwaelder and the NETCONF mailing list Eric Rescorla, Juergen Schoenwaelder, Simon Josefsson, Olivier
members for their comments on the document. The author appreciates Coupelon and the NETCONF mailing list members for their comments on
also Bert Wijnen and Dan Romascanu for their efforts on issues the document. The author appreciates also Bert Wijnen, Mehmet Ersue
resolving discussion, and Charlie Kaufman for the thorough review of and Dan Romascanu for their efforts on issues resolving discussion,
this document and for the helpful comments on the password-based and Charlie Kaufman for the thorough review of this document and for
authentication. the helpful comments on the password-based authentication.
8. References A. Appendix - Test Vectors for the PSK Derivation Function
8.1. Normative References The test vectors for the PSK derivation function in this document
have been cross-verified by two independent implementations. An
implementation that concurs with the results provided in this
document should be interoperable with other similar implementations.
password = password
psk_identity = psk_identity
psk_identity_hint = psk_identity_hint
The inner SHA-1 value (in hex):
inner := SHA-1(password + psk_identity + "Key Pad for Netconf")
== SHA-1("psk_identityKey Pad for Netconfpassword")
=> 6d6eeb6a b8d0466b 45245d07 47d86726 b41b868c
The outer SHA-1 value (in hex):
outer := SHA-1(inner + psk_identity_hint)
=> 88f3824b 3e5659f5 2d00e959 bacab954 b6540344
B. Appendix - Enabling Third Party Authentication using Passwords
During the 71st IETF meeting, several proposals have been proposed to
enable third party authentication that could be used in combination
with existing user authentication databases such as RADIUS. They are
listed below. More details on those proposals may be found at
https://www3.ietf.org/proceedings/08mar/slides/netconf-1/netconf-
1.htm and
http://www.psg.com/lists/netconf/netconf.2008/msg00125.html.
We summarize them as following:
1. Defining <user-login> RPC:
--------------------------
This option relies on JUNOS mechanism to enable an authentication
function via third parties. It consists of establishing a TLS with
no manager authentication, leaving the <request-login> RPC as the
only valid RPC. Anything else is an error.
Once the TLS session is established, the agent MUST authenticate
the manager by emitting the following <rpc> tag element:
<rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<challenge>Password:</challenge>
</rpc-reply>
In which the manager MUST reply with the following:
<rpc>
<request-login>
<challenge-response>password</challenge-response>
</request-login>
</rpc>
The rules to handle this were pretty simple:
- The <request-login> RPC could only be performed if the session
wasn't authenticated.
- No other RPCs could be performed if the session wasn't
authenticated.
- The transport protocol can authenticate the session
(internally).
Pros and cons:
o is simple to do. But
o might raise questions from the security ADs; NETCONF assumes
the authentication is part of the transport not NETCONF.
o only works for plaintext passwords (SASL PLAIN).
2. Enhancing TLS:
--------------
The second option consists of extending TLS so the manager
authentication becomes part of TLS. This extension, detailed in
http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt,
defines a new extension and a new TLS message to the TLS protocol
to enable TLS client authentication using passwords. The extension
is used to convey the manager login, whereas the new message is
defined and sent by the manager to prove its knowledge of the
password.
Steps during the TLS negotiation:
- The manager adds such an extension to its TLS ClientHello.
- If the agent agrees on using this extension, it will notify
the manager and replies with its certificate and/or its
authenticated public key.
- The manager generates a premaster secret and encrypts it
using the agent public key.
- The manager then computes the session key using the premaster
secret and encrypts, among others, its password with the
computed key.
- The agent decrypts the premaster secret and computes the same
key to decrypt the password.
- The agent checks with a database (or AAA infrastructures) to
verify the password and then to authenticate the manager.
Pros and cons
o is simple to do. But
o It is indeed not easy to convince TLS WG to add password
authentication extension to TLS.
3. Running BEEP over TLS:
----------------------
It looks complex for a solution, requires that all implementations
do actually support BEEP.
4. Extending NETCONF with a message to start TLS:
----------------------------------------------
This option consists of extending NETCONF with a new message to
start the TLS negotiation and to perform an authentication
mechanism based on RFC4422 (SASL) or on any similar protocol.
Pros and cons
o simple to do. But
o might raise questions from the security ADs; NETCONF assumes
the authentication is part of the transport not NETCONF.
Moreover, it adds complexity related to the use of SASL
PLAIN.
5. Enable SSH (RFC4742 and TLS (as defined through this document:
--------------------------------------------------------------
Since SSH already defines a password-based authentication and
because this protocol MUST be implemented as a security protocol
for NETCONF, users can rely on SSH for password authentication, and
on TLS for authentication using PSK or certificates. This means the
agent SHOULD passively listen for the incoming SSH (respectively
TLS) connection on port 830 (respectively port <TBA-by-IANA>).
Pros and cons
o simple to do.
o already specified by RFC4742 and by the current document.
B.1. Working Group discussion at the 71st IETF meeting
Some of the options have been found as not practical in the WG
session during 71st meeting.
Options #2 and #3 have not been supported in the WG session.
Option #1 and # 4 seems to be against the security design for
NETCONF. Whether #5 or other options can be accepted by the WG
members needs to be discussed on the mailing list.
Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
X.509 Public Key Infrastructure Certificate and Certificate Housley, R., and W. Polk, "Internet X.509 Public Key
Revocation List (CRL) Profile", RFC 3280, April 2002. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005. June 2005.
[RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites [RFC4279] Eronen, P. and H. Tschofenig., "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December for Transport Layer Security (TLS)", RFC 4279, December
2005. 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
skipping to change at page 8, line 35 skipping to change at page 13, line 45
Layer Security (TLS) with Network News Transfer Protocol Layer Security (TLS) with Network News Transfer Protocol
(NNTP)", RFC 4642, October 2006 (NNTP)", RFC 4642, October 2006
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
Configuration Protocol over Secure Shell (SSH)", RFC 4742, Configuration Protocol over Secure Shell (SSH)", RFC 4742,
December 2006. December 2006.
[NETNOT] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", [I-D.ietf-netconf-notification]
draft-ietf-netconf-notification-11.txt, (work in progress), Chisholm, S. and H. Trevino, "NETCONF Event Notifications",
November 2007. draft-ietf-netconf-notification-12.txt, (work in progress),
February 2008.
Author's Addresses Authors' Addresses
Mohamad Badra Mohamad Badra
LIMOS Laboratory - UMR6158, CNRS LIMOS Laboratory - UMR6158, CNRS
France France
Email: badra@isima.fr Email: badra@isima.fr
Contributors
Ibrahim Hajjeh
INEOVATION
France
Email: hajjeh@ineovation.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 23 change blocks. 
61 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/