Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

[Scott Brim <[e-mail]>]

Robin Whittle allegedly wrote on 01/21/2010 20:52 EST:
> Introduction of CEE would involve new host protocols and usually new
> application code and APIs

These are much less of a problem than they used to be.  However,
in any case improvements to the routing system should not depend on
changes to endpoints.  A change to routing architecture that makes no
difference in routing scalability until every endpoint in a domain is
updated isn't a wise idea.

> I believe the optimal arrangement for the Internet is not the CEE
> approach of requiring *all* hosts to take on more responsibilities
> for routing and addressing - which generally involves more state,
> more computation, delays in initiating contact with other hosts and
> the sending and receiving more and/or longer packets.  It also
> involves a lot of extra work, packets and therefore delays whenever
> the host gets a different (physical, "locator") address.  This can
> happen frequently with wireless mobile devices, even when they are
> stationary.

Better to leave mobility out of your argument.  For a mobile node,
everything you mention is going to happen anyway, and during handoff,
getting a new IP address is one of the smaller problems (compared to,
e.g. authentication and authorization and the infrastructure to support
it).  Also there are mitigation mechanisms whereby a node often doesn't
need a new address.

But you have omitted the burden on the routing domains that serve those
endpoints -- the burden on the edge networks' administration.  As the
network changes its upstream connectivity, it has to adjust its policies
to handle changes in addresses given to endpoints.

This is another example of why you want to decouple progress in the
endpoints (multihoming, multipathing, mobility, identification,
federated identity etc.) from routing and addressing architecture
(scaling, robustness, churn, reachability, complexity, administrative
overhead etc.).  They may benefit each other, but neither should depend
on the other, and each should be motivated on its own merits.


Patrick Frejborg allegedly wrote on 01/22/2010 03:54 EST:
> I agree here, do we really need to have cryptographic solution on the
> network layer?

Generally I agree.  Validation of various sorts is between consenting
parties, which may be routers, tunnel endpoints, session endpoints,
applications, whatever.  How much validation to have on which particular
packets should be up to the communicating pairs.  Validation will be
done at a higher layer anyway if at all.  Consider video distribution --
the main bandwidth consumer on mobile networks today -- which runs
multiple connections with a unifying validation scheme.

> We are trying to remove the IP address overload (identifier and
> locator) but if we are not careful we could introduce some other
> overload mechanism that somebody has to deal with in the future. The
> transport layer can take care of things and also the application layer
> can take care of things, such as cryptographic

Right, and if the upper layers have to do something anyway, why should
it be done in a lower layer?  The end-to-end principle applies inside a
stack as well as across a network.  The good reasons for providing a
function at a lower layer are if it cannot be done at a higher layer
(access to certain information is needed), or if it is certain that all
higher layer clients should use that function.

> If the host mobility is solved on the network layer it could get
> complicated as you describe above. I think the host mobility is an
> issue for the transport protocol - if we are trying to solve that on
> the network layer IMHO we are overloading the transport and network
> layer.
> 
> I think MPTCP, http://tools.ietf.org/html/draft-ford-mptcp-multiaddressed-02,
> doesn't add that much overhead

:-D but let's not forget that MPTCP is just one mechanism.  We already
have application-layer mechanisms in place that may never be abandoned
in favor of multipath transport.  Also let's get away from the idea that
a whole node ("host") is what is mobile.  The future is virtual.
Individual sessions will change their apparent location independently of
each other.  They need to be able to do so arbitrarily, so simply adding
session classes (e.g. "voice") to a whole node mobility protocol isn't
enough.


Xu Xiaohu allegedly wrote on 01/22/2010 04:58 EST:
> In the current Internet architecture, the overlapping of IP address
> semantics makes it possible to use uRPF to avoid IP (as the role of ID)
> spoofing to some extent. However, in an ID/locator split architecture, ID
> spoofing will be much harder to prevent provided there is no any mechanism
> for ID authentication (uRPF is useless for ID checking). If cryptographic
> identifiers are not used, ID authentication would have to be relied on a
> third-party certification infrastructure.

But that's the way it is today.  Communication endpoints are at higher
layers, and those that care will always check the validity of the other
endpoints' identifiers.  They do not depend on, or even expect, support
from lower layers for that.  End-to-end argument goes here.


Patrick Frejborg allegedly wrote on 01/22/2010 05:40 EST:
> The architectural question is - do the ID authentication issue belong
> to the network or to the hosts (or the application they use), where
> should the ID authentication be applied?

See arguments above about when it is appropriate for a lower layer to
provide a function for the use of a higher layer.


Brian E Carpenter allegedly wrote on 01/22/2010 15:07 EST:
> I think that authentication at the network ID level is important to
> to ensure that the physical origin of unwanted traffic can be checked
> and/or proved. 

The advantage of using a node ID is that a lower layer (network layer)
can take care of housekeeping before delivering packets to the actual
recipient (higher layer), and the higher layer can trust that everything
is okay.  Disregarding the end-to-end argument and the trust problems,
you still have the issue of virtualization.  When you're talking to me,
you don't get to know what my physical origin is.  Any of the sessions
we have open can move individually from box to box, and even from
virtual box to virtual box.  The only constant identifiers are
associated with the session or group of sessions.  Those identifiers can
be ad hoc and temporary once initial AAA is taken care of.


Noel Chiappa allegedly wrote on 01/23/2010 11:26 EST:
>     > From: Patrick Frejborg <[e-mail]>
> 
>     > Yes, and I believe that the  Trojan Horse is called MPTCP :-)
> 
> Support for multiple PA addresses does certainly help with the multi-homing
> aspects, but does it help with number (address) portability at all? 

Just for clarity: Multipath transport does not assume or rely on the
endpoint receiving multiple PA addresses from a network.

Scott