Last Call Review of draft-ietf-savi-mix-12
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?