Re: The internet architecture

[Christian Vogt <christian.vogt at ericsson.com>]

Keith -

Up front:  Many of your arguments are based on the assumption that the
name-oriented stack architecture proposed in [1] is limited to a new API
between applications and the stack.  If that was so, then the benefits
of the new stack architecture would undoubtedly be limited.  But the
name-oriented stack architecture goes beyond providing a new API.  It
also comprises changes further down the stack to take maximum benefit of
the proposed new naming concepts.  A new API alone would only provide a
new layer of abstraction, which (here I agree with you) would fail to
yield a substantial improvement.  Therefore, please keep in mind when
reading my further responses below, that the proposed name-oriented
stack architecture is more than a new API.

And another general comment up front, regarding your arguments related
to DNS reliability:  Yes, I agree with you that this is important.  For
sure it must be keep in mind when transitioning towards an architecture
that implies a stronger dependency on name-to-address mapping.  The
reason why I am convinced that we will get this right is that (i) the
tools to ensure various levels of DNS reliability and security already
exist due to existing dependencies on the DNS, and (ii) which level of
DNS reliability and security to provide for, in each particular
deployment scenario, will continue to be under the control of the
respective name owners.  I.e., as today, the name owners will be able to
select a hosting provider with sufficient trustworthiness, or to set up
the necessary DNS infrastructure themselves, or even to use hard-coded
name-to-address mappings in hosts.

Of course, a name-oriented stack architecture does not /have/ to use the
DNS as its name-to-address mapping system.  As Stephane said earlier in
this email thread: There are alternatives.  Still, I have two reasons to
believe that the DNS would be appropriate in this regard:

(1) The DNS protocol enables exactly the flexibility in name-to-address
   mapping that we need:  It enables an abstraction from the physical
   implementation of a service -- i.e., from the details of which hosts
   run the service and where these hosts are located.

   Note that the term "hostname", which is common in the DNS realm, is
   misleading due to exactly this abstraction.  And I think it has led
   to misunderstandings also in our discussion.  This is why I am now
   using the term "name" instead.

(2) The DNS has very attractive operational and security properties:
   Since resolution is along administrative relationships,  the right
   incentives are in place for DNS to work correctly.  Of course, this
   doesn't mean that there is no room for improvement.  Certain
   existing administrative procedures may be inappropriate, as you say.
   And clearly there would be benefit to additional cryptographic
   protection such as through DNSSEC.  But the DNS provides a certain
   level of faithfulness already without such improvements, and this is
   in my opinion very attractive.

> > The service name is a well-known string replacing the overloading of
> > port numbers for the same purpose, and the hostname maps to the set  
> > of
> > IP addresses through which the service is currently reachable.
>
> I'll never forget the time, back when I ran a mail server for a few
> thousand users, that mail started dropping on the floor because a call
> to getservbyname ("smtp", "tcp") inside sendmail started failing.
>
> The call failed not just because some dim bulb at Sun decided that it
> would be a good idea to take an API that originally did a flat file
> lookup and reimplement it with an RPC to an NIS server that didn't  
> share
> fate with the caller (not to mention several other fragilities
> associated with NIS).   On a deeper and more important level, the
> failure happened because the whole idea of getservbyname (and similar
> things, including the service name parameter to getaddrinfo) is
> brain-damaged [*].  "smtp" is not better than 25, and adding an extra
> layer of indirection just to make the port number be human readable is
> not an improvement.

There won't be a new indirection layer.  Instead, there will be a
separate name space for services, which will be distinct from the name
space for session identification.  Nowadays, port numbers are overloaded
for both, service identification and session identification.

And the separation of service identification and session identification
is going to have value.  An example is in IPv4 NAT'ing:  Here, the
overloading of port numbers limits the efficiency with which sessions
can be multiplexed onto the same IP address because the overloading
requires one of the two port numbers of a session to take a certain,
well-known value.  This problem is coming up nowadays in the discussions
around IPv6 transition, for which many techniques require aggressive
multiplexing of sessions onto the same IPv4 address.  You may argue that
this alone is not sufficient to motivate a change, but this would be a
separate topic for discussion.  Point in fact, the overloading of port
numbers does create problems, and eliminating the overloading would be
beneficial.

> When a protocol specification says that a connection is to be made to
> port 25, the correct way to write code to implement that specification
> is to tell it to connect to port 25.  htons(25) doesn't fail nearly as
> often as getservbyname("smtp", "tcp").

The comparison between htons() and getservbyname() is inappropriate
here.  Again, the reason is that the proposed name-oriented stack
architecture uses service names directly to identify a service.  It does
not map the service name onto an overloaded port number, which is what
getservbyname does.  Therefore, there is no additional layer of
indirection that would constitute an additional risk for failure.

> The right time to start insisting on use of ASCII endpoint names in  
> APIs
> (and this includes ports) is when destination hosts start using ASCII
> endpoint names to demultiplex traffic.  Doing it anytime sooner is  
> just
> asking for more failures in a network that's already inexcusably
> fragile.

Right, and again, this is exactly what the proposed name-oriented stack
architecture does.

> > Similarly, a DNS hostname can be specified to filter incoming
> > connections based on the IP addresses that this hostname currently  
> > maps
> > to.
>
> And that way, if someone can spoof the DNS response, or compromise the
> DNS server, it becomes possible to bypass the filter.  nice.

So you are preferring to use IP addresses for identification?  In the
presence of mobility, multi-homing, privacy addressing, and renumbering?
Come on...

Be assured that the proposed stack architecture will come with
appropriate security measures to protect the binding between names and
IP addresses.  And as described in the paper [1], there is more than one
option:  DNSSEC is one option.  Manual configuration of the filtering
host with name-to-address mappings is another option.  The latter is
equivalent to the existing practice of configuring hosts with IP
addresses.

> And yeah, everybody complains about renumbering pain these days  
> because
> nobody has yet figured out how to make core routing scale without
> renumbering from time to time.  But trying to make it easy to renumber
> everything might just be optimizing for the wrong case, especially if
> doing so compromises the reliability and security of enterprise
> networks.

While I wouldn't go as far as to say that the proposed name-oriented
stack architecture is /optimized/ for simplifying renumbering,
simplifying any form of re-addressing event is certainly an advantage of
the architecture, and simplified renumbering is included in that.
Re-addressing events are nowadays common, so considering them in the
stack architecture design is going to be a benefit.

> > The three main benefits of the hostname-oriented stack architecture  
> > are
> > consequently as follows:
> >
> > - Application programming becomes potentially easier.
>
> only if (a) the application can reasonably avoid dealing with that
> complexity [...]

... which it will.  This is explained in the paper, Keith.

> > - IP address changes, such as for mobility or multi-homing, do not
> >  disrupt ongoing sessions.
>
> uh, no.  not unless you're changing a lot more than the API (like the
> transport protocols), and you're also providing a way to do secure
> signaling of changes to endpoint addresses (consider that the  
> endpoints
> are often the last to know about such changes, and once their  
> addresses
> are changed they have no way of reaching their peers), and you're also
> providing a way to make all referrals work in terms of the DNS -  
> another
> significant challenge, BTW.

Of course.  Were you seriously assuming that we would not consider these
things?  They are all addressed in the paper, and they will continue to
be considered very carefully as we work the conceptual ideas of the  
paper
into more and more detailed architecture and protocol specifications.

> > - Transition to IPv6 no longer affects applications.
>
>
> wrong again, because (among other reasons) IPv4 only hosts will still
> not be able to talk to IPv6 only hosts.

To clarify:  Transition to IPv6 requires changes in three places -- in
the network, in host stacks, and in applications.  My statement above
relates to the fact that the proposed name-oriented stack architecture
would be an appropriate host stack change, which in turn would eliminate
the need for compliant applications to distinguish between IP versions.

- Christian


[1] Christian Vogt:  Towards A Hostname-Oriented Network Protocol
   Stack for Flexible Addressing in a Dynamic Internet,
   http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf