Subject: Re: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 14:01:24 +0200

Hi Kuntal,

Chowdhury, Kuntal wrote:
> Hi Hannes,
>
> Sorry for the late follow-up on this. Please see inline...
>
> -Kuntal
>
>
>   
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[email-masked]]
>> Sent: Saturday, September 01, 2007 3:13 PM
>> To: Mobile IPv6 Mailing List
>> Subject: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt
>>
>> Re-reading draft-ietf-mip6-rfc4285bis-00.txt I noticed a couple of
>>     
> things.
>   
>> * The references are out of date
>>
>> Example: draft-ietf-mip6-mn-ident-option-03.txt become RFC 4283 in
>>     
> 2005.
>   
> [KC>] Fixed.
>
>   
>> * RFC 3344 is a normative reference without a reason
>>
>>     
> [KC>] will be moved under informative references.
>
>   
>> * More RFC 2119 language is needed. When someone reads through the
>>     
> text
>   
>> then the places are pretty obvious. I could list them, if someone
>>     
> cares.
>   
> [KC>] We will add RFC 2119 in the reference list. The Terminology
> section already points to RCC 2119. What else is needed?
>
>   
I noticed that a couple of MUST, SHOULD and MAYs in the document need to 
be capitalized.
I can spot them for you, if you want.

>> * Replay Protection: There is no mandatory to implement replay
>> protection technique. To me it seems that only the timestamp based
>> replay protection really seems to be usable when used in combination
>> with the AAA infrastructure.
>>
>>     
> [KC>] I am not sure why so. It is true that only timestamp based relay
> protection scheme is specified in the current version of the I-D, but
> that should not necessitate use of an AAA infrastructure! 
>   
There are two separate issues regarding replay protection here. First, 
there is the replay protection between the HA and the MN and then there 
is replay protection also needed between MN and AAAS. For the latter you 
have to mandate the usage of timestamp based replay protection and 
resynchronization in order to get a working system. So far, only 
timestamp based replay protection is described for the interaction 
between MN to AAAs (unless you consider the extensions in 
draft-devarapalli-mip6-authprotocol-bootstrap-02.txt).

I can provide the text for you to make it clearer for you what I 
actually mean.

> Anyway, please refer to Appendix A (Rationale for mobility message
> replay protection option) for further details on the reason for
> selecting timestamp based replay protection mode.
>
>   
The appendix is fine with respect to the replay protection between MN 
and HA.

Ciao
Hannes

>> Ciao
>> Hannes
>>
>>
>> _______________________________________________
>> Mip6 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/mip6
>>     
>
>
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
>   

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Sep 2007 15:54:59 +0200

Hi Kuntal,

I wanted to be a bit more specific about the feedback regarding the 
timestamp-based replay protection technique. I believe the following two 
paragraphs should make everything clear.

In Section 5.2 of 
http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 you could write:

"

When the MN-AAA authentication mobility option is present in a BU the 
mobility message replay protection in section 6 option SHOULD be used.

"

At the end of Section 6 of 
http://tools.ietf.org/html/draft-ietf-mip6-rfc4285bis-00 you should 
indicate:

"

If the Mobile Node receives a Binding Acknowledgement with the code 
MIPV6-ID-MISMATCH, which is a response to a BU containing a MN-AAA 
authentication mobility option, and the authentication of the BA 
succeeds, the Mobile Node MUST resend the BU including the MN-AAA 
authentication mobility option, using the updated timestamp value.

"

The text about resynchronization of the timestamp between the MN <-> HA 
is already in the draft but the statement regarding the the MN-AAA usage 
is missing.
This paragraph would provide that statement.

Ciao
Hannes

Hannes Tschofenig wrote:
> I noticed that a couple of MUST, SHOULD and MAYs in the document need 
> to be capitalized.
> there is the replay protection between the HA and the MN and then 
> there is replay protection also needed between MN and AAAS. For the 
> latter you have to mandate the usage of timestamp based replay 
> protection and resynchronization in order to get a working system. So 
> far, only timestamp based replay protection is described for the 
> interaction between MN to AAAs (unless you consider the extensions in 
>> "This email message and any attachments are confidential information 
>> of Starent Networks, Corp. The information transmitted may not be 
>> used to create or change any contractual obligations of Starent 
>> Networks, Corp.  Any review, retransmission, dissemination or other 
>> use of, or taking of any action in reliance upon this e-mail and its 
>> attachments by persons or entities other than the intended recipient 
>> is prohibited. If you are not the intended recipient, please notify 
>> the sender immediately -- by replying to this message or by sending 
>> an email to [email-masked] -- and destroy all copies 
>> of this message and any attachments without reading or disclosing 
>> their contents. Thank you."
>>   
>
>