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

Pete McCann <mccap@petoni.org> Thu, 03 November 2011 00:44 UTC

Return-Path: <mccap@petoni.org>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC84C11E8073 for <gen-art@ietfa.amsl.com>; Wed, 2 Nov 2011 17:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnzMBE-1MMsf for <gen-art@ietfa.amsl.com>; Wed, 2 Nov 2011 17:44:58 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB03A1F0C36 for <gen-art@ietf.org>; Wed, 2 Nov 2011 17:44:57 -0700 (PDT)
Received: by qyl16 with SMTP id 16so629776qyl.10 for <gen-art@ietf.org>; Wed, 02 Nov 2011 17:44:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petoni.org; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=OiKeVhqECP7V+I32naXlZxNYB/GkVXFMQvzweQHMN3U=; b=LlSgDEg7kVzrb/ZQxx8EKo5lZ0uqYP4ASHJbnJ66QrKHG1fIjra1rfU1Gxie5y3Wrb TdxJTE1RnyRU1uzBeIJBTLotSXm60PrHjh5l/vMDGK+L/Edy8YqXFlB6LUWzh5VmrREa CKxJ6KGZ2WOJe2CCQCkKqwqGukpSkvKEu8bXc=
MIME-Version: 1.0
Received: by 10.182.49.1 with SMTP id q1mr1369433obn.48.1320281097027; Wed, 02 Nov 2011 17:44:57 -0700 (PDT)
Received: by 10.182.47.97 with HTTP; Wed, 2 Nov 2011 17:44:56 -0700 (PDT)
X-Originating-IP: [68.45.157.93]
Date: Wed, 2 Nov 2011 20:44:56 -0400
Message-ID: <CACvMsLFSoCPkRr3f7WS0u_517yn_QLO4vtG1M53X0cEnV7wg4A@mail.gmail.com>
From: Pete McCann <mccap@petoni.org>
To: gen-art@ietf.org, draft-ietf-savi-framework.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Gen-art] Gen-ART Telechat Review of draft-ietf-savi-framework-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Nov 2011 00:44:59 -0000

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>gt;.

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