idnits 2.17.1 draft-touch-tcp-ao-nat-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 23, 2013) is 3991 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TCPM WG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Experimental May 23, 2013 4 Expires: November 2013 6 A TCP Authentication Option Extension for NAT Traversal 7 draft-touch-tcp-ao-nat-05.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on November 23, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document describes an extension to the TCP Authentication 50 Option (TCP-AO) to support its use over connections that pass 51 through network address and/or port translators (NATs/NAPTs). This 52 extension changes the data used to compute traffic keys, but does 53 not alter TCP-AO's packet processing or key generation algorithms. 55 Table of Contents 57 1. Introduction...................................................2 58 2. Conventions used in this document..............................2 59 3. Background.....................................................3 60 4. Extension to Allow NAT Traversal...............................3 61 5. Intended Use...................................................4 62 6. Security Considerations........................................5 63 7. IANA Considerations............................................5 64 8. References.....................................................5 65 8.1. Normative References......................................5 66 8.2. Informative References....................................6 67 9. Acknowledgments................................................6 69 1. Introduction 71 This document describes an extension to the TCP Authentication 72 Option (TCP-AO) [RFC5925] called TCP-AO-NAT to support its use in 73 the presence of network address and/or port translators (NAT/NAPT) 74 [RFC2663]. These devices translate the source address and/or the 75 source port number of a TCP connection. TCP-AO without TCP-AO-NAT 76 extensions would be sensitive to these modifications, and would 77 discard authenticated segments. 79 At least one potential application of TCP-AO-NAT is to support the 80 experimental multipath TCP protocol [RFC6824], which uses multiple 81 IP addresses to support a single TCP transfer. 83 This document assumes detailed familiarity with TCP-AO [RFC5925]. As 84 a preview, this document focuses on how TCP-AO generates traffic 85 keys, and does not otherwise alter the TCP-AO mechanism or that of 86 its key generation [RFC5926]. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC-2119 [RFC2119]. 94 When used in lower case, these words have their conventional meaning 95 and do not convey the interpretations in RFC-2119. 97 3. Background 99 TCP-AO generates traffic keys that are specific to a socket pair 100 [RFC5925]. Using the TCP-AO convention (local = source for outgoing 101 segments, destination for incoming segments), the following 102 information is used to create a connection's traffic keys: 104 o IP local address 106 o IP remote address 108 o TCP local port 110 o TCP remote port 112 o TCP local Initial Sequence Number (ISN) 114 o TCP remote Initial Sequence Number (ISN) 116 Of these fields, the remote ISN is not known for SYN segments, and 117 is excluded from the traffic key used to authenticate them. 118 Otherwise, all fields are used in the traffic keys of all other 119 segments. 121 NATs and NAPTs (both referred to herein as "NATs", even if port 122 translation is included) would interfere with these uses, because 123 they alter the IP address and TCP port of the endpoint behind the 124 NAT [RFC2663]. 126 4. Extension to Allow NAT Traversal 128 The premise of TCP-AO-NAT is that it might be useful to allow TCP-AO 129 use in the presence of NATs, e.g., to protect client/server 130 communication where clients are behind NATs. 132 This document describes TCP-AO-NAT, an extension to TCP-AO that 133 enables its use in the presence of NATs. This extension requires no 134 modification to the TCP-AO header or packet processing, and requires 135 no modification to the algorithms used to generate traffic keys 136 [RFC5926]. The change is limited to the data used to generate 137 traffic keys only. 139 In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties 140 to be associated with one or more connections" [RFC5925]. This 141 includes the TCP connection identifier, the TCP option flag 142 (indicating whether TCP options other than TCP-AO are included in 143 the MAC calculation), keying information, and other parameters. TCP- 144 AO-NAT augments the MKT with two additional flags: 146 o localNAT 148 o remoteNAT 150 TCP-AO implementations supporting TCP-AO-NAT MUST support both 151 localNAT and remoteNAT flags. 153 These flags indicate whether a segment's local or remote 154 (respectively) IP address and TCP port are zeroed before MAC 155 calculation, either for creating the MAC to insert (for outgoing 156 segments) or for calculating a MAC to validate against the value in 157 the option. I.e., these would modify TCP-AO processing rules as 158 follows: 160 o In TCP-AO-NAT, traffic keys are computed by zeroing the 161 local/remote IP address and TCP port as indicated by the localNAT 162 or remoteNAT flags. 164 o In TCP-AO-NAT, MAC values are computed by zeroing the 165 local/remote IP address and TCP port as indicated by the localNAT 166 or remoteNAT flags. 168 The use of these flags needs to match on both ends of the 169 connection, just as with all other MKT parameters. 171 5. Intended Use 173 A host MAY use TCP-AO-NAT when it is behind a NAT, as determined 174 using NAT discovery techniques, or when TCP-AO protection is desired 175 but conventional TCP-AO fails to establish connections. 177 A client behind a NAT MAY set localNAT=TRUE for MKTs supporting TCP- 178 AO-NAT for outgoing connections. A server MAY set remoteNAT=TRUE for 179 MKTs supporting TCP-AO-NAT for incoming connections. Peer-to-peer 180 applications with dual NAT support, e.g., those traversing so-called 181 'symmetric NATs' [RFC5389], MAY set both localNAT=TRUE and 182 remoteNAT=TRUE for MKTs supporting TCP-AO-NAT bidirectionally. Once 183 these flags are set in an MKT, they affect all connections that 184 match that MKT. 186 TCP-AO-NAT is intended for use only where coordinated between 187 endpoints for connections that match the shared MKT parameters, as 188 with all other MKT parameters. 190 Note that TCP-AO-NAT is not intended for use with services 191 transiting application layer gateways (ALGs), i.e., NATs that also 192 translate in-band addresses, such as used in FTP or SIP. TCP-AO-NAT 193 protects the contents of the TCP segments from modification, and 194 would (correctly) interpret with such alterations as an attack on 195 those contents. 197 6. Security Considerations 199 TCP-AO-NAT does not affect the security of connections that do not 200 set either of the localNAT or remoteNAT flags. Such connections are 201 not affected themselves, and are not affected by segments in other 202 connections that set those flags. 204 Setting either the localNAT or remoteNAT flags reduces the 205 randomness of the input to the KDF used to generate the traffic 206 keys. The largest impact occurs when using IPv4, which reduces the 207 randomness from 2 IPv4 addresses, 2 ISNs, and both ports down to 208 just the two ISNs when both flags are set. The amount of randomness 209 in the IPv4 addresses and service port is likely to be small, and 210 the randomness of the dynamic port is under debate and should not be 211 considered substantial [RFC6056]. The KDF input randomness is thus 212 expected to be dominated by that of the ISNs, so reducing it by 213 either or both the IPv4 addresses and ports is not expected to have 214 a significant impact. 216 7. IANA Considerations 218 There are no IANA considerations for this document. This section can 219 be removed upon publication as an RFC. 221 8. References 223 8.1. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 229 Option", RFC 5925, Jun. 2010. 231 8.2. Informative References 233 [RFC6824] Ford, A., C. Raiciu, M. Handley, O. Bonaventure, "TCP 234 Extensions for Multipath Operation with Multiple 235 Addresses", RFC 6824, Jan. 2013. 237 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 238 Translator (NAT) Terminology and Considerations", RFC 239 2663, August 1999. 241 [RFC5389] Rosenberg, J., R. Mahy, P. Matthews, D. Wing, "Session 242 Traversal Utilities for NAT (STUN)", RFC 5389, Oct. 2008. 244 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 245 for the TCP Authentication Option (TCP-AO)", RFC 5926, 246 June 2010. 248 [RFC6056] Larsen, M., F. Gont, "Port Randomization," RFC 6056, Jan. 249 2011. 251 9. Acknowledgments 253 This extension was inspired by discussions with Dan Wing. 255 This document was prepared using 2-Word-v2.0.template.dot. 257 Author's Address 259 Joe Touch 260 USC/ISI 261 4676 Admiralty Way 262 Marina del Rey, CA 90292 263 USA 265 Phone: +1 (310) 448-9151 266 Email: touch@isi.edu