Subject: Re: [tcpm] Some comments on: draft-kuehlewind-tcpm-accecn-reqs

From: Bob Briscoe <[email-masked]>
Date: Thu, 3 Jul 2014 14:10:34 +0100

Gorry,

I wanted to respond to your dislike of our argument against the nonce 
and a couple of other points... (sorry I didn't notice your email 
back in March).

We don't need to have this argument in the accecn-reqs doc, so we've 
taken it out. But we do need to have the argument on the list. inline...

At 11:47 08/03/2014, Gorry Fairhurst wrote:
>Section 2:
>
>Disagree with text: "However, as the ECN Nonce is a separate 
>extension to ECN, even if a sender tries to protect itself with the 
>ECN Nonce, any receiver wishing to conceal marked packets only has 
>to pretend not to support the ECN Nonce and simply does not provide 
>any nonce sum feedback."
>- To me this argument is ridiculous (and I have said so), and I 
>think we should not perpetuate this argument!
>[[Here is why:  if a sender were to require a NS, then a receiver 
>would need to provide that or expect the sender would not continue 
>use of ECN, or at least limit is trust of ECN.  So the wording could 
>be improved, but RFC3540 says:  "If the receiver has never sent a 
>non-zero nonce sum, the sender can infer that the receiver does not 
>understand the nonce, and rate limit the connection, place it in a 
>lower-priority queue, or cease setting ECT in outgoing segments."]]
>- Saying the nonce sum has a second problem in that it only works if 
>it is deployed and actually used seems obvious.

I believe our argument is correct.

1) First, let's allow an assumption that the nonce is only for 
protection against ECN cheating (it isn't)...

One person saying they don't support the nonce is not a suspicious 
sign of potential malice when a majority of users don't support it 
either, or even a minority.

Here's a scenario: I'll be generous and assume that nonce support has 
been deployed unilaterally by one (or two) large mobile device 
vendors. Then imagine that you are running a Web server. Millions of 
clients ask you for ECN TCP connections. You support ECN because you 
have determined that it improves performance. You also want to get 
the client to use the nonce if supported, so you set the flags 
accordingly. The client responds with ECN support, but nonce sum =0.

By your argument you (the server) decline to use ECN further or you 
negate the performance benefits. Certainly you want to decline ECN 
for the one or two malicious users who use the device from the above 
vendor(s) but have hacked it to say it doesn't support the nonce. 
However, you also cannot help but decline to use ECN (or negate any 
performance benefits) for the millions of users who don't use those 
devices that support it. Are you really likely to have gone to all 
the hassle of deploying ECN then you decline to use it or you limit 
performance for 99.999% of users because the other 0.001% might be 
malicious? No.

The whole point of the nonce is to identify precisely which users are 
cheating. If you still have to use judgement and heuristics anyway, 
the nonce is not a solution.

2) Now, let's assume you are having trouble with clients mounting one 
of the attacks described in RFC3540 that supresses loss feedback (not ECN).

Any client that wants to mount these attacks just doesn't ask for ECN 
support. What are you going to do as a server. Reset every connection 
that doesn't ask for ECN? Again, you would have to punish large 
numbers of your customers in case a few might be cheating.

It's not helpful to say this argument is ridiculous. If I'm missing 
something, please describe a believable scenario where the nonce 
would be useful.

>It speaks of [...] Conex (specified for a specific domain).

I need to correct this misconception: ConEx is an e2e mechanism added 
to IP using transport feedback of loss or ECN where available. ConEx 
policing would certainly be applied in individual network domains, 
but the ConEx signal is e2e and defined in updates to e2e transport 
specs (starting with TCP).

>Section 4:
>
>Usage of RFC 2119: Personally, I really do not like use of RFC2119 
>keywords in this way: "This leads to the following requirements, 
>which MUST be discussed for any proposed more accurate ECN feedback 
>scheme:" - Mandating discussion is not helpful.
>
>(point 2 above): If we have requirements as the title suggests, then 
>I personally would encourage you to list them as requirements using 
>RFC 2119 language - but I don't mind seeing no RFC 2119 keywords if 
>the WG wants this, as long as I can see the relative importance of 
>each topic. At the moment I can't see this.

I recall that relative priority of requirements was already discussed 
in tcpm, and the general opinion (I think) was that this would be 
hard to do in abstract terms without a particular mechanism in mind 
that makes particular trade-offs. I strongly support that view - 
otherwise we will be having circular arguments for ever.

I also think mandating discussion is helpful. accecn-reqs is a 
checklist of things that need to be aired in any candidate spec. 
What's wrong with that?

Bob

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 11 Jul 2014 08:32:23 +0100

Sorry for the long delay in response, please see below comments as an 
individual:

On 03/07/2014 14:10, Bob Briscoe wrote:
> and a couple of other points... (sorry I didn't notice your email back
> in March).
>
I saw this.

>> Disagree with text: "However, as the ECN Nonce is a separate extension
>> to ECN, even if a sender tries to protect itself with the ECN Nonce,
>> any receiver wishing to conceal marked packets only has to pretend not
>> to support the ECN Nonce and simply does not provide any nonce sum
>> feedback."
>> - To me this argument is ridiculous (and I have said so), and I think
>> we should not perpetuate this argument!
>> would need to provide that or expect the sender would not continue use
>> of ECN, or at least limit is trust of ECN.  So the wording could be
>> improved, but RFC3540 says:  "If the receiver has never sent a
> One person saying they don't support the nonce is not a suspicious sign
> of potential malice when a majority of users don't support it either, or
> even a minority.
>
This is a deployment problem, not a protocol problem. If a sender 
accepts ECN feedback from a receiver that isn't NS capable, then it can 
not take advantage of the NS. You could be more conservative if you knew 
the NS was not implemented, or something else.

> been deployed unilaterally by one (or two) large mobile device vendors.
> Then imagine that you are running a Web server. Millions of clients ask
> you for ECN TCP connections. You support ECN because you have determined
> that it improves performance. You also want to get the client to use the
> nonce if supported, so you set the flags accordingly. The client
> responds with ECN support, but nonce sum =0.
>
> negate the performance benefits. Certainly you want to decline ECN for
> the one or two malicious users who use the device from the above
> devices that support it. Are you really likely to have gone to all the
> hassle of deploying ECN then you decline to use it or you limit
> cheating. If you still have to use judgement and heuristics anyway, the
> nonce is not a solution.
>
If implemented as a part of ECN support, I think the mechanism works - 
albeit you have to decide what to do about a client that chooses not to 
return a NS.

> 2) Now, let's assume you are having trouble with clients mounting one of
> the attacks described in RFC3540 that supresses loss feedback (not ECN).
>
> that doesn't ask for ECN? Again, you would have to punish large numbers
> of your customers in case a few might be cheating.
>
> something, please describe a believable scenario where the nonce would
> be useful.
>

I see some (potentially useful outcomes, we could agree upon?:

The problem that was intended to be addressed by the NS mechanism is a 
useful function that still should be addressed.

The NS mechanism was not (widely) deployed.

Other uses are permitted in the RFC-series, for ECT(1) - e.g. in 
combination with alternate DSCPs.

Perhaps more important, there may be mechanisms that can be still 
deployed to achieve the same goals, but with a better overall 
characteristic.

> I need to correct this misconception: ConEx is an e2e mechanism added to
> IP using transport feedback of loss or ECN where available. ConEx
> policing would certainly be applied in individual network domains, but
> the ConEx signal is e2e and defined in updates to e2e transport specs
> (starting with TCP).
>
I agree with what you say.

>> keywords in this way: "This leads to the following requirements, which
>> MUST be discussed for any proposed more accurate ECN feedback scheme:"
>> - Mandating discussion is not helpful.
>>
>> (point 2 above): If we have requirements as the title suggests, then I
>> personally would encourage you to list them as requirements using RFC
>> 2119 language - but I don't mind seeing no RFC 2119 keywords if the WG
>> wants this, as long as I can see the relative importance of each
>> topic. At the moment I can't see this.
>
> I recall that relative priority of requirements was already discussed in
> tcpm, and the general opinion (I think) was that this would be hard to
> do in abstract terms without a particular mechanism in mind that makes
> particular trade-offs. I strongly support that view - otherwise we will
> be having circular arguments for ever.
>
> I also think mandating discussion is helpful. accecn-reqs is a checklist
> of things that need to be aired in any candidate spec. What's wrong with
> that?
>
I read the latest version and said on-list that I *was* indeed happy 
with this aspect of the version being WGLC'ed.

> Bob

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 15 Jul 2014 20:19:10 +0100

Gorry,

Sorry for delay. Now it's me who missed your response for a while. Inline....

At 08:32 11/07/2014, Gorry Fairhurst wrote:
>Sorry for the long delay in response, please see below comments as 
>an individual:
>
>accepts ECN feedback from a receiver that isn't NS capable, then it 
>can not take advantage of the NS. You could be more conservative if 
>you knew the NS was not implemented, or something else.

My point was entirely that this is a deployment problem. I can't see 
a way to deploy the nonce protocol so that it allows TCP senders to 
distinguish cheating receivers from genuine. Whether or not the 
protocol is perfect when universally deployed is surely irrelevant if 
it provides little or no security while it is partially deployed.

The negotiation of a protocol capability is part of a protocol, so if 
it can be declined by those who don't want to be caught, and by many 
other innocent bystanders who create an environment where cheaters 
can hide in plain sight, then it is not a secure protocol.

>If implemented as a part of ECN support, I think the mechanism works 
>- albeit you have to decide what to do about a client that chooses 
>not to return a NS.

Yes, if the nonce had been a mandatory part of ECN, it would have 
given believable security. But it wasn't :(

>The problem that was intended to be addressed by the NS mechanism is 
>a useful function that still should be addressed.
>
>deployed to achieve the same goals, but with a better overall characteristic.

Yes. Agree (strongly) with all this.
Thx. And thx for the rest of the mail below.

Cheers

Bob