Re: Optimal IPv6 router

[Daniel Roesen]

On Sun, Feb 05, 2012 at 09:07:57PM -0500, valdis.kletni...@vt.edu wrote:
> OK, I'll bite.  What would qualify as a "native IPv6" router?

Perhaps those which were designed with IPv4+IPv6 in mind from day 1,
both in hardware and software - like Juniper/JUNOS. In contrast to other
the gear where IPv6 was always an aftermath, which shows in both
hardware (limits of performance, functionality and scaling) as well as
software (every feature gets implemented twice, even if the feature
itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
on XR]).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

Re: UDP port 80 DDoS attack

[Jeff Wheeler]

On Sun, Feb 5, 2012 at 10:08 PM, Steve Bertrand
 wrote:
> This is so very easily automated. Even if you don't actually want to trigger
> the routes automatically, finding the sources you want to blackhole is as

What transit providers are doing flow-spec, or otherwise, to allow
their downstreams to block malicious traffic by SOURCE address?

-- 
Jeff S Wheeler 
Sr Network Operator  /  Innovative Network Concepts

Re: Hijacked Network Ranges

[Michael Hallgren]

Le dimanche 05 février 2012 à 22:41 -0800, goe...@anime.net a écrit :
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.

... but at times, they prevent loss of... ...

mh

> 
> -Dan
> 

Re: Hijacked Network Ranges

[Christopher Morrow]

On Mon, Feb 6, 2012 at 1:35 AM, Mark Tinka  wrote:
> On Monday, February 06, 2012 01:14:20 PM Christopher Morrow

> We manually check the RIR WHOIS database. I'm sure some

do you have customers with 10k long prefix lists? it gets hard when
the lists get long, or the data is for downstream folks of your
customer. Good that someone's checking though, I'd love to see this
part automated.

>> resource certification would at least get us to the point
>> where checking the data in the IRR is 'easy', it's not
>> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
>> and it's not going to get people to update their IRR
>> objects (add AND DELETE!!!)
>
> I support RPKI, but also realize that operator support will
> take a very long time for various reasons, e.g., education,
> delayed software upgrades, persistence with older methods,
> fear of centralization, e.t.c.
>
> In such a case, operators will need to support "Invalid" and
> "NotFound" states of origin information for a long time. As

RPKI doesn't necessarily mean that the router knows anything about
certificates in the short-term. I think there's a time when 'the
resource certification system' (which is really, today, the rpki)
holds cert/roa data that you could use to filter what the IRR tells
you for a customer. You could even do this in any automated manner!

> adoption and deployment increases, operators can begin
> dropping "Invalid" results, "NotFound" results, or both. Or
> even mark them down with poor LOCAL_PREF values so as not to
> use those routes for forwarding unless it is really
> necessary.

The time between the previous and next paragraphs though is when all
isp's will need to beat the drums with their customers saying: "Hey,
you REALLY need to get that shit into the 'resource certification
system' (rpki), NOW." (because shortly we'll stop accepting your
"invalid" routes... and then the interwebs won't be able to find you,
and we'll all be sad.)

> At some point, when diffusion of RPKI is sufficiently
> prolific, anything that does not return a "Valid" result
> will be dropped. This should force every operator around the
> world to support it, much like the large carriers forced us
> all to use IRR's just so they won't ignore our routes,
> wherever we are in the world.
>
> But before all this happens, we have to prevent more
> hijacks. And we have to use the tools we have today.

sure... it's not working so well though :(

Re: Hijacked Network Ranges

[Mark Tinka]

On Monday, February 06, 2012 02:41:53 PM goe...@anime.net 
wrote:

> filters don't generate revenue.

Neither does traffic - that does generate revenue - not 
reaching your customer.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Verisign deep-hacked. For months.

[steve pirk [egrep]]

On Thu, Feb 2, 2012 at 16:42, Zaid Ali  wrote:

> That part is ambiguous at the moment since Verisign has not released
> details. Symantec has bought the SSL part of the business and claim that
> the SSL acquired network is not compromised. Sounds like lots of
> assumptions being drawn.
>
> Zaid
>
>
I am thinking it is related to the Chinese hacking of Gmail accounts in the
fall of 2010. Symantic acquired the SSL business in August 2010. The
hacking could have been in the spring for all we know. Google uses Thwate
as it's CA, but Thwate has "Builtin Object Token: Verisign Class 3 Public
Primary Certificate Authority" as it's root.

Seems to me part of the problem was traced back to browsers not checking
revoked certs via the browser CRLs. Didn't some in the chain have revoked
certs still installed?

-- 
steve pirk
yensid
"father... the sleeper has awakened..." paul atreides - dune
Google+ pirk.com

RE: Hijacked Network Ranges

[George Bonser]

> To: Christopher Morrow
> Cc: nanog@nanog.org
> Subject: Re: Hijacked Network Ranges
> 
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.
> 
> -Dan

Don't agree with the implied notion that a commercial network provider won't do 
anything that doesn't produce revenue.  They do all sorts of things that don't 
produce revenue, like purchase door locks and security cameras.  This is along 
the same avenue only for their networking which is their core competency.

Re: Hijacked Network Ranges

[goemon]

On Mon, 6 Feb 2012, Christopher Morrow wrote:

why aren't filters applied at all?


filters don't generate revenue.

-Dan

Re: Hijacked Network Ranges

[Mark Tinka]

On Monday, February 06, 2012 01:14:20 PM Christopher Morrow 
wrote:

>   o not having filters at all (pccw/pktel)

Well, we know what this leads to (part of the reasons you 
find some eBGP sessions carrying /25's or longer + RFC 1918 
space is because of this).

>   o filtering using old/stale data (ntt/l3)

Well, we think that this problem resolves itself rather 
well:

o If a customer is not getting traffic hitting a
  prefix, they'll check with their upstream on if
  their prefix is being received and propagated.

o If a customer is not seeing their prefix on the
  Internet, they'll check with their upstream on if
  their prefix is being received and propagated.

o If a customer starts announcing a new prefix
  without updating their upstream, one e-mail or
  phone call to the upstream will get this fixed.


In all cases above, it's better not to have an unauthorized 
prefix in the yonder than have open filters, because one is 
more likely to quickly get resolved without any colleteral 
than the other.

> why aren't filters applied at all? ("its hard, people
> keep asking me to update them, bah! work!")

Well, so was running the Internet without BGP communities or 
prefix lists or AS_PATH filters, until they appeared. And 
while some folk still use so-called "distribute lists" 
today, it's fine with me as long as they maintain secure 
operations with whatever solution they choose, hard or easy.

Some ISP's have automated this process either by using 
internal IRR software, or scripting web GUI's that their NOC 
can use to simply stick in the prefix, select which router 
to update, and bam!

Compared to the alternative, this is a small price to pay.

> why aren't filter data bases kept up to date? ("its hard,
> i have to email something to radb/altdb/etc... bah,
> work!")...

That's why we use the RIPE RR. They have a cool web GUI that 
you can use to edit on object, including IRR data (and 
they're respected by all other major RR's and operators):

https://apps.db.ripe.net/webupdates/


It certainly beats the old "MAIL FROM" system, although I 
believe that is still operational.

> why aren't checks of the filter data simple and
> mechanical? (and accurate?) ("Bah! work! plus, have you
> looked at the ouptput? bah! work!")

See above.

We manually check the RIR WHOIS database. I'm sure some 
networks might automate this with an internal system that 
checks the RIR WHOIS database, and probably integrates with 
their provisioning system that can automatically create and 
update filters on routers. I don't know...

But it's certainly better than the alternative.

> resource certification would at least get us to the point
> where checking the data in the IRR is 'easy', it's not
> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
> and it's not going to get people to update their IRR
> objects (add AND DELETE!!!)

I support RPKI, but also realize that operator support will 
take a very long time for various reasons, e.g., education, 
delayed software upgrades, persistence with older methods, 
fear of centralization, e.t.c.

In such a case, operators will need to support "Invalid" and 
"NotFound" states of origin information for a long time. As 
adoption and deployment increases, operators can begin 
dropping "Invalid" results, "NotFound" results, or both. Or 
even mark them down with poor LOCAL_PREF values so as not to 
use those routes for forwarding unless it is really 
necessary.

At some point, when diffusion of RPKI is sufficiently 
prolific, anything that does not return a "Valid" result 
will be dropped. This should force every operator around the 
world to support it, much like the large carriers forced us 
all to use IRR's just so they won't ignore our routes, 
wherever we are in the world.

But before all this happens, we have to prevent more 
hijacks. And we have to use the tools we have today.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Hijacked Network Ranges

[Christopher Morrow]

On Mon, Feb 6, 2012 at 12:07 AM, Mark Tinka  wrote:

> It's 2012, we really shouldn't be seeing this type of thing
> anymore, particularly after what happened in Pakistan.

s/pakistan/pakistan,nyc(ntt),minneapolis(ntt),level3's incidents, .../

there's lots of people that have fallen victim of:
  o not having filters at all (pccw/pktel)
  o filtering using old/stale data (ntt/l3)

why aren't filters applied at all? ("its hard, people keep asking me
to update them, bah! work!")
why aren't filter data bases kept up to date? ("its hard, i have to
email something to radb/altdb/etc... bah, work!")
why aren't checks of the filter data simple and mechanical? (and
accurate?) ("Bah! work! plus, have you looked at the ouptput? bah!
work!")

resource certification would at least get us to the point where
checking the data in the IRR is 'easy', it's not going to get people
to PUT FILTERS ON CUSTOMER SESSIONS, and it's not going to get people
to update their IRR objects (add AND DELETE!!!)

-chris

Re: Hijacked Network Ranges

[Mark Tinka]

On Monday, February 06, 2012 12:26:51 PM Suresh 
Ramasubramanian wrote:

> I had this happen to me in 2008 -
> http://www.gossamer-threads.com/lists/nanog/users/110097
> Total pain in the ass when it does happen.  Funnily
> enough in that case it was another downstream of the
> same ISP who was pulling this stunt ..

Clearly the joy of running a clean network is not shared by 
all :-).

Yes, it is a little bit of extra hassle having to update 
filters when your downstreams make change requests 
(including verification, e.t.c.). But when some of our 
upstreams make us go through this, I'm much happier they do 
than they if they didn't. Some are even asking us to "fax" 
documents of such requests; a little extreme, but okay, I'll 
bite :-).

We do have some upstreams who are pretty lax about this. But 
we certainly are not, and as a result, are yet to put one of 
our customers or the Internet in jeopardy because we let one 
through the cracks.

It's 2012, we really shouldn't be seeing this type of thing 
anymore, particularly after what happened in Pakistan.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Thanks & Let's Prevent this in the Future.

[Mark Tinka]

On Thursday, February 02, 2012 01:00:43 AM George Bonser 
wrote:

> One problem is the number of routing registries and the
> requirements differ for them.  The nefarious operator
> can enter routes in an IRR just as easily as a
> legitimate operator.  There was a time when some
> significant networks used the IRRs for their filtration
> policy.  I'm not sure how many still do.

I've dealt with AfriNIC and APNIC WHOIS databases, and they 
normally control the 'inetnum' and inet6num' entries that go 
into the WHOIS databases. So there is some degree of 
certainty that what is in there is generally true.

You're right, anyone can create an IRR record, and it's 
quite terrible how easy it is to create false information 
that could break another person's network. This is why we 
don't generally trust IRR or PeeringDB data when verifying 
downstream prefixes which we should permit through our 
filters. We rely on the RIR 'inetnum' and 'inet6num' records 
for that.

My memory fails me on what ARIN do, but before AfriNIC was 
established and the majority of Africa's prefixes were 
allocated by RIPE and ARIN, I recall the ARIN policy (SWIP 
templates, et al) being a hassle-rich experience that 
anything else is long forgotten :-).

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Hijacked Network Ranges

[Mark Tinka]

On Wednesday, February 01, 2012 12:10:32 PM George Bonser 
wrote:

> Customer relationship with Kelvin's firm terminated and
> they contracted for service elsewhere but are apparently
> attempting to maintain the use of the address
> allocation(s) they received from Kelvin's firm.  They
> apparently did this by misrepresenting the fact that
> they were entitled to use that address space.

We've been in such situations without customers requesting 
us either to:

a) Block certain addresses across their transit
   links in order to mitigate DoS attacks.

b) Announce address space which does not necessarily
   belong to them, even though they aren't being
   nefarious.


In either case, a quick check of the RIR WHOIS database to 
qualify consistency in information does not hurt. Yes, WHOIS 
records aren't always the most up-to-date, but it's a fairly 
good representation of the truth most of the time, 
especially since 'inetnum' objects tend to be managed by the 
RIR's themselves, last time I checked.

This is quickly making the case for RPKI.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Hijacked Network Ranges

[Suresh Ramasubramanian]

I had this happen to me in 2008 -
http://www.gossamer-threads.com/lists/nanog/users/110097
Total pain in the ass when it does happen.  Funnily enough in that
case it was another downstream of the same ISP who was pulling this
stunt ..

--srs

On Mon, Feb 6, 2012 at 9:49 AM, Mark Tinka  wrote:
>
>
> The fact that the hijacking ISP's upstreams accepted routes
> through their network that didn't belong to that ISP is bad
> enough.
>
> That we should still be able to advertise anything without
> an appropriate filter being in place and expecting it to
> work (even if it's with good intention, as in this case) is
> equally as bad.



-- 
Suresh Ramasubramanian (ops.li...@gmail.com)

Re: Hijacked Network Ranges

[Mark Tinka]

On Wednesday, February 01, 2012 02:57:46 AM Tony McCrory 
wrote:

> Surely something is better than nothing.  Advertise the
> /24's and the /25's, see what happens.

The fact that the hijacking ISP's upstreams accepted routes 
through their network that didn't belong to that ISP is bad 
enough.

That we should still be able to advertise anything without 
an appropriate filter being in place and expecting it to 
work (even if it's with good intention, as in this case) is 
equally as bad.

A big fail to our community, for up to this day, not 
implementing basic routing and forwarding filters that would 
do away with all this cruft in the first place.

Clearly the Youtube/Pakistan/PCCW incident has long been 
forgotten.

But that's life, I guess...

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: UDP port 80 DDoS attack

[Steve Bertrand]

On 2012.02.05 22:30, Keegan Holley wrote:
 > 2012/2/5 Steve Bertrand 
On 2012.02.05 20 :37, Keegan Holley wrote:
Source RTBH often falls victim to rapidly changing or spoofed
source IP"s.
It also isn't as widely supported as it should be. I never said
DDOS was
hopeless, there just aren't a wealth of defenses against it.


This is so very easily automated. Even if you don't actually want to
trigger the routes automatically, finding the sources you want to
blackhole is as simple as a monitor port, tcpdump and some basic Perl.


This is still vulnerable to spoofing which could cause you to filter
legitimate traffic and make the problem worse.  Not saying that S/RTBH
is a bad idea.  RTBH is effective and a great idea just not very elegant.


Agreed. Diligence does play a role. However, the times I have 
implemented and used (s/)RTBH, I thought it was most elegant. I love its 
simplicity and effectiveness.



...and as far as this not having been deployed in many ISPs (per
your next message)... their mitigation strategies should be asked up
front, and if they don't have any (or don't know what you speak of),
find a new ISP.


You sometimes have to weigh the pro's and cons.  You can't always pick
the guys with the coolest knobs.


Agreed. But to me, DDOS mitigation is not just a cool knob. If my ISP 
can help mitigate a 1Gb onslaught so my 100Mb pipe isn't overwhelmed, 
that's more functional than cool. Ranks right up there with IPv6 ;)


Steve

Re: UDP port 80 DDoS attack

[Keegan Holley]

2012/2/5 Steve Bertrand 

> On 2012.02.05 20:37, Keegan Holley wrote:
>
>> 2012/2/5 Dobbins, Roland
>>
>
>  S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>>> you read the preso.
>>>
>>>
>> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.
>>
>
> This is so very easily automated. Even if you don't actually want to
> trigger the routes automatically, finding the sources you want to blackhole
> is as simple as a monitor port, tcpdump and some basic Perl.
>

This is still vulnerable to spoofing which could cause you to filter
legitimate traffic and make the problem worse.  Not saying that S/RTBH is a
bad idea.  RTBH is effective and a great idea just not very elegant.


>
> ...and as far as this not having been deployed in many ISPs (per your next
> message)... their mitigation strategies should be asked up front, and if
> they don't have any (or don't know what you speak of), find a new ISP.
>

You sometimes have to weigh the pro's and cons.  You can't always pick the
guys with the coolest knobs.

Re: Super Sunday

[Michael Painter]

Mike Lyon wrote:

When i did a sports bar of about 24 HD TVs, i used gear from here:

http://www.neoprointegrator.com/products.php

Good product, good support.

-mike



Looks like a well designed product...Thanks!

Any idea of what the 'Tahoe' costs (we have 16 sources)? 


--Michael

Re: UDP port 80 DDoS attack

[Steve Bertrand]

On 2012.02.05 20:37, Keegan Holley wrote:

2012/2/5 Dobbins, Roland



S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
you read the preso.



Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
It also isn't as widely supported as it should be. I never said DDOS was
hopeless, there just aren't a wealth of defenses against it.


This is so very easily automated. Even if you don't actually want to 
trigger the routes automatically, finding the sources you want to 
blackhole is as simple as a monitor port, tcpdump and some basic Perl.


...and as far as this not having been deployed in many ISPs (per your 
next message)... their mitigation strategies should be asked up front, 
and if they don't have any (or don't know what you speak of), find a new 
ISP.


Steve

Re: Optimal IPv6 router

[Masataka Ohta]

Glen Kent wrote:

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

It depends on what you want routers to do.

As I am working on Tbps photonic routers with fiber delay lines,
the bottleneck is at constant time (nano seconds order) electric
route look up.

There, several simple 4M*16bit SRAMs is fine for IPv4 with mostly
/24 routing table entries.

IPv6 was better because TLA had was merely 13bit long with only
8192 entries.

However, as the idea of TLA was abandoned long before and a lot
more than /24 is, seemingly, necessary for route look up of IPv6
backbone, I'm afraid IPv6 needs large amount of power consuming
content addressable memories.

Without any (defacto) standard prefix length at the IPv6 backbone,
it is simply impossible to say "optimal".

Masataka Ohta

Re: Super Sunday

[Mike Lyon]

When i did a sports bar of about 24 HD TVs, i used gear from here:

http://www.neoprointegrator.com/products.php

Good product, good support.

-mike

Sent from my iPhone

On Feb 5, 2012, at 17:47, Michael Painter  wrote:

> Mike Lyon wrote:
>> Sent from my iPhone
>>
>> On Feb 5, 2012, at 17:24, Michael Painter  wrote:
>>
>>> Jay Ashworth wrote:
 - Original Message -
> From: "Michael Painter" 

> On Vizio 37" 1080p display:
> Local NBC affiliate via off-air antenna= flawless 720p picture.
> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
> picture.
> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
> picture.

 I don't suppose you have the MPEG bitrates on those... :-)

 Cheers,
 -- jra
>>>
>>> No, but that's my next project.  I just received the ATSC dongle from 
>>> AVerMedia.
>>>
>>> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 
>>> displays at the sportsbar has been a challenge, but we made
>>> it with 2 hours to spare.
>>>
>>> Best,
>>>
>>> --Michael
>>>
>>
>> What gear were you using for the sports bar?
>>
>> -mike
>
> I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog 
> system.  Works great.
> http://www.zeevee.com/hdbridge
>

Re: Optimal IPv6 router

[Valdis . Kletnieks]

On Mon, 06 Feb 2012 06:50:54 +0530, Glen Kent said:

> Most routers today are basically IPv4 routers, with IPv6 thrown in.
Not sure if this statement is troll bait or flame bate. Probably both. ;)

I see Joel has already confirmed my memory that vendors had ASICs
doing IPv6 forwarding last century.

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

OK, I'll bite.  What would qualify as a "native IPv6" router?  Is this
another concept as silly as "hardware vs software based" routers?

And whaqt would be the definition of "more optimal"?  Just fixing
the current feature parity mismatch with the IPv4 side, or you got
some new routing paradigm in mind or something?


pgpKuDsXry3wG.pgp
Description: PGP signature

Re: Optimal IPv6 router

[Joel jaeggli]

On 2/5/12 17:20 , Glen Kent wrote:
> Hi,
> 
> Most routers today are basically IPv4 routers, with IPv6 thrown in.
> They are however designed keeping IPv4 in mind.
> 
> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

Asic based forwarding engines with ipv6 support are more than a decade
old at this point.

If one looks at an asr9000 or an MX or T that looks like an ipv6 router
to me.

> Glen
> 

Re: UDP port 80 DDoS attack

[Dobbins, Roland]

On Feb 6, 2012, at 8:50 AM, Keegan Holley wrote:

> Yes but assuming everything discussed at a conference is instantly adopted by 
> the entire industry gives one false hope no?

I'm certainly not making that assumption - hence the presos.

;>

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: UDP port 80 DDoS attack

[Keegan Holley]

2012/2/5 Dobbins, Roland 

>
> On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:
>
> > Source RTBH often falls victim to rapidly changing or spoofed source
> IP"s.
>
> S/RTBH can be rapidly shifted in order to deal with changing purported
> source IPs, and it isn't limited to /32s.  It's widely supported on Cisco
> and Juniper gear (flowspec is a better choice on Juniper gear).
>
> I was referring to support from ISP's not from hardware vendors.

If folks don't want to read the presos or search through the archives,
> that's fine, of course.  The fact is that there are quite a few things that
> operators can and should do in order to mitigate DDoS attacks; and making
> the perfect the enemy of the merely good only helps the attackers, doesn't
> it?
>
> Yes but assuming everything discussed at a conference is instantly adopted
by the entire industry gives one false hope no?

Re: Super Sunday

[Michael Painter]

Mike Lyon wrote:

Sent from my iPhone

On Feb 5, 2012, at 17:24, Michael Painter  wrote:


Jay Ashworth wrote:

- Original Message -

From: "Michael Painter" 



On Vizio 37" 1080p display:
Local NBC affiliate via off-air antenna= flawless 720p picture.
Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
picture.
Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
picture.


I don't suppose you have the MPEG bitrates on those... :-)

Cheers,
-- jra


No, but that's my next project.  I just received the ATSC dongle from AVerMedia.

Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but 
we made

it with 2 hours to spare.

Best,

--Michael



What gear were you using for the sports bar?

-mike


I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog system.  
Works great.
http://www.zeevee.com/hdbridge

Re: UDP port 80 DDoS attack

[Dobbins, Roland]

On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:

> Source RTBH often falls victim to rapidly changing or spoofed source IP"s. 

S/RTBH can be rapidly shifted in order to deal with changing purported source 
IPs, and it isn't limited to /32s.  It's widely supported on Cisco and Juniper 
gear (flowspec is a better choice on Juniper gear).

If folks don't want to read the presos or search through the archives, that's 
fine, of course.  The fact is that there are quite a few things that operators 
can and should do in order to mitigate DDoS attacks; and making the perfect the 
enemy of the merely good only helps the attackers, doesn't it?

;>

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: UDP port 80 DDoS attack

[Keegan Holley]

2012/2/5 Dobbins, Roland 

>
> On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
>
> > An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
> and RTBH?
>
> Actually, no, that isn't the focus of the preso.
>
> > The first four will not work against a DDOS attack
>
> This is incorrect - suggest you read the preso.
>

The ACL's are configured on the routers belonging to the victim AS which
will not save their access pipe if it's overrun unless I'm missing
something.  uRPF may help with spoofed traffic, but sometimes causes
problems with multi-homing and is often more harmful than helpful depending
on the network design.

>
> > and the last one just kills the patient so he does not infect other
> patients.
>
> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
> you read the preso.
>

Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
It also isn't as widely supported as it should be. I never said DDOS was
hopeless, there just aren't a wealth of defenses against it.

Re: Super Sunday

[Mike Lyon]

Sent from my iPhone

On Feb 5, 2012, at 17:24, Michael Painter  wrote:

> Jay Ashworth wrote:
>> - Original Message -
>>> From: "Michael Painter" 
>>
>>> On Vizio 37" 1080p display:
>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>> picture.
>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>> picture.
>>
>> I don't suppose you have the MPEG bitrates on those... :-)
>>
>> Cheers,
>> -- jra
>
> No, but that's my next project.  I just received the ATSC dongle from 
> AVerMedia.
>
> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays 
> at the sportsbar has been a challenge, but we made it with 2 hours to 
> spare.
>
> Best,
>
> --Michael
>

What gear were you using for the sports bar?

-mike

Re: Super Sunday

[Michael Painter]

Jay Ashworth wrote:

- Original Message -

From: "Michael Painter" 



On Vizio 37" 1080p display:
Local NBC affiliate via off-air antenna= flawless 720p picture.
Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
picture.
Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
picture.


I don't suppose you have the MPEG bitrates on those... :-)

Cheers,
-- jra


No, but that's my next project.  I just received the ATSC dongle from AVerMedia.

Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we 
made it with 2 hours to spare.


Best,

--Michael 

Re: UDP port 80 DDoS attack

[Dobbins, Roland]

On Feb 6, 2012, at 8:20 AM, Dobbins, Roland wrote:

> Actually, no, that isn't the focus of the preso.

More info here:



---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Optimal IPv6 router

[Glen Kent]

Hi,

Most routers today are basically IPv4 routers, with IPv6 thrown in.
They are however designed keeping IPv4 in mind.

With IPv6 growing, if we were to design a native IPv6 router, with
IPv4 functionality thrown in, then is it possible to design a more
optimal IPv6 router, than what exists today?

Glen

Re: UDP port 80 DDoS attack

[Dobbins, Roland]

On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:

> An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping, and 
> RTBH?

Actually, no, that isn't the focus of the preso.

> The first four will not work against a DDOS attack

This is incorrect - suggest you read the preso.

> and the last one just kills the patient so he does not infect other patients. 

S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest you 
read the preso.

There's been a lot of discussion on this topic on NANOG, suggest you take a 
look through the archives.

---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: UDP port 80 DDoS attack

[Keegan Holley]

An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
and RTBH?  The first four will not work against a DDOS attack and the last
one just kills the patient so he does not infect other patients.  As I said
earlier beyond traffic scrubbing offsite there isn't much defense against
DDOS.

2012/2/5 Dobbins, Roland 

>
> On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:
>
> > There aren't very many ways to combat DDOS.
>
> Start with the various infrastructure/host/service BCPs, and S/RTBH, as
> outlined in this preso:
>
> 
>
> ---
> Roland Dobbins  // 
>
>The basis of optimism is sheer terror.
>
>  -- Oscar Wilde
>
>
>
>

Re: Super Sunday

[Jay Ashworth]

- Original Message -
> From: "Michael Painter" 

> On Vizio 37" 1080p display:
> Local NBC affiliate via off-air antenna= flawless 720p picture.
> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
> picture.
> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
> picture.

I don't suppose you have the MPEG bitrates on those... :-)

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

Re: Super Sunday

[Michael Painter]

Jay Ashworth wrote:

What, no whacky weekend thread?

NBC and the NFL are, for the first time, televising the Super Bowl and its
preshow on the Internet... using a Silverlight app (so I hope you Linux people
don't enjoy football).

It's supposed to be available to tablets too, as a second-screen cast with
selectable angles and such, but Verizontal has an exclusive on mobile, so the
target page should bounce cellphones, unless a) they lie or b) they weren't
smart enough to IP block the carrier ranges.

 http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/

It will be interesting to see how this works out.

Enjoy the game.  Especially if you have a Big Wall to watch it on.

Cheers,
-- jr 'we want pictures' a



Halftime observations from 72.253.0.0/16:

On Vizio 37" 1080p display:
Local NBC affiliate via off-air antenna= flawless 720p picture.
Local NBC affiliate re-broadcast via Dish Network=flawless 1080i picture.
Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i picture.

On Samsung 23" 1080p monitor via Dell 2.8GHz GX270 with 7Mbps down:
Low resolution (appears to be less than VHS), sometimes jerky, picture.

Re: UDP port 80 DDoS attack

[Dobbins, Roland]

On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:

> There aren't very many ways to combat DDOS. 

Start with the various infrastructure/host/service BCPs, and S/RTBH, as 
outlined in this preso:



---
Roland Dobbins  // 

The basis of optimism is sheer terror.

  -- Oscar Wilde

Re: UDP port 80 DDoS attack

[Matthew Palmer]

On Sun, Feb 05, 2012 at 06:36:13PM -0500, Ray Gasnick III wrote:
> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.

Yep, we've got a customer who's been hit with it a couple of times (5Gbps
the first time, 3Gbps the second).  For hysterical raisins, we don't
actually control the network for this particular customer, but the network
provider did pretty much what you did -- blackholed the victim IP.  We've
mitigated the problem by using a full-time traffic-scrubbing service -- the
hope is that the scrubbing service will pay for all the traffic and only the
good stuff will get through.  Only time will tell if it works.  We also had
to renumber the customer, as the attacks were obviously remembering the old
IP and still knocking it off the network even after the DNS was repointed at
the scrubbing service.

- Matt

-- 
"I'm tempted to try Gentoo, but then I learned that its installer is in
Python, and, well, a base Python install on my system is something like
fifty megabytes (for what?  oh, right, we NEED four XML libraries, I
forgot)."  -- Dave Brown, ASR

Re: UDP port 80 DDoS attack

[Keegan Holley]

There aren't very many ways to combat DDOS.  That's why it's so popular.
Some ISP's partner with a company that offers a tunnel based scrubbing
service where they DPI all your traffic before they send it to you.  If you
only have a few upstreams it may be helpful to you.  I spoke to them last
year but we have too many links and too many blocks to use it.  I think the
name of the company was prolexic.  They're also a L3 VAR if you have L3
links.  There isn't alot of BGP (AFAIK) magic that doesn't involve cutting
someone off to save the rest of your customers.

2012/2/5 Ray Gasnick III 

> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.
>
>
>
> Wireshark shows this appears to be from a compromised game server (call of
> duty) with source IPs in a variety of different prefixes.
>
>
>
> Only solution thus far was to dump the victim IP address in our block into
> the BGP Black hole community with one of our 2 providers and completely
> stop advertising to the other.
>
>
>
> Anybody see this recently and have any tips on mitigation,  reply on or
> off list.
>
>
>
> Thank You,
>
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com
>
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at itmana...@milestechnologies.com
> 
>
> Computer Networking – IT Support – Business Software – Website Design –
> Online Marketing & PR
>
>
>

Re: UDP port 80 DDoS attack

[Fredrik Holmqvist / I2B]

Hi.

We had a customer that was attacked by the same "game server feature".
We received aprox 10 Gbit of traffic against the customer.

The attacker sends spoofed packets to the game server with the target
IP as "source", the gameserver sends replies back via UDP to the target
host. The attacker sends a couple of hundred packets per second and thus
generating a 10 Mbit UDP flood.

There is fixes/workarounds for the game servers, just a matter of the
admin taking care of it.
See: http://rankgamehosting.ru/index.php?showtopic=1320

The "attacking" IPs aren't spoofed, so just compile a list and send
e-mails to each provider.

We had 1000+ IPs gathered and sent 100+ abuse e-mails, only received
reply from less than 20%.
Sad that people care so little about mitigating DDoS/UDP/ICMP floods.


On Sun, 5 Feb 2012 18:36:13 -0500, Ray Gasnick III
 wrote:
> We just saw a huge flux of traffic occur this morning that spiked one
> of our upstream ISPs gear and killed the layer 2 link on another
> becuase of a DDoS attack on UDP port 80.
> 
> 
> 
> Wireshark shows this appears to be from a compromised game server
> (call of duty) with source IPs in a variety of different prefixes.
> 
> 
> 
> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.
> 
> 
> 
> Anybody see this recently and have any tips on mitigation,  reply on
> or off list.
> 
> 
> 
> Thank You,
> 
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com
> 
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at
> itmana...@milestechnologies.com
> 
> Computer Networking – IT Support – Business Software – Website Design
> – Online Marketing & PR

-- 
Fredrik Holmqvist
I2B (Internet 2 Business)
070-740 5033

Superbowl traffic.

[jamie rishaw]

(yeah, i used a (C) term , so sue me)

akam reporting ~17M hits/sec..
anyone seeing clearly identifiable traffic spikes (presumably due to sb)?

reply offlist if you want to submit data but don't want to be outed as
divulging corp info, but graphs and/or raw datars would be awesome
sauce. data will be aggregated/anonymized unless requested otherwise.

               ^^ yes, you can configure your router for awesomesauce.
 so HDICMRFT flak will be nulled.  :-p

-j
-- 
"sharp, dry wit; brash in his dealings" - Forbes

X-Ob-Zing: "it's very hard not to be condescending when you're
explaining..to an idiot." -BMaher
/* - teh jamie. ; uri -> http://about.me/jgr */

UDP port 80 DDoS attack

[Ray Gasnick III]

We just saw a huge flux of traffic occur this morning that spiked one of our 
upstream ISPs gear and killed the layer 2 link on another becuase of a DDoS 
attack on UDP port 80.



Wireshark shows this appears to be from a compromised game server (call of 
duty) with source IPs in a variety of different prefixes.



Only solution thus far was to dump the victim IP address in our block into the 
BGP Black hole community with one of our 2 providers and completely stop 
advertising to the other.



Anybody see this recently and have any tips on mitigation,  reply on or off 
list.



Thank You,

Ray Gasnick III
CISSP, Technology Specialist: Network Security & Infrastructure
Miles Technologies
www.milestechnologies.com

Phone: (856) 439-0999 x127
Direct: (856) 793-3821
How am I doing?  Email my manager at 
itmana...@milestechnologies.com

Computer Networking – IT Support – Business Software – Website Design – Online 
Marketing & PR

[NANOG-announce] Tutorials starting today, some available via webcast!

[Dave Temkin]

For the first time, NANOG will be webcasting (and archiving) some of our 
tutorials.

Beginning at 2PM PT, you can see John Kristoff give an Introduction to Shell and Perl Scripting for Network 
Operators, with a break from 3:30-4 and then starting back at 4PM PT with Intermediate Perl Scripting for 
Network Operators.  Both tutorials will be available later for review.


You may see all streaming options at http://www.nanog.org/streaming.php

-Dave Temkin
For the NANOG Program Committee

___
NANOG-announce mailing list
nanog-annou...@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

Super Sunday

[Jay Ashworth]

What, no whacky weekend thread?

NBC and the NFL are, for the first time, televising the Super Bowl and its
preshow on the Internet... using a Silverlight app (so I hope you Linux people
don't enjoy football).

It's supposed to be available to tablets too, as a second-screen cast with 
selectable angles and such, but Verizontal has an exclusive on mobile, so the
target page should bounce cellphones, unless a) they lie or b) they weren't 
smart enough to IP block the carrier ranges.

  http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/

It will be interesting to see how this works out.  

Enjoy the game.  Especially if you have a Big Wall to watch it on.

Cheers,
-- jr 'we want pictures' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA  http://photo.imageinc.us +1 727 647 1274

ISP access in Hebron, KY

[Eric Gauthier]

Hello,

We're looking for DIA in the 20 - 50mbps range for a
warehouse we have in Hebron, KY.  CinBell has been a
bit "slow" to respond to our DS3 requets, so I'm 
wondering who else in town has their own facilities
(also wondering who might be a good for a backup 
circuit)?

Thanks!

Eric :)