[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                           G. Daley
Internet-Draft                                    Monash University CTIE
Expires: August 19, 2005                               February 18, 2005


          Securing Proxy Neighbour Discovery Problem Statement
                   draft-daley-send-spnd-prob-01.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 August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   Proxy Neighbour Discovery is used to provide an address presence on a
   link from nodes which are no themselves present.  It allows a node 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 nodes on the home network when
   a Mobile Node is not at home, by allowing the Home Agent to act as
   proxy.  It is also used as a mechanism to allow a global prefix to
   span multiple links, where proxies act as relays for neighbour



Daley                   Expires August 19, 2005                 [Page 1]


Internet-Draft       Securing PND Problem Statement        February 2005


   discovery messages.

   Proxy Neighbour Discovery currently cannot be secured using SEND.
   Today, 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
     1.1  Mobile IPv6 and Proxy Neighbour Discovery  . . . . . . . .   3
     1.2  Bridge-like ND proxies . . . . . . . . . . . . . . . . . .   4
   2.   Proxy ND and Mobility  . . . . . . . . . . . . . . . . . . .   7
   3.   Proxy Neighbour Discovery and SEND . . . . . . . . . . . . .   9
     3.1  CGA signatures and Proxy Neighbour Discovery . . . . . . .  10
     3.2  Non-CGA signatures and Proxy Neighbour Discovery . . . . .  10
     3.3  Securing proxy DAD . . . . . . . . . . . . . . . . . . . .  11
   4.   Potential Approaches to Securing Proxy ND  . . . . . . . . .  12
   5.   Secured Proxy ND and Mobile IPv6 . . . . . . . . . . . . . .  13
     5.1  Mobile IPv6 and Router-based authorization . . . . . . . .  13
     5.2  Mobile IPv6 and per-address authorization  . . . . . . . .  13
   6.   Secured Proxy ND and Bridge-like proxies . . . . . . . . . .  13
     6.1  Authorization Delegation . . . . . . . . . . . . . . . . .  14
     6.2  Unauthorized routers and proxies . . . . . . . . . . . . .  14
     6.3  Multiple proxy spans . . . . . . . . . . . . . . . . . . .  14
     6.4  Routing Infrastructure Delegation  . . . . . . . . . . . .  15
     6.5  Local Delegation . . . . . . . . . . . . . . . . . . . . .  15
     6.6  Host delegation of trust to proxies  . . . . . . . . . . .  16
   7.   Proxying unsecured addresses . . . . . . . . . . . . . . . .  17
   8.   Summary of San Diego Bar BoF Discussion  . . . . . . . . . .  18
   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  18
   10.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
     10.1   Router Trust Assumption  . . . . . . . . . . . . . . . .  18
     10.2   Certificate Transport  . . . . . . . . . . . . . . . . .  18
     10.3   Timekeeping  . . . . . . . . . . . . . . . . . . . . . .  19
   11.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  19
   12.  References . . . . . . . . . . . . . . . . . . . . . . . . .  20
   12.1   Normative References . . . . . . . . . . . . . . . . . . .  20
   12.2   Informative References . . . . . . . . . . . . . . . . . .  20
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  21
        Intellectual Property and Copyright Statements . . . . . . .  22









Daley                   Expires August 19, 2005                 [Page 2]


Internet-Draft       Securing PND Problem Statement        February 2005


1.  Introduction

   Proxy Neighbour Discovery is defined in IPv6 Neighbour Discovery[2].
   It is used in Mobile IPv6 [4], and networks where a prefix has to
   span multiple links[5].  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 (NSs), and answer with Neighbour
   Advertisements (NAs).  These proxy Neighbour Advertisements direct
   data traffic through the proxy.  Proxied traffic is then forwarded on
   to the end destination.

1.1  Mobile IPv6 and Proxy Neighbour Discovery

   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.

   As seen in Figure 1, solicitors send a multicast solicitation to the
   solicited nodes address of the absent node (based on the unicast
   address).

            Absent Mobile       Proxy         Solicitor

                                        NS:SL3=S,DL3=Sol(A),TA=A
                               +-----+     SL2=s,DL2=sol(a),SLL=s
                               |     |<================
                               |     |
                               |     |================>
                               +-----+  NA:SL3=P,DL3=S,TA=A,
                                           SL2=p,DL2=s,TLL=p

   Legend:
      SL3: Source      IPv6 Address         NS: Neighbour Solicitation
      SL3: Destination IPv6 Address         NA: Neighbour Advertisement
      SL2: Source Link-Layer Address        RS: Router Solicitation
      DL2: Destination Link-Layer Address   RA: Router Advertisement
      TA:  Target Address
      SLL/TLL:  Source/Target Link-Layer Address Option

                                Figure 1




Daley                   Expires August 19, 2005                 [Page 3]


Internet-Draft       Securing PND Problem Statement        February 2005


   The Proxy, which listens to this address responds with a Neighbour
   Advertisement which originates at its own IPv6 address and has the
   proxy's address as the Target Link-Layer Address, but contains the
   absent mobile in the Target Address field of the Neighbour
   Advertisement.  In this case, no solicitations are proxied, as the
   advertisements originate within the proxy itself.

   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) [6].  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 [6].

   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
   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.

1.2  Bridge-like ND proxies

   Where proxies exist between two segments, messages may be sent by the
   proxy on the far link, in order to gain or pass on neighbour
   information.  The proxy in this case forwards messages while
   modifying their source and destination MAC addresses, and rewrites
   their Link-Layer Address Options solicited and override flags.  This
   is defined in the Bridge Like ND Proxy (NDproxy) draft [5].



Daley                   Expires August 19, 2005                 [Page 4]


Internet-Draft       Securing PND Problem Statement        February 2005


   This rewriting is incompatible with SEND signed messages for a number
   of reasons:

      Rewriting elements within the message will break the digital
      signature.

      The source IP address of the packets is the packet's origin, not
      the proxy's address.  The proxy is unable to generate another
      signature for this address, as it doesn't have the CGA private key
      [6].

   Proxy modification of SEND solicitations and advertisements require
   removal of (at least) CGA and Signature options, and may also need
   new options with proxy capabilities if non-CGA signatures are added
   to SEND.

   While bridge-like ND proxies aim to provide as little interference
   with ND mechanisms as possible, SEND has been designed to prevent
   modification or spoofing of advertisements by devices on the link.

   Of particular note is the fact that the NDProxy draft performs a
   different kind of proxy neighbour discovery to Mobile IPv6 [4][5].
   The Mobile IPv6 RFC specifies that the Home Agent as proxy sends
   Neighbour Advertisements from its own address with the Target Address
   set to the absent Mobile Node's address.  The Home Agent's own
   link-layer address is placed in the Target Link-Layer address option
   [4].

   The NDproxy draft resends messages containing their original address,
   even after modification [5].  Figure 2 describes packet formats for
   proxy neighbour solicitation and advertisement as specified by the
   draft.

            Advertisor          Proxy         Solicitor

     NS:SL3=S,DL3=Sol(A),TA=A,          NS:SL3=S,DL3=Sol(A),TA=A,
        SL2=p,DL2=sol(A),SLL=p +-----+      SL2=s,DL2=sol(a),SLL=s
            <==================|     |<================
                               |     |
            ==================>|     |================>
     NA:SL3=A,DL3=S,TA=A,      +-----+  NA:SL3=A,DL3=S,TA=A
        SL2=a,DL2=p,TLL=a                  SL2=p,DL2=s,TLL=p

                                Figure 2

   In order to use the same security procedures for both NDProxying and
   Mobile IPv6, changes may be needed to the proxying procedures in [5],
   as well as changes to SEND.



Daley                   Expires August 19, 2005                 [Page 5]


Internet-Draft       Securing PND Problem Statement        February 2005


   An additional (and undocumented) requirement for bridge-like proxying
   is the operation of router discovery.  Router Discovery packets may
   similarly modify neighbour cache state, and require protection from
   SEND.

   In Figure 3, the router discovery messages propagate without
   modification to the router address, but elements within the message
   change.  This is consistent with the description of Neighbour
   Discovery above.

            Advertisor          Proxy         Solicitor

     RS:SL3=S,DL3=AllR,                 RS:SL3=S,DL3=AllRr,
        SL2=p,DL2=sol(A),SLL=p +-----+     SL2=s,DL2=allr,SLL=s
            <==================|     |<================
                               |     |
            ==================>|     |================>
     RA:SL3=A,DL3=S,           +-----+  RA:SL3=A,DL3=S,
        SL2=a,DL2=p,SLL=a                 SL2=p,DL2=s,SLL=p

                                Figure 3

   Once again, these messages may not be signed with a CGA signature by
   the re-advertisor, because it does not own the source address.

   Additionally, multicast Authorization Delegation Discovery ICMPv6
   messages need to be exchanged for bridge-like ND proxies to prove
   their authority to forward.  Unless the proxy receives explicit
   authority to act as a router, or the router knows of its presence, no
   authorization may be made.  This explicit authorization requirement
   may be at odds with zero configuration goal of ND proxying [5].

   An alternative (alluded to in an appendix of NDproxy) suggests that
   the proxy send Router Advertisements (RAs) from its own address.  As
   described by NDproxy this is insufficient for providing proxied
   Neighbour Advertisement service, but may be matched with neighbour
   solicitation and advertisement services using the proxy's source
   address in the same way as Mobile IPv6 [5][4].  This means that all
   router and neighbour advertisements would come from the proxied
   address, but may contain a target address which allows proxied
   neighbour presence to be established with peers on other segments.
   Router Discovery in this case has the identity of the original
   (non-proxy) router completely obscured in router discovery messages.

   The resultant proxy messages would have no identifying information
   indicating their origin, which means that proxying between multiple
   links would require state to be stored on outstanding solicitations
   (effectively an ND only NAT).  This level of state storage may be



Daley                   Expires August 19, 2005                 [Page 6]


Internet-Draft       Securing PND Problem Statement        February 2005


   undesirable.

   Mobile IPv6 does not experience this issue when supplying its own
   address, since ND messages are never forwarded on to the absent node
   (the Home Agent having sufficient information to respond itself).

   Authorization from a router may still be required for Router
   Advertisement, and will be discussed in Section 6.

2.  Proxy ND and 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.

   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 Care-of-Address (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[7].  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.

   As shown in Figure 4, after the mobile node departs, the Home Agent
   or Proxy sends an overriding Neighbour advertisement, in order to
   update existing neighbour cache entries.

            Absent Mobile       Proxy         Solicitor

                               +-----+
               Binding Update  |     |
              ---------------->|     |
               or Fast BU      |     |================>
                               +-----+  NA:SL3=P,DL3=AllN,TA=A,
                                           SL2=p,DL2=alln,TLL=p


                                Figure 4

   Where the proxy forwards between segments of a network, nodes may
   move between segments [5].  For this scenario, the proxy is
   responsible for updating neighbour cache entries as incorrect state
   is left in them after the move.



Daley                   Expires August 19, 2005                 [Page 7]


Internet-Draft       Securing PND Problem Statement        February 2005


   Devices which were on the same segment as the moving node,
   subsequently have incorrect neighbour cache state, as they now need
   to traverse the proxy to get to the other node.  Devices which were
   previously being proxied may now be on the same segment as the mobile
   node, and may go direct.

   As illustrated in Figure 5, the nodes may have incorrect neighbour
   cache state, even if the proxy knows of the departure to another
   segment.

            Mobile Node         Proxy          Mobile Node - M
            (Departed)            P            (New Location)

             + - - +                            +-----+ NC:
             '     '     NC:          NC:       |     | N -> n
             + - - +     N -> n+-----+M -> m    +-----+
                |              |     |             |
             ------------------|     |--------------------
                  |            |     |
               +-----+NC:      +-----+
               |     |M -> m
               +-----+

               Existing
              Neighbour - N

                                Figure 5

   While neighbour cache state times out, and causes devices to probe
   for the location of a peer, long delays may occur before timeouts of
   neighbour cache state [2].  In cases where these delays are too long,
   the proxy may have to override the neighbour cache entries of hosts
   which were previously on the same segment as the moving node.

   Those devices now resident on the same segment as the mobile node
   will have the proxy's link-layer address in its neighbour cache.  In
   the NDProxy draft, it is indicated that packets are never forwarded
   back to the same segment upon which they arrived (potentially to
   prevent forwarding loops)[5].

   Similarly, if the mobile node is unaware of its movement, it too may
   have incorrect neighbour cache entries for devices which it is now on
   the same segment as.  This is shown below in Figure 6.








Daley                   Expires August 19, 2005                 [Page 8]


Internet-Draft       Securing PND Problem Statement        February 2005


            Mobile Node         Proxy          Mobile Node - M
            (Departed)            P            (New Location)

             + - - +                            +-----+ NC:
             '     '        NC:       NC:       |     | N -> p2
             + - - +           +-----+M -> m    +-----+
                |              |     |N -> n       |
             ------------------|     |--------------------
                               |     |           |
                             P2+-----+P1      +-----+ NC:
                                              |     | M -> p1
                                              +-----+

                                              Existing
                                              Neighbour - N

                                Figure 6

   For the remaining duration of their incorrect neighbour cache entry
   (up to around 35 seconds), all packets will be dropped.  Therefore,
   these devices may need to be updated with the present node's
   link-layer address.

   Procedures regarding updating caches rely upon Section 7.2.6 of IPv6
   Neighbour Discovery [2], which allows proxies to neighbour advertise
   to all-nodes with the override flag set when becoming a proxy or
   addresses change.

   For either environment, updates are required to neighbour cache
   entries which may be for SEND nodes.  These advertisements must
   therefore have enough authority to override neighbour cache entries
   even though they are secured.

3.  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, and be signed by the transmitter.  (section 7.4 of [6]).

   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.

   Even if the message is able to be transmitted from the original
   owner, differences in link-layer addressing and options require
   modification by a proxy.  If a message is signed with a CGA-based
   signature, the proxy is unable to regenerate a signature over the



Daley                   Expires August 19, 2005                 [Page 9]


Internet-Draft       Securing PND Problem Statement        February 2005


   changed message as it lacks the keying material.

   Therefore, a router wishing to provide proxy Neighbour Advertisement
   service can not use existing SEND procedures 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 node 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].

3.1  CGA signatures and Proxy Neighbour Discovery

   SEND defines one public-key and signature format for use with
   Cryptographically Generated Addresses (CGAs) [6].  CGAs are intended
   to tie address ownership to a particular Public/Private key pair.

   In SEND as defined today, Neighbour Discovery Messages (including the
   IP Addresses from the IPv6 header) are signed with the same key used
   to generate the CGA.  This means that message recipients have proof
   that the signer of the message owned the address.

   Where a  proxy replaces the message source with its own CGA, the
   existing CGA option and RSA signature option need to be replaced with
   the proxy's.  Such a message will validate using SEND, except that
   the Target Address field will not match the IPv6 Source Address in
   Neighbour Advertisements [6].

   Additional authorization information may be needed to prove that the
   proxy is indeed allowed to advertise for the target address, as is
   described in Section 4.

3.2  Non-CGA signatures and Proxy Neighbour Discovery

   Where a proxy retains the original source address in a proxied
   message, existing SEND-CGA checks will fail, since fields within the
   message will be changed.  In order to achieve secured proxy neighbour
   discovery in this case, new signature authentication mechanisms may
   be needed for SEND.



Daley                   Expires August 19, 2005                [Page 10]


Internet-Draft       Securing PND Problem Statement        February 2005


   SEND provides interfaces for extension of SEND to non-CGA based
   authorization.  Messages are available for Authorization Delegation
   Discovery, which is able to carry arbitrary PKIX/X.509 certificates
   [9].

   There is no specification though of keying information option formats
   analogous to the SEND CGA Option [6].  The existing option allows a
   host to verify message integrity by specifying a key and algorithm
   for digital signature, without providing authorization for functions
   other than CGA ownership.

   The digital signature in SEND is transported in the RSA Signature
   Option.  As currently specified, the signature operation is performed
   over a CGA Message type, and infers support for CGA verification.
   clarification or changing of this issue for non-CGA operations may be
   necessary.

   Within SEND, more advanced functions such as routing may be
   authorized by certificate path verification using Authorization
   Delegation Discovery.

   With non-CGA signatures and authentication, certificate contents for
   authorization may need to be determined, as outlined in Section 4.

   While SEND provides for extensions to new non-CGA methods, existing
   SEND hosts may silently discard messages with unverifiable RSA
   signature options (Section 5.2.2 of [6]), if configured only to
   accept SEND messages.  In cases where unsecured neighbour cache
   entries are still accepted, messages from new algorithms will be
   treated as unsecured.

3.3  Securing proxy DAD

   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 existing SEND procedures, the address which is used for CGA tests
   on DAD NSs is the target address.  A Proxy which originates this
   message while the proxied address owner is absent is unable to
   generate a CGA-based signature for this address and must undertake
   DAD with an unsecured NS.  It may be possible that the proxy can
   ensure that responding NA's are secured though.

   Where bridge-like NDproxy operations are being performed, DAD NS's
   may be copied from the original source, without modification



Daley                   Expires August 19, 2005                [Page 11]


Internet-Draft       Securing PND Problem Statement        February 2005


   (considering they have an unspecified source address and contain no
   link-layer address options)[5]

   If non-CGA based signatures are available, then the signature over
   the DAD NS doesn't need to have a CGA relationship to the Target
   Address, but authorization for address configuration needs to be
   shown using certificates.  Where SEND-only nodes do not understand
   the signature format.

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.

   For bridge-like proxies, it is assumed that there is no preexisting
   trust between the host owning the address and the proxy.  Therefore,
   authority may necessarily be dynamic or based on topological roles
   within the network [5].

   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.
   Devices which are proxies could either be granted the right to proxy
   by the network's router, or be implicitly allowed to proxy by virtue
   of being an authorized router.

   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.




Daley                   Expires August 19, 2005                [Page 12]


Internet-Draft       Securing PND Problem Statement        February 2005


   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.

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).

5.1  Mobile IPv6 and Router-based authorization

   A secured Proxy Neighbour Advertisements proposal based on existing
   router trust would require no explicit authorization signalling
   between HA and MN to allow proxying.  Hosts on the home link will
   believe proxied advertisements solely because they come from a
   trusted router.

   Where the home agent operates as a router without explicit trust to
   route from the advertising routing infrastructure (such as in a home,
   with a router managed by an ISP), more explicit proxying
   authorization may be required, as described in Section 6.

5.2  Mobile IPv6 and per-address authorization

   Where proxy Neighbour Discovery is delegated by the MN to the home
   agent, the MN needs to learn the public key for the Home Agent, so
   that it can generate a certificate authorizing the public-private
   key-pair to be used in proxying.  It may conceivably either do this
   using Certificate Path Solicitations over a home tunnel, over the
   Internet, or Router Discovery while still at home [6][4].

   When sending its Binding Update to the HA, the MN would need to
   provide a certificate containing the subject(proxy-HA)'s 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 Certificate Path Advertisement[6].  Messaging or such an exchange
   mechanism would have to be developed.

6.  Secured Proxy ND and Bridge-like proxies

   In link-extension environments, the role of a proxy is more
   explicitly separated from that of a router.  In SEND, routers may
   expect to be authorized by the routing infrastructure to advertise,
   and provide this authority to hosts in order to allow them to change



Daley                   Expires August 19, 2005                [Page 13]


Internet-Draft       Securing PND Problem Statement        February 2005


   forwarding state.

   Proxies are not part of the traditional infrastructure of the
   Internet, and hosts or routers may not have an explicit reason to
   trust them, except that they can forward packets to regions where
   otherwise they could not reach.

6.1  Authorization Delegation

   If a proxy can convince a device that it should be trusted to perform
   proxying function, it may require that device to vouch for its
   operation in dealing with other devices.  It may do this by receiving
   a certificate, signed by the originating device that the proxy is
   believed capable of proxying under certain circumstances.

   This allows nodes receiving proxied neighbour discovery packets to
   quickly check if the proxy is authorized for the operation.  There
   are several bases for such trust, and requirements in proxied
   environments, which are discussed below.

6.2  Unauthorized routers and proxies

   Routers advertising on networks without routers may have to operate
   with no explicit authorization, and SEND hosts will configure these
   if there's no other option [6].  While proxies may similarly attempt
   to advertise without authority, this provides no security for the
   routing infrastructure.  Any device can set up to be a SEND proxy/
   router so long as it signs its own ND messages from its CGA.

   This may not help in the case that a proxy attempts to update
   neighbour cache entries for SEND node which moves between links,
   since the SEND node's authority to advertise its own CGA address
   would not be superceded by a proxy with no credentials.

6.3  Multiple proxy spans

   Proxies may have multiple levels of nesting, which allow the network
   to connect between non-adjacent segments.

   In this case, authority delegated at one point will have to be
   redelegated (possibly in a diluted form) to proxies further away from
   the origin of the trust.









Daley                   Expires August 19, 2005                [Page 14]


Internet-Draft       Securing PND Problem Statement        February 2005


       Trust        ProxyA             ProxyB      Distant
       Origin - T                                   Node - D

        +-----+                                    +-----+
        |     |                                    |     |
        +-----+     +-----+            +-----+     +-----+
           |        |     |            |     |        |
        ------------|     |------------|     |----------
                    |     |            |     |
                    +-----+            +-----+
          ==========>     ==============>    ==========>
          Deleg(A,T)    Deleg(B,Deleg(T,A))   Advertise(D, Deleg(B,
                                                    Deleg(A,T))

                                Figure 7

   As shown in Figure 7, the Proxy A needs to redelegate authority to
   proxy for T to B, this allows it to proxy advertisements back to D,
   which target T.

6.4  Routing Infrastructure Delegation

   Where it is possible for the proxy to pre-establish trust with the
   routing infrastructure, or at least to the local router, it may be
   possible to authorize proxying as a function of routing within the
   subnet.  The router or CA may then be able to certify proxying for
   only a subset of the prefixes which is itself certified for.

   If a router or CA provides certification for a particular prefix, it
   may be able to indicate that only proxying is supported, so that
   neighbour cache entries of routers connected to internet
   infrastructure are never overridden by the proxy, if the router is
   present on a segment.

   Hosts understanding such certificates may allow authorized proxies
   and routers to override host SEND/CGA when assuming proxy roles, if
   the host is absent.

   Proxy certificate signing could be done either dynamically (requiring
   exchanges of identity and authorization information), or statically
   when the network is set up.

6.5  Local Delegation

   Where no trust tie exists between the authority which provides the
   routing infrastructure and the provider of bridging and proxying
   services, it may still be possible for SEND hosts to trust the
   bridging provider to authorize proxying operations.



Daley                   Expires August 19, 2005                [Page 15]


Internet-Draft       Securing PND Problem Statement        February 2005


   SEND itself requires that routers be able to show authorization, but
   doesn't require routers to have a single trusted root.

   A local bridging/proxying authority trust delegation may be possible.
   It would be possible for this authority to pass out local use
   certificates, allowing proxying on a specific subnet or subnets, with
   a separate authorization chain to that for the routers with Internet
   access.

   This would require little modification to SEND, other than addition
   of router based proxy authority (as in Section 6.4), and proxies
   would in effect be treated as routers by SEND hosts [6].
   Distribution of keying and trust material for the initial bootstrap
   of proxies would not be provided though (and may be static).

   Within small domains, key management and distribution may be a
   tractable problem, so long as these operations are are simple enough
   to perform.

   Since these domains may be small, it may be necessary to provide
   certificate chains for trust anchors which weren't requested in
   Certificate Path Solicitations, if the proxy doesn't have a trust
   chain to any requested trust anchor.

   This is akin to 'suggesting' an appropriate trusted root.  It may
   allow for user action in allowing trust extension when visiting
   domains without ties to a global keying infrastructure.  In this
   case, the trust chain would have to start with a self-signed
   certificate from the original CA.

6.6  Host delegation of trust to proxies

   Unlike Mobile IPv6, for bridge-like proxied networks, there is no
   existing security association upon which to transport proxying
   authorization credentials.

   Proxies need then to convince neighbours to delegate proxy authority
   to them, in order to proxy-advertise to nodes on different segments.
   It will be difficult without additional information to distinguish
   between legitimate proxies, and devices which have no need or right
   to proxy (and may wish two network segments to appear to be
   connected).

   When proxy advertising, proxies must not only identify that proxying
   needs to occur, but provide proof that they are allowed to do so, so
   that SEND Neighbour Cache entries may be updated.  Unless the
   authorization to update such entries is tied to address ownership
   proofs from the proxied host or the verifiable routing



Daley                   Expires August 19, 2005                [Page 16]


Internet-Draft       Securing PND Problem Statement        February 2005


   infrastructure, spoofing may occur.

   When a host received a proxied neighbour advertisement, it would be
   necessary to check authorization in the same way that authorization
   delegation discovery is performed in SEND.

   Otherwise, certificate transport will be required to exchange
   authorization between proxied nodes and proxies.

   Proxies would have to be able to delegate this authorization to
   downstream proxies, as described in Section 6.3.

   Movement between segments could be controlled with increasing
   certificate sequence numbers and timestamps.  The timestamp of the
   root authority (in this case, the CGA address owner) would be most
   significant.  Where ties exist, the shortest chain would supercede,
   as this would indicate a proxy closer to the proxied node.

7.  Proxying unsecured addresses

   Where the original neighbour discovery message is unsecured, there is
   an argument for not providing secured proxy service for that node.

   In both the Mobile IPv6 and extended networks cases, the node may
   arrive back at the network and require other hosts to map their
   existing neighbour cache entry to the node's link-layer address.  The
   re-arriving node's overriding of link-layer address mappings will
   occur without SEND in this case.

   It is notable that without SEND protection any node may spoof the
   arrival, and effectively steal service across an extended network.
   This is the same as in the non-proxy case, and is not made
   significantly worse by the proxy's presence (although the identity of
   the attacker may be masked if source addresses are being replaced).

   If signatures over the proxied messages were to be used, re-arrival
   and override of the neighbour cache entries would have to be allowed,
   so the signatures would indicate that at least the proxy wasn't
   spoofing (even if the original sender was).

   For non-SEND/CGA routers, though, it may be possible for secured
   proxies to send signed router advertisement messages, in order to
   ensure that routers aren't spoofed, and subsequently switched to
   being on different parts of the extended network.

   This has problems in that the origin is again unsecured, and any node
   on the network could spoof router advertisement for an unsecured
   address.  These spoofed messages may become almost indistinguishable



Daley                   Expires August 19, 2005                [Page 17]


Internet-Draft       Securing PND Problem Statement        February 2005


   (except for the non-CGA origin address) from unspoofed messages from
   SEND routers.

   Given these complexities, the simplest method is to allow unsecured
   devices to be spoofed from any port on the network, as is the case
   today.

8.  Summary of San Diego Bar BoF Discussion

   At the Bar BoF in San Diego, discussion followed the issue of mobile
   nodes receiving proxy service from home agents and FMIPv6 access
   routers.

   At the time, it was considered appropriate to see if the router
   authorization model could be adopted for proxy SEND.  This discussion
   didn't cover bridge-like proxies in any detail though.

9.  IANA Considerations

   No new options or messages are defined in this document.

10.  Security Considerations

   This document is in a developmental stage.  The author actively seeks
   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.

10.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 [8].

10.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 Certificate Path
   Solicitation or Advertisement transport [6].  This constitutes a
   potential chicken-and-egg problem.  Either modifications to initial
   home binding semantics or certificate transport are required.  This



Daley                   Expires August 19, 2005                [Page 18]


Internet-Draft       Securing PND Problem Statement        February 2005


   may be trivial if signed, non-repudiable certificates are sent in the
   clear between the MN's CoA and the HA without being tunneled.

10.3  Timekeeping

   All of the presented methods rely on accurate timekeeping on the
   receiver nodes of Neighbour Discovery Timestamp Options and
   certificates.

   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
   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.

11.  Acknowledgments

   Jean-Michel Combes brought this issue to the attention of the SEND
   WG.  James Kempf and Dave Thaler particularly contributed to work on



Daley                   Expires August 19, 2005                [Page 19]


Internet-Draft       Securing PND Problem Statement        February 2005


   this document.  Contributions to discussion on this topic helped to
   develop this document.  Thanks go to Jari Arkko, Vijay Devarapalli,
   and Mohan Parthasarathy.

12.  References

12.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]  Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND Proxy)",
        draft-ietf-ipv6-ndproxy-00 (work in progress), December 2004.

   [6]  Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
        "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
        (work in progress), July 2004.

   [7]  Koodli, R., "Fast Handovers for Mobile IPv6",
        draft-ietf-mipshop-fast-mipv6-03 (work in progress), October
        2004.

12.2  Informative References

   [8]  Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
        Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [9]  Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
        Public Key Infrastructure Certificate and Certificate Revocation
        List (CRL) Profile", RFC 3280, April 2002.












Daley                   Expires August 19, 2005                [Page 20]


Internet-Draft       Securing PND Problem Statement        February 2005


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 August 19, 2005                [Page 21]


Internet-Draft       Securing PND Problem Statement        February 2005


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 (2005).  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 August 19, 2005                [Page 22]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/