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

["Chowdhury, Kuntal" <[e-mail]>]

Hi Hannes,

Thanks for your valuable comments. We will include your suggested texts
in the I-D.

BR,
Kuntal


> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]]
> Sent: Monday, September 24, 2007 8:55 AM
> To: Chowdhury, Kuntal
> Cc: Mobile IPv6 Mailing List
> Subject: Re: [Mip6] Comments for draft-ietf-mip6-rfc4285bis-00.txt
> 
> 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