doc: Add RFC documents

1 files changed, 283 insertions, 0 deletions

diff --git a/doc/rfc/rfc7443.txt b/doc/rfc/rfc7443.txt
new file mode 100644
index 0000000..e2d61e2
--- /dev/null
+++ b/doc/rfc/rfc7443.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          P. Patil
+Request for Comments: 7443                                      T. Reddy
+Category: Informational                                     G. Salgueiro
+ISSN: 2070-1721                                                    Cisco
+                                                       M. Petit-Huguenin
+                                                      Impedance Mismatch
+                                                            January 2015
+
+
+          Application-Layer Protocol Negotiation (ALPN) Labels
+         for Session Traversal Utilities for NAT (STUN) Usages
+
+Abstract
+
+   Application-Layer Protocol Negotiation (ALPN) labels for Session
+   Traversal Utilities for NAT (STUN) usages, such as Traversal Using
+   Relays around NAT (TURN) and NAT discovery, are defined in this
+   document to allow an application layer to negotiate STUN usages
+   within the Transport Layer Security (TLS) connection.  ALPN protocol
+   identifiers defined in this document apply to both TLS and Datagram
+   Transport Layer Security (DTLS).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7443.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.                 Informational                     [Page 1]
+
+RFC 7443                   ALPN for STUN/TURN               January 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
+   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
+     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
+     4.2.  Informative References  . . . . . . . . . . . . . . . . .   4
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5
+
+1.  Introduction
+
+   STUN can be securely transported using TLS-over-TCP (referred to as
+   TLS [RFC5246]), as specified in [RFC5389], or TLS-over-UDP (referred
+   to as DTLS [RFC6347]), as specified in [RFC7350].
+
+   ALPN [RFC7301] enables an endpoint to positively identify an
+   application protocol in TLS/DTLS and distinguish it from other TLS/
+   DTLS protocols.  With ALPN, the client sends the list of supported
+   application protocols as part of the TLS/DTLS ClientHello message.
+   The server chooses a protocol and sends the selected protocol as part
+   of the TLS/DTLS ServerHello message.  Application protocol
+   negotiation can thus be accomplished within the TLS/DTLS handshake,
+   without adding network round-trips.
+
+   STUN protocol usages, such as TURN [RFC5766], can be used to identify
+   the purpose of a flow without initiating a session.
+
+   This document proposes the following ALPN labels to identify STUN
+   protocol [RFC5389] usages.
+
+
+
+
+
+Patil, et al.                 Informational                     [Page 2]
+
+RFC 7443                   ALPN for STUN/TURN               January 2015
+
+
+   'stun.turn':  Label to identify the specific use of STUN over (D)TLS
+      for TURN (Section 4.6 of [RFC7350]).
+
+   'stun.nat-discovery':  Label to identify the specific use of STUN
+      over (D)TLS for NAT discovery (Section 4.1 of [RFC7350]).
+
+2.  IANA Considerations
+
+   The following entries have been added to the "Application-Layer
+   Protocol Negotiation (ALPN) Protocol IDs" registry established by
+   [RFC7301].
+
+   The "stun.turn" label identifies the use of TURN usage (D)TLS:
+
+      Protocol: Traversal Using Relays around NAT (TURN)
+
+      Identification Sequence: 0x73 0x74 0x75 0x6E 0x2E 0x74 0x75 0x72
+      0x6E ("stun.turn")
+
+      Specification: This document (RFC 7443)
+
+   The "stun.nat-discovery" label identifies the use of STUN for the
+   purposes of NAT discovery over (D)TLS:
+
+      Protocol: NAT discovery using Session Traversal Utilities for NAT
+      (STUN)
+
+      Identification Sequence: 0x73 0x74 0x75 0x6E 0x2E 0x6e 0x61 0x74
+      0x2d 0x64 0x69 0x73 0x63 0x6f 0x76 0x65 0x72 0x79
+      ("stun.nat-discovery")
+
+      Specification: This document (RFC 7443)
+
+3.  Security Considerations
+
+   The ALPN STUN protocol identifier does not introduce any specific
+   security considerations beyond those detailed in the TLS ALPN
+   Extension specification [RFC7301].  It also does not impact the
+   security of TLS/DTLS session establishment or application data
+   exchange.
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.                 Informational                     [Page 3]
+
+RFC 7443                   ALPN for STUN/TURN               January 2015
+
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              October 2008, <http://www.rfc-editor.org/info/rfc5389>.
+
+   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+              Security Version 1.2", RFC 6347, January 2012,
+              <http://www.rfc-editor.org/info/rfc6347>.
+
+   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
+              "Transport Layer Security (TLS) Application-Layer Protocol
+              Negotiation Extension", RFC 7301, July 2014,
+              <http://www.rfc-editor.org/info/rfc7301>.
+
+   [RFC7350]  Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
+              Layer Security (DTLS) as Transport for Session Traversal
+              Utilities for NAT (STUN)", RFC 7350, August 2014,
+              <http://www.rfc-editor.org/info/rfc7350>.
+
+4.2.  Informative References
+
+   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+              Relays around NAT (TURN): Relay Extensions to Session
+              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010,
+              <http://www.rfc-editor.org/info/rfc5766>.
+
+Acknowledgements
+
+   This work benefited from the discussions and invaluable input by the
+   various members of the TRAM working group.  These include Simon
+   Perrault, Paul Kyzivat, Brandon Williams, and Andrew Hutton.  Special
+   thanks to Martin Thomson and Oleg Moskalenko for their constructive
+   comments, suggestions, and early reviews that were critical to the
+   formulation and refinement of this document.
+
+   Barry Leiba, Stephen Farrell, Adrian Farrel, and Richard Barnes
+   provided useful feedback during IESG review.  Thanks to Russ Housley
+   for his Gen-ART review and Adam Langley for his IETF LC review
+   comments as TLS expert.
+
+
+
+
+
+Patil, et al.                 Informational                     [Page 4]
+
+RFC 7443                   ALPN for STUN/TURN               January 2015
+
+
+   The authors would also like to express their gratitude to the TRAM WG
+   chairs Gonzalo Camarillo and especially Simon Perrault, who also
+   acted as document shepherd.  Lastly, we also want to thank the
+   Transport Area Director Spencer Dawkins for his support and careful
+   reviews.
+
+Authors' Addresses
+
+   Prashanth Patil
+   Cisco Systems, Inc.
+   Bangalore
+   India
+
+   EMail: praspati@cisco.com
+
+
+   Tirumaleswar Reddy
+   Cisco Systems, Inc.
+   Cessna Business Park, Varthur Hobli
+   Sarjapur Marathalli Outer Ring Road
+   Bangalore, Karnataka  560103
+   India
+
+   EMail: tireddy@cisco.com
+
+
+   Gonzalo Salgueiro
+   Cisco Systems, Inc.
+   7200-12 Kit Creek Road
+   Research Triangle Park, NC  27709
+   United States
+
+   EMail: gsalguei@cisco.com
+
+
+   Marc Petit-Huguenin
+   Impedance Mismatch
+   United States
+
+   EMail: marc@petit-huguenin.org
+
+
+
+
+
+
+
+
+
+
+
+Patil, et al.                 Informational                     [Page 5]
+