idnits 2.17.1 draft-baker-savi-one-implementation-approach-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2010) is 5099 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-34) exists of draft-ietf-savi-dhcp-02 == Outdated reference: A later version (-14) exists of draft-ietf-savi-fcfs-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SAVI F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational May 10, 2010 5 Expires: November 11, 2010 7 An implementation approach to Source Address Validation 8 draft-baker-savi-one-implementation-approach-00 10 Abstract 12 This note is intended to flesh out a comment made on a mailing list. 13 It describes one of many possible implementation approaches to SAVI 14 systems, and is intended as much as anything to be an existence proof 15 that there is at least one that would work. 17 Requirements 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in [RFC2119]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 11, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. The purpose of SAVI . . . . . . . . . . . . . . . . . . . 3 59 1.2. Conceptual SAVI Switch Model . . . . . . . . . . . . . . . 3 60 2. Solutions for identifying valid bindings . . . . . . . . . . . 5 61 2.1. An implementation proposal . . . . . . . . . . . . . . . . 6 62 2.2. Implementation in a DHCP configuration . . . . . . . . . . 6 63 2.3. Implementation using Secure Neighbor Discovery . . . . . . 7 64 2.4. Implementation using Neighbor Discovery . . . . . . . . . 7 65 3. Extreme Cases . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This note is intended to flesh out a comment made on a mailing list. 77 It describes one of many possible implementation approaches to SAVI 78 systems, and is intended as much as anything to be an existence proof 79 that there is at least one that would work. The comment was: 81 Let me give you one potential implementation. Consider a switch 82 that for whatever reason is discarding datagrams from a given port 83 because they use an IPv6 source address that is not in its tables. 84 For various reasons, it very likely has a counter, on the switch 85 or VLAN if not on the port itself. It could also maintain a 86 register or FIFO to capture the source IPv6 and MAC addresses this 87 happened on. Without putting the logic for generating the request 88 into the data path, it becomes quite possible for a control plane 89 process to monitor that register and initiate DHCP queries to 90 verify the address and obtain the state from DHCP server. This 91 could be done at a controlled rate per port, to prevent what 92 amounts to a DOS multiplier in which a source address "scan" 93 results in a DHCP query assault on the server. 95 In the event that a switch restarts, that logic obviously happens 96 across the board. It can result in a burst comparable in size to 97 the number of ports on the switch in a short interval, but that is 98 not a continuing behavior. 100 1.1. The purpose of SAVI 102 Any discussion of an algorithm must start from a statement of what 103 problem it intends to solve. The purpose of this algorithm is to 104 ensure that, within the subnet in which it is implemented, any IPv6 105 source address used by a given Ethernet client is valid. It is valid 106 if it has been allocated in accordance with the algorithms in use for 107 the class of address on the subnet, and as a result is in use by 108 exactly one system. Ideally, the system also responds to it. 110 1.2. Conceptual SAVI Switch Model 112 As shown in Figure 1, a switch is a system with Ethernet ports and 113 uses [IEEE.802-1D.1993] Ethernet switching among those ports. Those 114 ports may support individual Ethernet clients (which may themselves 115 be hosts or IP routers, which require different handling by the 116 switch, as routers originate Ethernet datagrams with many IPv6 source 117 addresses while hosts use only their own), or may be trunks between 118 switches; in the latter case, a protocol such as IEEE Spanning Tree 119 is run to prevent bad things from happening. "Trunks between 120 switches" differ in scale. It is common to have a small (four or 121 eight) port switch on a desktop to facilitate wiring. A virtual host 122 may appear to be a small virtual switch with some number virtual 123 clients attached to it. Large switches are often deployed in tandem 124 to manage failure rates, and may connect hundreds to thousands of 125 clients. The connection between two switches is always a trunk. In 126 smaller cases it is rational to have the larger switch bind 127 associations to the combination of a port and a MAC address, while in 128 larger switches must depend on each other for source address 129 validation services for scalability. 131 There are two general kinds of filters in a typical switch: the "Port 132 Filter" and the "Forwarding Logic". A Port Filter applies policy to 133 the datagrams received on a port, usually to discard or only permit 134 selected datagrams. The Forwarding Logic identifies the set of ports 135 to which an Ethernet Frame from a given port will be forwarded. In 136 the forwarding logic, the specified set of ports may be null, a 137 single port, a larger set of ports, or all of them except the port 138 the datagram was received on. Background processes in a switch may 139 be attached to a virtual port, so that traffic to or from the CPU is 140 not a special case in its algorithms. 142 Any given implementation will of course vary in its internal 143 structure and characteristics. The port filter might literally use a 144 separate memory system per port, or might be the same database used 145 for forwarding applied in a different way, or might use some other 146 solution. The intention here is not to attempt to specify the 147 implementation, but to identify a conceptual framework in which 148 varying implementations can be described. 150 +-------------------+ 151 | Switch | 152 | | 153 | +------+ | 154 +----+ +----+ | Port | | 155 |Host|----|Port|----|Filter| | 156 +----+ +----+ +------+ | 157 | | | 158 +-----+ +----+ +----------+| 159 |Else-|---|Port|--|Forwarding|| 160 |Where| +----+ | Logic || 161 +-----+ | +----------+| 162 +-------------------+ 164 Figure 1: Ethernet Switch Data Plane 166 The Port Filter is primarily in view in the SAVI model. A SAVI 167 implementation configures the Port Filter to 168 1. Identify IPv6 [RFC2460] datagrams, 170 2. Isolate their binding values, which are generally some subset of 171 their port, MAC Address, and IPv6 Source Address, 173 3. Accept IPv6 datagrams matching one of a list of specified 174 bindings, and 176 4. Discard all other IPv6 datagrams. 178 The discussion in SAVI has primarily related to the binding 179 relationships among interfaces and addresses that are 181 o Statically configured, 183 o Derived from Stateless Address Autoconfiguration 184 [RFC4862][RFC4941], or 186 o Assigned via DHCPv6 [RFC3315]. 188 2. Solutions for identifying valid bindings 190 Several proposals have been put forward as means to identify valid 191 switch bindings. The major ones depend on either 193 o An external reference, such as a DHCPv6 [RFC3315] server, 194 assigning valid bindings as specified in [I-D.ietf-savi-dhcp], or 196 o Individual clients using Stateless Address Autoconfiguration 197 [RFC4862][RFC4941] correctly, as specified in 198 [I-D.bi-savi-stateless]. 200 A simpler approach was suggested in [I-D.ietf-savi-fcfs], in which 201 the first user of an address is deemed to be its "owner" for the 202 foreseeable future. This suffers two security defects: the use of an 203 address does not imply that the address has been allocated by any 204 given algorithm (it may indeed have been statically assigned or be 205 generated at a high rate during an attack), and does not imply that 206 there are no others that validly lay claim to it. 208 We in short come down to the relative merits of using either the 209 control plane to detect and make inferences from control plane (DHCP 210 or SLAAC DAD) behavior and behavior in the data plane that simply 211 learns addresses as their are used, comparable to their learning and 212 use in IEEE 802.1D. 214 2.1. An implementation proposal 216 It is reasonable to expect that the forwarding logic, which is often 217 implemented in hardware or microcode, does not attempt to manage its 218 tables in real time. Instead, it has some defined interface - 219 perhaps a register or queue - to a control plane process. In normal 220 operation, the forwarding and filtering tables require no 221 modification; the port filter and forwarding logic refer to them, and 222 the datagram is handled accordingly. However, in exception cases, 223 the datagram or relevant information from it is queued to the control 224 plane for further analysis. 226 +-----------------------------------+ 227 | Switch | 228 | | 229 | +------+ +----------+| 230 +----+ +----+ | Port | | Table || 231 |Host|----|Port|----|Filter|--||--|Management|| 232 +----+ +----+ +------+ | Process || 233 | | +----------+| 234 +-----+ +----+ +----------+ | 235 |Else-|---|Port|--|Forwarding| | 236 |Where| +----+ | Logic | | 237 +-----+ | +----------+ | 238 +-----------------------------------+ 240 Figure 2: Switch Data and Control Planes 242 As shown in Figure 2, I suggest that this might be extended to 243 include information about failures of SAVI-relevant port filter 244 entries. If the SAVI Port Filter terms all fail to match (e.g., the 245 logic in Section 1.2 determines that case 4 applies), the datagram is 246 discarded, but a request is queued to the Table Management Process to 247 determine whether a new SAVI term needs to be added to the relevant 248 Port Filter. The process executes an appropriate procedure, and in 249 the event of an affirmative outcome updates the Port Filter to accept 250 the new binding. When the client retransmits the datagram, it passes 251 through. 253 2.2. Implementation in a DHCP configuration 255 In a network using DHCPv6 [RFC3315], we have the luxury of an 256 authoritative information source. Correct implementation depends 257 only on deriving information from it. This requires two components: 259 1. The forwarding logic MUST be configured to identify DHCP 260 datagrams and send copies to the Table Management Process. If 261 the switch observes a datagram from the DHCP server authorizing a 262 binding between a port, a MAC Address, and an IPv6 Source 263 Address, the binding is stored in the Port Filter for the 264 relevant port. 266 2. When a client is observed using an IPv6 source address that fails 267 the binding test, the Table Management Process MAY construct a 268 DHCPv6 Request that appears to be from the client enquiring about 269 the address. The DHCP server will likely respond to the 270 datagram; if it responds in the affirmative, the action in bullet 271 1 will record the authorization. 273 The switch MAY also apply a policy to detect and mitigate attacks, 274 such as rate limiting the number of new source addresses used on a 275 port per unit time. 277 2.3. Implementation using Secure Neighbor Discovery 279 In a network using SEcure Neighbor Discovery [RFC3971], we have the 280 luxury of an authoritative exchange. Correct implementation depends 281 on deriving information from it. This requires two components: 283 1. The forwarding logic MUST be configured to identify SeND messages 284 and send copies to the Table Management Process. If the switch 285 observes a SeND Response demonstrating the necessary credentials 286 to authorize a binding between a port, a MAC Address, and an IPv6 287 Source Address, the binding is stored in the Port Filter for the 288 relevant port. 290 2. When a client is observed using an IPv6 source address that fails 291 the binding test, the Table Management Process MAY construct a 292 Secure Neighbor Solicitation for the address. The relevant 293 client will likely respond to the datagram; the action in bullet 294 1 will record the authorization. 296 The switch MAY also apply a policy to detect and mitigate attacks, 297 such as rate limiting the number of new source addresses used on a 298 port per unit time. 300 2.4. Implementation using Neighbor Discovery 302 In a network in which there is no authoritative information source, 303 correct implementation depends on observing the correct 304 implementation of Neighbor Discovery [RFC4861] and Address 305 Autoconfiguration [RFC4862]. 307 When a client is observed using an IPv6 source address that fails the 308 binding test, the Table Management Process SHOULD initiate a 309 multicast Neighbor Solicitation to find the client using its source 310 address. One of three things will happen: 312 1. There will be no Neighbor Advertisement in response, 314 2. There will be one or more Neighbor Advertisement responses, at 315 least one of which is from some other client, or 317 3. There will be exactly one Neighbor Advertisement response, from 318 the indicated client. 320 The first case is characteristic of some attack scenarios (the source 321 is simply generating addresses and using them), and of the Duplicate 322 Address Detection phase of Address Autoconfiguration. It is an 323 address that should not be seen at this point as a source address. 324 The second case is also characteristic of some attack scenarios; a 325 program is directly spoofing the address of another system. In these 326 cases, the Table Manager MUST NOT configure the binding into the Port 327 Filter authorizing the use by this client. The third case, on the 328 other hand, is exactly what any client correctly implementing 329 [RFC4861] would expect to see in Neighbor Discovery. The switch 330 stores the binding indicated by the response - which may be from the 331 indicated client or a different one. 333 The switch MAY also apply a policy that would detect and mitigate 334 other attacks, such as rate limiting the number of new source 335 addresses validated on a port per unit time. 337 3. Extreme Cases 339 Discussion on the list has suggested a variety of solutions to 340 extreme cases, notably saving tables in nonvolatile memory to handle 341 extreme failures. In my opinion, this is ill-advised and 342 unnecessary. 344 DHCP-assigned addresses, which have a lifetime, and SLAAC-assigned 345 addresses (especially private ones, but also addresses derived from 346 the MAC Address), which are flushed when an interface is 347 disconnected, are examples of ephemeral information in a network. 348 The storage of ephemeral information in permanent storage, such as 349 nonvolatile memory, has the effect of making a switch that has 350 rebooted attempt to enforce rules that may no longer apply; if they 351 do still apply, their validity derives from the assent of the 352 authority. Verification with the authority is therefore always 353 sufficient to validate an address. 355 Such actions are also unnecessary. In the event of the reboot of a 356 switch in a large Ethernet, all of its clients will follow SLAAC 357 procedures or issue DHCP requests to obtain their addresses, or the 358 port failure will be masked from them by desktop switches and they 359 will continue using preexisting addresses. For a short interval, 360 both client address management and switch address validation as 361 described in Section 2.1 can result in a high rate of control plane 362 traffic. However, it is limited in two ways: it is only carried out 363 on behalf of the clients of the switch, which are a finite number, 364 and each such transaction requires at most a limited interval. When 365 the reboot has completed and the initial burst passed, matters will 366 return to their normal state. 368 Since non-volatile memory has a cost and is unnecessary, storage of 369 ephemeral information in non-volatile memory is ill-advised. 371 4. IANA Considerations 373 This memo asks the IANA for no new parameters. 375 Note to RFC Editor: This section will have served its purpose if it 376 correctly tells IANA that no new assignments or registries are 377 required, or if those assignments or registries are created during 378 the RFC publication process. From the author"s perspective, it may 379 therefore be removed upon publication as an RFC at the RFC Editor"s 380 discretion. 382 5. Security Considerations 384 Several comments about security have been made in this document, but 385 it has not been subjected to a thorough security analysis. 387 As noted in Section 2, the data-plane-only approach suggested in 388 [I-D.ietf-savi-fcfs], in which the first user of an address is deemed 389 to be its "owner" for the foreseeable future, suffers two security 390 defects: the use of an address does not imply that the address has 391 been allocated in accordance with SLAAC, and does not imply that 392 there are no others that validly lay claim to it. 394 The Neighbor Discovery model discussed in Section 2.4 is not secure. 395 That is why SeND exists. However, it can detect cases in which an 396 address has no active users or multiple users, which serves the 397 present purpose. 399 The approach suggested in Section 2.1 is based on the supposition 400 that the client has followed whatever rules apply in the network for 401 allocating addresses. The fact cannot, however, be proven; the only 402 thing that can be proven is that the result is consistent with it 403 having done so. 405 6. Acknowledgements 407 This note was requested by the working group chairs. It has been 408 reviewed by Joel Halpern, to whom Section 3 responds. 410 7. References 412 7.1. Normative References 414 [IEEE.802-1D.1993] 415 Institute of Electrical and Electronics Engineers, 416 "Information technology - Telecommunications and 417 information exchange between systems - Local area networks 418 - Media access control (MAC) bridges", IEEE Standard 419 802.1D, July 1993. 421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 422 Requirement Levels", BCP 14, RFC 2119, March 1997. 424 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 425 (IPv6) Specification", RFC 2460, December 1998. 427 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 428 and M. Carney, "Dynamic Host Configuration Protocol for 429 IPv6 (DHCPv6)", RFC 3315, July 2003. 431 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 432 Neighbor Discovery (SEND)", RFC 3971, March 2005. 434 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 435 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 436 September 2007. 438 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 439 Address Autoconfiguration", RFC 4862, September 2007. 441 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 442 Extensions for Stateless Address Autoconfiguration in 443 IPv6", RFC 4941, September 2007. 445 7.2. Informative References 447 [I-D.bi-savi-stateless] 448 Bi, J., Yao, G., Wu, J., and F. Baker, "SAVI Solution for 449 Stateless Address", draft-bi-savi-stateless-00 (work in 450 progress), April 2010. 452 [I-D.ietf-savi-dhcp] 453 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 454 DHCP", draft-ietf-savi-dhcp-02 (work in progress), 455 April 2010. 457 [I-D.ietf-savi-fcfs] 458 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 459 SAVI: First-Come First-Serve Source-Address Validation for 460 Locally Assigned Addresses", draft-ietf-savi-fcfs-02 (work 461 in progress), October 2009. 463 Author's Address 465 Fred Baker 466 Cisco Systems 467 Santa Barbara, California 93117 468 USA 470 Email: fred@cisco.com