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?