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

From: [email-masked]
Date: Thu, 23 Aug 2001 20:01:53 +0300

Erik,

I have wanted to find out if piggybacking transport messages with Mobile BUs
is possible with no cost to the recipient. If any standardization activity
(other than some very easy stuff with Mobile IPv6 itself) would be needed to
allow piggybacking, let's just forget about it.

	Jarno

> -----Original Message-----
> From: ext Erik Nordmark [mailto:[email-masked]]
> Sent: 23. elokuuta 2001 12:42
> To: Rajahalme Jarno (NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: Piggybacking [Was: IPsec, IKE, MIPv6 and concensus ]
> 
> 
> 
> > 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".
> 
> 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).
> 
> > 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? 
> 
> 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
>