Aleksi,

On 2010-08-04 14:12, Aleksi Suhonen wrote:
> Changed subject to better reflect content.
> 
> Today I wrote:
>>> Why does a receiving host care about the flow label at all? It
>>> exists  to make sure that all intermediate nodes give correct
>>> treatment to theflow, but once it reaches its destination it's
>>> "safe", right?
> 
> On 08/03/10 23:49, Shane Amante wrote:
>> It depends on your worldview. I think Brian Carpenter (?) may have
>> said it best in a private e-mail -- let me paraphrase (and, Brian,
>> please correct me if I'm wrong). The flow-label can belong either to the
>> network -or- to the host(s): pick one[1].

In terms of who sets it, that is the simplest way to state our main
choice, I believe.

> 
> {snip}
> 
>> OTOH, if you believe the flow-label belongs to hosts and you
>> potentially want to enable applications like
>> draft-blake-ipv6-flow-label-nonce-02, which could prevent off-path
>> attacks, then you (likely) can't have routers messing around with the
>> flow-label. Routers may read a flow-label, but they can't attempt to
>> change it.
> 
> Hmm ... OK, that makes sense. I don't believe in it tho.

You don't believe in the draft-blake proposal?

Another usage is when the destination host is actually a multithreaded
server, which chooses to do internal load balancing based on the flow
label. That raises some very interesting MITM attacks, by swapping
labels between two flows directed to the same server.

> "0 FL mutable" would work reasonably well with both world views,
> as there's one chance in a million that rnd() would yield zero.
> One connection in a million would fail, and cause a retry?

Our draft already says:

       The RECOMMENDED scheme is that, whether set by the source host
       according to RFC 3697, or by an FL router according to the rules
       below, the label contains a pseudo-random value between 1 and
       0xFFFFF.

We are not very far from your proposal or that of Rémi, but the real
question is whether there is consensus for this sort of change,
or simply for a tidied up and clarified RFC3697bis.

   Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to