Source Address Validation H. Li Improvements WG Y. Li Internet-Draft Huawei Technologies Intended status: Standards Track July 6, 2009 Expires: January 7, 2010 Source Address Validation via Shared Key draft-li-savi-skey-00 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 January 7, 2010. 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 describes a mechanism to provide source address validation for IPv6 networks using a shared key (Skey) signature Li & Li Expires January 7, 2010 [Page 1] Internet-Draft Souce Address Validation by shared key July 2009 approach. The basic idea is that a device generates a signature using a shared key and its IP address and then the signature is sent to a validating device for source address validation. The proposed mechanism is intended to complement ingress filtering techniques with a finer granularity on the control of the source addresses used. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design considerations . . . . . . . . . . . . . . . . . . . . . 4 2.1. Scope of Skey SAVI . . . . . . . . . . . . . . . . . . . . 4 2.2. Constraints for Skey SAVI . . . . . . . . . . . . . . . . . 4 2.3. Address ownership proof . . . . . . . . . . . . . . . . . . 4 3. Skey SAVI specification . . . . . . . . . . . . . . . . . . . . 5 3.1. Skey SAVI data structures . . . . . . . . . . . . . . . . . 5 3.2. Share key and related information . . . . . . . . . . . . . 5 3.3. Skey SAVI algorithm . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Processing of hosts . . . . . . . . . . . . . . . . . . 6 3.3.2. Processing of Skey device . . . . . . . . . . . . . . . 7 4. Handling special cases . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Li & Li Expires January 7, 2010 [Page 2] Internet-Draft Souce Address Validation by shared key July 2009 1. Introduction In order to alleviate the overburden of networks and provide a security control over users' packets, operators' devices need to filter illegal packets from malicious users. Drafts [draft-ietf-savi-send-00] and [draft-ietf-savi-fcfs-01] proposed in SAVI WG introduced different mechanisms to provide source address validation for IPv6 networks. Mechanisms proposed in both drafts are based on anchors, such as MAC, Port and VLAN. In an operator's network, there may exist more than one potential anchor to be used, which may vary greatly in different access networks. Figure1 shows a scenario where anchors may vary over time. Host A is moving between access point 1 (AP1) and access point 2 (AP2). It is assumed that host A connects to the network via PPPoE through AP1 and connects to network via PPPoA through AP2. Both connections go to a SAVI device. If it is a SeND or FCFS SAVI device, it will cache the binding information of the IP address of host A and the relevant L2 information which may be obtained by snooping the packet from/to host A. When host A attaches to AP1, SAVI device may bind IP address of host A with its MAC address. When host A attaches to AP2, it is possible that SAVI device needs to bind the IP address of host A with its virtual circuit information. If host A keeps moving between AP1 and AP2, SAVI device needs to frequently update the binding information of host A. +--------+ +------+ PPPoE access +-----------+ | Host A +-------| AP1 |-----------------|SAVI device| +--------+ +------+ | | | | | \|/ |(binding | +--------+ +------+ PPPoA access | cache) | | Host A +-------| AP2 |-----------------| | +--------+ +------+ +-----------+ Figure 1: Anchor info varies for nomadic user This document proposes a shared key (SKey) based mechanism for SAVI implementation. It binds user's IP address with a shared key. L2 information such as MAC or VLAN is not required. A shared key based signature is used for source address validation, which offloads validating device from L2 network information management. Shared key is more suitable for moving scenarios, while anchors comprised of shared keys and related information can be treated as non-volatile anchors cached by the validating device. This SKey mechanism is applicable to both IPv4 and IPv6, and is intended to complement ingress filtering techniques with a finer granularity on the control of the source addresses used. Li & Li Expires January 7, 2010 [Page 3] Internet-Draft Souce Address Validation by shared key July 2009 2. Design considerations 2.1. Scope of Skey SAVI Skey SAVI could be only applied to a network where routers support IP Authentication Header protocol and all hosts share a key with the router. Skey SAVI is used to verify the source address of a packet generated by a host connected to the local link, as SAVI working group mainly addresses problems in LAN environment . As described in [draft-ietf-savi-send-00], there are local traffic and transit traffic in a local link. Shared key SAVI can be used for local traffic. In other words, Skey SAVI can verify if the traffic generated by the hosts attached to the local link contains a valid source address or not. The verification of the source address of the transit traffic is out of scope of this document. Other techniques, such as ingress filtering [RFC2827], are recommended for transit traffic validation. In that sense, Skey SAVI is a complement to ingress filtering as it provides the validation of local traffic only, while relies on the latter to validate transit traffic. Hence, the security level is increased by using these two techniques together. It is also easy for Skey SAVI to be extended to other scenarios, e.g. a host sharing a key with a router which is not on a same local link. 2.2. Constraints for Skey SAVI Skey SAVI is designed for easy deployment in existing networks with a minimum set of changes. Many operating systems, such as Windows, are able to generate a signature using a shared key. Usually host and access router share a symmetric key. IPv6 protocol uses the next header field to specify the protocol it carries. The carried protocol [RFC2402] can contain a signature signed by a host. Hence Skey SAVI does not require any changes in the hosts and verification purely relies on the usage of existing protocols. Skey SAVI validation is performed by Skey SAVI function. Such function can be placed in different types of devices, such as a router or a layer-2 bridge. The basic idea is that the Skey SAVI function is located at a device in the network that can enforce the correct usage of source address by dropping the non-compliant packets. 2.3. Address ownership proof The main function performed by Skey SAVI is to verify that source addresses used in data packets actually belong to the originator of Li & Li Expires January 7, 2010 [Page 4] Internet-Draft Souce Address Validation by shared key July 2009 packets. In Skey SAVI address ownership if proved based on shared key validation. A shared key is used to generate a signature contained in packets. Signature then is used to bind the shared key with an IP address that is used by a node as the source IP address of packets. By comparing signatures, we can verify the source address used in any packet. 3. Skey SAVI specification 3.1. Skey SAVI data structures Skey SAVI function relies on a signature to validate source addresses used in data packets. The signature is based on a shared key. Source address and hash algorithm are used to generate the signature. Such information is stored in Skey SAVI Database (DB). The Skey SAVI DB will contain a set of entries of currently used IP source addresses. Each entry contains the following information: o IP source address o shared key o shared key lifetime o hash algorithm Additionally, Skey SAVI needs to know what are prefixes directly connected, so it maintains a data structure called Skey SAVI prefix list, which contains: o Prefix o Interface where prefix is directly connected Finally, Skey SAVI keeps a list of routers that are directly connected in order to avoid directly applying Skey SAVI verification to them. In the Skey SAVI Router List, the following information is stored: o Router's IP address (of the directly connected interface) o Router's Layer-2 information, such as layer-2 address or port which the router is connected to 3.2. Share key and related information Before the Skey SAVI device can validate the source address from a host, host and router should get a shared key and relavant information. There are two ways to get these information, statically configuration to hosts and routers or a dynamic negotiation mechanism used between hosts and routers. Li & Li Expires January 7, 2010 [Page 5] Internet-Draft Souce Address Validation by shared key July 2009 3.3. Skey SAVI algorithm 3.3.1. Processing of hosts When a host sends a packet to the network, it checks its local database to find a shared key which is shared between Skey SAVI device and itself. If such a shared key is not found, the host may try to get one. For example, the host can retrieve a shared key using dynamic negotiation mechanism such as public key Encryption protocol. The host may prompt an alert to user to inform that the shared key is lost and/or a shared key is required. If the shared key's lifetime is expired, the host should update the shared key by certain dynamic mechanism. The hash algorithm that relates to a shared key can be one of those listed below. o MD5 o RIPEMD o SHA o TIGERR o WHIRLPOOL The host uses the shared key and its IP address to generate a signature by a hash algorithm corresponding to the share key. Only one hash algorithm is bound to a shared key. Information to be hashed includes the IP header, payload of IP packet and the shared key. In order to avoid the replay attack, a nonce or time stamp value may be put in RESERVED field or Security Parameters Index field of authentication header (AH) with Authentication Data field set to Zero to generate the signature. The signature generated is put into Authentication Data of AH, which is inserted to IP packet and sent to Skey SAVI device by the host. The signature of the host can be carried in authentication header indicated in next header of IP packets. Figure 2 indicates the IPv4 packet format with Skey signature and Figure 3 indicates the IPv6 packet format with Skey signature. +------------+-------------------------+----------------------+ | IP header | Skey signature |Upper layer protocol | +------------+-------------------------+----------------------+ Figure 2: Skey singnature in IPv4 packet Li & Li Expires January 7, 2010 [Page 6] Internet-Draft Souce Address Validation by shared key July 2009 +-----------+-------------+----------------+----------------------+ | IP Header | Hop-by-Hop | Skey signature | Upper layer protocol | | | routing | | | +-----------+-------------+----------------+----------------------+ Figure 3: Skey singnature in IPv6 packet 3.3.2. Processing of Skey device When Skey SAVI device gets an IP packet, it will check whether there is a signature in the authentication header field of the packet. If there is no signature, Skey SAVI device will discard the packet or redirect it to other devices. If there is a signature in the field, the Skey SAVI function will verify the source address used in the packet. To do the verification, Skey SAVI function searches the Skey SAVI DB using the IP source address as a index. If no entry is found, the Skey SAVI may discard the packet or perform a shared key negotiation mechanism. If an entry is found, the Skey SAVI gets the shared key and the hash algorithm from the entry. By using the IP source address, shared key, nonce or time-stamp (if there is one in the packet ) and hash algorithm as input, Skey SAVI function generates another signature. Skey SAVI function compares the signature generated by itself with the signature carried in received packet. If two signatures are exactly the same, it implies the host who sent the packet is the owner of source IP address. Skey SAVI then removes the authentication header of the packet and forwards it to the network. If the signatures are different, the packet should be discarded. 4. Handling special cases Skey SAVI function naturally supports the following special cases: o Hosts with multiple IP addresses will be able to pass the signature check. In this case, multiple IP addresses correspond to the same shared key. o Proxy ND is naturally supported, since the signature is bound to the source IP address. o Mobile nodes are also naturally supported, since Skey SAVI DB contains IP source addresses and share keys. o Anycast services can also be supported. In this case, all nodes should have the share key, so they all can pass the signature procedure. The Skey SAVI DB entry will contain multiple layer-2 addresses for a same IP address. Li & Li Expires January 7, 2010 [Page 7] Internet-Draft Souce Address Validation by shared key July 2009 5. Security Considerations Skey SAVI does not introduce any extra security vulnerability to the network. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [RFC2402] IETF, "IP Authentication Header", November 1998, . [RFC2827] IETF, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", May 2000, . [RFC3118] IETF, "Authentication for DHCP Messages", June 2001, . [draft-ietf-savi-fcfs-01] IETF, "First-Come First-Serve Source-Address Validation Implementation", March 2009, . [draft-ietf-savi-send-00] IETF, "SeND-based Source-Address Validation Implementation", January 2009, . Authors' Addresses Hongyu Li Huawei Technologies Shenzhen, China Phone: +86-755-28973567 Fax: Email: lihy@huawei.com URI: Li & Li Expires January 7, 2010 [Page 8] Internet-Draft Souce Address Validation by shared key July 2009 Yizhou Li Huawei Technologies Huihong Mansion, No. 91 Baixia Rd Nanjing, 210001 China Phone: +86-25-84565887 Fax: Email: liyizhou@huawei.com URI: Li & Li Expires January 7, 2010 [Page 9]