Subject: Re: [MOBILE-IP] [Fwd: Re: [MOBILE-IP] New version of "MobilitySup port in IPv6"draft]

From: Richard Draves <[email-masked]>
Date: Fri, 3 Nov 2000 13:30:37 -0800

> In step (2) of section 5.2.1, it does explain "... a packets
> source address
> MUST match the SA selector value". This is explained in
> section 4.4.3 also.
> The above wording is not correct. But one has to do the checks to make
> sure that the right SA was used for this packet. It would be
> nice if the
> IPv6 header's source address field contained the Home Address before
> the IPsec processing begins. Again, this is implementation dependent.
> Some implementations might find it easier to do it this way.

Thanks for helping me understand this. Doesn't the IPsec processing
(checking selectors) need more than just the source address? It needs other
selectors, like the transport protocol & port values. So if you wish to
implement the processing when you see the AH/ESP header, you need to look
ahead in the packet to find these values. This looking ahead could also find
the Home Address. On the other hand, if you delay this processing until you
see the TCP/UDP header, then you'll have already processed an intervening
Home Address option. So either way, having the Home Address option after the
IPsec header doesn't seem too difficult for implementations. What am I
missing?

Thanks,
Rich

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Sat, 4 Nov 2000 09:28:16 +1100

> see the TCP/UDP header,
        => How can you see that if you have ESP ? Have I misunderstood
         you ?

---

From: Richard Draves <[email-masked]>
Date: Fri, 3 Nov 2000 16:32:10 -0800

> > (checking selectors) need more than just the source
> address? It needs
> > other
> > ahead in the packet to find these values. This looking
> ahead could also
> > find
> > the Home Address. On the other hand, if you delay this
> processing until
> > you
> > see the TCP/UDP header,
> >

I hope so :-). When processing the ESP header, you'd use the destination
address, SPI, and IPsec header type to find the SA and decrypt the remainder
of the packet. Then to implement the required selector checks, you could
either scan ahead in the packet to find the transport header and look for a
home address option, or you could delay the selector checks until you
actually process the transport header.

As I understand it, the reasoning has been:
- some implementations find it convenient to know the home address when
processing the IPsec header
- therefore it would be convenient if the Home Address option appears before
the IPsec header
- but the Home Address option (and care-of address in the IPv6 header) needs
to be protected to process a Binding Update
- therefore the Binding Update MUST be protected by AH.

So we've gone from a matter of convenience for some implementations (which
seems minor to me, as I've described above) to a real limitation in Mobile
IPv6. If I want to encrypt my traffic, this means I have to use AH in
addition to ESP.

The alternative is to allow the Home Address and Binding Update (with a
Care-Of Address suboption) to appear after an ESP header. Why isn't this a
viable alternative that should be allowed?

Thanks,
Rich

---

From: Richard Draves <[email-masked]>
Date: Sat, 4 Nov 2000 14:46:38 -0800

> AH protects both the care of address and the home address. If
> you use ESP with
> auth you will be protecting the Home address and not the care
> of address.

As I noted in my previous message, the solution is to use a care-of-address
suboption in the Binding Update when using ESP.

>    This is my preference. Some implementations need to treat
> packet data as
>    read-only and can't actually switch or exchange addresses
> in the packet.
>
> => it is really a matter of taste... As far as I know nobody
> strongly objects
> against a solution or the other.

I think I agree with this. Each solution might have efficiency advantages
for one implementation or another, but I don't see a real functionality
difference. (Unlike the issue of MUST use AH, which is real functional
limitation.)

>    The other other argument would be, maybe I want to hide my
> home address from
>    the network that I'm visiting, and so I want to have the
> Home Address option
>    sitting behind an ESP header with encryption. :-)
>
> => if you'd like to hide your home address then you can't send binding
> updates to correspondents (because the home address will be
> in the routing
> header)...

Hence my smiley. You can't even put the routing header behind the ESP
header, because then when the ESP header is processed the destination
address is the care-of address, and you want the SA to be associated with
the home address so you don't have to change SAs when you move.

Rich

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Wed, 8 Nov 2000 16:47:16 +1100

>            => I can't see how this is not true !
>            If you statelessly autoconfigure yourself with an address
>            then you _MUST_ do DAD.
>
> => this is the same for statefull autoconfigure too.
>
        => That's fine, but it doesn't make the statement
        untrue. I'm considering the stateless part only.
        So a subset of the DAD use.

>    > => On a common wired system you can't move from a link to another
> link
>    > without a reliable indication from layer 2 like a carrier loss
> followed
>    > by a restart sequence.
>    >
>            => You also have L2 indications in a wireless system clearly.
>            They may not be identical but certainly similar.
>
> => this depends on the wireless system. Some have real carrier detections
> and some have nothing, for instance the non-standard ad hoc mode by Lucent
> for 802.11 (which can be considered as a cellular LAN if we need a
> definition by example).
>
>            => Any terminal can have multiple interfaces.
>
> => it should...
>
>            If implementations do not support them there are
>            probably other reasons and you could check with
>            implementors for that.
>
> => I've checked. For too many of them to test mobility you have just
> to unplug your RJ45 Ethernet and to plug it to another link. This is
> supposed to model some 802.11 systems (but fortunately they have in
> general a more clever way to work :-)...
> It is this limited view of what is mobility which makes me very tired
> and I believe our DAD discussion is too marked by that. This is why my
> first remark was about the context: with it we can know if the DAD issue
> is a general one or it is only for some applications (real-time) on a
> special kind of links (what I have called cellular LANs). In both cases
> it is useful to discuss (a special case issue is still an issue) but
> a general issue should be in the general document (ie. can slow it down)
> and a specific one should be addressed in a specific document.
>
        => Well there are considerations for media specific characteristics
        in the spec .... anyway the aim of my mail is to bring the issue
        to the authors' attention again since a new revision is coming
        out. I'm not trying to delay it, just to get the comments in on
time.
        I think a note on DAD would be sufficient. Even if it's in the
appendix.
        Just so people are aware of the dependencies between the two
        specs. I don't think adding that is a major job that would delay
        the spec.

        Regards,
        Hesham