RE: draft-ietf-ipv6-ndproxy review (was: Re: Please Review: Docum ents on IESG Agenda for September 15, 2005)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Jari, since this is all security related, I have asked the
security ADs if they can pick up this comment.

Sam has agreed to do so.

Bert

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Monday, September 12, 2005 09:59
> To: Wijnen, Bert (Bert); Margaret Wasserman; dthaler@microsoft.com
> Cc: Aaa-Doctors (E-mail)
> Subject: draft-ietf-ipv6-ndproxy review (was: Re: Please Review:
> Documents on IESG Agenda for September 15, 2005)
> 
> 
> Wijnen, Bert (Bert) wrote:
> 
> >  o draft-ietf-ipv6-ndproxy-03.txt
> >    Neighbor Discovery Proxies (ND Proxy) (Experimental) - 3 of 5 
> >    Token: Margaret Wasserman
> >  
> >
> Some comments:
> 
> > o    Support Neighbor Discovery, Router Discovery, or DHCPv4
> >      packets using IPsec.  We also note that the current methods
> >      for securing these protocols do not use IPsec so this is
> >      considered acceptable.
> 
> I would probably not mention this at all, because its confusing.
> IPsec in this purpose doesn't really work anyway, so why bother
> even mentioning it...
> 
> However, the draft should have a note saying that it has
> chosen to not support nodes that do SEND.
> 
> > 9.  Security Considerations
> 
> This section seems a bit unclear imho and would benefit from a
> rewrite and direct representation of the issues and the properties
> and limitations of the specification at hand. Here's
> a suggested rewrite:
> 
> Unsecured Neighbor Discovery and ARP have a number of security issues
> which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines
> security mechanisms that can protect Neighbor Discovery. No such
> mechanism has been defined for ARP.
> 
> Proxies are susceptible to the same kind of security issues that
> plague hosts using unsecured Neighbor Discovery. These issues include
> hijacking traffic and denial-of-service within the subnet. 
> Malicious nodes
> within the subnet can take advantage of this property, and hijack
> traffic. In addition, a Neighbor Discovery proxy is essentially a
> legitimate man-in-the-middle, which implies that there is a need
> to distinguish proxies from unwanted man-in-the-middle attackers.
> 
> This document does not introduce any new mechanisms for the protection
> of proxy neighbor discovery. That is, it does not provide a mechanism
> from authorizing certain devices to act as proxies, and it does not
> provide extensions to SEND to make it possible to use both SEND and
> proxies at the same time.
> 
> Note also that the use of proxy Neighbor Discovery may render it
> impossible to use SEND both on the leaf subnet and on the external
> subnet. This because the modifications performed by the proxy will
> invalidate the RSA Signature Option in a secured Neighbor Discovery
> message, and cause SEND-capable nodes to either discard the messages
> or treat them as unsecured. The latter is the desired operation when
> SEND is used together with this specification, and ensures that SEND
> nodes within this environment can selectively downgrade themselves to
> unsecure Neighbor Discovery when proxies are present.
> 
> In the following we outline some potential paths to follow
> when defining a secure proxy mechanism.
> 
> It is reasonable for nodes on the leaf subnet to have a secure
> relationship with the proxy, and accept ND packets from either the
> owner of a specific address (normal SEND), or which it can verify
> are from a trusted proxy (see below).
> 
> For nodes on the external subnet, there is a tradeoff between
> security (where all nodes have a secure relationship with the
> proxy) and privacy (where no nodes are aware that the proxy is a
> proxy). In the case of a point-to-point external link (Scenario
> 2) however, SEND may not be a requirement on that link.
> 
> Verifying that ND packets come from a trusted proxy requires an
> extension to the SEND protocol and is left for future work, but is
> similar to the problem of securing Router Advertisements which is
> supported today.
> 
> Alternative designs might involve schemes where the right
> for representing a particular host is delegated to the proxy,
> or where multiple nodes can make statements on behalf of
> one address [RINGSIG]
> 
> (And add a new reference to RFC 3971 [SEND] and
> draft-kempf-mobopts-ringsig-ndproxy [RINGSIG].)
> 
> --Jari
>