Preference Level based Binding Table

Abstract

Different documents [savi-fcfs] [savi-dhcp] [savi-send] propose different preference schemes to resolve binding entry collisions (same L3 address, different binding anchors) based of the address-assignment method that they cover. For instance [fcfs] keeps the first entry and rejects others. However, in heterogeneous deployments, all address-assignment methods co-exist, and there is a need for defining an algorithm that compare colliding entries across these different methods (and any other method not covered) to pick up a preferred one. This document describes one such algorithùm.

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 September 9, 2010.

Copyright Notice

Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Problem Statement
2.  Entry preference algorithm
    2.1.  Preference Level
    2.2.  Entry update algorithm
3.  Normative References
Appendix A.  Contributors and Acknowledgments
§  Author's Address

1.  Problem Statement

The key stone for a savi switch to perform address-source validation safely and efficiantly is how accurately it can learn about addresses on the link, and establish their binding to the binding anchor. This accuracy greatly depends on how well the switch deals with entry collisions.

There are currently several documents [savi-dhcp] [savi-fcfs] [savi-send] that describe the different methods for discovering bindings of addresses active on the link. Each of these documents describes separately how one particular discovery method deals with address collisions. For instance [fcfs] proposes that the first binding discovered for a given address prevail over subsequent ones. However, no document describes how to handle binding collisions in an heterogenous environment, with a mixt of DHCP-assigned, SLAC-assigned and manually assigned addresses, discovered over a variety of mechanisms (snooping, configuration), out of different type of ports (access, trunk, trusted or untrusted) carrying different type or credentials (including CGA). For example, for a given address, discovered concurently by snooping NDP and by snooping DHCP, with different bindings (different ports or different MACs), it is useful to define which of these two should remain in the binding table, as it will drive which traffic (from which MAC or on which port) will be allowed, and which will be denied. The goal of the document is to propose a method for dealing with the collisions in such heterogenous environment.

2.  Entry preference algorithm

2.1.  Preference Level

We define the preference level (preflevel) as an attribute of an entry in the binding table. It establishes the score of the entry in terms of preference. It is computed at the time the entry is discovered, by combining different factors related to the discovery. These factors range from the method of learning (NDP snooping, DHCP snooping, statically created), the type of port the entry is learnt from (access port, trunk, trusted access or trusted port), the credentials associated with the entry (CGA, etc.) and other criterias to-be-defined. The preflevel is used to compare two candidate entries (same l3 address, different binding anchors) in the binding table. The higher the preference level is, the more preferred the entry.

The different factors of preference 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. In theory, an CGA entry could be learnt thru NDP or DHCP snooping or just be created statically on the switch. To combine them in a fair algorithm, each factor is given a number from 0 to n, ordered from smallest contribution to biggest. The preference value corresponding to factor p is defined as 2**p. The preference level is computed as a sum of all relevant preference values. The goal of this encoding is to ensure that for any factor q < i, the sum of preferences values of q to i-1 is smaller than preference value of i. In other word, it is not enough for an entry to accumulate all factors less important than CGA credentials to beat an entry with just CGA credentials. And that the same time, if preference factor p < q, a preference level of p + i is smaller than one of q + i. In other words, to choose between an NDP snooped CGA address and a DHCP snooped CGA address, the latter is preferred.

A first series of factors to establish the preflevel are based upon the method by which the entry is discovered. The following discovery methods factors have been identified so far:

• DATA-SNOOPING: the entry is dicovered by snooping data packet, as described in [savi-fcfs]>
• NDP-SNOOPING: the entry is dicovered by snooping NDP messages, as described in [savi-fcfs]>
• DHCP-SNOOPING: the entry is dicovered by snooping DHCP messages, as described in [savi-dhcp]
• STATIC: the entry is statically configured on the switch>
• LOCAL: the entry is one of the switch address

Another set of factors of an entry preflevel are based upon the port the binding was learnt from. For example, an entry would have different preflevels if it is learnt from:

• ACCESS_PORT: it typically attaches to end-nodes
• TRUNK_PORT: it attaches to a non savi-switch
• TRUSTED_ACCESS: it attaches to trusted end-nodes
• TRUSTED_TRUNK: it attaches to another savi-switch

Another set of factors of the preflevel are based on the credentials associated with this learning. An entry associated with cryptographic proof (CGA) should be preferred over the same entry without this proof. Sometimes, an entry is discovered by snooping a message that carries a link-layer address at layer3 and above. For instance, an NDP message can contain the Link-Layer address as a SLLA or TLLA option. A DHCP message can also carry the link-layer address in the Client-Identifer option. In the cases where the MAC of the source is both found as the source MAC of the message, and in the payload of the message, it maybe be useful to prefer binding entries carried in messages where these two values are identical. The following credential factors have been identified:

• LLA_MAC_MATCH: LLA (found in NDP or DHCP option) and SMAC (found at layer2) are identical;
• CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.)
• CERT_AUTHENTICATED: the entry is authenticated with a certificate

So far the following preflevel factors have been identified, from lowest (0) to highest (10):

• NDP-SNOOPING: (0) the entry is dicovered by snooping NDP messages
• LLA_MAC_MATCH: (1) LLA (found in NDP or DHCP option) and MAC (found at layer2) are identical
• TRUNK_PORT: (2) the entry was learnt from a trunk port (connected to another switch)
• ACCESS_PORT: (3) the entry was leant from an access port (connected to a host)
• TRUSTED_ACCESS: (4) The entry was learnt from a trusted port
• TRUSTED_TRUNK: (5) The entry was learnt from a trusted trunk
• DHCP_SNOOPING: (6) the entry is dicovered thru DHCP snooping
• CGA_AUTHENTICATED: (7) The entry is CGA authenticated, per [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.)
• CERT_AUTHENTICATED: (8) the entry is authenticated with a certificate
• STATIC: (9) this is a statically configured entry
• LOCAL: (10) the address is one of the switch L3 address

Note that the absolute values behind each factor - 0 to 10 - don't matter. Their relative position is essential. The values don't show up outside the switch, and it is always possible to insert new factors value in the sequence without breaking the algorithm. DATA-SNOOPING has no value as it is not considered as being a contributor to the preference level.

2.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_6, in that order until one rule is satisfied: Updating an entry attribute if:

1. Allow, if no entry exist
2. Deny, if a more trusted entry exist
3. Allow if exsiting entry is less trusted
4. Allow, if received on a trusted port
5. Poll (DAD NS) existing entry and deny if response received
6. Allow

3. Normative References

Appendix A.  Contributors and Acknowledgments

This draft benefited from the input from: Pascal Thubert.

Author's Address