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

Re: flow label demultiplexing

Hi Pekka,


El 18/04/2005, a las 8:57, Pekka Savola escribió:

Hi,

Now that the charter bashing has quieted down, some technical discussion... I've read through the drafts again, and I have some high-level comments; I'll send a couple of them this week or so.

The first is demultiplexing, especially based on Flow Label.

First, one specific comment:

An added limitation imposed by this approach is that all the
potential source and destination locators have to be known beforehand
by the receiver in order to be recognized.

==> I don't understand why this is a limitation in practice (though it may be an architectural limitation). Isn't the assumption that all the potential locators must be exchanged somehow before the network connectivity failure, otherwise the shim6 solution might not be able to switch to working locators? Otherwise the rehoming could not be secured...


Well, if you are using CGA security, you could use the new locator (as source address) without prior information to the peer. This could be useful in *some* scenarios (let's not mention the word for now :-)
CGA based security does not need prior exchange of locators, right?


....

All the approaches listed in demultiplexing based on flow label appear to have issues. It was not clear to me which approaches were really put forward and which were clearly rejected.

When looking at different alternatives, this is what I had in mind which could work up to a certain degree:

1. allocate a new flow label for all new communications immediately
2. when setting up the multihoming context, keep track of all the
potential source and destination locators
3. flow label used by the created (src,dst,flow) in 1. is reserved
so it can't be used for any communication to any destination
locator *in the set*
4. when switching to new locators, use the same flow label
5. when demuxing the packet, the demuxer knows which locators can be used
as source or destination, and use the flow label for demuxing.

This has a couple of generic issues:
 - what if the same flow label is used for some other address, and that
   address later gets added to this locator set?

   This is better than nothing; the alternative is to do flow
   label reservation ("*,*,flow"), but that results in running out of
   flow labels with a high number of flows.  Or would that be an
   acceptable tradeoff?

   If this approach would be used, it would just mean that if you had
   communicated recently to host X, and host X would soon afterwards be
   added to a locator set, you could not use shim6 to do connection
   survivability to host X.  This doesn't seem too awful a tradeoff..

 - in step 3. above, an implementation could also perform two-tiered
   reservation: first reserve the flow label for any communication,
   but when in the danger of running out, start using it also for
   those destinations that don't belong to the locator set.  This way
   this would not be an issue (albeit difficult to debug) until the
   hosts are so loaded that they're running out of the flow label
   space for their sessions.



IMHO this seems the wise to do it in this approach, i guess.

Regards, marcelo


 - demultiplexing just using the flow label (and not also source
   locators) is a non-starter, because then anyone would be able to
   inject any kind of packet to a particular data stream just by being
   able to pick the right flow label (and not having to even spoof the
   source address).  Requiring that the source address is one of the
   previously communicated locators mitigates this greatly.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings