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

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

I was speaking of HA and MN in context of BU excahnge for HA notification.  The rest below is really the same debate as the thread I will respond to I just sent.
thx
/jim 

> -----Original Message-----
> From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On 
> Behalf Of marcelo bagnulo braun
> Sent: Wednesday, July 19, 2006 3:14 PM
> 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
> 
> 
> El 19/07/2006, a las 19:59, Bound, Jim escribió:
> 
> >
> >>
> >> 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.
> >
> 
> i am not sure i understand...
> 
> a description of the IPSec processing is what i mentioned 
> above, so i guess we agree here
> 
> in addition, you suggest to include the out of band 
> processing, but if i understand correctly this IS the shim6 
> protocol, since this is the way the alternative locators and 
> associated security information is conveyed... we could put 
> it explicitely...
> 
> >>
> >>>   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.
> >
> 
> No, the HA is not involved in the data path when RO mode is used,
> 
> in RO mode the data packet flow directly between the MN and 
> the CN, so 
> the two cases RO and BT mode are different. The point is that RO mode 
> requires similar out of band signaling and result in a IPSEc 
> processing 
> equal to the one of the shim6 protocol
> 
> >>
> >>>  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.
> 
> the point is how oes it proves to the CN that it owns the 
> HoA... using 
> IPSec? no, because, similarly to the shim6 case, in order to 
> use IPSec 
> for this you would need global PKI. So alternative methods (the so 
> called out of band signalling) are needed. The result in 
> terms of IPSec 
> processing is the same than in shim. Both MIP and shim lie below the 
> IPSec layer and the translate the locator of received packet to the 
> original identifiers/home address, so that the IPSec SA can 
> be searched 
> using the identifiers and not the locators used to route the packets.
> 
> 
> 
> >   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.
> >
> 
> I don't see why do you day this... MIP needs to restore the 
> HoA before 
> the IPSec processing exactly the same that in the shim case, 
> where the 
> shim needs to restore the ulids before IPSec processing. In 
> both cases 
> the security of the binding between the identifier and the 
> locators is 
> not based in IPSec but is this out of band security.
> 
> Regards, marcelo
> 
> 
> > 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
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> 
> 
>