[rbridge] Max Network size

[Joe Touch]

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



Gray, Eric wrote:
> 
>>-----Original Message-----
>>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]On
>>Behalf Of Joe Touch
>>Sent: Friday, May 06, 2005 12:44 PM
>>To: Developing a hybrid router/bridge.
>>Subject: Re: [rbridge] Max Network size
> 
> 
> [.. SNIP ..]
> 
> 
> 
>>Guillermo Ibáñez wrote:
>>
>>>...
>>>
>>>>> I wonder if an ARP server/registrar approach can be foreseen 
>>>>> as an alternative or complementary strategy. The Designated 
>>>>> Rbridge registers each host, when an ARP is received, at a
>>>>> (distributed) ARP server.
>>>> 
>>>> When an ARP reply is received, that can be done. But the first
>>>> ARP to an otherwise unknown host, which has silently attached
>>>> to a stub at an RBridge ingress, is unknown. The only way to
>>>> find it is to flood.
>>>
>>>True. But this is the only case.
>>
>>The problem is that it's the defining case. All others can, as you
>>observe, be optimized with a variety of engineering solutions. IMO, none
>>are all that interesting - ARP already caches at the endhost anyway.
> 
> I had a similar discussion with a colleague a few years back.
> Apparently, there are a growing number of networks where it's
> not necessary to flood packets.

Not IP over Ethernet. ;-)

> This is the case whenever an attaching host is required to do
> something active before it can go into a passive mode - such 
> as obtain IP address, default router, DNS server, etc. from a 
> DHCP server.

You can assert that sort of requirement for a deployment, but it's not
part of ethernet, IP, DHCP, or DNS. E.g., DHCP helps configure you, but
only when you don't have config info. If you move ethernets within an
enterprise (i.e., within a campus deployment), you don't necessarily
contact DHCP when you move.

> Given the prevalence of dynamic address configuration at this
> time, there are plenty of examples of networks where it is not
> possible for a host to "silently attach".

But they can silently move. And dynamic configuration is never a
requirement of any of these protocols; it may be the requirement of a
deployment. We don't want RBridge to be limited to those sorts of
deployments.

> While this creates interesting points of confusion since some
> people may have direct experience with networks like this that
> (ostensibly) work, the fact is that working with a network of
> this type presents special problems and is not ubiquitously
> possible as of yet.

Agreed...

>>>>>This 
>>>>>can help to enforce security (like preventing MAC spoofing) and  also 
>>>>>ensure ARP resolution in one step without broadcast. 
>>>>
>>>>Correct the above if not correct, but assuming that there is no way to
>>>>secure ARP that doesn't modify ARP too.
>>>> 
>>>
>>>ARP query would be performed by the Designated Router (encapsulated 
>>>query directed to the ARP server).
>>
>>The ARPs are originated outside the campus; the two options are to
>>encapsulate the ARP and broadcast it or to encapsulate it and send it to
>>an internal cache (the ARP server). Neither is secure, since they are
>>triggered by external, unauthenticated ARPs.
>>
>>
>>>I am not expert, but I guess the 
>>>server can autenticate the DRs.
>>
>>Sure - but that only authenticates the internal cache; there's no way to
>>authenticate the initial broadcast whose reply is used to populate the
>>cache.
>>
>>
>>>I agree that a host may spoof its MAC 
>>>but security measures are possible both at the ARP server (the spoofed 
>>>host is registered in same server) and at the DR (attacks and  behaviour
>>>will likely concentrate on a certain port of  DR) 
>>
>>Why bother? As above, we already need to support broadcast ARP to
>>bootstrap. Besides, securing the internal protocol complicates the
>>deployment. There's little utility to securing the ARP cache
>>communication this way, IMO, unless you've already secured internal
>>control communication (e.g., routing) for other reasons.
>>
>>
>>>>> The point is to distribute the load of ARP registry and
>>>>> queries between multiple ARP servers. This may be based on IP
>>>>> hashing.
>>>> 
>>>> Sure, hashing will direct you to the right cache. But how does
>>>> that cache know what to reply? It can't unless IT floods;
>>>> that's the catch-22.
>>>
>>>The caché knows the content because it is the unique both server and 
>>>registrar for the IP addresses set. Prior to that query, upon first ARP 
>>>issued  the host was registered by the DR at that caché, based on its 
>>>hash(IP). 
>>
>>ARP may announce the location of the ARP sender, but doesn't announce
>>the location of the ARP reply. Both need to be snooped to load the
>>cache. The trouble is the first ARP _to_ any new IP address must always
>>be broadcast; by definition, it won't be in the cache.
> 
> For the same reason, this is not always the case.  If it is likely
> that every host will know the IP (and MAC) address of a default
> router, all ARP traffic from that point on may be unicast directed 
> to the default router.

Only if it only talks to the router or IP addresses elsewhere; IP
addresses within the LAN won't be handled.

> This can be a big if, however, in some networks and should not be
> assumed.
> 
>>>An ARP cache query from host would produce from DR two 
>>>packets : a registration of originating host at ARP registrar and an ARP
>>>query of destination host at ARP server. 
>>
>>What does the ARP server do with a request of the destination if it
>>hasn't seen any communication from that host before?
> 
> It could respond exactly as it would if the host was not attached.
> This could be appropriate behavior in networks where silent host
> attachment is a non-starter anyway.

Yes - we could prohibit silent attachment and silent movement. How, in
that case, does the first communication ensue? You need to force
something outside the RBridge system (DHCP server, default router, etc.)
to do something it doesn't do now...

> The poster-child example is the typical small network with a single
> DHCP server that also happens to be the Internet attachment point,
> firewall, NAT and default router.  This is the increasingly common
> - but not (yet) universal - case.

Sure. But this is, in a lot of ways, just another version of an
optimization. We definitely need to cover the case where the
optimization isn't in place anyway...

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCe7ENE5f5cImnZrsRAlEqAJ4jS9SKWVumA04Jww7dEtiliX/piwCgrLF4
pMbithlRy+9xumBJbx2Tmtc=
=qG76
-----END PGP SIGNATURE-----