SAVI L. N. Shen, H. W. Zhang Internet Draft M. Wang, Y. J. Zhang Intended status: Informational ICT Expires: March, 2011 August 31, 2010 SAVI Solution for MIPv4 draft-shen-savi-mipv4-00.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. 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 March 4, 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 Shen Expires March 4, 2011 [Page 1] Internet-Draft savi-mipv4 August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document specifies a procedure for creating bindings between HoAs(Home Address) of MIPv4[RFC3344] Mobile Nodes and binding anchors[SAVI-Framework] on SAVI(Source Address Validation Improvements) device in a Foreign Network. The bindings can be used to filter packets generated by the MIPv4 Mobile Nodes in the Foreign Network. Table of Contents Copyright Notice ............................................... 1 Abstract ....................................................... 2 1. Introduction ................................................ 3 2. Conventions used in this document............................ 3 3. Mechanism Overview........................................... 3 4. SAVI MIPv4 Scenario.......................................... 3 5. Conceptual Data Structures................................... 4 5.1. Control Plane Data Structure: Binding State Table (BST). 4 5.2. Data Plane Data Structure: Filtering Table (FT)......... 5 6. MIPv4 Registration Snooping.................................. 6 6.1. Registration via Foreign Agent.......................... 6 6.2. Direct Registration.................................... 7 7. Binding Anchor Attributes.................................... 8 8. Binding State Description.................................... 9 9. Binding State Management..................................... 9 9.1. Binding Set Up.......................................... 9 9.1.1. From NULL to PENDING............................... 9 9.1.1.1. Trigger Event................................. 9 9.1.1.2. Event Validation.............................. 9 9.1.1.3. Following Actions............................. 9 9.1.2. From PNDING to BOUND.............................. 10 9.1.2.1. Trigger Event................................ 10 9.1.2.2. Event Validation............................. 10 9.1.2.3. Following Actions............................ 10 9.1.3. From PNDING to NULL.............................. 10 9.1.3.1. Trigger Event................................ 11 9.1.3.2. Event Validation............................. 11 9.1.3.3. Following Actions............................ 11 9.2. Binding Remove......................................... 11 9.3. State Machine of MIPv4 Snooping........................ 11 Shen Expires March 4, 2011 [Page 2] Internet-Draft savi-mipv4 August 2010 10. Filtering Specification.................................... 12 10.1. Data Packet Filtering................................. 12 10.2. Control Packet Filtering.............................. 12 11. About LifeTime............................................. 13 12. MN CoA Considerations...................................... 13 13. Security Considerations.................................... 13 14. IANA Considerations........................................ 13 15. References................................................. 13 15.1. Normative References.................................. 13 15.2. Informative References................................ 13 1. Introduction SAVI supports all address assignment mechanisms. In mobile ip environment, it's a different situation. In MIPv4, the MN is allowed to use the HoA (home address) as the source address to send packets to the CN (correspondent node), while the HoA is not within the foreign network prefix. This document specifies a mechanism to create bindings between MIPv4 MN's HoAs and trustable anchors. SAVI can use the bindings to validation the source addresses of the packets generated by MIPv4 MNs. This mechanism is a supplement to the other SAVI solutions. 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 This mechanism performs MIPv4 Registration snooping to set up bindings between MN's HoAs and corresponding binding anchors. The bindings will be used to validate the HoA of the packets generated by MIPv4 MN. This mechanism SHOULD be deployed on the access device(access switch, wireless access point, etc). 4. SAVI MIPv4 Scenario Figure 1 depicts a typical MIPv4 scenario in SAVI environment. There is at least one FA (Foreign Agent). The binding process of MIPv4 MN's Shen Expires March 4, 2011 [Page 3] Internet-Draft savi-mipv4 August 2010 HoA is independent of other address binding mechanisms. SAVI-FA-Trusted attribution and SAVI-MN-Validation attribution will be described in section 7. +----------+ | | | FA | | | +----------+ | | SAVI-FA-Trusted +---------------------+ | | | SAVI | | | +---------------------+ | | SAVI-MN-Validation| | +--------+ +--------+ | | | | | MN | | Host_A | | | | | +--------+ +--------+ Figure 1: MIPv4 SAVI Scenario 5. Conceptual Data Structure This section describes the main data structure.It uses the compatible data structure with SAVI DHCP[SAVI-DHCP]. 5.1. Control Plane Data Structure: Binding State Table(BST) +----------+---------+---------+--------------+----------+ | Anchor | Address | State | LifeTime | Other-ID | +----------+---------+---------+--------------+----------+ | A_Anchor | A_CoA | Bound |CoA_Bound_TIME| | +----------+---------+---------+--------------+----------+ | A_Anchor | A_HoA | PENDING |A_PENDING_TIME| A_ID | +----------+---------+---------+--------------+----------+ | B_Anchor | B_HoA | Bound | B_BOUND_TIME | B_ID | +----------+---------+---------+--------------+----------+ | C_Anchor | NULL | PENDING |C_PENDING_TIME| C_ID | +----------+---------+---------+--------------+----------+ Shen Expires March 4, 2011 [Page 4] Internet-Draft savi-mipv4 August 2010 BST maintains all the binding information between SAVI and MIPv4 MN. Here is the detail: Anchor: The trustable binding anchor which is used to validate source address. Switch ports Security Associations are the most common ones. Which kind of anchor to use is up to the implementation, while in wireless environment security associations are recommended. Address: MN's home address or MN's care-of address or NULL address. This field contains the address of the MIPv4's node to bind. The NULL address will temporarily used when MN don't has the HoA. State: This field maintains the binding state.The state transit will be described in section 8. LifeTime: The LifeTime records the lifetime of the binding entry. When the lifetime times out, the entry becomes invalid. Identification: It records the identification of MN's registration request and matches the corresponding registration reply. 5.2. Data Plane Data Structure: Filtering Table(FT) +----------+---------+ | Anchor | Address | +----------+---------+ | A_Anchor | A_CoA | +----------+---------+ | A_Anchor | A_HoA | +----------+---------+ | B_Anchor | B_HoA | +----------+---------+ FT is derived from BST, and contains the bindings between binding anchor and the address.This table is only used to validate the HoA of MIPv4 MN. Here is the detail: Anchor: the trustable binding anchor which will be used to validate source address. Address: MN's home address or MN's care-of address. Shen Expires March 4, 2011 [Page 5] Internet-Draft savi-mipv4 August 2010 6. MIPv4 Registration Snooping This section the process of MIPv4 Registration Snooping. When the MN leaves the home network and enters a foreign network, it has to register its CoA in HA(home agent). There are two registration modes: Registration via Foreign Agent and Direct Registration. The details of MIPv4 Registration are defined RFC3344. 6.1. Registration via Foreign Agent When MN realizes that it enters a foreign network, it initiates the registration procedure. MN sends registration request message to FA. On receiving the registration request, SAVI extracts the necessary information from the request and creates new BST entry, and forward the request. On receiving the registration request, FA processes the request and sends registration request to HA for the MN. HA processes the request and sends registration reply message to FA. On receiving the registration reply, FA processes the reply and sends registration reply to the MN. On receiving the registration reply, SAVI updates the corresponding entry in BST and FT, and forward the reply. Shen Expires March 4, 2011 [Page 6] Internet-Draft savi-mipv4 August 2010 MN SAVI FA HA | | | | | 1.Agnet Discovery | | | |<----------------------------------------->| | | | | | |2.Registratoin Request| | | |--------------------->| | | | | | | | 3.Create BST Entry | | | | | | | | 4.Forward Request | | | |------------------->| | | | | | | | 5.Process Request | | | | | | | |6.Registration Request| | | |--------------------->| | | | | | | | 7.Process Request | | | | | | |8.Registration Reply | | | |<---------------------| | | | | | | 9.Process Reply | | | | | | |10.Registration Rely| | | |<-------------------| | | | | | | 11.Update BST | | | Update FT | | | | | | | 12.Forward Reply | | | |<---------------------| | | | | | | Figure 2: Registration via Foreign Agent 6.2. Direct Registration When MN realizes that it enters a foreign network, before it initiates the registration procedure, MN has to get a valid ip address within the foreign network prefix. The address allocation can be DHCP, manual configuration, etc. The allocated ip address is called Co-located CoA. Note that the Co-located CoA MUST be bound in SAVI. The MN sends registration request to HA directly. On receiving the registration request, SAVI extracts the necessary Shen Expires March 4, 2011 [Page 7] Internet-Draft savi-mipv4 August 2010 information from the request and creates new BST entry, and forward the request. HA processes the registration request, and sends registration reply to MN. On receiving the registration reply, SAVI updates the corresponding entry in BST and FT, and forward the reply. MN SAVI FA HA | | | | | 1.Agnet Discovery | | | |<----------------------------------------->| | | | | | |2.Get Co-located CoA | | | |<-------------------->| | | | | | | | 3.Bind CoCoA | | | | | | |4.Registration Request| | | |--------------------->| | | | | | | | 5.Create BST Entry | | | | | | | | 6.Forward Request | | | |------------------------------------------>| | | | | | | | 7.Process Request | | | | | | | 8.Registration Reply| | |<------------------------------------------| | | | | | 9.Update BST | | | Update FT | | | | | | | 10.Forward Reply | | | |<---------------------| | | | | | | Figure 3: Direct Registration 7. Binding Anchor Attribute SAVI-MN-Validation Attribute is used on binding anchor on which the MN Home Addresses are to be validated. The filtering process on binding anchors with such attribute is described in section 10. Shen Expires March 4, 2011 [Page 8] Internet-Draft savi-mipv4 August 2010 SAVI-FA-Trusted Attribute is used on binding anchor on the path to a trustable Foreign Agent. 8. Binding State Description According to the mobility registration procedure, two states are defined: PENDING and BOUND. PENDING: This state indicates that SAVI has received the registration request message and is waiting for the registration reply message.In this state, the binding between MN's HoA and trustable anchor is incomplete. BOUND: This state indicates that SAVI has received the registration request message and the corresponding reply message which indicates the registration is accepted.In this state, the binding generates an entry in FT to validate the source address of MN. 9. Binding State Management 9.1. Binding Set Up 9.1.1. From NULL to PENDING 9.1.1.1. Trigger Event A Registration Request message is received from SAVI-MN-Validation attribute anchor. 9.1.1.2. Event Validation SAVI checks current BST as follows: 1. Whether the limitation on binding entry number of this binding anchor will be exceeded if a new entry is triggered. 9.1.1.3. Following Actions If the check is failed, the registration request message SHOULD be discarded. If the check is passed,SAVI MUST create an entry for the binding anchor in the Binding State Table (BST), set the state field to PENDING, set the LifeTime field to MAX_PENDING_TIME. The ID field of the request packet MUST also be recorded in the entry. Shen Expires March 4, 2011 [Page 9] Internet-Draft savi-mipv4 August 2010 +----------+---------+---------+----------------+----------+ | Anchor | Address | State | LifeTime | Other-ID | +----------+---------+---------+----------------+----------+ | MN | MN_CoA | PENDING |MAX_PENDING_TIME| MN_ID | +----------+---------+---------+----------------+----------+ Then SAVI MUST forward the Registration Request. 9.1.2. From PNDING to BOUND 9.1.2.1. Trigger Event A Registration Reply message is received from SAVI-FA-Validation attribute anchor. 9.1.2.2. Event Validation SAVI checks current BST and the message as follows: 1. Whether there is an entry with the corresponding ID in PENDING state in the BST. 2. Whether the Reply indicates the Request is accepted. 9.1.2.3. Following Actions If check1 failed, SAVI SHOULD forward the Registration Reply. If check1 passed and check2 passed,SAVI MUST records LifeTime in the Reply message in the corresponding entry and HoA if necessary, and set the State filed from PENDING to BOUND. +----------+---------+---------+----------------+----------+ | Anchor | Address | State | LifeTime | Other-ID | +----------+---------+---------+----------------+----------+ | MN | MN_HoA | BOUND | BOUND_LIFETIME | MN_ID | +----------+---------+---------+----------------+----------+ A corresponding entry MUST be generated in the FT. +-----------+----------+ | Anchor | Address | +-----------+----------+ | MN_Anchor | MN_CoA | +-----------+----------+ 9.1.3. From PNDING to NULL Shen Expires March 4, 2011 [Page 10] Internet-Draft savi-mipv4 August 2010 9.1.3.1. Trigger Event A Registration Reply message is received from SAVI-FA-Validation attribute anchor. 9.1.3.2. Event Validation SAVI checks current BST and the message as follows: 1. Whether there is an entry with the corresponding ID in PENDING state in the BST. 2. Whether the Reply indicates the Request is denied. 9.1.3.3. Following Actions SAVI MUST delete the corresponding entry in the BST. 9.2. Binding Remove 1. SAVI receives Registration Reply message with the corresponding ID in PENDING state in the BST and the Reply indicates the Registration Request is denied. 2. The entry in BOUND state in the BST times out. The corresponding entry in the FT MUST also be removed. 3. The entry in PENDING state in the BST times out. 9.3. State Machine of MIPv4 Snooping The main state transits are listed as follows. Note that precondition of state transit is not included. Triggering events must satisfy the preconditions before changing the state. Shen Expires March 4, 2011 [Page 11] Internet-Draft savi-mipv4 August 2010 +----------+--------------------+--------------+--------------+ | State | Event | Actions | Next State | +----------+--------------------+--------------+--------------+ | NULL |Registration Request|Generate Entry| PENDING | +----------+--------------------+--------------+--------------+ | PENDING | Timeout | Remove Entry | NULL | +----------+--------------------+--------------+--------------+ | PENDING | Registration Reply | Record | BOUND | | | = Success | LifeTime | | +----------+--------------------+--------------+--------------+ | PENDING | Registration Reply | Remove Entry | NULL | | | = Failure | | | +----------+--------------------+--------------+--------------+ | BOUND | Timeout | Remove Entry | NULL | +----------+--------------------+--------------+--------------+ 10. Filtering Specifications Agent Solicitation/Advertisement, Registration Request/Reply are treated as Control Packets, and others are treated as Data Packets. 10.1. Data Packet Filtering Data packets with a binding anchor which has attribute SAVI-MN- Validation MUST be checked. If the source address of a packet associated with its binding anchor is in the FT, this packet SHOULD be forwarded; or else the packet SHOULD be discarded, or alternatively the SAVI SHOULD record this violation. 10.2. Control Packet Filtering Forward Agent Solicitation Message from binding anchor with the SAVI- MN-Validation attribute. Forward Registration Request Message from binding anchor which with the SAVI-MN-Validation attribute. Discard Agent Advertisement Message not from binding anchor with the SAVI-FA-Trust attribute. Discard Registration Reply messages not from binding anchor with the SAVI-FA-Trust attribute. Shen Expires March 4, 2011 [Page 12] Internet-Draft savi-mipv4 August 2010 11. About LifeTime The LifeTime field in BST records the lifetime of the entry. In PENDING state, lifetime records the PENDING_TIME, which indicates the Registration Reply is expected within PENDING_TIME. If it timed out, the entry is removed. In BOUND state, lifetime records the lifetime in Registration Reply message, which indicates the HoA of the MN is registered to use. 12. MN CoA Considerations In Registration Via FA mode, FA can validate MN and HA. While in Direct Registration mode, MN registers to HA directly using co-located CoA. Although Co-located CoA MUST be bound in SAVI, it's still lack of validation of MN's HoA and HA. In this solution for MIPv4, Registration via Foreign Agent is recommended. 13. Security Considerations 1. When MN uses Co-located CoA and registers to HA directly, MN and HA may cooperate to deceive SAVI. As described in section 12, Registration via Foreign Agent is recommended, even when MN can get Co-located CoA. In agent advertisement, the R bit SHOULD be set. 2. A malicious MN can keep sending forged Registration Request, which takes up a lot of entries in BST. One improvement is rate limitation. 14. IANA Considerations There is no IANA consideration currently. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.2. Informative References Shen Expires March 4, 2011 [Page 13] Internet-Draft savi-mipv4 August 2010 [SAVI-Framework] Vogt, CV., "Source Address Validation Improvement Protocol Framework", draft-vogt-savi-framework-01, October 2009. [SAVI-DHCP] Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for DHCP", draft-ietf-savi-dhcp-05, July 2010. [RFC3344] C. Perkins, Ed., Nokia Research Center, "IP Mobility Support for IPv4", RFC3344, August 2002 Authors' Addresses Lingnan Shen ICT Email: shenlingnan@ict.ac.cn Hanwen Zhang ICT Email: hwzhang@ict.ac.cn Miao Wang ICT Email: wangm@ict.ac.cn Yujun Zhang ICT Email: zhmj@ict.ac.cn Shen Expires March 4, 2011 [Page 14]