Last Call Review of draft-ietf-savi-mix-12
review-ietf-savi-mix-12-secdir-lc-kelly-2016-12-01-00
Request | Review of | draft-ietf-savi-mix |
---|---|---|
Requested revision | No specific revision (document currently at 15) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-11-29 | |
Requested | 2016-11-17 | |
Authors | Jun Bi , Guang Yao , Joel M. Halpern , Eric Levy-Abegnoli | |
I-D last updated | 2016-12-01 | |
Completed reviews |
Secdir Last Call review of -12
by Scott G. Kelly
(diff)
Intdir Early review of -11 by David Lamparter (diff) Intdir Early review of -11 by Ralph Droms (diff) |
|
Assignment | Reviewer | Scott G. Kelly |
State | Completed | |
Request | Last Call review on draft-ietf-savi-mix by Security Area Directorate Assigned | |
Reviewed revision | 12 (document currently at 15) | |
Result | Has issues | |
Completed | 2016-12-01 |
review-ietf-savi-mix-12-secdir-lc-kelly-2016-12-01-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. summary: Ready with issues This document describes how multiple Source Address Validation Improvement (SAVI) methods can coexist in a single SAVI device and how collisions are resolved when the same binding entry is discovered by two or more methods. This is my first exposure to SAVI. In reviewing this document, I skimmed RFCs 7219, 7513, 6620, 7039, and 4862. I have a few comments on the Security Considerations text. The first paragraph says, SAVI MIX does not eliminate the security problems of each SAVI method. Thus, the potential attacks, e.g., the DoS attack against the SAVI device resource, can still happen. In deployment, the security threats from each enabled SAVI methods should be prevented by the corresponding proposed solutions in each document. Two comments on this: first, not only does SAVI MIX not improve on or reduce the security concerns for each implemented SAVI method, but in fact, combining methods (as in SAVI MIX) may increase susceptibility to DoS attacks. This is hinted at in the next paragraph, but it would be better to call this out directly. For the 3rd sentence, you might try, “In deployment, security considerations for each enabled SAVI method should be addressed as described in the associated RFC.” The second paragraph says, SAVI MIX is only a binding setup/removal arbitration mechanism. It does not introduce additional security threats if the arbitration is reasonable. However, there is a slight problem. SAVI MIX is more tolerant about binding establishment than each SAVI method alone. As long as one of the enabled SAVI methods generates a binding, the binding will be applied. As a result, the allowed number of SAVI bindings or allowed SAVI binding setup rate will be the sum of that of all the enabled SAVI methods. In deployment, whether a SAVI device is capable of supporting the resulting resource requirements should be evaluated. What constitutes “reasonable” arbitration? Shouldn’t this document spell that out? The document comments that SAVI is more “tolerant”, but shouldn’t this point out that mixing methods potentially reduces the security level to that of the weakest supported method (because of the FCFS suggestion below) unless additional steps (e.g. requiring non-overlapping address spaces for different methods) are taken?