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.