Subject: [NDProxy#17] SEND

From: "Dave Thaler" <[email-masked]>
Date: Wed, 16 Feb 2005 12:27:33 -0800

Summary:
Document first lists working with SEND as a requirement, and then
doesn't meet that requirement.

Discussion so far:
http://www.icir.org/dthaler/NDProxyIssues.htm#Issue%2017

The text that makes the document inconsistent is, from the Requirements
section:
> o Support secure IPv6 neighbor discovery. This is discussed in
>   the Security Considerations section.

This was an original goal, which as pointed out was not achieved, 
but is not really a strict requirement just a goal.  For example, 
IPv4 ARP Proxies are deployed today without meeting this requirement.
Hence propose to delete this sentence, and append additional
discussion to Security Considerations section as noted at bottom.

Regarding Erik's summary of:
> Thus any secure solution in this space requires at least one of:
> 1. that the host be modified to have a secure relationship with the
> proxy
> 2. that the proxies do not modify the ND packets
> Note that #2 can be done, but it requires that the proxies be able to
> receive packets addressed to any MAC address (just like bridges do).

I accept this conclusion, and point out that #2 cannot be used in either
the 802.11 scenario (since the proxy cannot be promiscuous) or the PPP 
scenario (since the link-layer address format is different).  Hence #1
is
all that's left.  Here, there's two classes of nodes: the local nodes on
the leaf network, and the nodes (including the router) on the external
link between the proxy and the router.

For local devices on the leaf network needing to verify NA's from
external
devices, having a secure relationship is not unreasonable, and this was
the (admittedly somewhat obscured) intent of the text:

> The requirements for securing proxied
> messages are similar to those for securing Router Advertisements,
> since the receiver must verify that the advertisement came from a
> valid router/proxy, rather than from the owner of a specific address.

although this requires additional work to specify how to use RA-like
auth
in NA messages, but I believe that this particular work is not unique to
this draft as discussed earlier.  It would be part of a new "Proxy SEND"
document as James Kempf suggested.

For devices on the external link between the proxy and the router
needing
to verify NA's from internal devices, the constraint of avoiding any
incentive to do an IPv6 NAT means it is not reasonable that they have a
secure relationship with the proxy (or rather that they have any secure
relationship they wouldn't have with any other non-proxy host).
However,
in the PPP scenario this shouldn't be an issue in practice since the
link
is point-to-point.  For 802.11 networks on the other hand, bridging and
SEND do appear to be inherently incompatible in the case where you don't
want the router to know that the proxy is a proxy (for fear, real or
imagined, of being charged extra).  Hence there's a tradeoff between
security and "privacy" here, with a sort of middle ground being
Christian's "I am behind an proxy, and the proxy address is X:Y:Z".

Propose replacing, in the Security Considerations section:
> From an IPv6 perspective, RFC 2461 [ND] already defines the
> ability to proxy Neighbor Advertisements. The requirements for
> securing proxied messages are similar to those for securing Router
> Advertisements, since the receiver must verify that the
> advertisement came from a valid router/proxy, rather than from the
> owner of a specific address.

with

> From an IPv6 perspective, RFC 2461 [ND] already defines the
> ability to proxy Neighbor Advertisements.  Since the ND packets must
> be modified whenever the link-layer address formats are different (as 
> with PPP) or promiscuous reception is not possible (as with 802.11),
> securing any solution in this space requires that hosts have a secure 
> relationship with the proxy.
> 
> 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.

-Dave

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------