Re: [secdir] [Last-Call] [tsvwg] Secdir last call review of draft-ietf-tsvwg-ecn-l4s-id-26

[Valery Smyslov <[e-mail]>]

Hi Bob,

 

thank you for the follow-up. Please see inline.

 

From: last-call [mailto:[e-mail]] On Behalf Of Bob Briscoe
Sent: Thursday, July 21, 2022 11:43 PM
To: Valery Smyslov; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Last-Call] [tsvwg] Secdir last call review of draft-ietf-tsvwg-ecn-l4s-id-26

 

Valery,

See [BB2]

On 21/07/2022 13:46, Valery Smyslov wrote:

HI Bob,

 

please, see inline.

 

From: Bob Briscoe [mailto:[e-mail]] 
Sent: Wednesday, July 20, 2022 8:08 PM
To: Valery Smyslov; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [tsvwg] Secdir last call review of draft-ietf-tsvwg-ecn-l4s-id-26

 

Valery,

Thank you for putting in all the work to review this. See [BB] inline.

On 19/07/2022 07:56, Valery Smyslov via Datatracker wrote:

Reviewer: Valery Smyslov
Review result: Has Issues
 
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 draft proposes an experimental Explicit Congestion Notification protocol
for low latency, low loss and scalable throughput (L4S) networks. The draft
also proposes a way for L4S and classic traffic to co-exist in the same network
by marking the L4S traffic with a value ECT(1) in IP header.
 
The draft contains a Security Considerations section that refers to the
security considerations in the architecture document for L4S networks
(draft-ietf-tsvwg-l4s-arch). It also references to Appendix C.1 for discussions
of the methods used to ensure integrity of congestion notification signals and
also discusses issues arising when traffic containing different DSCP values is
encapsulated in a single VPN tunnel - the replay protection mechanism can make
low priority traffic unable to pass through.
 
I think that the Security Considerations section lacks discussion of what can
happen with this protocol if an attacker actively manipulates the signals on
the path. Discussion in Appendix C.1 looks insufficient to me (and it mostly
concerned with misbehaved peers and not with active attacker on the path). 


[BB] Once an attacker has broken a network operator's system or physical access control to be able to mount on-path attacks, it is surely common knowledge that the operator's service is toast. Most of the fields in the IP header have little if any protection against on-path attacks {Note 1}. 

This draft defines an experimental use of one codepoint in a pre-existing field in the IP header. I don't believe that warrants mentioning the possibility that the access control of a network operator's systems could be breached. For instance, as far as I can see, there was not even discussion of on-path attacks in RFC791 or RFC2460 when IPv4 and IPv6 were defined, nor in any of their updates. And none in RFC2474 when the DSCP was defined. And none in RFC3168 when ECN was defined.

 

          Well, RFC791 doesn’t even have a security considerations section, so what? :-)

 

We could write a sentence into the draft saying that this codepoint is in the IP header, and everything in the IP header is vulnerable to on-path attack if system or physical access control is compromised. But I would rather not, because it wouldn't be specifically relevant to this draft (although I would not fight hard against it if the sec area  director insisted). 




          My point was that it’s worth to mention what on-path attacker can specifically do with this protocol, not to add a sentence that such an attacker can do any kind of evil (which is generally right). For example:

 

                      An attacker capable to block packets or to modify them on the path can disrupt this protocol in the following ways:

1.     re-classify L4S traffic as classic and vise-versa

2.     manipulate ECN signals that may cause buffers overrun or underrun

3.     ...

 

                      An attacker capable to only inject new packets into the network can disrupt this protocol in the following ways:

4.     ?

________
{Note 1}: For instance, an on-path attacker can delete some or all passing packets. It can send them out of the wrong interface and increment the hop limit, creating a routing loop with no hop limit. It can change their source and/or destination addresses (appropriately changing their TCP checksums - or not for that matter). It can change their (outer) DSCP. It can reduce the hop limit (or TTL in v4) so that someone else downstream looks as if they are dropping packets before they reach their destination, and so on.

          Note also, that attacker’s capabilities may be limited to only inject new packets and not to block or modify the existing packets.

          I think it’s worth to clarify how such an attacker can influence operations of this protocol (see above).


[BB2] What purpose would this serve? I'm afraid it would be what I would call 'security text for the sake of writing'. 

It would be equivalent to a draft about the definition of a new Diffserv codepoint having to describe what an on-path attacker could do if it changed the DSCP to each of the other DSCPs, or injected copies of packets with the DSCP changed. Such on-path attacks might have been relevant in the original Diffserv or ECN specs, but given they weren't written there, I don't think they have a place in a new codepoint definition for an existing field. I'm trying to nip this in the bud, otherwise academic text listing possible on-path attacks would just make all RFCs incredibly tedious. However, I have a compromise...


More relevant perhaps would be the possible changes to the L4S ECN field that a network operator itself might apply. Of course, the ECN field is meant to be changed by the operator - to indicate congestion. There is discussion of other illegal ECN transitions in the original ECN spec [RFC3168; §18] although it is rather abstract and divorced from the motivations an operator has. Those motivations for changing these fields and how to deal with them were all addressed much more completely by the ConEx WG, which is why this draft refers to the ConEx abstract mechanism [RFC7713]  (see later). 

Your review comment does make me notice that a pointer about swapping ECN codepoints is missing from the Security Considerations. I'll explain by proposing text to fix it, to be added at the end of the first para of the Security Considerations:

...Defining ECT(1) as the L4S identifier introduces a difference between the effects of ECT0 and ECT1 that RFC 3168 previously defined as distinct but with equivalent effect. For L4S ECN, a network node is still required not to swap one to the other, even if the network operator chooses to locally apply the treatment associated with the opposite codepoint (see Sections 5.4.1.1 and 5.4.1.2). These sections also describe the potential effects if a network node does swap one to the other. The present specification does not change the effects of other illegal transitions of the ECN field, which are still as described in Section 18 of RFC 3168.

Then add the following 'what-if' sentences respectively to the ends of 5.4.1.1 and 5.4.1.2:

5.4.1.1 
...If a non-compliant network node did swap ECT(0) to ECT(1), the packet could subsequently be ECN-marked by a downstream L4S AQM, but the sender would respond to congestion indications thinking it had sent a Classic packet. This could result in the flow yielding excessively to other L4S flows sharing the downstream bottleneck.

5.4.1.2
...If a non-compliant network node did swap ECT(1) to ECT(0), the packet could subsequently be ECN-marked by a downstream Classic ECN AQM. L4S senders are required to detect and handle such treatment (Section 4.3 item 3), but that does not make this swap OK, because such detection is not known to be perfect or immediate. 


Is this a decent compromise? It describes the effect of swapping the codepoints. Even tho' it doesn't describe it as an on-path attack, it still implies what the result of an on-path attack would be. And, it helps explain what the stakes are to any operator that thinks swapping them would be OK. It also points to where the effect of the other transitions are described.

 

          Yes, this is a kind of text I wanted to see (describing how network attacks can influence this particular protocol). 

          I would only ask to add an attacker as a possible source of this swap. Something like this:

 

5.4.1.1 
...If a non-compliant or malicious network node did swap ECT(0) to ECT(1), the packet could subsequently be ECN-marked by a downstream L4S AQM, but the sender would respond to congestion indications thinking it had sent a Classic packet. This could result in the flow yielding excessively to other L4S flows sharing the downstream bottleneck.

5.4.1.2
...If a non-compliant or malicious network node did swap ECT(1) to ECT(0), the packet could subsequently be ECN-marked by a downstream Classic ECN AQM. L4S senders are required to detect and handle such treatment (Section 4.3 item 3), but that does not make this swap OK, because such detection is not known to be perfect or immediate. 



[Snipped next point, given agreement reached]




 

The alternative methods to protect feedback
integrity looks inefficient to me (I admit, that I may be missing something,
especially with ConEx which I have only looked over, but it looks to me that
active attacker can fool these methods). What about TCP-AO - it only protects
TCP packet, so an attacker is still able to manipulate DSCP field.


[BB] What is the actionable request here?

 

         I would suggest to add some text describing what kind of integrity protection is implied here and what an attacker is still able to do

         when these mechanisms are used.


As said earlier, this draft defines an experimental use of one codepoint in a pre-existing field in the IP header. It points to three ways that congestion notification and feedback in this pre-existing field can already be protected. This draft itself doesn't make any of these three any less or any more viable.




          I understand.


Paraphrasing, your comment says "I haven't really read or thought about these methods deeply, including the output of years of work of the ConEx IETF WG, but they're probably inefficient and vulnerable to active attack." I hope you agree that this isn't a particularly constructive or respectful comment.

 

          Didn’t mean to disrespect the ConEx IETF WG work. My point was that as a security person I believe that the term “integrity protection”, that you use, implies using some cryptographic mechanism, if we talk about active attackers and not about accidental network failures. As far as I understand, among the three only TCP-AO uses it, but only to protect the TCP header, so an attacker can still manipulate the IP header fields, e.g. to re-classify L4S traffic.

 

Regarding TCP AO, the bullet already says it only protects the feedback in the TCP header.

          You may also want to mention end-to-end IPsec, that will also protect transport headers (not limited to TCP).

 


[BB2] Here's proposed new text that describes "what kind of integrity protection is implied [by each] and what an attacker is still able to do":

For instance:
 
   *  The sender can test the integrity of a small random sample of the receiver's feedback by
      occasionally setting the IP-ECN field to a value normally only set
      by the network.  Then it can test whether the receiver's feedback
      faithfully reports what it expects (see para 2 of Section 20.2 <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-26#section-20.2>  of
      the ECN spec [RFC3168 <https://datatracker.ietf.org/doc/html/rfc3168> ].  This works for loss and it will work for
      the accurate ECN feedback [RFC7560 <https://datatracker.ietf.org/doc/html/rfc7560> ] intended for L4S. Like the 
      (historic) ECN nonce, this technique does not protect against a 
      misbehaving sender. But it allows a well-behaved sender to check 
      that each receiver is correctly feeding back congestion 
      notifications. 
 
   *  A network can check that its ECN markings (or packet losses) 
      have been passed correctly round the full feedback loop by 
      auditing congestion exposure (ConEx) [RFC7713 <https://datatracker.ietf.org/doc/html/rfc7713> ].  This assures 
      that the integrity of congestion notifications and feedback 
      messages must have both been preserved. ConEx information is also
      available anywhere along the network path so it can be used to 
      enforce a congestion response.  Whether the receiver or a downstream network
      is suppressing congestion feedback or the sender is unresponsive
      to the feedback, or both, ConEx audit can neutralise any advantage
      that any of these three parties would otherwise gain.  
 
   *  Congestion feedback fields in transport layer headers are immutable 
      end-to-end, and therefore amenable to end-to-end integrity protection. 
      This preserves the integrity of a receiver's feedback messages to 
      the sender, but it does not protect against misbehaving 
      receivers or misbehaving senders.  The TCP authentication 
      option (TCP-AO [RFC5925 <https://datatracker.ietf.org/doc/html/rfc5925> ]), QUIC's end-to-end protection [RFC9001] 
      or end-to-end IPsec authentication [RFC4302] can be used to
      detect any tampering with congestion feedback (whether
      malicious or accidental) respectively in TCP, QUIC or any transport.   
      TCP-AO covers the main TCP header and TCP options by default, but it
      is often too brittle to use on many end-to-end
      paths, where middleboxes can make verification fail in their
      attempts to improve performance or security, e.g. by
      resegmentation or shifting the sequence space.

 

          Generally these additions look good. But there is an issue with AH (RFC4302). While officially it exists,

          and it’s true that it can protect integrity of a whole IP packet including the IP header, it is almost extinct in real life.

          This is mostly because it is incompatible with NATs and with some other middleboxes

          and ESP now provides both confidentiality and authentication, so no need for separate protocol.

          For this reason I didn’t mention AH specifically and I suggest you to remove the reference to it

          (otherwise you are risking to become a target for folks arguing to make AH historic).

 

          By end-to-end IPsec I meant ESP in transport mode (it can be tunnel mode too, but with no benefits in this case)

          between ultimate sender and receiver that protects everything after IP header, so it has the same effect as TCP-AO for your use case.


Your suggestion to add IPsec led me to feel I should also mention QUIC (these bullets were originally written in 2017 when TCP was still dominant).
I believe it is now much clearer how each bullet relates to the point of the section, so thanks.

 

          Yes, it is better.


BTW, I hope you can see that the term “integrity protection”, that I used, does not have to imply using some cryptographic mechanism. That is a common misconception of people steeped in the information security world. If you're interested, offlist I can send you a presentation I prepared years ago collecting together a number of examples of what I called structural security design patterns. The first two above are both examples.

          I agree that we use slightly different meanings of this term :-)

          I would be grateful if you send me your presentation (offlist).

 

 
Part of discussion about VPN tunnels in the Security Considerations section is
a repetition of what was discussed in Section 6.2. The problem of blocking low
priority traffic by VPN replay protection mechanism is not new, but in my
opinion it is partly an operation issue depending on a threat model (users
behind VPN are usually "trusted" to some extend, but I agree that one's mileage
may vary).


[BB] Are you asking us to change any text? 
I think the text already states under which circumstances the vulnerability exists (the threat model).

          I’d suggest to remove the para starting with “If the anti-replay window of a VPN egress is too small..” 

          and replace it with a short text referencing Section 6.2. But it’s up to you.


[BB2] I'll leave it as it is, if that's OK, unless you think it's an incorrect summary of §6.2. If it's just repetition by summarization, that was intended.
We don't want to change anything we don't have to, given this was a somewhat controversial issue in the WG.




          OK, I can live with this.

 
 
The Security Considerations section also mentions the ACK-splitting attack
claiming that this recommendations prevent it, but no details are given (except
for a reference). It would be great if this para is expanded a bit.


[BB] That sentence was from one of the co-authors of all the L4S drafts, and I wrote it into the draft without checking that it was actually correct. It's very unusual for me to trust someone else without checking for myself (!). But now that I look into it, I'm not at all sure it is true. 

I've emailed my co-authors, and I'll get back to you on this one.


[BB] I started a thread about this on tsvwg analysing the Savage-TCP attacks, and recommending we should delete these two lines.
It's just received a nice clear agreement from Neal Cardwell, writing as co-author of both the Savage-TCP paper and the RACK RFC:
    https://mailarchive.ietf.org/arch/msg/tsvwg/zpDvWVUxW_XapDmjsxwwgs09izY/

Thank you for questioning these two lines. And thank you again for your review. 
We're converging. Hopefully one more round might close this discussion.

          Definitely!

 

          Thank you,

          Valery.

Bob





          OK, thank you.

 

          Regards,

          Valery.

 


Bob






 
 
Nit: to my eye the phrase "optional anti-replay is mandatory in both IPsec and
DTLS" looks like oxymoron: either it is optional or it is mandatory. Note also,
that in some conditions anti-replay protection in IPsec cannot be used (with
multicast traffic).


[BB] The intended meaning was:





    "it is mandatory to allow the anti-replay facility to be disabled in both IPsec and DTLS"


We'll change it to that.


Bob






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





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