[rbridge] ARP proxying

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Guillermo Ibáñez wrote:
> 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?.

That would be a 'cache miss', and MUST result in a broadcast. We're
still assuming an ARP cache at the DRs.

It's only under a 'hit' that a unicast can be provided.

Joe

> Joe Touch wrote:
> 
> 
> 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
> 
> 
> 
_______________________________________________
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

iD8DBQFDrC67E5f5cImnZrsRAg6JAKC62gRQxx5fmJIIoXm+Ttk9NTG35ACeI8tM
y0BqOQY/g0VdKJ+9whD8pZc=
=R2iu
-----END PGP SIGNATURE-----