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

[Hannes Tschofenig <[e-mail]>]

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