summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6978.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6978.txt')
-rw-r--r--doc/rfc/rfc6978.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6978.txt b/doc/rfc/rfc6978.txt
new file mode 100644
index 0000000..cc79807
--- /dev/null
+++ b/doc/rfc/rfc6978.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Independent Submission J. Touch
+Request for Comments: 6978 USC/ISI
+Category: Experimental July 2013
+ISSN: 2070-1721
+
+
+ A TCP Authentication Option Extension for NAT Traversal
+
+Abstract
+
+ This document describes an extension to the TCP Authentication Option
+ (TCP-AO) to support its use over connections that pass through
+ Network Address Translators and/or Network Address and Port
+ Translators (NATs/NAPTs). This extension changes the data used to
+ compute traffic keys, but it does not alter TCP-AO's packet
+ processing or key generation algorithms.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This is a contribution to the RFC Series, independently
+ of any other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not 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/rfc6978.
+
+Copyright Notice
+
+ Copyright (c) 2013 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.
+
+
+
+
+
+Touch Experimental [Page 1]
+
+RFC 6978 TCP-AO NAT Extension July 2013
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions Used in This Document ...............................2
+ 3. Background ......................................................3
+ 4. Extension to Allow NAT Traversal ................................3
+ 5. Intended Use ....................................................4
+ 6. Security Considerations .........................................5
+ 7. References ......................................................5
+ 7.1. Normative References .......................................5
+ 7.2. Informative References .....................................5
+ 8. Acknowledgments .................................................6
+
+1. Introduction
+
+ This document describes an extension to the TCP Authentication Option
+ (TCP-AO) [RFC5925] called TCP-AO-NAT to support its use in the
+ presence of Network Address Translators and/or Network Address and
+ Port Translators (NATs/NAPTs) [RFC2663]. These devices translate the
+ source address and/or the source port number of a TCP connection.
+ TCP-AO without TCP-AO-NAT extensions would be sensitive to these
+ modifications and would discard authenticated segments.
+
+ At least one potential application of TCP-AO-NAT is to support the
+ experimental multipath TCP protocol [RFC6824], which uses multiple IP
+ addresses to support a single TCP transfer.
+
+ This document assumes detailed familiarity with TCP-AO [RFC5925]. As
+ a preview, this document focuses on how TCP-AO generates traffic
+ keys, and it does not otherwise alter the TCP-AO mechanism or that of
+ its key generation [RFC5926].
+
+2. Conventions Used in This Document
+
+ 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].
+ When used in lower case, these words have their conventional meaning
+ and do not convey the interpretations in RFC 2119.
+
+
+
+
+
+
+
+
+
+
+
+
+Touch Experimental [Page 2]
+
+RFC 6978 TCP-AO NAT Extension July 2013
+
+
+3. Background
+
+ TCP-AO generates traffic keys that are specific to a socket pair
+ [RFC5925]. The following information is used to create a
+ connection's traffic keys. (Note that 'local' and 'remote' are
+ interpreted as in TCP-AO [RFC5925].)
+
+ o IP local address
+
+ o IP remote address
+
+ o TCP local port
+
+ o TCP remote port
+
+ o TCP local Initial Sequence Number (ISN)
+
+ o TCP remote Initial Sequence Number (ISN)
+
+ Of these fields, the remote ISN is not known for SYN segments and is
+ excluded from the traffic key used to authenticate them. Otherwise,
+ all fields are used in the traffic keys of all other segments.
+
+ NATs and NAPTs (both referred to herein as "NATs", even if port
+ translation is included) would interfere with these uses, because
+ they alter the IP address and TCP port of the endpoint behind the NAT
+ [RFC2663].
+
+4. Extension to Allow NAT Traversal
+
+ The premise of TCP-AO-NAT is that it might be useful to allow TCP-AO
+ use in the presence of NATs, e.g., to protect client/server
+ communication where clients are behind NATs.
+
+ This document describes TCP-AO-NAT, an extension to TCP-AO that
+ enables its use in the presence of NATs. This extension requires no
+ modification to the TCP-AO header or packet processing, and it
+ requires no modification to the algorithms used to generate traffic
+ keys [RFC5926]. The change is limited to the data used to generate
+ traffic keys only.
+
+ In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties
+ to be associated with one or more connections" [RFC5925]. This
+ includes the TCP connection identifier, the TCP option flag
+ (indicating whether TCP options other than TCP-AO are included in the
+
+
+
+
+
+
+Touch Experimental [Page 3]
+
+RFC 6978 TCP-AO NAT Extension July 2013
+
+
+ Message Authentication Code (MAC) calculation), keying information,
+ and other parameters. TCP-AO-NAT augments the MKT with two
+ additional flags:
+
+ o localNAT
+
+ o remoteNAT
+
+ TCP-AO implementations supporting TCP-AO-NAT MUST support both
+ localNAT and remoteNAT flags.
+
+ These flags indicate whether a segment's local or remote
+ (respectively) IP address and TCP port are zeroed before MAC
+ calculation, either for creating the MAC to insert (for outgoing
+ segments) or for calculating a MAC to validate against the value in
+ the option. These flags modify TCP-AO processing rules as follows:
+
+ o In TCP-AO-NAT, traffic keys are computed by zeroing the
+ local/remote IP address and TCP port as indicated by the localNAT
+ or remoteNAT flags.
+
+ o In TCP-AO-NAT, MAC values are computed by zeroing the local/remote
+ IP address and TCP port as indicated by the localNAT or remoteNAT
+ flags.
+
+ The use of these flags needs to match on both ends of the connection,
+ just as with all other MKT parameters.
+
+5. Intended Use
+
+ A host MAY use TCP-AO-NAT when it is behind a NAT, as determined
+ using NAT discovery techniques, or when TCP-AO protection is desired
+ but conventional TCP-AO fails to establish connections.
+
+ A client behind a NAT MAY set localNAT=TRUE for MKTs supporting
+ TCP-AO-NAT for outgoing connections. A server MAY set remoteNAT=TRUE
+ for MKTs supporting TCP-AO-NAT for incoming connections. Peer-to-
+ peer applications with dual NAT support, e.g., those traversing
+ so-called 'symmetric NATs' [RFC5389], MAY set both localNAT=TRUE and
+ remoteNAT=TRUE for MKTs supporting TCP-AO-NAT bidirectionally. Once
+ these flags are set in an MKT, they affect all connections that match
+ that MKT.
+
+ TCP-AO-NAT is intended for use only where coordinated between
+ endpoints for connections that match the shared MKT parameters, as
+ with all other MKT parameters.
+
+
+
+
+
+Touch Experimental [Page 4]
+
+RFC 6978 TCP-AO NAT Extension July 2013
+
+
+ Note that TCP-AO-NAT is not intended for use with services transiting
+ Application Layer Gateways (ALGs), i.e., NATs that also translate
+ in-band addresses, such as used in FTP or SIP. TCP-AO-NAT protects
+ the contents of the TCP segments from modification and would
+ (correctly) interpret such alterations as an attack on those
+ contents.
+
+6. Security Considerations
+
+ TCP-AO-NAT does not affect the security of connections that do not
+ set either the localNAT or remoteNAT flags. Such connections are not
+ affected themselves and are not affected by segments in other
+ connections that set those flags.
+
+ Setting either the localNAT or remoteNAT flags reduces the randomness
+ of the input to the Key Derivation Function (KDF) used to generate
+ the traffic keys. The largest impact occurs when using IPv4, which
+ reduces the randomness from 2 IPv4 addresses, 2 ISNs, and both ports
+ down to just the two ISNs when both flags are set. The amount of
+ randomness in the IPv4 addresses and service port is likely to be
+ small, and the randomness of the dynamic port is under debate and
+ should not be considered substantial [RFC6056]. The KDF input
+ randomness is thus expected to be dominated by that of the ISNs, so
+ reducing it by either or both of the IPv4 addresses and ports is not
+ expected to have a significant impact.
+
+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.
+
+ [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
+ Authentication Option", RFC 5925, June 2010.
+
+7.2. Informative References
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations",
+ RFC 2663, August 1999.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ October 2008.
+
+
+
+
+
+
+Touch Experimental [Page 5]
+
+RFC 6978 TCP-AO NAT Extension July 2013
+
+
+ [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
+ for the TCP Authentication Option (TCP-AO)", RFC 5926,
+ June 2010.
+
+ [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
+ Protocol Port Randomization", BCP 156, RFC 6056,
+ January 2011.
+
+ [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
+ "TCP Extensions for Multipath Operation with Multiple
+ Addresses", RFC 6824, January 2013.
+
+8. Acknowledgments
+
+ This extension was inspired by discussions with Dan Wing.
+
+ This document was initially prepared using 2-Word-v2.0.template.dot.
+
+Author's Address
+
+ Joe Touch
+ USC/ISI
+ 4676 Admiralty Way
+ Marina del Rey, CA 90292
+ USA
+
+ Phone: +1 (310) 448-9151
+ EMail: touch@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Touch Experimental [Page 6]
+