On Tue, Apr 10, 2001 at 01:17:38AM +0200, Dmitri Kalintsev wrote:
> On Mon, Apr 09, 2001 at 01:35:02PM +0200, Jesper Skriver wrote:
>
> > We here allow rfc1918 sources by choice, as dropping them will cause
> > pMTUd problems when the link with the smaller mtu use rfc1918 addresses,
> > and there are such links out there in the world, even though we don't
> > use them ...
>
> I personaly don't see any value in accepting packets with sources I cannot
> get back to. We filter them, and nobody yet complained. If people were not
> foreseeing enough to deploy rfc1918 on their networks and leaking these into
> the Internet, they are fully responsible for the consequences, not me.
But it's your customers that experience problems too, and complain to
you.
The thing about pMTUd, is that most customers don't understand it, and
probably most of the people in the operation centers around the world
doesn't either, so you will never know when your customers have problems
related to pMTUd.
> I'd like to ask you if I may: what counter-DoS measures you employ to
> protect your network and your customers, as well as protecting the Internet
> from your customers misbehavior? (Having powerful routers which are not
> affected by any possible (d)DoS does not count) ;)
First, allowing packets into the network (from a transit provider, or a
peering partninger) with a rfc1918 source doesn't make any difference.
But we apply strick anti-spoofing filters on ALL customers, so that they
cannot send any packets onto the interface with a source address
different from the ones they've been assigned.
And regarding protecting the customers, there is nothing bulletproof way
of identifying a DoS, so they cannot be dropped in filters or similar,
so we do what one can do, monitor the network for unusual traffic
patterns, and have humans look at them, when they are detected.
/Jesper
-- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: FreeBSD committer @ AS2109 (A much smaller network ;-)One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT