SAVI J. Bi, G. Yao, J. Wu Internet Draft CERNET Intended status: Standard Tracks F. Baker Expires: April 2010 October 27, 2009 SAVI Solution for DHCPv4/v6 draft-bi-savi-cps-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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 27, 2009. Bi Expires April 27, 2010 [Page 1] Internet-Draft savi-dhcp October 2009 Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies the procedure of setting up bindings between DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and anchor (refer to [SAVI-framework]) on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets with forged IP addresses. Table of Contents 1. Introduction ................................................ 3 2. Conventions used in this document............................ 4 3. Mechanism Overview .......................................... 4 4. Background and Related Protocols............................. 4 5. Terminology ................................................. 5 6. Conceptual Data Structures................................... 5 6.1. Binding State Table (BST)............................... 5 6.2. Filtering Table (FT).................................... 5 7. Binding States Description................................... 6 8. DHCP Scenario ............................................... 6 9. Anchor Attributes ........................................... 7 9.1. SAVI-Host Attribute..................................... 7 9.2. SAVI-Poly Attribute..................................... 7 9.3. SAVI-DHCP-Trust Attribute............................... 7 9.4. SAVI-RA-Trust Attribute................................. 8 10. Prefix Configuration........................................ 8 11. Binding Set Up ............................................. 9 11.1. Process of DHCP Snooping............................... 9 11.1.1. Initialization.................................... 9 11.1.1.1. Trigger Event................................ 9 11.1.1.2. Message Validation........................... 9 11.1.1.3. Following Actions............................ 9 11.1.2. From START to LIVE............................... 10 11.1.2.1. Trigger Event............................... 10 11.1.2.2. Message Validation.......................... 10 Bi Expires April 27, 2010 [Page 2] Internet-Draft savi-dhcp October 2009 11.1.2.3. Following Actions........................... 10 11.1.3. From LIVE to DETECTION........................... 11 11.1.3.2. Message Validation.......................... 11 11.1.3.3. Following Actions........................... 11 11.1.4. From DETECTION to BOUND.......................... 12 11.1.4.1. Trigger Event............................... 12 11.1.4.2. Following Actions........................... 12 11.1.5. After BOUND...................................... 12 11.2. State Machine of DHCP Snooping ....................... 12 12. Filtering Specification.................................... 13 12.1. Filter Data Packet.................................... 13 12.2. Filter Control Packet................................. 13 13. Handle port UP/DOWN event.................................. 14 13.1. On port DOWN event.................................... 14 13.2. On port UP event...................................... 14 14. About Collision in Detection............................... 14 14.1. Whether to notify the DHCP server .................... 15 14.2. The result of detection without host aware ........... 15 15. Filtering during detection................................. 15 16. Binding Number Limitation.................................. 15 17. Constants ................................................. 15 18. Summary of to-be-removed sections and open issues ......... 16 19. Security Considerations.................................... 16 20. IANA Considerations........................................ 16 21. References ................................................ 17 21.1. Normative References.................................. 17 21.2. Informative References................................ 17 22. Acknowledgments ........................................... 17 1. Introduction This document describes the procedure of setting up bindings between DHCP assigned address and anchor (refer to [savi-framework]). Other related details about this procedure are also specified in this document. These bindings can be used to filter packets with forged IP addresses. How to use these bindings is specified in [savi-framework], depending on the environment and configuration. The definition and examples of anchor is also specified in [savi-framework]. The binding process is inspired by the work of IP source guard. This specification is different from IP source guard on the specification on collision detection, which is quite useful in an environment with multiple address assignment methods. Bi Expires April 27, 2010 [Page 3] Internet-Draft savi-dhcp October 2009 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Mechanism Overview The mechanism specified in this document is designed to provide a host level source IP address validation granularity, as a supplement of BCP38 [BCP38]. This mechanism is deployed on the access device (including access switch, wireless access point/controller, etc), and performs DHCPv4/v6 snooping to set up bindings between DHCP assigned IP address and corresponding anchors. The bindings can be used to validate the source address in the packets. 4. Background and Related Protocols This mechanism is an instance of SAVI [savi-framework] solution, specialized for addresses assign through DHCP protocol. Dynamic Host Configuration Protocol version 4 [RFC2131] and Dynamic Host Configuration Protocol version 6 [RFC3315] specify the procedures of providing a client with assigned address and other configuration information from a DHCP server. If a client gets an address through DHCP protocol, the address should be regarded as a potential "authorized" or "registered" address of the client. In IPv6, IPv6 Stateless Autoconfiguration [RFC4862] is used as another address assignment mechanism. A node can use this mechanism to auto-configure an IPv6 address. A DHCPv6 client may use a stateless address to send message to DHCP server. Even in a DHCPv6 only environment, a node must assign its link-local address through this mechanism. [RFC4862] also clearly requires that duplicated address detection must be performed on any IPv6 address, including DHCPv6 address. [RFC4861] specifies the Neighbor Discovery protocol, which is an essential part of IPv6 address assignment. [RFC5227] specifies the procedure to detect IPv4 address collision. It is not enforcement currently. However, this feature is useful to determine the uniqueness of an IPv4 address on the link. Bi Expires April 27, 2010 [Page 4] Internet-Draft savi-dhcp October 2009 5. Terminology The terms used in this document are described in [savi-framework], [RFC2131] and [RFC3315]. 6. Conceptual Data Structures (To be removed and merged with data structures used by other mechanisms in [savi-framework] if possible) This section describes the possible conceptual data structures used in this mechanism. Two main data structures are used to record bindings and their states respectively. There are redundancy between the two structures, for the consideration of separation of data plane and control plane. 6.1. Binding State Table (BST) This table contains this state of binding between source address and anchor. Entries are keyed on the anchor and source IP address. Each entry has a lifetime item recording the remaining lifetime of this entry, a state item recording the state of this binding and an item recording other information. +---------+----------+-------+-----------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------+-------+ | A | IP_1 | Bound | 65535 | | +---------+----------+-------+-----------+-------+ | A | IP_2 | Bound | 10000 | | +---------+----------+-------+-----------+-------+ | B | IP_3 |_Start | 1 | | +---------+----------+-------+-----------+-------+ Figure 1 Instance of BST 6.2. Filtering Table (FT) This table contains the bindings between anchor and address, keyed on anchor. This table doesn't contain any state of the binding. This table is only used to filter packet. Access Control List can be regarded as a practical instance of this table. Bi Expires April 27, 2010 [Page 5] Internet-Draft savi-dhcp October 2009 +---------+----------+ |Anchor |Address | +---------+----------+ |A |IP_1 | +---------+----------+ |A |IP_2 | +---------+----------+ Figure 2 Instance of FT 7. Binding States Description This section describes the binding states of this mechanism. START A DHCP request (or a DHCPv6 Confirm) is received from host, and it may trigger a new binding. LIVE A DHCP address is acknowledged by a DHCP server. DETECTION A gratuitous ARP or Duplicate Address Detection NSOL has been sent by the host (or the SAVI device). BOUND The address has passed duplicate detection and it is bound with the anchor. 8. DHCP Scenario (This section should be removed and merged with other scenarios in [savi-framework]) This section specifies the deployment scenarios of this mechanism. Bi Expires April 27, 2010 [Page 6] Internet-Draft savi-dhcp October 2009 +--------+ | DHCP | | Server | +-------,+ `. `. `. +----'-----+ | SAVI | | Device | +-/------/-+ | | +----\-+ +\-----+ |DHCP | |Client| |Relay | | | +------+ +------+ Figure 3 DHCP Scenario 9. Anchor Attributes This section specifies the anchor attributes involved in this mechanism. 9.1. SAVI-Host Attribute (This attribute should be described in the [savi-framework]) If and only if an anchor is exclusively associated with a single host, this anchor can be set to have SAVI-Host attribute. 9.2. SAVI-Poly Attribute (This attribute should be described in the [savi-framework]) If an anchor is associated with a small number of hosts through a converge device, this anchor can be set to have SAVI-Poly attribute. SAVI-Poly attribute is a conflict attribute of SAVI-Host attribute. The main different process on anchor with SAVI-Poly attribute from that with SAVI-Host attribute is the policy of binding consistence. 9.3. SAVI-DHCP-Trust Attribute If and only if an anchor is associated with a trustable DHCP server/relay, it can be set to have this attribute. Bi Expires April 27, 2010 [Page 7] Internet-Draft savi-dhcp October 2009 If DHCP is used to assign address in the network, there MUST be at least one anchor with this attribute. DHCP Reply message not from such ports MUST be dropped. 9.4. SAVI-RA-Trust Attribute (This attribute should be described in the [savi-framework]) If and only if an anchor is associated with a trustable router, it can be set to have this attribute. There MAY be no SAVI-RA-Trust anchor on a SAVI device. Router Advertisement received not from SAVI-RA-Trust anchor MUST be discarded. 10. Prefix Configuration (This section should be included in [SAVI-framework] but not this document.) Before setting up a host-level granularity binding table, it is important to configure correct prefixes on the SAVI device. At least two prefix scopes must be set: the IPv4 prefix and IPv6 prefixes. This document suggests set 3 prefix scopes: IPv4 Prefix: The allowed scope of any kind of IPv4 addresses. It can be set manually. IPv6 SLAAC Prefixes: The allowed scope of SLAAC and manually configured IPv6 addresses. It can be set through snooping RA message from port with SAVI-RA-Trust attribute, or manual configuration. FE80::/64 MUST be set to a feasible prefix. IPv6 DHCPv6 Prefixes: The allowed scope of DHCPv6 addresses. It can be set through DHCP-PD protocol, or manual configuration. If some of the prefix scope is set to have non prefix, it implies corresponding address assignment method is not allowed in the network. Bi Expires April 27, 2010 [Page 8] Internet-Draft savi-dhcp October 2009 There is no need to explicitly present these prefix scopes. But these restrictions MUST be used as premier check in binding set up. 11. Binding Set Up This section specifies the procedure of setting up bindings based on control packet snooping. 11.1. Process of DHCP Snooping 11.1.1. Initialization (Whether to keep this section is left for future discussion) 11.1.1.1. Trigger Event A DHCPv4/v6 Request or a DHCPv6 Confirm is received with an anchor which has the attribute of SAVI-Host or SAVI-Poly. 11.1.1.2. Message Validation The SAVI device checks the Request or Confirm as follows: 1. Whether the limitation on binding entry number of this anchor will be exceeded. 11.1.1.3. Following Actions Forward the REQUEST message. Generate an entry in the Binding State Table (BST), and set the state field to be START. The lifetime of this entry is set to be MAX_DHCP_RESPONSE_TIME. The Transaction ID (Refer to Section 2 in [RFC2131] and Section 4.2 in [RFC3315]) field of the request packet is also recorded in the entry. +---------+----------+-------+-----------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+-----------------------+-------+ | A | | Start |MAX_DHCP_RESPONSE_TIME | TID | +---------+----------+-------+-----------------------+-------+ Figure 4 Binding entry in BST on initialization The TID is kept for assurance that the response from DHCP server can be delivered to the request host. This is left as an open issue for future discussion. Bi Expires April 27, 2010 [Page 9] Internet-Draft savi-dhcp October 2009 11.1.2. From START to LIVE 11.1.2.1. Trigger Event A DHCPv4 DHCPACK or DHCPv6 REPLY message is received. 11.1.2.2. Message Validation The SAVI device checks the message as follows: 1. Whether the message is received with an anchor which has SAVI- DHCP-Trust attribute; 2. Whether the entry in the BST with corresponding TID is in state of START. 11.1.2.3. Following Actions Deliver the message to the destination. Set the state of the corresponding entry to be LIVE. The lifetime of the entry is set to be MAX_ARP_PREPARE_DELAY or MAX_DAD_PREPARE_DELAY respectively. The lease time is also recorded in the entry. +---------+----------+-------+------------------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-------+------------------------+-------+ | A | Addr | LIVE |MAX_ARP_PREPARE_DELAY or| Lease | | | | |MAX_DAD_PREPARE_DELAY | Time | +---------+----------+-------+------------------------+-------+ Figure 5 Binding entry in BST on assignment Or set the state of the corresponding entry to be DETECTION, and send an ARP Request or NSOL for the assigned address. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 6 Binding entry in BST on assignment: another case Insert an entry into the Filtering Table if the assigned address is not bound with another anchor. Bi Expires April 27, 2010 [Page 10] Internet-Draft savi-dhcp October 2009 +---------+----------+ |Anchor |Address | +---------+----------+ |A |Addr | +---------+----------+ Figure 7 Binding entry in FT on assignment 11.1.3. From LIVE to DETECTION (This section should be removed or modified if all the DAD related procedures are to be described in SLAAC document) 11.1.3.1. Trigger Event A gratuitous ARP Request or Duplicate Address Detection Neighbor Solicitation is received from the host. Or a timeout event of an entry with state LIVE happens. 11.1.3.2. Message Validation The SAVI device checks the message as follows: 1. Whether the Target IP address field of the ARP Request or Neighbor Solicitation has been bound with the corresponding anchor in BST or FT. 11.1.3.3. Following Actions If timeout event of an entry with state LIVE happens, send an ARP Request or a DAD NSOL, with target address set to the recorded address in the entry. Set the state of the entry to be DETECTION. The lifetime of the entry is set to be MAX_ARP_DELAY or MAX_DAD_DELAY respectively. +---------+----------+-----------+-----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+-----------------+-------+ | A | Addr | DETECTION |MAX_ARP_DELAY or| Lease | | | | |MAX_DAD_DELAY | Time | +---------+----------+-----------+-----------------+-------+ Figure 8 Binding entry in BST on detection Bi Expires April 27, 2010 [Page 11] Internet-Draft savi-dhcp October 2009 11.1.4. From DETECTION to BOUND 11.1.4.1. Trigger Event A timeout event of an entry with state DETECTION happens or an ARP Response or NA for an address in BST with state DETECTION is received. 11.1.4.2. Following Actions If a timeout event of an entry with state DETECTION happens, set the state of the entry to be BOUND. The lifetime of the entry is set to be the Lease time acknowledged by DHCP server. +---------+----------+-----------+----------------+-------+ | Anchor | Address | State | Lifetime |Other | +---------+----------+-----------+----------------+-------+ | A | Addr | BOUND | Lease time | | +---------+----------+-----------+----------------+-------+ Figure 9 Binding entry in BST on finalization If an ARP Response or NA for an address in BST with state DETECTION is received, remove the corresponding entry in BST and FT. 11.1.5. After BOUND Whenever a DHCP Decline is received from the host, delete the entry in BST and FT. Whenever a DHCP Release is received from the host, if the state of the entry is BOUND, delete the entry in BST and FT. If a DHCPv4 Acknowledgement or DHCPv6 Reply with Renew/Rebind sign is received from the server, set lifetime of the entry in BST to be the new lease time. If the lifetime of an entry with state BOUND expires, delete the entry in BST and Filter Table. 11.2. State Machine of DHCP Snooping State Packet/Event Action Next State - REQUEST/CONFIRM Set up new entry START START ACK Record lease tim LIVE START Timeout Remove entry - Bi Expires April 27, 2010 [Page 12] Internet-Draft savi-dhcp October 2009 LIVE Gra ARP REQ/DAD NS - DETECTION LIVE DECLINE Remove entry - LIVE Timeout Send ARP Req/DAD NS DETECTION DETECTION Timeout - BOUND DETECTION ARP RESPONSE Remove entry - DETECTION DECLINE Remove entry - BOUND RELEASE/DECLINE Remove entry - BOUND Timeout Remove entry - BOUND RENEW/REBOUND Set new lifetime BOUND 12. Filtering Specification This section specifies how to use bindings to filtering packets. 12.1. Filter Data Packet Data packets with anchor which has attribute SAVI-Host or SAVI-Poly are filtered. There can be anchor with neither attributes. If the source of a packet associated with its anchor is in the FT, this packet will be forwarded; or else the packet MUST be discarded. 12.2. Filter Control Packet The source address of DHCPv4 Request/Discovery must be all zero address. The source address of DHCPv6 Request/Confirm must be an address associated with the corresponding anchor in FT. The source address of IPv6 DAD NS and IPv6 gratuitous ARP must pass the check on FT. All DHCP Reply/Ack packets MUST be from anchor with SAVI-DHCP-Trust attribute. The target address and source address in all the Neighbor Advertisement packets and ARP relies must also pass the checks on FT, Bi Expires April 27, 2010 [Page 13] Internet-Draft savi-dhcp October 2009 if they are associated with anchors which have SAVI-Host or SAVI-Poly attribute. 13. Handle port UP/DOWN event These events must be handled when port is used as anchor. 13.1. On port DOWN event Whenever a port with attribute SAVI-Poly or SAVI-Host turns down, the bindings with the anchor SHOULD be 1: removed immediately; 2: or kept until lease time expires; 3: or kept for a short time. The reason for why three choices are made here is there is no perfect solution. If bindings are removed immediately when port turns down, the device may discard legal packets when the link is very flappy. However, this solution has the lightest overhead and simplest design. If bindings are kept until lease time expires, the device can handle the flappy link problem. The device then should make a choice whether to keep the bindings or give up them whenever a Duplicate Address Detection Neighbor Solicitation for the bound address arrives. Either choice actually may lead to some problem. If bindings are kept just for a short time, the flappy link problem can also be handled. Also the device would seldom face the DAD NS for the bound address in that short time. The main problem of this solution is how to set the length of this time. 13.2. On port UP event Whenever a port turns UP, the device can choose either to restore the bindings not removed, or restore the bindings whenever the node uses the address. 14. About Collision in Detection The SAVI device may receive a response in detection. Some related details are specified here. Bi Expires April 27, 2010 [Page 14] Internet-Draft savi-dhcp October 2009 14.1. Whether to notify the DHCP server It is unnecessary for the SAVI device to notify the DHCP server, because the host will send a DECLINE message to it once it finds the advertised address is conflict. 14.2. The result of detection without host aware In case the SAVI device send detection packet instead of the host, the host will not get aware of the detection result. If the detection succeeds, there is no trouble. However, if the detection fails, the packets from the host with the assigned address will be filtered out. This result can be regarded as a reasonable punishment for not performing duplicate detection and using a collision address. 15. Filtering during detection In this mechanism, whenever the DHCP server replies an address, this address will be allowed immediately even before duplicate detection is completed. This design is in consideration of a host may start to send packets straightway without detection. Also this design is to be compatible with optimistic DAD [RFC4429]. However, this feature may allow an attacker to send quantities of packets with source addresses already assigned to other nodes. A practical solution for this vulnerability is configuring the address pool and allocation algorithm of the DHCP server carefully. 16. Binding Number Limitation It is suggested to configure some mechanism in order to prevent a single node from exhausting the binding table entries on the SAVI device. Either of the following mechanism is sufficient to prevent such attack. 1. Set the upper bound of binding number for each anchor with SAVI- Host or SAVI-Poly attribute. 2. Reserve a number of binding entries for each anchor with SAVI-Host or SAVI-Poly attribute and all anchors share a pool of the other binding entries. 17. Constants MAX_DHCP_RESPONSE_TIME 120s MAX_ARP_PREPARE_DELAY Default 1s but configurable Bi Expires April 27, 2010 [Page 15] Internet-Draft savi-dhcp October 2009 MAX_ARP_DELAY Default 1s but configurable MAX_DAD_PREPARE_DELAY Default 1s but configurable MAX_DAD_DELAY Default 1s but configurable 18. Summary of to-be-removed sections and open issues To-be-removed sections: 1. Section 6: Conceptual data structures 2. Section 8: DHCP scenario 3. Part of Section 9: Anchor attributes 4. Section 10: Prefix configuration Open issues (discussed but not finished): 1. Whether to keep state START Should the procedure be initialized based on client request or server response? From Eric Levy-Abegnoli and Christian Vogt. 2. Whether to keep state DETECTION Should DHCP interact with NDP to detect collision or should all the collision detection be left to NDP and the DHCP solution just snoop DHCP only? From Eric Levy-Abegnoli. 19. Security Considerations There are no security considerations currently. 20. IANA Considerations There is no IANA consideration currently. Bi Expires April 27, 2010 [Page 16] Internet-Draft savi-dhcp October 2009 21. References 21.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC5227] S. Cheshire, "IPv4 Address Conflict Detection", RFC5227, July 2008. 21.2. Informative References 22. Acknowledgments Thanks to Christian Vogt, Eric Nordmark, Marcelo Bagnulo Braun, Alberto Garcia, Eric Levy-Abegnoli, Jari Arkko, David Harrington, Pekka Savola, Xing Li, Lixia Zhang, Robert Raszuk, Greg Daley, Joel M. Halpern and Tao Lin for their valuable contributions. Bi Expires April 27, 2010 [Page 17] Internet-Draft savi-dhcp October 2009 Authors' Addresses Jun Bi CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: junbi@cernet.edu.cn Guang Yao CERNET Network Research Center, Tsinghua University Beijing 100084 China Email: yaog@netarchlab.tsinghua.edu.cn Jianping Wu CERNET Computer Science, Tsinghua University Beijing 100084 China Email: jianping@cernet.edu.cn Fred Baker Cisco Systems Email: fred@cisco.com Bi Expires April 27, 2010 [Page 18]