[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ó:
----- Original Message -----
From: marcelo bagnulo braun <firstname.lastname@example.org>
Date: Thursday, May 5, 2005 7:06 pm
Subject: Re: Flow label versus Extension header - protocol itself
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...
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
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
mappings. I wasn't recommending use of IKE/AH for that because people
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
as our already defined extension header. SPI's are already sender
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-
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
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
but I know the label", but for a previously known valid
mapping, you shouldn't need to signal that the packets are about to
arrive like MIPv6 does now.
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