Subject: Re: I-D Action: draft-gont-6man-flowlabel-security-02.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2012 14:18:23 +1300

Hi,

I really don't like the use of the counter in Fernando's proposed algorithm:

 Flow Label = counter + F(Source Address, Destination Address, Secret Key)

It seems to me that it introduces significant predictability for a malicious
observer of the packets leaving a given source.

Effectively the equivalent algorithm in RFC 6437 is

 Flow Label = F(Srce Addr, Dest Addr, Protocol #, Srce Port, Dest Port, Secret Key)

which is less predictable, even if the port number is not randomized.

I'll have more to say once a current investigation of algorithms by
a student is finished.

Regards
   Brian Carpenter

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 Jan 2012 23:49:28 -0300

Hi, Brian,

> observer of the packets leaving a given source.

As noted off-list, I personally think that rather than proposing a
single algorithm, we should describe a set of algorithms, a la RFC 6056
-- as there a number of tradeoffs-

> which is less predictable, even if the port number is not randomized.

If the attacker can predict the algorithm in
draft-gont-6man-flowlabel-security-02.txt, he knows the IPv6 addresses
of the two endpoints, and the secret key. So I don't see what'd be the
real improvement of this variant.

That said, it also seems technically incorrect: If you expect the
resulting (src ip, dst ip, flow label) to be unique, then introducing
the port numbers in F() could lead to unnecessary collisions.

Yes, now that the requirement of uniqueness has been relaxed, collisions
are less important... but I don't see what's the "gain" of the modified
expression you suggest above.

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2012 16:04:35 +1300

> real improvement of this variant.

With your proposal, after observing label N, you can (with reasonable probability)
predict label N+1; you don't need this to be 100% accurate to cause trouble.

> the port numbers in F() could lead to unnecessary collisions.

Sure, as noted in the new RFC: a statistically small rate of collisions
does not significantly bias load sharing.

> expression you suggest above.

That label 4502 will essentially never be followed by label 4503,
which your method explictly allows (your Table 1). Include the counter in
the input to the hash function and this problem disappears.

Regards
     Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 24 Jan 2012 01:17:08 -0300

> predict label N+1; you don't need this to be 100% accurate to cause trouble.

If the attacker can *observe* labels, why would he bother to "guess" them?

> the input to the hash function and this problem disappears.

Well, one should clearly state the threat model:
If you're thinking about off-path attackers, then the fact that flow
labels corresponding to the same set (src IP, dst IP) will be
incremental is irrelevant (the attacker knows that the Flow-IDs are a
monotonically-increasing sequence, but does not know where that sequence
is).

If the threat model is that we're concerned about on-path attacker,
then: game over: the attacker will always know the FlowLabel values,
regardless of the algorithm that we use.

That said, and as noted above, it is interesting to offer alternatives.
For example, if you implement the hash-based approach described in my
I-D, the first flow label is "expensive", but the rest are really cheap:
e.g., just add the counter to the value of F() that you have recorded in
the destinations cache. OTOH, randomizing every FlowLabel might be more
expensive.

I personally think that rather than enforcing a single algorithm, we
should offer a set of possible algorithms, and discuss the tradeoffs --
after all, not all implementations need to agree on the same algorithm.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2012 09:18:37 +1300

> If the attacker can *observe* labels, why would he bother to "guess" them?

So that s/he can generate plausible bogons as part of a DOS attack. It seems
to me that predictability of the flow label is similar to predictability
of port numbers in that respect.

> monotonically-increasing sequence, but does not know where that sequence

If you are trying to confuse a load balancing algorithm, being able to
predict the next new SYN packet, even only with partial success,
might be a useful thing. Since all major content providers run load
balancers, attacks on load balancing algorithms are an important
concern. If you can bias a load balancer to (almost) always pick
the same server, the content provider will not be happy.

(Note: I am not suggesting that existing load balancers are open
to such an attack, but we don't want the flow label to make things
worse.)

> regardless of the algorithm that we use.

Indeed.

> the destinations cache. OTOH, randomizing every FlowLabel might be more

That depends on how much extra you pay for holding state in the destinations
cache. A stateless algorithm avoids that.

> after all, not all implementations need to agree on the same algorithm.

Absolutely; that's why RFC 6437 does not specify an algorithm.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Tue, 24 Jan 2012 18:02:28 -0300

Hi, Brian,

> of port numbers in that respect.

Let me rephrase with two questions:

a) If an attacker is off-path, how can he "attack" the algorithm
proposed in "draft-gont-6man-flowlabel-security-02.txt"?

b) If an attacker is on-path how does any algorithm prevent the attacker
from *knowing* which FlowLabels he should forge?

> might be a useful thing. 

How could you possible predict, being an off-path attacker, the next
FlowLabel?

> Since all major content providers run load

My understanding is that FlowLabels are expected to be used as I-Ds for
flows, and have no internal semantics. -- it's not that forging a
specific value will make packets always go through the same set of routers.

> to such an attack, but we don't want the flow label to make things

How worse would the approach in
"draft-gont-6man-flowlabel-security-02.txt" for FlowLabels when e.g.
Linux uses the same approach for port numbers?

> cache. A stateless algorithm avoids that.

The destinations cache is already there. So a few bytes per entry does
not seem to be a big deal. -- and if it is, then you'd probably be
concerned about having the Destinations Cache in the first place....

> Absolutely; that's why RFC 6437 does not specify an algorithm.

I'm fine with not describing any algorithms in the base expect. But I do
think that something along the lines of RFC 6056 is needed -- everytime
something like that was misswing, people got it wrong. Thing about IP
ID, TCP port numbers, etc., etc.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2012 15:39:53 +1300

> proposed in "draft-gont-6man-flowlabel-security-02.txt"?

OK, I mean an attacker who is able to observe the traffic but not
perform MITM modifications. Some people call that off-path...

> from *knowing* which FlowLabels he should forge?

Obviously for an established flow, you can inject forged packets that
appear to belong to that flow; we can never prevent this. But if you
can predict the flow label for *future* flows, you can forge and
inject SYN packets before the real user ever starts the flow. Since
a large part of today's forged traffic seems to consist of SYN packets,
this seems like a sensitive target.

> How could you possible predict, being an off-path attacker, the next

Yes, you must be able to passively observe the previous traffic.

> specific value will make packets always go through the same set of routers.

If the label is used in a load balancer, it *might* do exactly that.
It isn't certain (see draft-carpenter-v6ops-label-balance-01.txt).

> Linux uses the same approach for port numbers?

I thought we were trying to randomise port numbers for exactly
that reason; it seems to me that any form of regularity in the
numbers is asking for trouble, even if we don't have an exact
attack model.

> concerned about having the Destinations Cache in the first place....

It's an engineering trade-off, certainly. My taste is always to avoid
extra state, however.

> ID, TCP port numbers, etc., etc.

Yes, but maybe we need a little experience first. That's why I have a
student playing with the largest IPv6 traces we've managed to get hold
of.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Jan 2012 07:18:41 -0300

> perform MITM modifications. Some people call that off-path...

Well, the attacker *is* on the path if he can observe traffic.

That said, if the attacker is able to observe traffic, then game over.
Whether we use random FlowLabels or predictable FlowLabels is the same:
the attacker is not going to waste his time "guessing" when he can learn
the labels by listening to traffic.

> this seems like a sensitive target.

Since FlowLabels do not carry any specific semantics, I cannot see how
"forge and inject before..." would be any worse than firing those
packets once the flow has already been established.

That aside, as noted above, the attacker could only predict flowlabels
if he is on-path. And if the attacker is on-path, game over.

> numbers is asking for trouble, even if we don't have an exact

As noted in the port randomization RFC, the goal is that an off-path
attacker can not predict values. In particular, if we start imposing
requirements such as "we must minimize the probability of FL reuse",
etc., then that's certainly asking against randomness at the same time.

In the case of port randomization, the port selection algorithm has two
goals:

* selecting port numbers such that they are not predictable by an
off-path attacker
* minimizing the port reuse frequency.

As a result, a hash based approach can tackles the two of them.

An anecdote:
While working on the port randomization stuff, a guy from vendor X
argued that he'd not implement the hash-based algorithm because one of
his customers was running a small app to measure the "randomization
quality" of their port selection algorithm.

-- Clearly, they were missing the point (and we noted that at the time):
what we wanted was the port numbers to be difficult to guess by
*off-path* attackers. If the attacker was on the other endpoint of the
connection, he could always see the packets, and could always perform
any attack that he wanted.

> It's an engineering trade-off, certainly. My taste is always to avoid

Four bytes per IP address (*not* per TCP connection or the like) doesn't
seem like a big deal. -- You're going to hit many other problems before
those four extra bytes become a problem.

That said, I'm generally in favour of offering choices, discussing the
trade-offs, and let people pick the option that they like most.

> student playing with the largest IPv6 traces we've managed to get hold

Experimental data is always good. However, regardless of what the
results of this experiment are, let's just say that with the current
levels of v6 deployment, it's hard to tell whether those results will
still hold in, say, two years, or whatever.

Different systems use different address types, addresses selection
algorithms, etc., that are likely to evolve over time (not to mention
the traffic patterns).

So I'm more of the idea that the aforementioned experiment could help to
identify algorithms that suck, but not really prove that this or that
algorithm is (or will be) best (assuming that there's such a thing --
which I don't think it's the case... there are just different options,
with different trade-offs).

Thanks,

---

From: Brian Haberman <[email-masked]>
Date: Wed, 25 Jan 2012 08:43:47 -0500

Fernando,

> the labels by listening to traffic.

I think you and Brian C. are not talking about the same issue.  Brian C.
is talking about being able to see current flow labels and then being
able to guess future flow labels.  That is, the attacker has the ability
to forge traffic for a future exchange.  You seem to be focused on the
observation of a current flow and the attacker being able to inject
traffic into that flow.

> packets once the flow has already been established.

Injection of state into the endpoints may influence a large number of
functions, so an attacker's ability to forge packets may allow it to
skew the behavior of one of the nodes.

> if he is on-path. And if the attacker is on-path, game over.

I don't think that is completely true.  If the attacker cannot guess the
future flow label correctly, its attempts may be detected.

Regards,
Brian H.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 25 Jan 2012 11:07:49 -0300

> observation of a current flow and the attacker being able to inject

Agreed. The point I'm trying to make is that I do not see what the
attacker would gain from guessing a label that's not in use yet. For
instance, if he were to send packets with that forged label, the spoofed
traffic might not event "compete" with any existing traffic.

> skew the behavior of one of the nodes.

Not sure what you mean....

> future flow label correctly, its attempts may be detected.

How? And more importantly, why would an attacker want to forge a future
label that is not in use?

Let's keep in mind that if the attacker is on-path, that of attacking
the flow label is probably the last DoS variant an attacker could try
(no amplification, etc.)

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Jan 2012 09:08:46 +1300

> traffic might not event "compete" with any existing traffic.

One case that I'm thinking of specifically is if the attacker also knows
the load balancing algorithm in use, and in particular how it interacts
with the flow label, then there might be a way to bias the load balancing
and orchestrate a DOS SYN attack on a particular server. All I'm saying is
that *any* kind of predictability of future flows is a weakness that we
should avoid.

> Not sure what you mean....

Load balancing is an example. I think you'd be courageous to assert
that the bad guys won't find another.

> the flow label is probably the last DoS variant an attacker could try

They will try anything that works, in the end. I think it's very cheap
to avoid this risk - in your notation, it means

is changed to

 Flow Label = F(Source Address, Destination Address, Secret Key, counter)

That means that the regularity introduced by the counter is hidden by
the hash function.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 26 Jan 2012 07:54:12 -0300

Hi, Brian,

On 01/25/2012 05:08 PM, Brian E Carpenter wrote:
> the load balancing algorithm in use,

One should expect the attacker to know the load-balancing algorithm, but
not the parameters with which it operates.

If the attacker knows all of these things (algorithm+parameters), then
*that* is where the flaw is (assuming having the attacker play with
load-balancing is a concern, of course).

> and in particular how it interacts
> and orchestrate a DOS SYN attack on a particular server. 

Not sure what you mean. Are you arguing that in this case the flow-label
would be used for *server* load-balancing?

> All I'm saying is

I'm generally of the idea that "random is your friend" (wherever possible).

That said, I'm also arguing that when analyzing the security properties
of something, the threat model should be clearly defined.

For yet another example, draft-gont-predictable-fragment-id. My original
proposal was to simply randomize the Fragment Identification. But
concerns with collisions of Fragment IDs led to alternative approaches
(although I personally think that that doesn't mean that simple Fragment
ID randomization should be ruled out).

> that the bad guys won't find another.

I just have not seen any example in which an algorithm such as the one
in "draft-gont-6man-flowlabel-security-02" would allow an attacker to do
something that he cannot do with randomized (as in rand()) FlowLabels.

And I'm just saying that if the attacker is on-path, what algorithm you
use is mostly irrelevant.

> They will try anything that works, 

Again: Is there any benefit an attacker would get from knowing what FLs
might be used in the future?

For instance, if the FLs are not in use, it doesn't seem to make sense
for an attacker to start firing packets with such labels, as those
packet would not compete with the "real ones". And if the attacker is
on-path, then he'll play lazy, and would simply learn the labels from
the wire.

> in the end. I think it's very cheap

This also means that the algorithm is now broken. The goal of F() is to
produce a constant value for each set (src IP, dst IP), which cannot be
easily guessable by an off-path attacker (F() introduces the
randomization). Then counter is incremented for each new label, such
that for each set (src IP, dst IP) you get monotonically-increasing flow
bales, such that the FL reuse frequency is minimized (please see the
sampl output in the I-D).

If you introduce "counter" within F(), it's like changing the secret key
for every flow label, at which point the result of F() is probably not
better than than of "rand()".

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jan 2012 16:55:58 +1300

Fernando,

> would be used for *server* load-balancing?

Yes (draft-carpenter-v6ops-label-balance) but there could be a similar
argument for ECMP or LAG, where "the worst an attacker
could do against ECMP or LAG is attempt to selectively overload a
particular path." [RFC6438]

> of something, the threat model should be clearly defined.

I think it's fairly clear: the attacker reverse-engineers a load balancer
and figures out how to make it send too many flows in the same direction,
thereby saturating a target.
> use is mostly irrelevant.

Unless you know all the load balancing algorithms in present and future use,
I don't see how you can assert that.
> on-path, then he'll play lazy, and would simply learn the labels from

Again: I don't know, and you don't know, what use future load balancers
might make of flow label values. I do know that if the sequence of flow
labels is even partly predictable, the behaviour of load balancers *might*
become partly predictable.

> sampl output in the I-D).

But you greatly increase predictability as a result. I don't understand
how that can possibly be a good thing.

> better than than of "rand()".

That depends entirely on the quality of F(); as I've already said, I hope
to have some results for various algorithms and some large IPv6 packet
traces quite soon, but I already know that FNV1a gives very good results.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Mon, 30 Jan 2012 02:24:47 -0300

> particular path." [RFC6438]

Again: If using a specific value has any semantics other than just
"identifying a flow", *that* is where the vulnerability is being introduced.

> thereby saturating a target.

Well, that's a security-unwise approach. If you're concerned about that
possible attack, use some local secret such that, even if the attacker
knows the algorithm and the FL, he cannot really control the load
sharing at his own will.

> I don't see how you can assert that.

It's the intended semantics for the FL and threat model that matters,
rather than the algorithm.

If the attacker is on-path, he can always learn the FLs in use, and
forge packets with that FL such that his packets are sent on the same
link as the legitimate packets (e.g. overloading the link) -- and you
cannot do anything about that (other than preventing the attacker from
snooping the packets, or forging the attack packets).

The other possible threat is that of an attacker being able to send his
packets on any particular link, at his own will. In that case, you
should assume the attacker knows your algorithm, and that he can also
pick the FLs he'll use. Therefore, it is the algorithm itself that must
prevent the attacker from being able to do that (e.g., employ a secret).

As noted, I'm not arguing that randomizing the FL is a bad thing. I'm
just arguing that the rationale for claiming that simple randomization
is better than other possible approaches is flawed.

> Again: I don't know, and you don't know, 

According to my analysis, there isn't. -- So if you want to declare a
"winner" among algorithms (particularly when there *are* tradeoffs)
based, then you should be able to answer that question.

> what use future load balancers might make of flow label values. 

We'll we should be providing guidance on how we expect the FL to be
used, shouldn't we?

> I do know that if the sequence of flow

That is true only if the load balancer implementation is flawed.

> how that can possibly be a good thing.

I don't understand the basis on which you flag things as "good" or "bad".

If you can come up with a scenario in which *on-path* predictability
makes possible attacks that simple randomization doesn't, then I would
buy your argument. But so far it looks more like religion than anything
else.

> That depends entirely on the quality of F(); as I've already said,

Not sure what you mean. If F() has the properties described in
draft-gont-6man-flowlabel-security-02, the adding the counter as you
described breaks the algorithm.

Thanks,