[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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