LARTC - Aug 2002 - Q: best solution to stop traffic to huge amount of unregistered hosts

Hi

perhaps someone else already had the same problem.

Problem description:

I''m running a class B University network with approx 10k hosts
attached. I would now like to stop traffic from and to hosts
in my network not already registered in my DNS server.

This means I''ve to handle with approx 50k rules|routes. Sure
I can summarize the unalloctaed address space a little bit
with masks to approx 30k rules, anyway this seems to be a problem.

Question:

What will be the best solution between the different choices
netfilter/iptables, ip route(s) ... type prohibit and
tc filter ... u32 ... police 0kbps

netfilter/iptables doesn''t seem to scale well and the only
match module "pool" which is able to deal with pools of addresses
seemes to stay in alpha state.


With ip route I think I have to describe all unregistered hosts
to stop traffic and not the smaller amount of registered hosts.
Does the FIB and route cache scale well to approx 30k routes?

Is it possible and more performant to use tc to throttle down
traffic to unregistered hosts already in the ingress lane
without hitting the routing and netfilter engine with this
traffic? Does tc scale well with this huge amount addresses/masks?

How could this be handled with tc?

Regards and thanks in advance for any hint
	Charly

P.S. Speed is important, this linux router/firewall connects
Gigabit Ethernet networks

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:karl.gaissmaier@rz.uni-ulm.de          Network Administration
Tel.: ++49 731 50-22499
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Marian Jancar schrieb:
> 
> On Thu, 22 Aug 2002 09:38:58 +0200
> "Karl Gaissmaier" <karl.gaissmaier@rz.uni-ulm.de> wrote:
> 
> > I''m running a class B University network with approx 10k
hosts
> > attached. I would now like to stop traffic from and to hosts
> > in my network not already registered in my DNS server.
> >
> > This means I''ve to handle with approx 50k rules|routes. Sure
> > I can summarize the unalloctaed address space a little bit
> > with masks to approx 30k rules, anyway this seems to be a problem.
> 
> Create tree with decreasing netmask, you will have more rules in total
> but packets will have to travel through only few of them.
Yep, I thought already about this. If I set decreasing netmasks from /17
to /32 	I would end up with 2^16 chains but after 16 comparisons
I would have a match. This would be the extreme!

If I create 256 different chains based on a /24 netmask
then I would have a match at least after 256 + 256 = 512
comparisons. The first max 256 comparisons select the
next chain and the last max 256 comparisons select the
/32 address in this special chain.

Anyway I find this ugly with iptables that we have no
MADDR match (in analogy to MPORT). If you build a firewall
you try always to build groups of services (mport) and
groups of servers/clients (maddr). With iptables you have
to reply the same rule n times for n similar servers/clients.

This is ugly and a performance bottleneck because these
similar rules are cheched sequentially.

Best regards and thanks for your tip.

	Charly

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:karl.gaissmaier@rz.uni-ulm.de          Network Administration
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Robert Collier schrieb:
> 
> Hi Karl,
> 
> I don''t have any suggestions for an easy way to solve your problem
-
> but:
> 
> On Thu, Aug 22, 2002 at 09:38:58AM +0200, Karl Gaissmaier wrote:
> > With ip route I think I have to describe all unregistered hosts
> > to stop traffic and not the smaller amount of registered hosts.
> > Does the FIB and route cache scale well to approx 30k routes?
> 
> With ''large routing tables'' enabled the kernel works just
fine with a
> full internet routing table of 115,000 routes so a mere 30,000 should
> be a doddle.
> 
> Your main problem will be getting the routes into the kernel.
Yes this is a problem. I tried for fun to build a 64k routing table
with:
ip route add type prohibit 10.0.i.j
(i=0..255; j=0..255)
and this took more than one hour on my home desktop (old pentium 90)
to fill the routing table.
Even if I know that this is pretty old stuff I was astonished over this
slow progress.

The question that arises is now for me, how long does it take
for a full internet routing table to get synchronized after
a route flush with a linux router?

Anyway, you told me that the kernel works fine with 115k routes
but be aware I will use this with Gigabit Interfaces.

What is the average forwarding time in ms for a packet with
115k routes?

Best regards and thanks for your answer
	Charly

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:karl.gaissmaier@rz.uni-ulm.de          Network Administration
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Gerry Creager N5JXS schrieb:
> 
> The answers are not necessarily pretty.
> 
> I''ve done a similar task with a Juniper M5 router.  It will handle
up to
> about 180,000 rules at wire speed.  But it is expensive.
> 
> If your switches were a little newer, we could use 802.1x to enable the
> switch-use capability flag (:-) and solve the problem.
you know, 10k hosts are never attached to a network with homogenous
new network devices :-(
> 
> Instead of policing at a single edge point, you might consider policing
> at dormatory and building edges, where the load is smaller and you can
> use masking and diminsh the ruleset some more.
but the management is very difficult, see above
> 
> With a sufficiently fast box, or series of boxes, doing specific tasks,
> you should be able to do this.  Folks like Juniper achieve it by being
> able to classify and mark in ASIC without having to go to the processor.
Netfilter and iproute2/tc is very good but I miss just a fast
matching module for a "pool" of ip addresses and the missing tc-cref
or better documented tc examples, especially dealing with general
ingress policing.

Best regards
	Charly

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:karl.gaissmaier@rz.uni-ulm.de          Network Administration
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Karl Gaissmaier wrote:
> Gerry Creager N5JXS schrieb:
> 
>>The answers are not necessarily pretty.
>>
>>I''ve done a similar task with a Juniper M5 router.  It will
handle up to
>>about 180,000 rules at wire speed.  But it is expensive.
>>
>>If your switches were a little newer, we could use 802.1x to enable the
>>switch-use capability flag (:-) and solve the problem.
> 
> 
> you know, 10k hosts are never attached to a network with homogenous
> new network devices :-(
Unfortunately, I do.  We have 50k hosts, more or less, on 2 class B 
address spaces.  We have about 200 buildings, and I''m not sure how many
wiring closet switches.  And worse, yet, how many wiring closet hubs!

Our (switched) dorm hosts are about 10k.

So, I understand the issues.  The comment about newer gear, and 802.1x, 
however, stands.  This will provide some capability to handle registered 
hosts in the future, perhaps... but I remain skeptical.
>>Instead of policing at a single edge point, you might consider policing
>>at dormatory and building edges, where the load is smaller and you can
>>use masking and diminsh the ruleset some more.
> 
> 
> but the management is very difficult, see above
Correct, but you have several management issues.  One is unnecessary 
delays while filtering, marking and queuing.  Another is device 
configuration.  I''ve found little existing useful software for
real-life
multiple device (and heterogeneous device) management.  And none I''m 
willing to pay for.  I _do_ have a team of graduate students who are 
working on a heterogeneous-environment configuration tool, but it''s not
nearly ready for prime time.
>>With a sufficiently fast box, or series of boxes, doing specific tasks,
>>you should be able to do this.  Folks like Juniper achieve it by being
>>able to classify and mark in ASIC without having to go to the processor.
> 
> 
> Netfilter and iproute2/tc is very good but I miss just a fast
> matching module for a "pool" of ip addresses and the missing
tc-cref
> or better documented tc examples, especially dealing with general
> ingress policing.
We have experimented with A Juniper M5, as a shaping and filtering box 
for specific applications.  It worked well in the tests, but is an 
expensive toy for this.  You might consider a Sitara box for some off 
your work.

I prefer the Linux approach, too, but there are times where scalability, 
due to the state of the art (and certainly not for want of advancement 
in the state of the art!) means a commercial solution.  What HAS 
happened, though, is that my expectations for the commercial products 
are now higher than they were... and the salesmen are somewhat worried.

Regards,
Gerry

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

On Thu, Aug 22, 2002 at 07:02:26PM -0500, Gerry Creager N5JXS
wrote:
> 
> Our (switched) dorm hosts are about 10k.
How do you deal with ip theft?
> 
> Regards,
> Gerry
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Regards.

-- 
 ... ___________________________________________________________ ...
|   /|                                                         |\   | 
|  /-| Pedro Larroy Tovar. PiotR | http://omega.resa.es/piotr  |-\  |
| /--|            No MS-Office attachments please.             |--\ |
o-|--|              e-mail: piotr@omega.resa.es                |--|-o 
|  \-|    finger piotr@omega.resa.es for public key and info   |-/  | 
|...\|_________________________________________________________|/...| 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Hi Don,

Don Cohen schrieb:
> 
> Just reading mail that arrived while I was on vacation ...
> 
> Several points.
> - In order to use the current tc you don''t have to match all of
the
> illegal addresses (64K - 10K) - it would be easier to default to
> disallow packets and match the smaller 10K that are allowed.
> 
actually I can do this with three independent ore loosely coupled
systems:

iproute2
netfilter
tc

netfilter is to slow for 10k rules and if I use hierarchical prefixes
I have a lot of chains and still ca. 500 rules in worst case.

With iproute2 I could do this with a prohibit rule, but then I have
the bigger amount of disallowd addresses.

I think in the moment tc is the best solution, but how could this
be handled on ingress shaping to a 0 kbps queue?
> - What you really want, of course, is a new module that does a simple
> table lookup to decide whether to classify a packet.  This should be
> easy to write.  The hard part is filling the table - I don''t even
know
> where your data comes from.
the comes programmatically from the DNS system by a walk throug.
I check once a day all Class B addresses whether they are registered.
> 
> - I''d expect your addresses to not be uniformly distributed.  A
right!
> reasonable routing scheme would assign different class-c''s to
> different departments/dorms; many class c''s don''t exist
and you
> can eliminate those immediately; those that do probably go to other
> routers and those can do further filtering.
> An additional benefit of this more distributed solution is that,
this must be done a the central FW, because the other routers
are from different vendors with even different capabilities.
This would not be manageable.
> at least for traffic originating inside your network, earlier
> filtering prevents one class c from denying (outbound) service to
> others.  I''d guess that you''re less concerned with
outside attackers
> sending to these bogus addresses without provocation from inside.
Regards
	Charly

-- 
Karl Gaissmaier          Computing Center,University of Ulm,Germany
Email:karl.gaissmaier@rz.uni-ulm.de          Network Administration
Tel.: ++49 731 50-22499
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/