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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
