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

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 4 Oct 2000 10:43:36 -0700

Hello folks,

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

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.

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: AIme Le-Rouzic <[email-masked]>
Date: Thu, 5 Oct 2000 15:19:55 +0200

Hello,

Charles E. Perkins wrote:

>address would be in the Home Address destination option.

 The RH used towards the mobile and the Destination Option Home address
are similar about many aspects. Can't we have the same behavior about AH
for both.

 To authenticate the RH the AH processing is done on the state RH will
be at the reception.That means the
Home Address in the IP header.
 The Home address in the IP header is the final state
of the packet also when HA,
 it is why it may be better to apply AH on this state.

 Best Regards.

---

From: Vijay Devarapalli <[email-masked]>
Date: Sat, 21 Oct 2000 15:08:31 -0700

Hi Charlie.

see my comments below

> processing is still very simple.

This makes the implementation of the ip_input function difficult for those
packets which carry the Home Address option before the AH. In particular, I
wouldnt know when to exactly replace the CoA with the Home address in the
source of the packet.

Consider the case where a CN/Home Agent receives a BU. The packet could be
like this

        IPv6 header, HA dest hdr, AH, BU dest hdr, TCP hdr.

The ip_input() function most often is a protocol switch which just calls the
corresponding protocol  handler for each protocol header that it encounters.
I need to replace the CoA with home address before I give it to the module
which handles TCP. I have three options

1. do the switch in the BU handling function
2. do the switch in ip_input function before calling the upper layer
functions
3. do the switch in the tcp module.

Consider another case where the packet is

       IPv6 header, HA dest hdr, ICMP

Now I have two options

1. do the switch in ip_input function before calling the upper layer
functions
2. do the switch in the ICMP module

Yet another case could be

       IPv6 hdr, HA dest hdr, Frag hdr, AH, BU, ICMP

In this case I would have to do the switch before the frag header is
processed. Now both the AH module and the BU handler need to be aware for
this.

Therefore the best and the easiest thing to do would be do the switch when
the HA dest hdr is processed. Then AH proceeds normally. The BU handler alone
needs to know where the CoA is stored (could be a pointer / in the HA dest
hdr after the switch)

I would like to propose the following.

On the Mobile Node side

Before AH checksum calculation switch the contents of the source address of
the packet and the Home Address dest option (the source address would be CoA
already). This way the CoA is also protected. This switch is not a big deal
because, most oftenAH implementation would require creating another text
string or mbuf(with mutable fields zeroed out). The checksum is calculated on
this text string. The original mbuf is left intact.

On the CN / Home Agent side

1. Process IPv6 header.
2. Process Home Address option. Do the switch. Store the CoA in the Home
Address option. Maybe use a bit to indicate this.
3. Process AH naturally. Security Association is chosen based on the source
address of the packet.
4. Process BU. Only this module needs to know that the CoA is store in the
Home Address option.
5. Call each protocol handler.

In my opinion, the above makes things easy to implement. Comments are
welcome.

Regards
Vijay

---

From: Stefan Schmid <[email-masked]>
Date: Mon, 23 Oct 2000 17:51:42 +0100

> already). This way the CoA is also protected.

  It seems you aggree with Charlie in that the CoA should be used for the AH
calculation. Or did I get you wrong?

> 3. Process AH naturally. Security Association is chosen based on
> the source address of the packet.

  If so, this does not make sense to me. If you do the "switch" (swapping
CoA with HA) before the AH processing, you could not process the AH
naturally (which would assume the CoA to be in the IPv6 SrcAddr field).

  Anyway, I agree with you that the best place to do the "switch" is when
the Home Address option is processed. However, this implies that the AH
calculation needs to use the CoA in the Home Address Option as IPv6 SrcAddr.
This shouldn't be a problem though.

Regards,

- Stefan

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 23 Oct 2000 10:14:31 -0700

hi Stefan,

see my comments below

> calculation. Or did I get you wrong?

Well, it is a bit different. The CoA is protected by AH. But the AH module uses
the IPv6 source address (after the switch, the source address contains the Home
address) for choosing the security association.

> naturally (which would assume the CoA to be in the IPv6 SrcAddr field).

The AH module need not assume anything. It can just go ahead, choose the
security association based on the IPv6 source address and calculate the
checksum over the packet. It need not bother about the contents in the Home
Address destination option.

Hope that clarifies things a bit

Regards
Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Oct 2000 10:19:30 -0700

Hello Stefan,

> calculation. Or did I get you wrong?

If you mean that the care-of address should be part of the data
included as input to the AH calculation, I agree.

However, the security association used to perform the calculation
MUST be indexed by the mobile node's home address.

> naturally (which would assume the CoA to be in the IPv6 SrcAddr field).

This procedure has the home address in the ip6_src address field
before AH processing begins.  So, AH processing is natural.

> This shouldn't be a problem though.

It is a problem, because then the security association would have to be
renegotiated every time the mobile node moves to a new care-of address.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Oct 2000 10:32:55 -0700

Hello folks,

I understand better now the implementation difficulties
which are caused by leaving the care-of address in the
IPv6 header.

So, I agree with you that we should specify the behavior
you have suggested below, which also is much closer to the
spirit of the existing Internet Draft specification.

I'll use the word "exchange" instead of "switch", since
the latter was misinterpreted in at least one implementation
effort.

I hope this is acceptable, and I am also looking for additional
comments before the next revision is completed.

Regards,
Charlie P.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 29 Oct 2000 14:31:46 +0100

=> misinterpretation MUST be avoided!

=> you already know my opinion, field exchange is a bit simpler than
more abstract way to deal with both home and care-of addresses.
Of course both must be protected and it is easier to protect them
directly (ie. in ICV and not via SA match) in place (ie. one as the
source, one in the home address option).

Regards