Subject: [mobile-ip] Issue 110 & auth data option

From: Henrik Petander <[email-masked]>
Date: Thu, 19 Sep 2002 19:55:40 +0300 (EEST)

Hi all,

I am working on changing our implementation to use the new authorization
data option.

I noticed that the ordering of the options was not defined per issue 110.
This makes the calculation of the authorization data complex. In draft 15
the auth. data suboption was the last, so the building and processing of
the data was straightforward.

IMHO, it would make sense also with the MH options to make the
authorization data option always the last one, so that the processing of
the MH and the options could be done in a single run of the MAC function.

Regards,

Henrik

		----------------------------------
		Henrik Petander
		Helsinki University of Technology,
		GO/Core Project
		[email-masked]
		Office: +358 (0)9 451 5846
		GSM: +358 (0)40 741 5248
		----------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Sep 2002 22:16:41 +0300

> the MH and the options could be done in a single run of the MAC function.

I'd like to do this. I assume we also mandate all padding to be
before BAD.

Jari
----
Issue list URL reminder:
http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 19 Sep 2002 15:25:26 -0400

Jari

> I'd like to do this. I assume we also mandate all padding to be

If you are going to do this, you'll also have change the alignment
requirements for BAD.

Personally, I don't see why this should be specified.  Normally, BAD
will end up being the last option anyway and the implementation is
only effected in the rare case where BAD is not last.

For a lot of implementations the savings are going to be even less 
significant since the whole mobility message may be in multiple bufers
(scatter/gather) and multiple MAC calls are needed anyway.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tru64 UNIX - IPv6 Project Lead
Hewlett Packard 		Tel: (603) 884-1079
Nashua, NH 03062		ZKO3-3/T07

---

From: Jari Arkko <[email-masked]>
Date: Mon, 23 Sep 2002 15:07:39 +0300

> (scatter/gather) and multiple MAC calls are needed anyway.

I agree that on some implementations several MAC calls are needed anyway.
However, I know personally several implementations that don't use multiple
buffers and these implementations could potentially benefit from this.

So there is a small benefit. The question is, is there a disadvantage?
In order to adopt the new approach, we need two things:

   (1) Change the alignment requirement for BAD from 4n+2 to 8n+2.
   (2) Add a requirement that implementations must put BAD last and not
       add any padding (not that it would ever be needed either, given
       the padding requirement).

The first item doesn't appear to cause any new implementation work
as alignment needs to be handled anyway. (I'm not quite sure how
typical message composition would change, is there a change to the
number of bytes consumed? Probably not in most cases, at least not
if the implementation put the BAD option as the last one already.)

The second item seems like a fairly simple thing also. But the MN
needs to compose the message in the right order, and the CN will
have to check it.

In conclusion I don't see any major increase in implementation
work. Since there is some benefit for some implementations, shouldn't
we do as Henrik suggested? Does the correct ordering cause a
big problem for someone's implementation?

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Sep 2002 19:02:01 -0700

Jari Arkko wrote:

> we do as Henrik suggested? 

Yes. I hadnt read this thread when I sent the earlier mail.

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 25 Sep 2002 10:00:37 -0400

Ok.  I'll go along, but please specify what should
be done with the packet if the Auth Data option is
not last.  It seems like the choices are:

	- Process anyway	
	- Silently drop
	- BAck with new error code.
	- ICMP Parameter Problem code 2

-vlad

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 25 Sep 2002 09:42:48 -0700

"be liberal in what you accept" ;-). if it is not the 
last and you still havent reached then end of the Mobility 
Header, you continue processing, looking for the relevant 
fields before verifying the authenticator field.

>         - ICMP Parameter Problem code 2

process anyway.

regards
Vijay

---

From: Joe Lau <[email-masked]>
Date: Wed, 25 Sep 2002 18:04:21 -0700 (PDT)

Jari,

On your draft "Using IPsec to Protect Mobie IPv6 Signaling between Mobile
Nodes and Home Agents,

7.2.4 Payload Packets

       mobile node SPD OUT:
         - IF interface = tunnel to home agent & source = home address &
              destination = any & proto = any
           THEN USE SA7
       ...

When the MN register with the HA with the S-flag set to 0, the HA creates 
multiple Binding Cache entries, one for each of possibly several home 
addresses.  Am I correct, that each home address will require a separate
mobile node SPD OUT/IN policy, similarly for the SAD?

Another question I have is that when the prefix is changed, the home address
will change which will affect the IPSec SPD and SAD.  How does IPSec know
the Prefix is changed w/o special handshaking mechanism with MIPv6?  

Thanks!

Joe Lau

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Sep 2002 08:18:06 +0300

> fields before verifying the authenticator field.

Well, yes but if we do this then I'm not sure what the order
requirement buys us. Then we need code to calculate the authenticator
when the message is split in several parts.

I was thinking that BAD MUST be the last one (or else drop it),
otherwise we might as well have a free order.

Note that if the order is free, then implementations who don't want to
have code for the BU send case can always place it the last one anyway,
but they have to support receiving BAD in any place.

My suggestion is that the option MUST be last, and we SHOULD
drop the BU if it is not.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Sep 2002 08:36:42 +0200

7.2.4 Payload Packets
   
          mobile node SPD OUT:

=> if the SPD doesn't support address sets, a set of entries is needed.
You are right.

=> this is not a Mobile IPv6 issue but a general issue for IPv6 renumbering:
if there are explicit addresses in the policy, the policy must be updated
when a prefix is changed... Fortunately renumbering is both a rare and
a medium term (i.e., in days or weeks) event.

Regards

[email-masked]

PS: RFC 3041 is a more important issue in this case, but again this
is a IPv6 problem, not a mobility one.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Sep 2002 08:36:42 +0200

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Sep 2002 10:15:55 -0700

okay. fine with me.

Vlad, Henrik, what do you guys say?

Vijay

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 26 Sep 2002 13:26:29 -0400

I am OK with "drop it" behavior.

-vlad