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

From: Mohan Parthasarathy <[email-masked]>
Date: Wed, 4 Oct 2000 12:30:10 -0700

>
> It seems that there are now multiple incompatible
> interpretations of the specification within the
> existing Internet Draft, that deals with making AH
> computations when the Home Address option is present.
>
> I would like to mandate (i.e., MUST) the simplest possible
> strategy, to wit:
>
> 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.

> Source IP address field of the IPv6 header, and then the home
> address would be in the Home Address destination option.
>
> 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.

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. 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.

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.

> My belief is that this is the simplest solution and makes
> for a really unambiguous specification, promoting both
> interoperability and ease of processing as well as better
> compatibility with existing specifications for the order
> of options processing.
>
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 ?

-mohan

> Comments will be appreciated.  A message which captures
> a lot of the previous discussion is appended after the
> main body of this note.  In the appended discussion, the
> question is raised whether a node receiving the Home Address
> option can easily change the way it looks up the security
> associations to depend on data in the Home Address option
> instead of the IPv6 header.  I have heard that this is
> not a problem.  I do not know the code myself, so I will
> rely on input from others who have the appropriate experience.
>
> Regards,
> Charlie P.
>
>
>
>
> -------- Original Message --------
> Subject: Re: [MOBILE-IP] New version of "Mobility Support in IPv6" draft
> Date: Sat, 23 Sep 2000 19:39:11 +0200
> From: Francis Dupont <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
>
>  In your previous mail you wrote:
>
>    My understanding is that the current specification makes it
>    mandatory to copy the home address into the ip6_src field of
>    the IPv6 header.  Swapping should not be performed.  Here,
>    "replace" means "copy over".   I reckon that the current
>    specification should be made unequivocal on this point.
>
> => I disagree. You need to protect both the source address and
> the address in the home address option (they should be the care-of
> and the home addresses of the mobile). If you consider a common
> binding update then you can see why this is important.
>  IMHO addresses must be swapped but there are two incompatible
> ways to do this:
>  - swap field contents (easy, simple but some people don't like this)
>  - swap pointers (more difficult but keeps the packet read-only).
> Someone must do the choice and write the result in the draft!
>
>    ---- insert big logical break delimiter at this point ---------
>
>    While thinking about the effects of this requirement, I found
>    myself wondering why.  It seems like the natural processing
>    for the mobile node, when creating the Authentication Header,
>    would be to calculate the authentication data starting with
>    the predictable fields of the IPv6 header and extensions with
>    as little change as possible.
>
> => you should consider the receiving side for AH processing.
> When the receiving side executes the home address option then
> it updates the source address (the field itself (physical) and
> the pointer to it (logical)). The AH is after then the source
> address is supposed to be the home address when the AH is processed
> and (the important point) when the security code looks for its
> parameters.
>
>    I would think that, typically, the IPv6 header already has the
>    mobile node's Care-of Address inserted as the ip6_src field before
>    the Authentication Header calculation is initiated.
>
> => it is not so clear and:
>  - the security parameters lookup (SPD/SADB) is more important than
>    the AH calculation itself and must be done with the home address.
>  - the AH calculation has to deal with mobility anyway.
>
>    Then, in order to make the spec work, the mobile node has
>    to proceed as follows:
>    - Put in its home address as ip6_src, temporarily
>    - Do the AH thing
>    - Restore its care-of address as ip6_src.
>    This seems like a lot of extra work, and a very handy
>    place to put bugs.
>
> => AH calculation is in general a very handy place to put bugs.
> Mobility doesn't make things worse, it just justifies we keep AH (:-).
>
>    What if we make it so that the recipient uses the address
>    in the Home Address option to select the appropriate security
>    association?
>
> => this is an important point. The current spec makes this easy
> for the recipient which:
>  - is the way AH processing is defined (cf routing header case)
>  - puts the burden on the mobile node shoulders
>  - works.
>
>    I understand the current specification to be fashioned so that
>    the recipient can select the security association based on the
>    contents of the source IPv6 address in the IPv6 header.
>    However, whether or not to actually CHANGE the fields,
>    treating them as mutable,
>
> => swapping pointers is better for that (it was proposed by
> Microsoft Research people who consider the packet as read-only)
>
>    seems to introduce a lot of unnecessary specification difficulties
>    that could be avoided.
>    Changing the way that a security association is looked up
>    seems a lot cheaper than copying and recopying data within
>    the challenge data.
>
> => I am not convinced by your argument. In fact I am not convinced
> by any argument for field or pointer swapping (:-)... Both are not
> obviously right but this is a minor point: the real issue is to
> deal with IKE (the draft proposal works, this is just a bit hard
> to implement and very hard to configure).
>
>    If everybody hates this idea, then just forget I mentioned it!
>
> => the only thing I really hate is to have no clear statement in
> the current draft. It will make one half of secure mobile IPv6
> implementations not interoperable with mine...
>
> Thanks
>
> [email-masked]
>
> PS: another missing point in the current mobile IPv6 draft:
> the home agent is a router then can have more than one address then
> the draft should *accurately* specify what address the home agent
> MUST use as the source address of tunneled packet (the answer is
> obvious but a specification is better than common sense, don't forget
> a paranoid mobile node will check the source address of tunneled packets).
> (the similar issue for BA/BR is already in the mailing list archive
> because it simply breaks sequence number check)
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 6 Oct 2000 09:29:06 -0700

Hello Mohan,

Thanks for your note.

> 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.

------------------

> 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.

> 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).

>                      If this is correct and  working
> the following:

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.

It seems to me that all the trouble comes on the receive side,
in deciding what address to pass to the higher level protocols.

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.

> 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"...

> 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?

Regards,
Charlie P.