Subject: RE: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts- 00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 1 Aug 2001 19:24:35 +0200

Vijay, 

B cannot work at all. all packets from tbe MN to the CN 
contain a home address option in a destination options 
header. that means the security association is applied 
to every packet between the MN and CN. so 'B' also needs 
option specific selectors.

=> The Home address destination option is not 
relevant here. The BU is. These are 2 separate
options so you don't need to apply the AH to 
every packet. 

Hesham

Jari Arkko wrote:

> So, in my mind our options are the following (again talking only
> about the BU protection, not the key exchange):
> 
>     a) The mip-specific scheme in the -14 draft
>     b) Standard IPsec usage without piggybacking
>     c) Fixed IPsec which enables piggybacked and/or
>         option-specific selectors
> 
> Personally, my main preferences are either (a) or (b)
> solutions. There are differences between these two
> approaches, but the main significant question seems
> to be if the piggybacking is needed or not. Has someone
> looked at the concrete benefits of piggybacking in terms
> of numbers somewhere, preferrably taking in account
> various header compression schemes that get to be
> applied on the most sensitive links? Please note that
> separate packets can still be sent in parallel, no additional
> RTTs should be introduced. Also, there might be other
> factors such as firewall rule sets that affect this discussion.
> 
> Jari

---

From: Michael Thomas <[email-masked]>
Date: Wed, 1 Aug 2001 13:49:51 -0700 (PDT)

> options so you don't need to apply the AH to 

   I'm pretty sure that Vijay is correct here. IPsec selectors
   do not define a standard way to use the port numbers in
   the ID payload to select for different destination options.
   This is probably not that hard to define, but it's not
   standard now.

		Mike

---

From: "Jari Arkko" <[email-masked]>
Date: Thu, 2 Aug 2001 07:20:52 +0300

>    This is probably not that hard to define, but it's not

It has earlier already been discussed that if a _new next
header number_ is allocated for the BU then there is no
issue, and current standard can be used.

Jari