Document Action: 'Source Address Validation Improvement Framework' to Informational RFC (draft-ietf-savi-framework-06.txt)
The IESG <iesg-secretary@ietf.org> Tue, 21 February 2012 21:02 UTC
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487311E8075; Tue, 21 Feb 2012 13:02:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.653
X-Spam-Level:
X-Spam-Status: No, score=-102.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Kt4bsEi8zCGK; Tue, 21 Feb 2012 13:02:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592AF11E80A5; Tue, 21 Feb 2012 13:02:03 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'Source Address Validation Improvement Framework' to Informational RFC (draft-ietf-savi-framework-06.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 3.64p2
Message-ID: <20120221210203.31689.8282.idtracker@ietfa.amsl.com>
Date: Tue, 21 Feb 2012 13:02:03 -0800
Cc: savi mailing list <savi@ietf.org>, savi chair <savi-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 21:02:12 -0000
The IESG has approved the following document: - 'Source Address Validation Improvement Framework' (draft-ietf-savi-framework-06.txt) as an Informational RFC This document is the product of the Source Address Validation Improvements Working Group. The IESG contact persons are Jari Arkko and Ralph Droms. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-savi-framework/ Technical Summary The Source Address Validation Improvement method was developed to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes and motivates the design of the SAVI method. Working Group Summary The normal WG process was followed. The document as it is now, reflects WG consensus. Note that ongoing discussions about tracing in an earlier SAVI WG document may affect this document, even substantially. Document Quality The document was thoroughly reviewed by Frank Xia, Mikael Abrahamsson and Jean-Michel Combes. Personnel The Document Shepherd is J-M Combes and the responsible Area Director is Jari Arkko. RFC Editor Note Please add this text to the end of Section 1: NEW: Note that SAVI raises a number of important privacy considerations that are discussed more fully in [draft-ietf-savi-threats]. SAVI implementers MUST take those privacy considerations into account when designing solutions that match this framework and follow the recommendations given in [draft-ietf-savi-threats]. Please add this text to the end of the Security Considerations Section: NEW: Section 2 explained how the preferred location of SAVI instances is close to hosts. However, in some cases this make the SAVI instances themselves vulnerable, and may defeat the purpose of deploying a SAVI solution. For instance, deployments should not place SAVI functionality in devices that are physically exposed. Even if the device correctly monitors the source address usage of hosts, an attacker could replace the device with one that does not check, or hook up to a trusted interface from the device to the rest of the network. Similarly, deployments where SAVI instances are distributed across administrative boundaries are not recommended. For instance, in most cases it would be undesirable to deploy a distributed SAVI solution on both sides of a customer - provider interface, if the solution required trusting the correct operation of the SAVI devices on the other side of the interface. Please add this text to the end of Section 4: NEW: Note, if such configuration is used, care must be taken as any hosts on subnets attached to non-enforcing ports will be able to use spoofed source addresses?