The IESG has approved the following document: - 'SAVA Testbed and Experiences to Date ' <draft-wu-sava-testbed-experience-06.txt> as an Experimental RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wu-sava-testbed-experience-06.txt Technical Summary This draft documents an experimental design implemented in a research network for source address validation. The draft is not intended as a solution proposal but rather as a report of something that was done together with both the positive and negative experiences. Working Group Summary This is not a WG document, and is published only as information for the Internet community. Document Quality The presented approaches have been implemented on a test bed. Personnel The document has been reviewed by Jari Arkko for the IESG. RFC Editor Note Please remove references from the abstract (i.e., [Wu07]). Section 1: s/accomplishedaccurately/accomplished accurately/ Figure 5: s/.REG/REG/ Please change the title of the document to "A SAVA Testbed and Deployment Experience" In Section 2.5, change OLD: Although the overhead of maintaining and exchanging authentication tags between AS pairs is O(N) rather than O(N^2), the ... NEW: Although the overhead of maintaining and exchanging authentication tags between AS pairs is O(N) from the point of view of one AS, rather than O(N^2), the ... Keep the two first paragraphs of Section 2.1, but replace everything else in the section (even the figure) with this: __ ____ __ ____ .-'' `': .-'' `': | | | | | +-+----+ | Inter-AS SAV | +-+----+ | | |Router+--+------------------+---|Router+ + | +--.---+ | | +--.---+ | Intra-AS | | \ Intra-AS | | | SAV | +--+---+ \ SAV | +--+---+ | | |Router| \ | |Router| | | +--.---+ \ '_ +-----+ _ | | \ `'-------''' / | \ / | \ | +---------------------+\ ----+---------. Router | \ | ++-------\------------+ \ | | | \ | | | | | +------+|+------++----+|Intra-AS | | |Switch|||Switch||Host||SAV | | +------+|+------++----+| | | | | | \ | |+-+--++----+|+----++----+ | ||Host||Host|||Host||Host| | `+----++----+|+----++----+ / `--. | _.-' `------|------+'' Access | Network | SAV Key: SAV== Source Address Validation Figure 1: Solution Overview This document divides source address validation into three different classes of solutions: 1. Access network. This prevents a host in a network from spoofing the address of another host in the same network segment. This enables host-granularity of protection compared to Intra-AS prevention. See Section 2.2 for details. 2. Intra-AS. When the edge router of an access network performs source address validation (e.g., using [RFC2827] and [RFC3704]), hosts are prevented from spoofing an arbitrary address, but unless access network SAV is employed, they may be able to spoof an address of a host in the same network segment. In a degenerate case, when a router connects a single host, the host can't spoof any address. 3. Inter-AS. Mechanisms that enforce packet source address correctness at AS boundaries. Because the global Internet has a mesh topology, and because different networks belong to different administrative authorities, IP source address validation at Inter-AS level is more challenging. Nevertheless we believe this third level of protection is necessary to detect packets with spoofed source addresses, when the first two levels of source address validation are missing or ineffective. In the rest of this section we describe the specific mechanisms implemented at each of the three levels in detail. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
