idnits 2.17.1 draft-levy-abegnoli-savi-plbt-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 an Introduction section. ** 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 (March 8, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3972' on line 218 looks like a reference -- Missing reference section? 'RFC3971' on line 215 looks like a reference -- Missing reference section? 'RFC4861' on line 221 looks like a reference -- Missing reference section? 'RFC4862' on line 225 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Levy-Abegnoli 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track March 8, 2010 5 Expires: September 9, 2010 7 Preference Level based Binding Table 8 10 Abstract 12 Different documents [savi-fcfs] [savi-dhcp] [savi-send] propose 13 different preference schemes to resolve binding entry collisions 14 (same L3 address, different binding anchors) based of the address- 15 assignment method that they cover. For instance [fcfs] keeps the 16 first entry and rejects others. However, in heterogeneous 17 deployments, all address-assignment methods co-exist, and there is a 18 need for defining an algorithm that compare colliding entries across 19 these different methods (and any other method not covered) to pick up 20 a preferred one. This document describes one such algorithum. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 9, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Entry preference algorithm . . . . . . . . . . . . . . . . . . 3 64 2.1. Preference Level . . . . . . . . . . . . . . . . . . . . . 3 65 2.2. Entry update algorithm . . . . . . . . . . . . . . . . . . 5 66 3. Normative References . . . . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Contributors and Acknowledgments . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Problem Statement 72 The key stone for a savi switch to perform address-source validation 73 safely and efficiantly is how accurately it can learn about addresses 74 on the link, and establish their binding to the binding anchor. This 75 accuracy greatly depends on how well the switch deals with entry 76 collisions. 78 There are currently several documents [savi-dhcp] [savi-fcfs] [savi- 79 send] that describe the different methods for discovering bindings of 80 addresses active on the link. Each of these documents describes 81 separately how one particular discovery method deals with address 82 collisions. For instance [fcfs] proposes that the first binding 83 discovered for a given address prevail over subsequent ones. 84 However, no document describes how to handle binding collisions in an 85 heterogenous environment, with a mixt of DHCP-assigned, SLAC-assigned 86 and manually assigned addresses, discovered over a variety of 87 mechanisms (snooping, configuration), out of different type of ports 88 (access, trunk, trusted or untrusted) carrying different type or 89 credentials (including CGA). For example, for a given address, 90 discovered concurently by snooping NDP and by snooping DHCP, with 91 different bindings (different ports or different MACs), it is useful 92 to define which of these two should remain in the binding table, as 93 it will drive which traffic (from which MAC or on which port) will be 94 allowed, and which will be denied. The goal of the document is to 95 propose a method for dealing with the collisions in such heterogenous 96 environment. 98 2. Entry preference algorithm 100 2.1. Preference Level 102 We define the preference level (preflevel) as an attribute of an 103 entry in the binding table. It establishes the score of the entry in 104 terms of preference. It is computed at the time the entry is 105 discovered, by combining different factors related to the discovery. 106 These factors range from the method of learning (NDP snooping, DHCP 107 snooping, statically created), the type of port the entry is learnt 108 from (access port, trunk, trusted access or trusted port), the 109 credentials associated with the entry (CGA, etc.) and other criterias 110 to-be-defined. The preflevel is used to compare two candidate 111 entries (same l3 address, different binding anchors) in the binding 112 table. The higher the preference level is, the more preferred the 113 entry. 115 The different factors of preference are not all exclusive (some are). 116 For instance, an entry could be associated with CGA credentials, and 117 received from a trunk port at the same time. In theory, an CGA entry 118 could be learnt thru NDP or DHCP snooping or just be created 119 statically on the switch. To combine them in a fair algorithm, each 120 factor is given a number from 0 to n, ordered from smallest 121 contribution to biggest. The preference value corresponding to 122 factor p is defined as 2**p. The preference level is computed as a 123 sum of all relevant preference values. The goal of this encoding is 124 to ensure that for any factor q < i, the sum of preferences values of 125 q to i-1 is smaller than preference value of i. In other word, it is 126 not enough for an entry to accumulate all factors less important than 127 CGA credentials to beat an entry with just CGA credentials. And that 128 the same time, if preference factor p < q, a preference level of p + 129 i is smaller than one of q + i. In other words, to choose between an 130 NDP snooped CGA address and a DHCP snooped CGA address, the latter is 131 preferred. 133 A first series of factors to establish the preflevel are based upon 134 the method by which the entry is discovered. The following discovery 135 methods factors have been identified so far: 136 o DATA-SNOOPING: the entry is dicovered by snooping data packet, as 137 described in [savi-fcfs]> 138 o NDP-SNOOPING: the entry is dicovered by snooping NDP messages, as 139 described in [savi-fcfs]> 140 o DHCP-SNOOPING: the entry is dicovered by snooping DHCP messages, 141 as described in [savi-dhcp] 142 o STATIC: the entry is statically configured on the switch> 143 o LOCAL: the entry is one of the switch address 145 Another set of factors of an entry preflevel are based upon the port 146 the binding was learnt from. For example, an entry would have 147 different preflevels if it is learnt from: 148 o ACCESS_PORT: it typically attaches to end-nodes 149 o TRUNK_PORT: it attaches to a non savi-switch 150 o TRUSTED_ACCESS: it attaches to trusted end-nodes 151 o TRUSTED_TRUNK: it attaches to another savi-switch 153 Another set of factors of the preflevel are based on the credentials 154 associated with this learning. An entry associated with 155 cryptographic proof (CGA) should be preferred over the same entry 156 without this proof. Sometimes, an entry is discovered by snooping a 157 message that carries a link-layer address at layer3 and above. For 158 instance, an NDP message can contain the Link-Layer address as a SLLA 159 or TLLA option. A DHCP message can also carry the link-layer address 160 in the Client-Identifer option. In the cases where the MAC of the 161 source is both found as the source MAC of the message, and in the 162 payload of the message, it maybe be useful to prefer binding entries 163 carried in messages where these two values are identical. The 164 following credential factors have been identified: 166 o LLA_MAC_MATCH: LLA (found in NDP or DHCP option) and SMAC (found 167 at layer2) are identical; 168 o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] 169 o CERT_AUTHENTICATED: the entry is authenticated with a certificate 171 So far the following preflevel factors have been identified, from 172 lowest (0) to highest (10): 173 o NDP-SNOOPING: (0) the entry is dicovered by snooping NDP messages 174 o LLA_MAC_MATCH: (1) LLA (found in NDP or DHCP option) and MAC 175 (found at layer2) are identical 176 o TRUNK_PORT: (2) the entry was learnt from a trunk port (connected 177 to another switch) 178 o ACCESS_PORT: (3) the entry was leant from an access port 179 (connected to a host) 180 o TRUSTED_ACCESS: (4) The entry was learnt from a trusted port 181 o TRUSTED_TRUNK: (5) The entry was learnt from a trusted trunk 182 o DHCP_SNOOPING: (6) the entry is dicovered thru DHCP snooping 183 o CGA_AUTHENTICATED: (7) The entry is CGA authenticated, per 184 [RFC3972] 185 o CERT_AUTHENTICATED: (8) the entry is authenticated with a 186 certificate 187 o STATIC: (9) this is a statically configured entry 188 o LOCAL: (10) the address is one of the switch L3 address 190 Note that the absolute values behind each factor - 0 to 10 - don't 191 matter. Their relative position is essential. The values don't show 192 up outside the switch, and it is always possible to insert new 193 factors value in the sequence without breaking the algorithm. DATA- 194 SNOOPING has no value as it is not considered as being a contributor 195 to the preference level. 197 2.2. Entry update algorithm 199 Once an entry is installed in the binding table, its attributes 200 cannot be changed without complying with this "entry update 201 algorithm". 203 The algorithm is as follows, starting with rule_1, up to rule_6, in 204 that order until one rule is satisfied: Updating an entry attribute 205 if: 206 1. Allow, if no entry exist 207 2. Deny, if a more trusted entry exist 208 3. Allow if exsiting entry is less trusted 209 4. Allow, if received on a trusted port 210 5. Poll (DAD NS) existing entry and deny if response received 211 6. Allow 213 3. Normative References 215 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 216 Neighbor Discovery (SEND)", RFC 3971, March 2005. 218 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 219 RFC 3972, March 2005. 221 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 222 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 223 September 2007. 225 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 226 Address Autoconfiguration", RFC 4862, September 2007. 228 [savi-dhcp] 229 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 230 DHCPv4/v6", draft-ietf-savi-dhcp-01.txt I-D, Dec 2009. 232 [savi-fcfs] 233 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "First- 234 Come First-Serve Source-Address Validation 235 Implementation", draft-ietf-savi-fcfs-02 I-D, March 2009. 237 [savi-send] 238 Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- 239 Address Validation Implementation", 240 draft-ietf-savi-send-02 I-D, Oct 2009. 242 Appendix A. Contributors and Acknowledgments 244 This draft benefited from the input from: Pascal Thubert. 246 Author's Address 248 Eric Levy-Abegnoli 249 Cisco Systems 250 Village d'Entreprises Green Side - 400, Avenue Roumanille 251 Biot-Sophia Antipolis - 06410 252 France 254 Email: elevyabe@cisco.com