Network Working Group J. Kaippallimalil Internet-Draft F. Xia Expires: September 1, 2009 Huawei USA February 28, 2009 Access Node Control Protocol for Source Adress Validation draft-kaippallimalil-ancp-sav-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. 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 September 1, 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. Kaippallimalil & Xia Expires September 1, 2009 [Page 1] Internet-Draft ANCP for SAVI February 2009 Abstract This document specifies an extension of Access Node Control Protocol to provide source address validation for IPv4 and IPv6 networks. An access router uses the proposed mechanism to provision source address validation states on a layer 2 device which a host may directly connects to. The solution proposed here can be used in either public access networks or enterprise networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. ANCP overview . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ANCP/TCP connection establishment . . . . . . . . . . . . 5 3.2. ANCP Connection keep-alive . . . . . . . . . . . . . . . . 5 3.3. Capability negotiation . . . . . . . . . . . . . . . . . . 5 4. ANCP based Source Address Validation . . . . . . . . . . . . . 6 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Kaippallimalil & Xia Expires September 1, 2009 [Page 2] Internet-Draft ANCP for SAVI February 2009 1. Introduction Validating source prefix/address on an IP link help to prevent a host from spoofing other IP prefixes. The network access server (NAS) or access router (AR) can validate source prefixes. In some networks, it may be desirable to validate the source prefix at a switch between the host and access router. This memo proposes a means to install state information for validating source address/prefix on such a switch. The access router can provide the switch the required state information to validate prefixes. State information for validation includes the IP prefix/address and some lower layer identities. Lower layer identities that the host asserts as authentic are bound to the IP prefix by the NAS. For example, an IP prefix, MAC address and line identity or connection identifier may be used to validate an established session. Details about building up a correlation between IP addresses and lower-layer binding anchors is beyond the scope of the document. The scope of this document is about how to provision state information on a source prefix validation switch that is not is not collocated with the access router. Currently, some network switches snoop protocols to build source validation state information. However, there are several reasons to consider providing this state to the source validation switch explicitly: o Some communication channels or protocols may not be possible to snoop. This may be because the connection is ciphered or the protocol uses its own end-to-end encryption. Examples include EAP encryption, SeND/CGA. o As access network supports new capabilities (e.g. nomadic behavior, roaming) and protocols (e.g. IPv6), the source validation switch should be modified to snoop various protocols and change state building software. This would increase the complexity of the switch. o Snooping obtains information "implicitly" (and thus subject to change when any authentication, signaling on the path changes). Explicitly configuring state with a protocol would allow the source validation switch to remain unmodified. The use of ANCP to configure source validation state would mean that the switch would now have to process this protocol. However, some switches (e.g. DSLAM) already terminate ANCP and only needs support for these extensions. For other switches which do not support ANCP already, the trade-off would be between supporting ANCP or the complexity of snooping various protocols, or not being able to snoop Kaippallimalil & Xia Expires September 1, 2009 [Page 3] Internet-Draft ANCP for SAVI February 2009 at all. An architecture that implements a switch and access router in different devices is the fixed broadband network illustrated in Figure 1. However, this is not limited to one specific deployment or architecture. After the router establishes relationship of a host between a binding anchor and an IP address, the router provisions the switch with the relationship. Thus, source address validation can be enforced in the switch which is nearer the hosts than the router. +-------+ +-------+ Host 1----------| | | | | | | | | | | | | | ANCP | | Host 2----------|Switch |<------->| Router| |(DSLAM)| | (NAS) | | | | | | | | | Host 3----------| | | | +-------+ +-------+ Figure 1: Source Address Validation in Layer 2 device 2. Terminology 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]. SAVI state: the relationship between a host's IPv4/IPv6 address (or IPv6 prefix) and low layer binding anchor. It may also includes forwarding flag "allowed/not allowed" regarding some IP addresses. 3. ANCP overview ANCP specified in [I-D.ietf-ancp-protocol] describes extensions to the GSMPv3 protocol to allow its use in a broadband environment. ANCP focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM. It is intended to be augmented by additional protocol specification for future use Kaippallimalil & Xia Expires September 1, 2009 [Page 4] Internet-Draft ANCP for SAVI February 2009 cases. 3.1. ANCP/TCP connection establishment ANCP uses TCP for exchanging protocol messages. [RFC3293] defines the GSMP message encapsulation for TCP. The TCP session is initiated from the switch to the router. Please refer to [I-D.ietf-ancp-protocol] for detail. 3.2. ANCP Connection keep-alive GSMPv3 defines an adjacency protocol. The adjacency protocol is used to synchronize states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. ANCP extends the protocol to accommodate DSL networks. Please refer to [I-D.ietf-ancp-protocol] for detail. 3.3. Capability negotiation The adjacency message as defined in [RFC3292] is extended in ANCP to carry technology specific "Capability TLVs". Both the switch and the router advertise supported capabilities in the originated adjacency messages. In addtion to existing capability types, the following capability is defined for source address validation. 5. Capability Type : Source-Address-Validation = 0x1F Length (in bytes) : 0 Capability Data : NULL Kaippallimalil & Xia Expires September 1, 2009 [Page 5] Internet-Draft ANCP for SAVI February 2009 4. ANCP based Source Address Validation +----+ +-------------+ +-----------+ |Host| |Switch(DSLAM)| |Router(NAS)| +----+ +-------------+ +-----------+ | | | | 1 Authentication,DHCPv4&v6 | | Neighbor Discovery, or other processing | |<==========================================>| | | | | | 2 SAVI state | | establishment | | | | | 3 ANCP(SAVI-State-Add) | | |<------------------------| | | | | 4 SAVI Enforcement | | | | | | 5 SAVI state | | cleaning | | | | | 6 ANCP(SAVI-State-Del) | | |<------------------------| Figure 2: SAVI State Synchronization 1. Address configuration. Before sending any packets, the host MUST configure its IPv4/IPv6 address. The host may get its IP address from an AAA server during authentication, e.g, PPPoX. The host may also allocate a IPv4 or IPv6 address from a DHCPv4 or DHCPv6 server. In IPv6 case, the host may use statelss address configuration procedure to configure its address. 2. Whatever the procedure the host uses to configure its address, the router also establishes a binding with a lower layer identity (such as MAC id) and IPv4 or IPv6 address (or prefix) information, that is, a SAVI state is establised. 3. To enforce distributed soure address validation, the router installs the SAVI state in a switch using ANCP protocol. A new message called SAVI-State-Add is defined in Section 5. 4. The switch inspects each packet to match its IP address and low layer binding anchor using the SAVI state installed by the router. Any unmatched packet is discarded. Kaippallimalil & Xia Expires September 1, 2009 [Page 6] Internet-Draft ANCP for SAVI February 2009 5. When the host does not use the IP address any more, the router cleans the SAVI state. The router can detect the reachability through IPv6 Neighbor Unreachability Detection procedure in IPv6, or ARP aging in IPv4. 6. The router deletes the SAVI state through the new defined ANCP message Type SAVI-State-Add detailed in Section 5. In some case, the host uses its IP address without any address configuration signalling exchange between the host and the router, e.g. the host with a manual configured IPv4 or IPv6 address. The figure illustrated below shows the SAVI state installation. +----+ +-------------+ +-----------+ |Host| |Switch(DSLAM)| |Router(NAS)| +----+ +-------------+ +-----------+ | | | | 1 Data Packet | | |----------------->| | | | | | 2 Check SAVI State | | | | | | 3 ANCP(SAVI-State-Req) | | |------------------------>| | | | | | 4 ANCP(SAVI-State-Add) | | |<------------------------| | | | Figure 3: SAVI State Establishment through Data Packet Trigger 1. The host sends a packet. 2. The switch does not find any SAVI state installed. To process the packet optimistically, the switch forwards the packet. 3. At the same time, the swich requests the router to install a SAVI state. A new defined message called SAVI-State-Req is detailed in Section 5. 4. The router installs the SAVI state in switch using ANCP message SAVI-State-Add. Then, the switch either forwards packets with the specific IP address or denies them. 5. Message Format [I-D.ietf-ancp-protocol] specifies the ANCP message format as below. Kaippallimalil & Xia Expires September 1, 2009 [Page 7] Internet-Draft ANCP for SAVI February 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub | Message Type | Result| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Message Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: ANCP message Three new message types are defined here: 1. SAVI-State-Req ( value is TDB ) 2. SAVI-State-Add ( value is TDB ) 3. SAVI-State-Del ( value is TDB ) As to SAVI-State-Add message, Code field is used to identify allowed/ not allowed forwarding flag for packets with the IP and low-layer anchor binding information in this message. The description for the other fields is referred to [I-D.ietf-ancp-protocol]. The message payload field is illustrated as below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Family Number | IP Adress (v4 or v6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Adress ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ TLVs ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Message payload Address Family Number field is as defined in [IANAADFAM]. TLVs fields are used for containing lower layer binding anchor information. Kaippallimalil & Xia Expires September 1, 2009 [Page 8] Internet-Draft ANCP for SAVI February 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Value ~ ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: General TLV The value field is padded to a 4-octet alignment. The Length field in each TLV contains the actual number of bytes in the TLV (not including the padding if present). If a TLV is not understood by the access-node, it is silently ignored. The TLV is used to identify different Lower-Layer Binding Anchors: o Type = 0x01: switch port o Type = 0x02: MAC address o Type = 0x03: radio channel o Type = 0x04: security association o Type = 0x05: DSL VC-or-equivalent o Type = 0x06: Cable Modem customer channel 6. Security Considerations 7. Acknowledgements The authors would like to thank Sven Ooghe, and Roberta Maglione for their valuable review. 8. References 8.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. [IANAADFAM] "IANA", . Kaippallimalil & Xia Expires September 1, 2009 [Page 9] Internet-Draft ANCP for SAVI February 2009 8.2. Informative References [I-D.ietf-ancp-protocol] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, N., and R. Maglione, "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-04 (work in progress), November 2008. Kaippallimalil & Xia Expires September 1, 2009 [Page 10] Internet-Draft ANCP for SAVI February 2009 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 Kaippallimalil & Xia Expires September 1, 2009 [Page 11]