Subject: [Mip6] RE: Comments on draft-ietf-mip6-ikev2-ipsec-01

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 04 Apr 2005 14:10:35 +0200

Hi Vijay,

> 
> hi Gerardo,
> 
> thanks for the review.
> 
> Gerardo Giaretta wrote:
> > Hi Vijay,
> > 
> > I have some comments on draft-ietf-mip6-ikev2-ipsec-01.
> > 
> > Overall, the draft looks good. In my opinion, the unique 
> general issue
> > is that it is tied very much to rfc 3776 and as a result it is not
> > self-contained. I mean that it is not possible to read the 
> draft without
> > having also rfc3776 in front of you. This is ok to me, but 
> I wonder if
> > it is acceptable in general.
> 
> I guess it can be difficult. I was worried about this too, but didnt
> want repeat all the requirements. will ask the working group 
> about this.
>

ok. 
 
> > Some more detailed comments:
> > 
> > - section 3.2: I don't understand very well how this list should be
> > read. The draft states: "The mobile node and the Home Agent 
> MUST support
> > the requirements listed in Section 4 of RFC 3776 with the following
> > exceptions" (btw, s/support/fulfill). I'd expect a clear 
> reference to
> > requirements in rfc3776, but I found sometimes difficult to 
> match the
> > requirements and to understand what really changes. Isn't 
> much clearer
> > to state all the requirements (old and new ones)? More 
> details below.
> > 
> > - section 3.2, bullet 1: in order to be more adherent to 
> rfc 3776, I'd
> > say "It is not required to configure security policies 
> security policy
> > database entries specifically for the tunnel interface in order to
> > protect return routability signaling messages".
> 
> okay.
> 
> > - section 3.2, bullet 2: how is this requirement different 
> from the one
> > specified in rfc 3776 (4th bullet page at page 12)? Could 
> you clarify
> > please?
> 
> the text on dynamic keying part has changed. for IKEv1 we talk about
> Phase 1. for IKEv2, we talk about IKE_AUTH exchange. but we cant just
> state that. need to explain why the HA needs to check if the identity
> presented in IKE_AUTH exchange is allowed to create security
> associations for a particular home address.
> 

but this is true also for IKEv1, just replacing Phase 1 with IKE_AUTH.
Am I wrong?
If so, I don't see any real change, only a terminology one.

> suggestions to improve this are welcome.
> 
> > 
> > - section 3.2, bullet 3: maybe I am missing something here, 
> but how this
> > is different from IKEv1 and rfc 3776?
> 
> not different. I see the problem very well now. some requirements I
> am repeating from 3776. will fix this, based on what the working
> group decides.
> 

okay. My issue is just that with current text it's not clear how some
requirements change.

> > - section 5.1.1, last paragraph at page 11: "In the examples shown
> > above, the home address of the mobile node might not be 
> available all
> > the time." Are you referring to the case where the HoA is 
> dynamically
> > allocated? If yes, I'd mention it at least as an example. 
> 
> yes.
> 
> > Moreover, the draft continues: "When the mobile node 
> acquires a new home
> > address, it must add the address to the corresponding SPD 
> entries." What
> > about the HA? Does the HA need to add the address to the 
> corresponding
> > SPD entries or can it keep generic entries? I think it 
> should add the
> > HoA in SPD entries.
> 
> no. if the MN initiates IKE exchange, the HA can just populate the
> SPD from the IKE exchange. it doesnt need to create a SPD entry for
> a specific HoA.
> 

I saw the proposed text in another email. I'll reply to that one.

> > - section 7: this section refers to dynamic HoA assignment. 
> I wonder if
> > this procedure should be explained in this document or in the
> > bootstrapping document. Maybe the latter, if needed, can 
> simply point to
> > this one. 
> 
> I prefer the bootstrapping document just pointing to this section
> for HoA configuration.
> 

sounds good to me.

--Gerardo

> Vijay

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

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

---

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 04 Apr 2005 14:11:21 +0200

Hi Vijay,

see below...

> here is some new text.
>     In the examples shown above, the home address of the mobile node
>     might not be available all the time.  For instance, the 
> mobile node
>     might have not configured a home address yet.  When the 
> mobile node
>     acquires a new home address, it must either add the address to the
>     corresponding SPD entries or create the SPD entries for the home
>     address.
>  
> 
>     The SPD entries on the home agent are created when the mobile node
>     initiates IKE exchange.  The home agent can also have generic SPD
>     entries to prevent mobility header traffic that requires IPsec
>     protection from bypassing the IPsec filters.
> 
> does this look good?
> 

looks good.

Thanks,
--Gerardo