Skip to main content

Last Call Review of draft-ietf-idr-long-lived-gr-05

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
Reviewed revision 05 (document currently at 06)
Result Has issues
Completed 2023-07-04
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...".