Subject: RE: [mobile-ip] IPsec, IKE, MIPv6 and concensus

From: [email-masked]
Date: Thu, 23 Aug 2001 02:52:49 +0300

Erik wrote:
> 
> > The scenario is: 
> > 
> > - Need to send a BU to a CN
> >  - If there is an outgoing packet to the CN in a queue, and 
> >   - the packet is not associated with any SA
> >   - then can piggyback the BU with the packet in the queue
> >  - else send BU as a separate packet
> > 
> > If the spec allowed for this, would it be broken in some way?
> 
> Someone (I forgot who) pointed out that even this was a problem for 
> careful implementations of IPsec.
> The claim (which I understand and agree with) is that
> a TCP connection would like to use the same security policy 
> for the lifetime
> of the connection. If you don't then how can you use IPsec to prevent 
> a unsecure RST packet from blowing away your connection?
> 
> Thus if the packet is piggyback on a TCP SYN packet the peer
> is likely to assume that all of that TCP connection will be secured,
> but that will not be the case since the SYN was only secured 
> as a site effect
> of securing the piggy-backed BU.
> 

You mean that the recipient's IPsec implementation is creating new SPD
entries dynamically and implicitly as the side effect of a IPsec envelope
used with the TCP SYN packet?

If a selector for Mobile IP Next Header is defined, and the SA used for
reception of the packet specifies this selector (in which case it would NOT
contain a selector for TCP), there is no reason for the IPsec implementation
to create any SPD entries for the piggybacked TCP session. 

But there seems to be a related issue: the recipient should be able to check
that the piggybacked TCP packet can indeed get in without IPsec protection.

Normally, inbound IPsec processing matches also the packets that came with
no IPsec headers against the SPD to determine whether they *should* have
come with IPsec headers.

If Mobile IP Next Header selector is implemented as Transport Layer Protocol
selector, there is no way that IPsec inbound processing could know to look
for another embedded transport protocol selector (e.g. TCP) to make sure
that the SPD entry for that states "passby".

However, if a new selector parameter is defined for "in-between" Next
Headers, then both the sender and recipient of any piggybacked transport
protocol could check that the SPD entry matching the transport selector does
not require IPsec processing.

The new selector parameter would be needed to be implemented by all CNs
supporting route optimization (as well as the mobile nodes themselves), and
the associated check for the SPD entry for the piggybacked transport message
should be implemented at the same time as the new selector parameter.

By the RFC2401 only the first matching SPD entry is used for packet's IPsec
processing ("the first matching entry is consistently selected"). This would
need to change in case of "in-between" Next Header selectors and piggybacked
transport protocol messages, where multiple SPD entries need to be selected
and checked by both ends. Is this acceptable? 

	Jarno

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 10:43:16 +0200 (CEST)

> used with the TCP SYN packet?

I think that is what I'm saying (I've though more in terms of what
the implementation does than how this fits with the SPD concept).
I think an example is that the SPD initially has a matching entry
(e.g. just for TCP + the destination port) allowing IPsec or no IPsec.
But when a new connection is created an SPD entry is created which matches
just that connection and the entry constrains the policy to be what
was used on the SYN.

I don't know if such a scheme is discussed in RFC2401 but it seems useful
since it allows one to build servers where the client can choose whether
or not it wants to use ipsec i.e. there is less coordination needed.

> to create any SPD entries for the piggybacked TCP session. 

So how would you solve the above issue in that case?

> and checked by both ends. Is this acceptable? 

Seems like things are simpler without piggybacking.

  Erik

---

From: [email-masked]
Date: Thu, 23 Aug 2001 11:07:12 +0000

> not require IPsec processing.

This is exactly what my second comment in my previous email was 
about. Todays IPSec doesn't provide this functionality, so IPSec 
would need to be enhance by the following: 

1. Add a new IPSec selector (what you called "in-between" Next 
Header)

2. Allow IPSec implementation to apply two IPSec policies (one for 
the "in-between" Next Header, one for the payload) to the same 
packet. What shall be done, if both are contradictorily? This could 
become quite complex for implementations.

And as you mention below, this has to be done for all CNs and MNs, 
that is for nearly all host implementations. I'm not sure if it will 
be possible to get these IPSec modifications done. And is 
piggybacking really worth this effort?

> and checked by both ends. Is this acceptable? 
Wolfgang

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 23 Aug 2001 11:42:13 +0200 (CEST)

> that the SPD entry for that states "passby".

Yes, and in order to simplify things if we decide to remove piggybacking
the BU next header (or whatever it will be called) will be defined
as a new transport header from the IPsec perspective (i.e.
the same way you'd add SCTP support).

> and checked by both ends. Is this acceptable? 

I have no idea how complext such changes would be.
For instance, what would happen if the SPD matches for one part of the
packet and not the other - would the whole packet be rejected or
just the part with a non-matching SPD be ignored?

Let's step back and look at what problem we think we are solving with
piggybacking:
 - saving packets and or bytes on the first hop link of the BU
 - saving packets and/or bytes end-end (since other hops might have
   low bandwidth)

If all we care about is the first then one can envision an IPoverFoo specific
method of carrying two IP packets in a single link-layer packet.

If we care about solving the second one perhaps we can make this more
explicit and simple but providing exactly such a mechanism: an e2e mechanism
to send two packets (with the same IPv6 source, dest, tclass, and flowid)
as a single packet.

This could be done by definition a new extension header called
	multipacket
which would include some number of nexthdr and lengths values.

The receive side processing of such an extension header would occur before
IPsec (i.e. IPsec header would not be placed before this header) and
would result in two separate packets being produced and processed completely
independently by the receiver.

Thus the IPsec SPD checks would apply to two separate packets just as without
piggybacking.

So what problems does the multipacket extension header introduce?
Well, if it is general then firewalls and other middleboxes migh need to
look deeper into the packet. But this isn't much different than skipping the
destination options header containing the BU.

What diffserv labels(tclass) would apply to the packet? 
Should we restrict the multipacket extension to only contain one TCP/UDP
packet to make such determination easier?

[BTW: I think Robert Elz proposed such a mechanism for IPv6 a long time ago -
back when IPv6 header formats were painted using charcoal and greese inside 
caves in Australia, France, and elsewhere.]

   Erik

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 23 Aug 2001 08:31:41 -0700

Hello Erik,

> to send two packets (with the same IPv6 source, dest, tclass, and flowid)

Since both source and destination could often be wireless (or, more
abstractly, low-bandwidth) connections, end-to-end is important.
If you believe in ad hoc networks, then some intermediate links
might also be low-bandwidth.

The main purpose is saving packets by not sending Binding Updates
unless they are needed, and often they aren't needed until the
mobile wants to send data.  In cases where the Binding Update was
needed and the mobile node knows this but doesn't have any data,
then of course the update can be sent.  In cases where the mobile
node guesses wrong and doesn't send the update even when some
correspondent node would find it useful, either the home agent
or a smooth handover mechanism can help.

For this, I think it is very natural to model the outgoing data
stream from the mobile node as requiring occasional redirection
for the correspondent node, whenever the mobile node determines that
its previous care-of address isn't topologically correct any more.
This model leads naturally to including the Binding Update with
the data itself, because the route table can be marked with a flag
that says when packets need to include a Binding Update.

Of course there are other ways to model the necessary signalling,
somme of which will resolve some of the current difficulties with
IPsec AH.  I am in favor of continuing the existing way of including
Binding Update with data packets because it is bandwidth-efficient,
and there is a natural implementation for it.

If IPsec AH did the right thing for our needs, this discussion
would never have come up.  Furthermore, there are plenty of people
who claim that AH was a mistake anyway, independent of Mobile IP.
If IPsec AH can be made to do the right thing in the future, we should
allow it.  But to use IPsec AH problems as the basis for reducing the
potential performance of Mobile IPv6 seems wrong to me.

I'm reminded of the frequent accusations that IETF doesn't care about
wireless.  A lot of people do.  Other people think it's not worth
the effort.  I hate to see a valuable tool in our arsenal against
performance-loss to be discarded just because current IPsec AH
technology (itself frequently denigrated) does not yet provide the
exact semantics we need.  It would be different if we absolutely had
no other solution, but the authentication data suboption for the
...-14 Binding Update does solve the problem, and maybe in a way
that is better than using AH.

> which would include some number of nexthdr and lengths values.

Agreed that one could define new extension headers, but then I
don't see why that is better than what we've already done.
The devil is in the details, and who's to say that a year from
now we wouldn't still be bogged down in the new details of the
devil we didn't know yet?

Furthermore, the current Binding Update is a simple upgrade to
existing implementations.  This should be given due consideration.

It seems to me that going forward with what we have, with the
appropriate changes as have been noted over the last few weeks,
is a minimum energy and yet very effective solution.  I think that
is a lot better than assigning a heavy weighting factor towards
satisfying IPsec AH constraints which seem to be themselves
evolving and undergoing clarifications.

Regards,
Charlie P.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 23 Aug 2001 09:06:25 -0700 (PDT)

> to send two packets (with the same IPv6 source, dest, tclass, and flowid)

   Note that links with low bandwidth are fairly
   likely to want to use CRTP/ROHC themselves, so the
   actual cost of the IP6 header should be close to
   nil since it is almost completely compressible.
   This has the nice property that hops that care,
   can choose. Hops that don't don't. Also, you're
   proposal for layer two blocking applies equally
   well for intermediate/far end as well. Indeed,
   the way that DOCSIS modems work with concatenation
   (ie L2 blocking), having serveral packets in the queue
   at the same time is all that is required to cause the
   modem to ask for a larger transmission slot. This
   is a *much* larger win than any particular L4+
   packet piggybacking on another L3 packet, and is
   *far* less complex.

 > packet to make such determination easier?

   Right, and the same goes for intserv flows. Worse is 
   that when you have an L2 CBR QoS class on a shared
   media, all of the schemes I know of rely on some sort
   of TDM like multiplexing where you get a fixed slot
   sized allocation to send your data ever so many
   milliseconds. Variations on this theme abound but
   they all rely on the property that you minimize your
   slots to the minimum so as to not waste lots of
   bandwidth. In this case (and I think it's very pertinent
   to wireless -- a shared media), piggybacking is either
   a non-starter, or detrimental if you decide to carve
   out slots big enough to carry the occassional BU.

	     Mike