Internet DRAFT - draft-dondeti-ipv6-anycast-security
draft-dondeti-ipv6-anycast-security
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]
