Network Working Group J. Kaippallimalil Internet-Draft F. Xia Expires: August 29, 2010 Huawei USA J. Bi CERNET February 25, 2010 SAVI Solution for Delegated IPv6 Prefixes draft-kaippallimalil-savi-dhcp-pd-01.txt Abstract This document specifies the procedure for creating bindings between a DHCPv6 assigned source IPv6 prefix and an anchor. These bindings can be used to filter packets with forged IPv6 prefixes. 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 August 29, 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 Kaippallimalil, et al. Expires August 29, 2010 [Page 1] Internet-Draft SAVI Delegated Prefix February 2010 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Mechanism and Architecture Context . . . . . . . . . . . . . . 3 2.1. Mechanism Overview . . . . . . . . . . . . . . . . . . . . 3 2.2. Architecture Context . . . . . . . . . . . . . . . . . . . 3 3. Background and Related Protocols . . . . . . . . . . . . . . . 4 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 5 5.1. Binding State Table (BST) . . . . . . . . . . . . . . . . 5 5.2. Filtering Table (FT) . . . . . . . . . . . . . . . . . . . 5 5.3. Binding State Description . . . . . . . . . . . . . . . . 6 6. Anchor Attributes . . . . . . . . . . . . . . . . . . . . . . 6 6.1. SAVI-Validation Attribute . . . . . . . . . . . . . . . . 6 6.2. SAVI-DHCP Trust Attribute . . . . . . . . . . . . . . . . 6 7. Binding Specification . . . . . . . . . . . . . . . . . . . . 6 7.1. Process of DHCP-PD Snooping . . . . . . . . . . . . . . . 6 7.1.1. Initialization . . . . . . . . . . . . . . . . . . . . 6 7.1.2. From START to BOUND . . . . . . . . . . . . . . . . . 7 7.1.3. State transition from BOUND . . . . . . . . . . . . . 8 7.2. State Machine for DHCP-PD Snooping . . . . . . . . . . . . 9 8. Filtering Specification . . . . . . . . . . . . . . . . . . . 9 8.1. Data Packet Filtering . . . . . . . . . . . . . . . . . . 9 8.2. Control Packet Filtering . . . . . . . . . . . . . . . . . 9 9. Other Events . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Port Down Event . . . . . . . . . . . . . . . . . . . . . 10 9.2. Port Up Event . . . . . . . . . . . . . . . . . . . . . . 10 9.3. Binding Number Limit . . . . . . . . . . . . . . . . . . . 10 9.4. SAVI Device Failure . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Kaippallimalil, et al. Expires August 29, 2010 [Page 2] Internet-Draft SAVI Delegated Prefix February 2010 1. Introduction This document specifies the procedure for creating bindings between a DHCPv6 [RFC3633] assigned source IPv6 prefix and an anchor (refer to [SAVI Framework]). These bindings can be used to filter packets with forged IPv6 prefixes. The use of these bindings are specified in [SAVI Framework]. The definition and examples of anchor is also specified in [SAVI Framework]. This binding process is applicable to a SAVI switch in the path between a Requesting Router and Delegating Router. In a broadband access network, the CPE-R is the requesting router, access router is delegating router and there maybe SAVI switches in between. 2. Mechanism and Architecture Context 2.1. Mechanism Overview The mechanism specified in this document is designed to provide IPv6 prefix validation as a supplement to BCP38. The broadband access network consists of CPE-R (Requesting Router), access router (Delegating Router) and SAVI access device in between. This mechanism is deployed on the access device (such as DSLAM, OLT, etc.), and performs DHCPv6 snooping of prefix delegation to setup bindings between the assigned IPv6 prefix and corresponding anchors. The bindings can be used to validate the source prefix in the packets. 2.2. Architecture Context Customer Network | Provider Network | | | \ \ +---+ +-------+ | \+--------+ \ +---------------+ | H |------| CPE-R |--|------| Switch |---------| Access Router |---- +---+ +-------+ | /+--------+ / +---------------+ | / / | / | +--------+ / | | Switch |--/ | +--------+ | Kaippallimalil, et al. Expires August 29, 2010 [Page 3] Internet-Draft SAVI Delegated Prefix February 2010 Figure 1: Provider Network Architecture Figure 1 shows a network topology in which prefix delegation maybe used. The provider network consists of access Routers (AR) and switches. CPE-Rs are located at the boundary of the customer network. Hosts in the customer network are attached to the CPE-R. The CPE-R behaves as a router for hosts attached to it (i.e. CPE-R is the router for H). A host attached to an CPE-R uses prefixes that are advertised by the CPE-R. These prefixes are in turn delegated to the CPE-R using [RFC3633]. Details of prefix delegation, and other address configuration mechanisms for CPE-R are described in [I-D.ietf-v6ops-ipv6-cpe-router]. A switch in the provider network terminates access lines and aggregates connections. A SAVI-Device may be placed in the switch. The access router is the first router in the provider network. The provider network should be able to verify if packets from the CPE-R belong to the prefix delegated by the access router. 3. Background and Related Protocols This mechanism is an instance of a SAVI [SAVI Framework] solution specialized for IPv6 prefixes assigned using DHCPv6 prefix delegation protocol. In IPv6, the requesting router node must still assign its link-local address through IPv6 Stateless Autoconfiguration [RFC4862]. [RFC4861] Neighbor Discovery Protocol may be used for duplicate address detection of the link local address. A DHCP client in the requesting router may use this link-local address to send a message to the DHCP server. This mechanism concerns DHCPv6 messages used for prefix delegation. 4. Terminology Host: A network device that connects to the service provider network through a residential gateway. User: An entity that attaches to the network using one or more hosts. The user is usually the subscriber that owns the CPE- Router. CPE-Router: Gateway device located at the edge of the customer network and is an IP router. For a user within the customer network, the CPE-R is a gateway to the service provider network. Kaippallimalil, et al. Expires August 29, 2010 [Page 4] Internet-Draft SAVI Delegated Prefix February 2010 CPE-R Customer Premise Equipment Router DHCP Dynamic Host Configuration Protocol MAC Medium Access Control SAVI Source Address Validation Improvements TID Transaction Identity More definitions are described in [SAVI Framework]. 5. Conceptual Data Structures This section describes a set of conceptual data structures that are necessary for this mechanism. Two key data structures are used to record bindings and their states. The Binding State Table (BST) contains enties populated based on snooping the RFC3633 protocol. The Filtering Table (FT) contains bindings used to filter data plane traffic. 5.1. Binding State Table (BST) This table contains the state of bindings between source IPv6 prefix and anchor. Entries are keyed on anchor and source IPv6 prefix. Each entry has length of prefix, lifetime field containing the lifetime of the entry, a field recording the state of the binding, the default Router interface MAC address and a field for other information. +--------+--------+--------+-------+----------+--------+ | Anchor | Prefix | Length | State | Lifetime | Other | +--------+--------+--------+-------+----------+--------+ | A | IP_1 | 56 | Bound | 65535 | | +--------+--------+--------+-------+----------+--------+ | A | IP_2 | 56 | Bound | 10000 | | +--------+--------+--------+-------+----------+--------+ | B | IP_3 | 60 |_Start | 1 | | +--------+--------+--------+-------+----------+--------+ Figure 2: Instance of BST 5.2. Filtering Table (FT) This table contains the bindings between anchor and prefix/length, keyed on anchor. This table does not contain any state of the binding. It is used to filter packet. Kaippallimalil, et al. Expires August 29, 2010 [Page 5] Internet-Draft SAVI Delegated Prefix February 2010 +---------+--------+--------+ |Anchor |Prefix | Length | +---------+--------+--------+ |A |IP_1 | 56 | +---------+--------+--------+ |A |IP_2 | 56 | +---------+--------+--------+ Figure 3: Instance of FT 5.3. Binding State Description This section describes the binding states of this mechanism. START A DHCPv6 request with IA_PD is received from customer router. BOUND The prefix is assigned to the customer and bound to the anchor. 6. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. 6.1. SAVI-Validation Attribute The SAVI-Validation attribute should be set if and only if source prefix validation must be performed on traffic from this anchor. 6.2. SAVI-DHCP Trust Attribute The SAVI-DHCP Trust attribute must be set if and only if an anchor is associated with a trustable DHCP server/relay. 7. Binding Specification This section specifies the procedure of setting up bindings based on snooping [RFC3633]. 7.1. Process of DHCP-PD Snooping 7.1.1. Initialization This procedure is not performed if an unspoofable MAC is used as anchor (802.11i, 802.1ae/af). If not, DHCPv6 MUST be snooped for prefix delegation option. Kaippallimalil, et al. Expires August 29, 2010 [Page 6] Internet-Draft SAVI Delegated Prefix February 2010 7.1.1.1. Trigger Event A DHCPv6 REQUEST/option code OPTION_IA_PD is received on an anchor for which the SAVI-Validation attribute has been set. 7.1.1.2. Message Validation The SAVI device checks the REQUEST message for the following: 1. Will the limitation on binding entry number of this anchor be exceeded. 7.1.1.3. Following Actions Allow forwarding the REQUEST message if the binding entry limit is not exceeded. Generate an entry in the Binding State Table (BST) and set the state field to START. The lifetime of this entry is set to MAX_DHCP_RESPONSE_TIME. The Transaction ID field of the request packet is also recorded in the entry. +--------+--------+--------+-------+-----------------------+-------+ | Anchor | Prefix | Length | State | Lifetime |Other | +--------+--------+--------+-------+-----------------------+-------+ | A | | | START |MAX_DHCP_RESPONSE_TIME | TID | +--------+--------+--------+-------+-----------------------+-------+ Figure 4: Binding entry in BST on initialization The transation ID (TID) is kept for assurance that the response from the DHCP server can be matched to the prefix delegation requesting router. 7.1.2. From START to BOUND 7.1.2.1. Trigger Event A DHCPv6 REPLY message is received with option code OPTION_IA_PD. 7.1.2.2. Message Validation The SAVI device checks the REPLY message for the following: 1. Whether the message is received with an anchor which has the SAVI-DHCP-Trust attribute. Kaippallimalil, et al. Expires August 29, 2010 [Page 7] Internet-Draft SAVI Delegated Prefix February 2010 2. Whether an entry in the BST with corresponding TID is in the START state. 7.1.2.3. Following Actions Deliver the message to the destination. Set the state of the corresponding entry to BOUND. The lifetime of the entry is set to value of valid lifetime in OPTION_IAPREFIX. This lease time is recorded in the entry. +---------+----------+--------+-------+-------------------+-------+ | Anchor | Prefix | Length |State | Lifetime |Other | +---------+----------+--------+-------+-------------------+-------+ | A |IP_1 | 56 |BOUND |OPTION_IAPREFIX: |Lease | | | | | |valid-lifetime |Time | +---------+----------+--------+-------+-------------------+-------+ Figure 5: Binding entry in BST on assignment An entry is inserted into the filtering table if the assigned prefix is not bound to another anchor. +---------+--------+--------+ |Anchor |Prefix | Length | +---------+--------+--------+ |A |IP_1 | 56 | +---------+--------+--------+ Figure 6: Binding Entry in FT on assignment 7.1.3. State transition from BOUND Whenever a DHCPv6 RELEASE is received from the host, if the state of the entry is BOUND, the entry is deleted in the BST and FT. If DHCPv6 REPLY with Renew is received from the server, set lifetime of entry in BST with the new valid lifetime in OPTION_IAPREFIX. If the lifetime of an entry in with state BOUND expires, delete the entry in BST and FT. Kaippallimalil, et al. Expires August 29, 2010 [Page 8] Internet-Draft SAVI Delegated Prefix February 2010 7.2. State Machine for DHCP-PD Snooping State Message/Event Action Next State _* REQUEST/CONFIRM Set up new Entry START START REPLY Record Lease time BOUND Enter in FT START Timeout Remove Entry - BOUND RELEASE Remove Entry - BOUND Lease timeout Remove Entry - BOUND RENEW (Reply) Set new Lease time BOUND Figure 7 8. Filtering Specification 8.1. Data Packet Filtering Data packets with an anchor which has attribute SAVI-Validation MUST be checked. If the source prefix of a packet associated with its anchor is in the FT, this packet SHOULD be forwarded; else the packet MUST be discarded. 8.2. Control Packet Filtering For anchors with SAVI-Validation attribute: The source address of DHCPv6 Request/Confirm MUST be an address associated with the corresponding anchor in FT. The source address of DHCPv6 Solicit MUST be the link layer address bound to corresponding anchor. The link layer address MAY be bound based on SAVI-SLAAC solution. All DHCPv6 Reply packets MUST be from anchor with the SAVI-DHCP-Trust attribute. Kaippallimalil, et al. Expires August 29, 2010 [Page 9] Internet-Draft SAVI Delegated Prefix February 2010 9. Other Events 9.1. Port Down Event When a port with attribute SAVI-Validation goes down, the bindings with the anchor MUST be kept for a short time. If the port comes back up during this period, the prefix is still active. 9.2. Port Up Event When a port with attribute SAVI-Validation comes up after a failure, the bindings with the anchor in BST and FT are populated as in initialization. 9.3. Binding Number Limit 9.4. SAVI Device Failure 10. Security Considerations This document does not introduce any new vulnerabilities to IPv6 specifications or operation. Source address validation of hosts attached to various access networks supported by the fixed broadband network architecture is the subject of these specifications. 11. References 11.1. Normative References [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2728] Panabaker, R., Wegerif, S., and D. Zigmond, "The Transmission of IP Over the Vertical Blanking Interval of a Television Signal", RFC 2728, November 1999. 11.2. Informative References [I-D.ietf-v6ops-ipv6-cpe-router] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", draft-ietf-v6ops-ipv6-cpe-router-04 (work in progress), January 2010. Kaippallimalil, et al. Expires August 29, 2010 [Page 10] Internet-Draft SAVI Delegated Prefix February 2010 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006. [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 Framework] Vogt, CV., "Source Address Validation Improvement Protocol Framework", , October 2009. Kaippallimalil, et al. Expires August 29, 2010 [Page 11] Internet-Draft SAVI Delegated Prefix February 2010 Authors' Addresses John Kaippallimalil Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 214-606-2005 Email: jkaippal@huawei.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Jun Bi CERNET Network Research Center, Tsinghua University Beijing, 100084 Phone: +1 972-509-5599 Email: junbi@cernet.edu.cn Kaippallimalil, et al. Expires August 29, 2010 [Page 12]