SAVI Jun Bi Internet Draft CERNET Intended status: Standard Tracks Guang Yao Expires: May 2011 Tsinghua Univ. Joel M. Halpern Newbridge Networks Inc. Eric Levy-Abegnoli Cisco System November 8, 2010 SAVI for Mixed Scenario draft-bi-savi-mix-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 Bi Expires May 8, 2011 [Page 1] Internet-Draft savi-mix November 2010 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on May 8, 2011. 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 Simplified BSD License. Abstract This document specifies the procedure a SAVI device resolves conflict from multiple co-existing SAVI solutions. Table of Contents Copyright Notice ............................................... 2 1. Introduction ................................................ 3 2. Terminology ................................................. 3 3. Mixed Scenario .............................................. 3 4. Basic SAVI-MixMode Structure................................. 3 5. Problem Scope and Statement.................................. 4 5.1. Problem Scope .......................................... 4 5.2. Collision in Binding Set-up Procedure................... 4 5.2.1. Proposed solution.................................. 5 5.3. Collision in Binding Removal............................ 7 6. Security Considerations...................................... 7 7. IANA Considerations ......................................... 7 7.1. Normative References.................................... 7 7.2. Informative References.................................. 8 8. Acknowledgments ............................................. 8 Bi Expires May 8, 2011 [Page 2] Internet-Draft savi-mix November 2010 1. Introduction SAVI solutions are specified for scenarios allowing only single address assignment method without considering the co-existing of multiple address assignment methods. In practice, for both IPv4 and IPv6 network, generally multiple address assignment methods are allowed. Current SAVI solutions cannot be used directly in such scenarios, because collision between solutions may happen. This document specifies the possible collisions and proposes corresponding mechanism to solve the collisions. 2. Terminology Address Assignment Source (AAS): The de facto entity type that assigns address. 3. Mixed Scenario Currently, there are actually four SAVI solutions which cover different types of addresses: (1) SAVI-FCFS: SLAAC (2) SAVI-DHCP: stateful DHCP, static DHCP (3) SAVI-SEND: CGA with certificate, CGA without certificate (4) Manually configuration: static address manually configured by administrator on SAVI device statically. Note: address configured by user on host is treated as stateless address. A practical network may enable any combination of address assignment methods, and all the corresponding solutions should be enabled to avoid legitimate packet filtering. If more than one SAVI solution is enabled on SAVI device, the scenario is named as mix scenario in this document. 4. Basic SAVI-MixMode Structure Existing SAVI solutions are individual mechanism without considering inter-cooperation. To keep the independence and completeness of each solution, a SAVI solution is treated as a black box which snoops packet and generates/removes candidate binding, without concerning the inner structure of each solution. Because the binding entry setup by each solution is ALLOW entry, thus a solution will reject any address not bound by it. However, Bi Expires May 8, 2011 [Page 3] Internet-Draft savi-mix November 2010 address bound by any solution must be allowed if no collision, thus, binding entry table should be shared by all the solutions. The main work of this document is handling the conflict resulted from solutions sharing the binding table. If bindings on different addresses are set up by different solutions, no collisions can happen. Thus, a guideline here is to separate the address space of each type to avoid any kind of collision. However, if there is overlap between address spaces, bindings on the same address can be set up by different solutions, and collision can happen. 5. Problem Scope and Statement 5.1. Problem Scope This document is specified for collision between SAVI solutions. The situation that collision happens in a single solution, for example, the same address is bound by the same solution on different binding anchors, is not in the scope of this document. SAVI solutions mainly specify the setup and remove of bindings. Whenever a solution sets up a binding or removes an existing binding, it may violate the state of other solutions. In the mix mode, the SAVI device must decide whether to accept the operation request from each solution or not. 5.2. Collision in Binding Set-up Procedure In binding set up, collision happens when: (1) the same address (2) different binding anchors on the SAVI perimeter and (3) different binding solutions. As an instance, after an address is bound on one binding anchor by DHCP solution, the FCFS solution requires to bind the address on another binding anchor. Both bindings are legitimate in corresponding solution; however, only one of the bindings should be allowed. Then the SAVI device must decide whom the address should be bound with. NOTE: because a single SAVI device doesn't have the information of all bound addresses on the perimeter, a collision may not be explicit based only on local bindings. To make the perimeter-scope Bi Expires May 8, 2011 [Page 4] Internet-Draft savi-mix November 2010 collision explicit to each SAVI device, which means, a SAVI device must distinguish whether a local binding setup request violate a binding on other devices or not. Following mechanism can be used: (1) SAVI device performs DAD proxy for local manually configured address even if the node with static address is off-link;(Or to manually configure all the SAVI devices is also proposed.) Then the collision that SAVI-FCFS request static address can be handled. (2) Static address must be excluded from DHCP address pool; Then the collision that SAVI-DHCP request static address can be handled. (3) SAVI device performs DAD proxy for local DHCP address. Then the collision that SAVI-FCFS request DHCP address on other SAVI devices can be handled. 5.2.1. Proposed solution To make a choice between candidate bindings, a preference level based solution is thought to be efficient from the experience of similar implementations. The essential problem is: 1. The granularity of preference level; 2. The basis of preference level (or at least the default level). The preference level proposed in this document is an AAS (Address Assignment Source) granularity preference level. And preference level is assigned based on the trustworthy of AAS and the sequence of candidate bindings. By now, there are 4 types of AAS: (1) Node itself: SLAAC, CGA without certificate (2) DHCP sever: stateful DHCP address (3) PKI: CGA with certificate, plain address with certificate (4) Administrator: static address, static DHCP address(may not be taken into consideration as no standard document) Bi Expires May 8, 2011 [Page 5] Internet-Draft savi-mix November 2010 Combined with binding sequence, there will be 16 scenarios: FORMER LARER PREFERENCE Node Node In the scope of SAVI-SLAAC Node DHCP Switch here: either former or later Node PKI Later Node Admin Later DHCP Node Former DHCP DHCP In the scope of SAVI-DHCP DHCP PKI Later DHCP Admin Later PKI Node Former PKI DHCP Former PKI PKI No definition PKI Admin Later Admin Node Former Admin DHCP Former Admin PKI Former Admin Admin Later(Or not in scope of this document) If ignoring the details, the basic preference level of AAS is simply node