Re: Flow label versus Extension header - protocol itself

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Pekka,

Pekka Savola wrote:
> On Tue, 26 Apr 2005, Greg Daley wrote:
>
> > Greg,
> > Who thinks flow-labels are better than extension headers, otherwise
> > shim6 looks too much like Mobile IPv6.
>
>
> Agreed.
>
> However, it may be worth thinking a bit about the shim6 packet exchange 
> protocol itself.  Would that be based on UDP/TCP or destination options?
>
> Because if it would make sense to model the shim6 exchange protocol with 
> destination options, it would seem relatively easy to support both; 
> carrying context tag could be done very easily if someone wants to do 
> that, but the implementations would still have to support flow label.
>
> Then flow label could be used as a useful optimization, but one could 
> always fall back to using destination options as with the rest of the 
> shim6 protocol exchange if one wanted to.
I guess that there need to be some considerations on where the headers
are (TCP, UDP, DestOpt), and their relative position with regards
to IPSec (notably non-null encryption ESP).

Clearly there should be some security mechanism with which to secure
the mapping.  It would be good to have sufficient information to
identify which IPSec SA to use (some are identified by address) - this
is the first Dest Option position from RFC2460, and then also to
protect the binding for the identities and locators (either another
destination option (inside ESP from RFC2460), or a payload).

This issue has been visited a few times in SEND (where IPsec wasn't used
because of multicast, but included because of CGA discussion) and
Mobile IPv6 (Where IPSec is used, but the external header is
unprotected, and needs additional checks).

Where the outside identifier for the signalling isn't globally unique
(and what is...) there's going to be a difficulty in mapping the
identifier if the new message comes from a location not in the set.

Personally, I guess that it's OK to have two identifiers, one of which
could inhabit a destination option (if it was considered important).

If there's no mandatory requirement for destination options otherwise,
I guess that the processing would be up to the recipient (perhaps
mandatory to support on the receiver).

There are some minor potential problems if the destination option is
processed before locator update exchange, though, since an attacker not 
on the path which knows the identifier could inject packets and not
violate ingress filtering.

Greg