idnits 2.17.1 draft-ietf-savi-rationale-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2009) is 5574 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2827' is mentioned on line 68, but not defined == Missing Reference: 'BCP 38' is mentioned on line 68, but not defined Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Vogt 3 Internet-Draft Ericsson 4 Intended status: Informational January 22, 2009 5 Expires: July 26, 2009 7 A Solution Space Analysis for First-Hop IP Source Address Validation 8 draft-ietf-savi-rationale-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 The IETF working group on Source Address Validation Improvements, 48 SAVI, is chartered to design methods for IP source address validation 49 that complement ingress filtering with finer-grained protection. 50 This document summarizes the discussion in the SAVI working group and 51 design-related conclusions. The purpose of this is two-fold: First, 52 to guide the design process in the working group with written 53 documentation of decisions and their rationale. Second, to provide a 54 measure for assessing the IP source address validation methods that 55 the working group will eventually deliver. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Lower-Layer Binding Anchor . . . . . . . . . . . . . . . . . . 3 61 3. Packet Classification . . . . . . . . . . . . . . . . . . . . . 4 62 4. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 While ingress filtering [RFC 2827, BCP 38] provides a way to validate 69 IP source addresses at an aggregated level, there is not yet a 70 standardized mechanism for IP source address validation at a finer 71 granularity. Having a finer granularity would be helpful in a number 72 of situations, including filtering traffic from customer interfaces 73 implemented as ports in an IP-aware switch or a router, or general 74 improvements in filtering accuracy in enterprise networks. Depending 75 on the situation, there may be a requirement for blocking spoofed 76 packets or merely logging packets that appear to be spoofed. 78 Partial solutions exist to prevent hosts from spoofing the IP source 79 address of another host in the same IP link (e.g., the "IP source 80 guard"), but are proprietary. The purpose of the IETF working group 81 on Source Address Validation Improvements, SAVI, is to standardize 82 methods that prevent hosts attached to the same IP link from spoofing 83 each other's IP addresses. These methods are to complement ingress 84 filtering with finer-grained protection [TAXO]. 86 This document summarizes the discussion in the SAVI working group and 87 design-related conclusions. The purpose of this is two-fold: First, 88 to guide the design process in the working group with written 89 documentation of decisions and their rationale. Second, to provide a 90 measure for assessing the IP source address validation methods that 91 the working group will eventually deliver. 93 2. Lower-Layer Binding Anchor 95 Since the SAVI charter prohibits host changes, a SAVI device will 96 necessarily have to bind IP addresses to a property of layers below 97 IP. This is because, in the absence of host changes, properties of 98 lower layers are the only reasonably trustworthy information about a 99 packet sender that shows up in all packets. The question hence is 100 which lower-layer properties, or lower-layer "binding anchors", are 101 most appropriate for this purpose. Depending on the lower layers, 102 the available options are the following: 104 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 105 interface. 107 o The port on an Ethernet switch to which a host attaches. 109 o The security association between a host and the base station on 110 wireless links. 112 o The combination of a host interface's link-layer address and a 113 customer relationship in cable modem networks. 115 o An ATM virtual channel, a PPPoE session identifier, or an L2TP 116 session identifier in a DSL network. 118 o A tunnel that connects to a single host, such as an IP-in-IP 119 tunnel, a GRE tunnel, or an MPLS label-switched path. 121 The various options, of course, differ significantly in the scurity 122 they provide. IEEE extended unique identifiers, for example, fail to 123 render a secure binding anchor because they can be spoofed without 124 much effort. And switch ports alone may be insufficient because they 125 may connect to more than a single host, such as in the case of 126 concatenated switches. 128 One possible approach would be to define a set of possible binding 129 anchors, and leave it up to the administrator to choose one or more 130 of them. Such a selection of binding anchors would, of course, have 131 to be accompanied by an explanation of the pros and cons of the 132 different binding anchors. EIn addition, SAVI devices may have a 133 default binding anchor depending on the lower layers. Such a default 134 could be to use switch ports when available, and MAC addresses 135 otherwise. EOr to use MAC addresses, and switch ports in addition if 136 available. 138 3. Packet Classification 140 The prerequisite that a SAVI solution should be complementary to 141 ingress filtering, and not substitute it, implies that SAVI should 142 not validate packets that are forwarded by routers. This calls for a 143 method for SAVI to classify first-hop packets from forwarded packets 144 (where "first-hop packets" are transmitted by the originating host, 145 and "forwarded packets" are relayed by a router). Techniques to 146 achieve such packet classification can be divided into the following 147 classes: 149 1. Packets are classified based on whether or not their source 150 address is from an on-link subnet prefix. 152 2. Packets are classified based on whether or not the sending node 153 is an authorized router. 155 Both classes of packet classification techniques have pros and cons. 156 An advantage of class (1) is that the configuration of SAVI devices 157 with the necessary packet classification information is in many cases 158 simpler: SAVI devices that are colocated with a router have direct 159 access to on-link subnet prefixes because routers need to be aware of 160 the on-link subnet prefixes themselves. Furthermore, SAVI devices 161 can learn on-link subnet prefixes by listening to DHCP messages and, 162 in IPv6, to Router Advertisement messages. This enables auto- 163 configuration of SAVI devices that are implemented on a switch. With 164 class (2), similar auto-configuration is possible only with SeND 165 because a router can then be securely identified based on its 166 verifiable Router Advertisement messages. There is no way for a SAVI 167 device to automatically and securely identify a router if plain 168 Neighbor Discovery is used. Class (2) therefore requires pre- 169 configuration of SAVI devices with information about local routers if 170 plain Neighbor Discovery is used. 172 Of course, the auto-configuration of SAVI devices via DHCP messages 173 or Router Advertisement messages requires that the complete set of 174 on-link subnet prefixes is announced in these messages. It is 175 insufficient where DHCP is not used and no Router Advertisement 176 messages are sent, or where not all on-link subnet prefixes are 177 reveiled in DHCP messages or Router Advertisement messages. SAVI 178 devices then require additional sources for on-link subnet prefix 179 information. For example, on-link subnet prefixes that are manually 180 configured into hosts or routers have to be configured also into SAVI 181 devices. 183 On the other hand, a disadvantage of class (1) is that SAVI may 184 erroneously discard legitimate packets. This happens when a host 185 sends a packet to a neighbor via the local router instead of sending 186 it to the neighbor directly. The packet is then dropped when 187 forwarded by the local router because it is considered a first-hop 188 packet based on the subnet prefix of its source address. With class 189 (2), the SAVI device would not validate, and hence not drop, the 190 packet given that it is coming from the router. This issue with 191 class (1) can be mitigated if local routers use Redirect messages to 192 enforce direct neighbor-to-neighbor communications. 194 One conclusion from the above could be that class (2) should only be 195 used when SeND is available. And in such a case, class (1) could be 196 omitted. This would mean that, with plain Neighbor Discovery, class 197 (1) would be used exclusively. 199 4. Acknowledgment 201 This document is a resume of the discussions of the IETF working 202 group on Source Address Validation Improvements. The author would 203 therefore like to thank the working group members for their valuable 204 contributions, especially Marcelo Bagnulo, Fred Baker, Jun Bi, 205 Wojciech Dec, Paul Ferguson, David Miles, Erik Nordmark, Pekka 206 Savola, Dave Thaler, Guang Yao, Mark Williams, Jianping Wu, Dong 207 Zhang, and Lixia Zhang, in alphabetical order. 209 This document was generated using the xml2rfc tool. 211 5. Normative References 213 [TAXO] Vogt, C. and J. Arkko, "SAVI Design Taxonomy and Analysis", 214 July 2008. 216 Author's Address 218 Christian Vogt 219 Ericsson Research, NomadicLab 220 Office 551 221 Hirsalantie 11 222 02420 Jorvas 223 Finland 225 Email: christian.vogt@ericsson.com