Subject: Re: [secdir] secdir review of draft-ietf-tcpm-accurate-ecn-14

From: Bob Briscoe <[email-masked]>
Date: Fri, 7 May 2021 19:15:22 +0100

Scott,

A belated thank you for your review. Sorry, I've been head down 
preparing a draft for an interim in another WG on Monday, which I just 
submitted.

On 13/04/2021 01:03, Scott G. Kelly wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> The summary of the review is Almost Ready.
>
> The title of this draft is, "More Accurate ECN Feedback in TCP". The document specifies a scheme (abbreviated AccECN) to provide more than one feedback signal per RTT in the TCP header. It does this by allocating a reserved header bit that was previously used for the ECN-Nonce (which has now been declared historic), and it overloads the two existing ECN flags in the TCP header.
>
> I'm not a TCP or ECN expert, so please take my comments with a proverbial grain of salt. Thinking about this strictly as a security geek, I see three places where this scheme could be tampered with: the sender, the receiver, and the network in between them.
>
> The security considerations section starts off by pointing out that there will be consequences to tampering by a middlebox (the network in between), and it describes the impact as limited.
>
> A malicious sender is not described, and I'm not sure that any such thing reasonably exists, but I did wonder about this.

[BB] A malicious sender is not described because the scope of AccECN is 
purely about changes to TCP's feedback protocol between Data Receiver 
and Data Sender. Malicious senders can ignore TCP feedback. So it 
doesn't matter what we say when we update a feedback spec if malicious 
senders can ignore the feedback anyway.

Incidentally, AFAIK, the only approach that has ever addressed the 
problem of ensuring the sender responds correctly to congestion feedback 
is the IETF's Congestion Exposure (ConEx) protocol, which the draft 
already cites in two contexts (both because ConEx also ensures the 
receiver has to feed back congestion indications honestly, and because 
ConEx needs AccECN to work correctly).

Do you think I ought to add this point to the Security Considerations?

>
> A malicious receiver (who might be motivated to interfere with AccECN in order to increase its own throughput at the expense of others) is described, and the reader is referred to section 5.3, which describes 3 different potential mitigations for this. There is also mention of the fact that the receiver might simply omit the option, pretending it had been stripped by a middlebox, but there is no known consequence (other than downgrading to plain ECN).
>
> There is a TODO in the security considerations which must be addressed (referring to a potential covert channel), and that's why the review summary is "Almost Ready". I suggest that the security AD might want someone both TCP and security expertise to evaluate this.

[BB] There might have been something lost in translation when the 
request for a SECDIR review was placed. The text in curly braces here 
was intended to be a message to the SECDIR reviewer about what we were 
most seeking guidance on. But I think you're right when you say this 
needs someone with both TCP and Security expertise (I have both, but I'm 
an author). I think the tcpm chairs have this in hand - I don't think 
you need to do anything further.

Thank you again.

Bob
> --Scott

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 10 May 2021 13:28:04 +0000

> > I'm not a TCP or ECN expert, so please take my comments with a proverbial
> grain of salt. Thinking about this strictly as a security geek, I see three places
> where this scheme could be tampered with: the sender, the receiver, and
> the network in between them.
> >
> > The security considerations section starts off by pointing out that there will
> be consequences to tampering by a middlebox (the network in between),
> and it describes the impact as limited.
> >
> > A malicious sender is not described, and I'm not sure that any such thing
> reasonably exists, but I did wonder about this.
> 

Just a quick note on terminology: For data transfers from a "data sender" to a "data receiver", the malicious "sender" of the TCP option would be the "data receiver".

So, a better phrasing might be:

  "... malicious *data* senders can ignore the feedback anyway."

When looking at the TCP option, a bit of care may be needed who is sending what (and for what purpose).

Michael

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 10 May 2021 15:22:13 +0100

Michael, see [BB2]

> When looking at the TCP option, a bit of care may be needed who is sending what (and for what purpose).

[BB2] Thx.
Also, in the Sec Consids section, we were careful to specify "Data 
rx/tx" except in one case, which I've fixed as well.

Bob