Subject: [MOBILE-IP] Bake-off issues

From: Patrice Calhoun <[email-masked]>
Date: Thu, 5 Aug 1999 12:39:46 -0700

All,

One of the biggest problems that were found during the bake-off is the fact that
RFC2002 incorrectly states how the computation of the authentication extensions
are done. Charlie Perkins has put together a Mobile-IP v2 draft, and I strongly
urge the Working Group to move this document forward to last call. The issue we
currently have is if someone states that they are RFC2002 compliant, they will not
interoperate with the rest of the world. This is obviously not to the advantage of
the IETF, and the Internet Community.

I strongly propose that the WG chairs move the said document ahead to last call.

On a side note, I have started to put together the bake-off results, but I am still
waiting for the results from two participants (you know who you are:). As soon as I
receive this information I will make it available to the list.

PatC

---

From: Jouni Malinen <[email-masked]>
Date: Fri, 6 Aug 1999 14:27:17 +0300

Unfortunately we could not take part in the Bake-off, so I'm sending
our comments on the RFC 2002bis and compatibility issues to the Mobile
IP list. I'm, however, looking forward to the results of the Bake-off
session.

Is the goal with RFC 2002bis to maintain the compatibility with RFC
2002 and the older implementation? In that case we think that the
following details should be taken into account.

I include a brief list here due to the length of the message:
- authentication extension usage
- duplicate reply types with RFC 2344
- >255-byte extension data
- co-located COA clarification

On Thu, 5 Aug 1999, Patrice Calhoun wrote:

> One of the biggest problems that were found during the bake-off is the
> fact that RFC2002 incorrectly states how the computation of the
> authentication extensions are done. Charlie Perkins has put together a
> Mobile-IP v2 draft, and I strongly urge the Working Group to move this
> document forward to last call. The issue we currently have is if
> someone states that they are RFC2002 compliant, they will not
> interoperate with the rest of the world. This is obviously not to the
> advantage of the IETF, and the Internet Community.

This authentication extension computation clearly needs clarification. If
the protected area is simply changed (like in
draft-ietf-mobileip-v2-00.txt), it would break the compatibility with the
older RFC 2002 compliant implementations. I don't think this is wanted and
luckily, in most cases, not even needed. It is possible to make the new
implementations compatible with the older ones (that are using the RFC
2002 compliant method, i.e. SPI not included in the protected area) as far
as the authentication between MN and HA is concerned.

While trying to get our implementation (Dynamics - HUT Mobile IP) to work
with others we used a compatibility mode that has an automated fall-back
to use the data area without SPI if the other end (MN/HA) is using the
older method. This way the compatibility is maintained with RFC 2002. The
first try would be to include the SPI in the protected area.

As far as the registration request from RFC 2002 compliant MN is
concerned, the compatibility mode does not introduce any new message
exchanges. The HA can first check, whether a MAC calculated with SPI
matches - if it doesn't, then a MAC calculated without SPI is checked. If
the HA notices that the MN is using a RFC 2002 method, it records this
information in the binding data and uses the compatibility mode in the
replies. This adds only one additional MD5 operation.

If it is the HA that is RFC 2002 compliant, there will be one additional
registration/request round when the MN registers for the first time. The
HA should reply with code 131 (mobile node failed authentication; RFC
2002, Chap. 3.8.2.1). The MN can then try to send the same registration
request with RFC 2002 compliant method. If this registration succeeds, the
MN uses the older method in the following registrations.

The other authentication extensions (MN-FA, FA-HA) may bring a bit more
problems as the FA must silently discard messages that failed the
authentication. So, MN-FA auth. ext. with RFC 2002 compliant FA would not
get a reply. The MN could of course try (after some time) to use the RFC
2002 compliant method, but this is not as clear a solution as with the
MN-HA case. The FA-HA case is easier, as even the older HA should reply
with code 132 (Chap. 3.8.2.1) and FA should reply with code 68 (Chap.
3.7.3.1).

I would propose, that the compatibility issue would at least be mentioned
in the draft that would eventually obsolete RFC 2002. The above described
method of providing compatibility could be added as an optional (MAY or
even SHOULD) feature.

As far as the other points in draft-ietf-mobileip-v2-00.txt are concerned,
there is couple of things that would seem to need some fixing. As a quick
remainder I might mention the duplicate codes with RFC 2344 (codes 74 and
75; see my message of July 3 to this list and Gabriel Montenegro's reply
to it).

In addition, I think that there is a potential problem spot in the
extension usage when the length of the extensions is over 255 bytes. RFC
2002 clearly states that the extension header has 8-bit long length field
(Chap 1.9). There is, however, at least couple of drafts that define
extensions with 16-bit long length field (expired
draft-ietf-mobileip-regkey-00.txt and
draft-gupta-mobileip-inline-secparams-00.txt).

The use of 16-bit long length field would clearly make it impossible
for an agent that does not know the extension to parse the message. As
far as the extensions type is between 0 and 127, this may not be very
big a problem as the message would be discarded anyway. I don't think
that this is a proper way of handling the longer extensions. The RFC
2002bis should thus have some clarification on the issue of using
longer extensions. I would propose, that a compatible method would be
used. One way would be to devide the extension data to 255 byte
fragments and have multiple extensions with same type field and a
length of 255 (and the last fragment with the remaining bytes). This
way the compatibility would be maintained. In addition, the extra
space needed for the duplicate type fields would be minimal (two bytes
for each 255 bytes of data; in case the extension would be under 256
long this would even save one byte (compared to 16-bit length field)
and with <512 bytes of data the required length would be same).

As a last point of this already long enough message I would also like to
have some clarification on the use of co-located COA and FA registration.
RFC 2002 (2.4.1) states that the MN should register through the FA even if
it might be able to get own co-loc. COA. Does this mean that the MN must
use FA decapsulation in that case or is it allowed to register with its
acquired co-loc. COA through FA?

The co-loc. COA is apparently used mostly in direct connection with
the HA. We have, used it in our implementation as a normal method of
registering through FA. The difference is, though, that we are
concentrating on hierarchical FA structure and use private address
space for the co-loc. COA.

PS.

We just released the new version of our software, Dynamics - HUT Mobile IP
v0.5, and people interested in our solutions can get more information
from our website at http://www.cs.hut.fi/Research/Dynamics/.

--
Jouni Malinen