Subject: Re: speaking of ND Proxy and NBMA etc.

From: Erik Nordmark <[email-masked]>
Date: Wed, 02 Dec 2009 23:31:07 -0800

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-masked]] 
> Sent: Thursday, November 12, 2009 3:51 PM
> To: Hemant Singh (shemant)
> Cc: [email-masked]
> 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.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Dec 2009 07:21:39 -0800

Erik,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Wednesday, December 02, 2009 11:31 PM
> Cc: [email-masked]; Pekka Savola

Some links rely on unicast RS/RA and not multicast. Wouldn't
unicast-only proxy ND avoid the looping issues you were
concerned with?

Fred
[email-masked]

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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Dec 2009 09:05:34 -0800

> unicast-only proxy ND avoid the looping issues you were

No.

If the network is misconfigured you can get loops. An example: we have 
host A sending (even a unicast NS) to the L2 address for router R1 for 
target B, that causes R1 to send (even a unicast NS) to what it thinks 
is the L2 address for B, but that turns out to be an incorrect L2 
address. For instance if that L2 address is that of some other router R2 
that does proxy ND, then it might in turn originate a NS for B send to 
the L2 address of R1. Then we'd have R1 and R2 sending NS packets for 
target B to each other at full line rate without any limit.

If some of the NS are multicast the risk gets worse, because the looping 
can be combined with the multicast duplication. In the example, 
multicast might mean that R3 and R4 would also receive an NS for B and 
decide they need to send a NS for B to R1.
But the unicast looping is bad enough.

    Erik

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 Dec 2009 09:50:35 -0800

Erik,

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Tuesday, December 08, 2009 9:06 AM
> To: Templin, Fred L
> Cc: Hemant Singh (shemant); [email-masked]; Pekka Savola
> If the network is misconfigured you can get loops.

Then, let's be sure the network is not misconfigured. Can't
we use spanning tree or some such to ensure that?

Fred

> An example: we have