Subject: [Gen-art] Gen-ART Telechat Review of draft-ietf-savi-framework-05

From: Pete McCann <[email-masked]>
Date: Wed, 2 Nov 2011 20:44:56 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-savi-framework-05
Reviewer:  Peter McCann
Review Date: 2011-11-02
IETF LC End Date:
IESG Telechat date: 2011-11-03

Summary:  One minor issue

Major issues: none

Minor issues:

The document presents the design of the SAVI model, and advocates
putting SAVI validators as close to the end host as possible, forming
a protection perimeter where there is some assurance that source IP
addresses are valid inside the perimeter.

However, the document does not discuss the possibility that some nodes
inside the perimeter may be compromised or otherwise untrusted (for
example, in case there are multiple distinct administrative domains
connected in some topology).  This seems to be a case of crusty on
the outside, soft in the middle security.  Perhaps some discussion
of these issues is warranted.  For example, it might make sense in
some cases to deploy SAVI instances that do replicate state, which
is argued against in the draft on the basis of memory savings.

Nits/editorial comments:

Section 1:
   and help with localizing hosts and identify
   misbehaving hosts.
SHOULD BE:
   and help with localizing hosts and identifying
   misbehaving hosts.

Section 2:
   Besides, in the case of legacy switches, the security level is lower,
   as there is no full protection for the hosts connected to the legacy
   server.
SHOULD BE:
   Besides, in the case of legacy switches, the security level is lower,
   as there is no full protection for the hosts connected to the legacy
   switch.

Section 3.1:
   constrained to a
   single IP address assignment methods
SHOULD BE:
   constrained to a
   single IP address assignment method

Section 4:
   figure Figure 1,
SHOULD BE:
   Figure 1,

Section 6:
   mix scenario can handle the same as scenario
SHOULD BE:
   the mixed scenario can be handled the same as a scenario

Reword this paragraph:
   Prioritization relationship between different address assignment
   methods is used as the basis to solve possible collisions.  Current
   standard documents of address assignment methods have implied the
   prioritization relationship in general cases.  However, considering
   in some scenarios, default prioritization level may not be quite
   suitable.  Configurable prioritization level should be supported in a
   document of SAVI solution for the mix scenario.

Section 7:
   This document
   suggests set 3 prefix configuration mechanisms at SAVI device:
SHOULD BE:
   This document
   suggests a set of 3 prefix configuration mechanisms at SAVI device:

   used as premier check
SHOULD BE:
   used as a first check