Neighbor Discovery Proxies (ND Proxy)
draft-ietf-ipv6-ndproxy-04

Smaller comment from Gen-ART review by Harald Alvestrand:


I have a number of other stylistic and scoping comments:

- Section 1 describes the scenarios where this document is applicable: Single IPv4 address and single /64 prefix delegation. It clearly identifies that NAT is used in the IPv4 scenario, and identifies cost as a driver for the /64 scenario: "Secondly, the extent to which Prefix Delegation is supported, and supported without additional charge, is up to the service provider."
If this solution has costs, I think some people would rather pay their service provider than use it; I think the the "no charge" part of the sentence could be dropped.
The part about "zero configuration" in the same paragraph is also possibly untrue; later we see a requirement to configure the proxy to know which interface is "upstream".

Here is an external review.  Personally I agree with the comments made
here.  The concern about the security considerations section is a
DISCUSS issue.

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