Subject: Re: [rrg] Name Based Sockets alternative critique

From: Javier Ubillos <[email-masked]>
Date: Tue, 02 Feb 2010 14:38:06 +0100

On Sat, 2010-01-30 at 01:30 +1100, Robin Whittle wrote:
> ... For
> instance, it is important to note that NBS is only practical for IPv6
> and that like most or all other Core-Edge Elimination architectures,
> there must be extra data transferred between any two communicating
> hosts, and typically extra delays due to the need for lookups
> involving a global query server system: DNS.

Before I start, I'd like to say that I'm representing _my_ understanding
of NBS. I'm hoping this is in sync with the ideas behind the NBS texts.

So, on with it :)

No and yes.
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.
Yes, there will be an initial query to DNS, and that requirement is
ubiquitous to software today.
You need some kind of tool to get away from those horrible PA-addresses.
The vast majority of schemes suggested on the list use one form or
another of indirection, in NBS that indirection is using DNS. (names =>
locators).
But, if what you are saying is that DNS needs to be queried continually
during each session, the answer is no.

>    Should the peer (page 7) do a lookup on the FQDN it gets from the
>    host and verify that the source address in the initial packet is
>    one of those returned by DNS, before sending the second packet
>    back, with the host's FQDN and this peer's FQDN to complete the
>    Initial Name Exchange?
Not according to the existing spec.
The existing spec (and implementation) don't assume that both sides are
NBS capable. The names (FQDN) are piggybacked on the packets until they
are acknowledged (or a timeout expires and legacy hosts are assumed).

>    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.

>    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.

>    In these Address Exchanges, should one host accept IP addresses
>    from the other host if these do not appear in the list of
>    IP addresses returned by a DNS lookup of the other host's name?

Initially, no. But after the initial few packets and the name exchange
has completed alternative locators may be exchanged (a'la shim6
perhaps).

>    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). 

> Alternative critique
> --------------------
<*snip*>
> NBS cannot be introduced for IPv4.  It could be introduced without
> disruption to IPv6, using a Destination Options extension header.

Why not IPv4?

> As with other CEE architectures, the benefits of portability,
> multihoming, inbound TE and mobility only apply to communication
> sessions conducted with other hosts whose stacks and applications
> have been upgraded to be NBS-aware.  This would make it difficult or
> more likely impossible to achieve the wide-enough adoption necessary
> for substantial routing scaling benefits - or substantial benefits to
> the adopters.

This is an interesting point. I understand your thought (and I
disagree).
The point where I think we disagree is, which of the following is most
likely to happen first:
* A majority of network operators upgrade their equipment.
* A majority of end-hosts upgrade their stacks.

> Ubiquitous adoption of NBS would involve every host in greater
> routing and addressing responsibilities.  These include DNS lookups
> before responding to a request to open a session, in order to check
> that source address of the request is one which is returned in a DNS
> lookup of the FQDN supplied in the request.

I don't think this is necessary, today we resolve a FQDN, pick our IP
and happily talk with it. 

// Javier

---

From: Robin Whittle <[email-masked]>
Date: Wed, 03 Feb 2010 11:12:51 +1100

Short version:        Name Based Sockets can only be applied to IPv6.

                      NBS, being a CEE architecture, would require
                      adoption of the Locator / Identifier Separation
                      model which would burden all hosts with
                      extra traffic, extra delays and extra
                      complexity.

Hi Javier,

> 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:

 http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf

     Yet it turns out that only the optional packet extensions of IP
     version 6 are appropriate for the name-based sockets interface:
     Exchange of domain names by a transport protocol would require
     support for optional packet extensions in all transport
     protocols.  This is not the case, however.  IP version 4 does
     not provide an appropriate means to exchange of domain names
     either, since its optional packet extensions are either dropped,
     or forwarded inefficiently, by many routers and middle-boxes.

     Only IP version 6 can exchange domain names appropriately. Its
     optional Destination Options packet extensions are ignored by
     routers and hosts if unrecognized.

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.

> 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

> another of indirection, in NBS that indirection is using DNS. (names =>

CEE, once fully adopted by all host stacks and all applications,
means that networks can multihome from PA space.  They no longer need
unscalable PI space.

CES makes a new kind of PI space which is scalable and which can be
divided much more finely than ordinary PI prefixes advertised in the DFZ.

Both could solve the routing scaling problem. CES retains the current
naming model and CEE changes it to the "Locator / Identifier
Separation" model which many RRG people consider superior, but which
I argue is inferior.

> during each session, the answer is no.

Not continually during the session, but see my previous message why
in many or most cases, the responding host needs to do a lookup (DNS
for NBS) before it can send a response packet.

> Not according to the existing spec.

The existing spec doesn't properly consider that many responding
hosts need to ensure that the packet they send will not go to any
other host than the one which has the Identifier which was in the
first packet.

> are acknowledged (or a timeout expires and legacy hosts are assumed).

Yes, but this doesn't prove to either host that the Locator which
come with the Identifier in these packets is a valid Locator for the
host with this Identifier.  At this stage in the communication, the
only way of checking that is with an Identifier -> Locator(s) lookup,
which in NBS is a DNS lookup of the FQDN which arrived in the packet.

> ATM, it's not secured. This is definitively worth exploring further.

Yes.

> ATM, it's not, also a point that needs to be explored.

This is what I am doing.  Thanks for discussing it.

> has completed alternative locators may be exchanged (a'la shim6

But each host has to do an Identifier -> Locator(s) lookup before it
can trust the Locator which arrived in a packet really is a valid
locator for the host whose Identifier arrived in the packet.

> returned set. And let the two communicating peers manage the rest (by

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.

>> disruption to IPv6, using a Destination Options extension header.

As noted above.

> * A majority of end-hosts upgrade their stacks.

Maybe so - but it would take a decade or more before 99% of stacks
had the new features.

The stack upgrade is the easy part.

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.

Upgrading all applications to do NBS would be a complete nightmare -
it will never happen.  The same goes for all other CEE architectures.

> and happily talk with it. 

Not with CEE - if you want to know which host you are sending the
reply packet to, you need to do a lookup to find that host's set of
allowable Locators first.

  - Robin

---

From: Javier Ubillos <[email-masked]>
Date: Wed, 03 Feb 2010 17:46:01 +0100

> needed for NBS into IPv4 packets without making them incompatible

Sorry, that slipped my mind.
http://www.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-24.pdf

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. :)

> 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.

My spontaneous reaction is "more NAT".
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.

>   http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

Yep, moved over the rest of that discussion to that thread.

> This is what I am doing.  Thanks for discussing it.

I don't really see why you _have_ to do this.
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.

> architectures I know of so far - and it is not necessarily what

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.

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.

> operate without an NBS stack.  Writing and debugging this would be

If the implementation is backwards compatible, this should be trivial.

// Javier

---

From: Robin Whittle <[email-masked]>
Date: Fri, 05 Feb 2010 14:58:30 +1100

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.
>>

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

> leave that for a later e-mail. :)

OK.

> 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%.

> 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.

> Yep, moved over the rest of that discussion to that thread.

OK - I look forward to you discussing that message.

> 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.

> 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.

>>> 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).
>>

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.

> 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.

> 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

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 9 Feb 2010 18:22:56 +0200

Hello Robin

I think that Christian has answered this in 

Page 9, sections Initial Address exchange and Address Updates.

Regards
Hannu 

>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: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Robin Whittle
>Sent: Friday, February 05, 2010 05:59
>To: RRG
>Subject: Re: [rrg] Name Based Sockets alternative critique
>
>> overcome this. I don't feel to confident on the details, so I'll 
>> happily leave that for a later e-mail. :)
>
>OK.
>
>
>> Here's a good point, one that I don't feel I have an 
>immediate answer 
>> to (which is good :)
>>
>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.
>
>
>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 
>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%.
>
>
>> 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.
>> 
>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.
>
>I am not suggesting that every communication requires it, but 
>I think many or most do.
>
>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.
>
>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.
>
>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.
>
>
>
>
>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.
>
>
>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
>[email-masked]
>http://www.irtf.org/mailman/listinfo/rrg
>