Subject: [mobile-ip] Issues in RFC 3344

From: Pete McCann <[email-masked]>
Date: Wed, 11 Dec 2002 13:46:53 -0600

Hi,

A couple of ambiguities in RFC 3344 have come to light in recent
interoperability testing.  The issues revolve around the handling of
Registration Replies cerrying a reject code generated by the FA, due
to (for example) failure of MN-AAA authentication or the use of a
stale challenge.

The following text might be the most relevant:

3.6.2.1. Validity Checks
...
   If the Code field indicates an authentication failure, either at the
   foreign agent or the home agent, then it is quite possible that any
   authenticators in the Registration Reply will also be in error.  This
   could happen, for example, if the shared secret between the mobile
   node and home agent was erroneously configured.  The mobile node
   SHOULD log such errors as security exceptions.

There are cases where the Code field indicates rejection at the FA
(for reasons that may or may not be related to authentication failure)
where a valid MN-HA extension may not be present.  What should we do
with those messages?  Should they be silently logged as security
exceptions, or should they trigger recovery actions as in the case of
any failed registration request?

There is a potential security problem here, if the MN is going to be
taking any action based on an un-authenticated Registration Reply.
This consideration is mentioned in RFC3012(bis), but maybe some note
of it should be made in the base Mobile IPv4 protocol.

Also, some implementations have been observed to append an invalid
MN-HA authentication extension when the FA generates a rejection code
in a Registration Reply.  Should these replies be processed as if the
MN-HA extension was simply missing?

I think there was inadequate attention given to this matter, and point
to the following text (which I think should be fixed) as evidence:

3.4. Registration Reply

   A mobility agent returns a Registration Reply message to a mobile
   node which has sent a Registration Request (Section 3.3) message.  If
   the mobile node is requesting service from a foreign agent, that
   foreign agent will receive the Reply from the home agent and
   subsequently relay it to the mobile node.

This text seems to assume that all registration requests are forwarded
on to the HA, and that all replies will be generated there relayed on
to the MN.  As we know that is not the case.

2nd issue: I recall a while back that we discussed on the list
backwards compatibility of the 2002-bis draft, and in particular the
problems with the following kinds of text:

3.5.2. Mobile-Home Authentication Extension

   Exactly one authorization-enabling extension MUST be present in all
   Registration Requests,

3.7.2.2. Forwarding a Valid Request to the Home Agent
...
      -  It MUST process and remove any Extensions following the
         Mobile-Home Authentication Extension,

This text would prohibit, for example, an MN that used *both* MN-HA
and MN-AAA in the same registration request.  Didn't we agree at one
point to change "Exactly one" to "At least one"?  There were also a
lot of other agreed changes throughout the text to fix related
compatibility issues.  Whatever happened to these fixes?

Sad to say, but I think we need an RFC3344bis.  Is there a possibility
that this could be undertaken by the working group?

-Pete

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 11 Dec 2002 12:34:37 -0800

Pete McCann wrote:

         ....... useful observations ............

> that this could be undertaken by the working group?

I think there was always an intention to make RFC3220bis.
RFC 3344 was published with the very strict constraint to
ONLY supply text that was erroneously deleted at the RFC
editor's desk.  The technical corrections which would have been
applied to RFC 3220 were disallowed from inclusion in RFC 3344.
The story as I understand it now, is that corrections to
RFC 3344 (for instance, to the problems you have identified)
could be applied as part of the process of republishing
Mobile IPv4 as a Draft Standard.

When that time comes, I will create another web page with
issues as has been done successfully for Mobile IPv6.
I think this may also be tied in with the possibility of
moving Mobile IPv4 specfication work into another working
group.

Regards,
Charlie P.