Internet Engineering Task Force Internet Draft L. Dondeti, T. Hardjono, B. Haberman draft-dondeti-ipv6-anycast-security-00.txt Nortel/ Verisign/ Nortel Expires: December 2001 June 2001 Security Requirements of IPv6 Anycast STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 mate- rial or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the security issues within network-layer any- cast protocols. In particular, it focuses on anycast server registra- tion with routers in an IPv6 network. Servers need to be authenti- cated and authorized to provide a particular anycast service. Clients need to be able to verify that an anycast server is authentic. While infrastructure security is the main focus of this document, we also identify the need for secure communication between anycast clients and servers. L. Dondeti, T. Hardjono, B. Haberman [Page 1] Internet Draft IPv6 anycast security requirements Table of Contents 1 Introduction to anycast 2 1.1 Application layer anycast 3 1.2 Network layer anycast 3 1.3 Anycast groups 3 2 Anycast addresses and routing in IPv6 3 3 Security issues of anycast 4 3.1 Unauthenticated anycast server announcements 4 3.2 Source address modification by an anycast server 5 3.3 Secure communication between anycast clients and servers 5 3.4 Anycast security requirements 6 4 Providing secure anycast communication 6 5 Security Considerations 6 6 Acknowledgements 6 7 References 7 8 Authors' contact information 7 1 Introduction to anycast IP anycast is an elegant solution for service discovery in the Inter- net [1]. An IP anycast address is assigned to one or more network interfaces (e.g. routers or hosts/servers) that provide a given ser- vice. A packet sent to an anycast address is delivered to the "topo- logically nearest" network interface with the anycast address. Anycast is an efficient way of providing a service replicated on sev- eral different devices in the Internet. It provides fault-tolerance and some load balancing. In the event of a server failure, packets addressed to an anycast address are routed to the "new nearest" node providing the desired service. Requests originating in different parts of the network may reach different anycast servers, thus pro- viding rudimentary load balancing. Anycast service location works as follows. When a client requires service, it sends the request to the corresponding anycast address. Note that two packets addressed to an anycast address may reach two different anycast servers. Therefore, an anycast client needs to make sure that its request fits in a single packet. The responding anycast server puts its own unicast address as the source address in the reply message. For any stateful communication with an anycast server, the client uses the responding server's unicast address. Future stateless anycast service requests, however, can be sent to the any- cast address. L. Dondeti, T. Hardjono, B. Haberman [Page 2] Internet Draft IPv6 anycast security requirements We differentiate between network layer anycast and application aware or simply application layer anycast. 1.1 Application layer anycast Web caching and ftp service are examples of application layer ser- vices that can benefit from anycast. These services modify the defi- nition of anycast to denote a protocol that finds the "best server" as opposed to the "nearest" server as defined in RFCs 1546 and 2373. The rationale in changing the definition is that it is often desir- able to reach the least loaded server or in other words the server that can provide the fastest service. Anycast requests in this case are routed by application layer devices. 1.2 Network layer anycast Network layer anycast routes anycast requests to the "nearest" (by routing protocol's measure of distance) interface that advertises the anycast address. We list some services that use network layer anycast below [2]: o DNS server discovery [3]. o To locate routers providing an ISP's services. o To reach any router attached to a particular subnet [4]. o To reach any router that provides an entry point into a domain (AS). 1.3 Anycast groups Finally, we end this section by describing the notion of an anycast group. From the perspective of a client, anycast is a service. A service provider enables several nodes to respond to a particular anycast request. We treat all the network nodes responding to an any- cast request as members of an anycast group. We then control member- ship of the anycast group. Routers advertise routes to only autho- rized members of an anycast group. 2 Anycast addresses and routing in IPv6 An IPv6 anycast address is syntactically indistinguishable from a unicast address [2]. This implies that routers treat an anycast address same as a unicast address during routing. However, when an interface is configured with an anycast address, the node with the L. Dondeti, T. Hardjono, B. Haberman [Page 3] Internet Draft IPv6 anycast security requirements interface knows the nature of the address and treats it accordingly. RFC 2373 specifies that an anycast address must not used as the source address of a packet. Thus an anycast server needs to put its unicast address as the sender address in the reply packets. If a client needs followup information, it can send that request to the responding anycast server's unicast address. RFC 2373 also states that anycast addresses can only be assigned to routers, but not hosts. Itojun et. al [5] observe that it is insecure to permit hosts to inject routes to anycast addresses. With anycast group access control [6] mechanisms in place, we may be able to remove this restriction. Knowledge of anycast addresses We know that anycast servers need to know whether an IPv6 address is being used for an anycast service. This is to ensure, among other things, that sender address in the reply packet is the unicast address of the anycast server. Routers in the network do not need to know that an address is being used an anycast address, since no spe- cial treatment is required for routing packets sent to an anycast address. Note that anycast clients also need to know that a particu- lar IPv6 address is an anycast address. There are several reasons. First, recall that an anycast request must be sent in a single packet. Further, the client must not fragment anycast packets. Finally, the client cannot employ simple security checks such as ver- ifying whether sender address of the response packet is same as the destination address in the reply packet. 3 Security issues of anycast Anycast is vulnerable to security attacks similar to unicast and mul- ticast. Clients send requests to an anycast address, to which one the members of the anycast group might respond. Several security threats pertaining to anycast have been identified in earlier works [3,1]. In this document, we describe those and identify additional issues of concern pertaining to anycast data com- munications. Finally, we summarize the security requirements of any- cast. 3.1 Unauthenticated anycast server announcements Any entity in the network can advertise itself as an anycast server. In other words, anycast group membership is not controlled. First, an adversary can use this opportunity to provide false information to a L. Dondeti, T. Hardjono, B. Haberman [Page 4] Internet Draft IPv6 anycast security requirements client [5]. Note that the client has no way of knowing whether the information is legitimate. Second, adversaries can create "black holes" by advertising bogus server addresses. Anycast requests routed to these bogus addresses will reach a fake server, which does not respond to the request. This constitutes a denial of service (DOS) attack. Anycast security requirement 1: Access to anycast group membership must be controlled. We need an anycast server registration mechanism during which access control functions can be performed. Routers must advertise routes of legitimate anycast servers only. 3.2 Source address modification by an anycast server An anycast address cannot be a source address [2] in an IPv6 packet. Consequently, an anycast server responding to a request puts its own address as the source address in the reply packet. Notice that the client has no way of knowing whether the source address is that of a legitimate anycast server or not. Therefore, the client cannot trust the information provided by the anycast server. Also, consider that a client may use the source address for a follow-up request, and that request might go to a bogus server, which might send false informa- tion, or not reply at all. We need anycast source authentication. For example, the anycast server might produce a certificate, signed by a trusted certification authority (CA) that the server belongs to the specified anycast group, in its reply packet. Anycast security requirement 2: Responses to anycast requests may need to be authenticated. 3.3 Secure communication between anycast clients and servers Some anycast services may require secure communication between the clients and servers. This is to imply that we may need to ensure that anycast communications are confident, authenticated and protected against replay attacks. We describe the need for authentication of anycast replies in the previous section. Source authentication or content authentication are suggested solutions in the literature in the context of anycast [3] L. Dondeti, T. Hardjono, B. Haberman [Page 5] Internet Draft IPv6 anycast security requirements or in the context of immediate applications of anycast, viz., DNS [7]. However, notice that both solutions are not protected against replay attacks. For example, a rogue entity in the network can replay out- dated (possibly incorrect) information. The client would have no way of identifying the correct information. An adversary thus can cause denial of service or provide bogus service, even when anycast commu- nications are authenticated. Anycast security requirement 3: We may need secure communication between anycast clients and servers. In other words, anycast communications may need to be confidential, authenticated and protected from replay attacks. 3.4 Anycast security requirements In summary, we list several security requirements of anycast: o Only legitimate anycast servers should be able to advertise them- selves as providers of anycast service. o Anycast clients may need to know the replying server is an autho- rized anycast server. o Anycast communication may need to be confidential. o Anycast clients may want to verify freshness of a reply. 4 Providing secure anycast communication In the current version of the document, we concentrate on identifying the security threats and requirements of anycast communication. Note that most of the issues raised in the above discussion may be solved with existing techniques. We may, however, need to tailor them for anycast. 5 Security considerations In this document, we identify the security issues pertaining to any- cast communications. Briefly, we need to control access to anycast groups. Routers must advertise routes to only authorized members of an anycast group. Replies to anycast requests may need to be authen- ticated, confidential and protected against replay attacks. 6 Acknowledgements L. Dondeti, T. Hardjono, B. Haberman [Page 6] Internet Draft IPv6 anycast security requirements We appreciate Dave Thaler's comments on the security needs of any- cast. 7 References [1] C. Partridge, T. Mendez, and W. Milliken, "Host anycasting ser- vice," RFC (Informational) 1546, Internet Engineering Task Force, Nov. 1993. [2] R. Hinden and S. Deering, "IP version 6 addressing architecture," RFC (Standards Track) 2373, Internet Engineering Task Force, July 1998. [3] DNS Discovery Design Team, Thaler D. (Editor), "Analysis of DNS server discovery mechanisms for IPv6," Internet Draft, Internet Engi- neering Task Force, Mar. 2001. Work in progress. [4] D. Johnson and S. Deering, "Reserved IPv6 subnet anycast addresses," RFC (Standards Track) 2526, Internet Engineering Task Force, Mar. 1999. [5] J. Itojun and K. Ettikan, "An analysis of IPv6 anycast," Internet Draft, Internet Engineering Task Force, Oct. 2000. Work in progress. [6] B. Haberman and D. Thaler, "Host-based anycast using MLD," Inter- net Draft, Internet Engineering Task Force, Feb. 2001. Work in progress. [7] D. Eastlake, "Domain name system security extensions," RFC (Stan- dards Track) 2535, Internet Engineering Task Force, Mar. 1999. 8 Authors' contact information Lakshminath R. Dondeti Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA (978) 288-6406 ldondeti@nortelnetworks.com Thomas Hardjono Verisign Inc. 401 Edgewater Place, Suite 280 Wakefield, MA 01880, USA thardjono@verisign.com Brian Haberman L. Dondeti, T. Hardjono, B. Haberman [Page 7] Internet Draft IPv6 anycast security requirements Nortel Networks 4309 Emperor Blvd., Durham, NC 27703, USA (919) 992-4439 haberman@nortelnetworks.com L. Dondeti, T. Hardjono, B. Haberman [Page 8]