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

[Fernando Gont <[e-mail]>]

Hi, Brian,

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


On 03/13/2012 08:24 PM, Brian E Carpenter wrote:
>> 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).

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



>>  2.   Vulnerability analysis
>>
>>  2.1.   RFC3697-compliant implementations
> 
> Are there any of those? I've seen very little evidence that they
> 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
> 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.

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



> 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?

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



>> 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?

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)



>> 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.

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



> 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.

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



>> 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.

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



> 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.

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



>>    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.

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



>> 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.

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


> 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. 

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
> distribution of values, which wanted for load balancing anyway.

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492