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

[Bob Briscoe <[e-mail]>]

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.

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


> The
> conclusion made in C.1, that integrity protection of ECT(1) is not needed, must
> be backed up in my opinion.

[BB] Ah! we didn't mean that. I admit it isn't very clear, so how about 
this rewording (HTML format email reader required):

CURRENT:

    It is highly unlikely that ECT(1) will be needed for integrity
    protection in future. The ECN Nonce RFC [RFC3540] as been
    reclassified as historic, partly because other ways have been
    developed to protect feedback integrity of TCP and other
    transports [RFC8311] that do not consume a codepoint in the IP
    header.  For instance:

PROPOSED:

    It is highly unlikely that ECT(1) will be needed*as a nonce *for integrity
    protection*of congestion notifications *in future.  The ECN Nonce RFC [RFC3540]*h*as been
    reclassified as historic, partly because other ways*(that do not consume a codepoint in the IP header)*  have been
    developed to protect feedback integrity of TCP and other
    transports [RFC8311]that do not consume a codepoint in the IP header.  For instance:

Reason:
We didn't mean that integrity protection /of/ ECT(1) is not needed.
We meant use of ECT(1) /for/ integrity protection of the rest of the ECN 
field is not needed, because other integrity protection methods are 
available (without having to burn a scarce codepoint in the IP header).


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

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.


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.

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


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

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


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/