Re: Flow label versus Extension header - protocol itself

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

Hi Marcelo,

marcelo bagnulo braun wrote:
[cut]
> > If the upper layer on the data plane is only AH or authenticated ESP,
> > there's no need to be particularly careful about the matching and
> > whether
> > the source and destination addresses are in the locator set, since
> > the authentication mechanism will take care of it.
>
> ok, so you are considering a scenario that depending on what the next 
> header, the demux operation is performed based on different context 
> tags, i.e. if there IPSec is done based on the SPI, if no IPSec use the 
> flow label, for example?
>
> My only concern about this multi-context tag situation is the added 
> complexity, especially considering that we need a general purpose 
> mechanism to deal with the general case, where the next header is no 
> useful for us

Yes, I guess there should only be one specification (and simple).
As mentioned, pre-signalling works OK no matter what the allocation
scheme is used.

[cut]
> > As a slightly comical solution: we could use AH (or a trusty
> > authenticated ESP)
> > as our already defined extension header.  SPI's are already sender
> > assigned,
> > and are even bigger than flow labels.
>
> in the data packets, you mean?
>
> but wouldn't this imply that all data packets need to be protected with 
> ESP or AH, imposing crypto for all data packets?

Oh yes.  I said it may be comical.

It's not really crypto anyway, it's an HMAC.
I don't think we need to worry too much about
the burdens of using HMACs.

It lies within the realm of possibile, although not
necessarily desirable, solutions.

[cut]
> > So it may be possible for someone to quickly shift to a valid source
> > and destination pair without explicitly signalling at that instant.
> >
> > essentially, the signalling could say: all these are valid locators,
> > please be ready for these packets.
>
> fully agree, so this is not a problem, right?
>
> i mean, before accepting packets from a given locator, this locator has 
> to be be contained in the locator set and properly verified. through 
> this verification process, it is possible to guarantee that the context 
> tag associated to this locator is good for uniquely identify the 
> associated shim context...
>
> I mean, i don't see a problem which is specific to the context tag 
> assignment mechanism....

I agree.

So sender or receiver allocation becomes purely a choice about
whether to match on <source,tag> (receiver) or <source,dest,tag>
(sender).

Does the signalling have to say which destination locators a
host will communicate to in the receiver case?

[chop]
> > Well, perhaps it doesn't matter in the general "I haven't seen the
> > address
> > but I know the label", but for a previously known valid <src,dest,label>
> > mapping, you shouldn't need to signal that the packets are about to
> > arrive like MIPv6 does now.
>
> agree.
>
> What is needed is a signalling mechanism to add locators to the locator 
> set and properly verify it (at this point a valid context tag can be 
> assoicated by the receiver, as you suggested)
> Once that the locator is included in the locator set and verified, it 
> can be used without prior signalling to announce its usage in the data 
> packets

Subsequent signaling (not on the critical path) may be able to be used
to verify path reachability, in an analogous manner to STALE neighbour
cache entries, if no upper layer confirmation is available.

There should be some experiences available from IKE DPD which apply
(if there is no use of IKE itself).

Greg