Re: [Mip4] WG Last Call on draft-mip4-faerr-00.txt

Hello Naveen,

Naveen PaulKandasamy wrote:

>   "I support the advancement of this document to the IESG with a
>    request for publication as proposed standard."

Thanks!

> and  i have the following comments abt the draft...
> 
> - Length field is mentioned as 4.
> think it should be 2, excluding type/length fields as per rfc 3344 ?

Yes, thank you.  It's amazing this bug has been there so
long, consistently glossed over by me every time I lookd
at the document.

> - in the case of a MN using collocated CoA without R bit
> set, can the MN ignore the FA error extn  (in case if some malicious
> node added this extn,)
>  since this extn does not seem to relate to this scenario ?

I'm inclined to agree, but I don't think the language
belongs in this document.  I would say that ignoring
such messages is a matter to be resolved in the base
specification (now, rfc3344bis).

> also,  since this extension is unprotected, wondering if we should
> mention abt the FA behavior when a (malicious) node between FA
> and HA appends this extn to the RRP ? is the FA supposed to drop the
> RRP considering it a parse error ? am not sure if this is a generic problem
>  for all extns and has been  addressed elsewhere ?

I have checked the recent minutes, and as best I
remember the agreement was, eventually, to write
something into the Security Considerations.  In order
to avoid overengineering, I did not make any new
mandate or recommendation, but I thought anyway it
would be reasonable to _allow_ the mobile node to
take some minimal protective action if available,
namely to just wait a few milliseconds in case an
authentic registration request arrives.  Here is
what I added to section 7.

   In many typical cases, the mobile node will not have a security  
   association with the foreign agent that has sent the extension.
   Thus, the mobile node will be unable to ascertain that the foreign
   agent sending the extended Registration Reply message is the same
   foreign agent that earlier received the associated Registration
   Request from the mobile node.  Because of this, a malicious foreign
   agent could cause a mobile node to operate as if the registration had
   failed, when in fact its home agent and a correctly operating foreign
   agent had both accepted the mobile node's Registration Request.  In
   order to reduce the vulnerability to such maliciously transmitted
   Registration Reply messages with the unauthenticated extension, the
   mobile node MAY delay processing of such Registration Reply messages
   for a short while in order to determine whether another authentic
   Registration Reply might be received fromm the true foreign agent.

If the "MAY" in this paragraph is still unwanted, I'll
be happy to take it out.  And, as always, if someone wants
to supply text that would be appreciated.

With this, I think I have responded to all the comments.
The revised draft is ready for submission.

Regards,
Charlie P.

-- 
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/