[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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