Subject: [rbridge] Max Network size

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 6 May 2005 13:31:54 -0400

> -----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.

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.

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".

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.

> 
> >>>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.

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.

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.

> Joe
>   [.. SNIP ..]

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 06 May 2005 11:01:49 -0700

Gray, Eric 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.
>>>

Not IP over Ethernet. ;-)

> as obtain IP address, default router, DNS server, etc. from a 

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.

> 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.

> this type presents special problems and is not ubiquitously

Agreed...

>>>>> 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.
>>>

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

> 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...

> - 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

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri, 06 May 2005 13:06:51 -0700

> contact DHCP when you move.

Even than the host needs to perform some tests to know it is still
connected to the same IP subnet. Like the reachability test outlined in
http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The
test is using ARP....

> optimization isn't in place anyway...

I agree.....

Let's not rely on presence of optimizations. Nevertheless let's
enumerate them, so that people don't think they are always stuck with
the worst case scenario.

Alper

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 06 May 2005 13:26:27 -0700

> http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The

It CAN use that test, but doesn't have to. There are devices that don't
bother to say anything until they have something to say, rather than
just when an interface regains signal...

(which is why the DHC draft above isn't a requirement, but an optimization).

> enumerate them, so that people don't think they are always stuck with

I'm not arguing against discussing optimizations at all; just that we
need to implement the base case regardless. And to make sure the
optimizations don't come with any downside (i.e., when they fail, they
shouldn't interfere with what would have happened were they not there).

Joe

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri, 06 May 2005 14:09:49 -0700

> http://ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-11.txt . The

Yes, but many/most existing implementations do not perform such checks.
When I move my host from one Ethernet switch port to another, or 
associated with a different 802.11 AP, the stack silently assumes that 
this is the same IP subnet as before.
While we have a DNA WG and the above draft which tries to make this work 
better, I don't think TRILL should assume that such mechanisms are 
implemented in all the hosts.

    Erik

---

From: alper.yegin at samsung.com (Alper Yegin)
Date: Fri, 06 May 2005 14:25:04 -0700

> (which is why the DHC draft above isn't a requirement, but an

I don't expect all hosts to be implementing this draft overnite. So, I'm
not proposing to take this as the baseline "host behavior." In that
sense I agree with you. I just wanted to note that, for any reasonable
host that moves around and cares to establish reachability as fast as
possible, it is reasonable to expect them to do something. The
reachability test mentioned in that I-D is an example.

> shouldn't interfere with what would have happened were they not
there).

I agree.

Alper