Skip to main content

Last Call Review of draft-ietf-savi-mix-12

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
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

   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?