Skip to main content

Source Address Validation Improvement (SAVI) Framework

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    savi mailing list <>,
    savi chair <>
Subject: Document Action: 'Source Address Validation Improvement Framework' to Informational RFC (draft-ietf-savi-framework-06.txt)

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:

Ballot Text

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.


   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:

  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:

  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:

  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?

RFC Editor Note