Neighbor Discovery Proxies (ND Proxy)
Note: This ballot was opened for revision 04 and is now closed.
(Brian Carpenter) (was Discuss) No Objection
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".
(Margaret Cullen) (was Discuss, Yes) No Objection
(Bill Fenner) No Objection
(Sam Hartman) (was Discuss) No Objection
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