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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 <!ENTITY rfc4861  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml'>
 <!ENTITY rfc4862  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml'>
 <!ENTITY rfc3971  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
 <!ENTITY rfc3972  PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
]> 
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc ipr="trust200902" category="std" docName="<draft-levy-abegnoli-savi-plbt-02.txt>">

<front>
  <title abbrev="Preference Level based Binding Table">
        Preference Level based Binding Table
  </title>

<author fullname="Eric Levy-Abegnoli" initials="E.L.A."
 surname="Levy-Abegnoli">
    <organization> Cisco Systems</organization>
    <address>
      <postal>
        <street>Village d'Entreprises Green Side -
	  400, Avenue Roumanille </street>
        <city>Biot-Sophia Antipolis - 06410</city>
        <country>France</country>
      </postal>
      <email>elevyabe@cisco.com</email>
    </address>
  </author>

 <date/>

<abstract>
<t>
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.
</t>
</abstract>
</front>

<middle>

<!---------------------------------------------------------------->

<section anchor="problem" title="Problem Statement">
<t>
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.
</t>
>t>
In IPv6, there are many methods for assigning addresses, whether thru Stateless AutoConfiguration (SLAC), Dynamic Host Address Configuration Protocol 
(DHCP) or static assignment. Even within one particular method, there are many variations in the way addresses are assigned. For instance, the interface
identifier of a SLAC address can be derived from the MAC address (EUI-64), Cryptographically computed (CGA), ramdomly generated  using an MD5 hash.
In addition to the way addresses are assigned, the method by which they are discovered by the switch can also vary greatly. For instance, they can be
discovered by snooping DHCP messages, NDP messages or even data packets (regardeless on whether the address is assigned by DHCP, SLAC or manually configured).
Rather of being discovered, an address - and its binding - can also be manually configured on the switch. Last for no tleast, the address could be one of
the switch address, when the switch is L2 and L3 at the same time.
<t>
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. 
</t> 
</section>

<section anchor="prefalgo" title="Entry preference algorithm">
<section anchor="preflevel" title="Preference Level">
<t>
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.
</t>
<t>
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.
</t>  
<t> 
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:
<list style="symbols">
<t>	DATA-SNOOPING: the entry is dicovered by snooping data packet, as described in [savi-fcfs]></t>
<t>	NDP-SNOOPING: the entry is dicovered by snooping NDP messages, as described in [savi-fcfs]></t>
<t>	DHCP-SNOOPING: the entry is dicovered by snooping DHCP messages, as described in [savi-dhcp]</t>
<t>     STATIC: the entry is statically configured on the switch></t>
<t>     LOCAL: the entry is one of the switch address</t>
</list>
</t>
<t>
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:
<list style="symbols">
<t>	ACCESS_PORT: it typically attaches to end-nodes</t>
<t>	TRUNK_PORT: it attaches to a non savi-switch</t>
<t>	TRUSTED_ACCESS: it attaches to trusted end-nodes</t>
<t>     TRUSTED_TRUNK: it attaches to another savi-switch</t>
</list>
</t>
<t>
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:
<list style="symbols">
<t>     LLA_MAC_MATCH: LLA  (found in NDP or DHCP option) and SMAC (found at layer2) are identical;</t>
<t>	CGA_AUTHENTICATED: The entry is CGA authenticated, per <xref target="RFC3972"/></t>
<t>	CERT_AUTHENTICATED: the entry is authenticated with a certificate</t>
</list>
</t>

<t>
So far the following preflevel factors have been identified, from lowest (0) to highest (10):
<list style="symbols">
<t>	NDP-SNOOPING: (0) the entry is dicovered by snooping NDP messages</t>
<t>	LLA_MAC_MATCH: (1) LLA  (found in NDP or DHCP option) and MAC (found at layer2) are identical</t>
<t>	TRUNK_PORT: (2) the entry was learnt from a trunk port (connected to another switch)</t>
<t>	ACCESS_PORT: (3) the entry was leant from an access port (connected to a host)</t>
<t>	TRUSTED_ACCESS: (4) The entry was learnt from a trusted port</t>
<t>	TRUSTED_TRUNK: (5) The entry was learnt from a trusted trunk</t>
<t>	DHCP_SNOOPING: (6) the entry is dicovered thru DHCP snooping</t>
<t>	CGA_AUTHENTICATED: (7) The entry is CGA authenticated, per <xref target="RFC3972"/></t>
<t>	CERT_AUTHENTICATED: (8) the entry is authenticated with a certificate</t>
<t>	STATIC: (9) this is a statically configured entry</t>
<t>     LOCAL: (10) the address is one of the switch L3 address</t>
</list>
</t>
<t>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.</t>
</section>
<section anchor="repalgo" title="Entry update algorithm">
<t>
Once an entry is installed in the binding table, its attributes cannot be changed without complying
with this “entry update algorithm”.
</t>
<t>
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: 
<list style="numbers">
<t>Allow, if no entry exist</t>
<t>Deny, if a more trusted entry exist</t>
<t>Allow if exsiting entry is less trusted</t>
<t>Allow, if received on a trusted port</t>
<t>Poll (DAD NS) existing entry and deny if response received</t>
<t>Allow</t>
</list>
</t>

An entry is "reachable" if its valid lifetime has not expired. For entries configured manually on the switch, this lifetime is
never expired. For entries learnt thru DHCP snooping, the valid lifetime is the value carried in the identity association. For
entries learnt thru NDP snooping, it is an arbitrary value since the last proof of activity (whether and NDP or a data packet carrying
the entry binding). 

</section>

</section>
</middle>
<!---------------------------------------------------------------->

<back>
<references title='Normative References'>

&rfc4861;
&rfc4862;
&rfc3971;
&rfc3972;
<reference anchor="savi-fcfs">
  <front>
 <title>
 First-Come First-Serve Source-Address Validation Implementation
 </title>
 <author surname="Nordmark" initials="E">
<organization>Sun</organization></author>
 <author surname="Bagnulo" initials="M">
<organization>UC3M</organization></author>
<author surname="Levy-Abegnoli" initials="E">
<organization>Cisco Systems</organization></author>
 <date month="March" year="2009" />
  </front>
<seriesInfo name="draft-ietf-savi-fcfs-02" value="I-D"/>
</reference>

<reference anchor="savi-dhcp">
  <front>
 <title>
 SAVI Solution for DHCPv4/v6
 </title>
<author surname="Bi" initials="J">
<organization>Cernet</organization></author>
<author surname="Wu" initials="J">
<organization>Cernet</organization></author>
<author surname="Yao" initials="G">
<organization>Cernet</organization></author>
<author surname="Baker" initials="F">
<organization>Cisco</organization></author>
 <date month="Dec" year="2009" />
  </front>
<seriesInfo name="draft-ietf-savi-dhcp-01.txt" value="I-D"/>
</reference>

<reference anchor="savi-send">
  <front>
 <title>
 SEND-based Source-Address Validation Implementation
 </title>
 <author surname="Bagnulo" initials="M">
 <organization>UC3M</organization></author>
 <author surname="Garcia-Martinez" initials="A">
 <organization>UC3M</organization></author>
 <date month="Oct" year="2009" />
  </front>
<seriesInfo name="draft-ietf-savi-send-02" value="I-D"/>
</reference>


</references>

<section title="Contributors and Acknowledgments">
<t>
This draft benefited from the input from: Pascal Thubert.
</t>
</section>

</back>

</rfc>