Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

[Erik Nordmark <[e-mail]>]

Daniel Roesen wrote:

> e.g. enforced(!), centrally administered site-wide policy, incl. traffic
> engineering inbound and outbound. With no way for hosts to make their
> own decisions, nothing to (re)configure, no DNS complexity, no wastage
> of bandwidth for keepalive, no communication setup delays (the slow DSL
> line have already high latency, don't want to add anything to that) etc.

[FWIW shim6 doesn't have a communication setup delay. But it does have 
"do no harm" security which is missing from your list.]

But the above sounds like asking for a "free lunch" of a BGP with 
infinite scaling ;-)

Even in Mike O'Dell's GSE the host had to choose between multiple 
destination addresses for the peer when sending at least the first packet.
So GSE doesn't seem to satsify the above requirement for the hosts to 
not be able to make their own decisions.
AFAICT any case of id/locator separation there will need be a function 
to pick locators for a given identifier, thus some additional selection 
is needed.

Apart from finding solutions that scale (which drive us towards a 
locator prefix per ISP that a site uses), we also need a solution that 
satisfies the "first, do no harm" security concerns (stated in RFC 4218).

The only deployable security techniques that address those seem to be 
HBA, CGA, and HIP's HITs. Since all of those techniques require that the 
IP identifier (what TCP and UDP sees as the IP address) be of a 
particular form, it either requires involvement of the hosts, or a NAT 
middlebox that will be a Single Point of Failure.

Thus in searching for a site multihoming approach, the requirements 
implied that the host needed to be involved in the security side.

Can we do better with respect to traffic engineering without throwing 
out security? draft-nordmark-shim6-esd outlines ways in which we can get 
the same feedback loop from routers as in GSE.

> I can't see any, as it's a host multihoming solution, not a site
> multihoming solution. The things I'm primarily missing (aside "keep it
> simple on the host end, they don't even get TCP right") are site
> multihoming features that you cannot sanely implement on hosts. But
> I'm happy to be proven wrong. :-)

Sure hope so ;-)

   Erik