[FYI. ---rsk ]
- Forwarded message from ARIN -
> Date: Tue, 24 Jan 2017 12:59:04 -0500
> From: ARIN
> To: arin-annou...@arin.net
> Subject: [arin-announce] ARIN DoS Attack
>
> Starting at 10:53 AM ET on Tuesday, 24 January, a DoS attack began
> against ARIN. This
:41 PM
To: 'NANOG'
Subject: DOS Attack
Hi
Do you know about a DOS attack protection provider that you can recommend to
me please?
Thank you
KARIM M.
Hi
Do you know about a DOS attack protection provider that you can recommend to
me please?
Thank you
KARIM M.
On Wed, Mar 25, 2015 at 8:50 AM, John Kristoff wrote:
> On Wed, 25 Mar 2015 08:27:14 -0400
> Rob Seastrom wrote:
>
>> John's statement was in the context of general advice to be included
>> in a BCOP document and I felt compelled to say "whoa there".
ok, that was my reaction as well.
> My inten
Other phrases can be substituted.
"no guts, no glory"
"go big or go home"
"no pain, no pain"
Chuck
-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Scott Weeks
Sent: Wednesday, March 25, 2015 1:41 AM
To: nanog@nanog.org
Subject
On Wed, 25 Mar 2015 08:27:14 -0400
Rob Seastrom wrote:
> John's statement was in the context of general advice to be included
> in a BCOP document and I felt compelled to say "whoa there".
My intent was for it to be taken as a DDoS mitigation response option,
not as a general practice.
John
Christopher Morrow writes:
> On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom wrote:
>>
>> John Kristoff writes:
>>
>>> If the attack is an infrastructure attack, say a routing interface that
>>> wouldn't normally receive or emit traffic from its assigned address
>>> except perhaps for network co
--
> measures". I volunteer to write the article on "YOLO upgrades",
> wherein one loads untested software on equipment with no OOB, types
> "request system reboot", shouts "YOLO", and hits return.
:: YOLO
-
If a manager forces me to do
On Tue, Mar 24, 2015 at 5:27 AM, Rob Seastrom wrote:
>
> John Kristoff writes:
>
>> If the attack is an infrastructure attack, say a routing interface that
>> wouldn't normally receive or emit traffic from its assigned address
>> except perhaps for network connectivity testing (e.g. traceroute) o
On 3/24/15 5:27 AM, Rob Seastrom wrote:
John Kristoff writes:
If the attack is an infrastructure attack, say a routing interface that
wouldn't normally receive or emit traffic from its assigned address
except perhaps for network connectivity testing (e.g. traceroute) or
control link local co
John Kristoff writes:
> If the attack is an infrastructure attack, say a routing interface that
> wouldn't normally receive or emit traffic from its assigned address
> except perhaps for network connectivity testing (e.g. traceroute) or
> control link local control traffic (e.g. local SPF adjace
On Mon, 23 Mar 2015 19:00:14 -0400
Yardiel D.Fuentes wrote:
> Since there have been good feedback for this BCOP. The committee
> decided to extend the "last-call period" for another two weeks to
> give ample chance to further feedback.
>
> So, it is not late for more comments,
Hi Yardiel,
Nice
Thank you all who have contributed your feedback, comments and discussion
points towards the DDoS/DoS attack BCOP.
I have updated the current version of the BCOP with the agreed upon feedback:
http://bcop.nanog.org/index.php/BCOP_Drafts
Since there have been good feedback for this BCOP. The
Hello NANOGers,
Following up on the below effort from last year, the DDoS/DoS Attack BCOP Draft
document is ready for the last call 2-week period. After this period and unless
notable objections are raised, the current document will be ratified as such.
The current document can be found in
Thanks Roland,
Does anyone have a recommended value for tuning LPTS based on experience ?
Rgds
Peter
On Tue, Feb 7, 2012 at 7:45 AM, Dobbins, Roland wrote:
>
> On Feb 7, 2012, at 1:43 PM, Peter Ehiwe wrote:
>
> > What is the attacker spoofs the correct peering address ,
>
> In that case, work wi
On Feb 7, 2012, at 1:37 PM, Peter Ehiwe wrote:
> What is the best way to mitigate DOS attack against the bgp process of a
> router ,
iACLs and CoPP:
<https://files.me.com/roland.dobbins/prguob
---
Roland Dobbins
Hi ,
What is the best way to mitigate DOS attack against the bgp process of a
router , is LPTS on IOS-XR enough ?
Rgds
Peter
irst place. Just punt the
> packet up and move on.
>
I think Jeff's focus here is on the kinds of core and TOR switches that
are mostly used in datacenters, not so much the CPE end of the world.
>
> Still, you've sold me on part of the claim: A /64 is inherently
> vulnerable t
On Jul 17, 2011, at 1:17 PM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote:
>> Basically an ND entry would have the following states and timers:
>
> I've discussed what you have described with some colleagues in the
> past. The idea has merit and I would certainly no
find out
about the "good" ones when the response comes back.
This means you could multiply a unicast flood into a multicast flood
but you'll have to pump out several orders of magnitude more packets
than with the original problem before it causes me grief.
Still, you've sold
On Sun, Jul 17, 2011 at 3:40 PM, Owen DeLong wrote:
> Basically an ND entry would have the following states and timers:
I've discussed what you have described with some colleagues in the
past. The idea has merit and I would certainly not complain if
vendors included it (as a knob) on their boxes
On Jul 17, 2011, at 10:35 AM, Jeff Wheeler wrote:
> On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
>> My off-the-cuff naive solution to this problem would be to discard the
>> oldest incomplete solicitation to fit the new one and, upon receiving
>> an apparently unsolicited response to
On Sun, Jul 17, 2011 at 11:42 AM, William Herrin wrote:
> My off-the-cuff naive solution to this problem would be to discard the
> oldest incomplete solicitation to fit the new one and, upon receiving
> an apparently unsolicited response to a discarded solicitation,
> restart the process flagging
you're a hacker with an ability to generate arbitrary packets on a
LAN, DOSing the adjacent router by overwhelming its ARP cache is one
of the least interesting things you can do... and one of the easiest
to get busted at.
It isn't necessary (or possible) to solve every conceivable *lo
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> Interesting, thnaks. It's not the vendors I would expect, and it's
>> not based on SEND (which is not surprising at all and actually a
>> good thing).
>
> Personally I think SEND is never going to get any traction.
Last time
On Sun, 17 Jul 2011, Florian Weimer wrote:
> Interesting, thnaks. It's not the vendors I would expect, and it's not
> based on SEND (which is not surprising at all and actually a good
> thing).
Personally I think SEND is never going to get any traction.
> Is this actually secure in the sense
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> Others use tunnels, PPPoE or lots of scripting, so certainly
>> something can be done about it. To my knowledge, SAVI SEND is still
>> at a similar stage. Pointers to vendor documentation would be
>> appreciated if this is n
On Sun, 17 Jul 2011, Florian Weimer wrote:
> Others use tunnels, PPPoE or lots of scripting, so certainly something
> can be done about it. To my knowledge, SAVI SEND is still at a similar
> stage. Pointers to vendor documentation would be appreciated if this is
> not the case.
--
Mikael
* Mikael Abrahamsson:
> On Sun, 17 Jul 2011, Florian Weimer wrote:
>
>> In practice, the IPv4 vs IPv6 difference is that some vendors
>> provide DHCP snooping, private VLANs and unicast flood protection in
>> IPv4 land, which seems to provide a scalable way to build Ethernet
>> networks with addre
On Sun, 17 Jul 2011, Florian Weimer wrote:
> In practice, the IPv4 vs IPv6 difference is that some vendors provide
> DHCP snooping, private VLANs and unicast flood protection in IPv4 land,
> which seems to provide a scalable way to build Ethernet networks with
> address validation---but there i
On Jul 17, 2011, at 4:15 PM, Florian Weimer wrote:
> In practice, the IPv4 vs IPv6 difference is that some vendors provide DHCP
> snooping, private VLANs and unicast flood protection in IPv4
> land, which seems to provide a scalable way to build Ethernet networks with
> address validation---but
On Jul 15, 2011, at 10:24 AM, Jimmy Hess wrote:
> In most cases if you have a DoS attack coming from the same Layer-2 network
> that a router is attached to,
> it would mean there was already a serious security incident that occured to
> give the attacker that special point to atta
* Jared Mauch:
> Solving a local attack is something I consider different in scope
> than the current draft being discussed in 6man, v6ops, ipv6@ etc...
That's not going to happen because it's a layering violation between
the IETF and IEEE. It has not been solved during thirty years of IPv4
over
On Thu, Jul 14, 2011 at 9:47 PM, Owen DeLong wrote:
>
> Very true. This is where Mr. Wheeler's arguments depart from reality. He's
> right
> in that the problem can't be truly fixed without some very complicated code
> added
> to lots of devices, but, it can be mitigated relatively easily and m
On Thu, 14 Jul 2011 23:13:03 PDT, Owen DeLong said:
> On Jul 14, 2011, at 8:24 PM, Jimmy Hess wrote:
> > In most cases if you have a DoS attack coming from the same Layer-2
> > network that a router is attached to,
> > it would mean there was already a serious security incid
ng to keep the majority of thoughts here for layer-3
>> originated attacks, even if the target is a layer2 item.
>> - Jared
>
> In most cases if you have a DoS attack coming from the same Layer-2
> network that a router is attached to,
> it would mean there was already a ser
On 07/15/2011 12:24 AM, Jimmy Hess wrote:
> A similarly hazardous situation exists with IPv4, and it is basically
> unheard of for IPv4's Layer 2/ARP security weaknesses to be exploited
> to create a DoS condition, even though they can be (very easily),
IMO, the situation is different, in that
acks, even if the target is a layer2 item.
> - Jared
In most cases if you have a DoS attack coming from the same Layer-2
network that a router is attached to,
it would mean there was already a serious security incident that
occured to give the attacker that special point to attack from.
A
http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
Sent from my iThing
On Jul 14, 2011, at 10:57 PM, Fernando Gont wrote:
> On 07/14/2011 11:35 PM, Jared Mauch wrote:
>
>>> Well, unless there's some layer-2 anti-spoofing mitigation in
>>> place, with /64 subnets the "local attacker" ty
On 07/14/2011 11:35 PM, Jared Mauch wrote:
>> Well, unless there's some layer-2 anti-spoofing mitigation in
>> place, with /64 subnets the "local attacker" typically *will* have
>> enough addresses.
>
> Solving a local attack
Well, I was talking about not *introducing* ;-) one.
> is something
On Jul 14, 2011, at 10:06 PM, Fernando Gont wrote:
>> It should be possible to mitigate this, so long as the attack does not
>> actually
>> originate from a neighbor on the same subnet as a router IP interface on
>> an IPv6 subnet with sufficient number of IPs.
>
> Well, unless there's some
On 07/14/2011 10:24 PM, Jimmy Hess wrote:
>> In this particular case, if the implementation enforces a limit on the
>> number of entries in the "INCOMPLETE" state, then only nodes that have
>> never communicated with the outside world could be affected by this
>> attack. And if those entries that a
On Jul 14, 2011, at 6:24 PM, Jimmy Hess wrote:
> On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote:
>> On 07/11/2011 09:17 PM, Karl Auer wrote:
>> Vulnerability to this specific issues has a great deal to do with the
>> implementation. After all, whenever there's a data structure that can
> Y
On Thu, Jul 14, 2011 at 7:29 PM, Fernando Gont wrote:
> On 07/11/2011 09:17 PM, Karl Auer wrote:
> Vulnerability to this specific issues has a great deal to do with the
> implementation. After all, whenever there's a data structure that can
Yes
> In this particular case, if the implementation enf
On 07/11/2011 09:17 PM, Karl Auer wrote:
> I realise this is not "specific implementations" as you requested, but
> it seems to me that the problem is generic enough not to require that.
>
> The attack is made possible by the design of the protocol, not any
> failing of specific implementations. S
ble to obtain Neighbor Discovery service from
the last hop router as it will be already busy with sending other
solicitations. This DoS attack is different from the others in that
the attacker may be off-link. The resource being attacked in this
case is the conceptual neighbor cache,
> Null routing the source isn't going to stop
Except when doing source based blackholing, see
http://tools.ietf.org/html/draft-kumari-blackhole-urpf-02 section #4
Dave.
Hi,
Please look for proxad.fr <-- Free
Free is an ADSL provider based in France and proxad is a hosting
company (please give a look at the "dig -x" below)
dig -x 88.191.63.28
; <<>> DiG 9.5.0b2 <<>> -x 88.191.63.28
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, stat
>One of my customers, a host at 64.8.105.15, is feeling a "bonus"
>~130kpps from 88.191.63.28. I've null-routed the source, though our
>Engine2 GE cards don't seem to be doing a proper job of that,
>unfortunately. The attack is a solid 300% more pps than our aggregate
>traffic levels.
Null routi
Mikael Abrahamsson wrote:
Do you really call this "little if any information publically visible"?
Nope, I was wrong about that. My search-fu on RIPE isn't up to snuff,
apparently; hence the request for assistance.
pt
Hello,
On Wed, 26 Nov 2008 05:37:59 -0500
Pete Templin <[EMAIL PROTECTED]> wrote:
> One of my customers, a host at 64.8.105.15, is feeling a "bonus"
> ~130kpps from 88.191.63.28. I've null-routed the source, though our
> Engine2 GE cards don't seem to be doing a proper job of that,
> unfortun
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pete Templin wrote:
> One of my customers, a host at 64.8.105.15, is feeling a "bonus"
> ~130kpps from 88.191.63.28. I've null-routed the source, though our
> Engine2 GE cards don't seem to be doing a proper job of that,
> unfortunately. The attack
On Wed, 26 Nov 2008, Pete Templin wrote:
It's coming in via 6461, but they don't appear to have any ability to
backtrack it. Their only offer is to blackhole the destination until
the attack subsides. BGP tells me the source is in AS 12322, a RIPE AS
that has little if any information public
One of my customers, a host at 64.8.105.15, is feeling a "bonus"
~130kpps from 88.191.63.28. I've null-routed the source, though our
Engine2 GE cards don't seem to be doing a proper job of that,
unfortunately. The attack is a solid 300% more pps than our aggregate
traffic levels.
It's comin
54 matches
Mail list logo
