Re: draft-iab-unsaf-considerations-01.txt
Hi. I liked most of your suggestions for the UNSAF document. I'd like to comment further on two or three things: > Also from section 2: > > > >o absent "middlebox communication (midcom)" there is no usable way > > to let incoming communications make their way through a firewall > > under proper supervision: that is, respecting the firewall > > policies and as opposed to circumventing security mechanisms. The > > danger is that internal machines are unwittingly exposed to all > > the malicious communications from the external side that the > > firewall is intended to block. This is particularly unacceptable > > if the UNSAF process is running on one machine which is acting on > > behalf of several. > > I contend this is not a problem posed only by UNSAF processes. > Firewalls that filter at the Internet and transport layers have > performance requirements for enforcing access control policies on > incoming communications even when only one address realm is involved. > > I don't see how the presence of NA[P]T in a firewall substantially > alters these requirements. the difference is this - a firewall presumably gives you the ability to set policy about what kind of traffic is permitted - so you can choose which applications work and which fail according to your estimate of the benefit and risk that each presents. a NAT makes an entire class of applications fail whether you want them to fail or not - once you install the NAT, you have little further choice about whether those applications fail. (yes, I know you can often nail up a address binding, but this doesn't solve most of the problems, and it only works for a small number of hosts behind a NAPT) but I think the IAB were trying to say that it's important to make sure that measures used to circumvent NAT problems do not essentially end up violating site security policies. an application that's not allowed to talk through a firewall shouldn't be able to use the NAT-workaround to enable it to do so. (and if that's what they meant to say, perhaps it can be said more clearly?) (but IMHO neither should the mere presence of a NAT be taken to mean that there's a policy in place that prohibits incoming connections) > >1. Precise definition of a specific, limited-scope problem that is > >to be solved with the UNSAF proposal. A short term fix should > >not be generalized to solve other problems; this is why "short > >term fixes usually aren't". > > For example, I suggest extensions to Internet application protocols for > UNSAF use (in an IPv4/NAT environment) should be preferred to > application protocols generalized for UNSAF use (over both IPv6 and IPv4 > transports). this seems like a overgeneralization, or maybe I don't understand you. the method that used to adapt an application to NATs will necessarily vary significantly from one application to another, depending on a wide variety of factors - the communications patterns, typical session duration, deployment model (can the user reasonably be expected to install a proxy?), consequences of failure, etc. of each application. at the same time, a generalized approach can be applied to a significant subset of applications, with a useful side effect of aiding a transition to IPv6. see draft-moore-nat-tolerance-recommendations-00 for a start. > This scenario reminds me of a similar one I've observed in a > depressingly large number of home networks in which the wireless access > point product I helped develop has been installed by novice users. > > Here is the scenario which is most familiar to me: > >o the customer has existing Internet service from some broadband > service provider, using e.g. a DSL line connected to an > appliance that integrates a DSL modem with a NAPT router/firewall. > >o these devices are sometimes packaged with automated provisioning > firmware, so the customer may view them as part of what their > ISP provides them. > >o later, the customer wants to use a host with only a wireless LAN > interface; so, they install a wireless access point (like the > one I helped to develop) that ships in its default configuration > with NAPT and a DHCP server enabled. > >o after this, the customer has a wired LAN in one private address > realm and a wireless LAN in another private address realm. > > Furthermore, most customers probably have no idea what the phrase > "address realm" means, and shouldn't have to learn it. All they often > know is that the printer server is inaccessible to the wireless laptop > computer. (Why? Because the discovery protocol uses UDP multicast with > TTL=1, but that's okay because any response would just be dropped by the > NAPT anyway, because there's no ALG.) I'd say that "why" is because NAPT+(PPP/DHCP) is a poor solutio
Re: draft-iab-unsaf-considerations-01.txt
>Also, I think it would be helpful to know how commonly twice-NAT is >deployed, but I don't have any data there. I believe (at least) twice-NAT is fairly common. I have a NATting router between by cable access modem and my home's local area network, and my cable access provider has a NATting router between the cable access network and the public internet. So that's two. And then if one of the PC's on my home LAN connects up to a PC on the home LAN of another similarly configured user, that would be four. Don't ask me how we make that connection today: it's a kludge and probably violates one or both of our cable access service subscription agreements. :-) BTW, this is why I want MIDCOM! Jim james woodyatt <[EMAIL PROTECTED]>@ietf.org on 04/04/2002 05:53:31 PM Sent by: [EMAIL PROTECTED] To: IETF list <[EMAIL PROTECTED]> cc: Leslie Daigle <[EMAIL PROTECTED]> Subject: draft-iab-unsaf-considerations-01.txt friends-- I have some commentary to offer on draft-iab-unsaf- considerations-01.txt, i.e. "IAB Considerations for UNilateral Self-Address Fixing (UNSAF)" which comes from my experience developing a consumer network appliance that combines the functions of an 802.11b access point with a NAT router for Internet access. From section 2: > >o there *is* no unique "outside" to a NAT -- it may be impossible to > tell where the target UNSAF partner is with respect to the source; > how does a client find an appropriate server to reflect its > address? (See Appendix C). > >o specifically because it is impossible to tell where "outside" or > "public" is, an address can only be determined relative to one > specific point in the network. If the UNSAF partner that > reflected a client's address is in a different NAT-masked subnet > from some other service X that the client wishes to use, there is > _no_ guarantee that the client's "perceived" address from the > UNSAF partner would be the same as the address viewed from the > perspective of X. (See Appendix C). These two paragraphs are confusing to me. The explanation in Appendix C helps to clarify the issue, but I would suggest rewriting them along the following lines: o a NAT may be a gateway between two or more private address realms, with another NAT optionally used to gateway to the public Internet realm; therefore, it may not always be possible to fix a transport address to the correct realm (or realms) for a given instance of an UNSAF process. (See Appendix C). o there is no system for identifying address realms; therefore, even if there were a mechanism for UNSAF processes to reflect their transport addresses correctly in all appropriate realms, the address of a service from the perspective of a client in one realm is not comparable with the address of the same service from the perspective of a client in another realm. Also from section 2: > >o absent "middlebox communication (midcom)" there is no usable way > to let incoming communications make their way through a firewall > under proper supervision: that is, respecting the firewall > policies and as opposed to circumventing security mechanisms. The > danger is that internal machines are unwittingly exposed to all > the malicious communications from the external side that the > firewall is intended to block. This is particularly unacceptable > if the UNSAF process is running on one machine which is acting on > behalf of several. I contend this is not a problem posed only by UNSAF processes. Firewalls that filter at the Internet and transport layers have performance requirements for enforcing access control policies on incoming communications even when only one address realm is involved. I don't see how the presence of NA[P]T in a firewall substantially alters these requirements. Again from section 2: > >o proposed workarounds include the use of "ping"-like packets as > traffic to the target service in order to determine the source > address from the perspective of the target. However, there is no > guarantee that the address translation will be constant throughout > the course of the communication between endpoints; aging of NAT > UDP bindings varies widely. This is another paragraph that is confusing to me. I think it's because the word "target" is used in way that makes it hard to understand in context. I'd prefer to see this written as follows: o proposed workarounds include the use of "ping"-like address discovery requests sent from the initiator to the listener, to which the listener responds with the transport address of the initiator-- in the address realm of the listener; however, with connection-less transports, e.g. UDP, IPsec ESP, etc., an UNSAF process must take
Re: draft-iab-unsaf-considerations-01.txt
>>Also, I think it would be helpful to know how commonly twice-NAT is >>deployed, but I don't have any data there. > >I believe (at least) twice-NAT is fairly common. I have a NATting router >between by cable access modem and my home's local area network, and my >cable access provider has a NATting router between the cable access >network and the public internet. What cable provider is this, so that we can avoid them? /\ |John Stracke|Principal Engineer | |[EMAIL PROTECTED] |Incentive Systems, Inc.| |http://www.incentivesystems.com |My opinions are my own.| || |See what bilateral symmetry can do for YOU! | \/
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 08:42 AM, [EMAIL PROTECTED] wrote: > [I wrote:] >>Also, I think it would be helpful to know how commonly twice-NAT is >>deployed, but I don't have any data there. > > I believe (at least) twice-NAT is fairly common. I have a NATting router > between by cable access modem and my home's local area network, and my > cable access provider has a NATting router between the cable access > network and the public internet. [...] I should clarify that I was using the term "twice-NAT" as defined in section 4.3 of RFC 2663 "NAT Terminology and Considerations" which actually describes quite a different thing altogether. Begin excerpt: >Twice NAT is a variation of NAT in that both the source and >destination addresses are modified by NAT as a datagram crosses >address realms. This is in contrast to Traditional-NAT and Bi- >Directional NAT, where only one of the addresses (either source or >destination) is translated. [...] Your scenario (which is in the same category as my scenario and the scenario in Appendic C) is not named anywhere I can find. If it has no name yet, I would propose "compound NAT" or something similar. I think it's important to distinguish that we're not talking about a type of NAT here, but rather a way of composing a topology of address realms using multiple instances of potentially different types of NAT. (Ick-- I feel dirty just writing that phrase.) -- j h woodyatt <[EMAIL PROTECTED]>
Re: draft-iab-unsaf-considerations-01.txt
Pretty much any of the large providers that only provide 10/8 addresses to their custommers... I believe AOL for one does this and it wouldn't surprise me if most of the large cable providers do something silly like this at the low end (You can always pay more for a real IP address) Bill On Fri, Apr 05, 2002 at 02:25:49PM -0500, John Stracke wrote: > >>Also, I think it would be helpful to know how commonly twice-NAT is > >>deployed, but I don't have any data there. > > > >I believe (at least) twice-NAT is fairly common. I have a NATting router > >between by cable access modem and my home's local area network, and my > >cable access provider has a NATting router between the cable access > >network and the public internet. > > What cable provider is this, so that we can avoid them? > > /\ > |John Stracke|Principal Engineer | > |[EMAIL PROTECTED] |Incentive Systems, Inc.| > |http://www.incentivesystems.com |My opinions are my own.| > || > |See what bilateral symmetry can do for YOU! | > \/ >
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 01:49 PM, Bill Strahm wrote: > > [...] I believe AOL for one does this and it wouldn't surprise me if > most of the large cable providers do something silly like this at the > low end (You can always pay more for a real IP address) I have also received several reports from multiple sources I find credible that at least one large ISP in Asia is doing this. I am, of course, unable to verify such reports. -- j h woodyatt <[EMAIL PROTECTED]>
Re: draft-iab-unsaf-considerations-01.txt
On Thursday, April 4, 2002, at 05:53 PM, Keith Moore wrote: > [I wrote:] >> [...] >> I don't see how the presence of NA[P]T in a firewall substantially >> alters these requirements. > > [...] > but I think the IAB were trying to say that it's important to make > sure that measures used to circumvent NAT problems do not essentially > end up violating site security policies. an application that's > not allowed to talk through a firewall shouldn't be able to use the > NAT-workaround to enable it to do so. (and if that's what they meant > to say, perhaps it can be said more clearly?) If that's the case, then it wasn't clear to me in the draft. Perhaps one of the current members of the IAB would care to clarify this point before I offer to compose an alternative wording. > (but IMHO neither should the mere presence of a NAT be taken to mean > that there's a policy in place that prohibits incoming connections) I rather liked the language your wrote in draft-moore-nat-tolerance-recommendations-00.txt about that. Perhaps UNSAF proposals should be structured so that they make no assumptions about whether the presence of NAPT does or does not imply a policy permitting or prohibiting any particular class of incoming connections. I'm not sure how to say that in a meaningful way. >>>1. Precise definition of a specific, limited-scope problem that is >>>to be solved with the UNSAF proposal. A short term fix should >>>not be generalized to solve other problems; this is why "short >>>term fixes usually aren't". >> >> For example, I suggest extensions to Internet application protocols for >> UNSAF use (in an IPv4/NAT environment) should be preferred to >> application protocols generalized for UNSAF use (over both IPv6 and >> IPv4 >> transports). > > this seems like a overgeneralization, or maybe I don't understand you. I suspect I wasn't communicating clearly. > the method that used to adapt an application to NATs will necessarily > vary significantly from one application to another, depending on > a wide variety of factors - the communications patterns, typical session > duration, deployment model (can the user reasonably be expected to > install > a proxy?), consequences of failure, etc. of each application. > at the same time, a generalized approach can be applied to a significant > subset of applications, with a useful side effect of aiding a transition > to IPv6. see draft-moore-nat-tolerance-recommendations-00 for a start. I was specifically thinking about UNSAF processes, and all I was trying to do was ask the IAB to make a specific recommendation against the use of UNSAF processes in applications of IPv6 transports. I've met too many people-- who are otherwise fairly smart-- who are absolutely committed to the notion that NAT devices will still be required to secure IPv6 networks. I don't understand them, and I think they're wrong about the security considerations of NAT, but I know they're out there. - Another thing that springs to mind: the IAB should probably encourage-- in no uncertain terms-- that any UNSAF process specified for use with IPv4 NAT should also be specified for use with RFC 2766 "Network Address Translation - Protocol Translation (NAT-PT)" as well. -- j h woodyatt <[EMAIL PROTECTED]>
Re: draft-iab-unsaf-considerations-01.txt
On Friday, April 5, 2002, at 03:25 PM, james woodyatt wrote: > > Another thing that springs to mind: the IAB should probably encourage-- > in no uncertain terms-- that any UNSAF process specified for use with > IPv4 NAT should also be specified for use with RFC 2766 "Network > Address Translation - Protocol Translation (NAT-PT)" as well. I forgot to mention: I think that the dominant variant of NAT-PT will be the combination of Bidirectional-NAT-PT and NAPT-PT. I will admit, though, that my wording above was probably too strong. I'd like to revise my comment by suggesting that proposals for UNSAF processes applicable to IPv4 NAT should be reviewed in the light of RFC 2766 NAT-PT as well. -- j h woodyatt <[EMAIL PROTECTED]>
