Subject: Re: [Mip4] draft-ietf-mip4-faerr-01.txt review

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 18 Sep 2005 19:39:42 +0300

Hello Jari,

Jari Arkko wrote:

>
> Technical:
>
> Overall, this draft is short and seems to make a lot of
> sense. I did have one technical question (which may
> be just a lack of my own understanding), one suggested
> addition to the security considerations section and a three
> very minor editorial nits.
>
>>    A mobile node that cannot correctly interpret the
>>    contents of the FA Error Extension MUST NOT use the care-of
>>    address provided in the Registration Reply message, until another
>>    Registration Request message has been sent and a successful
>>    Registration Reply message received.
>
>
> Hmm... I may be missing something here, but why would
> the mobile node use the care-of address even if it did  "correctly
> interpret the contents of the FA error extensions"? Its an error,
> so why continue...?

Well, the HA could be providing a status code that would enable
the mobile node to use the care-of address, so perhaps it is
better to be definitive about it in this way.

>
>> 7. Security Considerations
>>
>>    The extension in this document improves the security features
>>    of Mobile IPv4 by allowing the mobile node to be assured of the
>>    authenticity of the information supplied within a Registration
>>    Request.  Previously, whenever the foreign agent was required to
>>    provide status information to the mobile node, it could only do so
>>    by destroying the ability of the mobile device to authenticated the
>>    Mobile-Home Authentication Extension data.
>
>
>>    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.
>
>
>
> This is very good. However, we should probably say something
> about bidding down attacks somewhere. Suggest adding the
> following note to the end of Section 7:
>
>    It should be noted that if the mobile node can not be certain
>    that it operates in a network that supports this extension,
>    malicious foreign agents might still be able to change the
>    status information. Where such vulnerability is unacceptable,
>    the mobile node can employ a policy where it refuses to
>    communicate with foreign agents that do not support this
>    extension.

Use of the extension will be rare -- only when an error condition
arises that is not visible to the home agent.  I don't believe we should
require yet another negotiation in the foreign network for this purpose.

I think I'll wait before adding any text along these lines.  And, the
discussion with Kent and Gabriel is relevant to this point.

>
> Editorial:
>
>>    (see section 3) from the space of numbers for nonskippable mobility
>
>
> s/nonskippable/non-skippable/

Done.

>
>>    Future allocations from this number space require IETF
>>    consensus.
>
>
> Maybe s/IETF consensus/IETF Consensus [RFC 2434]/

I changed it to expert review.

>
>>    Registration Reply might be received fromm the true foreign agent.
>
>
> s/fromm/from/

Fixed.

Regards,
Charlie P.

-- 
Mip4 mailing list: [email-masked]
    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/