Tim,
On Sep 9, 2010, at 05:05 MDT, Tim Chown wrote:
> On 9 Sep 2010, at 06:49, Mikael Abrahamsson wrote:
>>
>> In real life, ISPs consider DSCP as one thing they have the right to change
>> (along with TTL) in transit. I can imagine the flow label being considered
>> the same thing regardless of what the standard says.
>
> The interesting thing in the academic networks through Europe and I believe
> Internet2 as well is that - the last time I checked - there is agreement
> between the NRENs (national academic ISPs) to pass DSCP values unaltered
> between networks.
>
> In general in those academic networks the only rewriting that may occur is at
> site exit routers where site policy may either determine the DSCP value a
> packet is marked with, or trump the DSCP value set by a user/application.
> I believe where policing detects excess traffic of a certain DSCP value, that
> traffic is dropped rather than being remarked.
>
> There are agreed semantics for DSCP values between multiple NRENs, e.g. for
> Premium, BE and LBE, who also agree to not alter the DSCP in transit, even
> though there's nothing stopping them doing so per se.
>
> I don't see why the Flow Label should be treated differently. If
> cooperating ISPs agree to pass it unaltered, that's fine. As the spec
> stands, it's hard to see how we could say otherwise.
One counter-point worth considering. If there is a desire "raise the bar"
higher than BCP 38, in terms of preventing/minimizing off-path attacks in
IPv6[1], then IMHO it would be best to discourage ISP's from changing a
non-zero flow-label[2] of plain/vanilla (non-tunneled) IPv6 packets mid-flight
(i.e.: leave it unchanged). This would allow end-hosts/receivers, perhaps even
middleboxes (e.g.: firewalls if they wanted to keep track of that much state),
some ability to "inexpensively" sort out the good, from bad, packets as
described in [1].
Assuming that folks generally agree the above is a good (primary?) goal, the
question may then become can (or, should?) we make the flow-label compatible as
an input-key for flow-based load-balancing across LAG & ECMP paths? At least
as I understand them now, the two drafts [1] are compatible with using the
input-key for flow-based load-balancing decisions (more or less), which IMO is
a great thing: two uses for the price of one! ;-)
-shane
[1] draft-gont-6man-flowlabel-security-00 or
draft-blake-ipv6-flow-label-nonce-02
[2] I am slightly concerned about, for example, first-hop routers over-writing
a non-zero flow-label in plain/vanilla IPv6 (non-tunneled) packets, because the
sending host hasn't set one. More specifically:
a) Would routers be capable of implementing something like draft-gont or
draft-blake (in HW) or is there too much state (i.e.: ensuring that previous
flow-labels aren't re-used within a certain [time] window)?
b) Assuming that, e.g., first-hop routers couldn't implement either draft,
then they would like revert to implementing a stateless hash of various IPv6
header fields with no (?) crypto/authentication properties. If that is the
case, then it seems the "security value" of a received flow-label at a remote
host is virtually nil and we're not much better off than BCP 38 ...
-shane
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
