Network Working Group E. Levy-Abegnoli Internet-Draft Cisco Systems Intended status: Standards Track August 4, 2009 Expires: February 5, 2010 Preference Level based Binding Table 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 February 5, 2010. 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract [fcfs] proposes a simple preference scheme to resolve binding entry collisions (same l3 address, different anchors): it keeps the first entry and rejects any others. However, there are cases where keeping Levy-Abegnoli Expires February 5, 2010 [Page 1] Internet-Draft Preference Level based Binding Table August 2009 the first entry is not the best choice, and others cases where it is bogus. This draft analyses what are these cases, and proposes a different algorithm (preference based) to fix the problem. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2. Binding entry completion . . . . . . . . . . . . . . . . . . . 4 3. Link-Layer Address anchor . . . . . . . . . . . . . . . . . . . 4 4. Entry preference algorithm . . . . . . . . . . . . . . . . . . 5 4.1. Preference Level . . . . . . . . . . . . . . . . . . . . . 5 4.2. Entry update algorithm . . . . . . . . . . . . . . . . . . 6 4.3. Switch port configuration . . . . . . . . . . . . . . . . . 7 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Contributors and Acknowledgments . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Levy-Abegnoli Expires February 5, 2010 [Page 2] Internet-Draft Preference Level based Binding Table August 2009 1. Problem Statement In the general case, when two nodes A and B compete for the same L3 address, the first one (A) to perform DAD sucessfully is the one that should "own" it. [RFC4862] enforces that behavior by enabling A to defend its address through the DAD procedure. Once A has succesfully completed DAD, if B wishes to use A's address, it is expected to run DAD and it will get a DAD response from A. At this stage, it should give up on the address. If B does not give up, it is faulty, and a third party device such as a savi-switch is entitled to drop its traffic. From there, [fcfs] proposes to install A's binding (L3 address/A's anchor) into the binding table, and drop traffic sent by B, sourced with the same L3 address. While this is working in the general case, there are some scenarios where the first node to present a binding on the link is not the one that should ultimately owns it. A simple example is the one of SeND nodes. Consider the case of a link with a mix of ND (RFC4861] and SeND (RFC3971] nodes. Consider node A running ND, node B and node C running SeND. Node A is malicious and knows about B's CGA address "b". It can also easily compute "b'", which is B secondary address, derived from the same RSA public key, with a colision count of 1. Assuming b and b' has not made it into the switch binding table yet (nodes are down), node A could advertizes b and b', without any CGA credentials, either by sourcing data packets or by DAD'ing them. Node A could also listen and respond to DAD messages sent by B. In either scenarios, According to [RFC3971], B is the legitimate owner of b', and C, as a SeND node, must consider it that way and bind b' to B's link-layer address. However, a savi-switch implementing [fcfs] will pick up A as the owner of b and b'. B's packets will be filtered out, and C will only see A's claim and trust A as the legitimate owner, without a chance to make a different better choice. In the absence of a savi-switch, a better more secure situation would be established with B and C ignoring A's claims on b' if not on b. It appears that on a link with a mix of nodes supporting ND and nodes supporting SeND, a switch using a first-come-first-serve algorithm will break SeND and endup decreasing the security rather than augmenting it. SeND mandates a different algorithm that first-come- first-serve, so should do the savi-switch. It is possible to generalize and consider that it is sometimes desirable for the switch to pick up an address owner which is not the first one presenting the binding. It can be because it is a CGA Levy-Abegnoli Expires February 5, 2010 [Page 3] Internet-Draft Preference Level based Binding Table August 2009 address, or the address is one of a trusted server, or the address was assigned by DHCP. This draft proposes an algorithm based on the computation of a preference level, to choose between two competing binding entries. 2. Binding entry completion In order to learn about CGA credentials associated with a binding candidate, the switch needs to read these credential out of an NDP message. Therefore, a data packet should not be used to complete the binding entry, but only as a hint that it should seek for completion. Upon receiving a data packet carrying a source address not seen before, the switch should issue a DAD packet on the link (all ports of the vlan), including the one from which the data packet was received. The address owner is expected to respond with an NA, carrying CGA credentials if any. Upon receiving this response, the switch can complete the binding entry and start forwarding traffic from the source. 3. Link-Layer Address anchor So far, there has been several possible binding anchors listed, and one of them was the MAC address. However, it was not specified whether the MAC address was the one found at layer 2 (SMAC), or the link-layer-address (LLA) announced by NDP. It is important to note that these two are not always the same, and some tools uses that difference to play some game on the link. For instance, a node B could act as a binding-server, on behalf of nodes (S1, S2) within a server-farm, vis-as-vis clients on the link. B would announce, with its own SMAC and source, S1 or S2 link-layer address, associated with the anycast server-fam address, based on server load or other criterias. Another scenario is the one of an attacker A, poisoning nodes neighbor cache, by sending NDP NA messages with SMAC=MAC_A, L3-src=A, target=B and LLA option=MAC_A. Such message carries two bindings, first one [A, MAC_A], and a second one [B, MAC_A]. While the first one may be legitimate, the second may not be (an entry [B, MAC_B] could exist in the switch binding table. Such message could easily redirect all traffic (for B) to A. In the two scenarios considered above, the savi switch would have some need to analyse the content of the NDP message, up to the link- layer-address option, rather than only look at the message envelope (SMAC/IP-src). Only some NDP messages are carrying this option: NS (but not DAD), NA, RS, RA. Note that neither DAD packets nor data Levy-Abegnoli Expires February 5, 2010 [Page 4] Internet-Draft Preference Level based Binding Table August 2009 packets have the information needed. A scheme where the switch would issue a DAD NS upon receiving a data packet or a DAD message (with a delay to avoid DAD failure) would be useful to obtain an NA from the address owner, with the LLA option. This is yet another reason to "complete" the binding on NDP messages rather than on data packet. 4. Entry preference algorithm 4.1. Preference Level The preference level (preflevel) is an attribute of an entry in the binding table. It is setup when the entry is learnt, based on where it is learnt from, the credentials associated with it and other criterias to-be-defined. The preflevel is used to arbitrage between two candidate entries (same l3 address) in the binding table. The higher the preference level is, the more preferred the entry. One of the key factor of an entry preflevel is the port the binding was learnt from. For example, an entry would have different preflevels if it is learnt from: o An access port: it typically attaches to end-nodes o A trunk port: it attaches to a non savi-switch o A trusted access port: it attaches to trusted end-nodes o A trusted trunk: it attaches to another savi-switch A second factor of the preflevel is the credentials associated with this learning. An entry associated with cryptographic proof (CGA) should be preferred over the same entry without this proof. In Section 3, it was highlighted that the source mac (SMAC) and the link-layer address (LLA) found in the same NDP message could be different. It maybe be useful to prefer binding entries carried in messages where the SMAC and the LLA are identical. Binding entries can be learnt from various procotol, whether NDP, DHCP or statically assigned. It is useful to define a preference order within thse various source of binding. Each factor of the binding preference level is given a value and referred to as preference value. For instance, a binding associated with CGA credential would be given a value "CGA_AUTHENTICATED". A binding received from a trusted access port would be given "TRUSTED_ACCESS". The different preference values are not all exclusive (some are). For instance, an entry could be associated with CGA credentials, and received from a trunk port at the same time. It could -or not- Levy-Abegnoli Expires February 5, 2010 [Page 5] Internet-Draft Preference Level based Binding Table August 2009 verify SMAC=LLA. So we define the preference level of an entry as a sum of preference values. Preference values are flags, encoded as 2**n where n in the no of the flag. The higher n, the more prevalent is the value. The preference level of an entry the sum of all preference values that apply to it. The goal of this encoding is to ensure that the sum of preferences values 1 to N-1 is smaller than preference N. And that the same time, if preference values P < Q, a preference level of P + N is bigger than one of Q + N. The following preflevel values have been identified (from lowest to highest): o LLA_MAC_MATCH: LLA (found in NDP option) and MAC (found at layer2) are identical; o TRUNK_PORT: the entry was learnt from a trunk port (connected to another switch) o ACCESS_PORT: the entry was leant from an access port (connected to a host) o TRUSTED_ACCESS: The entry was learnt from a trusted port o TRUSTED_TRUNK: The entry was learnt from a trusted trunk o DHCP_ASSIGNED: the entry is assigned by DHCP o CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] o CERT_AUTHENTICATED: the entry is authenticated with a certificate o STATIC: this is a statically configured entry per [RFC3971]. Here are some examples of preference levels: o An entry learnt from a trunk port with SMAC matching LLA would have a preflevel TRUNK_PORT+LLA_MAC_MATCH bigger than one simply matching lla/mac (LLA_MAC_MATCH). o However an entry learnt from an access port with matching mac/lla would have a smaller preflevel than an entry learnt from a trusted port. 4.2. Entry update algorithm Once an entry is installed in the binding table, its attributes cannot be changed without complying with this "entry update algorithm". The algorithm is as follows, starting with rule_1, up to rule_5, in that order until one rule is satisfied: Updating an entry attribute is: 1. Allowed when the preflevel carried by the change is bigger than the preflevel stored in the entry. 2. Denied if the preflevel carried by the change is smaller than the preflevel stored in the entry 3. Allowed if preflevel >= TRUSTED_PORT Levy-Abegnoli Expires February 5, 2010 [Page 6] Internet-Draft Preference Level based Binding Table August 2009 4. Denied is the entry is in state REACHABLE (and preflevel are equal) 5. Allowed otherwise Entry state is a useful part of the preference algorithm. Three states have been identified: INCOMPLETE, REACHABLE and STALE. An entry is INCOMPLETE when the entry has not been verified thru an NDP (NS/NA) exchange. For instance, upon receiving a data packet, the switch will issue a DAD NS and wait for an NA. Before receiving the NA, the entry is IMCOMPLETE. Then it moves to REACHABLE. Then to STALE unless the binding is confirmed by more NDP traffic. The switch may, by policy, deny binding completion for an entry in state INCOMPLETE if the change is not associated with the port where this entry was first learnt from. This will eventually break DAD, but will provide some mitigation against DAD attacks. By default, the switch should listen to DAD response coming from any port. For movement, if an entry is in REACHABLE, it means it was seen recently in its known location, and any binding takeover is considered as an attack. However, If the binding takeover is received from a trusted port, it should be allowed, regardless of the entry state. 4.3. Switch port configuration Qualifying a port of the switch is of primary importance to influence the "entry update algorithm" (see Section 4). The switch configuration should allow the following values to be configured on a per-port basis: o TRUNK_PORT: the port of the switch is connected to another switch port, that is not a plb-switch. o ACCESS_PORT: the port of the switch is connect to an end-node. o TRUSTED_PORT: the port of the switch is connected to a trusted end-node. o TRUSTED_TRUNK: the port of the switch is connected to another plb- switch. 5. Normative References [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, Levy-Abegnoli Expires February 5, 2010 [Page 7] Internet-Draft Preference Level based Binding Table August 2009 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [fcfs] Nordmark, E. and M. Bagnulo, "First-Come First-Serve Source-Address Validation Implementation", draft-ietf-savi-fcfs-01 I-D, March 2009. Appendix A. Contributors and Acknowledgments This draft benefited from the input from: Pascal Thubert. Author's Address Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot-Sophia Antipolis - 06410 France Email: elevyabe@cisco.com Levy-Abegnoli Expires February 5, 2010 [Page 8]