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

[Brian E Carpenter <brc@zurich.ibm.com>]

Sure, in my shim6 world the ULID is an initially valid locator.
Of course, it may become invalid dynamically during the course
of a session, but that will not invalidate the SA as far as
I can see.

   Brian

Bound, Jim wrote:
> 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