Subject: [SAVA] Request for SAVA BoF at IETF69 [Was: Re: [Int-area] BOF and WG request cutoff date approaching]

From: fergdawg at netzero.net (Fergie)
Date: Mon, 21 May 2007 17:00:13 GMT

An embedded and charset-unspecified text was scrubbed...
Name: not available
Url: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/attachments/20070521/d2af64b4/attachment.txt

---

From: junbi at cernet.edu.cn (Jun Bi)
Date: Wed, 23 May 2007 13:40:55 +0800

Just a minor revision to the BoF request.
The SAVA mailing list info should be:

General Discussion: sava at nrc.tsinghua.edu.cn
To Subscribe: http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava   (was changed)
Mailing List Archive: http://mail.nrc.tsinghua.edu.cn/pipermail/sava/      (was changed)
Document Repository: http://narl.tsinghua.edu.cn/sava

thanks,
Jun Bi

Source Address Verification and Authentication (SAVA)

Co-chairs
TBD

Internet Area Directors:

Jari Arkko <jari.arkko at piuha.net>
Mark Townsley <townsley at cisco.com>

Internet Area Advisor:
TBD

Routing Area Advisor:
TBD

Security Area Advisor:
TBD

Technical Advisors:
TBD

Mailing Lists:

General Discussion: sava at nrc.tsinghua.edu.cn
To Subscribe: http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
Mailing List Archive: http://www.nrc.tsinghua.edu.cn/pipermail/sava/
Document Repository: http://narl.tsinghua.edu.cn/sava

Description of Working Group/s:

The proposed "Source Address Validation Architecture" Working Group is
chartered to specify standardization of methods for building an IP (both
IPv4 and IPv6) addressing architecture to ensure that every packet received
and forwarded holds an authentic source address. 

"Valid source address" in this case has two meanings: 
i) First, the address must have been appropriately allocated and not be
forged. (i.e. the route to the address must have been injected into the
routing tables by someone authorized to inject such a route, and the packet
must have been injected into the network by an entity authorized to use
that source address.)

ii) Second, the address except in cases where global uniqueness is
specifically excluded, must be globally unique and traceable to its origin.
That is, information about the address's location and ownership must be
verifiable and correct.

The current Internet addressing architecture does not verify the source
address of the packets received and forwarded, although RFC 1812 has
mentioned that a router SHOULD implement the ability to validate source IP
addresses. In the current Internet addressing architecture using IPv4, it
is difficult to ensure the authenticity of the source IP address of every
packet forwarded in the network. This leads to many security, management,
and accounting problems.

There are many mechanisms related to the validation of source IP addresses,
(see the appendix,) but few of them are widely deployed by the current
Internet addressing architecture. Because the current Internet addressing
architecture using IPv4, which does not verify the source address of the
packets received and forwarded, has been in operation for many years, it is
not feasible or cost-effective to change from the current Internet
infrastructure.

The main purpose of the SAVA WG is to propose a source address validation
architecture. 

The first step will be a detailed categorization and description of the
problem and sub-problems that ...(problem statement document)

The framework for design and possibilities for the implementation of the
architecture will be discussed and outlined in a separate framework
document. Existing protocols and technologies may be extended, and new
mechanisms and protocols to support the architecture may be created. 

The deployment policy and network transition mechanism also need to be
taken into account. The WG should not limit itself to a single
architectural design or a single solution for any given part of the
architecture, although there should be an over-arching framework to which
all designs, mechanisms, operational practices and other solutions must
adhere.

The thirds step is to..(solutions)

Important characteristics of any solutions produced by the SAVA WG include:

1. Operators should receive a significant benefit from deploying the
architectural mechanisms in their own network, even if many parts of the
Internet have not deployed. This is required to give operators an incentive
to adopt the architecture as early as possible.

2. The architecture should support incremental deployment, so that there is
tangible benefit to be gained from partial deployment on the Internet.

3. The architecture must not have any significant negative impact on
throughput or latency.

4. The relation between different components of the architecture should be
loosely-coupled. That is, where there are multiple mechanisms to address a
particular problem or function within the architecture, it should be
possible for network operators to choose the mechanism they find most
suitable.

5. The architecture should support multi-fence solutions to provide
different granularities of authenticity. That is, there should be
mechanisms to deal with address authenticity at the local network level, at
the provider edge, at intra-provider router connections and at
inter-provider boundaries.

6. The solutions should focus both on IPv4 and IPv6, but solutions suitable
for IPv6 should not be excluded simply because they are not suitable for
IPv4. 

Within this in mind, the goals of the WG are to complete the following work
items

. Document the problem statement for which the work of SAVA is a
solution, and submit it to the IESG as an Informational Standard.

. Design an architectural framework for SAVA and its component solutions,
identifying the interactions between them, and submit it to the IESG for
publication as a Proposed Standard.

. Develop [individual solutions for each component for the framework
architecture] to support SAVA and submit them to the IESG for publication
as Proposed Standards.

The WG Will NOT:

. Work on end-end verification for applications and hosts, although hooks
may be provided to allow applications to discover if the source address of
a packet comes from a "SAVA Compliant" Network.

. Mechanisms to implement SAVA functionality where exact mechanisms are
better left to individual vendors to implement.

Goals and Milestones:

Jun-07 Submit -01 versions of problem statement, framework document and
test-bed experience.

Jul 07 Hold BoF in Chicago, asking for this Charter to be approved

Aug 07 Final version of Charter approved and WG created.

Aug 07 Submit draft-00 of SAVA first-hop validation draft.

Oct 07  Submit WG Draft-00 on Problem Statement for SAVA

Oct 07 Submit WG Draft 00 on Architectural Framework for SAVA

Feb 08 Submit WG draft 00 SAVA first-hop validation solution

Feb-08 Collect non-WG drafts for intra- and inter- AS validation solutions.

Mar 08 Final Drafts  of problem statement and framework document for
submission to IESG

Jun-08 Submit WG draft 00 for intra and inter-AS validation solutions

Aug 08 Submit final draft of SAVA first-hop validation draft to IESG for
approval.

Dec 08 Submit final drafts for intra- and inter- AS validation solutions to
IESG

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

--------------------------------------------------------------------------------

> _______________________________________________
> SAVA mailing list
> SAVA at nrc.tsinghua.edu.cn
> http://mail.nrc.tsinghua.edu.cn/cgi-bin/mailman/listinfo/sava