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

[Bob Briscoe <[e-mail]>]

Valery, see [BB3]

On 22/07/2022 14:16, Valery Smyslov wrote:
>
> 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]
>     <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.
>

[BB3] ...We want to propose one change to my original suggested text: 
s/illegal/unexpected/
Reason: ECT0 - > ECT1 is actually legal, in the narrow case of packets 
with a particular DSCP, by an old proposed standard [RFC6660] that was 
implemented but its time has now passed. Rather than go into a long 
subroutine explaining that, it more readable just to use a slightly 
weaker word.

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

[BB3] Even better compromise. This is all now in the local editor's copy.
That closes off this point. Thank you.

>
>
> [Snipped next point (misunderstanding about need for ECT1), given 
> agreement reached]
>
>

[Snipped conversation about integrity of congestion notifications, given 
agreement reached]

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

[BB3] Done.

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

[BB3] Yes, fully converged. Thank you again.


Bob

>
> 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 Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/