On 21 Jun 2011, at 10:13 , Jari Arkko wrote:
> I think you are making it easier than it really is.
>
> Here's the problem.
> The first packet arrives and its small. The router can read the 5-tuple.
> All fine so far. Picking
>
> flowid = f(5-tuple)
>
> The next packet arrives, only this time it is fragmented.
> The router cannot read the 5-tuple from all fragments. Now,
> what is the router supposed to do? Here are its options:
>
> 1. Reassemble to find the 5-tuple information. All is fine,
> except that its a heavy implementation burden (and a DoS vulnerability).
A router that I built would not try to reassemble transit traffic.
> 2. Revert to using 2-tuple for the fragmented packet:
>
> flowid' = f(2-tuple)
>
> Now flowid != flowid' This is really bad, as it means that
> a normal packet and a fragmented packet for the same flow
> would have different flowids, and might take different routes,
> be re-ordered, etc.
We agree it is undesirable, but I would not write "really bad".
I think we differ on whether it is practical to avoid having
different Flow Label values for fragmented vs non-fragmented
packets of a given flow *in the particular case* where the
originating node sent the packet with zeros in the Flow Label
field.
In the approach I outlined, for some given flow where the
originating node did not set a Flow Label value, the
non-fragmented packets all will have some Flow Label value A,
while fragmented packets all will have some Flow Label value B.
With high probability, (A != B). Still, this outcome is not
obviously worse than having all of those packets with a Flow Label
value of zero.
We might also disagree on how common fragmented IPv6 packets are
in the deployed world, I'm not sure. In my experience they are
uncommon in the deployed world. I gather they are very common
in the small niche of supercomputing, but in that special case
the number of fragmented packets will dwarf the number of
non-fragmented packets. This results in the vast majority of
packets within the flow having the same Flow Label value.
Separately, packet re-ordering can (and routinely does) happen
in the deployed world already, regardless of contents of the
Flow Label field. So receiving nodes already have to be able
to cope with reordered packets.
Also, modern TCP implementations cope MUCH better with re-ordered
packets than older TCP implementations. So the performance hit of
a re-ordered packet is not nearly as drastic as it was (for example)
15 years ago.
> 3. Do some magic matching of fragment identifiers. Again, we can find
> the 5-tuple, but now the router has to remember per-session state
> (another DoS vulnerability).
(A) A router I built would not be trying to keep that per-session state.
(B) Literally every step in packet handling is a potential DOS
vulnerability. It is not possible to avoid DOS vulnerabilities
in useful packet networks. So one ought to be claiming that
the DOS vulnerability is lower-cost for the attacker than
existing DoS vulnerabilities and also expensive for the victim.
[While I do believe those 2 properties hold in this case, it is
crucial to examine/discuss those 2 properties for any claim of
any DoS vulnerability in a packet network. If we try to evaluate
"DOS vulnerability" on a binary basis, we are unlikely to make
scientifically sound decisions.]
There is a 4th implementation option, which is to use only fields
in the base IPv6 header for all cases where a router adds a Flow Label.
That implementation option adds little or no value for load-balancing
as compared with a zero Flow Label, because existing load-balancing
algorithms in the deployed world already tend to use the variable
fields of the IPv6 header (e.g. source IPv6 address, destination IPv6
address, maybe ToS byte) for deployed load-balancing situations.
For non-fragmented packets, the deployed world already tends to use
the 5 input values that these I-Ds discuss, by the way.
Part of my point in mentioning that hardware forwarding engines
(i.e. ASIC, FPGA) are already commonplace, even in very low cost devices,
was to point out that such forwarding engines can look at any combination
of any fields in any IP header (and often also in the TCP/UDP/SCTP/ICMP
headers), with no incremental performance cost, at wire-speed. In
at least one IPv6 capable forwarding ASIC implementation that I'm
very familiar with, this flexibility did not significantly increase
the gate count and did not increase the die size. Folks who worked
on a different widely deployed IPv6 capable forwarding ASIC have told
me that these properties were also true in their silicon.
IMHO, the vast majority of the benefit to using the IPv6 Flow Label
for load-balancing accrues to those IPv6 packets that have been
fragmented where the originating node inserts the non-zero Flow Label
value based on the documented 5 input parameters.
In the other cases, the 5 values either already can be read
spontaneously at wire speed by commonly used merchant silicon
forwarding engines (e.g. for non-fragmented packets) OR the
after-the-fact inserted Flow Label performs no better than using
base IPv6 header fields that can be read spontaneously at wire speed
(for fragmented packets).
By having routers use the usual 5 inputs to generate a non-zero
Flow Label for all non-fragmented packets that arrive with zero value
Flow Labels, the common case of a non-fragmented IPv6 packet is
handled a bit better and the less common case of a fragmented IPv6
packet is not really worse off. After all, a router can't know
from examination of packet N of flow X whether some future packet
N + Delta in the same flow X will or won't contain a Fragment
Header.
IMHO, Yours,
Ran
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
