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

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Aug 2005 14:48:00 +0300

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...?

> 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.

Editorial:

>    (see section 3) from the space of numbers for nonskippable mobility

s/nonskippable/non-skippable/

>    Future allocations from this number space require IETF
>    consensus.

Maybe s/IETF consensus/IETF Consensus [RFC 2434]/

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

s/fromm/from/

--Jari

-- 
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/

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 22 Aug 2005 11:22:43 +0200

Hi Jari,

> interpret the contents of the FA error extensions"? Its an error,

Ah, but if the mobile node does not understand the new extension, it
will only look at the result code returned int the regular result
code field; and that result code (from the HA) may be ok.  However,
since this extension is non-skippable, a mobile node which complies
with the base spec will discard the message (as it does not
understand the extension).  So a 3344 compliant MN will do the right
thing; this text just underlines / explains this.  I'd say this text
is not strictly needed, or at least could be re-written, maybe as
follows:

   "The FA Error extension is only valid for use within Mobile IPv4
   Registration Reply messages.  The FA Error Extension is not
   skippable.  Accordingly, a mobile node that cannot correctly
   interpret the contents of the FA Error Extension must silently
   discard the message, according to Section 1.8 of RFC 3344 [2],
   and not use the care-of address it contains."

>     communicate with foreign agents that do not support this

Mmm.  In order for this to be enforceable, we would need to add a
bit to the Router Advertisements of agents, announcing support. But
this could also be spoofed, so we're back to zero.  I don't see how
this is enforceable without requiring use only of FAs with which the
MN has a security association.

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

Right to all.

	Henrik

---

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Aug 2005 12:51:08 +0300

Hi Henrik,

>code field; and that result code (from the HA) may be ok.  However,
Yes. Success needs to be prevented somehow in this case.

>thing; this text just underlines / explains this.  I'd say this text
Ok, I didn't realize this.

>   and not use the care-of address it contains."
Much better, thanks.

>MN has a security association.
Agreed. But the question is if we need to enforce
it. The first priority would be to document the
vulnerability, if it exists.

The second priority would be finding a possibility
for some subset of mobile nodes to avoid this problem,
if they wish to pay the price of not working with
existing FAs. I didn't actually think about this in terms of a
new bit. Is it possible to look at the status code value
and if its in the range designated for errors given
from the FA, and refuse to accept such an error
if it doesn't come in the FA Error Extension?

--Jari

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 22 Aug 2005 12:32:08 +0200

on 2005-08-22 11:51 Jari Arkko said the following:
[...]
> vulnerability, if it exists.

Agreed.

> if it doesn't come in the FA Error Extension?

No, the FA would not in general use this FA Error Extension
if it was the originator of an error messages; only in the
case when it has to override a message from the HA would this
be used.  What you can say is that with this extension in place,
the MN can choose to never accept a Registration Reply where the
HA's message digest is broken.  This means that any malicious
FA has to generate a complete, false reply without HA auth. ext.
present; but in that case, a later correct one could appear, as
already described in the draft.

However, this also brings us to the main point for which this
extension was designed - for use with the revised MIPv4
challenge/response mechanism, which hopefully should be
in good shape when this extension can be used.  Checking for
bidding-down usage in that context should be done, though -
I don't think draft-ietf-mip4-rfc3012bis-04.txt mentions this.

	Henrik