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:41:27 +0200

Let's get an agreement on this: the MN
can use AH without needing a new nxt header
value and without using AH on every packet
with a Home address option if :
- No piggybacking was allowed
- The IPsec selectors granularity was refined
 to see the BU option not the Home address option. 

I do however agree with the option Erik mentioned 
below (having a new nxt header) in which case only
eliminating piggybacking would be needed. 
But I would like to leave the 2 options open. 

So in one case a nxt header value is needed and in 
another the IPsec granularity is changed. Of course
this is assuming piggybacking is disallowed. 

Hesham

-----Original Message-----
From: Michael Thomas
To: Erik Nordmark
Cc: Michael Thomas; Jari Arkko; [email-masked]; [email-masked]; [email-masked]
Sent: 8/1/2001 6:20 PM
Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt

Erik Nordmark writes:
 > 
 > >    I don't understand this: destination options are not
 > >    supposed to be touched in the middle. Requiring
 > >    all destination options to be protected -- not just
 > >    BU's -- sounds like a *feature* to me. This requires
 > >    no changes to IPsec.
 > 
 > I think there are some issues here. Recall the MIPv6 uses destination
options
 > for binding updates, acks,  requests, as well as home address option.
 > 
 > Even if nobody ever invents any new destination options header this
means
 > that if the IPsec policy says that packets with nexthdr = destination
options
 > this effects packets containing e.g. home address options.
 > Thus for traffic between two mobile nodes (which always have home
address
 > options in both directions) you'd be forced to use IPsec on every
packet.
 > In fact, when a mobile node is sending packets (using its home
 > address) it must always include a home address option thus those
packets
 > would require IPsec.
 > 
 > Of course, if other destination options are invented in the future
the
 > precense of those would also force IPsec which might be undesirable.
 > 
 > So things for sure would be simpler if, in addition to no
piggybacking,
 > the BU (and binding acks, requests as well?) were sent using a
different
 > nexthdr value or otherwise using different IPsec selectors (i.e. a
UDP port
 > number would avoid this issue as well.)

Yes, the more I think about this the more I'm
inclined to agree.  Another negative effect would
be that you'd be unable to use SRTP instead of
IPsec which in turn would pooch ROHC for the media
(or at least give 12-16 bytes more of
uncompressible data per packet). A longer term
solution would be to extend the generalized port
semantics to DO's just as it's getting extended
to support SCTP right now. 

I think I'd probably favor that more for the
following reasons:

1) Creating a new header type always seems like
   a rather large club to beat on a problem
2) IPsec will work right now if you're willing
   to live with the restrictions (ie, all home
   address options would need crypto applied to
   it too)
3) The situation where this would be problematic is just the
   MN/CN traffic since the traffic is tunneled
   between the HA/MN. I imagine that *most* of
   the MN/CN BU's will actually be the weak
   variety instead.
4) Where strong authentication is used between
   MN/CN is likely to be an all or nothing 
   proposition anyway (ie, all PDA's in my
   enterprise using 802.11 MUST set up IPsec
   transport SA's to protect *everything*).
   Thus #2 may be a not-terrible restriction.

Thus, waiting for an abstracted port mechanism for
DO's may be viewed as more of a completeness
issue, rather than a must have issue.

	      Mike

---

From: Francis Dupont <[email-masked]>
Date: Mon, 06 Aug 2001 22:57:23 +0200

=> yes!

=> this is not so simple because the destination option header
is not a final one (i.e. the next header value is not a valid
protocol). So you have to do more than to convert the port field
in a profile field as we 'll have to do for ICMPv6 (to get a profile
for all ICMPv6 packets but not the neighbor discovery for instance).
This seems to be far easier to implement than to make it acceptable (:-)!

Regards

[email-masked]

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 06 Aug 2001 17:56:01 -0700

Hello folks,

One important thing to arrange is that mobile nodes should be allowed
to deliver Binding Updates "on-demand", and not upon every change
of care-of address, and not immediately after acquisition of a care-of
address.  This would in many case allow better a reduction in signalling.
There are reasonable ways to implement this, and I believe that the
ways to do this are also friendly to implementing piggybacking.

I think there is also value to allowing a mobile node to send fewer
packets, but of course this depends on traffic patterns and the mobility
factor.  Increasing the burden on bandwidth imposed by sending
Binding Updates effectively reduces their applicability, perhaps only
by some percentage, but percentage would be significant for some
bandwidths and traffic patterns.

Piggybacking has not been implemented much, but I think it has
enough advantages that it should be retained for improving the
future performance of the protocol.  Furthermore, according to
recent comments, the current state of implementation for Mobile
IPv6 is not the prime motivator for retaining or deleting protocol
features.  In fact, now it seems that no implementation is required
to attain Proposed Standard.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 7 Aug 2001 06:28:17 -0700 (PDT)

It isn't clear that there is in fact any clear win
with piggybacking. Indeed, piggybacking is almost
certainly going to be lossage with CRTP/ROHC. If
you consider layer two's which allow multiple
IP packets/frame (which is generally a Good Idea
for any slow/contentious upstream), then *not*
piggybacking would probably perform better.

Also: Alper already outlined many technical
deployment issues in IP stacks.

	   Mike