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). The conclusion made in C.1, that integrity protection of ECT(1) is not needed, must be backed up in my opinion. 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. 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). 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. 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). -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
