Hi,
On 08/03/10 23:49, Shane Amante wrote:
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.
I wrote:
Hmm ... OK, that makes sense. I don't believe in it tho.
On 08/04/10 03:48, Brian E Carpenter wrote:
You don't believe in the draft-blake proposal?
What I really meant was that I'm not a firm believer that the FL
belongs to end hosts only.
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.
My personal philosophy is that the primary function of the FL
is to tell individual flows apart, so that network behaviour
characteristics can be assigned to and guaranteed for them.
Most of all this could be achieved with DSCPs, but packet
ordering cannot be guaranteed by DSCPs alone.
I'm not against tacking other meanings on the FL, like the few
drafts just mentioned. However, I'm deeply suspicious about trying
to force too much meaning on the FL, especially if the whole
communication can fail due to a change in the FL. There are too
many security implications, both for the host and for the network.
To explain where I'm coming from with my philosophy: Internet
Exchange Points are desperate for any easy sources of entropy
for their switch matrix link aggregation. Most of the traffic
is between a handful of MAC addresses, so they need to look
deeper into the stack, but going beyond the first header just
won't be feasible in IPv6.
If IXPs can't trust the FL as an input to LAG hashes, they might
end up being forced to just forget about packet ordering and do
the best they can with round robin. And then nobody wins.
(And here's to hoping that some day we will have enough IPv6
traffic on an IXP to fill even a single LAG member circuit. O:-)
Having said all of the above, I don't want to stand in the way
of progress. I just wanted to voice my concerns.
Yours,
--
Aleksi Suhonen
Department of Communications Engineering
Tampere University of Technology
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
