idnits 2.17.1 draft-iab-unsaf-considerations-00.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. ** 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 68: '...ion. Use of these workarounds MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 44 has weird spacing: '...termine or...' == Line 62 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 (January 9, 2002) is 8142 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 (~~), 4 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: July 10, 2002 Internet Architecture Board 5 IAB 6 January 9, 2002 8 IAB Considerations for UNilateral Self-Address Fixing (UNSAF) 9 draft-iab-unsaf-considerations-00.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 July 10, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 In order to alleviate the fundamental problem with current NA[P]T 41 middleboxes altering the relationship between the apparent location 42 and true identity of endpoints, various proposals have been made for 43 "UNilateral Self-Address Fixing (UNSAF)" processes. These are 44 processes whereby some originating process attempts to determine or 45 fix the address (and port) by which it is known -- e.g., to be able 46 to use address data in the protocol exchange, or to advertise a 47 public address from which it will receive connections. 49 This document outlines the reasons for which these proposals can be 50 considered at best as short term fixes to specific problems, and the 51 specific issues to be carefully evaluated before creating an UNSAF 52 proposal. 54 1. Introduction 56 As predicted some years ago, the fundamental problem with current 57 NA[P]T middleboxes is that they alter the relationship between the 58 apparent location and true identity of endpoints. For some purposes, 59 endpoints need to know their own apparent location, or fix a public 60 address from which they will receive packets. "UNilateral Self- 61 Address Fixing (UNSAF)" is a process whereby some originating process 62 attempts to determine or fix the address (and port) by which it is 63 known -- e.g., to be able to use address data in the protocol 64 exchange, or to advertise a public address from which it will receive 65 connections. 67 There are only heuristics and workarounds to attempt to achieve this 68 effect; there is no 100% solution. Use of these workarounds MUST be 69 considered transitional in IETF protocols; a better architectural 70 solution is being sought. The explicit intention is to deprecate any 71 such workarounds when sound technical approaches are available. 73 2. Architectural Considerations for UNSAF Systems 75 Any users of these workarounds should be aware that specific 76 technical issues that impede the creation of a general solution 77 include: 79 o there *is* no unique "outside" to a NAT -- it may be impossible to 80 tell where the target UNSAF partner is with respect to the source; 81 how does a client find an appropriate server to reflect its 82 address? 84 o specifically because it is impossible to tell where "outside" or 85 "public" is, an address can only be determined relative to one 86 specific point in the network. If the UNSAF partner that 87 reflected a client's address is in a different NAT-masked subnet 88 from some other service X that the client wishes to use, there is 89 _no_ guarantee that the client's "perceived" address from the 90 UNSAF partner would be the same as the address viewed from the 91 perspective of X. 93 o absent "middlebox communication (midcom)" there is no usable way 94 to let incoming communications make their way through a firewall 95 under proper supervision: that is, respecting the firewall 96 policies and as opposed to circumventing security mechanisms. 98 o the proposed "ping"-like services create stateful conditions; 99 there is no guarantee that the state will remain consistent for 100 the duration of the communication. 102 o since the reflecting service is not integrated with the middlebox, 103 it does not really know what the middlebox thinks it is doing and 104 can only guess in an attempt to use past behavior as a predictor 105 of future behavior. 107 o the communication exchange is made more "brittle" by the 108 introduction of other servers (UNSAF partners) that need to be 109 reachable in order for the communication to succeed -- more boxes 110 that are "fate sharing" in the communication. 112 Work-arounds may mitigate some of these problems through tight 113 scoping of applicability and specific fixes. For example, 115 o rather than finding the address from "the" outside of the NAT, the 116 applicability of the approach may be limited to finding the "self- 117 address" from a specific service, for use exclusively with that 118 service; 120 o limiting the scope to outbound requests for service (or service 121 initiation). 123 By distinguishing these approaches as short term fixes, the IAB 124 believes the following considerations must be explicitly addressed in 125 any proposal: 127 o Precise definition of a specific, limited-scope problem that is to 128 be solved with the UNSAF proposal. A short term fix should not 129 be generalized to solve other problems; this is why "short term 130 fixes usually aren't". 132 o Description of an exit strategy/transition plan. The better short 133 term fixes are the ones that will naturally see less and less use 134 as the appropriate technology is deployed. 136 o Discussion of specific issues that may render systems more 137 "brittle". For example, approaches that involve using data at 138 multiple network layers create more dependencies, increase 139 debugging challenges, and make it harder to transition. 141 o Identify requirements for longer term, sound technical solutions - 142 - contribute to the process of finding the right longer term 143 solution. 145 3. Security Considerations 147 As a general class of workarounds, as noted above UNSAF proposals may 148 introduce security holes because, absent "middlebox communication 149 (midcom)", there is no usable way to let incoming communications make 150 their way through a firewall under proper supervision: respecting 151 the firewall policies as opposed to circumventing security 152 mechanisms. 154 Authors' Addresses 156 Leslie Daigle 157 Editor 159 Internet Architecture Board 160 IAB 162 EMail: iab@iab.org 164 Appendix A. IAB Members at the time of this writing 166 Harald Alvestrand 168 Ran Atkinson 170 Rob Austein 172 Fred Baker 174 Brian Carpenter 176 Steve Bellovin 178 Jon Crowcroft 180 Leslie Daigle 182 Steve Deering 184 Sally Floyd 186 Geoff Huston 188 John Klensin 190 Henning Schulzrinne 192 Full Copyright Statement 194 Copyright (C) The Internet Society (2002). All Rights Reserved. 196 This document and translations of it may be copied and furnished to 197 others, and derivative works that comment on or otherwise explain it 198 or assist in its implementation may be prepared, copied, published 199 and distributed, in whole or in part, without restriction of any 200 kind, provided that the above copyright notice and this paragraph are 201 included on all such copies and derivative works. However, this 202 document itself may not be modified in any way, such as by removing 203 the copyright notice or references to the Internet Society or other 204 Internet organizations, except as needed for the purpose of 205 developing Internet standards in which case the procedures for 206 copyrights defined in the Internet Standards process must be 207 followed, or as required to translate it into languages other than 208 English. 210 The limited permissions granted above are perpetual and will not be 211 revoked by the Internet Society or its successors or assigns. 213 This document and the information contained herein is provided on an 214 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 215 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 216 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 217 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 218 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 220 Acknowledgement 222 Funding for the RFC Editor function is currently provided by the 223 Internet Society.