[rbridge] ARP proxying

[Radia Perlman]

And even without modifying SEND, it's possible to do a compromise 
optimization.
The totally nonoptimized thing is to flood the ARP/ND query, and have each
Designated RBridge decapsulate and send it on each of the links. The 
most optimized thing
is to have the first RBridge send the ARP/ND response to the querier.

An in-between
thing that works with current SEND (and probably any possible variation 
that it might
evolve into) is to have the first RBridge send the query to the target's 
designated RBridge,
who would send the query to the target, get a response, and send it back.

Radia



Christian Huitema wrote:

>>>	In addition, since the RBridge enjoys a man-in-the-middle
>>>      
>>>
>position,
>  
>
>>>it is likely that implementers may well implement some hack or
>>>      
>>>
>another
>  
>
>>>to get around this.
>>>      
>>>
>
>SEND is explicitly designed to prevent this kind of hacks.
> 
>  
>
>>There doesn't need to be a hack - though I expect that would be
>>prohibited by the security model in SEND anyway. But SEND doesn't
>>prohibit sharing the keys, which the rbridge could be party to.
>>    
>>
>
>Well, there is no explicit protocol to share the keys used in SEND. One
>might argue that sharing these keys would in fact be a gross security
>violation. The keys are cryptographically linked to the IPv6 address,
>and could be used for many applications besides security the IPV6/MAC
>address mapping. There have been proposal to use them for IPSEC and for
>Mobile IP.
>
>Now, we could question the value of securing the mapping between IP
>address and MAC address in a switched/routed environment. After all,
>even if the mapping was secure, the relays could still decide to rewrite
>the MAC address, and deliver the packets to whatever point they feel is
>appropriate. SEND can hardly provide a protection against that. One
>possible outcome would be to recognize that SEND, as currently
>specified, is not really secure.
>
>In fact, we went through a similar analysis of the value of 802.1X
>access controls for wired networks. In wireless networks, 802.1X
>associates a MAC address with an encryption context on the access point.
>But on wired networks, 802.1X only "authorises a MAC address", without
>any further protection. Insert a hub on the path, and all kinds of
>interesting attacks become possible.
>
>The IEEE is working on a better solution for access control to wired
>networks. It will probably involved some level of layer 2 encryption.
>SEND probably needs to evolve in a same way. If it does evolve, then
>there could be an additional requirement, i.e. accept the presence of
>relays on path.
>
>-- Christian Huitema
>
>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>