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

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

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:[e-mail]] 
>>Sent: Saturday, July 15, 2006 10:02 PM
>>To: Bound, Jim
>>Cc: [e-mail]
>>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
>>>
>>>
>>
>>
>