Hemant Singh (shemant) wrote:
I personally think RFC 4389 is well shaken out for a doc - as we say in
our new short note, the only reason they didn't make the ND Proxy doc a
Standards Track doc because ND Proxy did not support SEND extensions.
I definitely had other concerns around RFC 4389 around the weaknesses in
loop avoidance. ND proxy in essence forwards IP (ND) packets without
decrementing ttl, which can lead to catastophic loops. The RFC tries to
ameliorate that by detecting loops. However, the loop detection is based
on receiving RAs (with the P-bit) which handles some cases. But it isn't
robust against somebody connecting what was two Ethernet segments after
ND proxy has sent its two P-bit RAs.
Thus I personally don't think this approach is fit as a standards track
document.
The SEND extensions was work TBD with another IETF WG but that group is,
I think, 4 years and counting for not taking this work. But there are
networks that need ND Proxy without use of SEND.
draft-ietc-csi-proxy-send is underway but is a bit subtle in its
applicability. The idea around RFC 4389 is that the proxy isn't known to
the other nodes. Yet proxy-send is based on explicitly assigning a
ceritificate and associated trust to the proxy node. See text around
The Secure Proxy ND becomes part of the trusted infrastructure just
like a SEND router. The Secure Proxy ND is granted a certificate
that specifies the range of addresses for which it is allowed to
perform proxying of SEND messages
Such an approach is workable for the Mobile IP scenario, because there
the MN and HA have a relationship thus it is reasonable for the MN to
trust the HA.
But it doesn't seem to fit the transparent case of RFC 4389.
If there are networks "that need ND proxy" as you say, and at the same
time have the threats that SeND was designed to handle (the threats are
listed in RFC 3756), then I think there is an architectural disconnect.
To be able to secure the network some constraints need to be placed on
who can advertise things in Neighbor Discovery messages and that seems
to be fundamentally at odds with any transparent ND proxying.
I suspect such cases are best handled (when SeND can't be deployed on
the link) by splitting what is one link into separate links (by using
existing techniques like VLANs, or perhaps inventing some new technique
above layer 2) so that the security threats related the shared link goes
away.
I think that this is in essence what is done for IPv4 since the DHCPv4
address assignment essentially is used to establish point-to-point
connectivity between the router and each peer; there is no shared
multicast or broadcast traffic needed on the link to set this up.
IPv6 is different in its reliance on not only link-local addresses but
also on multicast RS and RA packets to do the initial setup.
Regards,
Erik
Hemant
-----Original Message-----
From: Pekka Savola [mailto:[email protected]]
Sent: Thursday, November 12, 2009 3:51 PM
To: Hemant Singh (shemant)
Cc: [email protected]
Subject: Re: speaking of ND Proxy and NBMA etc.
On Wed, 11 Nov 2009, Hemant Singh (shemant) wrote:
http://www.ietf.org/id/draft-wbeebee-6man-nd-proxy-std-00.txt
Do we already have implementations? What are the implementation
experiences? Were all the features of the spec useful, or should
something be changed (added, removed, clarified)?
This is not procedurally required for PS, but if there are a lot of
implementations already, this would be a strong argument for going to
PS.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
