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

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

Brian, you have missed the point and I will have to respond more later.
This was discused in the WG meeting.  SAs must coorespond to loactors
and if those are ULIDs fine,  but if not there is an IPsec architecture
problem here. Your comment on how IP works is not how practice or
implementations work but only in IETF marketing powerpoint charts.
Best,
/jim 

> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] 
> Sent: Saturday, July 15, 2006 10:02 PM
> To: Bound, Jim
> Cc: shim6@psg.com
> Subject: 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
> > 
> > 
> 
>