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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Fri, 3 Aug 2001 00:07:02 +0200

I'm pretty sure that Vijay is correct here. 

=> No because the statement assumed that the Home Address
option implied that protection is required. 
It is the BU option that implies that. 2 different
options.

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.

=> My point has been that, provided there is no piggybacking
we can keep the selectors' granularity as they 
are by creating a new nxt header value or 
increase the granularity by looking for 
the BU option. ONLY packets with the BU option
will be protected in either case. 

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: Sun, 5 Aug 2001 08:29:21 -0700 (PDT)

> will be protected in either case. 

   If we burned a new protocol number, that's correct.
   Maybe I'm the only one who has a lot of reluctance
   of burning protocol numbers...

	      Mike