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!
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!
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!
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!
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!
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!
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 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!
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!
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!
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 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!
| 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 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!
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^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!
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!
"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!
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!
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. 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!
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!
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!
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!
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!
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, 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!
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!
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!
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!
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, 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!
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!
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!
--- 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!
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!
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!
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!
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!
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!
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!
"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!
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.lanl.gov/mfisk/ for
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!
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!
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!
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!
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!
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!
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 flight. That doesn't
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!
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!
[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!
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!
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!
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: 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!
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!
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!
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!
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 Another message from the Society for More Accurate Technical Terminology!
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!
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!
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!
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!
"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 future problem. It is
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!
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!
"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!
[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!
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!
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!
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!
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!
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!
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!
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 is an issue, not the size of
Re: NATs *ARE* evil!
the problems with NAT are not generally due to implementation. they are inherent in the very idea of NAT, which destroys the global Internet address space. Keith
Re: NATs *ARE* evil!
How does the idea of NAT destroy the global Internet address space? because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless.
Re: NATs *ARE* evil!
Frank Solensky wrote: Brian E Carpenter wrote: Frank, This is goodness. Can I ask that you publish the *method* before you publish any results? I have seen various attempts to tackle this in the past, and they have all given results that are very hard to interpret and whose meaning depends very much on the method used. I think we could react to the numbers more rationally if we discussed the method first. Sure thing. Would it make sense to spin this off as a separate list? big-internet is probably still there. Brian
Re: NATs *ARE* evil!
On 15 Dec 2000 at 10:56 -0500, Keith Moore apparently wrote: How does the idea of NAT destroy the global Internet address space? because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? ...Scott
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!
On Fri, 15 Dec 2000 08:54:36 PST, Scott Brim said: How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? The lesson to be learned is that we say "The Keith Moore that works at UTK". In fact, there's a word for when two people use the same exact identifier - it's called "identity theft" and usually makes life very difficult for all concerned - for many of the same reasons that 2 hosts with the same IP address don't play nice. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
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. right. if net 10 networks stay completely isolated from one another, then there's no problem. the problem only exists when people want to tie those networks together. but it's inevitable that the vast majority of private networks *will* want to communicate with the public Internet in ways that NAT does not facilitate. 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? in a nutshell, yes. Keith
Re: NATs *ARE* evil!
[recipient list trimmed] The lesson to be learned is that we say "The Keith Moore that works at UTK". even this is not sufficient. I once received a telephoned death threat from someone who had mistaken me with a different Keith Moore from UTK. fortunately I was able to convince him that he had the wrong person, but it wasn't easy. Keith
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!
On Fri, 15 Dec 2000, Scott Brim wrote: How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? They do that by attempting to use additional fields to create a unique global name for Keith Moore, such as "Keith Moore, the painter from Dublin" or "Keith Moore, the taxidermist from Dubai." And just like you can't identify 192.168.0.1 if it changes the address it lives on in the global namespace, you'll have a hard time finding your friend Keith if he moves to Dallas. The lesson we learn from this is that people need significantly longer names, in order to prevent confusion, and make it easier to find long-lost acquaintances. Not to mention which make the jobs of various government agencies and courts significantly easier. -= flail? http://flail.com/ =- -= the online comic strip =-
Re: NATs *ARE* evil!
On Fri, 15 Dec 2000 12:11:29 EST, Dave Robinson said: What's the problem with locally significant addresses? Having thousands of Hmm.. this from a guy posting from endtoend.com? I'm not sure if the right word is "ironic" or "sarcastic". In any case, didn't we just release an RFC detailing in excruciating detail? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: NATs *ARE* evil!
Bingo! RFC 2775, RFC 2993 Brian Dave Robinson wrote: 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!
Well, let me correct myself. It is more along the lines of firewall security being broken in the sense of all firewalls would have to be open to entire networks instead of limiting individual hosts. IP would be broken in the sense of routers not being able to distinguish which route to choose in the case of multiple hosts having the same IP address but they are located behind different firewalls, routers, etc in different enterprises. Tina Iliff -Original Message- From: Iliff, Tina Sent: Friday, December 15, 2000 11: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!
Don't get me wrong, NAT is an odd booger to be sure, personally I think it is another $BIG_SOFTWARE_COMPANY conspiracy ;-) But... they do not have the same identity, when NAT occurs the device then bears a globally unique IP address at least to all those with whom there may be a conflicting address and those are the only ones that count. yes no maybe? It does not matter whether you call the street my house is on Maple street or 4th street or four streets down from main street as long as the Post Office (read NAT box) knows what you mean happy friday and merry holidays, David H -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 12:22 PM To: Scott Brim Cc: Keith Moore; Dave Robinson; M Dev; Sean Doran; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! On Fri, 15 Dec 2000 08:54:36 PST, Scott Brim said: How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? The lesson to be learned is that we say "The Keith Moore that works at UTK". In fact, there's a word for when two people use the same exact identifier - it's called "identity theft" and usually makes life very difficult for all concerned - for many of the same reasons that 2 hosts with the same IP address don't play nice. -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: NATs *ARE* evil!
Folks should read and *refer* to the NAT WG documents before commenting. An awful lot of work was put into the content and wording of these documents. RFC 2663 draft-ietf-nat-protocol-complications-06.txt RFC 2993
Re: NATs *ARE* evil!
How much meaning does "Keith Moore" have? Somehow we have a planet with billions of people on it and those who need to still manage to find the appropriate "Keith Moore". How do they do that? Are there any lessons to be learned? "Keith Moore" is not an address, "Keith Moore" is a name. Melinda
RE: NATs *ARE* evil!
Well, in this case a device that is doing NAT (properly anyway)would replace the ip and socket headers, much the way each router replaces physical addresses. -Chris Millikin -Original Message- From: Iliff, Tina [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 9: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!
RFC 2993 Architectural Implications of NAT's ? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 12:55 PM To: Dave Robinson Cc: [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! On Fri, 15 Dec 2000 12:11:29 EST, Dave Robinson said: What's the problem with locally significant addresses? Having thousands of Hmm.. this from a guy posting from endtoend.com? I'm not sure if the right word is "ironic" or "sarcastic". In any case, didn't we just release an RFC detailing in excruciating detail? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
Re: NATs *ARE* evil!
From: Keith Moore [mailto:[EMAIL PROTECTED]] the problems with NAT are not generally due to implementation. they are inherent in the very idea of NAT, which destroys the global Internet address space. From: Dave Robinson [EMAIL PROTECTED] How does the idea of NAT destroy the global Internet address space? Ah, Keith was using a little verbal shorthand here. He meant "NAT removes the global *uniqueness* of NAT'd Internet addresses". Similarly, when he said: addresses are meaningless. he really meant "NAT'd addresses are no longer capable of uniquely globally identifying people". NAT'd addresses do still have *some* meaning, of course, it's just a more complex and restricted meaning than they used to. This message brought to you by the Society for More Accurate Technical Terminology. :- Noel
RE: NATs *ARE* evil!
Point taken. Rather than reiterate my point I will refer to the following excerpt from RFC 2993: " - NATs enable casual use of private addresses. These uncoordinated addresses are subject to collisions when companies using these addresses merge or want to directly interconnect using VPNs. " This is becoming a major drawback to NAT. -Chris -Original Message- From: Matt Holdrege [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 10:19 AM To: [EMAIL PROTECTED] Subject: Re: NATs *ARE* evil! Folks should read and *refer* to the NAT WG documents before commenting. An awful lot of work was put into the content and wording of these documents. RFC 2663 draft-ietf-nat-protocol-complications-06.txt RFC 2993
Re: NATs *ARE* evil!
How does the idea of NAT destroy the global Internet address space? because in a NATted network the same addresses are used in different parts of the network. addresses are meaningless. So what? Why is this the big problem? __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/
Re: NATs *ARE* evil!
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 Scott
