[rbridge] Back to ND/ARP optimization

[Arien Vijn]

Hello Radia,

On May 3, 2007, at 4:38 PM, Radia.Perlman at sun.com wrote:

> Looking back on old emails, there are some people who'd like to get  
> rid of ND/ARP optimization,
> and some people pointing out that optimizing ND might not be so  
> simple (for instance, SEND).
>
> I'd be OK with removing it from the spec, or certainly making it  
> something other than a MUST, like
> perhaps MAY.
>
> But there were fields in the per-VLAN instance of IS-IS to  
> facilitate this, namely the (L3 address, L2 address).
> An RBridge *could* learn this information locally, but wouldn't  
> learn it as much. In other words, if S behind R1 sends
> an ARP request for target T behind R2, the response will be unicast  
> to S, so none of the other RBridges will
> learn where T is. Only R1. So R1 could in the future do a proxy  
> ARP. But if R2 announced (T, t) in its per-VLAN
> instance of IS-IS, then all the RBridges could learn (T,t).  
> Furthermore, if T has registered with R2 via some
> L2 enrollment protoocol, then R2 can immediately know if T is no  
> longer there and alert everyone.

This mechanism optimises successful quires, but I think that those  
are not the bulk of the ARP/ND broadcasts/multicasts.

> Does anyone have a handle on how much traffic is caused by ARP/ND?
>
> We could certainly do a compromise, like that each RBridge R1  
> SHOULD throttle ARP/ND queries, and
> not reflood a query for T if there has been more than k (some  
> parameter) queries for T in the last n seconds.

This is similar to the way we do ARP mitigation. We made a friendly  
ARP spoofer that starts spoofing replies when the queries for T reach  
a threshold and after it verified that T is indeed unreachable. It  
stops spoofing for T as soon as it detects any sign of life from T.  
It works like charm as long as ARP caches and associated hard and  
software resources can deal with all these resolved addresses.

So I think that this approach would work. It may be implemented as  
feature in (R)bridges. But I think that it is better address it at  
the source and add a (optional) back-off mechanism in ARP/ND  
implementations.

> But that doesn't even have to be in the spec.

True.

> It would be nice to know in operational networks how much traffic  
> is caused by ARP/ND queries, and how
> worried people are about a malicious endnode DOS'ing by sending  
> lots of queries. (but it could just as easily
> send other types of broadcast/multicast traffic so maybe it's not  
> worth worrying about optimization ARP/ND because
> of malicious nodes).

Run a hacker conference network and you'll know that unfriendly ARP  
spoofing is reality. Would you choose to include ARP/ND optimizations  
then you should take that into account too.

Considering the possible consequences of ARP/ND optimizations versus  
what it would gain, I would suggest not to put that in the specs from  
the start. RBridges are probably difficult enough to engineer.  
Besides, I see no reason why this could not be added later on.

Cheers, Arien


--
Arien Vijn
Amsterdam Internet Exchange
http://www.ams-ix.net