On Tue, 6 Mar 2007, Mikael Abrahamsson wrote:
Customer gets hacked, one of their boxen starts spewing traffic with spoofed
addresses. The way I understand your solution is to automatically shut their
port and disrupt all their traffic, and have them call customer support to
get any further.
> Disabling their port and punting them to customer support is
> NOT a cost
> efficient way of dealing with the problems, at least not in
> the market I
> am in.
It's like the car rental business. If you want to provide cars to people
without a drivers license, then your customer support peop
Mikael Abrahamsson wrote:
>
> On Tue, 6 Mar 2007, Sean Donelan wrote:
>
>> Isn't this true of everything (bad source addresses, worms, abuse,
>> etc). Does hiding/ignoring the problem just makes it worse because
>> there is no incentive to fix the problem while it is still a small
>> problem? If i
On Tue, 6 Mar 2007, [EMAIL PROTECTED] wrote:
On Tue, 06 Mar 2007 21:54:06 +0100, Mikael Abrahamsson said:
So instead I just drop their spoofed traffic and if they call and say that
their line is slow, I'll just say it's full and they can themselves track
down the offending machine and shut it
On Tue, 06 Mar 2007 21:54:06 +0100, Mikael Abrahamsson said:
> So instead I just drop their spoofed traffic and if they call and say that
> their line is slow, I'll just say it's full and they can themselves track
> down the offending machine and shut it off to solve the problem.
This doesn't so
On Tue, 6 Mar 2007, Sean Donelan wrote:
Isn't this true of everything (bad source addresses, worms, abuse, etc).
Does hiding/ignoring the problem just makes it worse because there is no
incentive to fix the problem while it is still a small problem? If it
isn't important enough to bother the
On Tue, 6 Mar 2007, Mikael Abrahamsson wrote:
Also, all the examples you give implies a BGP transit customer. I am
imagining all kinds of customers, from colo customers where I am their
default gateway, to residential customers where it's the same way.
I tried to give examples upstream of a r
On Sun, 4 Mar 2007, Sean Donelan wrote:
When customers misconfigure their router, e.g. wrong BGP neighbor or
ASN, wrong interface IP address, exceed max prefix limit, etc; don't
they lose Internet connectivity until they fix it?
A properly configure router should never forward even a single
On Sun, 4 Mar 2007, Mikael Abrahamsson wrote:
Instead of dropping packets with unallocated sources addresses, perhaps
backbones should shutdown interfaces they receive packets from unallocated
address space. Would this be more effective at both stopping the sources
of unallocated addresses; a
On 3/2/07, Roland Dobbins <[EMAIL PROTECTED]> wrote:
No one has done the digging required to answer any of these
questions, unfortunately.
Can you get a valid answer to this based on the existence of BCP38?
What I mean is, if your upstream is filtering bogons, you can't get a
good read on the
On Sun, 4 Mar 2007 07:46:12 -0800
"Barry Greene (bgreene)" <[EMAIL PROTECTED]> wrote:
>
> To 'globally' monitor, we have
> http://www.cymru.com/BGP/robbgp-bogon.html and
> http://www.cymru.com/BGP/asnbogusrep.html and
> http://www.cidr-report.org/ and http://www.routeviews.org/ and
> http://www
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Chris L. Morrow
> Sent: Thursday, March 01, 2007 6:23 AM
> To: Jon Lewis
> Cc: Eric Ortega; nanog@merit.edu
> Subject: Where are static bogon filters appropriate? was:
> 96.2.0.0/16 Bogons
>
>
>
> http://www.completewhois.com/hijacked/files/203.27.251.0.txt
>
> http://www.completewhois.com/hijacked/index.htm
>
>
> This can proof the opposite.
>
> Malware comes from redirected allocated blocks, not from bogons.
I don't think this is proof. The haphazard way that BCP38 and ingress
p
On Sat, 3 Mar 2007, Sean Donelan wrote:
Instead of dropping packets with unallocated sources addresses, perhaps
backbones should shutdown interfaces they receive packets from
unallocated address space. Would this be more effective at both
stopping the sources of unallocated addresses; as wel
http://www.completewhois.com/hijacked/files/203.27.251.0.txt
http://www.completewhois.com/hijacked/index.htm
This can proof the opposite.
Malware comes from redirected allocated blocks, not from bogons.
Kind regards
Peter and Karin
Sean Donelan wrote:
On Fri, 2 Mar 2007, Daniel Senie wr
On Fri, 2 Mar 2007, Daniel Senie wrote:
How do you know, if you're the one being attacked and you have no idea if the
originating network or their immediate upstream implemented BCP38? Shall we
just discard ingress filtering? If few attacks are using it today, should we
declare it no longer re
On Thu, Mar 01, 2007 at 07:16:37AM -0800, Peter Thoenen wrote:
[Thoenen seems to have clipped the attribution]
> > Perhaps,
> > bogon acls are helpful when they are configured on backbone, but not
> >
> > everywhere.
>
> And if ever major backbones (read tier 2/3) would do so all us little
>
Speaking of bogons and more practical daily operation issues, perhaps
you guys can help reaching the fine folks at AS7643 or maybe their
upstream provider can be kind enough to filter out the following:
BGP routing table entry for 123.0.0.0/8, version 14613827
Paths: (1 available, best #1, not
On Mar 2, 2007, at 1:18 PM, Sean Donelan wrote:
How much of a problem is traffic from unallocated addresses?
Backbone operators probably have NetFlow data which they could mine
to find out.
On the other hand, how much of a problem is obsolete bogon filters
causing
everytime IANA delegat
At 04:18 PM 3/2/2007, Sean Donelan wrote:
On Fri, 2 Mar 2007, Roland Dobbins wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur - but it seems that many seem to be looking for someone
--- [EMAIL PROTECTED] wrote:--
> I think this really goes to the heart of the matter - the inability/
> unwillingness to prioritize and allocate resources to properly
> implement 'good neighbor' policies which are not perceived as having
> any financial benefit to the
On Fri, 2 Mar 2007 15:37:01 -0600
"Eric Ortega" <[EMAIL PROTECTED]> wrote:
>
> I think Sean raises a good point. I guess the larger picture is what
> are we trying to protect and what are trying to protect that from.
>
Bingo.
The problem isn't with "security people", it's with "security peopl
Cc: NANOG
Subject: Re: Where are static bogon filters appropriate? was: 96.2.0.0/16
Bogons
On Fri, 2 Mar 2007, Roland Dobbins wrote:
>> Sometimes, network operators have to take the bull
>> by the horns and develop their own systems to do a job that vendors
>> simply don't
On Fri, 2 Mar 2007, Roland Dobbins wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur - but it seems that many seem to be looking for someone else to do
this for them (or, perhaps, the l
On Mar 2, 2007, at 7:31 AM, <[EMAIL PROTECTED]> wrote:
Sometimes, network operators have to take the bull
by the horns and develop their own systems to do a job that vendors
simply don't understand.
Concur - but it seems that many seem to be looking for someone else
to do this for them (or
> No, the SP can't be the 'Internet
> firewall' for customers,
They can if the SP supplies and manages the CPE device. Nowadays, a lot
of functionality could potentially be provided in a CPE device. Hardware
cost and hardware capabilities are no longer barriers to doing this.
There is still s
On Fri, 02 Mar 2007 08:55:42 GMT, [EMAIL PROTECTED] said:
> > one, I'm an example of another, and the advocates of static bogon filters
> > are
important word alert --> ^^
> policy and management of that policy. Bogon filters are
> an example of a policy implem
On Mar 2, 2007, at 4:12 AM, Robert E. Seastrom wrote:
uRPF isn't always adequate for all antispoofing cases, as you know.
What about iACLs?
bogon
filtering by end sites is the sort of thing that is recommended by
"experts" for whom "security" is an end in and of itself, rather than
a com
Roland Dobbins <[EMAIL PROTECTED]> writes:
> On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
>
>> So... again, are bogon filters 'in the core' useful? (call 'core' some
>> network not yours)
>
> Antispoofing is 'static' and therefore brittle in nature, people
> change jobs, etc. - so, we shou
> I think this really goes to the heart of the matter - the inability/
> unwillingness to prioritize and allocate resources to properly
> implement 'good neighbor' policies which are not perceived as having
> any financial benefit to the organization.
>
> So, can this sort of activity someh
On Mar 2, 2007, at 12:55 AM, <[EMAIL PROTECTED]> wrote:
One might argue that if a company is not capable of
setting a policy and managing that policy, then you
should not implement the policy at all.
I think this really goes to the heart of the matter - the inability/
unwillingness to prior
> Well Steve, it's like this: There are (a) security experts,
> (b) "security
> experts", and (c) guys that spend their day making things
> usable in spite of
> what the rest of the net throws in their AS's direction.
> You're an example of
> one, I'm an example of another, and the advocates
On Thu, Mar 01, 2007, Roland Dobbins wrote:
>
>
> On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
>
> >So... again, are bogon filters 'in the core' useful? (call 'core' some
> >network not yours)
>
> Antispoofing is 'static' and therefore brittle in nature, people
> change jobs, etc. - so
On Thu, 01 Mar 2007 21:08:59 EST, "Steven M. Bellovin" said:
> On Thu, 01 Mar 2007 14:22:37 + (GMT)> "Chris L. Morrow" <[EMAIL
> PROTECTED]> wrote:
> > So, where are static bogon filters appropriate? (loaded question
> > perhaps) I ask because just about every 'security expert' and
> > 'securi
On Thu, 01 Mar 2007 14:22:37 + (GMT)
"Chris L. Morrow" <[EMAIL PROTECTED]> wrote:
>
> On Thu, 1 Mar 2007, Jon Lewis wrote:
>
> > On Wed, 28 Feb 2007, Eric Ortega wrote:
> >
> > > I'd like to thank the group for the responses and help with this
> > > issue. I find it ironic that Randy's stud
On Mar 1, 2007, at 1:10 PM, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
Antispoofing is 'static' and therefore brittle in nature, people
change jobs, etc. - so, we shouldn't do antispoofing, either?
Enterprises typicall
On Mar 1, 2007, at 11:33 AM, Chris L. Morrow wrote:
I absolutely agree, but without some tool or process to follow...
we get
stuck acls/filters and no idea that there is a problem until it's
far into
the problem :(
There are canonical email lists on which these changes are announced,
a
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours) The cisco auto-secure feature sure showed some fun
effects for this too, eh?
We managed to fix that mis-application in later releases, but it has
human dependen
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
The challenge for folks on the far side of this problem
(69box.atlantech.net for instance or midco) is finding a way to get this
adjusted.
69box.atlantic.net
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)
On Thu, 1 Mar 2007, Jon Lewis wrote:
> Such updates get posted to various places like nanog, cisco-nsp, probably
> other -nsp lists, and such...but for the large number of ASNs not
> represented at all on those lists, I don't know how they're supposed to
> "get notified" every time a bogon ceas
Hey, Chris.
ah-ha! but seriously, is this something an NSP/ISP should be doing?
or is
this an enterprise function? or MSSP function? Are there standard
tools
available to notify folks when changes occur? (aside from: "go check
iana.org website" or "golly traffic's not flowing anymore")
We
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is
this an enterprise function? or MSSP function? Are there standard tools
available to notify folks when changes occur? (aside from: "go check
iana.org website" or "golly traffic's
On Thu, 1 Mar 2007, Roland Dobbins wrote:
>
>
> On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
>
> > So, where are static bogon filters appropriate?
>
> #define static
>
> Obviously, one's bogon filters (both for iACLs and for prefix-lists
> or whatever other mechanism one uses to filter th
On Thu, 1 Mar 2007, Jon Lewis wrote:
> On Thu, 1 Mar 2007, Chris L. Morrow wrote:
>
> > So, where are static bogon filters appropriate? (loaded question perhaps)
> > I ask because just about every 'security expert' and 'security whitepaper'
> > or 'security suggestions' has some portion that sp
> Perhaps,
> bogon acls are helpful when they are configured on backbone, but not
>
> everywhere.
And if ever major backbones (read tier 2/3) would do so all us little
guys wouldn't have to (yet for some reason I keep getting the odd hit
in my acl logs from bogon space daily).
Yes I know the
Jon Lewis wrote:
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So, where are static bogon filters appropriate? (loaded question
perhaps)
I ask because just about every 'security expert' and 'security
whitepaper'
or 'security suggestions' has some portion that speaks to "why it's a
grand idea t
On Mar 1, 2007, at 6:22 AM, Chris L. Morrow wrote:
So, where are static bogon filters appropriate?
#define static
Obviously, one's bogon filters (both for iACLs and for prefix-lists
or whatever other mechanism one uses to filter the route
announcements one accepts) must be dynamic enoug
On Thu, 1 Mar 2007, Chris L. Morrow wrote:
So, where are static bogon filters appropriate? (loaded question perhaps)
I ask because just about every 'security expert' and 'security whitepaper'
or 'security suggestions' has some portion that speaks to "why it's a
grand idea to have acl-lines/fire
48 matches
Mail list logo