One document matched: draft-levy-abegnoli-savi-plbt-02.txt

Differences from draft-levy-abegnoli-savi-plbt-01.txt

Network Working Group                                   E. Levy-Abegnoli
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                           March 8, 2010
Expires: September 9, 2010


                  Preference Level based Binding Table
                 <draft-levy-abegnoli-savi-plbt-02.txt>

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 algorithum.

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.



Levy-Abegnoli           Expires September 9, 2010               [Page 1]

Internet-Draft    Preference Level based Binding Table        March 2010


   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 . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Entry preference algorithm  . . . . . . . . . . . . . . . . . . 3
     2.1.  Preference Level  . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Entry update algorithm  . . . . . . . . . . . . . . . . . . 5
   3.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Appendix A.  Contributors and Acknowledgments . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6































Levy-Abegnoli           Expires September 9, 2010               [Page 2]

Internet-Draft    Preference Level based Binding Table        March 2010


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



Levy-Abegnoli           Expires September 9, 2010               [Page 3]

Internet-Draft    Preference Level based Binding Table        March 2010


   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:
   o  DATA-SNOOPING: the entry is dicovered by snooping data packet, as
      described in [savi-fcfs]>
   o  NDP-SNOOPING: the entry is dicovered by snooping NDP messages, as
      described in [savi-fcfs]>
   o  DHCP-SNOOPING: the entry is dicovered by snooping DHCP messages,
      as described in [savi-dhcp]
   o  STATIC: the entry is statically configured on the switch>
   o  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:
   o  ACCESS_PORT: it typically attaches to end-nodes
   o  TRUNK_PORT: it attaches to a non savi-switch
   o  TRUSTED_ACCESS: it attaches to trusted end-nodes
   o  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:



Levy-Abegnoli           Expires September 9, 2010               [Page 4]

Internet-Draft    Preference Level based Binding Table        March 2010


   o  LLA_MAC_MATCH: LLA (found in NDP or DHCP option) and SMAC (found
      at layer2) are identical;
   o  CGA_AUTHENTICATED: The entry is CGA authenticated, per [RFC3972]
   o  CERT_AUTHENTICATED: the entry is authenticated with a certificate

   So far the following preflevel factors have been identified, from
   lowest (0) to highest (10):
   o  NDP-SNOOPING: (0) the entry is dicovered by snooping NDP messages
   o  LLA_MAC_MATCH: (1) LLA (found in NDP or DHCP option) and MAC
      (found at layer2) are identical
   o  TRUNK_PORT: (2) the entry was learnt from a trunk port (connected
      to another switch)
   o  ACCESS_PORT: (3) the entry was leant from an access port
      (connected to a host)
   o  TRUSTED_ACCESS: (4) The entry was learnt from a trusted port
   o  TRUSTED_TRUNK: (5) The entry was learnt from a trusted trunk
   o  DHCP_SNOOPING: (6) the entry is dicovered thru DHCP snooping
   o  CGA_AUTHENTICATED: (7) The entry is CGA authenticated, per
      [RFC3972]
   o  CERT_AUTHENTICATED: (8) the entry is authenticated with a
      certificate
   o  STATIC: (9) this is a statically configured entry
   o  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





Levy-Abegnoli           Expires September 9, 2010               [Page 5]

Internet-Draft    Preference Level based Binding Table        March 2010


3.  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,
              "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.

   [savi-dhcp]
              Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for
              DHCPv4/v6", draft-ietf-savi-dhcp-01.txt I-D, Dec 2009.

   [savi-fcfs]
              Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "First-
              Come First-Serve Source-Address Validation
              Implementation", draft-ietf-savi-fcfs-02 I-D, March 2009.

   [savi-send]
              Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
              Address Validation Implementation",
              draft-ietf-savi-send-02 I-D, Oct 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 September 9, 2010               [Page 6]