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 rev. 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 Halpern, Eric Levy-Abegnoli
Draft last updated 2016-12-01
Completed reviews Secdir Last Call review of -12 by Scott Kelly (diff)
Intdir Early review of -11 by David Lamparter (diff)
Intdir Early review of -11 by Ralph Droms (diff)
Assignment Reviewer Scott Kelly 
State Completed
Review review-ietf-savi-mix-12-secdir-lc-kelly-2016-12-01
Reviewed rev. 12 (document currently at 15)
Review result Has Issues
Review completed: 2016-12-01

Review
review-ietf-savi-mix-12-secdir-lc-kelly-2016-12-01

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?