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

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 6 Oct 2000 12:32:31 -0700

>
>
> Hello Mohan,
>
> Thanks for your note.
>
> >> When calculating the AH checksum, the mobile node performs
> >> the calculation with all data in place.  This means that,
> >> during the calculation, the Care-of Address might be in the
> >
> > Why do you say "might" here ?  It is a bit confusing.
>
> The care-of address is only in the IPv6 header when the
> Home Address destination option is present.  It is not required
> for all packets to contain the Home Address destination option,
> for instance if the mobile node is at home.
>
> In fact, I wish it were not required even when the mobile
> node is away from home.  In the future, if my fantasy comes
> true and ingress filtering is abolished, there will no longer
> be such a need for this restriction.
>
> My reading of the current specification would be that the
> mobile node SHOULD include a Home Address option in every
> outgoing packet when it is away from its home domain, and
> thus possibly subject to ingress filtering.  Perhaps it would
> be good to make this explicit in the draft -- or maybe it
> is already in there and I have just not seen it lately.
>
In section 7.4,

    -  Every IPv6 mobile node MUST support sending packets containing a
       Home Address option; this option MUST be included in all packets
       sent while away from home, if the packet would otherwise have
       been sent with the mobile node's home address as the IP Source
       Address.

It is a MUST and it is not very easy to figure out what it means
by just reading it once :-)

> ------------------
>
> >> Of course, this also means that the node receiving a packet
> >> with AH will have to follow the same algorithm, which
> >> basically just means not moving data fields at all.
> >> The only complication comes when it is necessary to look up
> >> the appropriate security association for processing either
> >> AH or ESP.  That lookup, typically indexed by the
> >> Source IP address of the IPv6 header, would instead have
> >> to be indexed by the home address in the Home Address
> >> destination option.  Since that destination option would
> >> occur in the packet _before_ the security header,
> >> processing is still very simple.
> >
> > If you do it this way then other sections need change because
> > currently the draft in section 5.4 talks about Home address
> > option processing on receipt of a packet :
> >
> > ... on receipt of a packet with Home Address option,
> > the receiving node replaces the Source Address in the IPv6 header
> > with the Home Address in the Home Address option.
>
> Right.  If this change were to be made, the specification would
> require a very careful re-reading.  All 100 pages of it.
> I'd like to find a solution agreeable to everyone, make it
> correct and clear (to avoid the current problems of apparent
> ambiguity), make it simple and amenable to very natural
> processing, and get it done.
>
> The important point here is to find the simple and natural
> solution.  I hope you (and others) will be able to give the
> following discussion some very careful consideration to help
> me make sure I understand the problem before tackling the
> final specification.
>
> > I think there are other places. This tells me that the first
> > thing i do is swap the addresses (or pointers ) and then
> > do the AH computation.
>
> That is sort-of what draft 12 says (apparently subject to
> multiple interpretations), isn't it?  It wasn't my proposal,
> which was to leave the addresses in place (both on the
> transmit side and the receive side).
>
I should not have used the word swap above. There is ambiguity
and i would like to interpret it as swap.

> >                      If this is correct and  working
> > out the transmit side based on this,  you would need
> > the following:
> >
> > 1) Insert a home address option with the CoA in it.
> > 2) Do the IPsec processing  (this includes SPD lookups which
> >    needs the right source address and hence gels in easily)
> > 3) swap the addresses in the source field of the IPv6 header with
> >   the one in Home Address option after IPsec processing.
>
> I propose, on the transmit side, the following:
> 1) Put in AH, but leave the authentication field blank.
> 2) Put in the other fields as needed.
> 3) Put in the Home Address option with the Home Address
> 4) Put in the other fields as needed.
> 5) Put in the IPv6 header, with the Care-of Address in the
>    ip6_src field
> 6) Do the IPsec computation.
>
At step (6), i have to look at my SPD/SADB for doing IPsec.
Source address could be one of the IPsec selectors. In that
case, the code needs to look for home address option and
if present, do lookups with the Home Address, otherwise
use the CoA. Is this natural ?

> It seems to me that all the trouble comes on the receive side,
> in deciding what address to pass to the higher level protocols.
>
We also need to know the Home address for verifying IPsec policy
checks later. It might be easier if it is present in the IPv6
source address field as that's how the normal code would work
without the option.

> If the Home Address option is present, then the receiver is
> suddenly required to either:
> - change the fields of the received IPv6 header, or
> - change the way that data is structured to build the
>   pseudo-header for the higher-level protocols.
>
> It seems to me that the latter is preferable, given all of the
> other considerations.  If my proposal finds acceptance, then
> the programming steps for removing all of the IPv6-level headers
> and passing the results to, say, TCP, would require that the
> mobile node's actual home address be stored somewhere else
> than the received packet header.
>
> Another alternative would be to do some sort of header field
> swapping AFTER the AH processing occurs, but that seems even
> less natural than doing some sort of swap during the processing
> of the Home Address option.
>
Or change the transmit side processing as i suggested.

> > We just have to describe the bits that pass through AH computation.
> > Swapping is just a word to describe the contents of the home
> > address option and the ipv6 source address field. This is no
> > way modifying the contents of the packet.
>
> ... well, it seems like your statement requires a special
> meaning for the word "contents".  Maybe you mean "payload"...
>
Actually i meant the payload.

> > Is the above ambiguous still ? Either way is fine by me
> > as long as it is consistent. With your suggestion, you
> > have to make sure that all sections that discusses
> > about Home Address option processing is clear i.e
> > AH before swap or swap before AH ?
>
> What do you think about the "not at all swap" proposal?
> Or have I missed something else important here?
>
What we need is the actual bits passed through AH i.e what
does the IPv6 header's source address, detination address
and the home address option contain while doing the
outbound and inbound AH computation. How you derive those
should be left to the implementation. While explaining
the home address option on inbound,  the draft has
to mention that if this option is present, it contains
the home address and this will be needed for IPsec
processing. Why should it talk about updating the
source address field of the IPv6 header ?
How you form the bits to do IPsec AH computation should be
left to the implementation ? We can just describe the contents
of the Ipv6 source address field and the Home address option.

-mohan

> Regards,
> Charlie P.