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

Re: Flow label versus Extension header - protocol itself



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