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

["Dave Thaler" <dthaler@windows.microsoft.com>]

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Monday, September 12, 2005 12:59 AM
> To: Wijnen, Bert (Bert); Margaret Wasserman; Dave Thaler
> 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...

Proposed change accepted (removed this point).

> However, the draft should have a note saying that it has
> chosen to not support nodes that do SEND.

Agree, although that statement is slightly misleading.  This draft 
expands on proxy neighbor discovery which was already mentioned in 
RFC 2461.  It was SEND that chose to not cover proxy neighbor discovery 
in the base spec, leaving it to future extensions.

In any case, we agree that a more clear statement would be helpful, 
and I like the text you've proposed below.

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

Accepted the proposed text, but retained an additional statement which 
existed in -03 (marginally reworded to fit with your rewording),
inserted
at end of above paragraph:
                            We note that RFC 2461 [ND] already defines
  the ability to proxy Neighbor Advertisements, and extensions to SEND
  are already needed to cover that case, independent of this document.

> 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
                                                            ^
Added informative reference here to

[SPND]
     Daley, G., "Securing Proxy Neighbour Discovery Problem
     Statement", Work in progress, draft-daley-send-spnd-
     prob-01.txt, February 2005.

> 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

Accepted.

Proposed updated draft is at
http://www.icir.org/dthaler/draft-ietf-ipv6-ndproxy-04.txt

-Dave