draft-gont-6man-flowlabel-security-03

[Brian E Carpenter <[e-mail]>]

Here are my comments on this draft.

> 1.  Introduction
> 
>    The flow label is a 20-bit field that allows a source to label
>    sequences of packets for which it requests special handling by IPv6
>    routers (e.g., non-default quality of service).  

I think the clause starting "for which" should be deleted. It really refers
to the description in Appendix A of RFC 2460, which is obsolete (and see
further comments below).

>  2.   Vulnerability analysis
> 
>  2.1.   RFC3697-compliant implementations

Are there any of those? I've seen very little evidence that they
exist. More seriously, this section mixes up issues that derive
from Appendix A of RFC 2460 with issues that derive from RFC 3697.
RFC 2460 says this about the flow label:

>>    This aspect of IPv6 is, at the time of
>>    writing, still experimental and subject to change as the requirements
>>    for flow support in the Internet become clearer.  Hosts or routers
>>    that do not support the functions of the Flow Label field are
>>    required to set the field to zero when originating a packet, pass the
>>    field on unchanged when forwarding a packet, and ignore the field
>>    when receiving a packet.
>> 
>>    Appendix A describes the current intended semantics and usage of the
>>    Flow Label field.

This makes it clear (to me, at least) that Appendix A was not normative;
it had experimental status. It was a mistake that RFC 3697 did not
obsolete Appendix A.

That doesn't invalidate the security analysis of Appendix A, but is
there any evidence that the rules quoted from Appendix A were ever
implemented?

> 2.1.1.   DoS resulting from verification of Flow Label consistency

This section is entirely based on Appendix A rules, not RFC 3697.

...
>    Therefore, while this verification might be of help to mitigate some
>    blind attacks by obfuscation, we believe the drawbacks of performing
>    such verification outweigh the potential benefits, and thus recommend
>    systems to not perform such verification.

Agreed - that is one of the reasons that RFC 6437 obsoleted Appendix A.

> 2.1.2.  Covert channels
> 
>    As virtually every protocol header field, the Flow Label could be
>    used to implement a covert channel.  In those network environments in
>    which the Flow Label is not used, middle-boxes such as packet
>    scrubbers could eliminate this covert channel by resetting the Flow
>    Label with zero...

Since the flow label is supposed to be sent end-to-end, in all three
models (RFC 2460, RFC 3697, RFC 6437), middleboxes must not do this.
The possible exception case is explained carefully in Section 6.1 of
RFC 6437. That text was the result of a tremendous discussion in 6man,
and we don't want to repeat it, do we?

> 2.1.4.  Information Leaking
> 
>    If a host selects the Flow Label values of outgoing packets such that
>    the resulting sequence of Flow Label values is predictable, this
>    could result in an information leakage.  Specifically, if a host sets
>    the Flow Label value of outgoing packets from a system-wide counter,
>    the number of "outgoing flows" would be leaked.  

That behaviour would be an explicit violation of Appendix A of RFC 2460,
but unfortunately it was explicitly allowed by RFC 3697.  It is again
a violation of RFC 6437, fortunately.

In general: given that RFC 2460 Appendix A and RFC 3697 are both
obsolete and probably unimplemented, I am not sure what we gain from
this security analysis, compared to the analysis included in RFC 6437.

> 3.1.  Recommended algorithm

>From my experiences testing out some algorithms, I am convinced that we
should not recommend an algorithm, but simply leave implementors of
RFC 6437 to make their choices. Of course there is no harm in publishing
suggested algorithms, as we've done in the tech report I announced
recently. But I really think there's nothing to gain by formally
recommending a specific algorithm.

That said,

>    ...we RECOMMEND that the Flow
>    Label of each flo be selected acording to a PRNG.  That is, each Flow
>    Label would be selected with:
> 
>                            Flow Label = random()

It should be made clear that this is a stateful algorithm for use in the
source host, which has to keep some state for each flow anyway. We don't
expect routers that are setting the flow label to use a stateful method.

>    where:
> 
>    random():
>       Is a a Pseudo-Random Number Generator (PRNG).

It needs to be a PRNG with good properties - whatever random function
shows up in a typical C library may not be good enough.

> 3.2.  Alternative Algorithm
> 
>    Implemenatations concerned with the Flow Label reuse frequency of the
>    algorithm specified in Section 3.1 MAY use the following alternative
>    scheme, which aims at minimizing the Flow Label reuse frequency by
>    producing per-destination monotonically-increasing Flow Label values.

That concern is pretty much irrelevant unless you have a very bad PRNG.
In a space of one million values, reuse (by a given source) is rare,
and doesn't matter as far as load balancing goes (as discussed on the
thread for draft-carpenter-v6ops-label-balance).

Also, I believe that this approach conflicts with RFC 6437:

>>    ...If a hash
>>    algorithm is used, as suggested in Section 3, it SHOULD include a
>>    step that makes the flow label value significantly difficult to
>>    predict [RFC4086], even with knowledge of the algorithm being used.

The monotonic increase allows observers to predict future values with
some probability of success. It also works against the goal of a uniform
distribution of values, which wanted for load balancing anyway.

    Brian