idnits 2.17.1 draft-tsirtsis-nat-bypass-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 344 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 100 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '... Drafts are ...' == Line 11 has weird spacing: '...cuments of t...' == Line 12 has weird spacing: '... groups may ...' == Line 16 has weird spacing: '... Drafts may ...' == Line 17 has weird spacing: '...iate to use ...' == (95 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 1998) is 9598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'NAT' is defined on line 257, but no explicit reference was found in the text == Unused Reference: 'L2TP' is defined on line 261, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'NAT' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TP' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPHC' -- Possible downref: Non-RFC (?) normative reference: ref. 'ROUT' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT George Tsirtsis, BTLABS 2 Alan O'Neill, BTLABS 3 January 1998 5 NAT Bypass for End 2 End 'sensitive' applications 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts). 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a "working 19 draft" or "work in progress." 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 Abstract 27 This document attempts to generate discussion on methods to run end 28 2 end 'sensitive' protocols and capabilities, like IPSEC, on networks 29 that use Network Address Translators (NAT). The proposal does so by 30 outlining one method to bypass NAT, when the required capabilities 31 cannot be supported by NAT. The method uses a tunnel between a local 32 host and the NAT box in order to dynamically allocate addresses to 33 those hosts that need to communicate with external networks. With an 34 allocated external address, the local hosts are able to communicate 35 with external hosts without breaking the end 2 end principle. This 36 proposal does not introduce any new protocols, it simply reuses 37 existing protocols to provide an example solution. 39 Terminology 41 Application 43 In this document the term application refers to anything that uses 44 the IP network protocol (IPSEC, FTP etc). 46 L2TP 48 In this document only the end 2 end flavour of L2TP is considered 49 (otherwise known as PPTP) were the Host and the L2TP Access 50 Concentrator (LAC) are both in the Host and only the connection 51 between LAC and L2TP Network Server (LNS) goes across the network. 53 Bypass the NAT 55 This means that the Address Translation function is bypassed, NOT the 56 NAT box, since the tunnel that bypasses the translation function, MAY 57 terminate at a Router combined with a NAT box. 59 1. Introduction and Motivation 61 Network Address Translation (NAT) is used today as an interim 62 solution to the problem of limited address space in IPv4. One can 63 design a network using private address space (not globally unique)and 64 use NAT in order to allow communication with external networks. The 65 NAT typically has only a small number of external addresses 66 available, resulting in savings in the IPv4 address space. 68 Unfortunately, address translation breaks one of the fundamental 69 principles of Internet; the End 2 End Principle [ROUT]. This 70 recommends that packets flow end to end, between hosts, without 71 anyone changing its contents along the path. A number of applications 72 have been designed with that principle in mind and any attempt to 73 change the contents of their packets results in failure of the 74 application. NAT does exactly that; for outgoing traffic it replaces 75 the source private address of a hosts with an externally routable 76 source address and replaces the corresponding private destination 77 address for return traffic. 79 This change of the address on transit works with a number of 80 applications wile others can be fixed, e.g: FTP, by using Application 81 Layer Gateways (ALG) to also translate appropriate fields in the 82 higher layers (e.g: TCP checksum) in order to 'hide' from the other 83 end the fact that something has changed in the packet. 85 In other applications, however, the use of ALGs is either too 86 inefficient, to be practicable (e.g: Mobile IP), or they bridge a 87 very important part of the application in question (e.g: in IPSEC you 88 have to trust the ALG/NAT - not always possible). 90 Note that the complete list of applications that break with NAT is a 91 current NAT WG item. 93 This proposal provides a way to allow hosts, in networks that use 94 NAT, to communicate with external hosts without breaking the end 2 95 end principle. In order to achieve the above functionality, a tunnel 96 has to be built between the host in the private network and the NAT. 97 The tunnel is then used to allocate an external address, out of the 98 pool of addresses available to the NAT, as well as to route the 99 packets outside the private network. 101 1.1. Assumptions 103 The NAT box MUST be able to handle tunnels on the interface attached 104 to the private network. This should not be very difficult since NAT 105 boxes are usually integrated with routers. 107 L2TP tunneling is assumed in this draft due to its extended 108 functionality, but other types of tunneling MAY also be used. 110 It would also be helpful if the host could establish the tunnel to 111 the NAT without human intervention. Alternatively, the tunnel MAY be 112 statically configured and ONLY used when an application is end 2 end 113 sensitive. 115 1.2. Applicability and Limitations 117 * This proposal does not solve problems that are inherent to NAT. In 118 fact it does not change anything in the NAT or any other protocol. It 119 merely bypasses NAT when the required functionality cannot be 120 supported by NAT. 122 * This proposal could be used by networks that use private address 123 space, with a small number of users that need to run applications 124 that break through NAT. Hosts that do not need, or are not allowed by 125 local policy, to run this kind of applications, can still use NAT in 126 the traditional way but SHOULD NOT be allowed to use the tunnel. 128 * The network designer who is going to use the described mechanism 129 needs to balance between the number of global addresses available, 130 the total number of hosts in the private network and the number of 131 users that are allowed to bypass the NAT at the same time. 133 * It is clear that when an address is allocated to a tunnel it can 134 not be overloaded by muxing the port numbers (NAPT function) 136 * With this proposal NAT becomes an overloaded box. Apart from 137 address translation, it is required to be able to handle tunnels, 138 address allocation and potentially PPP, radius etc. 140 * The use of L2TP, that carries PPP packets, allows for the use of 141 access related protocols like RADIUS, providing policy and 142 potentially an accounting mechanism. 144 * NAT with the functionality described in this proposal is not 145 transparent to the users that use the added functionality, since they 146 need to know where to terminate the tunnel. 148 * NAT becomes a single point of failure for users who access it 149 through tunnels. As far as the author understands, hot standbys may 150 be problematic since the tunnel configuration may be difficult to 151 transfer. 153 * The use of a tunnel creates an added overhead due to tunnel 154 headers. Header compression mechanisms for L2TP are currently 155 investigated in [L2TPHC] 157 2. Requirements 159 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 160 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 161 document, are to be interpreted as described in [KEYWORDS]. 163 3. Overview 165 Consider the private network in Figure 1 connected through NAT to the 166 global Internet. Hosts A and B can communicate with Host C using NAT 167 in order to translate their private addresses to global addresses, 168 which are valid in the Internet. 170 +---------+ 171 | Private | +------------+ 172 +-------+ | Network | +-----+ | | +-------+ 173 | HostA |=|=========|=| NAT |--| Internet |--| HostC | 174 +-------+ | L2TP /| +-----+ | | +-------+ 175 | / | +------------+ 176 +------+--+ 177 | 178 +-----+ 179 |HostB| 180 +-----+ 182 Figure 1: Tunneled connection through NAT. 184 Lets assume that one of the hosts, say Host A, wants to set-up an 185 IPSEC tunnel to Host C. In order to do that Host A needs a global 186 address that is valid end to end and is not going to be changed by 187 the NAT box. In order to do get a global address, Host A initiates an 188 L2TP tunnel between itself and the NAT. With normal L2TP operation, 189 virtual interfaces are set-up in both Host A and NAT, PPP parameters 190 are negotiated and an address, from the pool of global addresses 191 located in the NAT, is assigned to Host A. 193 At the end of this procedure Host A has an IP connection running over 194 the L2TP tunnel to the NAT, using an address valid to the global 195 Internet. From then on, Host A can initiate a number of applications 196 that normally would not run through the NAT, including IPSEC to Host 197 C. 199 All subsequent communication to Host C is transmitted through the 200 L2TP tunnel in both directions and the NAT acts as a normal router 201 without translation taking place. 203 The tunnel SHOULD be disconnected or at least deactivated after the 204 session is finished and the global address MUST be returned to the 205 NAT's pool of addresses. 207 4. Why Tunneling 209 The allocation of a globally unique address to a host in a private 210 network is an obvious solution to networks that use NAT. This, 211 however, creates an oxymoron in the sense that NAT is used in order 212 avoid providing global addresses to all hosts in a network. 214 One could argue that if a hosts has to run applications like IPSEC 215 frequently it might make sense to have a global address permanently 216 allocated to it. The problem is that this is a static solution which 217 means that even when this host does not uses its global address, the 218 address can not be used by others. Additionally, most applications 219 are associated with a user not a host, e.g: IPSEC is a user's 220 decision. 222 It can also be argued that DHCP could be used to temporary allocate a 223 global address. This is also problematic since the allocated address 224 is not routable in the private domain leading to scaling problems. 225 With Tunneling the routing problem is resolved, because the tunnel is 226 routed on the private address. 228 L2TP also has the added advantage that it is configured relatively 229 automatically and may carry PPP. The latter allows the NAT to 230 authenticate users that want to use the added functionality applying 231 local policy, since this is clearly an expensive function. 233 5. SECURITY CONSIDERATIONS 235 There are no security problems created by this proposal further to 236 these described in the protocols used. 238 6. OPEN ISSUES 240 The authors do not claim to be experts on either IPSEC nor L2TP and 241 as such, help is required to investigate and clarify the details of 242 this proposal. 244 A host that wants to use the functionality described needs to know 245 the address of the NAT. Can this be automated? 247 Is it possible for the tunnel to be initiated automatically when 248 IPSEC is to be used without human intervention? Remember that the 249 tunnel has to be set-up and an address to be allocated before the 250 host can initiate IPSEC. 252 REFERENCES 254 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 255 Requirement Levels", RFC 2119, March 1997. 257 [NAT] P. Srisuresh, et.al., The IP Network Address Translator (NAT), 258 ftp://ietf.org/internet-drafts/draft-rfced-info-srisuresh-03.txt, 259 September 1997 261 [L2TP] K. Hamzeh et.al., Layer Two Tunneling Protocol "L2TP", 262 ftp://ietf.org/internet-drafts/draft-ietf-pppext-l2tp-08.txt, November 263 1997 265 [L2TPHC], A.J. Valencia, L2TP Header Compression (``L2TPHC''), 266 ftp://ietf.org/internet-drafts/draft-ietf-pppext-l2tphc-01.txt, December 267 1997 269 [ROUT] C. Huitema, Routing In The Internet, 1995, Prentice Hall. 271 AUTHORS 273 George Tsirtsis 274 Internet Transport Group 275 B29 Room 129 276 BT Laboratoties 277 Martlesham Heath 278 IPSWICH 279 Suffolk IP5 3RE 280 England 282 Phone: +44 1473 640756 283 Fax: +44 1473 640709 284 e-mail: george@gideon.bt.co.uk 286 Alan O'Neill 287 Internet Transport Group 288 B29 Room 129 289 BT Laboratoties 290 Martlesham Heath 291 IPSWICH 292 Suffolk IP5 3RE 293 England 295 Phone: +44 1473 646459 296 Fax: +44 1473 640709 297 e-mail: alan.oneill@bt-sys.bt.co.uk 299 DISCLAIMER 301 Notice: This contribution has been prepared to assist the IETF as a 302 basis for discussion. It is not a binding proposal on British 303 telecommunications plc; specifically, British Telecommunications plc 304 reserves the right to modify, delete and amend any statements contain 305 herein.