Re: Nimrod is still ugly - was: NATs *ARE* evil!
If you find a way to select paths in real networks using only virtual data, we'd all be interested to hear it. Try draft-guruprasad-addressless-internet-00.txt, and the ECUMN'2000 paper on which it was based, at http://affine.watson.ibm.com/tmp/vinet.pdf The draft doesn't yet mention the log(N) bounds on the routing complexity, but I did try to explain that real addresses are obviated at all levels. A detailed comparison of addressing and addressless principles is yet to be made, hopefully soon in the next revision and/or paper. -p.
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.
NAT v4 vs v6
What are the differences (definitions) of v4 and v6? __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
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: Congestion control
At 11:25 AM 12/17/00 -0800, Paul Hoffman / IMC wrote: WG chair says "OK, the room is now over-full. Who are there people in the doorway or outside who intend to work actively on drafts or forming the charter for this group? I see seven hands up. Could fourteen people who are currently sitting or jammed up against a wall who do *not* already plan to work actively on drafts This is among the set of reasonable procedures to follow when there is congestion. As with each technique suggested, there are benefits and there are problems. However the premise to my suggestion is that we are growing and are going acquire larger venues eventually. So let's acquire them a little sooner and avoid the pain of congestion and imperfections and inconveniences of all these congestion management techniques. d/ ps. The plea for less active attendees to move works once. It does not cover late arrivals. Taking a Draconian attitude towards active participants who arrive late is an example of the imperfection of the management techique. =-=-=-=-= Dave Crocker [EMAIL PROTECTED] Brandenburg Consulting www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464
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: Congestion control
I find it amusing that this debate on how to handle "congestion" at IETF meetings mirrors the technical debate on congestion in the Internet. The two sides still seem to be "more bandwidth" or "apply QOS". Bob
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: What is the IETF? -- A note of caution
At 14:02 18/12/2000 +1030, Andrew Rutherford wrote: At 09:49 -0500 15/12/00, John C Klensin wrote: I don't think company names on badges are harmful, and they do help us identify each other (otherwise, we could carry the principle to the limits and leave the names off too, replacing them with randomly-assigned numbers). So what about replacing company names on badges with email addresses? That might allow one to infer company affiliation if the wearer lists an address with a company component. Given most of us know each other via email address, and may wish to follow up a "hallway conversation" with email, it's possibly more functional. Personally, I like having organizations on nametags. It is quite often the way in which I find out that old friends have changed jobs. -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
CORRECTION: Middleware/Middle Boxes Architecture List information
I know, this is completely silly, but the subscription email address I gave out previously is not working. The correct subscription and list information is as follows: List name: [EMAIL PROTECTED] Subscribe: [EMAIL PROTECTED] While the service is run by majordomo, the majordomo alias does not exist. Again, the topic of this list will be focused on the architecture, diagnosis, and discovery of devices in the middle of the network, so that the applications could then communicate with them, or otherwise report errors to their users. This work is complimentary to the MIDCOM working group. My apologies for the confusion. -- Eliot Lear [EMAIL PROTECTED]
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: Congestion control
wait for the Assured Seating (AS) Per Hotel Behavior (PHB) with multiple drop precedence levels badges are marked on ingress to the room based on willingness to work... the chair drops people marked "dead weight" first as the room fills in order to come up with another diffserv-related acronym, sophisticated chairs use reverse RED (Read Every Draft) to boot out those who havent. cheers, gja Bob Hinden wrote: I find it amusing that this debate on how to handle "congestion" at IETF meetings mirrors the technical debate on congestion in the Internet. The two sides still seem to be "more bandwidth" or "apply QOS". Bob -- Grenville Armitagehttp://members.home.net/garmitage/ Bell Labs Research Silicon Valley
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: What is the IETF? -- A note of caution
The point of individuality is a good one. But this should be the choice of the person. They can write whatever they choose for the company. For many of us it is informative. At 02:02 PM 12/18/2000 +1030, Andrew Rutherford wrote: At 09:49 -0500 15/12/00, John C Klensin wrote: I don't think company names on badges are harmful, and they do help us identify each other (otherwise, we could carry the principle to the limits and leave the names off too, replacing them with randomly-assigned numbers). So what about replacing company names on badges with email addresses? That might allow one to infer company affiliation if the wearer lists an address with a company component. Given most of us know each other via email address, and may wish to follow up a "hallway conversation" with email, it's possibly more functional. Michael W. Condry Director, Internet Strategy 2111 N.E. 25th Ave. JF3-206 Hillsboro, OR 97124-5961 Phone: (503) 264-9019 FAX: (503) 264-3483 Email: [EMAIL PROTECTED]
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: 49th-IETF conf room planning
On Mon, 18 Dec 2000, Matthew Goldman wrote: I also disagree with you regarding hotel rates. Pre-negotiated block rates for meetings are around the same price as we paid in San Diego for a similar type of hotel (clearly, Vegas hotels are both much better than and much worse than the Sheraton San Diego). The only time hotel rooms are extremely high is for major expositions -- like Comdex, Consumer Electronics Show, etc -- because those rooms are not booked as blocks. The hotels jack up the prices for those weeks. I've been to Vegas on a non-convention week and got a hotel room for $70/night vs. $180/night for the same room during Comdex. It would be up to the IETF to negotiate for 2000-3000 rooms; that's a lot of buying power. If they can't get reasonable rates, then we don't go there. Actually, geek conferences get the shaft in Vegas, because Vegas is wise to the fact that geeks, knowing the odds, are much less likely to gamble. That's why Comdex, Interop, and so forth, get such high hotel rates. Now, if we assured them that IETF stands for "International Eaters of Tasty Food", or similar, we might get a break... And we can point to the frequent mention of "many fine lunches and dinners" in _Exploring the Internet_ as substantiation. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ --
Re: 49th-IETF conf room planning
I fervently hope not. Las Vegas is the tobacco smoking capital of the U.S. -- higher rates than anywhere else in the country, including areas where they grow the stuff. It is also very hard to find good quality food (but is awash in cheap buffets). Sorry, but I'd prefer Vegas vs. not being able to attend half of the meetings I planned to in San Diego simply because there was not enough space. I was very dishardened by this, and hope the meeting planners are able to plan for 3000+ attendees for future meetings. for many people, having smoke anywhere near the meeting rooms is as much of a barrier to participation as having the meeting rooms full. I'd far rather we raise the bar for participants (i.e. only admit those who have done their homework) than make more room for non-participants. Keith
RE: 49th-IETF conf room planning
It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. In addition, turning away people who wish to attend seems counter to the IETF spirit. -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, December 18, 2000 8:36 PM To: Matthew Goldman Cc: 'Randall Gellens'; Daniel Senie; Michael Richardson; [EMAIL PROTECTED] Subject: Re: 49th-IETF conf room planning I fervently hope not. Las Vegas is the tobacco smoking capital of the U.S. -- higher rates than anywhere else in the country, including areas where they grow the stuff. It is also very hard to find good quality food (but is awash in cheap buffets). Sorry, but I'd prefer Vegas vs. not being able to attend half of the meetings I planned to in San Diego simply because there was not enough space. I was very dishardened by this, and hope the meeting planners are able to plan for 3000+ attendees for future meetings. for many people, having smoke anywhere near the meeting rooms is as much of a barrier to participation as having the meeting rooms full. I'd far rather we raise the bar for participants (i.e. only admit those who have done their homework) than make more room for non-participants. Keith
Re: 49th-IETF conf room planning
It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. I disagree in the strongest possible terms. it makes a great deal of sense if the purpose of the meeting is to get technical work done, rather than to spoonfeed people who can't be bothered to read the background material. and we're seeing entirely too much spoonfeeding in meetings these days - witness the tremendous amount of precious meeting time that is devoted to presentations of *material already explained in the relevant drafts*, rather than discussion. OTOH I happen to feel that it's quite useful if IETF folks who actively participate in some WGs, drop in on the meetings of other WGs. we need to encourage cross-pollenation between groups. but we don't need to encourage non-participants to attend IETF meetings. In addition, turning away people who wish to attend seems counter to the IETF spirit. the IETF spirit has always been to include anyone *who does his/her homework* Keith
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: 49th-IETF conf room planning
On Mon, Dec 18, 2000 at 11:35:38PM -0500, Keith Moore wrote: I fervently hope not. Las Vegas is the tobacco smoking capital of the U.S. -- higher rates than anywhere else in the country, including areas where they grow the stuff. It is also very hard to find good quality food (but is awash in cheap buffets). Sorry, but I'd prefer Vegas vs. not being able to attend half of the meetings I planned to in San Diego simply because there was not enough space. I was very dishardened by this, and hope the meeting planners are able to plan for 3000+ attendees for future meetings. for many people, having smoke anywhere near the meeting rooms is as much of a barrier to participation as having the meeting rooms full. I was out there this past summer at Caesers Palace for a Lunar Development Conference and the only place I found smoke was in the Casino itself. The conference rooms and actual hotel rooms were smoke free and very nice (and cheap). In the Caesars Palace Conference center the hallways were as large as the subdivided Grand Ballroom in San Diego. Caesars would barely even notice us I'd far rather we raise the bar for participants (i.e. only admit those who have done their homework) than make more room for non-participants. This wouldn't have helped in the DOMREG/WHOIS BOF. I did an informal survey and everyone in my part of the doorway was someone who should have been there and who had read the documents. Maybe the solution isn't Vegas but instead focusing on conference centers in the city in question instead of strictly hotel only facilities. -MM -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: 49th-IETF conf room planning
On Mon, Dec 18, 2000 at 08:46:31PM -0800, Matthew Goldman wrote: It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. In addition, turning away people who wish to attend seems counter to the IETF spirit. I think the operative word here is 'attend'. Keith's point is that you don't 'attend' an IETF meeting, you participate in one. But we've beaten this horse into a fine pulp long before now so I'm not going to belabor the point -MM -- Michael Mealling| Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | [EMAIL PROTECTED]
Re: 49th-IETF conf room planning
This suggestion will I hope generate much heated discussion. We could always ask the working group chairs to identify the contributing members. Those who submit Internet-Drafts can also be added to the list. These members like the WG Chairs, ADs, ... can have stickers added to their badges. Those without badges can be asked to leave when space gets tight. It makes absolutely no sense to have someone pre-pay a meeting fee, pay to travel to a location, attempt to attend a meeting, and be turned-away. I disagree in the strongest possible terms. it makes a great deal of sense if the purpose of the meeting is to get technical work done, rather than to spoonfeed people who can't be bothered to read the background material. and we're seeing entirely too much spoonfeeding in meetings these days - witness the tremendous amount of precious meeting time that is devoted to presentations of *material already explained in the relevant drafts*, rather than discussion. OTOH I happen to feel that it's quite useful if IETF folks who actively participate in some WGs, drop in on the meetings of other WGs. we need to encourage cross-pollenation between groups. but we don't need to encourage non-participants to attend IETF meetings. In addition, turning away people who wish to attend seems counter to the IETF spirit. the IETF spirit has always been to include anyone *who does his/her homework* Keith 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: 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
