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

From: Erik Nordmark <[email-masked]>
Date: Wed, 1 Aug 2001 18:00:15 +0200 (CEST)

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

   Erik

---

From: Michael Thomas <[email-masked]>
Date: Wed, 1 Aug 2001 09:20:34 -0700 (PDT)

> 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