idnits 2.17.1 draft-sivakumar-behave-edm-harmful-00.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 (March 5, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2663' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 223, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behave S. Sivakumar 3 Internet-Draft Cisco Systems 4 Intended status: Informational March 5, 2012 5 Expires: September 6, 2012 7 Issues with End-point dependent mapping 8 draft-sivakumar-behave-edm-harmful-00 10 Abstract 12 Some NAT devices implement the End-point dependent mapping and 13 filtering behavior. This document describes the issues that would 14 arise with End-point dependent mapping and filtering behavior. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2012. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 53 3. Why is End-point dependent mapping and filtering used . . . . . 4 54 4. Peer to Peer applications . . . . . . . . . . . . . . . . . . . 5 55 5. Issues with End-point dependent mapping and filtering . . . . . 5 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Terminology 66 The usage of the term "NAT device" in this document refer to any 67 NAT44 and NAT64 devices. 69 Address dependent end-point mapping - A NAT device creates a mapping 70 taking into account the destination address and port. The same 71 mapping is reused if a packet from the same source address, source 72 port destined to the same destination address. 74 Address and port dependent end-point mapping - A NAT device creates a 75 mapping taking into account the destination address and port. The 76 same mapping is reused if a packet from the same source address, 77 source port destined to the same destination address and destination 78 port. 80 End-point dependent mapping - A NAT device that does either Address 81 dependent mapping and/or Address and port dependent mapping is 82 referred to follow End-point dependent mapping. 84 Address dependent end-point filtering - A NAT device that allows 85 inbound traffic to the internal hosts only if the internal host had 86 previously communicated to the external address. 88 Address and port dependent end-point filtering - A NAT device that 89 allow inbound traffic to the internal hosts only if the internal host 90 had previously communicated to the same external address and port. 92 End-point dependent filtering - A NAT device that filters the 93 incoming traffic based on the external hosts' source address and/or 94 port. 96 2. Introduction 98 End-point dependent mapping and filtering is still prevalent in many 99 NAT devices. Even though [RFC4787] and [RFC5382] recommends against 100 using end point dependent mapping and filtering, these two RFCs does 101 not go into the details of why it is end point dependent mapping is 102 bad for applications. This document focuses on the negative impacts 103 of End point dependent mapping and filtering on applications. 105 2.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Why is End-point dependent mapping and filtering used 113 There are two main reasons that End-point dependent mapping and 114 filtering is used. a. End-point independent mapping can be used to 115 extend the number of ports available per global address, often 116 referred to as port overloading. For example, if there are two hosts 117 behind the same NAT device 119 +---------+ X1,x1 P,p +---------+ 120 | X1 |---------+ +---------| Y1 | 121 +---------+ | +--------+ | +---------+ 122 |---| NAT |---| 123 +---------+ | +--------+ | P,p +---------+ 124 | X2 |---------+ +---------| Y2 | 125 +---------+ X2, x2 +---------+ 127 Figure 1 129 Host X1 (X1, x1) initiating communication to destination (Y1, y1) and 130 host X2 (Y1, y1) initiating communication to destination (Y2, y2). 132 NAT device will translate the source address and port (X1, x1) to 133 public address (P, p) and it will translate the source address and 134 port (X2, x2) also to public address and port (P, p), as long as both 135 the hosts are not destined to the same end point. In order to 136 correctly demultiplex the return packets, the NAT device will store 137 the destination information. So, when the return packet from (Y1, 138 y1) to (P, p) is seen the NAT device can translate the destination to 139 (X1, x1). Similarly, when the return packet from (Y2, y2) destined 140 to (P, p) is seen, the destination will be translated to (X2, x2). 141 As can be seen with this example, the same external port p can be 142 used for multiple flows thus by maximizing the use of a single 143 external IPv4 address. 145 This kind of implementation also gives a perception that the NAT 146 device is actually doing end-point dependent filtering. 148 The End-point dependent filtering is perceived to offer security. 149 Since the outbound packet was sent to the external address, it is 150 assumed that is a trusted entry. Hence the return packets from the 151 same external address is assumed to be trusted and doing filtering 152 based on the external address and port is perceived to offer 153 security. 155 Secondly, most of the client server based applications with End-point 156 dependent filtering will work fine. This leads one to believe that 157 End-point dependent filtering will work for all other applications as 158 well. 160 4. Peer to Peer applications 162 Peer to Peer (P2P) applications use a variety of techniques to 163 traverse NATs like using Relay servers, TCP/UDP hole punching etc as 164 described in [RFC5128]. For P2P applications to work reliably across 165 NATs it is expected that the NAT devices does End-point independent 166 mapping and filtering. 168 Peer to Peer applications are becoming very common and some real life 169 examples of P2P applications are SIP used by VoIP service providers, 170 instant messaging, voice and video chat, Google Talk, Apple Facetime 171 and several famous gaming applications. The notion of not supporting 172 P2P applications is not just practical and NATs MUST be designed to 173 facilitate these applications. 175 While it is tempting to maximize the return on the investment by 176 maximizing the use of the existing IPv4 addresses, doing End point 177 dependent mapping, the harmful effects of this overrides any benefits 178 that it offers. 180 5. Issues with End-point dependent mapping and filtering 182 1. End point dependent mapping does not guarantee that the same 183 External address and port will be used regardless of the destination. 184 This would prevent the inbound connection from an application. 186 2. End point dependent filtering will allow inbound connections only 187 if a previous flow to the same host was previously initiated from an 188 internal host. This will prevent incoming connection requests from 189 an application. 191 6. Acknowledgements 193 Thanks to Dan Wing for providing the idea to write this document and 194 reviewing it. 196 7. IANA Considerations 198 None 200 8. Security Considerations 202 None. 204 9. References 206 9.1. Normative References 208 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 212 Translator (NAT) Terminology and Considerations", 213 RFC 2663, August 1999. 215 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 216 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 217 RFC 4787, January 2007. 219 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 220 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 221 RFC 5382, October 2008. 223 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 224 NAT64: Network Address and Protocol Translation from IPv6 225 Clients to IPv4 Servers", RFC 6146, April 2011. 227 9.2. Informative References 229 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 230 Peer (P2P) Communication across Network Address 231 Translators (NATs)", RFC 5128, March 2008. 233 Author's Address 235 Senthil Sivakumar 236 Cisco Systems 237 7100-8 Kit Creek Road 238 Research Triangle Park, North Carolina 27709 239 USA 241 Phone: +1 919 392 5158 242 Email: ssenthil@cisco.com