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]