[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header - protocol itself


El 06/05/2005, a las 2:47, Greg Daley escribió:

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.


agree

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

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 ;)


ok

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.


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?


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.


agree

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

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.


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

regards, marcelo


Greg