On Sat, 2 Feb 2008, Tomas L. Byrnes wrote:
I sincerely doubt that any backbone provider will filter at a /32. That
means they have to check EVERY PACKET AT FULL IP DEST against your AS
advertised routes. Since most backbone routers build circuits at the /18
and above mask on MPLS, just to
yes absolutely, if an agreement could be reached - then that is a neater
solution, but I wonder if an agreement could ever be reached in a
timescale that doesn't make deployment of the alternative more
attractive as it doesn't require everyone to agree.
From:
Hi,
I am no lawyer, but I question whether ATT can patent anything that uses
the existing technology and commands implemented in BGP. The idea that
you can patent a persons intent in advertising a prefix in BGP seems
somewhat bizarre. Surely a patent relates to the use of a new bit of
IANAL, but my understanding of patents is that anyone can patent any
innovative combination of existing things, if it produces a new effect
or is used in a new way. According to the patent lawyers I've worked
with, that is, in fact, the most common type of patent. As an example,
Watt's steam
On Feb 3, 2008 2:53 PM, Tomas L. Byrnes [EMAIL PROTECTED] wrote:
3: Backbone routers can't reasonably filter on a bunch of /32s and also
forward traffic at wire speed.
yes they can. the size of the individual route doesn't matter to the
devices in question, the NUMBER of routes does... (as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
anyway, the idea behind multi-as blackholing has been (and
apparently continues to get) rehashed a few times over the
last 5-8 years... good luck!
It seems that way. People seem to forget about the conversations and
work around 2000 -
Hi Barry,
Thank you for some really useful pointers, I am off to do some more
reading.
Kind Regards
Ben
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Barry Greene (bgreene)
Sent: 03 February 2008 21:07
To: Christopher Morrow; Tomas L. Byrnes
Cc:
Hi,
snip
your point here is that perhaps instead of this scheme one would just
advertise the max-prefix-length (/24 currently) from a 'better' place on
your network and suck all the 'bad' traffic (all traffic in point of
fact) for the attacked destination via a transit/peer/place which can
deal
On Feb 3, 2008 5:18 PM, Ben Butler [EMAIL PROTECTED] wrote:
Hi,
snip
your point here is that perhaps instead of this scheme one would just
advertise the max-prefix-length (/24 currently) from a 'better' place on
your network and suck all the 'bad' traffic (all traffic in point of
fact)
If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
I can think of at least one Global Tier One that offers a service that
allows one to do exactly this (ie. advertise a /30 or /32
[EMAIL PROTECTED] (Ben Butler) writes:
...
This hopefully will ensure a relatively protected router that is only
accessible from the edge routers we want and also secured to only accept
filtered announcements for black holing and in consequence enable the
system to be trusted similar to
Hi,
I was not proposing he Null routing of the attack source in the other
ISPs network but the destination in my network being Null routed as a
destination from your network out.
This has no danger to the other network as it is my network that is
going to be my IP space that is blackholed in
You could achieve the exact same result simply by not advertising the
network to your peers, or by advertising a bogus route (prefixing a
known bogon AS for the addresses you want null-routed). I realize you
would have to subnet/deaggregate your netblocks, and therefore could
wind up with a
On Feb 2, 2008, at 1:16 PM, Ben Butler wrote:
So, given we all now understand each other - why is no one doing the
above?
Some folks are doing this, just not via some third-party
route servers. For example, either via customer peering
sessions, or other BGP interconnections between peers.
On Feb 2, 2008 3:39 PM, Tomas L. Byrnes [EMAIL PROTECTED] wrote:
The bigger issue with all these approaches is that they run afoul of a
patent applied for by ATT:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u
I was not proposing he Null routing of the attack source in the other
ISPs network but the destination in my network being Null routed as a
destination from your network out.
i explained why this is bad -- it lowers the attacker's costs in what
amounts to an economics war. they can get a web
destination-based blackhole routing for mitigation *effectively
completes the attack*, which is often times undesirable. Inter-domain
source-based blackhole routing is pretty much a non-option.
That is why I put Completing the Attack in my subject line - and didnt
attempt to sujest this as an
Hi,
i explained why this is bad -- it lowers the attacker's costs in what
amounts to an economics war. they can get a web site taken down by its
own provider just by attacking it. they need fewer resources for their
attack once they know the provider's going to blackhole the victim.
I
If you're trying to do it on a /32 basis, I doubt you'd find too many
border router operators interested in accepting a route that small, but
I may be wrong.
Well then they wouldn't be peering with this route reflector in the
first place.
-Original Message-
From: Tomas L. Byrnes
While I am not sure I fully understand your suggestion, I don't think it
would be that hard to set up manually.
Sure it would require asking the individual peers for their black hole
communities, but of they don't have one they are unlikely to honor the
infrastructure you describe anyway.
Assume
On Feb 3, 2008, at 4:50 AM, Paul Ferguson wrote:
We (Trend Micro) do something similar to this -- a black-hole BGP
feed of known botnet CCs, such that the CC channel is effectively
black-holed.
What's the trigger (pardon the pun, heh) and process for removing IPs
from the blackhole list
ATT has no reason to pull their application, what needs to happen is
that the publisher of the prior art contact the USPTO.
If ATT willingly failed to note the prior art in their app, that may be
a problem, but it isn't their duty to report ALL prior art, just the
stuff they know about.
IANAL,
On Feb 2, 2008 11:40 PM, Tomas L. Byrnes [EMAIL PROTECTED] wrote:
ATT has no reason to pull their application, what needs to happen is
that the publisher of the prior art contact the USPTO.
If ATT willingly failed to note the prior art in their app, that may be
a problem, but it isn't their
I see your point, but I think maintaining the box for the control session
would also require a decent amount of work.
Presumably, since you must all adhere to some quasi-standard to communicate
with the control peer, you could probably also agree on creating a standard
BGP community (ie. 64666:666
Well then they wouldn't be peering with this route reflector
Well then, the utility is probably close to 0, isn't it?
I doubt most of the sources of DDOS traffic, especially those without
ingress source filtering, are going to peer with your route reflector.
What's their economic incentive to
25 matches
Mail list logo
