[secdir] secdir review of draft-ietf-savi-mix-12

["Scott G. Kelly" <[e-mail]>]

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?