Network Working Group C. Vogt Internet-Draft Ericsson Intended status: Informational January 22, 2009 Expires: July 26, 2009 A Solution Space Analysis for First-Hop IP Source Address Validation draft-ietf-savi-rationale-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 26, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The IETF working group on Source Address Validation Improvements, SAVI, is chartered to design methods for IP source address validation Vogt Expires July 26, 2009 [Page 1] Internet-Draft SAVI Rationale January 2009 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. 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 Vogt Expires July 26, 2009 [Page 2] Internet-Draft SAVI Rationale January 2009 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 July 26, 2009 [Page 3] Internet-Draft SAVI Rationale January 2009 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 July 26, 2009 [Page 4] Internet-Draft SAVI Rationale January 2009 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 July 26, 2009 [Page 5] Internet-Draft SAVI Rationale January 2009 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 July 26, 2009 [Page 6]