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? _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
