[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-savi-rationale

Network Working Group                                            C. Vogt
Internet-Draft                                                  Ericsson
Expires:  May 16, 2009                                 November 12, 2008


  A Solution Space Analysis for First-Hop IP Source Address Validation
                    draft-vogt-savi-rationale-00.txt

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 May 16, 2009.

Abstract

   The IETF working group on Source Address Validation Improvements,
   SAVI, is chartered to design methods for IP source address validation
   that complement ingress filtering with finer-grained protection.
   This document summarizes the discussion in the SAVI working group and
   design-related conclusions.  The purpose of this is two-fold:  First,
   to guide the design process in the working group with written
   documentation of decisions and their rationale.  Second, to provide a
   measure for assessing the IP source address validation methods that
   the working group will eventually deliver.







Vogt                      Expires May 16, 2009                  [Page 1]


Internet-Draft               SAVI Rationale                November 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Lower-Layer Binding Anchor  . . . . . . . . . . . . . . . . . . 3
   3.  Packet Classification . . . . . . . . . . . . . . . . . . . . . 4
   4.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7










































Vogt                      Expires May 16, 2009                  [Page 2]


Internet-Draft               SAVI Rationale                November 2008


1.  Introduction

   While ingress filtering [RFC 2827, BCP 38] provides a way to validate
   IP source addresses at an aggregated level, there is not yet a
   standardized mechanism for IP source address validation at a finer
   granularity.  Having a finer granularity would be helpful in a number
   of situations, including filtering traffic from customer interfaces
   implemented as ports in an IP-aware switch or a router, or general
   improvements in filtering accuracy in enterprise networks.  Depending
   on the situation, there may be a requirement for blocking spoofed
   packets or merely logging packets that appear to be spoofed.

   Partial solutions exist to prevent hosts from spoofing the IP source
   address of another host in the same IP link (e.g., the "IP source
   guard"), but are proprietary.  The purpose of the IETF working group
   on Source Address Validation Improvements, SAVI, is to standardize
   methods that prevent hosts attached to the same IP link from spoofing
   each other's IP addresses.  These methods are to complement ingress
   filtering with finer-grained protection [TAXO].

   This document summarizes the discussion in the SAVI working group and
   design-related conclusions.  The purpose of this is two-fold:  First,
   to guide the design process in the working group with written
   documentation of decisions and their rationale.  Second, to provide a
   measure for assessing the IP source address validation methods that
   the working group will eventually deliver.


2.  Lower-Layer Binding Anchor

   Since the SAVI charter prohibits host changes, a SAVI device will
   necessarily have to bind IP addresses to a property of layers below
   IP.  This is because, in the absence of host changes, properties of
   lower layers are the only reasonably trustworthy information about a
   packet sender that shows up in all packets.  The question hence is
   which lower-layer properties, or lower-layer "binding anchors", are
   most appropriate for this purpose.  Depending on the lower layers,
   the available options are the following:

   o  The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's
      interface.

   o  The port on an Ethernet switch to which a host attaches.

   o  The security association between a host and the base station on
      wireless links.





Vogt                      Expires May 16, 2009                  [Page 3]


Internet-Draft               SAVI Rationale                November 2008


   o  The combination of a host interface's link-layer address and a
      customer relationship in cable modem networks.

   o  An ATM virtual channel, a PPPoE session identifier, or an L2TP
      session identifier in a DSL network.

   o  A tunnel that connects to a single host, such as an IP-in-IP
      tunnel, a GRE tunnel, or an MPLS label-switched path.

   The various options, of course, differ significantly in the scurity
   they provide.  IEEE extended unique identifiers, for example, fail to
   render a secure binding anchor because they can be spoofed without
   much effort.  And switch ports alone may be insufficient because they
   may connect to more than a single host, such as in the case of
   concatenated switches.

   One possible approach would be to define a set of possible binding
   anchors, and leave it up to the administrator to choose one or more
   of them.  Such a selection of binding anchors would, of course, have
   to be accompanied by an explanation of the pros and cons of the
   different binding anchors.  EIn addition, SAVI devices may have a
   default binding anchor depending on the lower layers.  Such a default
   could be to use switch ports when available, and MAC addresses
   otherwise.  EOr to use MAC addresses, and switch ports in addition if
   available.


3.  Packet Classification

   The prerequisite that a SAVI solution should be complementary to
   ingress filtering, and not substitute it, implies that SAVI should
   not validate packets that are forwarded by routers.  This calls for a
   method for SAVI to classify first-hop packets from forwarded packets
   (where "first-hop packets" are transmitted by the originating host,
   and "forwarded packets" are relayed by a router).  Techniques to
   achieve such packet classification can be divided into the following
   classes:

   1.  Packets are classified based on whether or not their source
       address is from an on-link subnet prefix.

   2.  Packets are classified based on whether or not the sending node
       is an authorized router.

   Both classes of packet classification techniques have pros and cons.
   An advantage of class (1) is that the configuration of SAVI devices
   with the necessary packet classification information is in many cases
   simpler:  SAVI devices that are colocated with a router have direct



Vogt                      Expires May 16, 2009                  [Page 4]


Internet-Draft               SAVI Rationale                November 2008


   access to on-link subnet prefixes because routers need to be aware of
   the on-link subnet prefixes themselves.  Furthermore, SAVI devices
   can learn on-link subnet prefixes by listening to DHCP messages and,
   in IPv6, to Router Advertisement messages.  This enables auto-
   configuration of SAVI devices that are implemented on a switch.  With
   class (2), similar auto-configuration is possible only with SeND
   because a router can then be securely identified based on its
   verifiable Router Advertisement messages.  There is no way for a SAVI
   device to automatically and securely identify a router if plain
   Neighbor Discovery is used.  Class (2) therefore requires pre-
   configuration of SAVI devices with information about local routers if
   plain Neighbor Discovery is used.

   Of course, the auto-configuration of SAVI devices via DHCP messages
   or Router Advertisement messages requires that the complete set of
   on-link subnet prefixes is announced in these messages.  It is
   insufficient where DHCP is not used and no Router Advertisement
   messages are sent, or where not all on-link subnet prefixes are
   reveiled in DHCP messages or Router Advertisement messages.  SAVI
   devices then require additional sources for on-link subnet prefix
   information.  For example, on-link subnet prefixes that are manually
   configured into hosts or routers have to be configured also into SAVI
   devices.

   On the other hand, a disadvantage of class (1) is that SAVI may
   erroneously discard legitimate packets.  This happens when a host
   sends a packet to a neighbor via the local router instead of sending
   it to the neighbor directly.  The packet is then dropped when
   forwarded by the local router because it is considered a first-hop
   packet based on the subnet prefix of its source address.  With class
   (2), the SAVI device would not validate, and hence not drop, the
   packet given that it is coming from the router.  This issue with
   class (1) can be mitigated if local routers use Redirect messages to
   enforce direct neighbor-to-neighbor communications.

   One conclusion from the above could be that class (2) should only be
   used when SeND is available.  And in such a case, class (1) could be
   omitted.  This would mean that, with plain Neighbor Discovery, class
   (1) would be used exclusively.


4.  Acknowledgment

   This document is a resume of the discussions of the IETF working
   group on Source Address Validation Improvements.  The author would
   therefore like to thank the working group members for their valuable
   contributions, especially Marcelo Bagnulo, Fred Baker, Jun Bi,
   Wojciech Dec, Paul Ferguson, David Miles, Erik Nordmark, Pekka



Vogt                      Expires May 16, 2009                  [Page 5]


Internet-Draft               SAVI Rationale                November 2008


   Savola, Dave Thaler, Guang Yao, Mark Williams, Jianping Wu, Dong
   Zhang, and Lixia Zhang, in alphabetical order.

   This document was generated using the xml2rfc tool.


5.  Normative References

   [TAXO]  Vogt, C. and J. Arkko, "SAVI Design Taxonomy and Analysis",
           July 2008.


Author's Address

   Christian Vogt
   Ericsson Research, NomadicLab
   Office 551
   Hirsalantie 11
   02420 Jorvas
   Finland

   Email:  christian.vogt@ericsson.com





























Vogt                      Expires May 16, 2009                  [Page 6]


Internet-Draft               SAVI Rationale                November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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@ietf.org.











Vogt                      Expires May 16, 2009                  [Page 7]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/