Subject: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt

From: "Jari T. Malinen" <[email-masked]>
Date: Sun, 09 Dec 2001 14:49:45 -0800

Pekka,

The HAO issue you mention can arguably be considered an implementation
issue, taken care by the note in the MIPv6 draft. However, it should be
mandatory. I'll discuss this below. I'll also cross-post this note to
the mobile-ip since you asked it there without anybody answering.

Pekka Savola wrote:
> 
> On Fri, 7 Dec 2001, Jari T. Malinen wrote:
> > Jari Arkko wrote:
> > >
> > > > To conclude, dst.hdr is in RFC,
> > > > the new proposal an individual draft so I'd say it could be
> > > > something to consider for a second generation of Mobile IPv6,
> > > > perhaps.
> > >
> > > Just a clarifying question to make sure I have correctly understood
> > > the current situation with the HAO: the DO header is in the basic
> > > IPv6 RFCs. However, the format of a specific DO that can be
> > > used to carry the Home Address, HAO, is defined in the MIPv6
> > > I-D. I'm asking this because we'd very much like to publish the
> > > cellular host draft as an RFC soon, and in order to require the
> > > use of the HAO we need not just a resolution to the security
> > > worries, but also a reference to some RFC that defines the HAO.
> > > Unless I'm mistaken, we currently don't have such an RFC anywhere.
> > > Or?
> >
> > True, though Mobile IPv6 seems to have a process and timetable to
> > achieve the same goal and also be in last stages of the process.
> >
> > HAO was presented to ipng as a mandatory feature before IPv6 was
> > finalized and it was designed to fill a missing piece of IPv6
> > functionality to support mobility. At that time it was endorsed
> > by the ipng wg and it ended up in the MIPv6 draft. It has been
> > pretty stable ever since. The only reason it is not yet in RFC is
> > due to non-HAO-format related issues.
> 
> Btw,
> 
> One interesting detail of HAO is that its processing isn't defined
> anywhere.
> 
> If you look at MIPv6 draft, the only thing it says about this (AFAICS) is
> a note in security considerations that it could be implemented like
> swapping the addresses.

This issue of HAO processing was supposed to be covered by the note you
refer to. On my opinion it is a very important note and should have had
more emphasis, but according to some other implementors, discussed (also)
in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers
in somebody's implementation which kept the formulation as it is now. Or
maybe I remember it incorrectly, I did not quite understand motivation for
the concern then.

There is a subtle transparency issue involved in this note. MIPv6 provides
transparency by letting applications see the packet as if coming from the
home address. In implementation this is at least considered to mean that
when an application reads the IP source address from the socket, it is
the home address. This implementation detail is not verbosely explained
since it should be obvious to implementors what application transparency
(from changes of the CoA) means in this respect.

The processing order both sending and receiving need to be such that the
transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6
option which can be the home address with exactly the same machinery
used with non-HAO packets. Any other protocol when using HAddr for
communication need to experience the same degree of transparency.

But, when processing other headers beyond HAO in an implementation,
transparency should also mean they see the home address in IP source just
like in a non-MIPv6 data packet. For example, when constructing an AH,
and the note is followed, we observe the swapping happens at HAO processing
in the receiving end before AH processing. If the expressed transparency
principle would be followed in IPsec integration to the fullest, this would
mean the receiving AH processing sees HAddr in IP source. When following in
AH ICV computation the rule of having the authenticated data as seen by the
receiver after processing, it should take into account this swap (swap the
addresses in the ICV computation copy of a to-be sent packet to reflect the
same swap at the receiving end's HAO processing).

Hence, on my opinion, the note should be elevated to be something mandatory.
This would fully implement the transparency principle. It requires no message
format or interface changes to IPsec, only for it to follow its existing principle
of making authenticated packet look like one seen by the receiver (to reflect the
swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the
ICV generation).

Some called this note just an implementation detail, to me there is more to it,
it gives a processing rule needed for clean implementation of transparency.
Now there may be implementations with tricks to avoid this processing when
assuming IPsec implementation is untouchable to the latest bit (the swap can't
be done until all IPsec implementations agree, since otherwise we'll get wrong
MAC value from the other end not doing the swap when this end follows the rule)..
Hence, this is more of an issue of harmonizing protocol engineering implementation
rules for inter-protocol interworking than an actual security issue.

> I have brought this up in mobile-ip@ but there wasn't any response...

Hope this gives one answer. I also hope implementors seeing this otherwise would
express their concerns now. I'd say it also points there is a siginficant body
of experimentation done with current components of MIPv6, HAO included. Changing its
format now would mean a long re-rehearsal to get to the same state of experience.
Possible, but this should be taken into account when deciding so.

> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

BR,

-Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Dec 2001 07:47:28 +0200 (EET)

> the mobile-ip since you asked it there without anybody answering.

My gripe here is the location: IMO, it must be noted in the *main
sections* of the draft how home addresses are supposed to be used (e.g. it
substitutes the source address in some implementation-dependent way for
example X.x, maintaining connections even though the source address would
change). This is taken as granted, like everybody would already know what
Home Address is supposed to achieve.  Security Considerations seems like a
completely wrong place to specify the behaviour.