One document matched: draft-daley-send-spnd-prob-00.txt
Network Working Group G. Daley
Internet-Draft Monash University CTIE
Expires: January 10, 2005 July 12, 2004
Securing Proxy Neighbour Discovery Problem Statement
draft-daley-send-spnd-prob-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Proxy Neighbour Discovery is used to provide an address presence on a
link from hosts which are absent. It allows a host to receive
packets directed at its address by allowing another device to
neighbour advertise on its behalf.
Proxy Neighbour Discovery is used in Mobile IPv6 and related
protocols to provide reachability from hosts on the home network when
a Mobile Node is not at home, by allowing the Home Agent to act as
proxy.
Daley Expires January 10, 2005 [Page 1]
Internet-Draft Securing PND Problem Statement July 2004
Proxy Neighbour Discovery currently cannot be secured using SEND.
SEND assumes that a node advertising an address is the address owner
and in possession of appropriate public and private keys for that
node. This document describes how existing practice for proxy
Neighbour Discovery relates to Secured Neighbour Discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Proxy Neighbour Discovery and SEND . . . . . . . . . . . . . . 4
3. Proxy ND in Mobility . . . . . . . . . . . . . . . . . . . . . 4
4. Potential Approaches to Securing Proxy ND . . . . . . . . . . 5
5. Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7.1 Router Trust Assumption . . . . . . . . . . . . . . . . . 6
7.2 Certificate Transport . . . . . . . . . . . . . . . . . . 7
7.3 Timekeeping . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Daley Expires January 10, 2005 [Page 2]
Internet-Draft Securing PND Problem Statement July 2004
1. Introduction
Proxy Neighbour Discovery is defined in IPv6 Neighbour Discovery and
is used in Mobile IPv6 [2][4]. It allows a device which is not
physically present on a link to have another advertise its presence,
and forward on packets to the off-link device.
Proxy Neighbour Discovery relies upon another device, the proxy, to
monitor for Neighbour Solicitations, and answer with Neighbour
Advertisements. These proxy Neighbour Advertisements direct data
traffic through the proxy. Proxied traffic is then forwarded on to
the end destination.
When moving in the Internet, the aim of Mobile IPv6 is to allow a
device continued packet delivery, whether present on its home network
or not. For Mobile IPv6 Mobile Nodes (MNs), it is necessary to keep
existing sessions going even when one leaves the home network. If a
neighbour is actively delivering packets to a Mobile Node which is at
home, this neighbour will have a valid neighbour cache entry pointed
at the MN's link-layer address on the Home link.
If Cryptographically Generated Addressing (CGA) is available, the MN
may be able to secure its neighbour cache bindings while at home
using Secured Neighbour Discovery (SEND) [5]. SEND assumes that the
address owner is the advertiser and therefore has access to the keys
required to sign advertisements about the address.
Movement away from the home link requires that a proxy undertake
Neighbour Discovery. In Mobile IPv6, the role of the proxy is
undertaken by the Home Agent. While the Home agent has a security
association with the MN, it as proxy will not have access to the
public-private key pair used to generate the MN's cryptographic
address. This prevents Proxy Neighbour Discovery from using SEND as
defined [5].
Where a host moves from the home network to a visited network, the
proxy needs to override existing valid neighbour cache entries which
may have SEND protection. This is needed in order to redirect
traffic to use the proxy's link-layer address, allowing packets to
flow onto the tunnel connecting the Home Agent/Proxy and the MN.
With current specifications, any solicitation or advertisement sent
by the proxy will not be able to update the MN's home address if the
existing NC entry is protected by SEND. Such existing neighbour
cache entries will time-out after Neighbour Unreachability Detection
[2].
Where secured proxy services are not able to be provided, a proxy's
advertisement may be overridden by a bogus proxy without it even
Daley Expires January 10, 2005 [Page 3]
Internet-Draft Securing PND Problem Statement July 2004
knowing the attack has occurred.
This document describes some of the issues in providing security for
proxy Neighbour Discovery, and how Mobile IPv6 interacts with these
requirements.
2. Proxy Neighbour Discovery and SEND
There are currently no existing secured Neighbour Discovery
procedures for proxied addresses, and all Neighbour Advertisements
from SEND nodes are required to have equal source and target
addresses (section 7.4 of [5]).
Signatures over SEND messages are required to be applied on the CGA
source address of the message, and there is no way of indicating that
a message is proxied. Therefore, a router wishing to provide proxy
Neighbour Advertisement service can not use SEND on those messages.
A host may wish to establish a session with a device which is not
on-link but is proxied. As a SEND host, it prefers to create
neighbour cache entries using secured procedures. Since SEND
signatures cannot be applied to an existing proxy Neighbour
Advertisement, it must accept non-SEND advertisements in order to
receive proxy Neighbour Advertisements.
Neighbour Cache spoofing of another host therefore becomes trivial,
as any address may be proxy advertised to the SEND node, and
overridden only if the node is there to protect itself. When a node
is present to defend itself, it may also be difficult for the
solicitor determine the difference between a proxy-spoofing attack,
and a situation where a proxied device returns to a link and
overrides other proxy advertisers [2].
Initiation of Proxy Neighbour Discovery also requires Duplicate
Address Detection (DAD) checks of the address[3]. These DAD checks
need to be performed by sending Neighbour Solicitations, from the
unspecified source address, with the target being the proxied
address.
In SEND, the address which is used for CGA tests on DAD NSs is the
target address. A Proxy is unable to generate a signature for this
address and must undertake DAD with an unsecured NS.
3. Proxy ND in Mobility
Whenever a mobile device moves off a link and requires another device
to forward packets from that address to the MN's new location, proxy
Neighbour Discovery is required.
Daley Expires January 10, 2005 [Page 4]
Internet-Draft Securing PND Problem Statement July 2004
In the Mobile IPv6 case, where the Mobile Node moves away from home,
a Home Agent needs to be able to override existing neighbour cache
entries in order to redirect packet flow over a tunnel to the Mobile
Node's CoA [4].
In Fast Handovers for Mobile IPv6, local neighbours or routers with
existing valid neighbour cache states need to be told the PAR's
link-layer address when the MN is departing for a new link, or after
arrival on the new link when tunnel forwarding begins[6]. This
allows the MN to maintain reachability to the hosts on that link
until it is able to send Mobile IPv6 Binding signalling subsequent to
address configuration on the new network.
4. Potential Approaches to Securing Proxy ND
SEND nodes already have the concept of delegated authority through
requiring external authorization of routers to perform their routing
and advertisement roles. The authorization of these routers takes
the form of delegation certificates.
Proxy Neighbour Discovery requires a delegation of authority on
behalf of the absent address owner, to the proxier. Without this
authority, other devices on the link have no reason to trust an
advertiser.
Existing trust relationships lend themselves to providing authority
for proxying in two alternative ways.
First, the SEND router authorization mechanisms described above
provide delegation from the organization responsible for routing in
an address domain, to the certified routers. It may be argued that
routers so certified may be trusted to provide service for nodes
which form part of a link's address range, but are themselves absent.
Second, where the proxied address is itself a CGA, the holder of the
public and private keys is seen to be authoritative about the
address' use. If this address owner was able to sign the proxier's
address and public key information, it would be possible to identify
that the proxy is known and trusted by the CGA address owner for
proxy service. This method requires that the proxied address know or
learn the proxy's address and public key, and that the certificate
signed by the proxied node's is passed to the proxy, either while
they share the same link, or at a later stage.
In both methods, the original address owner's advertisements need to
override the proxy if it suddenly returns, and therefore timing and
replay protection from such messages need to be carefully considered.
Daley Expires January 10, 2005 [Page 5]
Internet-Draft Securing PND Problem Statement July 2004
5. Secured Proxy ND and Mobile IPv6
Mobile IPv6 has a security association between the Mobile Node and
Home Agent. The Mobile Node sends a Binding Update to the Home
Agent, to indicate that it is not at home. This implies that the
Mobile Node wishes the Home Agent to begin proxy Neighbour Discovery
operations for its home address(es).
Proxy Neighbour Advertisements based on existing router trust require
no explicit authorization signalling between HA and MN to allow
proxying. Existing hosts on the home link will believe
advertisements solely because they come from a trusted router.
Where proxy Neighbour Discovery is delegated by the MN to the home
agent as proxy, the MN needs to learn the CGA public key for the Home
Agent, so that it can generate a certificate authorizing this address
and public-private key-pair to be used in proxying. It may
conceivably either do this using Delegation Chain Solicitations over
a home tunnel, over the Internet, or Router Discovery while still at
home [5].
When sending its Binding Update to the HA, the MN would need to
provide a certificate containing the subject(proxy-HA)'s CGA public
key and address, the issuer(MN)'s CGA and public key, and timestamps
indicating when the authority began and when it ends. This
certificate would need to be passed near to binding time, possibly in
a Delegation Chain Advertisement[5].
6. IANA Considerations
No new options or messages are defined in this document.
7. Security Considerations
This document is at a very early stage of its development. The
author actively elicits feedback regarding the security issues for
proxy Neighbour Discovery and the potential solution space. Please
monitor this section for further security considerations as the
document develops.
7.1 Router Trust Assumption
Router based authorization for Secured Proxy ND may occur without the
knowledge or consent of a device. It is susceptible to the 'Good
Router Goes Bad' attack described in [7].
Daley Expires January 10, 2005 [Page 6]
Internet-Draft Securing PND Problem Statement July 2004
7.2 Certificate Transport
The certification delegation relies upon transfer of the new
credentials to the proxying HA in order to undertake Proxy ND on its
behalf. Since the Binding cannot come into effect until DAD has
taken place, the delegation of the proxying authority necessarily
predates the return of the Binding Ack, as described in [4]. In the
above described case, the home tunnel which comes into creation as
part of the binding process may be required for DCS or DCA transport.
This constitutes a potential chicken-and-egg problem. Either
modifications to initial home binding semantics or certificate
transport are required. This may be trivial if signed,
non-repudiable certificates are sent in the clear between the MN's
CoA and the HA without being tunneled.
7.3 Timekeeping
Both of these methods rely on accurate timekeeping on the receiver
nodes of Neighbour Discovery Timestamps.
For router authorized proxy ND, a neighbour may not know that a
particular ND message is replayed from the time when the proxied host
was still on-link, since the message's timestamp falls within the
valid timing window. Where the router advertises its secured proxy
NA, a subsequent replay of the old message will override the NC entry
created by the proxy.
Creating the neighbour cache entry in this way, without reference to
accurate subsequent timing, may only be done once. Otherwise the
receiver will notice that the timestamp of the advertisement is old
or doesn't match.
One way of creating a sequence of replayable messages which have
timestamps likely to be accepted is to pretend to do an unsecured DAD
on the address each second while the MN is at home. The attacker
saves each DAD defence in a sequence. The granularity of SEND
timestamp matching is around 1 second, so the attacker has a set of
SEND NA's to advertise, starting at a particular timestamp, and valid
for as many seconds as the original NA gathering occurred.
This sequence may then be played against any host which doesn't have
a timestamp history for that MN, by tracking the number of seconds
elapsed since the initial transmission of the replayed NA to that
victim, and replaying the appropriate cached NA.
Where certificate based authorization of proxy ND is in use, the
origination/starting timestamp of the delegated authority may be used
to override a replayed (non-proxy) SEND NA, while also ensuring that
Daley Expires January 10, 2005 [Page 7]
Internet-Draft Securing PND Problem Statement July 2004
the Proxy NA's timestamp (provided by the proxy) is fresh. A
returning MN would advertise a more recent timestamp than the
delegated authority and thus override it. This method is therefore
not subject to the above attack, since the proxy advertisement's
certificate will have a timestamp greater than any replayed messages,
preventing it from being overridden.
8. Acknowledgments
Jean-Michel Combes brought this issue to the attention of the SEND
WG. Contributions to discussion on this topic helped to develop this
document. Thanks go to Jari Arkko, Vijay Devarapalli, James Kempf
and Mohan Parthasarathy.
9. References
9.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05
(work in progress), April 2004.
[6] Koodli, R., "Fast Handovers for Mobile IPv6",
draft-ietf-mipshop-fast-mipv6-01 (work in progress), February
2004.
9.2 Informative References
[7] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
Daley Expires January 10, 2005 [Page 8]
Internet-Draft Securing PND Problem Statement July 2004
Author's Address
Greg Daley
Centre for Telecommunications and Information Engineering
Department of Electrical and Computer Systems Engineering
Monash University
Clayton, Victoria 3800
Australia
Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au
Daley Expires January 10, 2005 [Page 9]
Internet-Draft Securing PND Problem Statement July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daley Expires January 10, 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 13:08:28 |