Hello Robin I think that Christian has answered this in
http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf Page 9, sections Initial Address exchange and Address Updates. Regards Hannu >> Christian really needs to answer this. I can imagine a more complex >> construct for "Identifier", such as "combination of FQDN and one or >> more Locators from the set of allowed Locators returned by DNS. But >> it is messy, more complex than the Identifier construct of other CEE >> architectures I know of so far - and it is not necessarily what >> Christian has in mind. > > I don't understand why this should be a complex matter. > > A trivial solution: > DNS rotates the order of the IPs in the reply. > The NBS host picks the first address. > The rest of the communication is dealt with between those two endpoints. >But then the FQDN no longer refers to a specific host. It refers to one of several >hosts, each of which has a different IP address. >How do those hosts represent themselves to others? You can't have physical host X >and physical host Y both with the same Identifier, since Identifiers uniquely >identify hosts. >I think Christian does need to respond to this, rather than us trying to imagine how > he must be intending to solve it, and then debating the merits of the solution we > assume he has in mind. >-----Original Message----- >From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On >Behalf Of ext Robin Whittle >Sent: Friday, February 05, 2010 05:59 >To: RRG >Subject: Re: [rrg] Name Based Sockets alternative critique > >Short version: Why it is frequently important that a responding > host verify the Identity of the host which will > recieve the reply packet it sends. > > Whether it will be difficult to modify and debug > applications to do both NBS and non-NBS > communications. > > CEE multihoming chews address space at 2, or 3 or > more times the rate at which it is actually used - > so CEE is unsuitable for IPv4. > >Hi Javier, > >>>> I don't see why you would claim that it is only practical for IPv6. >>>> If it is due NAT:s, then please see reply below. >>> >>> Christian writes that there's no way of introducing the >extra things >>> needed for NBS into IPv4 packets without making them incompatible >>> with existing hosts: >> >> Sorry, that slipped my mind. >> http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf > >Thanks for pointing to this paper - which I hadn't seen: > > IP Options are not an option > Rodrigo Fonseca, George Porter, Randy H. Katz, > Scott Shenker and Ion Stoica, CS at UCLA > 2005-12-09 > >> However, talking to Christian I have understood there is a route to >> overcome this. I don't feel to confident on the details, so I'll >> happily leave that for a later e-mail. :) > >OK. > > >>> Also, for any CEE architecture such as NBS, to multihome a network, >>> such as a /20, would require at least two /20 prefixes of PA space, >>> one from each ISP. This would double address consumption - >so no CEE >>> architecture will ever be practical for IPv4. >> >> Here's a good point, one that I don't feel I have an >immediate answer >> to (which is good :) >> >> However, to extrapolate that to "... no CEE architecture >will ever be >> practical for IPv4." is quite a jump. > >I don't think so. Multihoming with any CEE requires at least >two global unicast addresses for each host. > >Its an open-and-shut case. There's nothing more to say - >there's no way this could be used as a scalable routing >solution for IPv4 to to the shortage of IPv4 global unicast >address space. > > >> My spontaneous reaction is "more NAT". > >Yes, but however you use the space, multihoming with CEE >requires at least two global unicast addresses for each >address which can actually be used by a host, a NAT box or >whatever. CES enables close to 100% efficient use of global >unicast address space. For portability alone, CEE could be >the same - just have a single upstream ISP and so each host >has a single IP address. But a major purpose of scalable >routing is multihoming, and CEE will always have an address >usage efficiency of 50%, 33% 25% or whatever depending on the >number of upstream ISPs used, while CES will always have an >efficiency close to 100%. > >The only inefficiency of CES is devoting one or two or three >address to one or two or three (two or more for multihoming) >ETRs for a given end-user network, which could have one, ten, >ten thousand or whatever actively used SPI (Ivip) addresses in >use. It may be possible to have those ETRs serve multiple >end-user networks, so the efficiency becomes closer still to 100%. > > >> My guess is also that I'm quite alone on this list not to >consider NAT >> to be an abomination from the 6th circle of hell. :) Hosts >have become >> pretty good at perforating NATs, and infrastructures for >e.g. STUN and >> Teredo are ubiquitous, readily available and free to use. >> >> I'm going to have to return this point. > >NAT is no barrier to any client-server protocol where the >client is behind NAT and initiates the communication - >provided there are enough keepalives to keep the NAT box on >its toes. The difficulty is some other host sending packets >to that host behind NAT. > >>>> Yes, there will be an initial query to DNS, and that >requirement is >>>> ubiquitous to software today. >>> >>> Please see my previous messages: >>> >>> http://www.ietf.org/mail-archive/web/rrg/current/msg05906.html >>> >>> Today's "IP addr. = ID = Loc" naming model should be retained >>> http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html >> >> Yep, moved over the rest of that discussion to that thread. > >OK - I look forward to you discussing that message. > >>>>> How is this exchange secured against the reply being spoofed by >>>>> an attacker? (Maybe it doesn't have to be.) >>>> >>>> ATM, it's not secured. This is definitively worth >exploring further. >>> >>> Yes. >>> >>> >>>>> How are the Initial Address Exchange and subsequent Address >>>>> Exchanges secured against spoofed packets? >>>> >>>> ATM, it's not, also a point that needs to be explored. >>> >>> This is what I am doing. Thanks for discussing it. >> >> I don't really see why you _have_ to do this. > >I am not suggesting that every communication requires it, but >I think many or most do. > >> Why do you _have_ to have verification at the >network/transport layers? >> In the FQDN => IP world we live in, this authentication is >done at the >> application layer (and that is where it, in my opinion belongs). >> >> Again, see the "Re: [rrg] Another concern about using FQDNs as host >> idenfieirs//re: A concern with ILNP//re: critique of RANGI" thread. > >OK. > >Today, web servers create log files in which the IP address of >the client is important. This involves no extra work, because >with the TCP-based communications, the IP address of the >client is known - and this is the client's Identifier. > >Now let's consider a CEE architecture such as NBS - and all >such architectures implement a separate objects for Locator >and Identifier. > >Let's say your desktop computer had an Identifier "jav-pc.sics.se" >and I want to cause you trouble by posting an inane or insane >comment on some blog of forum discussion site, as if you had >written it. I configure my PC that its Identifier is >"jav-pc.sics.se" and use it to connect to the blog server and >leave the stupid message. If the blog server does not do a >DNS lookup on the Identifier my PC provides in its initial >packets, then it will not realise that the Locator of my PC is >not one which is returned when looking up "jav-pc.sics.se". > >I think the blog server should do the lookup before bothering >to reply to the SYN packet my PC sends. If it did so, it >would recognise that the SYN packet had a bogus Identifier - >so it should ignore it and perhaps record the details in a >security log. > >If the blog server doesn't check, it carries on and I get to >post the comments. In the blog-server log, and in the >footnotes to the comments that everyone can read, will be >"jav-pc.sics.se" - so it appears you wrote the comments, for >instance if it can easily be seen that you genuinely did post >comments on this or other blog sites using the host with the >Identifier "jav-pc.sics.se". > >Now the log file and display on the blog site may well also >include the IP address - which could be quite a long piece of >text assuming this is IPv6. > >In later disputing whether these comments were yours or not, >you might point to the fact that the IP address is in >Australia and your PC is in Sweden. Maybe so, right now . . . >but your host is defined by its Identifier, and Identifiers >are entirely portable. You could use your identifier with any >physical host in the world which you had access to - that's >the whole idea of portability. > >How could you prove that at the time the comments were posted, >that you did not have my Locator as one of the Locators for >host "jav-pc.sics.se" in your DNS? > > >I think there are lots of communications today where the >simple fact of replying to an IP address to commence a >communication, or even to be the sole form of communication, >is made so much easier due to the fact that we can trust the >routing system not to deliver the packet to any other host but >the host with the Identity of that destination IP address. > >To replicate this in NBS or any other CEE architecture, the >respondent needs to look up the Identifier which came in the >initiator's packet, and only continue if the lookup includes a >Locator which matches the Locator in that packet. > >People complain about the architectural inelegance of having >the IP address perform both Locator and Identifier roles, but >it actually makes lots of things easier for hosts. When you >look in detail at what a CEE host has to do to have the same >confidence in responding to a packet, you find the responding >host has to do work, make a DNS request, wait for the reply >and then do some more work before it can be confident of using >pair of Identifer and Locator in its reply packet. > > > > >>>>> How does NBS perform the equivalent of "round-robin >DNS" - where >>>>> a FQDN DNS lookup returns multiple IP addresses, each one being >>>>> for a separate host? Initially I thought that the FQDN played >>>>> the role of both "Text name" and "Identifier", with the role of >>>>> "Locator" being played by one or more IP addresses. >However, to >>>>> do this load-distributing "round-robin DNS", NBS hosts must >>>>> distinguish between other hosts not just by their FQDN, but the >>>>> combination of a single FQDN and one or more IP addresses. >>>> >>>> Good point, but I don't see this as a great problem. It's a local >>>> policy decision. A trivial solution could be to pick a random IP >>>> from the returned set. And let the two communicating peers manage >>>> the rest (by exchanging sets of IP). >>> >>> Christian really needs to answer this. I can imagine a >more complex >>> construct for "Identifier", such as "combination of FQDN and one or >>> more Locators from the set of allowed Locators returned by >DNS. But >>> it is messy, more complex than the Identifier construct of >other CEE >>> architectures I know of so far - and it is not necessarily what >>> Christian has in mind. >> >> I don't understand why this should be a complex matter. >> >> A trivial solution: >> DNS rotates the order of the IPs in the reply. >> The NBS host picks the first address. >> The rest of the communication is dealt with between those >two endpoints. > >But then the FQDN no longer refers to a specific host. It >refers to one of several hosts, each of which has a different >IP address. > >How do those hosts represent themselves to others? You can't >have physical host X and physical host Y both with the same >Identifier, since Identifiers uniquely identify hosts. > >I think Christian does need to respond to this, rather than us >trying to imagine how he must be intending to solve it, and >then debating the merits of the solution we assume he has in mind. > >> There is no shared state, there are no more lookups in DNS, the >> relation betwen FQDN and IP is no longer important, the FQDN-string >> has been degraded to a localscope handle. > >So if the same application later opens a second socket to the >same FQDN, then it might get a different physical host's IP address? > >I don't think this is how NBS is intended to work - but that's >just my speculation. We need Christian to further this discussion. > > >>> Each application would need to work with a mixture of NBS hosts and >>> applications and and non-NBS hosts and applications, and be able to >>> operate without an NBS stack. Writing and debugging this would be >>> absolute hell. >> >> If the implementation is backwards compatible, this should >be trivial. > >I still believe that writing and debugging any CEE application >which has to also work with non-CEE hosts, and also work in >non-CEE mode entirely when it operates on a stack without CEE >enhancements, would be a nightmare. > >The application might be dealing simultaneously with any >number of other hosts. Some will have an NBS stack and an NBS >upgraded application. Some will have NBS stacks but not the >NBS upgraded application. So those, and the hosts with no NBS >stack (irrespective of the NBS status of their apps) will need >to be handled in a different manner from the hosts which do >support NBS. > >When a remote host has a non-NBS app (irrespective of the NBS >status of its stack) then the app on our host has to talk the >version of the app's protocol which predates whatever changes >were made to the protocol in order for it to be compatible with NBS. > >I am not saying it can't be done - I am just saying that it >would often be a very difficult task. Some apps would be >easy. Anything which simply opens a single TCP session with a >host as defined by a FQDN will obviously be easy to rewrite for NBS. > >- Robin > > >_______________________________________________ >rrg mailing list >rrg@irtf.org >http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
