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
