[rbridge] ARP proxying

[Guillermo Ibáñez]

I agree with the idea of directing broadcasts as unicast (my proposal 
for ARP Servers/Registrars in Abridges draft also uses unicast), but I 
am a bit lost : How can the first Rbridge know which is the target's 
designated Rbridge if the destianion host'sMAC is unknown?. Perhaps I 
misunderstood something.
Guillermo
Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Directing broadcasts as unicast (as suggested below) is probably a
>better idea in general than replaying given security considerations.
>
>Joe
>
>Radia Perlman wrote:
>  
>
>>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
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>>    
>>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDquNTE5f5cImnZrsRAu9UAKCAHqIrk064jiQ0bd02O2NtVPBUzwCfQhzB
>/hm9XmTTp2h25Gn92MieJ3w=
>=fMOQ
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>

-- 
Guillermo Ibáñez
Departamento de Ingeniería Telemática
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Leganés 91-6248794