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

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

> 
> The shim6 spec does have some words about this, in particular section
> 1.6 states:
> 
>     Layering AH and ESP above the multihoming shim means that 
> IPsec can
>     be made to be unaware of locator changes the same way 
> that transport
>     protocols can be unaware.  Thus the IPsec security associations
>     remain stable even though the locators are changing.  
> This means that
>     the IP addresses specified in the selectors should be the ULIDs.
> 
> however, it would be possible to add additional detailed 
> description about how would IPSec processing look like in a 
> shimmed environment (whether in the base spec or in the 
> applicability statement)

The above is really not enough it needs to speak to the actual IPsec processing and discuss the out-of-band signaling required.

> 
> >   That would help yes.  But, the home agent address is secured with 
> > the mobile node too by IPsec.
> 
> i was not cosnidering the communication with the HA but 
> directly with the CN using RO mode

Same thing from the HA side as it is proxy to the MN.

> 
> >  Making this word change in the spec and having a 
> discussion would be 
> > progress for sure, and we can then at least discuss security 
> > ramifications.  If you go to my very first mail on this the first 
> > input is that the text discussing this part of shim6 is not clear 
> > fixing that is a priori for sure then we can go to next steps.  But 
> > the MIPv6 case is not out of band signaling per se because the home 
> > agent address was kept with the node when it roamed and did 
> not have 
> > to be securely negotiated after going mobile.  That is a different 
> > network security scenario and property than CGA in shim6.
> >
> 
> indeed the communication between the HA and the mobile node 
> is a different scenario, but the communication between the MN 
> and the CN in RO mode is exactly the same scenario than a 
> shim6 communication AFAICT and it uses the exact same type of 
> out-band signalling, agree?

It is not exactly the same all cohesive security containment is rigorous on the MN as it owns its HA address.  Much different than what we are saying here.  Also the CN still can perform IPsec processing at the IP layer without popping up to code for a shim layer.

thanks
/jim
> 
> regards, marcelo
> 
> 
> > /jim
> >
> >> -----Original Message-----
> >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]
> >> Sent: Wednesday, July 19, 2006 4:32 AM
> >> To: Bound, Jim
> >> Cc: Brian E Carpenter; shim6@psg.com; Joe Abley
> >> Subject: Re: IPsec Issue Discussed for Shim6 at IETF 
> Meeting July 10, 
> >> 2006
> >>
> >> Hi Jim,
> >>
> >>
> >> El 18/07/2006, a las 18:23, Bound, Jim escribió:
> >>
> >>> Brian and Joe, (thanks).
> >>>
> >>> If ULID is both ID and Locator that is fine.  Here is more
> >> on my issue
> >>> and sorry for late response traveling and email is a pain.
> >>>
> >>> If when the packet is transmitted and the Locator is not
> >> the ULID, AND
> >>> the ULID is the SA to decrypt the packet is my concern.
> >>>
> >>> Here is why.
> >>>
> >>> First that means some form of out-of-band signaling was done to 
> >>> identify a Locator to a ULID so the decrypt can even
> >> happen. This is
> >>> out of scope for the IPsec architecture we clearly did 
> not support 
> >>> out-of-band singaling for IPsec all the way back to the
> >> 1994 or 1995
> >>> Danvers IETF meeting when we decided to move to IPsec.
> >>>
> >>> Second I am concerned about implementations that now assume
> >> per IPsec
> >>> that in fact the Locator is the SA in the arriving or
> >> sending packet
> >>> to another node.
> >>>
> >>> Does that help?
> >>>
> >>
> >>
> >> but isn't the case that there are existent protocols that 
> also use an 
> >> out of band signaling that you mention below the IPSec layer in a 
> >> similar fashion that the shim6 protocol (and i think there 
> are valid 
> >> reasons why to do that)
> >>
> >> Let's consider that case of Mobile IPv6 and in particular 
> the case of 
> >> RO mode
> >>
> >> Suppose that we have a node M that is communicating with a node C
> >>
> >> Suppose that node M has a stable address IPH and that node 
> C has an 
> >> address IPC
> >>
> >> Suppose that M and C have established and IPSec protected 
> >> communication using IPH and IPC (hence the IPSec SA 
> contains IPH and 
> >> IPC)
> >>
> >> Suppose now that node M (which is a mobile node running
> >> MIPv6) moves and it gets a new address CoA
> >>
> >> Suppose that the communication between M and C is in route 
> >> optimization mode
> >>
> >> Consider the case of packet flowing from M to node C.
> >> In this case, packets flowing from M to the mobile node C will be 
> >> carrying CoA in the src address field of the IPv6 header and they 
> >> will carry the HoA dst option containing the IPH address 
> In addition, 
> >> the packets carry the ESP/AH header.
> >> Since the IPSec SA contains IPH (and not CoA) the IPH must be 
> >> restored by the MIPv6 layer before the processing.
> >>
> >> Actually, RFC3775 states in page 110 that:
> >>
> >>        If route optimization is in use, the mobile node 
> inserts a Home
> >>        Address destination option into the packet, replacing the 
> >> Source
> >>        Address in the packet's IP header with the care-of 
> address used
> >>        with this correspondent node, as described in 
> Section 11.3.1.  
> >> The
> >>        Destination Options header in which the Home Address 
> >> destination
> >>        option is inserted MUST appear in the packet after 
> the routing
> >>        header, if present, and before the IPsec (AH [5] or ESP [6])
> >>        header, so that the Home Address destination option is 
> >> processed
> >>        by the destination node before the IPsec header is 
> processed.
> >>
> >> This basically means, that upon reception, MIPv6 will restore the 
> >> original IPH address before the IPSec processing, so that the 
> >> original addresses/identifers can be used to search the IPSec SA.
> >>
> >> As far as i can see this is exactly the same behaviour 
> that is being 
> >> proposed for the shim, or do you see any difference 
> between the case 
> >> of the shim6 and mipv6?
> >>
> >> Regards, marcelo
> >>
> >>
> >>
> >>
> >>> Thanks
> >>> /jim
> >>>
> >>>> -----Original Message-----
> >>>> From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
> >>>> Sent: Tuesday, July 18, 2006 11:04 AM
> >>>> To: Joe Abley
> >>>> Cc: Bound, Jim; shim6@psg.com
> >>>> Subject: Re: IPsec Issue Discussed for Shim6 at IETF
> >> Meeting July 10,
> >>>> 2006
> >>>>
> >>>> Joe Abley wrote:
> >>>>>
> >>>>> On 18-Jul-2006, at 07:24, Brian E Carpenter wrote:
> >>>>>
> >>>>>> 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.
> >>>>>
> >>>>>
> >>>>> Surely the ULID is static for the lifetime of a session,
> >>>> regardless
> >>>>> of what happens to the locator set?
> >>>>
> >>>> Exactly my point; but if the ULID ceases to work as a
> >> locator, it no
> >>>> longer has its initial duality as both an ID and a locator.
> >>>> And I want to be sure than Jim doesn't see a problem in that.
> >>>>
> >>>>      Brian
> >>>>
> >>>
> >>
> >>
> >
> 
>