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

[Hannes Tschofenig <[e-mail]>]

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:
> 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:[e-mail]]
>>> 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
>>> [e-mail]
>>> 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 [e-mail] -- and destroy all copies 
>> of this message and any attachments without reading or disclosing 
>> their contents. Thank you."
>>   
>
>


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