Subject: RE: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 11 Apr 2006 17:00:03 -0700

Hi,

I added some text to section 5. the latest text
is at 
http://www.dvijay.com/ietf/internet-drafts/mip6/mip6_ikev2.txt
and the diff at
http://www.dvijay.com/ietf/internet-drafts/mip6/diff-05to06.html

Vijay

> -----Original Message-----
> From: Shinta Sugimoto [mailto:[email-masked]] 
> Sent: Monday, April 10, 2006 10:48 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [Mip6] Changes to draft-ietf-mip6-ikev2-ipsec
> 
> On Mon, 10 Apr 2006 17:41:36 -0700
> "Vijay Devarapalli" <[email-masked]> wrote:
> 
> > > I've parsed the diff from 05 to 06 and had some 
> comments/questions.
> > > In the "tunnel all" mode, do you assume that the IKEv2 takes the
> > > role of updating the outer endpoint address of the IPsec tunnel
> > > established between the MN and HA ?  
> > 
> > it is still the binding update that updates the 
> > outer address of the IPsec tunnel. when you 
> > decapsulate the packet (or process the tunneled
> > BU), you need to relax the check for the outer
> > source address if the packet contains a BU that
> > is updating the CoA.
> 
> Ok, I see.  So there should be exceptional handling to check inner
> packet when outer source address verification fails.
> 
> > 
> > > I mean, in my view, BU message
> > > meant to be the trigger for updating the endpoint 
> address.  In this
> > > sense, it is actually convinient for the MN and HA to 
> have transport
> > > mode SA pair which is agnostic on MN's CoA.  
> > 
> > true. it is harder for an implementation to 
> > update the IPsec tunnel SA if the message that 
> > is going to do the update is also coming 
> > through the same tunnel. actually we had this 
> > discussion just before Mobile IPv6 became an 
> > RFC. I remember Tero Kivinen, Jari Arkko, 
> > Santeri Paavolainen and myself discussing this. 
> > I believe that discussion was one of the 
> > triggers to form the MOBIKE WG. :) 
> 
> I see.
> 
> > > If we assume that all
> > > mobility signals (including BU) are sent over the IPsec tunnel,
> > > I believe MN and HA are required to run MOBIKE (or 
> re-establish the
> > > IPsec SA) prior to the home registration.  
> > 
> > the goal is not to require MOBIKE. MOBIKE can
> > be used if you want to.
> 
> Ok.
> 
> > > So, I think the draft
> > > should mention implications/side-effect that "tunnel all" 
> mode have.
> > 
> > sure. I will add some text. 
> 
> Thnaks.
> 
> 
> Shinta
> 
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 12 Apr 2006 08:57:56 +0300

On Tue, 11 Apr 2006 17:00:03 -0700

>    o  The receipt of a Binding Update from the new care-of address  
>           updates the tunnel end point of the IPsec SA as described in  
>           Section 4.3.  Since the Binding Update that updates the tunnel end  
>           point is received through the same tunnel interface that needs to  
>           be updated, special care should be taken on the home agent to  
>           ensure that the Binding Update is not dropped.  This can be  
>           achieved by either performing the source address check on the  
>           outer IPv6 header after the binding update is processed or have  
>           exception handling to check the inner packet for a Binding Update  
>           when the source address match on the outer source address fails.  
>       Typical IPsec processing does not check the outer source address. 

Above text looks good to me.  Thanks.

Regards,
Shinta