idnits 2.17.1 draft-iab-unsaf-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 abstract seems to contain references ([P]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '...quired. Use of these workarounds MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 47 has weird spacing: '...termine or...' == Line 76 has weird spacing: '...termine or fi...' -- 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 (February 4, 2002) is 8118 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) No issues found here. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Daigle 3 Internet-Draft Editor 4 Expires: August 5, 2002 Internet Architecture Board 5 IAB 6 February 4, 2002 8 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) 9 draft-iab-unsaf-considerations-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 5, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 With current NA[P]T middleboxes, individual networks using different 41 address realms are bridged. However, as a side effect of address 42 translation, communicating endpoints on either side of the middlebox 43 do not know how to refer to themselves using addresses that are 44 applicable in the other realm -- the address translation is locked 45 within the middlebox. Various proposals have been made for 46 "UNilateral Self-Address Fixing (UNSAF)" processes. These are 47 processes whereby some originating process attempts to determine or 48 fix the address (and port) by which it is known to another process -- 49 e.g., to be able to use address data in the protocol exchange, or to 50 advertise a public address from which it will receive connections. 52 This document outlines the reasons for which these proposals can be 53 considered at best as short term fixes to specific problems, and the 54 specific issues to be carefully evaluated before creating an UNSAF 55 proposal. 57 1. Introduction 59 With current NA[P]T middleboxes, individual networks using different 60 address realms are bridged. However, as a side effect of address 61 translation, communicating endpoints on either side of the middlebox 62 do not know how to refer to themselves using addresses that are 63 applicable in the other realm -- the address translation is locked 64 within the middlebox. For some purposes, endpoints need to know the 65 addresses (and/or ports) by which they are known to their peers. 66 There are two cases. When the client initiates communication, 67 starting the communication has the side effect of creating an address 68 binding in the NA[P]T device and allocating an address in the realm 69 that is external to the NA[P]T box. In the second case, a server 70 will be accepting connections from outside, but because it does not 71 initiate communication, no NAT binding is created. In such cases, a 72 mechanism is needed to fix such a binding, before communication can 73 take place. 75 "UNilateral Self-Address Fixing (UNSAF)" is a process whereby some 76 originating process attempts to determine or fix the address (and 77 port) by which it is known -- e.g., to be able to use address data in 78 the protocol exchange, or to advertise a public address from which it 79 will receive connections. 81 There are only heuristics and workarounds to attempt to achieve this 82 effect; there is no 100% solution. Since NA[P]Ts may also 83 dynamically reclaim or readjust translations, "keep-alive" and 84 periodic re-polling may be required. Use of these workarounds MUST 85 be considered transitional in IETF protocols; a better architectural 86 solution is being sought. The explicit intention is to deprecate any 87 such workarounds when sound technical approaches are available. 89 2. Architectural issues affecting UNSAF Systems 91 Any users of these workarounds should be aware that specific 92 technical issues that impede the creation of a general solution 93 include: 95 o there *is* no unique "outside" to a NAT -- it may be impossible to 96 tell where the target UNSAF partner is with respect to the source; 97 how does a client find an appropriate server to reflect its 98 address? (See Appendix C). 100 o specifically because it is impossible to tell where "outside" or 101 "public" is, an address can only be determined relative to one 102 specific point in the network. If the UNSAF partner that 103 reflected a client's address is in a different NAT-masked subnet 104 from some other service X that the client wishes to use, there is 105 _no_ guarantee that the client's "perceived" address from the 106 UNSAF partner would be the same as the address viewed from the 107 perspective of X. (See Appendix C). 109 o absent "middlebox communication (midcom)" there is no usable way 110 to let incoming communications make their way through a firewall 111 under proper supervision: that is, respecting the firewall 112 policies and as opposed to circumventing security mechanisms. The 113 danger is that internal machines are unwittingly exposed to all 114 the malicious communications from the external side that the 115 firewall is intended to block. This is particularly unacceptable 116 if the UNSAF process is running on one machine which is acting on 117 behalf of several. 119 o proposed workarounds include the use of "ping"-like packets as 120 traffic to the target service in order to determine the source 121 address from the perspective of the target. However, there is no 122 guarantee that the address translation will be constant throughout 123 the course of the communication between endpoints; aging of NAT 124 UDP bindings varies widely. 126 o if periodic retries are used to refresh/reevaluate the address 127 translation state, both endpoints are required to maintain 128 information about the presumed state of the communication in order 129 to manage the address illusion. 131 o since the recipient of the "ping"-like packet (the target endpoint 132 of the communication, or some generic reflecting service that is 133 participating in the address determination) is not integrated with 134 the middlebox, it can only operate on the assumption that past 135 behavior is a predictor of future behavior. It has no special 136 knowledge of the address translation heuristic or affecting 137 factors. 139 o the communication exchange is made more "brittle" by the 140 introduction of other servers (UNSAF partners) that need to be 141 reachable in order for the communication to succeed -- more boxes 142 that are "fate sharing" in the communication. 144 Work-arounds may mitigate some of these problems through tight 145 scoping of applicability and specific fixes. For example, 146 o rather than finding the address from "the" outside of the NAT, the 147 applicability of the approach may be limited to finding the "self- 148 address" from a specific service, for use exclusively with that 149 service; 151 o limiting the scope to outbound requests for service (or service 152 initiation) in order to prevent unacceptable security exposures. 154 3. Practical Issues 156 From observations of deployed networks, there is a wide variety of 157 practice in how different NA[P]T boxes implement the handling of 158 different traffic and addressing cases. 160 Some of the specific types of observed behaviors have included: 162 o NA[P]Ts may drop fragments in either direction: without complete 163 TCP/UDP headers, the NA[P]T may not make the address translation 164 mapping, simply dropping the packet. 166 o Shipping NA[P]Ts often contain Application Layer Gateways (ALGs), 167 which attempt to be context-sensitive, performing different 168 actions depending on the application of the data stream. The 169 behavior of the ALGs can be hard to anticipate, and these 170 behaviors have not always been documented. 172 o NA[P]Ts differ markedly in their handling of UDP packets. Quite a 173 few only really work reliably with TCP. If they do handle UDP, 174 the timers aging out flows can vary widely. 176 o Variation in address and port assignments can be quite frequent -- 177 on NAPTs, port numbers always change, and change unpredictably; 178 there may be multiple NATs in parallel for load-sharing, making IP 179 address variations quite likely as well. 181 4. Architectural Considerations 183 By distinguishing these approaches as short term fixes, the IAB 184 believes the following considerations must be explicitly addressed in 185 any proposal: 187 1. Precise definition of a specific, limited-scope problem that is 188 to be solved with the UNSAF proposal. A short term fix should 189 not be generalized to solve other problems; this is why "short 190 term fixes usually aren't". 192 2. Description of an exit strategy/transition plan. The better 193 short term fixes are the ones that will naturally see less and 194 less use as the appropriate technology is deployed. 196 3. Discussion of specific issues that may render systems more 197 "brittle". For example, approaches that involve using data at 198 multiple network layers create more dependencies, increase 199 debugging challenges, and make it harder to transition. 201 4. Identify requirements for longer term, sound technical solutions 202 -- contribute to the process of finding the right longer term 203 solution. 205 5. Discussion of the impact of the noted practical issues with 206 existing, deployed NA[P]Ts and experience reports. 208 5. Security Considerations 210 As a general class of workarounds, as noted above UNSAF proposals may 211 introduce security holes because, absent "middlebox communication 212 (midcom)", there is no usable way to let incoming communications make 213 their way through a firewall under proper supervision: respecting 214 the firewall policies as opposed to circumventing security 215 mechanisms. 217 Authors' Addresses 219 Leslie Daigle 220 Editor 222 Internet Architecture Board 223 IAB 225 EMail: iab@iab.org 227 Appendix A. IAB Members at the time of this writing 229 Harald Alvestrand 231 Ran Atkinson 233 Rob Austein 235 Fred Baker 236 Brian Carpenter 238 Steve Bellovin 240 Jon Crowcroft 242 Leslie Daigle 244 Steve Deering 246 Sally Floyd 248 Geoff Huston 250 John Klensin 252 Henning Schulzrinne 254 Appendix B. Acknowledgements 256 This revision of the document has benefitted greatly from detailed 257 comments and suggestions from Thomas Narten and Bernard Aboba. 259 Appendix C. Example NA[P]T Configuration Scenario 261 Here is one sample scenario wherein it is difficult to describe a 262 single "outside" to a given address realm (bridged by NAPTs). This 263 sort of configuration might arise in an enterprise environment, where 264 different divisions have their own subnets (each using the same 265 private address space); the divisions are connected so that they can 266 pass traffic on each others' networks, but to access the global 267 Internet, each uses a different NAPT/firewall. 269 +---------+ 270 | Box C | (192.168.4.5) 271 +---+-----+ 272 | 273 ---------------------------------+------- 274 | 275 | 192.168.3.0/24 276 +----+----+ 277 | NAT 2 | 278 +----+----+ 279 | 10.1.0.0/32 280 | 281 -----+-------------------------+------------+---- 282 | | 283 | +----+----+ 284 | | Box B | (10.1.1.100) 285 | +---------+ 286 | 287 +----+----+ 288 | NAPT 1 | (10.1.2.27) 289 +----+----+ 290 | 10.1.0.0/32 291 | 292 ----+-----+-- 293 | 294 | 295 +----+----+ 296 | Box A | (10.1.1.100) 297 +---------+ 299 From the perspective of Box B, Box A's address is (some port on) 300 10.1.2.27. From the perspective of Box C, however, Box A's address 301 is some address in the space 192.168.3.0/24. 303 Full Copyright Statement 305 Copyright (C) The Internet Society (2002). All Rights Reserved. 307 This document and translations of it may be copied and furnished to 308 others, and derivative works that comment on or otherwise explain it 309 or assist in its implementation may be prepared, copied, published 310 and distributed, in whole or in part, without restriction of any 311 kind, provided that the above copyright notice and this paragraph are 312 included on all such copies and derivative works. However, this 313 document itself may not be modified in any way, such as by removing 314 the copyright notice or references to the Internet Society or other 315 Internet organizations, except as needed for the purpose of 316 developing Internet standards in which case the procedures for 317 copyrights defined in the Internet Standards process must be 318 followed, or as required to translate it into languages other than 319 English. 321 The limited permissions granted above are perpetual and will not be 322 revoked by the Internet Society or its successors or assigns. 324 This document and the information contained herein is provided on an 325 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 326 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 327 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 328 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 329 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 331 Acknowledgement 333 Funding for the RFC Editor function is currently provided by the 334 Internet Society.