Re: Flow label versus Extension header - protocol itself

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

Hi Marcelo, 

----- Original Message -----
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Date: Thursday, May 5, 2005 7:06 pm
Subject: Re: Flow label versus Extension header - protocol itself

[cut]
> >
> > Yes, it's always needed, but the time ordering of the packets to do
> > the signalling may not be strict.
> >
> > If the upper layer protocol is ESP with authentication (or AH),
> > for example, it will be possible to identify that the flow
> > belongs to an upper-layer data stream because of the SPI, and the
> > fact that the packet authenticates using the right HMAC.
> >
> 
> Are you considering the situation where the verification of the
> new locator is done through IPSec?
> 
> I mean, so far, i think we had considered the case where the 
> addition of new locators had its own security mechanism
> (different from IPSec) and that there was an explicit signalling
> message for adding new locators to the set, and that these
> messages carry their own authentication information.
> I mean, i think it is important to properly define what scenarios 
> are we considering...

Certainly.   

I was actually thinking that if signalling and data are in separate
messages, data plane messages are unprotected.

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.

The signaling scheme needs a separate and robust scheme for 
communicating
mappings.  I wasn't recommending use of IKE/AH for that because people 
will
throw stones at me (it's Internet Area not Security Area ;)

We'll discuss this soon.

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.

Worse ideas have got to Proposed Standard.

> > This may not be palatable to all, but the possibility is there
> > (and may be dismissed later).
> >
> > Packets sent before the signaling wouldn't be guaranteed to get
> > through, but if the actual signaling took computation time
> 
> Well, i my understanding data packets carrying new lcoators that 
> have not been added to the locator set through proper signaling
> will be discarded... I mean this is similar to MIP RO, a CN won't 
> understna packets coming from a CoA before the BU binding the new
> CoA to the HoA has been received and verified, right?


I see a difference with MIPv6 in that even if a locator has been added
to the set, the address mappings aren't 1-to-1 (like MIPv6). There 
may be N valid <source,label> pairs with M valid destinations in a one-
way
stream.

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.

If there was only a label to check initially, this would limit the
forwarding plane processing and storage requirements (limiting them
to a small known set of addresses for a particular tag, rather than
matching <source,tag> pairs).

> > (or a longer, reliable signaling path), this is an optimization
> > which would work well for some data.
> >
> > Please note that if strict ordering of signaling before packet
> > arrival is required, then receiver side flow label allocation
> > isn't required itself for ensuring decodability just based on
> > the IPv6 header.
> 
> I ma not sure i agree here

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