Re: IPsec Issue Discussed for Shim6 at IETF Meeting July 10, 2006

[Brian E Carpenter <[e-mail]>]

Jim, I don't understand your architectural issue here. IPSec is very much
an end-to-end protocol so relies on an e2e identifier (which is why
we have to fiddle around to get IPSec through NAT). It isn't required
that all packets belonging to a given SA travel the same path,
because IP doesn't have that property anyway. So none of my
architectural alarms go off here. (I'd certainly have no problem
with the chairs asking for an early Security Area review, however.)

The shim is clearly placed below IPSec in the stack. That was
documented in draft-ietf-shim6-l3shim. Is that draft dead?

     Brian

Bound, Jim wrote:
> Per the Chairs to WG,
> 
> Currently for Shim6 the ULIDs are used to encrypt and decrypt the Shim6
> packet per discussions on this with the authors for IPsec.  This is done
> and possible because there is a context associated with the locator pair
> from out-of-bound message exchange at each end point to identify the
> ULIDs for location pair association.  This means the locator pair in the
> IP header are not used for IPsec encyrpt and decrypt as is done today
> according to IPsec.
> 
> This is using out-of-bound signals to set up IPsec and was specifically
> rejected as a method for IPsec when defining the IPsec architecture back
> in 1995 at IETF Danvers meeting. In addition this type of use of IPsec
> should be verified and supported by the IPsec WG within the IETF.
> 
> This could be an IETF Last Call objection presented to the IESG for
> Shim6 base protocol spec.  In addition this part of Shim6 requires much
> better writing and explanation to provide absolute clarity of the
> situation and mechanics for processing IPsec.
> 
> Best,
> /jim
> 
>