Subject: [SAVA] Need your input: draft-sava-problem-statement-01

From: fergdawg at netzero.net (Fergie)
Date: Tue, 29 May 2007 07:18:12 GMT

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

---

From: bgreene at cisco.com (Barry Greene (bgreene))
Date: Tue, 29 May 2007 07:15:06 -0700

The general problem of supporting authenticity of source address in
   the Internet is divided into three separated sub-problems, referred
   as "First-hop, local subnet source validation", "Intra-AS
Communication
   of SAVA validation", and "Inter-AS Communication of SAVA validation."

This is not an accurate break out. 

-> You need tools to validate within the organization (what people are
calling subnet).

-> You need tools to validate when you cross organizational boundaries
where policy cannot be communicated (AS boundaries are too limiting).

-> You need tools to validate when you cross organizational boundaries
where policy can be communicated

-> You need ways to communicated the validation of trust through the
End-to-End system (beyond using IPSEC - which is the end-to-end system
of trust designed for the Internet).

> -----Original Message-----
> From: sava-bounces at nrc.tsinghua.edu.cn 
> [mailto:sava-bounces at nrc.tsinghua.edu.cn] On Behalf Of Fergie
> Sent: Tuesday, May 29, 2007 12:18 AM
> To: sava at nrc.tsinghua.edu.cn
> Subject: [SAVA] Need your input: draft-sava-problem-statement-01
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Okay, so I'm tired and cranky, but here's a rough cut of the 
> new problem statement.
> 
> PLEASE send comments ASAP so that we can get this thing 
> re-submitted this week, and begin to re-craft the framework draft.
> 
> We have a lot to do.
> 
> Thanks,
> 
> - - ferg
> 
> [snip]
> 
> Network Working Group                                       
> Paul Ferguson  
>  
> Internet-Draft                                              
> Trend Micro,
> Inc.
> Intended status: Experimental                               
> 31 May 2007 
> Expires: Novermber 30, 2007                                
>                                                         
>                                                         
>                                                          
>                                                        
> 
> 
>        Source Address Verification Architecture Problem Statement
>                     draft-sava-problem-statement-01
> 
> Status of this Memo
> 
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of 
> six months
>    and may be updated, replaced, or obsoleted by other 
> documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on November 30, 2007.
> 
> Copyright Notice
> 
>    Copyright (C) The IETF Trust (2007).
> 
> Abstract
> 
>    This document outlines the problems that the Source Address
>    Verification Architecture (SAVA) initiative plans to solve.  It
>    examines the current state in the internet, looks at current best
>    practices, and discusses why the current approaches are unlikely to
>    ever solve the problem of IP address spoofing.  It also discusses
>    some of the  problems that SAVA should NOT attempt to solve.
> 
> Requirements Language
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
> "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> 
> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . 
> . . . . . 3
>    2.  Current State of Affairs  . . . . . . . . . . . . . . 
> . . . . . 3
>    3.  Shortcomings of Best Current Practices  . . . . . . . 
> . . . . . 4
>    4.  Framework Requiremenmts/Discussion  . . . . . . . . . 
> . . . . . 4
>    5.  Scaling & Methodlogy . . . . . . . . . . . .  . . . . 
> . . . . . 5
>    6.  IANA Considerations . . . . . . . . . . . . . . . . . 
> . . . . . 5
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . 
> . . . . . 7
>    Intellectual Property and Copyright Statements  . . . . . 
> . . . . . 9
> 
> 
> 
> 
> 1.  Introduction
> 
>    As we all know, the Internet is a decentralized system 
> which basically
>    provides best effort, packet-based data forwarding service.  In the
>    forwarding process, intermediate devices (routers, switches, other
>    gateway devices, etc.) forwards IP packets based on the destination
>    IP address.
> 
>    This is how the Internet was designed to operate, and these are the
>    principle contraints that we must acknowledge in the 
> approach that SAVA
>    attempts to address.
> 
>    In virtaully all cases of processing traffic in the 
> Internet, the source
>    IP address is generally not validated as being genuine. It 
> is accepted as
>    being som simply because that it is written into the IP 
> header datagram.
> 
>    This is no longer acceptable as method of assuring the 
> validity of the
>    geneuine source of traffic, since it is trivial for any host in the
>    Internet to re-write this value, or simply misrepresent 
> itself as the
>    originator of traffic.
> 
>    This lack of source IP address validation makes it easy 
> for anyone to
>    spoof the originating IP host address, and has facilitated 
> many existing
>    historical (and current) instances of maliciousness (e.g. 
> hiding behind
>    spoofed IP source addresses, et al.).
> 
>    In recent years, there have been some efforts in the research
>    community to design mechanisms to expose efforts to which employ
>    IP source address spoofing -- plenty of instances of this 
> are readily
>    available.
> 
>    The motivation of this document is to clarify the problem 
> in solving
>    the spoofing of source address.
> 
>    The general problem of supporting authenticity of source address in
>    the Internet is divided into three seperated sub-problems, refered
>    as "First-hop, local subnet source validation", "Intra-AS 
> Communication
>    of SAVA validation", and "Inter-AS Communication of SAVA 
> validation."
> 
>    The primary difference between these three topological applications
>    details each issue and implementation is unique to the 
> place where it
>    is actually enabled.
> 
>    This problem statement attempts to illustrate why these 
> problems are
>    uniquely different, and why the SAVA framework, and 
> subsequent soutions,
>    must be implemented in such a fashion as to take into account the
>    placement of each function into the heierachy of the 
> Internet itself.
> 
> 
> 
> 2.  Current State of Affairs
> 
>    In the MIT Spoofer Project [Bev05], the authors found that
>    approximately one-quarter of the observed addresses, netblocks and
>    autonomous systems (AS) permit full or partial spoofing.  And they
>    suggested that a large portion of the Internet is vulnerable to
>    spoofing and concerted attacks employing spoofing remain a serious
>    concern.
> 
>    While this is by no means an authoritative measurement of the scope
>    of the problem, it does, however, illustrate the difficulty in 
>    measuring how deep this rabbit-hole actually goes.
> 
>    Commentary: There as much heated discussion, in various forums, on
>    the relative threat of spoofed IP host source addresses. Some of it
>    is valid, some invalid.
> 
>    One thing is for sure, however, andis still held true -- spoofed
>    IP host source address traffic still exists, for one 
> reason or another,
>    and still poses a conundrum insofar as validating the source of
>    maliciousness.
> 
> 
> 3.  Shortcomings of Best Current Practices
> 
>    While there are sverela BCPs in this area, the wide-spead adoption
>    of them remains elusive.
> 
>    There is only one Best Current Practice (BCP) published in the
>    IETF that deals with this issue, and there can be any number of
>    discussions on why it is not widely delpoyed (but that is a topic
>    for any number of other discussions):
> 
> 
>    Ingress Filtering, as described in BCP38 [RFC2827], descibes
>    a simple methodology for ISPs and any other Internet-facing
>    organisation to apply filters limiting the source addresses that
>    are allowed on to "source" packets into the Internet from a select
>    and predetermined set of prefixes.
>  
>    If BCP0038 were followed at all ingress points to the 
> Internet, then
>    there would be no spoofed packets on the Internet.
> 
>    One of the problem with BCP38 is that there is no measuareable or
>    incremental method to determine it's success -- either it 
> is deployed
>    globally, or else there is no way to determine it's effectiveness.
> 
>    What we attempt to do with SAVA, is to bring incremental benefit
>    to incremetal deployment of BCP38, as well as a way to meaure it's
>    global deployment and benefit.
> 
>  
> 
> 4.  Framework Requirements
> 
>    SAVA Architecural and WG framework disucssions will be 
> more completely
>    defined and addressed in the proposed workgroup charter and the
>    framework document.
> 
> 
> 
> 5.  Scaling & Methodology
> 
>    SAVA functionality solutions will be feasible for all network sizes
>    due to the manner in which we plan to dissect the 
> framework -- each of
>    the desired SAVA functionalities will be defined in 
> individual documents
>    that approximate their ability to perfoerm a specific 
> function relative
>    to their placement and function in the network heiracrhy:
> 
>    - First-hop, local-subnet source-address validation (and 
> enforcement);
>    - Intra-AS communication of SAVA validation;
>    - Inter-AS communication of SAVA validation.
> 
> 
> 6.  IANA Considerations
> 
>    This document makes no request of IANA.
> 
>    Note to RFC Editor: this section may be removed on 
> publication as an
>    RFC.
> 
> 
> 7.  Security Considerations
> 
>    For this document, no specific security considerations.  
> Many of the
>    solution elements will need to be examined carefully for robustness
>    and to see if they do not in themselves introduce security 
> problems.
> 
> 
> 8.  Acknowledgements
> 
>     Mark Williams <miw at juniper.net> & Jun Bi 
> <junbi at tsinghua.edu.cn> did
>     most of the footwork on the original version of this 
> draft, which I
>     have notoriosuly gutted.
> 
> 
> 9.  References
> 
> 
> 9.1.  Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
> 9.2.  Informative References
> 
>    [Bev05]    Beverley, S. and S. Bauer, ""The spoofer project:
>               inferring the extent of source address filtering on the
>               Internet", USENIX SRUTI 2005", 2005.
> 
>    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
>               Defeating Denial of Service Attacks which 
> employ IP Source
>               Address Spoofing", BCP 38, RFC 2827, May 2000.
> 
>    [RFC3871]  Jones, G., "Operational Security Requirements for Large
>               Internet Service Provider (ISP) IP Network
>               Infrastructure", RFC 3871, September 2004.
> 
> 
> Authors' Addresses
> 
>  
> Paul Ferguson
> Trend Micro, Inc.
> San Jose, California
> Paul_Ferguson at trendmicro.com
> +1.408.625.1068
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The IETF Trust (2007).
> 
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
> 
>    This document and the information contained herein are 
> provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
> REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 
> IETF TRUST AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 
> WARRANTIES, EXPRESS
>    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
> THE USE OF
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Intellectual Property
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be 
> claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  
> Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for 
> the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR 
> repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    ietf-ipr at ietf.org.
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
> 
> 
> 
> 
> [end]
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Desktop 9.6.1 (Build 1012)
> 
> wj8DBQFGW9Otq1pz9mNUZTMRAnIRAJ9e7/8aVWZpLb+sWfIWPIqSWUUaPACaAgFw
> ek+rFsWhVQY3UATp0/dQ78Q=
> =96Om
> -----END PGP SIGNATURE-----
> 
> 
> 
> --
> "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
>