Document Action: 'SAVA Testbed and Experiences to Date' to Experimental RFC

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf-announce