Hi Dale,
On Sep 16, 2010, at 20:37 MDT, Dale W. Carder wrote:
> On Sep 16, 2010, at 7:03 PM, Brian E Carpenter wrote:
>>
>> This is yet another substantial rewrite following the recent
>> discussions on the list (and some off the list). Please read
>> it with new eyes - a diff from the previous version will not
>> be very helpful.
>
>
> Is there a reason that hosts/nodes couldn't set the flow
> label to a site-specific value (and likely not pseudo-random)
> especially considering that the value may/will be cleared at
> administrative boundaries?
The usual saying applies: "your network, your rules". HOWEVER, when[1]
site-specific (a.k.a.: locally-defined) flow-label escapes beyond an
administrative boundary and downstream routers (in other ASN's) are using
flow-labels as input-keys for LAG and/or ECMP load-balancing (as recommended by
this draft), then there a few potential consequences (which may not be coming
out as clearly as they should in the present -04 draft):
1) Your traffic flows through those downstream networks could result in
non-determinisitic forwarding behavior if the flow-labels that are being used
were not, as per Rule #1 in the draft, both pseudo-random AND a
consistent/persistent value per-"flow". (See Section 3 for a definition of
"flow").
2) If there is a hope, or expectation, (and, I hope there is) that flow-labels
could be used to detect & potentially mitigate third-party DDoS or MiTM attacks
at receiving hosts (or, firewalls/middleboxes), then your site-specific
flow-labels could potentially results in dropped packets or transport sessions
being reset. Obviously what should, could or will happen is still TBD since
both draft-blake and draft-gont are, IMHO, still in their 'formative' stages.
The one "saving grace," as it were, is Rule #3.1:
1. A forwarding node acting as a domain border device MAY be
configured to set the flow label value in incoming packets to
the default value of zero.
... allows downstream ASBR's, firewalls, etc. to reset the flow-label to 0 to
fix "broken" upstream networks that are leaking site-specific flow-labels.
However, that downstream ASBR, firewall, etc. would first need to detect broken
flow-labels are being used, which IMO, would be quite challenging, at best, in
order that an operator would be prompted to login and configure such a thing.
Of course, if this were just a default action on ASBR's and FW's, (always
resetting to 0), then we're no better off than where we are today.
In short, don't do it (please). :-)
> In RFC 3697, #3 Flow Labeling Requirements, it says that the
> source node can use a well defined sequence like incrementing
> values, whereas the emphasis in the draft is on pseudo-randomness.
I think Brian already answered this.
> If I've missed that discussion, I apologize.
No worries.
Thanks!
-shane
[1] Even with the best of intentions, bugs and misconfigurations (intentional
or accidental) do happen. :(
[2] Dropped packets if the LAG and/or ECMP hash algorithm is putting, say, ALL
of your flows onto a single component-link of a LAG or ECMP path causing
congestion. Or, packets could potentially get reordered if, for example, the
flow-label was inconsistent on a per-packet basis which would cause packets of
the same flow to be sprayed on different component-links of a LAG or ECMP path
with different queue depths.
> Dale
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
