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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux