Re: IP network address assignments/allocations information?
On Mon, 29 Nov 1999 22:45:17 PST, Ian King said: > any "lack" because of it. I don't play UDP-based games or employ any of the > other relatively new protocols that are so sensitive to end-to-end-ness > (should they be? was that a valid assumption?), so a NAT is a great solution Well.. Urm... TCP and UDP both assume that one endpoint is talking directly in real time to another endpoint. The NAT problems only start when the protocol carries IP address/port information (such as the FTP 'PORT' command), and the NAT isn't aware of that protocol's translation requirements (If you see *this* at offset 80 of *that* packet, smash it to read *foobar* instead). I'll grant FTP an exemption, it came well before NAT units became prevalent (Was there an FTP-over-NCP before The Great IP Deployment?). However, I do agree that anybody designing a protocol in the last 3-4 years *should* have designed it to be firewall and NAT friendly. (Yes, I know that can be difficult in practice. I guess that's today's "Welcome to Reality"). Valdis Kletnieks Operating Systems Analyst Virginia Tech
RE: IP network address assignments/allocations information?
Hi Tony, Well, the statement below is not true -- I sit behind a NAT/PAT device and Real PLayer works just fine for me. I've only found a couple of applications that will not work for me (e.g. ICQ, NTP, SNMP), but then again, I'm not a gamer so I can't speak to the broader range of applications that it _does_ break. In any event, I've always personally been of the opinion that if applications don't work in the face of NAT, then the applications themselves are functionally deficient and should be fixed. :-) Cheers, - paul At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: >1) Yes ... We have been forced into a world of NAT where simple >applications such as Real Player won't work without real-time manual >intervention at the NAT.
Re: IP network address assignments/allocations information?
> And yes, additional IP addresses were going to cost dramatically more. NAT > was a simple case of economics... but on the other hand, I don't experience > any "lack" because of it. I don't play UDP-based games or employ any of the > other relatively new protocols that are so sensitive to end-to-end-ness > (should they be? was that a valid assumption?), so a NAT is a great solution > for me. understood. and you may never miss any of those distributed applications or applications that want your end to be the "server" for the very reason that NAT prevents them from having enough market share to be successful. i.e. just because you don't know what you're missing doesn't mean that NAT hasn't done you harm. > NAT would be bad if an ISP were using it to artificially expand its address > space; the use of NAT at the "small-time" end user's site seems quite > practical and beneficial, especially in a world where ISPs are going to hold > up non-naive users for ransom. Cheers -- Ian if you think of NAT as a short-term strategy and are fully aware of its limitations, it probably won't cause you much harm as an individual. then again, there are dozens of products out there claiming to offer something like "internet connection sharing" without bothering to mention the limitations of that approach...which seems like misleading advertising at best. Keith
Re: IP network address assignments/allocations information?
Paul Ferguson wrote: > > Hi Tony, > > Well, the statement below is not true -- I sit behind a NAT/PAT > device and Real PLayer works just fine for me. I've only found a > couple of applications that will not work for me (e.g. ICQ, NTP, > SNMP), but then again, I'm not a gamer so I can't speak to the > broader range of applications that it _does_ break. Real added features to their protocol which permit it to work around most anything. These include using TCP instead of UDP if UDP doesn't work (probably how you're getting your streams, if you look at the statistics). I have found NTP (ok, SNTP) actually works fine through the NAPT implementation I use. A very large percentage of the protocols used by actual end users really do work, provided the servers are out on the public network. > > In any event, I've always personally been of the opinion that > if applications don't work in the face of NAT, then the > applications themselves are functionally deficient and should be > fixed. :-) Indeed. While some in the IETF have stomped their feet and railed about how bad NAT is architecturally (something I suspect most folks concede) they've somehow believed it would be possible to offer a better solution and get NAT eliminated before it's widely deployed. Reality: it's extremely widely deployed, and must be taken into consideration when designing protocols. Those, like Real, who find ways to make their protocols work with NAT clearly will do better than those who do not. I've have thought I'd get a lot of feedback on the draft I've been working on in this area, draft-ietf-nat-app-guide-02.txt, but that's not been the case. New protocols should, in my opinion, provide descriptions of how they work or don't work with NAT. If there is a reason why they aren't going to work (carriage of port or address information), a description of how to build an Application Layer Gateway (ALG) should be provided. We are at a crossroads where architectural purity has intersected operational reality. > At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: > > >1) Yes ... We have been forced into a world of NAT where simple > >applications such as Real Player won't work without real-time manual > >intervention at the NAT. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranthnetworks.com
Re: IP network address assignments/allocations information?
> The NAT problems only > start when the protocol carries IP address/port information (such > as the FTP 'PORT' command), and the NAT isn't aware of that protocol's > translation requirements this is a popular misconception; it's a bit like saying that y2k only breaks programs that store years in two digits. see http://www.cs.utk.edu/~moore/what-nats-break.html for my attempt to list the various ways that programs can lose in the presence of NATs. Keith
RE: IP network address assignments/allocations information?
1) It doesn't have to stay that way with IPv6 or an equivalent technology. 2) That's good news. More details would be useful. 3) I think this is a red herring. With most organizations moving to DHCP and many to LDAP-driven policy management, this is completely possible. What makes you argue that such a transition isn't possible? It's much easier than (say) migrating operating systems. ssh -- Steve Hultquist, CTO and VP of Technology Leopard Boulder, Colorado, http://www.leopard.com/ "Tony Hain (Exchange)" <[EMAIL PROTECTED]> 11/29/99 11:44 AM To: "Fleischman, Eric W" <[EMAIL PROTECTED]>, Randy Bush <[EMAIL PROTECTED]>, "'Brian E Carpenter'" <[EMAIL PROTECTED]> cc: Bill Manning <[EMAIL PROTECTED]>, Pete Loshin <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: RE: IP network address assignments/allocations information? 1) Yes ... We have been forced into a world of NAT where simple applications such as Real Player won't work without real-time manual intervention at the NAT. 2) Yes Microsoft plans to support IPv6, and work has started. 3) We have moved from a world where Internal/External (and the associated management burden) was an option, to one where it is required. If corporations wanted to remove their firewalls (using IPSec instead) they couldn't. -Original Message- From: Fleischman, Eric W [mailto:[EMAIL PROTECTED]] Sent: Monday, November 29, 1999 8:47 AM To: Randy Bush; 'Brian E Carpenter' Cc: Bill Manning; Pete Loshin; [EMAIL PROTECTED] Subject: RE: IP network address assignments/allocations information? A few questions for the list: 1) If we effectively ran out of addresses when RFC 1597 was published, has running out of addresses hurt us in any way? 2) Originally we had anticipated using IPv6 to save us from IPv4 address depletion. What's the status of IPv6? How does IPv6 traffic compare in volume with IPv4 traffic? Do non-IPv6-supporting vendors (e.g., Microsoft) have plans to eventually support IPv6? 3) Given the current situation of corporations using private addresses internally and a smaller set of global IPv4 addresses on their periphery, and a global IPv4 internet, one should theoretically be able to say how many public IPv4 addresses have been assigned and therefore how many remain unassigned and by so doing estimate how long until consumption. Why is this not possible in practice? > -- > From: Brian E Carpenter[SMTP:[EMAIL PROTECTED]] > Sent: Friday, November 26, 1999 1:35 PM > To: Randy Bush > Cc: Bill Manning; Pete Loshin; [EMAIL PROTECTED] > Subject: Re: IP network address assignments/allocations information? > > Well, let's not focus on Bill's data. Frankly, I haven't seen any data > on this topic from any source that really convinces me that it > means much. All I know is that we have thousands of sites using > private address space, which completely falsifies any real data and > makes it impossible to attach any real meaning to concepts such as > "running out of addresses". My personal opinion is that we ran out > of addresses in practical terms around about when RFC 1597 was published. > > Brian > > Randy Bush wrote: > > > > > www.isi.edu/~bmanning/in-addr-audit.html > > > It does not cover specific /16 & /24 delegations, it just looks at > > > all of the SOA entries. Still, it does give a representation of how much > > > space is delegated. > > > > uh, as these data appear to be the statistics of an attempt to walk the > > dns in-addr.arpa tree what confidence is there that this fairly represents > > address space assignment/allocation? > > > > e.g. there are 153 /16 announcements in 133.0.0.0 and the table at > > http://www.isi.edu/~bmanning/in-addr-data.html shows one in-addr.arpa > > allocation entries. > > > > e.g. there are 166 announcements (of 175 /16 equivalents of space) in > > 147.0.0.0 and the table at http://www.isi.edu/~bmanning/in-addr-data.html > > shows 193 in-addr.arpa entries. > > > > so how can the data at www.isi.edu/~bmanning/in-addr-audit.html be > > interpreted to give a useful representation of how much space is > > assignmed/allocated? > > > > randy >
RE: IP network address assignments/allocations information?
> In any event, I've always personally been of the opinion that > if applications don't work in the face of NAT, then the > applications themselves are functionally deficient and should be > fixed. :-) I'm certainly not going to disagree with you about that, but H.323 does not work through NAT without extremely sophisticated stateful inspection/rewrite capabilities in the NAT, and it will not work, period, if the signaling streams are encrypted. For better or worse (and let's not get into that), there's a lot of H.323 out there and there's going to be much, much more over the coming years. RSIP isn't going to work cleanly with H.323, either (although there are some rather disgusting things you can do in the application about that). We can "should" until the cows come home (Hey! They're home!), but there's a lot of real software out there that is broken by network address translation. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, NY 14850 +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) [EMAIL PROTECTED]
RE: IP network address assignments/allocations information?
While it is important to focus on building protocols that are as functional as possible in as many different environments as possible, I find the statement that protocols are "functionally deficient" that do not take NAT and firewalls into account to be misguided. The ultimate goal of a network, in my mind, is to create an invisible connection between process running in distributed systems regardless of their location or connectivity. While protocol development is an appropriate place to address issues introduced by lower-level elements of the overall system, development of the lower levels should be focused on making development at higher levels as straight-forward as is practical. As has been discussed more exhaustively and ably by others than I am able to, NAT breaks this model. By introducing a single point-of-failure into the overall system and by also introducing artificial limitations linked directly to the temporary scarcity of address space, it is an anomoly in the overall development of the network system. The overall design philosophy for the network system, at least in my way of thinking, is one of inclusion and direct communication. We should endeavor to develop with that mindset. ssh Paul Ferguson <[EMAIL PROTECTED]> 11/30/99 05:10 AM To: "Tony Hain (Exchange)" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: RE: IP network address assignments/allocations information? Hi Tony, Well, the statement below is not true -- I sit behind a NAT/PAT device and Real PLayer works just fine for me. I've only found a couple of applications that will not work for me (e.g. ICQ, NTP, SNMP), but then again, I'm not a gamer so I can't speak to the broader range of applications that it _does_ break. In any event, I've always personally been of the opinion that if applications don't work in the face of NAT, then the applications themselves are functionally deficient and should be fixed. :-) Cheers, - paul At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote: >1) Yes ... We have been forced into a world of NAT where simple >applications such as Real Player won't work without real-time manual >intervention at the NAT. - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: IP network address assignments/allocations information?
--- Keith Moore <[EMAIL PROTECTED]> wrote: > > And yes, additional IP addresses were going to cost dramatically more. NAT > > was a simple case of economics... but on the other hand, I don't experience > > any "lack" because of it. I don't play UDP-based games or employ any of > the > > other relatively new protocols that are so sensitive to end-to-end-ness > > (should they be? was that a valid assumption?), so a NAT is a great > solution > > for me. > > understood. and you may never miss any of those distributed applications > or applications that want your end to be the "server" for the very reason > that NAT prevents them from having enough market share to be successful. > > i.e. just because you don't know what you're missing doesn't mean that NAT > hasn't done you harm. > Keith - There is no denying that NAT devices break a bunch of applications and protocols. But, they did get us through the rough times when IP addresses are scarce and many people wanted to hop on the Internet. In a way, NATs helped people keep their trust in IP and in the engineering community as a whole to come up with solutions that meet the need of the time. Having said this, I do believe, people who market NAT devices should warn customers of the limitations and not pretend like there arent any. There are some folks who believe NATs are behind the creation of private addresses. The fact of the matter of the matter is the other way around. People have been using private addresses to build their networks; People change their providers, but do not want to renumber their networks each time they change their providers. NATs were able to provide connetivity to external world without requiring them to renumber their addresses in the private network. If nothing else, I would say that NATs were able to bring to bear an awareness in the minds of protocol/application designers a need to seperate names and addresses. That in itself seems like an accomplishment. > > NAT would be bad if an ISP were using it to artificially expand its address > > space; the use of NAT at the "small-time" end user's site seems quite > > practical and beneficial, especially in a world where ISPs are going to > hold > > up non-naive users for ransom. Cheers -- Ian > > if you think of NAT as a short-term strategy and are fully aware of its > limitations, it probably won't cause you much harm as an individual. > > then again, there are dozens of products out there claiming to offer > something like "internet connection sharing" without bothering to mention > the limitations of that approach...which seems like misleading advertising > at best. > I agree. > Keith > > regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
Valdis Kletnieks wrote: > However, I do agree that anybody designing a protocol in the last 3-4 > years *should* have designed it to be firewall and NAT friendly. > (Yes, I know that can be difficult in practice. I guess that's today's > "Welcome to Reality"). Daniel Senie wrote: > > In any event, I've always personally been of the opinion that > > if applications don't work in the face of NAT, then the > > applications themselves are functionally deficient and should be > > fixed. :-) > > ...and [NAT] must be taken into consideration when designing protocols. > >New protocols should, in my opinion, provide descriptions > of how they work or don't work with NAT. If there is a reason why they > aren't going to work (carriage of port or address information), a > description of how to build an Application Layer Gateway (ALG) should be > provided. I really think trying to make everything "NAT aware" or "NAT friendly" is spending effort heading in the wrong direction. While I am forced to concede the wide deployment of NAT technology, I believe the problems it solves (or at least claims to) are better solved by other means, or require different solutions. Protocols are difficult enough to get right. I'd rather see time spent developing good algorithms than NAT compatibility. What about future NAT "features"? Are protocol designers supposed to guess at what new convolutions will be dreamt up? About the only serious issues NAT really addresses are the perceived IP address shortage, and being forced to renumber when changing ISPs. As for the shortage, this thread seems to indicate there isn't a real firm idea of how many addresses are actually being used. Have all the minimally used class A and B addresses been reclaimed? I suspect not, which tells me the immediate shortage can't be that great. And if switching to IPv6 in the long term has problems, effort should be spent solving those. As for being forced to renumber (can't take your address with you), is this really a technical routing problem (tables too large), or more of an economic/political/turf issue? While renumbering can be painful, DNS should hide the change, and things like DHCP can make it less so. Besides it shouldn't be too difficult for small organizations, and large ones should be able to take their address as they move. While NAT is an adequate stopgap solution to IP address dilemmas, in my opinion, it shouldn't be the final solution. > We are at a crossroads where architectural purity has intersected > operational reality. Let's not continue down the wrong road. Tony
Re: IP network address assignments/allocations information?
[EMAIL PROTECTED] wrote: > > > In any event, I've always personally been of the opinion that > > if applications don't work in the face of NAT, then the > > applications themselves are functionally deficient and should be > > fixed. :-) > > I'm certainly not going to disagree with you about that, > but H.323 does not work through NAT without extremely > sophisticated stateful inspection/rewrite capabilities > in the NAT, and it will not work, period, if the signaling > streams are encrypted. For better or worse (and let's > not get into that), there's a lot of H.323 out there > and there's going to be much, much more over the > coming years. RSIP isn't going to work cleanly with > H.323, either (although there are some rather disgusting > things you can do in the application about that). Agreed. Any protocol that wants to have out-of-band control will have difficulties with existing NATs (without ALGs). Thus, by saying "let's design NAT-friendly protocols", we are effectively ruling out a whole class of designs and only allow protocols with outgoing TCP connections (and possibly UDP request-response protocols). In the case of telephony, it would mean keeping a TCP connection open continuously to some outside server that would then use that TCP connection to send incoming calls behind the NAT. Thus, this is not just a matter of existing software, but fundamentally restricting protocol design to a very narrow class of design choices, choices which are basically inappropriate for anything related to efficient multimedia carriage (real-time multimedia over TCP isn't exactly a great option). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Re: IP network address assignments/allocations information?
> Keith - There is no denying that NAT devices break a bunch of applications > and protocols. But, they did get us through the rough times when IP > addresses are scarce and many people wanted to hop on the Internet. In a > way, NATs helped people keep their trust in IP and in the engineering > community as a whole to come up with solutions that meet the need of the > time. the latter statement seems a bit extreme. one could as easily make the statement that NATs are giving the engineering community a bad reputation in the eyes of the public, given that so many problems are now being caused by them. (also an extreme statement, but no less so than the first one) I'd rather just say that (a) NATs are a short-term fix with limited applicability, (b) for the long term general solution we will need longer addresses - as in IPv6, and (c) with careful definition of adaptation mechanisms such as NAT-PT and 6to4, devices with NAT and ALG functionality can be part of a transition path to IPv6. > There are some folks who believe NATs are behind the creation of private > addresses. The fact of the matter of the matter is the other way around. > People have been using private addresses to build their networks; People > change their providers, but do not want to renumber their networks each > time they change their providers. NATs were able to provide connetivity > to external world without requiring them to renumber their addresses in > the private network. absolutely true. > If nothing else, I would say that NATs were able to bring to bear an > awareness in the minds of protocol/application designers a need to > seperate names and addresses. though folks are indeed looking into the implications of such a separation, it's far from clear that this is a 'need'. every additional layer of indirection imposes a cost in terms of money, performance, reliability, and flexibility - all of which need to be weighted against whatever advantages might be obtained from such a separation. Keith
Re: IP network address assignments/allocations information?
--- Keith Moore <[EMAIL PROTECTED]> wrote: > > Keith - There is no denying that NAT devices break a bunch of applications > > and protocols. But, they did get us through the rough times when IP > > addresses are scarce and many people wanted to hop on the Internet. In a > > way, NATs helped people keep their trust in IP and in the engineering > > community as a whole to come up with solutions that meet the need of the > > time. > > the latter statement seems a bit extreme. one could as easily make the > statement that NATs are giving the engineering community a bad reputation > in the eyes of the public, given that so many problems are now being caused > by them. (also an extreme statement, but no less so than the first one) > I wasnt meaning to make an extreme statement. You are right; Neither of the statements by itself is complete. Fair is somewhere in the middle. > I'd rather just say that (a) NATs are a short-term fix with limited > applicability, (b) for the long term general solution we will need > longer addresses - as in IPv6, and (c) with careful definition of > adaptation mechanisms such as NAT-PT and 6to4, devices with NAT > and ALG functionality can be part of a transition path to IPv6. > That sounds good. Thanks. > > There are some folks who believe NATs are behind the creation of private > > addresses. The fact of the matter of the matter is the other way around. > > People have been using private addresses to build their networks; People > > change their providers, but do not want to renumber their networks each > > time they change their providers. NATs were able to provide connetivity > > to external world without requiring them to renumber their addresses in > > the private network. > > absolutely true. > > > If nothing else, I would say that NATs were able to bring to bear an > > awareness in the minds of protocol/application designers a need to > > seperate names and addresses. > > though folks are indeed looking into the implications of such a separation, > it's far from clear that this is a 'need'. every additional layer > of indirection imposes a cost in terms of money, performance, reliability, > and flexibility - all of which need to be weighted against whatever > advantages might be obtained from such a separation. > Address-renumbering and host-mobility come to mind as areas that can benefit from seperation of name and address semantics. Surely, this should be weighed against other metrics, as you say. No one solution fits all. > Keith regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
At 3:04 -0500 11/30/99, [EMAIL PROTECTED] wrote: >On Mon, 29 Nov 1999 22:45:17 PST, Ian King said: >> any "lack" because of it. I don't play UDP-based games or employ any of the >> other relatively new protocols that are so sensitive to end-to-end-ness >> (should they be? was that a valid assumption?), so a NAT is a great solution > >Well.. Urm... TCP and UDP both assume that one endpoint is talking >directly in real time to another endpoint. The NAT problems only >start when the protocol carries IP address/port information (such >as the FTP 'PORT' command), and the NAT isn't aware of that protocol's >translation requirements (If you see *this* at offset 80 of *that* >packet, smash it to read *foobar* instead). I would tend to agree. As I have said elsewhere, NATs in and of themselves do nothing wrong. They are doing things within the Internet/Network Layer that are perfectly legal. (In essence, they are treating the network address in much the same way that X.25, ATM, and MPLS treat their addresses.) The problem is that applications lacking an "application address space" are using the Network address space inappropriately. In a sense, we are making the same mistake the phone companies made when they kludged their route-dependent address space to be location-independent (first 800 numbers and then mobile). They have since fixed their problem. > >I'll grant FTP an exemption, it came well before NAT units became >prevalent (Was there an FTP-over-NCP before The Great IP Deployment?). Actually, there was and the PORT command existed as a kludge. The preferred approach for the data connection was intended to be a fixed offset from the telnet connection. The PORT command, then called SOCK, was inserted because BBN TIPs hardwired printers and such to certain sockets. Not exactly an example I would recommend following. The PORT command should have been retired decades ago. >However, I do agree that anybody designing a protocol in the last 3-4 >years *should* have designed it to be firewall and NAT friendly. >(Yes, I know that can be difficult in practice. I guess that's today's >"Welcome to Reality"). Applications which need to communicate addressing information for their own use should only use an application address space. Now, the fact that we don't have one is a bit of a problem! ;-) It would have been nice to have one before we got this far. How we get out of this mess at this point is anyone's guess. Take care, john
Re: IP network address assignments/allocations information?
--- Henning Schulzrinne <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > > > > In any event, I've always personally been of the opinion that > > > if applications don't work in the face of NAT, then the > > > applications themselves are functionally deficient and should be > > > fixed. :-) > > > > I'm certainly not going to disagree with you about that, > > but H.323 does not work through NAT without extremely > > sophisticated stateful inspection/rewrite capabilities > > in the NAT, and it will not work, period, if the signaling > > streams are encrypted. For better or worse (and let's > > not get into that), there's a lot of H.323 out there > > and there's going to be much, much more over the > > coming years. RSIP isn't going to work cleanly with > > H.323, either (although there are some rather disgusting > > things you can do in the application about that). > > Agreed. > > Any protocol that wants to have out-of-band control will have > difficulties with existing NATs (without ALGs). Good point. Out-of-band control will require an ALG. No argument there. But, that is not to say you shouldnt think about ALGs. > Thus, by saying "let's > design NAT-friendly protocols", we are effectively ruling out a whole > class of designs and only allow protocols with outgoing TCP connections > (and possibly UDP request-response protocols). I dont think, that is what is being said at all. If you could design applications that can work with NAT enroute, without needing an ALG; that would be great. But, if the applications do require an ALG enroute (as in the case of voice-over-IP which uses out-of-band call-control segnalling), then the application designers should also consider what it takes to build an ALG enroute. This is an issue not just with NATs, but also with firewalls and perhaps security gateways. >In the case of telephony, > it would mean keeping a TCP connection open continuously to some outside > server that would then use that TCP connection to send incoming calls > behind the NAT. > Are you refering to the TCP connection so you can retain the name-to-address mapping? I suspect, you need to do more than just that to permite RTP streams across NAT boundaries. In which case, you are better off monitoring the name-to-address mapping as part of the ALG, instead of relying on a TCP call-control session. > Thus, this is not just a matter of existing software, but fundamentally > restricting protocol design to a very narrow class of design choices, > choices which are basically inappropriate for anything related to > efficient multimedia carriage (real-time multimedia over TCP isn't > exactly a great option). > Please see my comments above. Protocol design will be deemed successful only as they are deployed. It does not harm to think of their impact on NATs, firewalls and security gateways - all of which are already deployed in a large number of locations. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
Re: IP network address assignments/allocations information?
*> *> I'll grant FTP an exemption, it came well before NAT units became *> prevalent (Was there an FTP-over-NCP before The Great IP Deployment?). There certainly was. FTP and Telnet were both ARPANET NCP protocols in use since ~1972. Bob Braden *> However, I do agree that anybody designing a protocol in the last 3-4 *> years *should* have designed it to be firewall and NAT friendly. *> (Yes, I know that can be difficult in practice. I guess that's today's *> "Welcome to Reality"). *> *>Valdis Kletnieks *>Operating Systems Analyst *>Virginia Tech *> *>
RE: IP network address assignments/allocations information?
> If you could design applications that can work with NAT > enroute, without needing an ALG; that would be great. > But, if the applications do require an ALG enroute > (as in the case of voice-over-IP which uses out-of-band > call-control segnalling), then the application designers should also > consider what it takes to build an ALG enroute. The problem of encrypted signaling remains, however. Should you choose to deal with this problem by terminating signaling on the ALG you have to consider the performance implications, as well, which have very real consequences when dealing with timing requirements imposed by interworking with the PSTN, where applicable. Not to mention, of course, key management soup. ALGs are a good solution for many NAT-related problems, but not for all of them. Melinda -- Melinda Shore Member of the Scientific Staff Nokia IP Telephony 127 West State Street Ithaca, NY 14850 +1 607 273 0724 (office) +1 607 275 3610 (fax) +1 607 227 4096 (mobile) [EMAIL PROTECTED]
RE: IP network address assignments/allocations information?
I think the below statement provides important perspective. NAT is not the Antechrist, nor is it salvation. Much of the work on "improving" NAT seems much like "improving" the Band-Aid so it will last for a year, although no one wears one for more than a couple of days! When IPv6 is deployed and everyone's toaster can have its own IP address, I suspect that most folks will be perfectly happy to decommission their NAT boxes. Firewalls are another and likely more significant issue. However, focusing on firewalls narrows the issue considerably; how many corporations are concerned whether their firewalls are Quake-friendly? For those protocols that are of interest to users of firewalls, the necessary work can be done to either build ALGs, figure out tunneling methods, or design firewall-friendly protocols; that work will be driven by a business need, rather than an academic discussion of what "should" work. It's important to know which protocols are broken by NAT and firewalls -- Keith Moore's work on that is very useful. But does each instance of "breakage" represent something that needs to be "fixed"? Part of this problem (NAT) will almost certainly go away; the other part (firewalls) requires at most a subset solution. Maybe we're trying too hard? :-) -- Ian -Original Message- From: Tony Dal Santo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 30, 1999 8:29 AM To: [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? [snip] While NAT is an adequate stopgap solution to IP address dilemmas, in my opinion, it shouldn't be the final solution. [snip]
To address or NAT to address?
At 09:15 30/11/99 -0500, Daniel Senie wrote: >> In any event, I've always personally been of the opinion that >> if applications don't work in the face of NAT, then the >> applications themselves are functionally deficient and should be >> fixed. :-) > >Indeed. While some in the IETF have stomped their feet and railed about >how bad NAT is architecturally (something I suspect most folks concede) >they've somehow believed it would be possible to offer a better solution >and get NAT eliminated before it's widely deployed. Reality: it's >extremely widely deployed, and must be taken into consideration when >designing protocols. Those, like Real, who find ways to make their >protocols work with NAT clearly will do better than those who do not. [...] >We are at a crossroads where architectural purity has intersected >operational reality. Some similar thoughts have been stirring in my sluggish brain... It seems to me that we may be able to recapture some aspects of end-to-end transparency at the application level if addressing issues are focused on host FQDNs, rather than IP addresses. - Application protocols that transfer addressing information as FQDNs rather than IP addresses don't get messed up by NATs. - FQDNs are (or can be) relatively stable over time, even if the IP address to which it refers may change. - FQDNs form an "address space" that can, for practical purposes, grow indefinitely. I don't claim this is a solution to all problems, just suggesting that application protocol design has a part to play. #g Graham Klyne ([EMAIL PROTECTED])
RE: IP network address assignments/allocations information?
Bottom line, NAT or changing destination addresses on the fly breaks the end-to-end nature of Internetworking. This is true not only for IP, for for other protocols as well. Some may recall older DECNET IV networks that exceeded the maximim ~65K nodes. We had to come up with a scheme to make that work and it was ugly. Even though we are not in the same situation as DECNET IV (we still have a lot of addresses available), we are (for other reasons already discussed) stuck with this NAT situation for the foreseeable future. It does absolutely no good to complain about the state of the world. It is what it is and all the complaining by the IETF won't change it. It would do a lot of good to find a way to dig ourselves out of this situation. The Internet isn't going to stop growing and there will be future applications that require or desire a heck of a lot of public IP addresses. Other future applications may compromise some useful feature to be "NAT Friendly". This is not a good thing. So we need to find a way to bridge ourselves to a new addressing architecture. IPv6 is one such architecture, but getting there is very, very difficult. So we need some alternative solutions in the meantime. And we need to continue to reassess how we might transition to such an architecture. The Internet will not stop changing so we need to be fluid in our transition schemes. The IETF, IAB and IRTF are struggling with this and there is no neat short term fix. The NAT WG and the NGTRANS WG are a couple of places (I'm sure there are others) where folks are trying to help things along and we would appreciate your support. P.S. Let me take this public moment to ask (beg!) for review of draft-ietf-nat-protocol-complications-01.txt which I'm editing. If you know of any particular protocol that has difficulty with basic Network Address Translation, please send me the info in the format of the above draft. - Matt Holdrege - NAT WG co-chair
Re: To address or NAT to address?
> At 09:15 30/11/99 -0500, Daniel Senie wrote: > > >> In any event, I've always personally been of the opinion that > >> if applications don't work in the face of NAT, then the > >> applications themselves are functionally deficient and should be > >> fixed. :-) > > > >Indeed. While some in the IETF have stomped their feet and railed about > >how bad NAT is architecturally (something I suspect most folks concede) > >they've somehow believed it would be possible to offer a better solution > >and get NAT eliminated before it's widely deployed. Reality: it's > >extremely widely deployed, and must be taken into consideration when > >designing protocols. Those, like Real, who find ways to make their > >protocols work with NAT clearly will do better than those who do not. > > [...] > >We are at a crossroads where architectural purity has intersected > >operational reality. > > Some similar thoughts have been stirring in my sluggish brain... > > It seems to me that we may be able to recapture some aspects of end-to-end > transparency at the application level if addressing issues are focused on > host FQDNs, rather than IP addresses. > > - Application protocols that transfer addressing information as FQDNs > rather than IP addresses don't get messed up by NATs. > > - FQDNs are (or can be) relatively stable over time, even if the IP address > to which it refers may change. > > - FQDNs form an "address space" that can, for practical purposes, grow > indefinitely. > > I don't claim this is a solution to all problems, just suggesting that > application protocol design has a part to play. > > #g > > > Graham Klyne > ([EMAIL PROTECTED]) > FQDN's cause problems with security. DNS is not secure and it is desireable to avoid contacting the DNS to establish whether or not a given set of credentials are reliable for a given connection. Authentication information is frequently encrypted and it is not possible nor desireable for the NAT to be able to much with its contents. Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2 The Kermit Project * Columbia University 612 West 115th St #716 * New York, NY * 10025 http://www.kermit-project.org/k95.html * [EMAIL PROTECTED]
Re: To address or NAT to address?
> It seems to me that we may be able to recapture some aspects of end-to-end > transparency at the application level if addressing issues are focused on > host FQDNs, rather than IP addresses. Forget about it. Many of the same folks doing NAT also do a two-faced DNS which hides most of their names from the outside. So a host inside such a site has no more idea of its global name than of its global address.
Re: To address or NAT to address?
--- Matt Crawford <[EMAIL PROTECTED]> wrote: > > It seems to me that we may be able to recapture some aspects of end-to-end > > transparency at the application level if addressing issues are focused on > > host FQDNs, rather than IP addresses. > > Forget about it. Many of the same folks doing NAT also do a > two-faced DNS which hides most of their names from the outside. So a > host inside such a site has no more idea of its global name than of > its global address. > > Its a different problem if you want to hide from outside access. That is independent of whether you use IP address or FQDN to label the host. regards, suresh __ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com
RE: IP network address assignments/allocations information?
Title: RE: IP network address assignments/allocations information? Valdis, This is the kind of BS that keeps these debates running. NAT problems exist anytime a connection originates on the public side and there is not a preexisting clear mapping to the private side. I didn't pick on Real Player at random. My house is connected through a NATPT, and my wife couldn't get a video stream opened back to her machine. If I had pre-mapped those ports to her machine, then my son would not have been able to get them on his. If I pre-map them, all the bogus security arguments about NAT become invalid. Clearly NAT has allowed me to create an environment which is not sustainable, but at least I know enough to know what the problem is, the average guy on the street doesn't stand a chance. Yes there are problems with protocols that carry addresses, but ignoring encrypted traffic that really amounts to acquiring and synchronizing deployments of ALGs. In the early stages this doesn't sound hard, but will vendors be willing to add new ALGs to 3 year old NAT hardware? Will they create an update process that is easy enough for the average user? Will the average user be able to figure out which NAT needs updating, and what version it needs? Add the fact that people want to encrypt their traffic for privacy, and one wonders why so much effort is spent on this dead-end technology. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 30, 1999 12:05 AM To: Ian King Cc: [EMAIL PROTECTED] Subject: Re: IP network address assignments/allocations information? On Mon, 29 Nov 1999 22:45:17 PST, Ian King said: > any "lack" because of it. I don't play UDP-based games or employ any of the > other relatively new protocols that are so sensitive to end-to-end-ness > (should they be? was that a valid assumption?), so a NAT is a great solution Well.. Urm... TCP and UDP both assume that one endpoint is talking directly in real time to another endpoint. The NAT problems only start when the protocol carries IP address/port information (such as the FTP 'PORT' command), and the NAT isn't aware of that protocol's translation requirements (If you see *this* at offset 80 of *that* packet, smash it to read *foobar* instead). I'll grant FTP an exemption, it came well before NAT units became prevalent (Was there an FTP-over-NCP before The Great IP Deployment?). However, I do agree that anybody designing a protocol in the last 3-4 years *should* have designed it to be firewall and NAT friendly. (Yes, I know that can be difficult in practice. I guess that's today's "Welcome to Reality"). Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: IP network address assignments/allocations information?
At 11:28 -0500 11/30/99, Tony Dal Santo wrote: >Valdis Kletnieks wrote: > >> However, I do agree that anybody designing a protocol in the last 3-4 >> years *should* have designed it to be firewall and NAT friendly. >> (Yes, I know that can be difficult in practice. I guess that's today's >> "Welcome to Reality"). > >Daniel Senie wrote: > >> > In any event, I've always personally been of the opinion that >> > if applications don't work in the face of NAT, then the >> > applications themselves are functionally deficient and should be >> > fixed. :-) >> >> ...and [NAT] must be taken into consideration when designing protocols. >> >>New protocols should, in my opinion, provide descriptions >> of how they work or don't work with NAT. If there is a reason why they >> aren't going to work (carriage of port or address information), a >> description of how to build an Application Layer Gateway (ALG) should be >> provided. > >I really think trying to make everything "NAT aware" or "NAT friendly" >is spending effort heading in the wrong direction. While I am forced to >concede the wide deployment of NAT technology, I believe the problems it >solves (or at least claims to) are better solved by other means, or >require different solutions. The problem is not to make applications "NAT aware" or "NAT friendly". The problem is to make applications "IP address unaware". What is an application doing exchanging and using names for things 2 layers below it? Sounds like a design for trouble if I ever heard of one. > >Protocols are difficult enough to get right. I'd rather see time spent >developing good algorithms than NAT compatibility. What about future >NAT "features"? Are protocol designers supposed to guess at what new >convolutions will be dreamt up? You are absolutely right. Time should be spent developing "good algorithms" which is common "good architecture". What NAT does is just another form of the same thing that X.25, ATM, and MPLS do with different identifiers. It is not bad algorithm there nor bad architecture. (I presume since there are so many ATM and MPLS supporters (X.25 seems to be gone for the most part, thank god.)) How does an application exchanging and using IP addresses qualify as good algorithms or good architecture. > >About the only serious issues NAT really addresses are the perceived IP >address shortage, and being forced to renumber when changing ISPs. As >for the shortage, this thread seems to indicate there isn't a real firm >idea of how many addresses are actually being used. Have all the minimally >used class A and B addresses been reclaimed? I suspect not, which tells >me the immediate shortage can't be that great. And if switching to IPv6 >in the long term has problems, effort should be spent solving those. > >As for being forced to renumber (can't take your address with you), No, you can't. If you did it would no longer be an address, but only a name. And then of no use to routing. >is this really a technical routing problem (tables too large), or more It is really a technical problem. >of an economic/political/turf issue? While renumbering can be painful, Only trying to keep the address is an economic/political/turf issue. >DNS should hide the change, and things like DHCP can make it less so. >Besides it shouldn't be too difficult for small organizations, and large >ones should be able to take their address as they move. Now you are on to the beginning of a good solution. > >While NAT is an adequate stopgap solution to IP address dilemmas, in my >opinion, it shouldn't be the final solution. > >> We are at a crossroads where architectural purity has intersected >> operational reality. > >Let's not continue down the wrong road. Correct. Lets get an application name space so we don't need to worry about it. Take care, John
RE: IP network address assignments/allocations information?
Tony, I wouldn't be so quick to characterize NAT as a "dead-end" technology. Personally, I think NAT is just fine, but I'm a self-proclaimed cynic and also consider myself somewhat of a pragmatist. In any event, it works for me, but I could certainly be in the minority. I think most of the hoopla surrounding NAT's revolve around engineering purism. And I agree that statements that assert that NAT's provide some sort of "security through obscurity" are complete red herrings. Having said that, I ask you: What do you foresee as a realistic IPv6 transition plan? Dual stacks? I don't see it happening, to tell you the truth. (Maybe this 6-in-4 stuff will actually help here.) The truth is that NAT's allow organizations to deploy machines in networks which otherwise would not have enough address space. To say that NAT's are unequivocally evil is unfair, methinks. - paul At 01:37 PM 11/30/1999 -0800, Tony Hain (Exchange) wrote: >Yes there are problems with protocols that carry addresses, but ignoring >encrypted traffic that really amounts to acquiring and synchronizing >deployments of ALGs. In the early stages this doesn't sound hard, but will >vendors be willing to add new ALGs to 3 year old NAT hardware? Will they >create an update process that is easy enough for the average user? Will >the average user be able to figure out which NAT needs updating, and what >version it needs? Add the fact that people want to encrypt their traffic >for privacy, and one wonders why so much effort is spent on this dead-end >technology.
Re: IP network address assignments/allocations information?
John Day <[EMAIL PROTECTED]> writes: > > Correct. Lets get an application name space so we don't need to worry > about it. > Please gods below, not more ASN.1 -- Mark Atwood | [EMAIL PROTECTED] | http://www.pobox.com/~mra |
Re: IP network address assignments/allocations information?
On Tue, 30 Nov 1999 13:37:33 PST, "Tony Hain (Exchange)" said: > This is the kind of BS that keeps these debates running. NAT problems exist > anytime a connection originates on the public side and there is not a > preexisting clear mapping to the private side. I didn't pick on Real Player I said: > Well.. Urm... TCP and UDP both assume that one endpoint is talking > directly in real time to another endpoint. The NAT problems only > start when the protocol carries IP address/port information (such > as the FTP 'PORT' command), and the NAT isn't aware of that protocol's > translation requirements (If you see *this* at offset 80 of *that* > packet, smash it to read *foobar* instead). I think we're actually saying the same thing here, and are violently in agreement, from different viewpoints. A 'pre-existing clear mapping' is what the NAT needs in order to do the datastream manipulations needed. Of course, if there exists such a mapping, but your NAT is older or for other reasons doesn't understand/implement it, you're still stuck. I meant "the problems only start" in the context of the breakage a NAT renders on a single connection that is assuming it's able to make an unmangled, unmodified end-to-end connection. If the NAT is able to handle the translation, the connection still suceeds. If the NAT doesn't do it, the connection loses. As Keith Moore pointed out in http://www.cs.utk.edu/~moore/what-nats-break.html there are other contexts *outside* that context that NAT has an impact on... -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
FAQ: The IETF+Censored list
The IETF+Censored mailing list At times, the IETF list is subject to debates that have little to do with the purposes for which the IETF list was created. Some people would appreciate a "quieter" forum for the relevant debates that take place, but the IETF's policy of openness has so far prevented the IETF from imposing any censorship policy on the [EMAIL PROTECTED] list. To give people an alternative, there is a list called "[EMAIL PROTECTED]". This list is a sublist (that is, it gets the same messages as) the open IETF discussion list. However, this list will not forward all messages; in particular, the filters have been set so that persons and discussions that are, in the view of Harald Alvestrand, irrelevant to the IETF list are not forwarded. Because this filter is automated, the criteria include: * Well known troublemakers * Well known crosspostings * Subjects that have led to recent non-conclusive exchanges * Some ways to say "unsubscribe" To join the list, [1]send the word "subscribe" in the BODY of a message to [EMAIL PROTECTED] (the URL here is an RFC 2368 mailto URL that does the Right Thing). For fun, there is a special list for the rejected messages: [EMAIL PROTECTED] - subscribe in the same fashion, by [2]mail to [EMAIL PROTECTED] By public request, the current set of filters are listed at [3]http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters Some statistics on postings, which may be useful in getting a perspective on the effects of the filter, are at [4]posting-counts.html (started Oct 14, 1998). This page is http://www.alvestrand.no/ietf+censored.html, and is posted monthly in text form to [EMAIL PROTECTED] _ Harald Tveit Alvestrand [5]< [EMAIL PROTECTED]> References 1. mailto:[EMAIL PROTECTED]?body=subscribe 2. mailto:[EMAIL PROTECTED]?body=subscribe 3. http://www.alvestrand.no/cgi-bin/hta/ietf+censored-filters 4. http://www.alvestrand.no/posting-counts.html 5. mailto:[EMAIL PROTECTED]
No Subject
unsubscribe
Unsubsribe
Unsubsribe Julio Novomisky Abre gratis una cuenta de email en StarMedia Mail. El mejor servicio de email gratis de toda Latinoamérica. http://www.starmedia.com
NomCom Artifacts
Hello: Just in case interested, there are some NomCom related artifacts (1992-2000) at: http://gnIETF.vlsm.org/#NomCom regards, -- -- Rahmat M. Samik-Ibrahim --- -- OSI: Same day service in a nanosecond world --- Interop T-shirt(vJ)
Re: To address or NAT to address?
> It seems to me that we may be able to recapture some aspects of end-to-end > transparency at the application level if addressing issues are focused on > host FQDNs, rather than IP addresses. this works to some extent. it specifically doesn't work for applications that need to rendezvous with specific processes on specific hosts (or which need to use specific interface addresses, say for performance reasons), since a single FQDN often corresponds to multiple hosts. (or, less frequently, to multiple addresses on a single host). note also that DNS is often slow, and seems less reliable than IP. by increasing the reliance on DNS you increase the probability of failure.
Re: IP network address assignments/allocations information?
At 18:12 -0500 11/30/99, Mark Atwood wrote: >John Day <[EMAIL PROTECTED]> writes: >> >> Correct. Lets get an application name space so we don't need to worry >> about it. >> > >Please gods below, not more ASN.1 What a strange reaction!? What does an arcane syntax notation have to do with Shoch's observation that there are 3 kinds of addresses: applications, hosts, and routes? What have you been smoking? > >-- >Mark Atwood | >[EMAIL PROTECTED] | >http://www.pobox.com/~mra |
Re: IP network address assignments/allocations information?
*> *> The problem is not to make applications "NAT aware" or "NAT friendly". The *> problem is to make applications "IP address unaware". What is an *> application doing exchanging and using names for things 2 layers below it? *> Sounds like a design for trouble if I ever heard of one. I don't believe this argument, John. The IP address is (part of) the transport layer end point address, something that an application can reasonably be expected to know about in the existing Internet architecture. Bob Braden
Crypto Advocate Under FBI Investigation (For Treason)
Crypto Advocate Under FBI Investigation Windows NT Magazine Tuesday, November 30, 1999 - We recently published a story regarding cryptography and IPv6, where somseone at the Department of Justice accused Scott Bradner, http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=167&TB=news Internet Engineering Task Force (IETF) area coordinator, of an anti-social act by trying to get encryption inserted into the new protocol. Later, at an IETF meeting where votes were taken for IPv6 encryption inclusion, Fore System's Brian Rosen brazenly claimed that regardless of any encryption inclusion, Fore systems would proceed by including back doors http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=177&TB=news into any included encryption technology. But the harrassment of the IETF doesn't stop there. Just how far will our federal government go towards controlling strong encryption? Apparently, very far. And this isn't a new effort by any means. We learned that William Allen Simpson, a Detroit-based computer consultant who was on the IETF staff, has been investigated by the federal government for treason charges. Simpson was the person that argued loudly for encryption to be included in the PPP protocol when it was still in design phases. That push landed Simpson in hot whatever with federal officials. Simpson learned through friends that he was under investigation for treason -- the FBI had been interviewing his friends and associates. Simpson obtained 54 pages of documents from the government under the Freedom of Information act, however the documents were heavily censored, including the bureau's basis for the investigation. According to a ZDTV report, http://www.zdnet.com/zdtv/cybercrime/chaostheory/story/0,3700,2398590,00.html Simpson did learn that the FBI had accused him of "challenging authority and laws that may impinge upon his activities." Wait a second! Isn't that part of what the Constitution is all about--the means to peacefully object to the laws of the land? I think so. And if that's true, then that certainly positions the FBI in a bad light since it would appear their actions are counter to the Consitutional rights. It not against the law to develop strong cryptography, but it is against the law to export that technology outside of proper governmental controls. The PPP protocol did not have encryption at the time--it was only a suggested inclusion--so why investigate a person for doing something completely legal? The IETF is an open public standards body that conducts its business in clear public view. They help stear standards that better ensure compatibility and interoperability. So why would the FBI investigate an IETF member just because that person suggested in a public meeting that strong encryption be included in a standard wide-spread protocol such as PPP? Source - http://www.ntsecurity.net/go/2c.asp?f=/news.asp?IDF=186&TB=news Not for commercial use. Solely to be fairly used for the educational purposes of research and open discussion. Jai Maharaj [EMAIL PROTECTED] Om Shanti
Re: To address or NAT to address?
> DNS is not secure True for now. Of course, this is something DNSSEC is supposed to address. > Authentication information is frequently encrypted Not in the case of DNSSEC. Rgds, -drc
No Subject
unsubscribe
RE: IP network address assignments/allocations information?
> >> However, I do agree that anybody designing a protocol in > the last 3-4 > >> years *should* have designed it to be firewall and NAT friendly. > >> (Yes, I know that can be difficult in practice. I guess > that's today's > >> "Welcome to Reality"). > > > >> > In any event, I've always personally been of the opinion that > >> > if applications don't work in the face of NAT, then the > >> > applications themselves are functionally deficient and should be > >> > fixed. :-) > >> > >> ...and [NAT] must be taken into consideration when > designing protocols. > >> > >>New protocols should, in my opinion, > provide descriptions > >> of how they work or don't work with NAT. If there is a > reason why they > >> aren't going to work (carriage of port or address information), a > >> description of how to build an Application Layer Gateway > (ALG) should be > >> provided. Could someone please take a look at draft-welzl-ptp-01.txt, and tell me how this protocol could be turned NAT friendly. I doubt that it's possible. I expect some people to yell "bad design" then; but how would you provide this functionality? Certain things simply can't be done if we strictly stick with an end2end point of view - and I would of course be glad if someone tells me I'm wrong and comes up with a solution:) Regards, Michael Welzl
Re: Crypto Advocate Under FBI Investigation (For Treason)
On Tue, 30 Nov 1999, Dr. Jai Maharaj wrote: > We learned that > William Allen Simpson, a Detroit-based computer > consultant who was on the IETF staff, has been > investigated by the federal government for treason > charges. Having been one of those interviewed by the FBI WRT W.A. Simpson, and having been party to the PPP activity at the time, I think I can probably comment with a bit of authority. Frankly, Bill brought the investigation upon himself. > Simpson was the person that argued loudly for > encryption to be included in the PPP protocol when it was > still in design phases. He argued no more loudly or softly than did I or a number of other people working on PPP at the time. We were not investigated so clearly the reason was NOT because he advocated encryption in PPP. > That push landed Simpson in hot > whatever with federal officials. Simpson learned through > friends that he was under investigation for treason -- > the FBI had been interviewing his friends and associates. Treason is a strong word. Yes he was investigated for commission of a crime but no charges were ever brought. During my interview I asked the FBI agent what had prompted the investigation of Mr. Simpson. The agent stated that the FBI had received reports that Bill Simpson had publically stated that he had actually exported encryption technology and they were required to investigate. He also stated that it appeared to be a non-issue but that policy required the investigation. He surmised that the report had come from someone who just wanted to cause difficulty for Mr. Simpson. > Simpson obtained 54 pages of documents from the > government under the Freedom of Information act, however > the documents were heavily censored, including the > bureau's basis for the investigation. According to a ZDTV > report, > > http://www.zdnet.com/zdtv/cybercrime/chaostheory/story/0,3700,2398590,00.html > > Simpson did learn that the FBI had accused him of > "challenging authority and laws that may impinge upon his > activities." Surprise, surprise! When you make a statement like, "no one can stop me from exporting encryption software," you leave yourself rather open to having someone report you for breaking the law. All someone had to say to the FBI was, "Bill Simpson boasted that he had exported restricted encryption software from the country." Whether accurate or not, this combined with his other public statements was sufficient to trigger a routine investigation. It doesn't appear to me that the FBI was on a witch hunt. > Wait a second! Isn't that part of what the Constitution > is all about--the means to peacefully object to the laws > of the land? I think so. And if that's true, then that > certainly positions the FBI in a bad light since it would > appear their actions are counter to the Consitutional > rights. Pardon me but, horse hocky! We are not talking about objecting to the laws but rather how the FBI reacted to a report of a crime. Even tho' they were pretty sure that they had been handed a red herring they were still required to investigate. Makes sense to me. > It not against the law to develop strong > cryptography, but it is against the law to export that > technology outside of proper governmental controls. The > PPP protocol did not have encryption at the time--it was > only a suggested inclusion--so why investigate a person > for doing something completely legal? But that is not WHY he was investigated. Bill was investigated because someone reported that he had committed a crime. He reinforced the impression by making indiscrete, public comments. His antisocial behavior at the IETF has made him enemies here and I suspect that someone who disliked him saw the opportunity to take advantage of Mr. Simpson's indiscretion in order to cause him trouble. > The IETF is an open public standards body that conducts > its business in clear public view. They help stear > standards that better ensure compatibility and > interoperability. So why would the FBI investigate an > IETF member just because that person suggested in a > public meeting that strong encryption be included in a > standard wide-spread protocol such as PPP? It would do you well to do a bit more research into the events before trotting Mr. Simpson out as the party wronged by the federal authorities. Mr. Simpson may have been wronged but it was by someone a bit closer to home, not by the FBI. And before any of you get any ideas, no, it wasn't me. > Not for commercial use. Solely to be fairly used for > the educational purposes of research and open discussion. Fairly? This seems like yellow journalism to me. > Jai Maharaj > [EMAIL PROTECTED] > Om Shanti Brian Lloyd [EMAIL PROTECTED] +1.530.676.6513
