Last Call Review of draft-ietf-alto-cost-calendar-17
review-ietf-alto-cost-calendar-17-secdir-lc-weis-2020-02-24-00
Request | Review of | draft-ietf-alto-cost-calendar |
---|---|---|
Requested revision | No specific revision (document currently at 21) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2020-02-24 | |
Requested | 2020-02-10 | |
Authors | Sabine Randriamasy , Y. Richard Yang , Qin Wu , Deng Lingli , Nico Schwan | |
I-D last updated | 2020-02-24 | |
Completed reviews |
Opsdir Last Call review of -16
by Jürgen Schönwälder
(diff)
Secdir Last Call review of -17 by Brian Weis (diff) |
|
Assignment | Reviewer | Brian Weis |
State | Completed | |
Request | Last Call review on draft-ietf-alto-cost-calendar by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/0IU4xe8mknOOPeAJ4sYRo4cDbd0 | |
Reviewed revision | 17 (document currently at 21) | |
Result | Ready | |
Completed | 2020-02-24 |
review-ietf-alto-cost-calendar-17-secdir-lc-weis-2020-02-24-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. This document defines the ALTO Cost Calendar, an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. Currently, the ALTO cost information service provides applications with guidance about current costs of a desired resource, but not for resources with a cost that changes dramatically over time. The ALTO Cost Calendar allows for specifying costs for varying time periods in the future. The extensions in this document are to the existing network flows, with policy defined in JSON. As such, additional security considerations are few. The well-written Security Considerations document does define a few considerations that come from announcing events that are expected to happen in the future. I have only one suggestion for additional text. The second paragraph on page 27 (draft -17) describes risks of a client using the calendaring information for their own selfish purposes. The suggested mitigation in the next paragraph is to limit the information “being leaked to malicious clients or third parties“ by authenticating clients with TLS. This strategy may thwart “third parties”, but it will not help in the case of “malicious clients” possessing valid credentials to authenticate. The threat here might be legitimate clients that have become subverted by an attacker and are now ‘bots’ being asked to participate in a DDoS attack. The calendar information would be valuable information for when to persecute a DDoS attack, and this should be noted here.