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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Mar 2012 12:24:10 +1300

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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 13 Mar 2012 22:24:18 -0300

Hi, Brian,

Thanks so much for your review! Please find my comments inline...

> to the description in Appendix A of RFC 2460, which is obsolete (and see

Agreed. -- I will fix this in the next rev.

> exist. 

Well, any implementation that existed before the recent RFC3697 update
were most likely RFC3696-compliant...

> More seriously, this section mixes up issues that derive

Well, if it was not obsoleted, it was still valid.

> there any evidence that the rules quoted from Appendix A were ever

You mean that of validating that all packets have the same extension
headers?

> and we don't want to repeat it, do we?

I certainly wouldn't want to repeat such discussion.SHould I keep the
first sentence of the above paragraph, and then provide a pointer to
Section 6.1 of RFC 6437?

(I should note, though, that if we wanted the FL to "MUST NOT be changed
en route", it should at the very least be covered by a checksum... which
is not)

> a violation of RFC 6437, fortunately.

I don't follow how this would be a violation of Appendix A of RFC 2460....

> this security analysis, compared to the analysis included in RFC 6437.

It's the specification we had for more than ten years, which might be
implemented and deployed?

> recommending a specific algorithm.

I've no objections to that. I can remove the "RECOMMNEDED" (etc)
language if deemed appropriate....

> expect routers that are setting the flow label to use a stateful method.

I don't follow. Are you referring to the fact that the host should
"record" the selected random number, or to something else?

> shows up in a typical C library may not be good enough.

Agreed ("random()" wasn't mean to be C's random() function) -- I should
propbably add a reference to the "random numbers" RFC here...

> That concern is pretty much irrelevant unless you have a very bad PRNG.

There's also the concern of processing cycles, which I didn't mention,
but should.

> some probability of success. 

I'd argue that RFC 6437 is underspecified. Certainly, the ability of an
attacker guessing the next number depends on what he's able to see. For
off-path attackers, it is virtually equally difficult to guess the next
FL produced by this algorithm, as it is to guess the next FL that would
be produced by "random()".

If you now argue "but if the attacker sees the previous FL...", I could
answer "if the attacker sees the state variables of the PRNG
implementation/instance you're using, he'd be able to guess the FL,
too". RFC 6437 is underspecified as to what we can expect the attacker
to see, and what's the threat model we have in mind.

Me, I think that we should be concerned about off-path attackers, but
shouldn't care about on-path attackers: if they are on path, game over
(they *see* the FLs... and also would probably launch other -- much more
devastating -- attacks).

> It also works against the goal of a uniform

How come that a counter could have a non-uniform distribution?? ---
actually, I'd argue that most PRNGs won't give you such a uniform
distribution!

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492