Last Call Review of draft-ietf-idr-long-lived-gr-05
review-ietf-idr-long-lived-gr-05-secdir-lc-smyslov-2023-07-04-00
Request | Review of | draft-ietf-idr-long-lived-gr |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2023-07-13 | |
Requested | 2023-06-29 | |
Authors | Jim Uttaro , Enke Chen , Bruno Decraene , John Scudder | |
I-D last updated | 2023-07-04 | |
Completed reviews |
Secdir Last Call review of -05
by Valery Smyslov
(diff)
Genart Last Call review of -05 by Stewart Bryant (diff) Secdir Telechat review of -06 by Valery Smyslov Opsdir Last Call review of -02 by Bo Wu (diff) Rtgdir Last Call review of -02 by Mike McBride (diff) |
|
Assignment | Reviewer | Valery Smyslov |
State | Completed | |
Request | Last Call review on draft-ietf-idr-long-lived-gr by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/8Q7ghbfEZzjt9BKX2DEHcYuGO_I | |
Reviewed revision | 05 (document currently at 06) | |
Result | Has issues | |
Completed | 2023-07-04 |
review-ietf-idr-long-lived-gr-05-secdir-lc-smyslov-2023-07-04-00
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 document defines a new BGP capability "Long-lived Graceful Restart Capability" that allows stale routes to be retained for a longer time than is currently allowed by RFC 4724. The document is well written and is easy to understand. My concern is that the upper limit for the "Long-lived Stale Time" period is 2^24 - 1 seconds (about 194 days) and the document doesn't specify any restrictions for this value. It seems to me that having such long lived stale routes may open new possibilities for attackers. In particular, a possibility of a resource exhausting for storing a lot of stale routes for a very long time leading to a DoS attack come first to my mind. This possibility is not mentioned in the Security Considerations. Then, it seems to me that the countermeasures suggested in Section 6 to avoid VPN breach may not work for large values of the "Long-lived Stale Time" period. And a final nit: the last para of Section 6 looks to me like some sort of excuse, which in my opinion is not appropriate for a technical document. No matter how complex an attack is, if it is ever feasible with the given threat model, then we should just describe it with no additional sentiments that it is hard. Perhaps it is better to describe possible attacks in terms of attacker's capabilities. E.g.: "If an attacker is able to inject packets into the network then the following attacks are possible...".