Source Address Validation in Intra-domain and Inter-domain Networks
charter-ietf-savnet-01

Source address validation (SAV) is one important way to mitigate source address
spoofing attacks in the data plane. Therefore, it is desirable to deploy SAV
in intra-domain and inter-domain networks. However, existing SAV mechanisms
like uRPF-related technologies may improperly permit spoofed traffic or block
legitimate traffic.

The "Source Address Validation in Intra-domain and Inter-domain Networks
(SAVNET)" working group will define routing-protocol-independent architectures
and procedures to accurately determine the valid incoming router interfaces for
specific source prefixes. The accuracy of the new SAV mechanisms is expected
to improve upon the current ones. The WG will not work on extending existing
mechanisms.

The scope of the SAVNET WG includes the SAV function for both intra-domain and
inter-domain networks and the validation of both IPv4 and IPv6 addresses. The
WG will address intra-domain solutions first and focus on routing protocol-
based mechanisms. SAVNET should avoid packet modification in the data plane.
Existing control and management plane protocols should be used within existing
architectures to implement the SAV function. Any modification of or extension
to existing architectures or control or management plane protocols must be
carried out in the working groups responsible for them and in coordination with
this working group.

The SAVNET WG is chartered for the following list of items:

(1) Problem Statement, Use Cases, and Requirements

This document should include an analysis of the current solutions and their
limitations.  This item may require one document to address intra-domain
SAV and another to address inter-domain SAV.

This document may not necessarily be published as an IETF Stream RFC, but
may be maintained in draft form or on a collaborative Working Group space
to support the efforts of the Working Group and help newcomers.

(2) SAVNET Architecture Documents

This item requires one document to address intra-domain SAV and another to
address inter-domain SAV.  Each document must describe the conditions under
which the architecture can improve accuracy or performance with respect to
existing SAV mechanisms without assuming pervasive adoption.  Each document
must also include a privacy analysis, the threat model addressed by the
proposed architecture, and a comparison to existing SAV mechanisms.

(3) Definition of routing protocol-independent operation and management
mechanisms to operate and manage SAV-related configurations.

After the WG has reached consensus on each item, a discussion about
whether it is appropriate to continue with further work must occur. The
discussion can consider topics related to the accuracy of the mechanism and the
types of attacks it can prevent. The WG Chairs will define the specific
criteria and determine that rough consensus to work further has been reached.
The WG may be rechartered or closed if rough consensus is not reached.

The SAVNET WG will coordinate and collaborate with other WGs as needed.
Specific interactions may include (but are not limited to):
* lsr for OSPFv2, OSPFv3 and IS-IS extensions
* idr for BGP extensions
* lsvr for BGP SPF extensions
* rift for RIFT extensions

Each of these other WGs can independently determine the applicability and
priority of SAV to their deployments.