[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flow label versus Extension header - protocol itself
marcelo bagnulo braun wrote:
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
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.
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?
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.
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
So sender or receiver allocation becomes purely a choice about
whether to match on <source,tag> (receiver) or <source,dest,tag>
Does the signalling have to say which destination locators a
host will communicate to in the receiver case?
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 <src,dest,label>
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
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).