Re: [v6ops] [tcpm] Flow Label Load Balancing

[Fernando Gont <[e-mail]>]

Hi, Tom,

On 29/11/20 13:25, Tom Herbert wrote:
>> Modulo the comments I've already made, I'm afraid we might be in the
>> path of making the FL unusable...
>>
> 
> Fernanda,,
> 
> I really don't understand how this makes the flow label "unusable", to
> the contrary this is a useful case with good effect and justifies the
> work in the host to set the field. In any case, it would be great if
> you could provide the draft with the normative requirements that would
> make the flow label "usable".

Have the FL identify a flow. packets RTO'ing does not imply that the 
retransmissions belong to a different flow.

FL changing for established sessions will break load-balancers. OTOH, 
one would still need to anylize what would happen if a SYN RTO-es, gets 
retransmitted, but both the original and the retransmitted SYN is delivered.



> Please include requirements for both hosts and network nodes. If there
> is going to the be a requirement that hosts MUST make a 1:1 mapping to
> a transport connection and the flow label MUST be consistent for the
> life of connection, then I would expect there to also be a requirement
> that the flow label MUST be immutable by all devices in the path-- in
> particular the requirement of RFC6437 would need to be updated: "A
> forwarding node MUST either leave a non-zero flow label value
> unchanged or change it only for compelling operational security
> reasons..."-- if hosts are not allowed to change a field they are
> primarily responsible for setting, then the network should not be
> allowed to modify it either.

I don't recall _(of the top of my head) why we ended up making the field 
mutable ("SHOULD NOT  be modified" rather than "MUST NOT.."). IIRC, it 
had to do with allowing middle-boxes to mitigate FL-based covert 
channels.  If that's the case (Brian CC'ed) then, in retrospective, that 
seems to have been a bad idea.  -- I was part of the discussion, so I 
take my share of blame. :-)



> Additionally, if the underlying design principle is that flow
> identification in a packet is immutable and persistent, then I'd like
> to see the discussion on how that rectifies with NAT where
> intermediate nodes routinely change IP addresses and transport port
> numbers without the host endpoints' knowledge-- unlike the flow label,
> port numbers are formally part of the transport connection
> identification, so changing them in flight is far more invasive and
> potentially harmful than changing the flow label (we've seen far more
> problems caused by NAT than flow label due to NAT state evictions,
> packets of a flow being re-routed to not hit the same NAT device,
> etc.).

You seem to be referring to IPv4 NAT, since IPv6 NPT does not modify the 
ports.   That said, even if IPv6 NAT did, then as long as the FL is 
consistent from the outside, that's fine. (i.e., the FL remains constant 
from both the "external realm" pov, and also from the "internal realm" pov).

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492