RE: visibility of identifier in shim6 payload packet

["Bound, Jim" <Jim.Bound@hp.com>]

Tom,

I am on vacation Aug 7-28 but doing some of my non day job work at times
to clean up. My response below.  I cannot stay mail for mail but
hopefully this will help. 

> Basically, you (and Jim) seem to be arguing that, with IPsec, 
> there can not be any packet transformation below the IPsec 
> layer that cannot be undone by an intermediate device that 
> looks only at the individual packets and doesn't have access 
> to other context negotiated by key management or shim 
> protocols, and that either:
> i) shim6 should be layered above IPsec and just work on the 
> basis of locators and perhaps use mobike techniques or just 
> create new SAs when locators change, or
> ii) shimmed packets must carry the ULID in each packet for the benefit
> of BITW/BITS implementations 

The flaw in IPsec is the use of addresses, but we cannot agree in the
IETF or elsewhere what is the best identity.  If IPsec is used the
issues for RFC 4218 are highly reduced, as IPsec Architeture does
provide security in depth defense at layer 3 for the node, use, and LAN.
I am not saying we do not need multi-layered security above layer 2 or
TLS, in fact we do and far more than we have today.  But, for shim6
IPsec is fine to secure the negotiations of the locators.  PKI or
Pre-Shared keys issue are orthogonal to the securing of ULIDs completely
and unlike some here I don't see a problem for the evolution of PKI for
IPsec between peers.

Regarding end-to-end.  No IPsec did not say that exactly the Internet
architecture states it is the best scenario.  I want the ability to
encrypt my packet to you so that no one on the planet, except with
proper law enforcement, can see anything in my IPv6 packet but the IP
header and hop-by-hop or destination options.  If an intermediate box
has the authority to decrypt (meainging permission from the end-nodes or
the authority of the end-nodes) the packet that is fine, but I suggest
that decryption not interfere with the line rates of the communications
NIC and IO communications between the end-nodes.
  
> 
> But I think the above is a limiting view of IPsec, and is not 
> consistent with reality that there may be IPsec (native 
> end-to-end) within IPsec
> (BITW) that changes the selectors available to BITW, or NATs.  

Today implementations are built to decrypt as fast path with the IP
header.  That is simply the case today.

CGA further exacerbates the broken issues of IPsec by relying on an IP
address based keying and also cannot support multi-prefix scenarios as I
understand the method. HBA uses CGA spec and is still address based
keying.  We need to remvove HBA from the core shim6 spec and leave a
template for multiple solutions that are TBD.

Best,
/jim

> 
> Tom
>