TCPM WG J. Touch Internet Draft USC/ISI Intended status: Proposed Standard October 19, 2009 Expires: April 2010 A TCP Authentication Option NAT Extension draft-touch-tcp-ao-nat-00.txt Status of this Memo This Internet-Draft is submitted to IETF 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 April 19, 2010. Copyright Notice Copyright (c) 2009 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 BSD License. Touch Expires April 19, 2010 [Page 1] Internet-Draft TCP-AO NAT Extension October 2009 Abstract This document describes an extension to the TCP Authentication Option to support its use over connections that pass through network address and/or port translators (NATs/NAPTs). This document describes this extension, and is intended that if desired, would be incorporated into the TCP-AO description currently under development. This document is not intended to remain stand-alone. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................2 3. Background.....................................................3 4. Extension to Allow NAT Use.....................................3 5. Intended Use...................................................4 6. Security Considerations........................................4 7. IANA Considerations............................................4 8. References.....................................................5 8.1. Normative References......................................5 8.2. Informative References....................................5 9. Acknowledgments................................................5 1. Introduction This document assumes detailed familiarity with TCP-AO [ID-TCP-AO]. It is intended as an extension to TCP-AO, and is described separately to allow its separate consideration. If approved, it is expected that this document would be integrated with TCP-AO. As a result, no background is included herein. TCP-AO can be extended to support use through NAT/NAPT devices [RFC2663]. These devices translate the source address and/or the source port number of a TCP connection. TCP-AO without these extensions would be sensitive to these modifications, and would discard authenticated segments. 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 Expires April 19, 2010 [Page 2] Internet-Draft TCP-AO NAT Extension October 2009 3. Background TCP-AO generates traffic keys that are specific to a socket pair [ID-TCP-AO]. 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 when for SYN segments, and is excluded from the traffic key used to authentication them. Otherwise, all fields are used in the traffic keys of all other segments. NATs and NAPTs (here just "NATs", even if port translation is included) would interfere with these uses, because they alter the local IP address and local TCP port [RFC2663]. 4. Extension to Allow NAT Use 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. We propose an extension to TCP-AO that enables its use in the presence of NATs. This extension requires no modification to the TCP-AO header. The change is limited to the way in which traffic keys are generated. We call this TCP-AO-NAT. For TCP-AO-NAT, there are two additional flags for each TCP connection. These flags, which could be copied from parameters of the MKT or set on a per-connection basis, are: o localNAT o remoteNAT Touch Expires April 19, 2010 [Page 3] Internet-Draft TCP-AO NAT Extension October 2009 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 the processing rules as follows: o Traffic keys are computed by zeroing the local/remote IP address and TCP port as indicated by the localNAT and remoteNAT flags. o MAC values are computed by zeroing the local/remote IP address and TCP port as indicated by the localNAT and remoteNAT flags. 5. Intended Use A client behind a NAT, or that suspects being behind a NAT, would set localNAT=TRUE. A server willing to support incoming TCP-AO-NAT connections would set remoteNAT=TRUE. Peer-to-peer applications with dual NAT support, e.g., those traversing symmetric NATs, would set both localNAT=TRUE and remoteNAT=TRUE [RFC5389]. 6. Security Considerations TCP-AO-NAT does not affect the security of connections that set neither 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 entropy of the input to the KDF used to generate the traffic keys. The largest impact occurs when using IPv4, which reduces the entropy from approximately 142 bits (2 IP addresses, 2 ISNs, and one dynamic port) down to 96 bits (1 IP address, 2 ISNs, and the dynamic port) when only one flag is used, or down to 64 bits (the 2 ISNs only) when both are used, with even less entropy for a SYN segment (reduced by 32 bits). We TCP-AO-NAT SHOULD NOT be used with both flags set in IPv4 as a result. 7. IANA Considerations There are no IANA considerations for this document. This section can be removed upon publication as an RFC. Touch Expires April 19, 2010 [Page 4] Internet-Draft TCP-AO NAT Extension October 2009 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ID-TCP-AO] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication Option",draft-ietf-tcpm-tcp-auth-opt-05.txt, July 2009. 8.2. Informative References [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)", RFC 5389, Oct. 2008. 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: touch@isi.edu Touch Expires April 19, 2010 [Page 5]