A TCP Authentication Option Extension for NAT Traversal
Author(s): Joseph Touch
This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but does...
TCPM WG J. Touch Internet Draft USC/ISI Intended status: Experimental May 23, 2013 Expires: November 2013 A TCP Authentication Option Extension for NAT Traversal draft-touch-tcp-ao-nat-05.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 November 23, 2013. 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. 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. Touch Expires November 23, 2013 [Page 1] Internet-Draft TCP-AO NAT Extension May 2013 Abstract This document describes an extension to the TCP Authentication Option (TCP-AO) to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This extension changes the data used to compute traffic keys, but does not alter TCP-AO's packet processing or key generation algorithms. 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. IANA Considerations............................................5 8. References.....................................................5 8.1. Normative References......................................5 8.2. Informative References....................................6 9. 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 and/or port translators (NAT/NAPT) [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 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 RFC2119 [RFC2119]. Touch Expires November 23, 2013 [Page 2] Internet-Draft TCP-AO NAT Extension May 2013 When used in lower case, these words have their conventional meaning and do not convey the interpretations in RFC2119. 3. Background TCP-AO generates traffic keys that are specific to a socket pair [RFC5925]. Using the TCP-AO convention (local = source for outgoing segments, destination for incoming segments), the following information is used to create a connection's traffic keys: 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 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 Touch Expires November 23, 2013 [Page 3] Internet-Draft TCP-AO NAT Extension May 2013 includes the TCP connection identifier, the TCP option flag (indicating whether TCP options other than TCP-AO are included in the 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. I.e., these would 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. Touch Expires November 23, 2013 [Page 4] Internet-Draft TCP-AO NAT Extension May 2013 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. 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 with 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 of 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 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 the IPv4 addresses and ports is not expected to have a significant impact. 7. IANA Considerations There are no IANA considerations for this document. This section can be removed upon publication as an RFC. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option", RFC5925, Jun. 2010. Touch Expires November 23, 2013 [Page 5] Internet-Draft TCP-AO NAT Extension May 2013 8.2. Informative References [RFC6824] Ford, A., C. Raiciu, M. Handley, O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC6824, Jan. 2013. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC5389, Oct. 2008. [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC5926, June 2010. [RFC6056] Larsen, M., F. Gont, "Port Randomization," RFC6056, Jan. 2011. 9. Acknowledgments This extension was inspired by discussions with Dan Wing. This document was 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: email@example.com Touch Expires November 23, 2013 [Page 6]