Re: NATs *ARE* evil!
[EMAIL PROTECTED] (Keith Moore) wrote on 19.12.00 in <[EMAIL PROTECTED]>: > agreed, *provided* there is a fast and reliable service for mapping > between one kind of identity and another. arguments of the form > "separate identities are better" tend to gloss over the difficulty > of providing an adequate mapping service. > > (Hint: DNS is neither sufficiently fast nor sufficiently reliable) Hmm, can't resist putting on my brain-storming hat here ... Let's see: assume we have a map from "who" (endpoint identifier) to "where" (topology descriptor). There will probably be a seconf map mapping "where" to "how" (routing info); this second will certainly be locally different - essentially traditional routing. Hmm. If this is to include multi-homing support, the who-where map needs to be 1:N. There's a problem with secure updating. I can connect via several different ISPs, just like a multi-homed host, so preferrably my endpoint identifier would not "belong" to those ISPs but to me. But then I don't know the topology information for that map any better than "I just connected to ISP X". And if that ISP isn't known to all routers globally (and at least one of them certainly isn't, doesn't even have an AS), then that information is not sufficient. So: I need to update the map to say "I just connected to system X", and there needs to be a secondary map (unless of course the first one can be reused) that says "system X is in turn connected to system Y, which is connected to globally known system Z". (Except all of those really are 1:N, not 1:1.) Now when I want to send a packet, I need to do the equivalent to ARP - query the map for topology information for the endpoint identifier of the other side, resolve the next hop via local routing information, and send it on it's way to the next hop. And here it gets interesting again. ARP just sends out a broadcast packet. We certainly don't want anything like that on the global Internet. So the packet needs to go to a specific destination, and for that to not create a bootstrapping problem, we'd need to have well-known ways to reach a local proxy. Proxy. Hmm. Caching would certainly be necessary. How long? Until someone on the route says "I can't deliver this"? What about routers in the middle, how do they find out? Where does the map live? We'd need to distribute the storage according to end-point ranges, I think, which means we get endpoint registries. Which probably need to be globally known (i.e. use special routing table entries) at least for the highest level, assuming there are several levels. (Why am I thinking EUI-64?) This looks possible, but I can see a great many new headaches in actually getting it operable. > the other problem with separating the layers is that the ability to > drill down through layers is essential for diagnostic purposes, > for tracking down miscreants, and to allow prototyping new kinds > of services that need to operate with knowledge of layer 3. So > we will always have a need for some kinds of "applications" to > operate with knowledge of network addresses. That seems entirely possible with something like the above. MfG Kai
Re: NATs *ARE* evil!
> thank you, I think you've advertised this draft quite adequately for the > time being. I'm quite willing to look at it, but there are numerous Thanks! now I will relax and go home :) > every possible alternative architecture to conclude that (a) most or all > of these identifiers are necessary, and (b) reserving space for each > one separately, and maintaining all of the mappings between them, > would be onerous. But before I go: Condition (b) presumes on possible alternative architectures. My favourite example is the parallel line axiom - in retrospect, it was *because* it was an axiom that we ended up having two sets of alternative geometries, elliptic and hyperbolic, one of which (Riemannian = elliptic) became the basis of general relativity. Currently, it looks like (b) is axiomatic, but I already break it, and I'm sure the younger, smarter generations will think of new ways we can't begin to imagine. happy holidays, -p.
Re: NATs *ARE* evil!
> > IMHO what we need to change is the *implicit* association between > > "host" related identifiers and "network topology" related identifiers - > > so that coders treat them as separate entities, and provide a way > > for the two to be different at the IP layer - while still allowing > > the optimization to take place where it makes sense. then you > > only need to maintain the mapping for the case where the identifiers > > are different. > > > > I'm still waiting for folks to see this "overloading" as a design compromise > > A fundamentally different approach that does achieve this separation > is described in draft-guruprasad-addressless-internet-00.txt. thank you, I think you've advertised this draft quite adequately for the time being. I'm quite willing to look at it, but there are numerous other drafts that are also on my list. > > rather than a pure evil. not overloading at all would be even more evil. > > You don't have adequate grounds for the second statement unless you can > formally establish that you have considered all *possible* alternative > architectures. I was referring to the set of identifiers I mentioned in my earlier message, all of which are IP addresses, or contain IP addresses, in the current Internet architecture. And no, I don't have to consider every possible alternative architecture to conclude that (a) most or all of these identifiers are necessary, and (b) reserving space for each one separately, and maintaining all of the mappings between them, would be onerous. Keith
Re: NATs *ARE* evil!
> IMHO what we need to change is the *implicit* association between > "host" related identifiers and "network topology" related identifiers - > so that coders treat them as separate entities, and provide a way > for the two to be different at the IP layer - while still allowing > the optimization to take place where it makes sense. then you > only need to maintain the mapping for the case where the identifiers > are different. > > I'm still waiting for folks to see this "overloading" as a design compromise A fundamentally different approach that does achieve this separation is described in draft-guruprasad-addressless-internet-00.txt. > rather than a pure evil. not overloading at all would be even more evil. You don't have adequate grounds for the second statement unless you can formally establish that you have considered all *possible* alternative architectures. In other words, experiences with Nimrod or early-day relative addressing, or with UUCP, ATM, SNA, etc, cannot be adequate foundation. That also excludes potential knocking down of my I-D, but you evidently haven't read it anyway. > as it happens, I'm in the NSRG. but I also think it's useful to have these Especially where we need to be more careful in positing opinions, lest we prematurely block out good solutions because of such prejudices and shun away "newbies" proposing them (to borrow from another thread!). One might recall that astronomers had a similar complexity problem with the celestial routing of planets at one time, and the solution, taken for granted today (but not taught in all schools!), contradicted most educated and carefully conservative opinions. I submit a more open attitude might be healthier for the Internet and my I-D :-) -p.
Re: NATs *ARE* evil!
> | yeah, I really wish those who are trying to improve network routing > | (an endeavor which I respect in principle) would consider that > | applications really do need stable endpoint identifiers which > | are globally scoped, exchangable with other applications, and > | reliably usable from anywhere to reach the process listening > | to that endpoint. > > Understood, and that was probably never a non-goal. > > The problem about overloading topology and identity is that it's hard > to think about separating the overloaded meanings from one another. this might be in part because there are several different kinds of overloading going on. IP addresses are used as, or as part of: network topology locations, subnet identifiers, network interface identifiers, host identifiers, service identifiers (groups of hosts performing a common service), and connection endpoint identifiers. (and I've probably left out one or two uses). to separate them all would impose far too much overhead. even to separate "host" related things from "network" related things imposes significant overhead both in bandwidth and in maintaining the mappings from one to the other. > Worrying that breakage can happen is perfectly understandable from both the > perspective of someone needing to work with the "where" (topology locator) > and someone needing to work with the "who" (identity name), since > in a large, complicated network, the overloading really can be > a zero-sum game. A proper separation (or initial non-overloaded design), > however, can satisfy both namespace needs. I'm not sure there is such a thing as "proper". overloading of IP address to mean both "host" and "network" was a useful optimization in the days when bandwidth was scarce, links were slow, hosts were stationary, the network didn't change topology often, and the net was small (and thus easier to route). overloading of IP addresses is *still* useful because many of the above conditions still exist, and will continue to exist, for large portions of the network. At the same time the overloading gets in the way in the (increasing number of) cases where some of the above conditions are violated. IMHO what we need to change is the *implicit* association between "host" related identifiers and "network topology" related identifiers - so that coders treat them as separate entities, and provide a way for the two to be different at the IP layer - while still allowing the optimization to take place where it makes sense. then you only need to maintain the mapping for the case where the identifiers are different. I'm still waiting for folks to see this "overloading" as a design compromise rather than a pure evil. not overloading at all would be even more evil. what we need now is a different compromise, rather than a design which is "proper" according to some idealistic principles. > Incidentally, the IRTF's NSRG (http://www.irtf.org/charters/namespace.html) > exists to study this problem, and there are a number of interesting ideas > being developed there that will meet your wishes expressed above. as it happens, I'm in the NSRG. but I also think it's useful to have these issues aired (briefly) on the wider IETF list. Keith
Re: NATs *ARE* evil!
Keith Moore writes: | yeah, I really wish those who are trying to improve network routing | (an endeavor which I respect in principle) would consider that | applications really do need stable endpoint identifiers which | are globally scoped, exchangable with other applications, and | reliably usable from anywhere to reach the process listening | to that endpoint. Understood, and that was probably never a non-goal. The problem about overloading topology and identity is that it's hard to think about separating the overloaded meanings from one another. Worrying that breakage can happen is perfectly understandable from both the perspective of someone needing to work with the "where" (topology locator) and someone needing to work with the "who" (identity name), since in a large, complicated network, the overloading really can be a zero-sum game. A proper separation (or initial non-overloaded design), however, can satisfy both namespace needs. Incidentally, the IRTF's NSRG (http://www.irtf.org/charters/namespace.html) exists to study this problem, and there are a number of interesting ideas being developed there that will meet your wishes expressed above. Sean.
Re: NATs *ARE* evil!
{I had written:}
> | from label switching, so what I'm suggesting is that we take the bull by
> | the horns once and for all and run MPLS over IP instead of under it...
>
> an mplsd-like tag fits neatly in the first half of an ipvsux destination
> address, although there are other places in the vsux header you can put
> tag bits if you're inclined to do so for stacking reasons or whatnot.
> ...
> this has all the same problems of NAT where there is no end-to-end
> namespace that is not TOPOLOGICAL in nature separate from but convertible
> between a namespace populated with globally unique IDENTITY names.
> (where that namespace can mean single hosts or service locations or whatever,
> but not two or more of these things simultaneously! overloading bad.)
>
> Sean.
The NATty problems also go away when the theme is completed with the
globally unique etc. namespace, with a different topology (but yet
a spanning tree by definition), and the conversion is formally handled
by automatic translation using a context-free attribute grammar distributed
en route, so that the label switched path is synthesised e2e without
having to return addresses to the client application. I.e. no "overloading".
The final architecture one then gets would be that described in
draft-guruprasad-addressless-internet-00.txt
-p.
Re: NATs *ARE* evil!
yeah, I really wish those who are trying to improve network routing (an endeavor which I respect in principle) would consider that applications really do need stable endpoint identifiers which are globally scoped, exchangable with other applications, and reliably usable from anywhere to reach the process listening to that endpoint. Keith
Re: NATs *ARE* evil!
At 02:11 AM 12/22/00 +0100, Sean Doran wrote: >an mplsd-like tag fits neatly in the first half of an ipvsux destination >address, although there are other places in the vsux header you can put >tag bits if you're inclined to do so for stacking reasons or whatnot. actually, I should think the flow label field might be pressed into service...
Re: NATs *ARE* evil!
| from label switching, so what I'm suggesting is that we take the bull by | the horns once and for all and run MPLS over IP instead of under it... an mplsd-like tag fits neatly in the first half of an ipvsux destination address, although there are other places in the vsux header you can put tag bits if you're inclined to do so for stacking reasons or whatnot. one nicety of stuffing the tag into the vsux header (or even *below* the vsux header, as payload) is that you can forward through v6 networks such as they exist, without them also simultaneously having to be MPLSd. that is, you abstract a collection of vsux-but-not-mplsd routers into a connection between two lsrs (with likely hit to reservation based control plane). in other words, a particularly useful mplsd label is one that causes the next-hop lsr to generate a packet that is relevant within a non-mplsd network with its own topological namespace. that is, generate an IPvsux or ordinary IP packet out an interface such that things on the other side of the interface can route back to it. that is, tag "xyzi" means be a NAT and send packet out IP/IPvsux interface "i". this has all the same problems of NAT where there is no end-to-end namespace that is not TOPOLOGICAL in nature separate from but convertible between a namespace populated with globally unique IDENTITY names. (where that namespace can mean single hosts or service locations or whatever, but not two or more of these things simultaneously! overloading bad.) Sean.
Re: NATs *ARE* evil!
At 04:41 PM 12/21/00 -0800, Fred Baker wrote: >Unfortunately, the world is not internet-attached. Western Europe is, the >US and Canada are, Australia is, Taiwan has Internet in every public >library (I'm told). It comprises populations in the 1 billion person >ballpark. There are some pretty large swaths of people in Eastern Europe, >Asia, and Africa that are not connected and should be. before I get flamed, let me hasten in with - I left out a lot of countries that have some level of internet attachment. My point is not that "your favorite country has no attachment", but that "there are relatively few countries that have essentially pervasive attachment". If you still think I'm missing your favorite country, flame me privately :^)
Re: NATs *ARE* evil!
At 02:54 PM 12/14/00 -0500, Tony Dal Santo wrote: >What exactly is the state of the IPv4 "address pool"? I realize there is >a PERCEIVED shortage, and this is usually the main motivation for NAT. >But is there a real shortage? Are "reasonable" requests for addresses >being denied? The way I understand it (which could easily be out of date) is that about 45% of the address pool has been delegated, and about 25.21% is currently being advertised. The unicast address pool, what we once called the class A, class B, and class C address pools, represents 7/8 of the IP Addresses: the remainder are divided among the multicast (class D) and experimental (class E) address space. So the bottom line is that we have delegated out a touch over half the usable unicast IP Address space. The way we are using that is, in many places, interconnecting NAT translation points - the use of private address space hides the real usage, and we have no really good way to estimate it. If we start going for non-client-server protocols - voice on IP - in a big way (and I am told that some of the world's largest telephone carriers have plans in place to convert national and international telco backbones to VoIP over the coming 3-5 years), that means that these devices will need to be addressable from outside their domains, which means those people will find themselves needing a non-NAT'd address. Implications are largely speculative, but have the option of being non-pretty. Next question, not usually discussed, is how much of the world as yet doesn't have IP Addresses allocated to it and would like to. I think it is fair to say that the world is convinced that IP connectivity is very important. I have heard ministers of telecom from dirt-poor African countries discuss how wonderful it would be to have so much free capital laying around that they could "put a telephone into each village." Those same ministers are doing whatever it takes to ensure that their countries are on the Internet. Unfortunately, the world is not internet-attached. Western Europe is, the US and Canada are, Australia is, Taiwan has Internet in every public library (I'm told). It comprises populations in the 1 billion person ballpark. There are some pretty large swaths of people in Eastern Europe, Asia, and Africa that are not connected and should be. If 25% of the address space is what we need for the part connected now, that tells me that I need 150% of the address space to cover everybody. If wide deployment of converged networks means that 25% was nowhere close enough for the present Internet population, then 150% is a very low guess. So that's "what is" last I heard it from those who have the hard numbers, and "what could be". "What will be" remains anybody's guess. My crystal ball is really shiny due to excessive rubbing, and just as cloudy as ever.
Re: NATs *ARE* evil!
At 02:19 PM 12/14/00 -0500, [EMAIL PROTECTED] wrote: >I haven't decided which of the four NAT should be blamed on. let's be fair. There was an excellent reason for NAT at the time. Postel suggested that private address spaces could be used rather than assigning precious IP Address space to networks that had no intention of attaching to the network, and NATs wound up being a way to couple that with topological address space management to try it out. We knew it was a short term hack at the time, and many of us still think that. As Yakov is prone to point out, in a perfect world wherein all applications are client/server and address space is uniformly available, there are enough addresses around so that NATs are all we need. There are a few problems: - the world is not perfect - all applications are not client/server - address space is not uniformly available Hence, NATs don't solve every problem. The reference to IPv6 is interesting. Up until a year ago, I didn't particular push IPv6 as a solution. Reason: it wasn't in anybody's operational game plan. IPv6 had a serious chicken/egg problem - numerous people wanted to be the second to deploy it, but nobody wanted to be first, and vendors generally didn't see the point in implementing it apart from somebody waving cash to buy it. As a proposal, it solved some interesting things, like more bits in the address, better autoconfiguration, more scalable mobility, more efficient VJ Header Compression, re-introduces the end to end model so we can support non-client/server applications well, and so on. However, being "good" isn't enough unless is it "good enough to deploy" - good enough to replace the old stuff, or good. When 3G put the proposal on the table, it became viable. At the moment, globally, we have perhaps half a dozen to a dozen commercial networks running IPv6 and upwards of 50 research networks. That's an insignificant dent in the great wide Internet, but it is not "nothing" either. We have some pretty large countries that have stated an intention to move in that direction. Now that folks have the opportunity to be second - someone else has gone first - anyone who is having trouble getting addresses from a registry is thinking seriously about IPv6. In short, things had to get worse before they could get better. We'll see where things go, but whatever my opinions on IPv6 are (and I am on record as saying it isn't all we might have liked it to be, my voice being one among many), I am not at all convinced that it is a washout.
Re: NATs *ARE* evil!
> > > On Thu, 21 Dec 2000, Mike Fisk wrote: > > > Yes, I was being slightly more general to include other gateways that > > don't necessarily operate at the application layer: > > TCP-splicing/spoofing, NAT, SOCKS, etc. > > > > The problem is that the protocol mechanisms to discover and use these > > gateways are piecemeal and inadequate. That leads many of them to be > > implemented "transparently" which breaks protocols that don't know there's > > a gateway. > > One way to let higher protocols transparently cross such gateways is described > both in Cheritan's Triad project and my I-D on addressless networking. The Thanks for citing the TRIAD project. The principal investigator is Prof. David Cheriton at Stanford. For details, see http://www-dsg.stanford.edu/triad/index.html. Sam > cut is made just above the IP layer - Triad shows that higher protocols like > TCP can be made happy with pretending there's an IP address below. I more > specifically propose a 32b switch path termination - as long as the 32b number > serves to identify an e2e path, whether or not it is an e2e destination > address and/or transits gateways would be irrelevant to the e2e operability > of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different > from label switching, so what I'm suggesting is that we take the bull by > the horns once and for all and run MPLS over IP instead of under it... That > way, you'd obsolete NATs and SOCKS in the longish run, but that's another story. > > > -p. > >
Re: NATs *ARE* evil!
On Thu, 21 Dec 2000, Mike Fisk wrote: > Yes, I was being slightly more general to include other gateways that > don't necessarily operate at the application layer: > TCP-splicing/spoofing, NAT, SOCKS, etc. > > The problem is that the protocol mechanisms to discover and use these > gateways are piecemeal and inadequate. That leads many of them to be > implemented "transparently" which breaks protocols that don't know there's > a gateway. One way to let higher protocols transparently cross such gateways is described both in Cheritan's Triad project and my I-D on addressless networking. The cut is made just above the IP layer - Triad shows that higher protocols like TCP can be made happy with pretending there's an IP address below. I more specifically propose a 32b switch path termination - as long as the 32b number serves to identify an e2e path, whether or not it is an e2e destination address and/or transits gateways would be irrelevant to the e2e operability of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different from label switching, so what I'm suggesting is that we take the bull by the horns once and for all and run MPLS over IP instead of under it... That way, you'd obsolete NATs and SOCKS in the longish run, but that's another story. -p.
Re: NATs *ARE* evil!
>> Excellent. We've agreed that IPv6's problems are a subset of IPv4's. From: Randy Bush <[EMAIL PROTECTED]> >unfortunately, we have not shown it is a proper subset. e.g. the larger >address space may exacerbate issues already causing problems in v4, such as >the increasing number of routes. >and i am not 'taunting' but trying to see how the hell we can solve some of >the serious problems we have today and not take them with us to the v6 land >of milk and honey, e.g. the multi6 discussion. >if we don't get much smarter quickly, we'll just be making the same mess on >a larger (in one dimension) scale. we need to take a very serious look at >8+8 again. we need to be open to other good ideas. You are absolutely right Randy. Unfortunately the coda for the IETF these days is "Rough Consensus and Shipping Code". One of the biggest problems these days is that we have people demanding backwards compatibility with things that don't really exist yet in a meaningful way. We are becoming more and more like the ITU these days. Several WG's such as SIP have engineers complaining about tiny little changes in a specification that would affect *their* code. So we can't fix a known problem in the spec even though hardly anyone is using this stuff yet.
Re: NATs *ARE* evil!
On Wed, 20 Dec 2000 13:39:11 -0500, you wrote: >V Guruprasad posted, in reply to private mail: > >> Obscurity would mean that a unique server host address exists but >> is not advertised. >No. Security through obscurity means any approach that attempts to protect >network resources (in this case, the server) by making them hard to find. VG gave a specific example of which you give the general case, seems to me that, at least in this area, you're "disagreeing to agree". :-) Rgds Denis -- Denis McMahon Usenet: Trim quotes Mobile: +44 7802 468949Reply at the end Email: [EMAIL PROTECTED] Don't use html I trim ng when posting! Email domain blocking in use
Re: NATs *ARE* evil!
On Thu, 21 Dec 2000, Harald Alvestrand wrote: > At 09:47 19/12/2000 -0800, Mike Fisk wrote: > >It's an argument of semantics, but I prefer to say that we're separating > >transport-layer end-to-end from application-layer end-to-end. Make > >applications explicitly terminate transport connections at gateways. So > >what is now a connection from me to you across a NAT and a proxy-ing > >firewall would be come a session-layer connection from me to you served by > >transport connections from me to the NAT, from the NAT to the proxy, and > >from the proxy to you. > > these are called "application layer gateways", and exist in droves already. > Most firewalls implement them, in addition to NAT and packet filters. Yes, I was being slightly more general to include other gateways that don't necessarily operate at the application layer: TCP-splicing/spoofing, NAT, SOCKS, etc. The problem is that the protocol mechanisms to discover and use these gateways are piecemeal and inadequate. That leads many of them to be implemented "transparently" which breaks protocols that don't know there's a gateway. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
Re: NATs *ARE* evil!
At 09:47 19/12/2000 -0800, Mike Fisk wrote: >It's an argument of semantics, but I prefer to say that we're separating >transport-layer end-to-end from application-layer end-to-end. Make >applications explicitly terminate transport connections at gateways. So >what is now a connection from me to you across a NAT and a proxy-ing >firewall would be come a session-layer connection from me to you served by >transport connections from me to the NAT, from the NAT to the proxy, and >from the proxy to you. these are called "application layer gateways", and exist in droves already. Most firewalls implement them, in addition to NAT and packet filters. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: NATs *ARE* evil^H^H^H^Hmpls!
one of nature's great dualities: statedulness will take root in the most barren soil, even though datagrams will try to route around it j though if nat speak unto nat, then ipv6 be born
Re: NATs *ARE* evil!
On Wed, 20 Dec 2000, John Stracke wrote: > I say it's a weak form because I believe you are wrong in stating that "a > unique server host address does not exist". The URL (ick) is an address > for the server; it's just a higher-level address than an IP address. The "URLs" in my approach do not identify the server host, and it's NOT a higher-level version of the IP address. See Section 2.1, which states the extent of weakness, and 2.3.9 which charts the conditions under which the information can be leaked to the client. The fact that my "URLs" are not high-level host addresses was specifically brought out at the ECUMN'2000 workshop-like conference, where the impact of this development was so strongly felt that attention was drawn to this right from the introductory plenary session. The purpose of the architecture is not to provide security, however. [ btw, what's (ick)? ] thanks, -p.
Re: NATs *ARE* evil!
V Guruprasad posted, in reply to private mail: > Obscurity would mean that a unique server host address exists but > is not advertised. > > Invisibility means that a unique server host address does not exist > at all. This is a harder condition. No. Security through obscurity means any approach that attempts to protect network resources (in this case, the server) by making them hard to find. Your approach, then, has a weak form of security through obscurity. It still permits clients to contact the server, which means that the server needs to be hardened against malicious clients, which is why security through obscurity is so poorly thought of. I say it's a weak form because I believe you are wrong in stating that "a unique server host address does not exist". The URL (ick) is an address for the server; it's just a higher-level address than an IP address. -- /==\ |John Stracke| http://www.ecal.com |My opinions are my own.| |Chief Scientist |=| |eCal Corp. |Campbell's has it wrong--it's "Never | |[EMAIL PROTECTED]|underestimate the power of *chocolate*". | \==/
Re: NATs *ARE* evil!
On Wed, 20 Dec 2000, John Stracke wrote: > > Why don't you read the I-D > > I did. Then you'd see that the invisibility refers to that of the server host, as follows: The client sees only the service name binding in the form of the URL, but what it gets as the data path is a virtual path (or LSP) handle. Since the label changes at each hop, the path index visible to the client host relates only to its own handle or file descriptor for the path, and is not enough to identify the server host. (The server host gets revealed only if there's only one hop.) Obscurity would mean that a unique server host address exists but is not advertised. Invisibility means that a unique server host address does not exist at all. This is a harder condition. If my approach is implemented *in addition to* end-to-end IP, you do get compromised because the IP layer supplies the host address. But the defect would be due to the IP layer, NOT my framework, which is happy as long as it can do MPLS end-to-end for transport. In particular, one does not need IP per se under my framework, and in that aspect, one can continue to use the higher IP protocols, like TCP, UDP, SCTP, etc. e2e because they'd run on top of the virtual path endings. One question that was unclear till the IETF meeting was whether these higher protocols could indeed be fooled to work independently of IP: the proof of principle exists - in Cheritan's Triad project at Stanford, the 32 b IP address is faked in similar fashion. Incidentally, Triad was substantially what I had initially proposed within IBM in 1995-1996, and we didn't see it as being of more than academic interest at that time. best regards, -p.
Re: NATs *ARE* evil!
V Guruprasad wrote: > > of virtual memory is that it makes it easier for the user (well, > > programmer) by hiding the nasty details of which physical address your > > IMHO, hiding is not the primary function of virtual memory addressing, On the contrary. Hiding the details from the programmer means that the OS can move data around without bothering the application; that's *precisely* the point of VM. Without that, you can't have swap space. Similarly, DNS hides the details of IP addresses, so that servers can be moved around without bothering the users. > although it does spin off as a powerful means of security (Section 2.1.3 > - security by invisibility). Otherwise known as "security through obscurity". -- /===\ |John Stracke| http://www.ecal.com |My opinions are my own. | |Chief Scientist |==| |eCal Corp. |"Dinner Special: Turkey $2.35; Chicken or Beef| |[EMAIL PROTECTED]|$2.25; Children $2.00." | \===/
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Mike Fisk wrote: > It's one thing to hand out addresses or names. It's another thing to run > a top-level routing server that all of your children customers have to > route through to get to other top-level providers. Your mapping between > the two would imply that, for instance, all traffic between europe and > japan would have to transit across a RIPE top server and a JPNIC top > server? Only in principle. No more than typing http://www.nokia.com from Finland would route the lookup to the .com root server in Washington D.C. Also, you're misreading it as "all traffic" - it should be "all connection request traffic". > Again, the hierarchical addressing is nothing new, but the fact that > you're tying routing to the same hierarchy will have new side-effects on > routing that need to be understood. Spanning tree, faster but suboptimal logical path. You wouldn't want your data to go that way. > Right now, routing is orthogonal to addressing and DNS naming. You're The orthogonality comes from the translation. The translation goes sideways from the name service spanning tree. Secondly, it does not need to know the global network topology or addresses. You still need IGP (or equivalent) to supply the translation rulebase, but no BGP, so to speak. > removing addressing and tying routing to naming. Now your name servers > have to route packets and be aware of peering relationships. That has No. Their job is only to compile connection requests, distributed fashion, into the data paths. Peering relations would be presumably compiled by IGPs for them, but that's as much as they need to have to get the connections going. Btw, I'm still working on some aspects of translation optimisation and failure recovery, which will be critical if and when we try to apply it on the Internet scale, and which I expect will reach a conclusive level within the next few months. On the other hand, these aspects are not critical for deploying over the existing Internet, or even for "addressless" cellular Internet connectivity, for example, since the latter will be routed through transcoding gateways for the foreseeable future in any case. thanks, -p.
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Mike Fisk wrote: > explosion. So over time there becomes an established club of roots and > everybody else has to be a child. That creates a monopolistic situation > where you have to pay a root node for transit. It could work, but it > sounds worse than the existing DNS root mess. > > How do you preserve the decentralized resilience of the Internet with such > a hierarchy? We do have such a thing in the Internet today. It used to be DARPA, and now it's IANA, and is still very much US-centric; we have regional bodies spec'd out for IPv6 that will control not only names but also addresses. In the proposed framework, you would only ask your immediate provider for connectivity - (s)he doesn't have to coordinate nationally and internationally to give you an address, and it's enough if your chosen name doesn't clash with something already registered at the provider's name server. So I'd think it's less of a mess than the DNS and IP are today in that regard. > maintain a reasonable number (< 100k?) of peers. For efficient table > lookup, there would be a push to standardize on a length limitation. So > You've just created a situation where the root club will enforce > sufficient hierarchy so as to limit the size of route tables. Like //com/ibm/watson/affine/tmp/vinet.pdf? Seems to be working ok for now. What I'm wondering is why/whether the residual defects, which are common to the DNS, should detract from the improvements/alternatives/differences that you haven't commented on. thanks, -p.
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Jon Knight wrote: > are on and what the address of their gateway router is. Not exactly what > I'd call omniscience. All right, I confess, I'm not perfect in summarising the existing art and relating to it (yet). I promise to gratefully acknowledge comments such as these that will doubtless help make the next revision more readable :) > Surely DNS addresses are more equivalent to the virtual memory No, in the sense I was arguing about, the DNS hostname points to a physical host (or interface, etc.), and is therefore a physical address. > of virtual memory is that it makes it easier for the user (well, > programmer) by hiding the nasty details of which physical address your IMHO, hiding is not the primary function of virtual memory addressing, although it does spin off as a powerful means of security (Section 2.1.3 - security by invisibility). > code and data live at. The whole point of the DNS is that it makes it > easier for the user by hiding the nasty details of what IP address you > need to talk to. And that's without getting into the situations where a That's high level programming language, not virtual addressing... This point is particularly brought out in my proposal, as the routing is literally accomplished as a (distributed) compilation (see attribute grammar examples in Section 2.4.4, page 28). > mention URNs at all and yet alot of what it seems to do appears similar to > the ideas behind the URN efforts of the IETF in the past. Similar sounding ideas, but no semantics match, really, since the underlying premises are fundamentally different. -p.
Re: NATs *ARE* evil!
> Steve Bellovin, on IPSEC, not-AH: > > | [A] host's identity is represented by its certificate (I'm speaking a bit > | loosely here); its IP address is merely the way that packets reach it. > > This is an example of two separate namespaces that allow one > to distinguish between "who" and "where". That the network > layer can be rewritten to the point of total protocol substitution > without interfering with the identification of who sent it > is a feature, adding enormous flexibility into the development > of network features. agreed, *provided* there is a fast and reliable service for mapping between one kind of identity and another. arguments of the form "separate identities are better" tend to gloss over the difficulty of providing an adequate mapping service. (Hint: DNS is neither sufficiently fast nor sufficiently reliable) the other problem with separating the layers is that the ability to drill down through layers is essential for diagnostic purposes, for tracking down miscreants, and to allow prototyping new kinds of services that need to operate with knowledge of layer 3. So we will always have a need for some kinds of "applications" to operate with knowledge of network addresses. Keith
Re: NATs *ARE* evil!
Date: Tue, 19 Dec 2000 11:20:23 -0500 From: V Guruprasad <[EMAIL PROTECTED]> On Tue, 19 Dec 2000, Keith Moore wrote: > mumble. as far as I can tell, both DNS names and IP addresses > are hopelessly overloaded and are likely to stay that way until > we figure out how to make a major architectural change. Could you please take a look at draft-guruprasad-addressless-internet-00.txt I just took a look at it, and it makes the following interesting assumption: "Internet == Web ---> URL's are the only form of addresses which matter". It also seems to be espousing a form of address path which looks remarkably similar to UUCP bang-path routing, using optimizations very similar to which were encoded in a UUCP pathalias file. Am I missing something or is that in essense your proposal? - Ted
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, V Guruprasad wrote: > Could you please take a look at > draft-guruprasad-addressless-internet-00.txt > ? I've just started to read it and in 1.1 it says: "- requiring e2e network knowledge (omniscience) at each node in the form of e2e routing tables (Section 1.3);" Erm, now I might be misunderstanding something here but our end nodes (workstations, servers, PCs, etc) certainly don't have full e2e routing knowledge. They know what their address(es) is/are, what network(s) they are on and what the address of their gateway router is. Not exactly what I'd call omniscience. Also I note in section 1.2 it says: "Even if better dressed as IP addresses, network addresses are real addresses in that they locate physical destinations in the network, unlike memory addresses, which are routinely virtualised by host operating systems." Surely DNS addresses are more equivalent to the virtual memory addresses in host if you're going to take that analogy? The whole point of virtual memory is that it makes it easier for the user (well, programmer) by hiding the nasty details of which physical address your code and data live at. The whole point of the DNS is that it makes it easier for the user by hiding the nasty details of what IP address you need to talk to. And that's without getting into the situations where a single IP address locates multiple hosts (broadcast addresses, multicast addresses, etc). Reading further into the draft I was left think "URNs". The draft does mention URNs at all and yet alot of what it seems to do appears similar to the ideas behind the URN efforts of the IETF in the past. Tatty bye, Jim'll
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, Mike Fi sk writes: > >The marginal value I see in IPsec is that it is useful for protocols other >than TCP. For TCP applications, I confess that I don't see much value in >IPsec (not that TLS has any particular merits, it just became more common >first). > Why do I think I'm having this discussion for the Nth time? IPsec has two other advantages: it protects *all* transmissions without touching the applications, which would otherwise need to be converted one at a time; it also protects TCP against one-packet denial-of-service attacks. All I have to do to tear down a TLS session is send one packet with the correct port and sequence numbers. TLS will notice that the packet doesn't belong, and will tear down the session. With IPsec, TCP will never even see the garbage packet, since it will fail the integrity check before it gets to that layer. --Steve Bellovin
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Theodore Y. Ts'o wrote: >Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) >From: Mike Fisk <[EMAIL PROTECTED]> > >Gateways that surreptitiously modify packets can break ANY end-to-end >protocol no matter what layer it's at. Assume that we sacrifice IP >addresses as not necessarily end-to-end. Fine, there are gateways that >need to modify your TCP ports too. Okay, sacrifice make it so ports >aren't covered by e2e assumptions like IPsec. Fine, there are gateways >that do ACK spoofing. Okay, sacrifice all header data and assume that >only payload is e2e. Whoops, even the payload has to be modified by some >gateways. The hypothesis that you can have these gateways and have >any part of the packet be guaranteed to be e2e is false. > >Given our inability to rule out the need for gateways that change IP >addresses (or other routing headers), this leads to the conclusion that >applications shouldn't use any header field (IP address, port, etc.) for >authentication. > > OK, in that case, we've completely thrown out the end-to-end principle It's an argument of semantics, but I prefer to say that we're separating transport-layer end-to-end from application-layer end-to-end. Make applications explicitly terminate transport connections at gateways. So what is now a connection from me to you across a NAT and a proxy-ing firewall would be come a session-layer connection from me to you served by transport connections from me to the NAT, from the NAT to the proxy, and from the proxy to you. Just as layer two frames don't cross routers, layer three and four frames don't cross these upper-layer gateways. I want to get rid of surreptitious proxies and gateways, but to get there you have to provide similar services somewhere in the stack. Today we maintain route tables, ARP for the router's layer two addresses, and form a packet. We need something equivalent to handle the discovery and addressing of upper-layer gateways. The presentation I gave at the midcom BOF covers some of this: http://public.lanl.gov/mfisk/papers/midcom-bof.pdf > and completely wiped out any possibility of IPSEC. If that's the world > we live in, where any part of the IP header can be subject to attack by > an intermediate attacker err, "service provider", then you shouldn't > be using IPSEC. You should be using TLS instead. That's the crux. If I live in an institution with a NAT or firewall, there is a policy that I will use that network "service". There may be other policies regarding what other intermediate gateways you trust. Many people will favor trusting as few (zero) gateways as possible. Hopefully these policies will drive people away from the use of these gateways, but I don't think we can assume that gateways will never exist. We need good protocol mechanisms that allow those policies. The marginal value I see in IPsec is that it is useful for protocols other than TCP. For TCP applications, I confess that I don't see much value in IPsec (not that TLS has any particular merits, it just became more common first). > It of course also means that no part of the IP header can be > authenticated in anyway, since it's of course all subject to change by > such gateways. Yes, I assert that that is an architectural assumption (concession) that needs to be made. You might be able to authenticate the IP header of the gateway, but that doesn't help you much with application-level e2e authentication. > Is that really the architecture that we should be building in the > Internet. I know some extremists would say yes, absolutely, and others > would be say that this would be a horror. The problem though is that > we're designing that assume (and depend upon) both architectural > philosophies. Is it any wonder that we're having disconnects? Agreed. We have to agree on what assumptions we can make. We need more questions like "can we sign in blood that the IP address will not be modified". Unfortunately, I don't think we can make that particular assumption (between application end-points). Yes, some of us are proposing a departure from some current architectural assumptions, but I think that there is sufficient evidence that there are legitimate (if unfortunate and messy) needs for this agility. You're correct in fearing that we can't just put a stake in the sand and swear them away. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.lanl.gov/mfisk/ for contact information
Re: NATs *ARE* evil!
From: Ken Raeburn <[EMAIL PROTECTED]> Date: 19 Dec 2000 09:02:52 -0500 "Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes: > Kerberos tried to deal with this problem by talking about "canonical > domain name", which it tried to define as being the name that you got > when you took a DNS name, forward resolved it to get an A address, and > then reverse-resolved it to get a DNS name. But this didn't work in > many cases, sometimes we got back an unqualified name, and in many cases > this scheme totally failed due to load balancing DNS servers, etc. I The MIT implementation does that, but I always thought that was just because certain gethostbyname implementations wouldn't return the canonical name (in the CNAME-processing sense) without doing this dance. Because of the server-cluster or load-balancing case, I've been thinking we should change it. The spec has never been quite that precise on this point; probably something we should fix for RFC1510bis. RFC-1510bis always ignored this issue, and at some level, it strikes at the heart of the whole name canonicalization mess. RFC-1510 assumes that you know the authentication name of the service. The problem is that it's silent on that the issue of how you discover said authentication name. What was implemented in the MIT implementation isn't actually specified anywhere; it's a local implementation hack. And, as Microsoft rightly points out, because we rely on the DNS, it's not really secure, either. Unfortunately, fixing this problem is hard! The problem with using the CNAME target as the authentication name is that that while it works for some load-balancers, it fails for others. It all depends on whether the load-balancers return a CNAME or an A address. Simply just using the CNAME also means that you need to also replicate the domain name search rules. If I type "telnet tsx-prime", and I have a domain name search rule of "valinux.com mit.edu", then the name which should be used is tsx-prime.mit.edu. Yet if I type "telnet shells", I should get the name shells.valinux.com. This reason is historically the reason why we played the forwards and backwards dance --- because we wanted to get that case right. So when checking gethostbyname implementations, if you have to check to see whether they return the FQDN both in the CNAME case, and in the case where an unqualified domain name is typed by the client. Many gethostbyname implementations will fail on one or the other > suspect the reason is that as our domain name friends would tell us, > there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. If you get hosts with multiple addresses (or, under IPv6, multiple prefixes), an address-based identifier is still not unique. (And, unpleasantly enough, there are server implementations that split a single IP address across multiple machines.) True enough. (Although some people actually want to be able to authenticate and distinguish between specific ethernet interfaces; they mostly fall into the category of "sick puppies", but it's indicative of the naming problem that we have. We don't have general agreement on what the semantics of the names that we do have, and as a result the semantics are overloaded as all hell, with different people taking advantage of different aspects of the overloaded semantics, making it extremely difficult to separate them out cleanly. Ack!) - Ted
Re: NATs *ARE* evil!
Hi Keith! On Tue, 19 Dec 2000, Keith Moore wrote: > mumble. as far as I can tell, both DNS names and IP addresses > are hopelessly overloaded and are likely to stay that way until > we figure out how to make a major architectural change. Could you please take a look at draft-guruprasad-addressless-internet-00.txt ? It's been done, and at least one conference PC rated it a best paper (online at http://affine.watson.ibm.com/tmp/vinet.pdf), so it couldn't be so bad as to be left in total oblivion while everyone continues in endless inane discussions :-( More to the point, everyone I did manage to present it to in the hallways at the 49th IETF did like the idea. I'd hate to list the nodders, but the list includes at least one IAB member, one W3C person, and an important contributor to IS-IS and OSPF, as I recall. "only an asteroid can clear the dinosaurs..." -p.
Re: NATs *ARE* evil!
In your previous mail you wrote: While I wouldn't go quite that far, I've been saying for years that the IP header doesn't need any authentication if we have IPsec. => this is not true for IPv6 extension headers or IPv4 options. ... in a note explaining why I thought AH was useless => you can argue this for IPv4, not for IPv6 where extension headers are really used. Many times some of us tried to remove AH, many times we vote to keep it: this topics should be in the "oh not this again" list of IETF and IPsec mailing lists. Regards [EMAIL PROTECTED] PS: "NATs are evil" should be in too (:-)!
Re: NATs *ARE* evil!
Steve Bellovin, on IPSEC, not-AH: | [A] host's identity is represented by its certificate (I'm speaking a bit | loosely here); its IP address is merely the way that packets reach it. This is an example of two separate namespaces that allow one to distinguish between "who" and "where". That the network layer can be rewritten to the point of total protocol substitution without interfering with the identification of who sent it is a feature, adding enormous flexibility into the development of network features. That IPSEC can preserve the end-to-end integrity of the the application-to-application data even in a rabidly-rewriting environment makes one wonder why people are so fanatical about preventing that rewriting at all! (The important thing is that one knows that "Steve's Machine" sent a packet that happened to arrive with a particular source address, which for a while can be used to send replies back to "Steve's Machine"). The only tricky thing here is having a "who" <-> "where" translation readily available to the host. Sean. P.S.: Incidentally, I have no trouble whatsoever with the concept of a last-hop-router before a host that can distinguish "who" "where" being presented with a permanent, deterministic association between the two. I also have no problem with the last-hop-router moving "corewards" even several hops. The thing I want to prevent is the requirement that ALL routers provide such a deterministic permanent mapping between the two, because ultimately that makes the Internet more expensive for everyone to use over time. (It also makes a non-dual-stack transition to a new Internet protocol much harder on the host side, and a non-ships-in-the-night deployment in routers nearly impossible).
Re: NATs *ARE* evil!
>If DNSSEC were deployed, I see no reason why SAs could not be >bound to domain names. > > I disagree. IPSEC is about Security at the IP layer, and that means we > need a security association which is tied to an object which is > addressable at the IP layer --- an IP address. except that, 99% of the time, the address is obtained from DNS, and, realistically, you care more about the authenticated identity of the peer than its address.. > A DNS name doesn't qualify; a single DNS name can resolve to many > different IP addresses, potentially representing multiple different > hosts. Some people do this for load-balancing purposes (to Randy Bushes > infinite digust, but this is the reality). > > Also, riddle me this: What host is addressed by the DNS name > a456.g.akamai.net? For me at home, it happens to be 207.87.18.169. > Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or* > 18.7.0.10. Betcha it's different for you. :-) "any problem in CS can be solved by adding another level of indirection". If we were to use the DNS name as the identity at each end of the SA, a456.g.akamai.net could turn into a CNAME pointing at the "real" server... And it might not matter ... from the point of view of the *services* provided, regardless of *which* instance of a456.g.akamai.net you connect to, you get the same data... it's just another face of the greater akamai distributed hive mind. [I assume that for operational/management purposes, akamai has per-replica names which are different from the ones given out in akamaized url's]. - Bill
Re: NATs *ARE* evil!
> there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. mumble. as far as I can tell, both DNS names and IP addresses are hopelessly overloaded and are likely to stay that way until we figure out how to make a major architectural change. I get amused when layer 3 folks tell me that overloading of IP addresses is bad and that we therefore need to overload DNS names even more. But it doesn't make any more sense to me to increase the overloading of IP addresses (which are fundamentally names of locations of network attachment points - all other uses are in some sense overloading) in order to reduce overloading of DNS names. it seems to me that if you want to authenticate to a specific host then you need to use an identifier that is uniquely associated with that host, like the hosts's serial number, so I'd want to have certificates that could associate that serial number with a key. but in most cases (at least from an apps guy's view of the world) I don't care about any particular host - what I want to authenticate is a service, and it could be on any hosts. in such cases I want to use the service name (which in today's world is usually a DNS name) as the authentication identifier. I could probably make a case for authenticating to IP addresses also, but for me this is the most difficult one to justify. bottom line is I think we have a need for SAs to be bindable to several different kinds of identifiers. I question the notion that IPsec should be "security at the IP layer" because to me IP is only a way of moving payload from one place to another - it has little to do with the services that humans care about and in whose identities they need to trust. Keith
Re: NATs *ARE* evil!
> If DNSSEC were deployed, I see no reason why SAs could not be > bound to domain names. Well, there are all those load-distributing hacks -- Akamai and others. But I bet they could come up with a huge flesh-tone bandaid so you would continue not to notice. On a good day.
Re: NATs *ARE* evil!
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes: > Kerberos tried to deal with this problem by talking about "canonical > domain name", which it tried to define as being the name that you got > when you took a DNS name, forward resolved it to get an A address, and > then reverse-resolved it to get a DNS name. But this didn't work in > many cases, sometimes we got back an unqualified name, and in many cases > this scheme totally failed due to load balancing DNS servers, etc. I The MIT implementation does that, but I always thought that was just because certain gethostbyname implementations wouldn't return the canonical name (in the CNAME-processing sense) without doing this dance. Because of the server-cluster or load-balancing case, I've been thinking we should change it. The spec has never been quite that precise on this point; probably something we should fix for RFC1510bis. > suspect the reason is that as our domain name friends would tell us, > there is no such thing as a "canonical domain name" for a host. > Kerberos tried to invent such a concept, but it didn't work all that > well. I would much rather have some real IP-level endpoint identifier. > If that's what we're securing, that's what we should be using. If you get hosts with multiple addresses (or, under IPv6, multiple prefixes), an address-based identifier is still not unique. (And, unpleasantly enough, there are server implementations that split a single IP address across multiple machines.) Ken
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, "Theodore Y. Ts'o" writes : > Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) > From: Mike Fisk <[EMAIL PROTECTED]> > > Gateways that surreptitiously modify packets can break ANY end-to-end > protocol no matter what layer it's at. Assume that we sacrifice IP > addresses as not necessarily end-to-end. Fine, there are gateways that > need to modify your TCP ports too. Okay, sacrifice make it so ports > aren't covered by e2e assumptions like IPsec. Fine, there are gateways > that do ACK spoofing. Okay, sacrifice all header data and assume that > only payload is e2e. Whoops, even the payload has to be modified by some > gateways. The hypothesis that you can have these gateways and have > any part of the packet be guaranteed to be e2e is false. > > Given our inability to rule out the need for gateways that change IP > addresses (or other routing headers), this leads to the conclusion that > applications shouldn't use any header field (IP address, port, etc.) for > authentication. > >OK, in that case, we've completely thrown out the end-to-end principle, >and completely wiped out any possibility of IPSEC. If that's the world >we live in, where any part of the IP header can be subject to attack by >an intermediate attacker err, "service provider", then you shouldn't >be using IPSEC. You should be using TLS instead. > >It of course also means that no part of the IP header can be >authenticated in anyway, since it's of course all subject to change by >such gateways. While I wouldn't go quite that far, I've been saying for years that the IP header doesn't need any authentication if we have IPsec. To me, a host's identity is represented by its certificate (I'm speaking a bit loosely here); its IP address is merely the way that packets reach it. I could post my analysis of this again (it was originally written during the Stockholm IETF, in a note explaining why I thought AH was useless), but I don't think that this is the place for it. --Steve Bellovin
Re: NATs *ARE* evil!
Date: Mon, 18 Dec 2000 14:45:08 -0800 (PST) From: Mike Fisk <[EMAIL PROTECTED]> Gateways that surreptitiously modify packets can break ANY end-to-end protocol no matter what layer it's at. Assume that we sacrifice IP addresses as not necessarily end-to-end. Fine, there are gateways that need to modify your TCP ports too. Okay, sacrifice make it so ports aren't covered by e2e assumptions like IPsec. Fine, there are gateways that do ACK spoofing. Okay, sacrifice all header data and assume that only payload is e2e. Whoops, even the payload has to be modified by some gateways. The hypothesis that you can have these gateways and have any part of the packet be guaranteed to be e2e is false. Given our inability to rule out the need for gateways that change IP addresses (or other routing headers), this leads to the conclusion that applications shouldn't use any header field (IP address, port, etc.) for authentication. OK, in that case, we've completely thrown out the end-to-end principle, and completely wiped out any possibility of IPSEC. If that's the world we live in, where any part of the IP header can be subject to attack by an intermediate attacker err, "service provider", then you shouldn't be using IPSEC. You should be using TLS instead. It of course also means that no part of the IP header can be authenticated in anyway, since it's of course all subject to change by such gateways. Is that really the architecture that we should be building in the Internet. I know some extremists would say yes, absolutely, and others would be say that this would be a horror. The problem though is that we're designing that assume (and depend upon) both architectural philosophies. Is it any wonder that we're having disconnects? - Ted
Re: NATs *ARE* evil!
Date: Mon, 18 Dec 2000 22:54:47 -0500 From: "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]> If DNSSEC were deployed, I see no reason why SAs could not be bound to domain names. I disagree. IPSEC is about Security at the IP layer, and that means we need a security association which is tied to an object which is addressable at the IP layer --- an IP address. A DNS name doesn't qualify; a single DNS name can resolve to many different IP addresses, potentially representing multiple different hosts. Some people do this for load-balancing purposes (to Randy Bushes infinite digust, but this is the reality). Also, riddle me this: What host is addressed by the DNS name a456.g.akamai.net? For me at home, it happens to be 207.87.18.169. Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or* 18.7.0.10. Betcha it's different for you. :-) When you add to this the problem that forwards and reverse name resolution are not always the same, and that sometimes the in-addr names don't even exist (for example, at the IETF terminal room in San Diego initially), I believe that trying to use DNS names for SA binding just isn't going to work in real life. Kerberos tried to deal with this problem by talking about "canonical domain name", which it tried to define as being the name that you got when you took a DNS name, forward resolved it to get an A address, and then reverse-resolved it to get a DNS name. But this didn't work in many cases, sometimes we got back an unqualified name, and in many cases this scheme totally failed due to load balancing DNS servers, etc. I suspect the reason is that as our domain name friends would tell us, there is no such thing as a "canonical domain name" for a host. Kerberos tried to invent such a concept, but it didn't work all that well. I would much rather have some real IP-level endpoint identifier. If that's what we're securing, that's what we should be using. - Ted
Re: NATs *ARE* evil!
> From: Geoff Huston <[EMAIL PROTECTED]> > part of the characteristics of today's Internet is that its is > flattening out. The concept of hierarchical connectivity with > 'upstreams' and 'downstreams' ... as I understand the current > deployment plan there are TLAs and sub TLAs, and an apparent > hierarchical view of the world again. I'm not quite sure if this is what Ted was referring to - and we have indeed wandered a bit. Your point is an important one, though - but the answer takes us even further afield, into routing theory. (Briefly!) There is a great misconception, in the IETF as a whole, that hierarchical location-names mean that either i) topological connections have to be hierarchical, or ii) paths have to be hierarchical. Both suppositions are absolutely, completely, untrue. As to the first, if you will consult the classic paper on hierarchical routing: Leonard Kleinrock, Farouk Kamoun; "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization"; Computer Networks 1 (1977); North-Holland Publishing Co.; pp. 155-174. you will see that their work utilizes a random graph (that's a technical definition, not a judgemental term :-), so that disposes of the first one. It does use strictly hierarchical routing (i.e. their abstraction naming boundaries are congruent with their abstraction action boundaries), but even so it's worth noting their conclusion: "As regards the network path length, we were able to place an upper bound on its increase due to the introduction of hierarchical routing ... in the limit of very large networks, enormous table [size] reductions may be achieved with essentially no increase in network path lengths" Use of non-hierarchical routing with hierarchical location-names is a complex topic, one I can't explore here because it's tied in with all sorts of hairy conflicting optimization (overhead, path length, etc) questions. However, it is easy to provide non-hierarchical routing, even when the naming system you are using is hierarchical. > part of the issue we face now is the semantics of the address ... Is an > address an identification of identity? A key to absolute location? A > key to relative location? An encoding of the local topology? There are interesting questions, and ones that unfortunately have not been previously settled in a consistent way across the community. (I would say more about the fundamental technical issues, in particular what technical tasks we ought to be using "place-names" for, but this probably isn't the right time/place.) > in looking at the structure of V6 addresses ... we appear to have > adopted an approach which is not far removed from the provider address > hierarchy structure of V4 today. >From my point of view, the problem is not with the hierarchical nature of the IPv6 address (since something like a hierarchy exists in every large-scale routing system I've ever seen), but rather with the point you just raised - just what it is that those things name, and how they name them. > My lurking concern is that it is not working in the V4 routing system > given the large percentage of table entries which are more specific > advertisements of aggregate announcments (approx 40%) and it won't work > for V6 either The problem you're touching on, of multi-homing, is basically not a problem with the addressing. It is a problem of i) the overall system architecture, and ii) the architecture of the routing system. It's a problem with the overall system architecture because providing the benefits of multi-homing by imposing the cost of supporting it *entirely* on the routing system - which is the way we are supporting multi-homing now - may not be the way to go. Multi-homing is a complex topic, but I do think there are other mechanisms which might be more cost-effective *in some circumstances* than shoving the whole job off on the routing (e.g. use of multiple addresses - but note that these addresses are still hierarchical). (And may I take a moment to point out that if we were charging for routes, the costs of having the routing "do it all" would be more apparent, and there would be more incentive to explore other mechanisms.) It's a problem with the routing architecture because in many cases, one needn't expand to a global scope for the advertisement of a multi-homed site, but the routing system as currently architected has no tools to help us with either i) determing, or ii) setting scopes. All we have is either i) purely local, or ii) global. > It appears that the intended address structure and deployment structure > appear to be at variance, and when that happens the temptation to alter > the address in flight to suit each local region's environment may well > be overwhelming. I can't conceive of any reason that the path selection would want to change an address (at least, in the sense of "location-name") in f
Re: NATs *ARE* evil!
DNSSEC is still evolving, it isn't deployed yet, and the right mailing lists to discuss it are the DNSEXT and DNSOP working groups. However, to give a really brief answer, if your local revolver is unwilling to do the full blown DNSSEC cryptography and just wants to trust that the local nameserver is doing it right (a reasonable scanario), it would likely secure its transactions with that namesever with TSIG [RFC 2845]. And one way in which TSIG keying material could be set up is TKEY [RFC 2940]. Donald From: [EMAIL PROTECTED] Message-Id: <[EMAIL PROTECTED]> To: "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] In-Reply-To: Your message of "Mon, 18 Dec 2000 22:54:47 EST." <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> >On Mon, 18 Dec 2000 22:54:47 EST, "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]> said: >> If DNSSEC were deployed, I see no reason why SAs could not be >> bound to domain names. > >I admit to not having read the DNSSEC RFCs. I however do hope that they >are immune to the same sort of attacks against SSL and SSHv1 that are currently >getting a lot of publicity. > >Anybody got a pointer to where in the RFC it discusses how the resolver on >my workstation initially verifies that it's not being man-in-the-middle'ed >from a spoof of our local nameserver? >-- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech
Re: NATs *ARE* evil!
On Mon, 18 Dec 2000 22:54:47 EST, "Donald E. Eastlake 3rd" <[EMAIL PROTECTED]> said: > If DNSSEC were deployed, I see no reason why SAs could not be > bound to domain names. I admit to not having read the DNSSEC RFCs. I however do hope that they are immune to the same sort of attacks against SSL and SSHv1 that are currently getting a lot of publicity. Anybody got a pointer to where in the RFC it discusses how the resolver on my workstation initially verifies that it's not being man-in-the-middle'ed from a spoof of our local nameserver? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: NATs *ARE* evil!
If DNSSEC were deployed, I see no reason why SAs could not be bound to domain names. Donald From: RJ Atkinson <[EMAIL PROTECTED]> Message-Id: <[EMAIL PROTECTED]> Date: Mon, 18 Dec 2000 20:45:43 -0500 To: [EMAIL PROTECTED] (Sean Doran) Cc: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> >The root issue with ESP/AH and NAT is that the Internet >Architecture does not currently have a sufficiently rich set >of namespaces. In the world of the current Internet Architecture, >ESP and AH are forced to bind SAs to addresses. In a different >world, they might be able to bind SAs to a different name. Some >folks are exploring which, if any, additional namespaces might >make sense to add to the architecture. As this is research, >not engineering, it is largely happening in the IRTF for now. >If something comes of it, no doubt an I-D or two will appear >online for perusal... > >Ran
Re: NATs *ARE* evil!
At 17:39 18/12/00, John Collis wrote: >This is true. To do this though really requires some re-architecting >of the current Internet model, based on "first principles". Yes. >In particular, there is not a sufficient "name space" for what we are >often currently trying to do - hence the "akamai" type of trick. Yes. >Currently we have a situation where the defined name spaces are >not sufficient for truly identifying the end points of a routed >connection. IP addresses are therefore there for routing >purposes. However a number of situations can now occur so that >the IP address is not sufficient to name all situations. A host >can be multi-homed, partially disconnected or mobile and then >things start getting ugly. Quite right. >We need to look at this. I believe that we are now already overloading the useful set >of meanings that one can attach >to an IP address (somewhat analogous to the presentation >from Randy Bush at the plenary session on DNS). IRTF NSRG is looking at this. Research from folks not involved in the NSRG would also be time well spent, IMHO. I suspect there are some theses lurking in this area, for those who might be of an academic bent. Cheers, Ran [EMAIL PROTECTED]
RE: NATs *ARE* evil!
At 13:44 15/12/00, Sean Doran wrote: >Surely the "much pain" is because, as Melinda Shore indicates, >some "anti-NAT fanatics" cannot understand the distinction >between "who" and "where"? I fancy that I know one or two things about ESP and AH. Your analysis is Wrong. The pain has nothing to do with fanatics of any sort. The root issue with ESP/AH and NAT is that the Internet Architecture does not currently have a sufficiently rich set of namespaces. In the world of the current Internet Architecture, ESP and AH are forced to bind SAs to addresses. In a different world, they might be able to bind SAs to a different name. Some folks are exploring which, if any, additional namespaces might make sense to add to the architecture. As this is research, not engineering, it is largely happening in the IRTF for now. If something comes of it, no doubt an I-D or two will appear online for perusal... Ran
Re: NATs *ARE* evil!
> Excellent. We've agreed that IPv6's problems are a subset of IPv4's. unfortunately, we have not shown it is a proper subset. e.g. the larger address space may exacerbate issues already causing problems in v4, such as the increasing number of routes. and i am not 'taunting' but trying to see how the hell we can solve some of the serious problems we have today and not take them with us to the v6 land of milk and honey, e.g. the multi6 discussion. if we don't get much smarter quickly, we'll just be making the same mess on a larger (in one dimension) scale. we need to take a very serious look at 8+8 again. we need to be open to other good ideas. what we don't need is more pissing contests and cute blame-casting, from either side. the fact is that there are no sides, as we're all in the same mess today, and likely will be together in the same can-we-avoid-a-mess tomorrow. it's called the internet. randy
Re: NATs *ARE* evil!
On Mon, 18 Dec 2000, Theodore Y. Ts'o wrote: > My concern is that it may turn out that some transport/routing people > may conclude that we may also need to do NAT to solve the routing > problem. In which case, we're back to where we started. > > I'd feel a lot better if we could get key routing/transport people to > sign some contract in blood stating that the IPV6 address is guaranteed > to be invariant, and that any attempt to design boxes which muck with > the IPV6 address in transit is architecturally out of bounds. That may > seem to you to be obviously true, but I 10 years ago we assumed the same > would be true for IPV4 addresses. Gateways that surreptitiously modify packets can break ANY end-to-end protocol no matter what layer it's at. Assume that we sacrifice IP addresses as not necessarily end-to-end. Fine, there are gateways that need to modify your TCP ports too. Okay, sacrifice make it so ports aren't covered by e2e assumptions like IPsec. Fine, there are gateways that do ACK spoofing. Okay, sacrifice all header data and assume that only payload is e2e. Whoops, even the payload has to be modified by some gateways. The hypothesis that you can have these gateways and have any part of the packet be guaranteed to be e2e is false. But I don't think these gateways are evil and should (or could) be forbidden. My hypothesis is that end applications have to know that these gateways exist. They shouldn't be surreptitiously transparent; they should be discoverable and applications should be aware of how high in the protocol stack that gateway reaches. Take the hardest problem, a gateway that reaches all the way up to the application layer to do content inspection. The application has to make a trust decision about whether or not it is willing to negotiate a key with that gateway that will let it decrypt the data. Otherwise, the gateway may refuse to pass the traffic. So the application consents, a protocol library provides the gateway with a decryption key, and the application annotates the little padlock in the corner of the user's screen appropriately. If so desired, the application can implement a policy that the decrypted form of the user's credit card number won't be provided to any proxy or endpoint that doesn't have a certificate signed by Visa's credit card practices review authority. Take an intermediate problem. Assume that only address and port translation are required by the gateway. The application can therefore assume e2e payload authenticity and privacy, but cannot assume e2e privacy of its ports. So that means that the coverage and keying of IPsec and TLS needs to be negotiable based on the policies of intervening gateways (middleboxes). And that, of course, if predicated on the ability to locate middleboxes. Given our inability to rule out the need for gateways that change IP addresses (or other routing headers), this leads to the conclusion that applications shouldn't use any header field (IP address, port, etc.) for authentication. > If it turns out that we need some kind of routing identifier in the IPV6 > address, whether it's the dreaded 8+8 scheme, or adding another 16 byte > value in the header which router are free to muck with to our heart's > content, at some level, whatever, I don't care. I'm security guy, not a > routing guy, so I don't know what will work the best, and at some level, > I don't care --- just so long as it works, and that we have something > which *everyone* agrees will be an invariant end-point identifier, now > and forever, world without end, Amen. > > Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a > need for some kind of routiing-gw/NAT boxes, and people will *still* be > complaning that it's all IPSEC's fault that IPSEC doesn't work through > NAT boxes, and the anti-NAT people will be complaining that the NAT > folks have changed the rules again. And all that work which the IPV6 > rollout folks have put into that project will in the end be for naught. As far as naming (who) versus routing (where) is concerned, endpoint naming seems as problematic as user naming is for X.509, etc. Why not apply the theory that a participant can be uniquely identified (but not necessarily located) by its key(s) and that no fixed mapping to or from a globally unique name (IP address) is necessary? Let's say a user sees a billboard and wants to communicate with what the billboard calls "www.cheapwidgets.com". Given a uniformly accepted DNS root or .com TLD, I would argue that DNSSEC can provide the verifiable chain to the key known as (.com's cheapwidgets's www). It will also provide a mapping to the current routing address (which could be a point of aggregation that knows a better local address). More sophisticated directory services (or SIP servers) can provide the same secure mapping to a key and/or DNS name. -- Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab See http://home.l
Re: NATs *ARE* evil!
"Theodore Y. Ts'o" <[EMAIL PROTECTED]> writes: > It would be *awfully* convenient if we declare up front that something > is the "end point identifier" (i.e., "who"), and is forever exempt from > being changed by intermediate routing entities, and if necessary, > something is else the routing component (i.e., "where"), which can > change. This "end point identifer" should have a canonical form, which > means that using the DNS name, as some have suggested, probably isn't > ideal. For better or worse, people are too used to playing DNS games > where foo.g.akamai.com (for example) isn't necessarily the same host, > regardless of where you are in the network. This is true. To do this though really requires some re-architecting of the current Internet model, based on "first principles". In particular, there is not a sufficient "name space" for what we are often currently trying to do - hence the "akamai" type of trick. Currently we have a situation where the defined name spaces are not sufficient for truly identifying the end points of a routed connection. IP addresses are therefore there for routing purposes. However a number of situations can now occur so that the IP address is not sufficient to name all situations. A host can be multi-homed, partially disconnected or mobile and then things start getting ugly. We need to look at this. I believe that we are now already overloading the useful set of meanings that one can attach to an IP address (somewhat analogous to the presentation from Randy Bush at the plenary session on DNS). One can see actually, that some of the current issues to do with Mobility, Multi-homing, NATs and the DNS are all related to an architectural complexity that was never considered in the original architecting of the Internet. (This is not a criticism, merely an observation based on a view 20 years later). Cheers, -- John Collis - Director Technology Development IndraNet Technologies Ltd. Email: [EMAIL PROTECTED] Web: http://www.indranet-technologies.com/
Re: NATs *ARE* evil!
> > What is technically wrong with v6 that isn't already technically wrong > > with v4? > > Thank you, Perry, you've put it in a nutshell. > Noel Excellent. We've agreed that IPv6's problems are a subset of IPv4's. Now until we have a concrete design proposal for a perfect world, can we drop that particular line of taunting?
Re: NATs *ARE* evil!
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote: >The flaw in your argument is that you're assuming that the only reason >to do NAT is because of the address space problem. My concern is that >it may turn out that some transport/routing people may conclude that we >may also need to do NAT to solve the routing problem. In which case, >we're back to where we started. > >I'd feel a lot better if we could get key routing/transport people to >sign some contract in blood stating that the IPV6 address is guaranteed >to be invariant, and that any attempt to design boxes which muck with >the IPV6 address in transit is architecturally out of bounds. That may >seem to you to be obviously true, but I 10 years ago we assumed the same >would be true for IPV4 addresses. I'm not sure that this is possible - part of the characteristics of today's Internet is that its is flattening out. The concept of hierarchical connectivity with 'upstreams' and 'downstreams' is one which appears to have relied on a high marginal cost of communications services. Now as I understand the current deployment plan there are TLAs and sub TLAs, and an apparent hierarchical view of the world again. Imagine, for a second, what the topology of the Internet would be if communications services were free. Now turn up the unit cost knob an little and do the same thought experiment. Part of the issue we faced in the Big Internet discussions, and part of the issue we face now is the semantics of the address and the level to which these semantics are overloaded. Is an address an identification of identity? A key to absolute location? A key to relative location? An encoding of the local topology? My concern, and the reason why I'm chiming on Ted's signing blood proposal is that in looking at the structure of V6 addresses, at least the structure of the immediate deployment 1/4 or so of the addresses, we appear to have adopted an approach which is not far removed from the provider address hierarchy structure of V4 today. My lurking concern is that it is not working in the V4 routing system given the large percentage of table entries which are more specific advertisements of aggregate announcments (approx 40%) and it won't work for V6 either (using the term 'work' very loosely in terms of being able to route accurately, efficiently and with a clear scaling property). It appears that the intended address structure and deployment structure appear to be at variance, and when that happens the temptation to alter the address in flight to suit each local region's environment may well be overwhelming. So I'd prefer to keep my blood to myself, thanks as its a contract I suspect we'll break within the operations environment. (and no I don't think that this would be a clever move, and yes, we will regret it afterwards.)
Re: NATs *ARE* evil!
At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote: >The flaw in your argument is that you're assuming that the only reason >to do NAT is because of the address space problem. My concern is that >it may turn out that some transport/routing people may conclude that we >may also need to do NAT to solve the routing problem. In which case, >we're back to where we started. > >I'd feel a lot better if we could get key routing/transport people to >sign some contract in blood stating that the IPV6 address is guaranteed >to be invariant, and that any attempt to design boxes which muck with >the IPV6 address in transit is architecturally out of bounds. That may >seem to you to be obviously true, but I 10 years ago we assumed the same >would be true for IPV4 addresses. I'm not sure that this is possible - part of the characteristics of today's Internet is that its is flattening out. The concept of hierarchical connectivity with 'upstreams' and 'downstreams' is one which appears to have relied on a high marginal cost of communications services. Now as I understand the current deployment plan there are TLAs and sub TLAs, and an apparent hierarchical view of the world again. Imagine, for a second, what the topology of the Internet would be if communications services were free. Now turn up the unit cost knob an little and do the same thought experiment. Part of the issue we faced in the Big Internet discussions, and part of the issue we face now is the semantics of the address and the level to which these semantics are overloaded. Is an address an identification of identity? A key to absolute location? A key to relative location? An encoding of the local topology? My concern, and the reason why I'm chiming on Ted's signing blood proposal is that in looking at the structure of V6 addresses, at least the structure of the immediate deployment 1/4 or so of the addresses, we appear to have adopted an approach which is not far removed from the provider address hierarchy structure of V4 today. My lurking concern is that it is not working in the V4 routing system given the large percentage of table entries which are more specific advertisements of aggregate announcments (approx 40%) and it won't work for V6 either (using the term 'work' very loosely in terms of being able to route accurately, efficiently and with a clear scaling property). It appears that the intended address structure and deployment structure appear to be at variance, and when that happens the temptation to alter the address in flight to suit each local region's environment may well be overwhelming. So I'd prefer to keep my blood to myself, thanks as its a contract I suspect we'll break within the operations environment. (and no I don't think that this would be a clever move, and yes, we will regret it afterwards.)
Re: NATs *ARE* evil!
Date: Fri, 15 Dec 2000 19:44:18 +0100 (CET) From: [EMAIL PROTECTED] (Sean Doran) | It's already happening. Try running IPSec from one 10 network to | another 10 network. Much pain. Surely the "much pain" is because, as Melinda Shore indicates, some "anti-NAT fanatics" cannot understand the distinction between "who" and "where"? Historically, the IPv4 address specified "who", and not necessarily "where". NAT, for better or for worse, represents an attempt to change that historical understanding. Some would say that it is a fiat acompli, and we should just live with it. Others would say it's NAT's fault for trying to change the rules in the middle of the game. Regardless of who's "right" with respect to that argument, I'd argue that it's not productive to dwell on it. I am personally much more interested in making sure this ambiguity doesn't arise with IPv6, since even though it's fairly late in the game, we have more of a chance of fixing things here since there's much less of a deployed base. It would be *awfully* convenient if we declare up front that something is the "end point identifier" (i.e., "who"), and is forever exempt from being changed by intermediate routing entities, and if necessary, something is else the routing component (i.e., "where"), which can change. This "end point identifer" should have a canonical form, which means that using the DNS name, as some have suggested, probably isn't ideal. For better or worse, people are too used to playing DNS games where foo.g.akamai.com (for example) isn't necessarily the same host, regardless of where you are in the network. The buttom line is that we need *something* which can unambiguously serve as an end point identifier. Is it the IPV6 address? It's big enough that we probably won't have to play NAT games to gain address space. On the other hand, I've heard claims that the routing folks want to reserve the right to muck with parts of the IPV6 address to make their job easier --- which is fine, but tell us which part in advance, so we can only protect the end-point identifier part of the address in protocols like IPSEC. Other people claim that the DNS address should be the unambiguous end point identifier. But that has problems, as discussed above. NAT merely exposes and exacerbates the perceptual problem, leading to bruised knees. Indeed. And regardless of who's at "fault" for creating this particular problem, the scary part is that it's not at all obvious to me that we've fixed it for IPV6. As near as I can tell the ambiguity of what everyone will agree is something we can use as an endpoint identifer remains. The only question is (and I don't have an answer), are we too late to try fixing it now? - Ted
Re: NATs *ARE* evil!
From: "Perry E. Metzger" <[EMAIL PROTECTED]> Date: 17 Dec 2000 13:32:03 -0500 It certainly takes more. The amount of NAT equipment out there is astonishing, and as I said at the plenary, people are starting to pay Real Money (as in millions a year) in large organizations to keep the NATs working properly. Several layers of NAT has become common, and NATs are stateful, which means they are necessarily more of a reliability problem than routers. v6 is really no harder to use than the old v4 pre-NAT network was. It is true that v6 qua v6 does not solve the route explosion problem. It is also true that the route explosion problem is a real problem. However, it doesn't make it worse, either. Perry, The flaw in your argument is that you're assuming that the only reason to do NAT is because of the address space problem. My concern is that it may turn out that some transport/routing people may conclude that we may also need to do NAT to solve the routing problem. In which case, we're back to where we started. I'd feel a lot better if we could get key routing/transport people to sign some contract in blood stating that the IPV6 address is guaranteed to be invariant, and that any attempt to design boxes which muck with the IPV6 address in transit is architecturally out of bounds. That may seem to you to be obviously true, but I 10 years ago we assumed the same would be true for IPV4 addresses. If it turns out that we need some kind of routing identifier in the IPV6 address, whether it's the dreaded 8+8 scheme, or adding another 16 byte value in the header which router are free to muck with to our heart's content, at some level, whatever, I don't care. I'm security guy, not a routing guy, so I don't know what will work the best, and at some level, I don't care --- just so long as it works, and that we have something which *everyone* agrees will be an invariant end-point identifier, now and forever, world without end, Amen. Otherwise, 5-7 years from now, we'll be using IPV6, and there will be a need for some kind of routiing-gw/NAT boxes, and people will *still* be complaning that it's all IPSEC's fault that IPSEC doesn't work through NAT boxes, and the anti-NAT people will be complaining that the NAT folks have changed the rules again. And all that work which the IPV6 rollout folks have put into that project will in the end be for naught. - Ted
Re: NATs *ARE* evil!
> > You know, concerns over global name spaces and architectural purity are > valid to the engineer/operator. But to Joe User who just got his first > cable modem and got rid of AOL, he just wants to connect his computer > to the Internet. Then he wants to share that connection with his kids' > computer and their $50 e-bay printer server. > > That's why so many of the little NAT gadgets are sold. Because Joe User > doesn't want to shell out extra bucks for more IP addresses and Joe > User needs simplicity. > > Also _most_ average users just want to browse the web, get their email, > download software, and maybe exchange music files. > > It is up to the networking professionals to make sure Big Company X and > Big Company Y connect when and where they have to. But its up to Joe > User to manage his home network. > > Lets try to at least make that simple for Mr. and Mrs. Joe User. Funny. I believe that is why the cable companies are giving each user 5 or 6 IP addresses. To make it easy so that the end user doesn't need to know how to manage a NAT. The answer is to give people the address space they need, not force them to understand the subtle problems that are caused by the use of NATs. You have no idea how many students complain that they can't access campus services due to the fact that Kerberos can't work through a NAT. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. SSH soon to follow.
Re: NATs *ARE* evil!
Perry E. Metzger wrote: > They can't avoid it. They need to get their work done. They have no > way of getting registered addresses. They're told to use NAT by > organizations like ARIN, and so they do the only thing they can. I have a hard time believing ARIN is telling people to use NAT, when the customer intends these hosts to have "external visibility". I can believe ARIN would send you to an ISP for small address blocks. I can also believe companies don't want to pay the fees, and instead use NAT to reduce the cost. If ARIN is indeed refusing requests, on what basis are requests being granted or refused? By the use of the addresses (e.g. .org versus .com)? Are these requests for "IPv4 ISP Registration" or "Individual IPv4 Address Space Assignment to End Users"? Perry, can you provide some more details on what happened, or is this just what you were told by an ISP? > Anyone notice how odd the growth charts look for the v4 allocation > space? It is because we've already run out of addresses, folks -- or > at least we're acting as though we have. I think that is exactly it; we are acting as though we've run out of addresses. I've yet to hear of a significant effort to "reclaim" unused addresses. Recovering a single class A picks up 16 million addresses. Until such an effort occurs, I refuse to believe the address space is truely exhausted. And if the address space isn't gone, I don't see any justification for refusing reasonable requests. Now whether we can route all of these addresses is another (much different) question. And if people aren't bothering to request addresses because of routing issues, fine. Let's say that instead of saying we are out of addresses. Granted, when addresses really start getting tight, and if the next generation technology isn't ready, I can see the justification for refusing some requests. But then I'd expect a well defined criteria describing how these decisions are being made. Tony
Re: NATs *ARE* evil!
--- Sean Doran <[EMAIL PROTECTED]> wrote: > Keith Moore writes: > > | but I'm fairly convinced that we are *far* better off with a global > | name space for network attachment points, which are exposed and > | visible to hosts and applications, than we are with only locally > | scoped addresses visible to hosts and applications > > Out of curiosity, do you (as a hosts and applications person) > really care what is in use in the network(s) between > the network attachment points in question, if the edges > of the network all have the properties in your lines above? > > Sean. You know, concerns over global name spaces and architectural purity are valid to the engineer/operator. But to Joe User who just got his first cable modem and got rid of AOL, he just wants to connect his computer to the Internet. Then he wants to share that connection with his kids' computer and their $50 e-bay printer server. That's why so many of the little NAT gadgets are sold. Because Joe User doesn't want to shell out extra bucks for more IP addresses and Joe User needs simplicity. Also _most_ average users just want to browse the web, get their email, download software, and maybe exchange music files. It is up to the networking professionals to make sure Big Company X and Big Company Y connect when and where they have to. But its up to Joe User to manage his home network. Lets try to at least make that simple for Mr. and Mrs. Joe User. __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: NATs *ARE* evil!
Keith Moore writes: | but I'm fairly convinced that we are *far* better off with a global | name space for network attachment points, which are exposed and | visible to hosts and applications, than we are with only locally | scoped addresses visible to hosts and applications Out of curiosity, do you (as a hosts and applications person) really care what is in use in the network(s) between the network attachment points in question, if the edges of the network all have the properties in your lines above? Sean.
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, RJ Atkinson type d: >>At 13:32 17/12/00, Perry E. Metzger wrote: >>From an operator perspective, supporting *2* IP protocols >>is much harder than supporting just one. If one looks around, >>very few NOCs on the planet today could reasonably be called >>"fully successful" just managing IPv4. lets not forget that supporting IP at all is counter intuitive - the business case for providing interconnectivity to _other_ peoples services is not there, unless they are already - it requires socialist (i.e. government subsidy) to make the internet what it is now - i am betting that most telco-child ISPs love NATs and simialr technology coz they promote walled gardens (like wap etc) and lock in and all that old stuff, BUT the only way out of this deadend that is IP v4 requires either OneBigIsp to take the plunge as a way of getting more check marks on their service, or as a way of getting an even bigger wall aroudn their garden (e.g. 3G guys might consider this:-), OR it requires some sort of socially responsible behaviour (e.g. most the 6bone is probably subsidized) to glop it all together and just make it inevitable(this is not specially a v6 plug, just a plea for connectivity) >>So, if one wanted IPv6 to be promoted by operators, >>one might spend time listening to operators and devising >>clever ways to make multi-homing and routing work visibly >>*better* with IPv6, to compensate for the much increased >>operational burden. Oddly enough, some folk are doing just >>this. indeed - we might as well work with what we have - hey, there's a lot of stuff one can do with the code still, including just re-writing a lot of cruft in routing code - btw, the way 3G access networks work, one ought to be able to mandate for really good aggregation - i think a lot of people forget that the exponential growth curve of the internet is not made out of homogeneous pieces - its actually a series of technology changes - the phases from government and unviersity and dial up, and dsl, and cable modem, and now mobile are all subtly different (as witness they have their own ISP cultures and own address allocation and routing headaches) - while datagram is one size fits all as a way of communicating, we need a range of address alloc and routing techniques for the different and future access and core networksi thought most this was discussed in the whole ipng debate and was why we solicited input so widelyso now lets go (finish) coding it cheers jon
Re: NATs *ARE* evil!
Daniel Senie <[EMAIL PROTECTED]> writes: > I'd read that RIPE is at least making micro-allocations available. The > ability to get a few /27 allocations can REALLY help in cross-connecting > corporations which find themselves needing private interconnects. It can help, but it is hardly sufficient. There are hundreds of servers involved in some of the systems I've seen. Thirty addresses won't usually cut it. In the end, we need more address space, and that means v6. -- Perry E. Metzger[EMAIL PROTECTED] -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/
Re: NATs *ARE* evil!
"Steven M. Bellovin" wrote: > > In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes > : > > >I mean, I can understand it is a temporary thing, e.g. if one company buys > >another, and in gluing the networks together they temporarily leave the > >bought company behind a NAT, but interface it to the world via the main > >corporation's gateway/NAT. But using a NAT box adds a ration of complexity > >(which is always bad and a source of potential problems), and using layers of > >them increases the complexity, with attendant complexity costs. I have a hard > >time understanding why people would add that much complexity, without a > >darned good reason. > > > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play > >with (how many, exactly, depends on how you're doing it). This is puzzling to > >me - what configurations are there out there that demand more address space, > >internally, than you already get with one layer of NAT box? Or is there some > >other reason I haven't figured out to have layers of address space? > > Generally, this happens not because of an address shortage, but because > of unforeseen interconnections between NATted sites. I'd read that RIPE is at least making micro-allocations available. The ability to get a few /27 allocations can REALLY help in cross-connecting corporations which find themselves needing private interconnects. These micro-allocations are not routed globally, but rather are used to ensure unique numbers are available for private interconnects. ARIN would do well to offer such at low cost. Or perhaps someone should gather up a bunch of allocated /24 nets which have been out there and aren't in use, and set up an interconnect registry to hand out /27s or /29s and rent them to those who need this type of private interconnect. -- - Daniel Senie[EMAIL PROTECTED] Amaranth Networks Inc.http://www.amaranth.com
Re: NATs *ARE* evil!
> > if you try to build a global network out of limited-scope addresses you > > eventually end up reinventing IP at a higher layer. > > Err, did you perhaps mean "end up reinventing globally unique addresses > somewhere else in the system"? :-) No. I considered whether reinventing something more-or-less like IP was more likely than merely reinventing globally unique addresses, and decided that it was...though it also seems likely that the "reinvented" IP would be far less efficient than the one we have now. note however that this reflects my expectations/intuitions about what would be likely to happen, not what I think would be an ideal path. but I'm fairly convinced that we are *far* better off with a global name space for network attachment points, which are exposed and visible to hosts and applications, than we are with only locally scoped addresses visible to hosts and applications - and this is regardless of whether we separate host identity from network location or not. Keith
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes : >I mean, I can understand it is a temporary thing, e.g. if one company buys >another, and in gluing the networks together they temporarily leave the >bought company behind a NAT, but interface it to the world via the main >corporation's gateway/NAT. But using a NAT box adds a ration of complexity >(which is always bad and a source of potential problems), and using layers of >them increases the complexity, with attendant complexity costs. I have a hard >time understanding why people would add that much complexity, without a >darned good reason. > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play >with (how many, exactly, depends on how you're doing it). This is puzzling to >me - what configurations are there out there that demand more address space, >internally, than you already get with one layer of NAT box? Or is there some >other reason I haven't figured out to have layers of address space? Generally, this happens not because of an address shortage, but because of unforeseen interconnections between NATted sites. --Steve Bellovin
Re: NATs *ARE* evil!
"J. Noel Chiappa" <[EMAIL PROTECTED]> writes: > > From: "Perry E. Metzger" <[EMAIL PROTECTED]> > > > Several layers of NAT has become common > > This is have a hard time fathoming - not that I'm doubting that people do it, > mind. Imagine a large number of companies talking to each other -- the sort of situation you have when, say, you have a large clearing and settlement operation on Wall Street that has decided to speak TCP/IP to its clients. Now, imagine also that the clearing house doesn't have real IP addresses -- after all, you're always told these days to use net 10 when you go to the registries and aren't going to be globally routing your nets -- and that the other firms also use unregistered addresses -- frequently, the same ones. Well, you have to talk, so you use NAT. Now, imagine that those clients have to access a service you are reselling -- say, some sort of market data or specialized clearing information. That service is also delivered over TCP/IP, and also over unregistered addresses. Packets start having to traverse several address zones, just within the network obvious to the clearing organization. Now, assume that there are a couple of address zones within the client site for whatever reason, so they're using NAT internally. Now, further assume that through various remote access schemes, you have to provide access to this mess over the "real" internet. Another layer of NAT gets added. Are you starting to see the nightmare that has been created here? None of this is theoretical. This stuff is really happening. > I mean, I can understand it is a temporary thing, e.g. if one company buys > another, and in gluing the networks together they temporarily leave the > bought company behind a NAT, but interface it to the world via the main > corporation's gateway/NAT. Unfortunately, multiple organizations like to talk to each other over their networks. Funny, that. Now, you'd imagine if a Large Market Data Provider, say, went to ARIN to ask for addresses, they'd get them, but they in practice don't -- they're told to use net 10 since their stuff isn't globally routed -- and of course all their customers use net 10 too... > But using a NAT box adds a ration of complexity (which is always bad > and a source of potential problems), and using layers of them > increases the complexity, with attendant complexity costs. I have a > hard time understanding why people would add that much complexity, > without a darned good reason. They can't avoid it. They need to get their work done. They have no way of getting registered addresses. They're told to use NAT by organizations like ARIN, and so they do the only thing they can. Why do you think we're seeing huge sales of routers but somehow we haven't run out of v4 address blocks? It isn't because people are using those routers as heating equipment. It isn't because those people wouldn't prefer to get registered addresses, too. Anyone notice how odd the growth charts look for the v4 allocation space? It is because we've already run out of addresses, folks -- or at least we're acting as though we have. I've seen as many as four layers of NAT. (That was only once, and not all the layers were within a single organization.) Two layers is routine, three less so. I'm making assumptions here, of course -- you don't know what's really going on inside the other organizations. For all I know, the packets I think are coming in from the other guy's net 10 are originating behind another layer of NAT or two. Hard to tell. It is impossible for *me* to try to figure out what is going on in such situations without a diagram. Imagine what it is like for ordinary NOC staff? And consider that NAT boxes are stateful. When they go, they take out long lived connections, unlike dead routers, which you can simply route around. And consider what happens when you suddenly discover that you need to re-jigger your whole nightmarish rube goldberg network because suddenly you have to make that net you never thought would have to talk to the internet show up on the net and you only have a couple of /24s you can get your hands on and have to push some of the stuff that's globally routed back into the private world somehow... None of this is theoretical. I've seen all of this. It is astonishing how hard it has all become. As I've said, millions are being spent a year by large organizations dealing with failures and complexity attributable to NAT. To the routing heads out there, v6 is a total failure because it doesn't solve the routing problem. I hear people like Sean Doran say "NAT is fine". That's because to the routing people and ISPs, the ugly stuff that happens at the endpoints of the networks is immaterial. ISPs get the global address blocks they want -- why do they care about the rest? Well, as things stand, we're having serious bad trouble happening at the edges of the net. NAT being a major source of operational trouble, failure and cost is not a futur
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, "J. Noel Chiappa" writes : > >I mean, once you're behind a NAT box, you've got a *lot* of addresses to play >with (how many, exactly, depends on how you're doing it). This is puzzling to >me - what configurations are there out there that demand more address space, >internally, than you already get with one layer of NAT box? Or is there some >other reason I haven't figured out to have layers of address space? Most *DSL providers only give you one or two addresses; some of them are even NAT'ed, which forces a small company (or something like my home network) to use a double-NAT. -Angelos
Re: NATs *ARE* evil!
> From: "Perry E. Metzger" <[EMAIL PROTECTED]> > Several layers of NAT has become common This is have a hard time fathoming - not that I'm doubting that people do it, mind. I mean, I can understand it is a temporary thing, e.g. if one company buys another, and in gluing the networks together they temporarily leave the bought company behind a NAT, but interface it to the world via the main corporation's gateway/NAT. But using a NAT box adds a ration of complexity (which is always bad and a source of potential problems), and using layers of them increases the complexity, with attendant complexity costs. I have a hard time understanding why people would add that much complexity, without a darned good reason. I mean, once you're behind a NAT box, you've got a *lot* of addresses to play with (how many, exactly, depends on how you're doing it). This is puzzling to me - what configurations are there out there that demand more address space, internally, than you already get with one layer of NAT box? Or is there some other reason I haven't figured out to have layers of address space? Noel
Re: NATs *ARE* evil!
At 12:37 PM 12/17/2000 -0500, J. Noel Chiappa wrote: >It's hard to put numbers on it without knowing what %-age of sites which are >already globally advertised has more that one prefix, and how fast that >number is growing. However, looking at the routing table growth (it has >doubled in about 3 years), and given the growth in the user community over >that time, one has to expect that the growth in the user community is the >driver. This is probably true. The data seem to support it. The increase in prefixes due to stingy allocation policies apparently has been more than cancelled out by the decrease in prefixes (presumably) due to better aggregation. The number of prefixes per AS has been trending downward: http://www.telstra.net/ops/bgp-entries-as.html while the number of ASes has been increasing: http://www.telstra.net/ops/bgp-as-count.html Bradley
Re: NATs *ARE* evil!
Keith Moore writes: | if you try to build a global network out of limited-scope addresses | you eventually end up reinventing IP at a higher layer. Correct, that's (some of) the point of CATNIP (RFC 1707): you construct a network layer out of a virtual superset of the component internets' address spaces. Simple translations can avoid burning huge numbers of bits in the "CATNIP" (the super-internet address space) as well as providing a host-to-network interface, a network-to-super-network interface, and so forth. 1707 itself is simply an example of one of many possible CATNIPs that can coexist simultaneously in different parts of a global Internet. The important thing for the flexibility to handle multiple simultaneous disjoint network layer protocols is a session layerish "who" namespace disjoint from the various routing namespaces of various scopes, yet which in any scope can be used to look up a locally-relevant hni/nsni/nni "label", yet is used end-to-end for demuxing and other purposes that require the mutual identification of endpoints. IPv6 makes a perfectly reasonable host-to-network interface, as many people have indicated based on experiences posted to this list. It would make a better one if it separated "who" from "where". If it does so sensibly, it could even make a half-decent in-network protocol, although more importantly, it would readily coexist with better-tuned network layers within a super-Internet. Sean.
Re: NATs *ARE* evil!
> From: Keith Moore <[EMAIL PROTECTED]> > if you try to build a global network out of limited-scope addresses you > eventually end up reinventing IP at a higher layer. Err, did you perhaps mean "end up reinventing globally unique addresses somewhere else in the system"? :-) Noel
Re: NATs *ARE* evil!
> The vitriol that will be poured on this is from reactionaries > who seek to preserve the indistinction between who and where, I don't know anyone who seeks to preserve this indistinction; however, I know several folks who are realistic about the difficulties of separating the two. > and who seek genetic purity of the network layer (i.e., the address > doesn't change at any border, implying the same protocol in use > everywhere). again, 'genetic purity' is a gloss over the real and significant technical justifications for a global network address space - many of which remain even if you do separate identify from network location. if you try to build a global network out of limited-scope addresses you eventually end up reinventing IP at a higher layer. Keith
Re: NATs *ARE* evil!
At 13:32 17/12/00, Perry E. Metzger wrote: >It is true that v6 qua v6 does not solve the route explosion >problem. It is also true that the route explosion problem is >a real problem. However, it doesn't make it worse, either. From an operator perspective, supporting *2* IP protocols is much harder than supporting just one. If one looks around, very few NOCs on the planet today could reasonably be called "fully successful" just managing IPv4. So, if one wanted IPv6 to be promoted by operators, one might spend time listening to operators and devising clever ways to make multi-homing and routing work visibly *better* with IPv6, to compensate for the much increased operational burden. Oddly enough, some folk are doing just this. Ran [EMAIL PROTECTED]
Re: NATs *ARE* evil!
Jon Crowcroft writes: | anyhow, i think the old 8+8 v6 scheme would have sorted this out just | dandilyand i dont understand the vitriol people our on it - I don't understand alot of the vitriol, but I personally am concerned that 8 bytes is insufficient. If there was ever a time-space trade-off that should favour more space, it's addresses in future networks that require packet order to be maintained (at least within individual flows). Clearly there are other bits of a size-large Internet which will be many orders of magnitude slower in terms of pps and bps, exposing the fact that no given space-versus-compute-time tradeoff in packet headers will satisfy everyone. Result: RFC 1707 redux. The VLA arguments, with "tunable" address lengths (to some maximum) is an interesting compromise with people who have trouble coping with arbitrary address-length variability, but I think CATNIP's scheme is just as good, allowing for "tunable" networks, some of which may choose to find an appropriate per-packet space-for-compute-time tradeoff. The vitriol that will be poured on this is from reactionaries who seek to preserve the indistinction between who and where, and who seek genetic purity of the network layer (i.e., the address doesn't change at any border, implying the same protocol in use everywhere). My bet is that at least some of the 8+8 opponents realize that a move away from current IPv6 + strict CIDR + single namespace on either of the latter two vectors inevitably leads to a system which encourages fractional and ongoing obsolescence of IPv6 itself, perhaps even before it's widely deployed. Sean.
Re: NATs *ARE* evil!
Keith Moore <[EMAIL PROTECTED]> writes: > > to make v6 work tarks end users more work than v4 > > if "v4" includes dealing with an increasingly severe shortage of > address space (which sooner or later implies forced renumbering) > and/or tying together multiple NATted networks, it's not at all > clear that this takes less work than v6. It certainly takes more. The amount of NAT equipment out there is astonishing, and as I said at the plenary, people are starting to pay Real Money (as in millions a year) in large organizations to keep the NATs working properly. Several layers of NAT has become common, and NATs are stateful, which means they are necessarily more of a reliability problem than routers. v6 is really no harder to use than the old v4 pre-NAT network was. It is true that v6 qua v6 does not solve the route explosion problem. It is also true that the route explosion problem is a real problem. However, it doesn't make it worse, either. Perry
Re: NATs *ARE* evil!
> From: Bradley Dunn <[EMAIL PROTECTED]> > I do think that there is a definite causal relationship between the > address space shortage and the number of prefixes in the routing tables. > People who allocate addresses .. use slow-start algorithms in their > allocation policies due to the shortage of addresses. Therefore many > organizations end up announcing several non-aggregatable prefixes .. > .. If everyone could get "enough" addresses the first time, we'd be > much closer to the ideal of one prefix per AS. You do have a valid point - that the address shortage is causing people to have multiple prefixes. However, do realize that when you do an O(N) analysis on the various factors that are causing the growth in the routing table, this particular one is causing more of an O(C) factor (since most organizations with more than one prefix would have a reasonably limited number of them), or maybe O(growth-rate-of-individual-organization) [which in most cases is going to be pretty small - ISP's adding a lot of customers would be one exception]. In other words, the exponential shape of the routing table size cannot be due to an O(C) or O(average-growth-of-individual-organization) factor. The bulk of the growth in the table has to be due to the growth in the network population as a whole, i.e. the sheer number of organizations attached to the network (which is growing at a much faster rate than any individual organization) - and in particular those which are becoming multi-homed. It's hard to put numbers on it without knowing what %-age of sites which are already globally advertised has more that one prefix, and how fast that number is growing. However, looking at the routing table growth (it has doubled in about 3 years), and given the growth in the user community over that time, one has to expect that the growth in the user community is the driver. Yes, the point you mention will have put something of a multiplier on the table size - but it's a relativly static multiplier, I expect. Noel
Re: NATs *ARE* evil!
> to make v6 work tarks end users more work than v4 if "v4" includes dealing with an increasingly severe shortage of address space (which sooner or later implies forced renumbering) and/or tying together multiple NATted networks, it's not at all clear that this takes less work than v6. Keith
Re: NATs *ARE* evil!
> From: "Perry E. Metzger" <[EMAIL PROTECTED]> > What is technically wrong with v6 that isn't already technically wrong > with v4? Thank you, Perry, you've put it in a nutshell. Noel
Re: NATs *ARE* evil!
>>I understand that there are pressures to do multihoming, but I just don't see >>how NAT (i.e. address sharing) is having much effect one way or the other on >>the intensity of the pressure to do multi-homing. NATs allow users to be irresponsible about the addressing since they dont require you to multihome hosts, but dynamically pick which way to enter and leave your domain - this means people can be stupid and run multihomed. for example. incentives are important wen resources are scarce y'know:-) anyhow, i think the old 8+8 v6 scheme would have sorted this out just dandilyand i dont understand the vitriol people our on it - antyhing else (liek yo usuggest coordinaging the addresses allocated to NATs on the outside so they aggregate ) is the SAME thing. involves the same requirements for a protocol to coordinate it nats for securtyy thru obscrurity are about as relavent to real security failures and risk and loss of face and revenue as postits on your keyboard saying do not touch...the most common failure we get is via applicatio nlevel messes (e.g. mail attachements) and user education is the only way to solve those. but of course, with pip cheers jon
Re: NATs *ARE* evil!
In message <[EMAIL PROTECTED]>, Sean Doran typed: >>Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT? > >>I didn't realize that, when I asked the IAB to use their technical insights >>as a market predictor, that behind the invisible hand of the marketplace >>lurks little ol' me. Maybe someone should tell Paul Krugman. Pagan God of Market Forces... oh thats no good - i want to speak to the 21st century god of market forcesand of course, she retired as uk primeminsiter a while back... so NATs address a user requirement as WELL as a network provider requirement - for example, asymwetric nats let the user get away with sloppier security (not just think they can ) by reducing the available services of course you could argue the same for ipv6 given your view that noones useing it in that unlike an asymetric nat (i can reach you but you can't reac me) v6 is symettreic in its ability to disable people :-) but fantasy aside, ipv6 involves _routing_ as well as addressing - NAT reduces the problem space for providers and users by reducing the number of services reachable - so? thats not exactly comparing things on a level playing field is it? to make v6 work tarks end users more work than v4 (they have to (re(re)-number) and worry about security policies properly) and takes router vendors some work to write some working code (something they have few people left able to do - sure everyone else has fewer still)). so it isnt surprising that one has seen more deploym,ent than the other , but it is not a measure of the releative (de)merits of NATs and ipv6 thats just in yr. head cheers jon i'd like to think we could talk about technical things we CAN do to maintain and increase connectivity, as well as retaining or decreasing the ease of config for an end user - to some extent, its one of those threshold things - despite its shortcomings, if people can get over the v6 threshold, it might sort things out provided a half way decent addressing plan AND retaining NAT type functionality for various reasons.of course there's multihomeing to worry about, but nothing in any other scheme 've seen sorts this - its an inherently hard problem to provide "always on" addresses, aggregation/hierarchy for scaling, and multihomeing - some sort of set theory #101 makes this obvious... j. p.p.s why has noone addressed my replace the DNS comment ? :-)
Re: NATs *ARE* evil!
At 02:28 AM 12/17/2000 -0500, J. Noel Chiappa wrote: >To put it another way, let's imagine an alternate reality in which IPv4 had >48-bit addresses - enough so pretty much everyone could get as many as they >wanted, and nobody used NAT boxes because they couldn't get enough addresses. >Now, think about what the routing table would look like in that alternative >reality. I expect it would have pretty much the same number of entries as we >do now - but on average, each entry would be "bigger". > >In other words, the routing system may be running into problems, but those >problems have basically nothing to do with the address space shortage, and the >measures taken to deal with it (i.e. NAT). (I'll leave unstated the obvious >corollary - I'm sure Perry will figure it out! :-) I'm with you in that I do not see a causal relationship between the availability and deployment of NATs and the increase in routing table size. However, I do think that there is a definite causal relationship between the address space shortage and the number of prefixes in the routing tables. People who allocate addresses (registries and ISPs) use slow-start algorithms in their allocation policies due to the shortage of addresses. Therefore many organizations end up announcing several non-aggregatable prefixes which they have acquired over time. If we did have an address space where "pretty much everyone could get as many [addresses] as they wanted," there would be fewer prefixes in the routing tables. If everyone could get "enough" addresses the first time, we'd be much closer to the ideal of one prefix per AS. Bradley
Re: NATs *ARE* evil!
"J. Noel Chiappa" <[EMAIL PROTECTED]> writes: > > From: "Perry E. Metzger" <[EMAIL PROTECTED]> > > > you're ideologically opposed to deploying v6 instead of against it for > > technical reasons? > > Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to > control of the means of production by the workers. > > And here I was, all these years, thinking there were all these technical > things wrong with IPv6. Oh well, I guess I wasn't very perceptive. What is technically wrong with v6 that isn't already technically wrong with v4? v6 doesn't claim to be a universal cure. It claims to fix a specific problem -- the exhaustion of IP addresses. No, it doesn't fix the routing table problem. Unfortunately, we don't know how to do that particularly elegantly yet. I'm not very convinced that you know either, Noel. I used to believe I was merely ignorant when I heard claims from "my betters" to the effect that there were techniques we were ignoring that would magically fix everything, but once I actually did things like reading the papers in question, I'm afraid I stopped believing. -- Perry E. Metzger[EMAIL PROTECTED] -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/
Re: NATs *ARE* evil!
[EMAIL PROTECTED] (Sean Doran) writes: > Perry Metzger writes: > > | Maybe because I hear from folks like you and others that you're > | ideologically opposed to deploying v6 instead of against it for > | technical reasons? > > You have never heard this from me. > > I have no doubt whatsoever that you have heard this from others > speaking about me. This probably includes your own inner voices. Dunno. Some people at carriers are experimenting with it, some of them seem to spend all their time being sarcastic and finding silly things to say. Luckily, we no longer need your help. > IPv6 is architecturally flawed in precisely the same way as IPv4 > is; it simply has 4x the number of binary digits in the address fields > and some minor cleanups which were important some years ago. Sure. On the other hand, it has four times more bits in the address field, and at the moment, we desperately need those bits. It is costing us truly astronomical sums not to have those bits. It does not solve the routing problem. It doesn't solve world hunger either. And your point is? (On the routing problem, the sad truth is that in spite of claims for years by you and others, there are no magic solutions to the routing problem. Blaming IPv6 for not incorporating the non-existent magic solution is rather like blaming IPv6 for not incorporating the non-existent magic cancer cure. I used to believe you and others who made vague claims about various architectures, and then I spent some time reading up on them, and I realized that none of them did particularly better.) .pm -- Perry E. Metzger[EMAIL PROTECTED] -- Quality NetBSD CDs, Support & Service. http://www.wasabisystems.com/
Re: NATs *ARE* evil!
> From: Geoff Huston <[EMAIL PROTECTED]> >> [NAT's] shouldn't have any effect on the *number* of [address] >> blocks (i.e. things which can potentially produce global routing table >> entries). >> ... So the number of distinct "local areas" is still the same, yes? >> And NAT's should, all else being equal, not have a negative effect on >> the aggregatability of those addresses. > well I fail to see that - how does a NAT gateway gain the appearance of > greater resiliency of service supply. Sorry, I didn't follow what you meant by that. Let me press on... > With NAT all addresses are not exactly equal as some are used as the > front address for an arbitrarily large number of concealed end device > addresses. The pressures to using multihoming of a prefix that > enconmpasses the NAT gateway does appear to be quite common. I understand that there are pressures to do multihoming, but I just don't see how NAT (i.e. address sharing) is having much effect one way or the other on the intensity of the pressure to do multi-homing. I'm not trying to be argumentative or rhetorical here, but I've carefully read your whole message, and I genuinely don't see anything that I can latch onto as a mechanism for what you reckon is going on, and I'd like to figure it all out. You said "some [addresses] are used as the front address for an arbitrarily large number of concealed end device[s]" - but how/why would the pressures you mention be any less if each host had its own permanent address? Are you saying that since the NAT box is necessarily a choke point (since we don't yet have, AKAIK, distributed NAT, where the translations are maintained in parallel in a number of different devices), there's more pressure to multi-home it to increase its reliability? If so (and my apologies if I'm making an incorrect guess), I think it's an incorrect analysis of the situation to say that the pressure to multi-home (and this, the impact on the routing) exists because it's a NAT box. To see this, consider the case where the site has all the addresses it needs, and there's no NAT at all. There are two alternative sub-cases. First, the site has one exit router - but I would imagine that in this case people want it multi-homed for reliability, just as they would with the single NAT box. How does this have any consequences for the routing which is different from the NAT case? The only difference is the "size" of the route - it'll be a /16 (to pick a random size), instead of the /22 (or whatever) with the NAT box. Second, let's assume instead that there are multiple exit routers. Again, each has to advertise those internal addresses - so again, we've still got a route being propogated over a large scope - only, just like the previous case, it's a /16 (say) instead of a /22 (say). > Unless of course you have evidence to present to suggest the contrarfy > is taking place? No, I gather a fair amount of multihoming is taking place, and of course that is causing the number of routes to grow, but I don't see how NAT i) has anything to do with the amount of multi-homing going on, or ii) how the NAT multi-homed case is any different, *in terms of the impact on the routing* (other than the *size* of the route), from the non-NAT multi-homed case. >> E.g. if provider X has a /12 out of which they have to support N >> customers, without NAT they'd have to give each customer, say, a /18; >> but with NAT, each customer can get a /22. > As far as I have seen things, its the customer who is using NAT, not > the provider. Of course - but the point is, for the people who are using NAT boxes because they can't get enough addresses (which, I gather from this thread, is a large share of the people using NAT), *iff* the provider could give them whatever size address block the customer needed/wanted, there'd be no incentive for them to deploy a NAT box (with all its hassles/problems, etc), no? I'm not blaming the providers, but it's a fact of life, is it not, that they can't give every customer all the addresses those customers want? > I think you may have missed my point that the motive for multihoming a > small prefix is far greater for a NAT network than a small non-NAT > network. Of course - that's because there are more hosts behind a small prefix that is NAT'ed than behind a small prefix that's not NAT'ed. But you seem to be assuming that because the NAT'ed entries are small, they "should" act like other small entries - *and that it's NAT's fault if they don't*. Neither one of these are accurate. It is certainly the case that in a network with NAT boxes, for that subset of routes which refer to destinations behind a NAT box, those prefixes will be smaller *than they would be without NAT boxes*. However, I see no reason to think that without NAT there would be any *fewer* routes - and as you know, it's the total number of routing entries which
Re: NATs *ARE* evil!
At 12/16/00 10:02 PM -0500, J. Noel Chiappa wrote: > > From: Geoff Huston <[EMAIL PROTECTED]> > > > There are strong indications that NAT is one factor behind this part of > > the BGP table. > >I'm afraid I'm missing the logic here. As you point out below, NAT's may have >caused people to use *smaller* blocks of the global address space: > > > much of the recent growth in the deployed Internet has happened behind > > NATs of various forms and the side effect is low levels of overall > > address space growth as reflected in the span of address space > > advertised in the BGP tables > >but they shouldn't, assuming all else being equal (a possibly bad assumption, >as I'll note below), and I believe that this possibly bad assumption is indeed a probably bad assumption as I;'ll note below as well. > have any effect on the *number* of blocks (i.e. things >which can potentially produce global routing table entries). The blocks are >just smaller, again as you point out: > > > but an increasing finer level of granularity in the routing table. > >So the number of distinct "local areas" is still the same, yes? And NAT's >should, all else being equal, not have a negative effect on the >aggregatability of those addresses. well I fail to see that - how does a NAT gateway gain the appearance of greater resiliency of service supply. With NAT all addresses are not exactly equal as some are used as the front address for an arbitrarily large number of concealed end device addresses. The pressures to using multihoming of a prefix that enconmpasses the NAT gateway does appear to be quite common. Unless of course you have evidence to present to suggest the contrarfy is taking place? >E.g. if provider X has a /12 out of which they have to support N customers, >without NAT they'd have to give each customer, say, a /18; but with NAT, each >customer can get a /22. As far as I have seen things, its the customer who is using NAT, not the provider. I'd be interested in seeing further details of a provider model as suggested in the above lines, as its relatively novel to me. > But there are still the same number of subsidiary >blocks (i.e. N sub-blocks), and outside X they can, all else being equal, >still be aggregate into that single /12. > >Now, if some subset M of those customers are multi-homed, so you can't >aggregate into a single /16, that's an issue - but that has nothing to do >with NAT - it has to do with the multihoming. The effect on the routing table >is the same, whether those people are behind NAT boxes or not. I think you may have missed my point that the motive for multihoming a small prefix is far greater for a NAT network than a small non-NAT network. >Am I missing something? hard to say. >There are some second-order ways in which NAT boxes might actually help >aggregation, now that I think about it. > >The simplest one is when customers switch providers, and don't want to >renumber. E.g. company X is a customer of ISP P, and has addresses (either >from P, or their own). X switches to ISP Q, which wants them to renumber >so they won't have to be separately advertised. X declines, saying it's >a hassle. > >If, however, a NAT box is installed (assuming X's applications don't run >afoul of NAT limitations), so that externally X's addresses become part of >Q's existing block, in this instance deployment of a NAT box will actually >reduce the routing table by one entry. I believe ease of renumbering under NAT is well trodden ground. >I gather this use of NAT boxes (to avoid renumbering) is not unknown, if not >the most common cause for installing a NAT. Does anyone have any idea how >often it happens? > >Another way in which NAT boxes might reduce the number of routes has to do >with how many customers a provider can fit into an address block before it >has to go back to the registry for another discontiguous block. > >To use the case about, with ISP X and a /12, if they are giving out a /18 to >each customer, then they only get to support 64 customers before they have to >go back for another block. If they are giving each customer a /22, then they >get 1024 customers to a /12 block. > > >I doubt any of these are major factors when you look at routing table growth, >though. But I expect that growth is principally due to other factors, and >NAT doesn't play a big role (either pro or con). I have said co0nsistently that it is a factor, and in reading your note I really don't see anything that would disabuse such a belief.
Re: NATs *ARE* evil!
the fact that IPv* doesn't distinguish between who and where does cause some problems, but does not significantly impact the ability to route IPv* packets. even if you free IP addresses from any kind of role as host identity (which IMHO would be a good thing except that nobody has produced a satisfactory solution to the problem of mapping between the two), IP addresses will still need to be fairly stable, and there will still be a nontrivial amount of effort associated with renumbering as the network topology changes. Keith
Re: NATs *ARE* evil!
> From: Geoff Huston <[EMAIL PROTECTED]> > There are strong indications that NAT is one factor behind this part of > the BGP table. I'm afraid I'm missing the logic here. As you point out below, NAT's may have caused people to use *smaller* blocks of the global address space: > much of the recent growth in the deployed Internet has happened behind > NATs of various forms and the side effect is low levels of overall > address space growth as reflected in the span of address space > advertised in the BGP tables but they shouldn't, assuming all else being equal (a possibly bad assumption, as I'll note below), have any effect on the *number* of blocks (i.e. things which can potentially produce global routing table entries). The blocks are just smaller, again as you point out: > but an increasing finer level of granularity in the routing table. So the number of distinct "local areas" is still the same, yes? And NAT's should, all else being equal, not have a negative effect on the aggregatability of those addresses. E.g. if provider X has a /12 out of which they have to support N customers, without NAT they'd have to give each customer, say, a /18; but with NAT, each customer can get a /22. But there are still the same number of subsidiary blocks (i.e. N sub-blocks), and outside X they can, all else being equal, still be aggregate into that single /12. Now, if some subset M of those customers are multi-homed, so you can't aggregate into a single /16, that's an issue - but that has nothing to do with NAT - it has to do with the multihoming. The effect on the routing table is the same, whether those people are behind NAT boxes or not. Am I missing something? There are some second-order ways in which NAT boxes might actually help aggregation, now that I think about it. The simplest one is when customers switch providers, and don't want to renumber. E.g. company X is a customer of ISP P, and has addresses (either from P, or their own). X switches to ISP Q, which wants them to renumber so they won't have to be separately advertised. X declines, saying it's a hassle. If, however, a NAT box is installed (assuming X's applications don't run afoul of NAT limitations), so that externally X's addresses become part of Q's existing block, in this instance deployment of a NAT box will actually reduce the routing table by one entry. I gather this use of NAT boxes (to avoid renumbering) is not unknown, if not the most common cause for installing a NAT. Does anyone have any idea how often it happens? Another way in which NAT boxes might reduce the number of routes has to do with how many customers a provider can fit into an address block before it has to go back to the registry for another discontiguous block. To use the case about, with ISP X and a /12, if they are giving out a /18 to each customer, then they only get to support 64 customers before they have to go back for another block. If they are giving each customer a /22, then they get 1024 customers to a /12 block. I doubt any of these are major factors when you look at routing table growth, though. But I expect that growth is principally due to other factors, and NAT doesn't play a big role (either pro or con). Noel
Re: NATs *ARE* evil!
I looked again. Perry Metzger still writes: | > So, I have to wonder, why is it that they have no option? | | Maybe because I hear from folks like you and others that you're | ideologically opposed to deploying v6 instead of against it for | technical reasons? Wait, it's because of *me* that IPv6 isn't a stunning success compared to NAT? I didn't realize that, when I asked the IAB to use their technical insights as a market predictor, that behind the invisible hand of the marketplace lurks little ol' me. Maybe someone should tell Paul Krugman. Sean. - -- Sean Doran, Pagan God of Market Forces <[EMAIL PROTECTED]>
Re: NATs *ARE* evil!
Perry Metzger writes: | Maybe because I hear from folks like you and others that you're | ideologically opposed to deploying v6 instead of against it for | technical reasons? You have never heard this from me. I have no doubt whatsoever that you have heard this from others speaking about me. This probably includes your own inner voices. Of course, that's because they do not have the technical acumen or architectural insight to play the ball instead of the man, as they say in soccer countries. IPv6 is architecturally flawed in precisely the same way as IPv4 is; it simply has 4x the number of binary digits in the address fields and some minor cleanups which were important some years ago. That you do not understand that IPv6 does not distinguish between who and where, and that this ultimately will explode in the routing system in exactly the same way that IPv4 is starting to, reflects upon you, rather than whatever people think my ideology might be. Sean.
Re: NATs *ARE* evil!
> From: "Perry E. Metzger" <[EMAIL PROTECTED]> > you're ideologically opposed to deploying v6 instead of against it for > technical reasons? Ah, *that's* what's wrong with IPv6 - it doesn't pay enough attention to control of the means of production by the workers. And here I was, all these years, thinking there were all these technical things wrong with IPv6. Oh well, I guess I wasn't very perceptive. Noel
Re: NATs *ARE* evil!
[EMAIL PROTECTED] (Sean Doran) writes: > I should have waited until Perry had spoken, because now that he has > pointed out the extreme cost of NAT, I have seen the light! > > NATs are expensive. They have gross side-effects. Even Noel Chiappa, > my guru, says that they are an architectural hack. > > So, why are people deploying them? > > They are so awful, that it must only happen when people have NO OTHER OPTION. > > So, I have to wonder, why is it that they have no option? Maybe because I hear from folks like you and others that you're ideologically opposed to deploying v6 instead of against it for technical reasons? -- Perry E. Metzger[EMAIL PROTECTED] -- "Ask not what your country can force other people to do for you..."
Re: NATs *ARE* evil!
> It looks like NAT's are a fact of life, and we > just need to figure out how to deal with them. well, that's the question after all - how best to deal with them? I claim that NATs are architecturally bankrupt and we should therefore devote as little energy as possible toward legitimizing NATs and/or trying to make them any more complex than they already are. let's not pretend that they don't exist, or that they don't have some valid uses. but let's not pretend that they are viable in the long term either. Keith
Re: NATs *ARE* evil!
> this focus on NATs seems to be an incomplete statement of the problem a complete statement of the problem is quite difficult, especially given that the problem can be viewed in many different ways (without any of them being contradictory with the others), each of these views being illuminating and therefore useful. RFC 2993 is one view; http://www.cs.utk.edu/~moore/what-nats-break.html is another, and there are some other quite illuminating views that haven't been published. and we're still in the process of discovering the extent of the problem. private addresses aren't a problem by themselves as long as people don't want hosts with private addresses to exchange *any* traffic with the global Internet and as long as people don't expect to run applications on such hosts that interoperate with other applications on the Internet. ALGs (which is what I assume you mean by firewalls) cause their own set of problems, some of which are similar to those caused by NATs. the fact that NATs, ALGs, and firewalls all are in wide use and that their effects combine with one another makes it difficult to talk about any of these in isolation regarding their effect on the network or on applications; the fact that these functions often appear together in the same box also adds to the confusion. but just because ALGs and/or firewalls cause some of the same problems as NATs does not mean that it's not useful to focus on the problems caused by NATs. there is an important difference between deliberate harm to interoperability done by firewalls in the name of security (or the illusion of security, but I digress) and the accidental/unintentional harm to interoperability that is done by NATs. Keith
Re: NATs *ARE* evil!
> Surely the "much pain" is because, as Melinda Shore indicates, > some "anti-NAT fanatics" cannot understand the distinction > between "who" and "where"? sounds like a Peter Pan theory okay, everbody, close your eyes and try *real hard* to make believe that you can route between networks using overlapping address space, and that you can run distributed large scale distributed applications without a shared space for endpoint identifiers... if it doesn't work, you're not trying hard enough to believe! excuse me while I puke. Keith
Re: NATs *ARE* evil!
> "Sean" == Sean Doran <[EMAIL PROTECTED]> writes:
Sean> I should have waited until Perry had spoken, because now that he
Sean> has pointed out the extreme cost of NAT, I have seen the light!
Sean> NATs are expensive. They have gross side-effects. Even Noel
Sean> Chiappa, my guru, says that they are an architectural hack.
Sean> So, why are people deploying them?
Sean> They are so awful, that it must only happen when people have NO
Sean> OTHER OPTION.
Let's seperate things as public networks vs private networks.
"Public networks"
IP addresses cost money and the people deploying NATs in places like
hotels are not smart enough to buy a pool of IP addresses and use host
routing.
For private network (e.g. corporate networks) there are other reasons.
But, availability of IP addresses is a major one.
My suggestion is that all NAT products should provide IPv6 with 6to4
support. Instead of doing ESPUDP to get IPsec around NATs, we should do
put ESP over IPv6. This requires the same amount of effort (new clients, new
servers), but leverages IPv6 into the equation. 6to4 is very cool.
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[
] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Re: NATs *ARE* evil!
> "Jon" == Jon Crowcroft <[EMAIL PROTECTED]> writes:
Jon> note that a major problem with the little wortk that is done is that
Jon> its not often done in realistic topologies - this is a problem with
Jon> ISPs who wont let people get at the data (or the traffic traces) so
Jon> with a few honourable exceptions, most the smart people trying to do
Jon> new stuff go on to other areas where there aren;t intractable
Jon> barriers to doig the experimental verficaition of the idea
This is even a problem for most non-major vendors.
Both at the BGP layer and at the forwarding layer.
I've even heard that some people at major's can't get at that info
because of inter-divisional politics.
CAIDA has produced lots of interesting data though. The problem for
vendors is finding enough to time to read it.
If someone knows of a grad school that has money to do BGP research :-)
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems Oh where, oh where has|problem with[
] [EMAIL PROTECTED] www.solidum.com the little fishy gone?|PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
RE: NATs *ARE* evil!
How about this, practicality. Let's say we can kill all NAT's by sunset, Sunday. Who can make stop all the NAT's poping up Monday morning? They might be up all night building experimental network, with red eyes? Pan Jung -Original Message- From: Iliff, Tina [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 10:48 AM To: 'Dave Robinson'; Keith Moore Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: NATs *ARE* evil! Yes! TCP breaks due to the fact that "true" source/destination sockets cannot be defined. The destination would not know where to send a response except in the case where DNS is used...unless I need to do more reading Tina Iliff -Original Message- From: Dave Robinson [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 11:11 AM To: Keith Moore Cc: M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: NATs *ARE* evil! What's the problem with locally significant addresses? Having thousands of 10 networks will never present a problem unless those networks at some point would like to talk to each other. Is that where this whole discussion is going (or coming from) - that ultimately the more NAT'ing we do, the more headaches we're creating for ourselves en route to true global connectivity? Dave -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 10:56 AM To: Dave Robinson Cc: Keith Moore; M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless.
Re: NATs *ARE* evil!
> "Scott" == Scott Bradner <[EMAIL PROTECTED]> writes: Scott> the use of private addresses - something that a whole lot of Scott> firewalls also do - howcum the subject line is not "NATs & Scott> Firewalls are evil!" or "use of private addresses is evil!"? Not all firewalls do NAT. Firewalls that do NATs are included in the definition of NAT/NAPT. Some application firewalls exist that don't change the addresses at all. They still mess up the end-to-end nature of the internet, but that's their stated purpose. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
Re: NATs *ARE* evil!
I find it amazing (well, probably not so amazing) that we are re-hashing this every few years. It looks like NAT's are a fact of life, and we just need to figure out how to deal with them. - paul At 07:59 PM 12/15/2000 -0500, Scott Bradner wrote: >I will admit to some level of confusion >the subject line of this thread is "NATs *ARE* evil!" yet most of the >discussion is about the use of private addresses - something that >a whole lot of firewalls also do - howcum the subject line is >not "NATs & Firewalls are evil!" or "use of private addresses is evil!"? > >this focus on NATs seems to be an incomplete statement of the problem
