Re: AS47860 - 93.175.240.0/20 - Wiskey Tango Foxtrot

[Christopher Morrow]

On Wed, Oct 5, 2016 at 7:55 PM, Ronald F. Guilmette 
wrote:

>
>
>
> P.S.  This crap appears to be be brought to us courtesy of AS29632,
> NetAssist, LLC:
>
> http://new.netassist.ua/
>
> So anyway, where are the grownups?
>

clearly whomever provides transit to 29632... probably worth hunting them
all down and asking questions.

AS47860 - 93.175.240.0/20 - Wiskey Tango Foxtrot

[Ronald F. Guilmette]

My analysis: Serious and apparently long-lived bogosity, with a clear
history of substantial spamming aactivity.

But you be the judge.

Looks to me like an unregistered RIPE AS announcing a route to a /20
worth of unregistered RIPE IPv4 space.

And this didn't exactly crop up just yesterday.  Looks like this has
been ongoing for one hell of a long time:

https://stat.ripe.net/widget/routing-history#w.resource=AS47860

Of course, it's not even nearly as much of an issue -now- as it was,
say, about 1 year ago, in October of 2015, when the /20 was apparently
populated by a huge boat load of snowshoe spammer domains.  Sadly,
Spamhaus has a bad habit of consistantly failing to ever put any
helpful date information on any of its listings, otherwise I'd be
able to see when -they- first noticed this absurd mess.

https://www.spamhaus.org/pbl/query/PBL1626432

Anyway, it's rather annoying to me personally... and I hope I'm not the
only one who feels that way... to know that this has gone mostly unnoticed
for so long, that nobody within the RIPE region has ever bothered to -do-
anything about it, and that the AS and the bogus route are still being
announced, even as we speak.

Assuming the thing remains in play, how long will be be before the spammers
return to use and abuse it yet again?

Maybe they were just waiting for a full year to go by so that they might
have some hopes of this /20 being automatically aged off some blacklists.


Regards,
rfg


P.S.  This crap appears to be be brought to us courtesy of AS29632,
NetAssist, LLC:

http://new.netassist.ua/

So anyway, where are the grownups?

Re: Questions re: VPN protocols globally

[Florian Weimer]

* Valdis Kletnieks:

> On Wed, 05 Oct 2016 12:06:07 -0400, Eric Germann said:
>
>> Customers will connect to their respective regional sites separately.
>> Any ITAR concerns there?
>
> If there are serious concerns there, I recommend spending the coin for
> an actual ITAR expert.

Right.  I *think* it is possible to pull this off, but I expect that
you have to file some paperwork, and doing that without proper
training and knowledge of the applicable guidelines seems way too
risky.

(There isn't just ITAR.  Local regulations apply as well.)

Re: nested prefixes in Internet

[Florian Weimer]

* Martin T.:

> Florian:
>
>> Are the autonomous systems for the /19 and /24 connected directly?
>
> Yes they are.

Then deaggregation really isn't necessary at all.

>> (1) can be better from B's perspective because it prevents certain
>> routing table optimizations (due to the lack of the covering prefix)
>
> What kind of routing table optimizations are possible if covering /19
> prefix is also present in global routing table?

The /24 prefix could arguably be dropped and ignored for routing
decisions.

Re: Questions re: VPN protocols globally

[Valdis . Kletnieks]

On Wed, 05 Oct 2016 12:06:07 -0400, Eric Germann said:

> Customers will connect to their respective regional sites separately.
> Any ITAR concerns there?

If there are serious concerns there, I recommend spending the coin for
an actual ITAR expert.



pgpEfSfJNvtPM.pgp
Description: PGP signature

Re: Level 3 voice outage

[Mel Beckman]

It’s good to see them acknowledging this.

 -mel

On Oct 5, 2016, at 10:10 AM, Gareth Tupper 
> wrote:

Looks like a fat finger event...

From Level 3:
"On October 4, our voice network experienced a service disruption affecting 
some of our customers in North America due to a configuration error. We know 
how important these services are to our customers. As an organization, we're 
putting processes in place to prevent issues like this from recurring in the 
future. We were able to restore all services by 9:31am Mountain time."


http://www.theregister.co.uk/2016/10/05/level3_voip_blackout_cause/



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mel Beckman
Sent: Tuesday, October 4, 2016 1:09 PM
To: Marco Teixeira >
Cc: Shawn Ritchie >; 
NANOG list >
Subject: Re: Level 3 voice outage

Possibly somebody YANGed when they should have yinged :)

-mel beckman

On Oct 4, 2016, at 1:06 PM, Marco Teixeira 
>
 wrote:

Yeap, i know, it was what i understood, as it is my opinion that a zero day 
would fit better... in the pure speculation world :) At the end of the day... 
maybe some undocumented fault int some obscure functionality that was 
activated/deployed a long time ago, and just revealed it self now... There are 
so many things that can go wrong on complex networks even with all the controls 
imposed on changes...




On Tue, Oct 4, 2016 at 8:54 PM, Shawn Ritchie 
>
 wrote:
Well, Level3 has by no means said that this was the result of a DDoS, that's 
just speculation on behalf of folks who do not work at Level3 so far.

On Tue, Oct 4, 2016 at 2:49 PM Marco Teixeira 
>
 wrote:
I won't believe a company like Level3 would not deploy backplane 
protection/policing on routers. Also, 1Tb/s aggregated DDoS towards OVH network 
didn't pause or rebooted routers. And i guess both companies have had their 
share of (D)DoS in the past, so they had the time to get up to the challenge. 
Now... there where times where one malformed IP packet would cause a memory 
leak leading to a router reboot... :)?




On Tue, Oct 4, 2016 at 8:23 PM, Mel Beckman 
> wrote:

765 Gbps per second directed at a router's interface IP might give the
router pause, so to speak :)

-mel

On Oct 4, 2016, at 12:10 PM, Marco Teixeira
>
wrote:

Multiple reboots across several markets... Does not seem something
that full pipes would trigger. Had it been an approved chance it would
have been rolled back i guess... On the other hand, a zero day could apply...

Em 04/10/2016 19:54, "Mel Beckman" 
> escreveu:

Sure. The recent release of the IoT DDoS attack code in the wild.

-mel

On Oct 4, 2016, at 11:42 AM, 
valdis.kletni...@vt.edu
 wrote:

On Tue, 04 Oct 2016 18:14:54 -, Mel Beckman said:

This could be DoS attack.

Or a missing comma in a code update.

Or a fumble-fingered NOC monkey.

Or

You have any reason to suspect a DoS attack rather than all the
other possibilities?



--

--
Shawn



This electronic mail transmission contains information from Warner Pacific 
Insurance Services that may be confidential or privileged. Such information is 
solely for the intended recipient, and use by any other party is not 
authorized. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of this message, its contents or any 
attachments is prohibited. Any wrongful interception of this message is 
punishable as a Federal Crime. If you have received this message in error, 
please notify the sender immediately by telephone (800) 801-2300 or by 
electronic mail at 
postmas...@warnerpacific.com.

RE: Legislative proposal sent to my Congressman

[Harry Crowder]

The term you are referencing is unicast reverse path verify strict/hard mode
Enforces that the packets source can be reached via the interface of the 
receiving traffic
If this is generaly applied at all provider edge routers and dsl/dialup/vpc 
pop's would solve the spoofing issue as a whole

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Larry Sheldon
Sent: Monday, October 3, 2016 5:36 PM
To: Stephen Satchell ; nanog@nanog.org; ietf-act...@ietf.org
Cc: s...@us-cert.gov; act...@eff.org
Subject: Re: Legislative proposal sent to my Congressman



On 10/3/2016 13:58, Stephen Satchell wrote:
> In thinking over the last DDos involving IoT devices, I think we don't 
> have a good technical solution to the problem.  Cutting off people 
> with defective devices they they don't understand, and have little 
> control over, is an action that makes sense, but hurts the innocent.  
> "Hey, Grandma, did you know your TV set is hurting the Internet?"
>
> It's the people who foist bad stuff on the people who need to take the 
> responsibility.  Indeed, with enough moxie, we could avoid the net 
> saturation problem in the first place.
>
> My proposal, as I sent it to my US House Representative:
>

[much snipping]


> Why not nip the IoT problem in the bud?

Why not, indeed?  (Full disclosure:  I am not and have not for some years been 
active in management of any networks, and I AM woefully behind the state of the 
arts.)

Having said that, it occurs to me that Mr. Satchell's proposal (and most of the 
others I have read about here and elsewhere lately) are doomed to the same 
failure as Chicago's plan for reducing illegal deaths by firearm, and for much 
the same reason (discussion of which here I will spare you.

Back in the day, I was fighting a problem that I summarized (then and
now) as trying to stop the use and abuse of the University's (that employed me) 
56kb Frame Relay link to the Internet.  Then as now I defined "abuse" as the 
use of our facilities for purposes that no stretch of imagination or definition 
could be said to be to the University's benefit.

Through some experimentation I concluded that there were several clearly 
identifiable sources of abuse.  I disremember the ordering by severity but they 
included:

Outright attacks on the University and others.
Myriad "scans" for a variety of reasons.

The first of these two I remember as being the worst (in terms of item-count 
AND in terms of packet-size.  I also recall it being the easiest to fix, if 
anybody want to fix it.  (The dominant reasons  given where that it would cost 
money without a revenue stream, and it would reduce traffic that WAS in the 
revenue stream.  The fix I proposed: 
Require (by law) that every service provider and every origination customer of 
a service provider would under penalty of law, block the transmission of a 
packet whose source address could not be reached via the link upon which it was 
found.

The Myriad scans problem was a little harder (for among other reasons--the 
argument that they were good for us, even though they accounted for something 
like 60% of the traffic on that link).  The solution I tried but ran out of 
dollars on was to detect somebody scanning and route them to the Loopback 
interface of the boundary router.
--
"Everybody is a genius.  But if you judge a fish by its ability to climb a 
tree, it will live its whole life believing that it is stupid."

--Albert Einstein

 From Larry's Cox account.

Re: Questions re: VPN protocols globally

[Eric Germann]

IPSec and corporate.

Customers will connect to their respective regional sites separately.  Any ITAR 
concerns there?


> On Oct 5, 2016, at 12:01 PM, Christopher Morrow  
> wrote:
> 
> 
> 
> On Tue, Oct 4, 2016 at 11:15 PM, Eric Germann  > wrote:
> I’ve been charged with building a global VPN as an overlay on top of a 
> certain 3 letter company who also sells lots of stuff.
> 
> 
> you say 'vpn' do you mean 'mpls vpn' or 'ipsec vpn over intertubes' ?
>  
> We’re looking at
> 
> US East
> US West
> US Central (eventually)
> Brazil
> Singapore
> Frankfurt
> Ireland
> Sydney
> Maybe Canada
> Maybe India (outsourcesrs)
> 
> In the planning stages now and wondering if there are any protocols I need to 
> stay away from ITAR wise with this list of countries.
> 
> Contemplating Suite B with GCM, etc and AES acceleration.
> 
> 
> most places dont' really care about encryption if your use is 'for corporate 
> use', not providing use by external parties (internet access sorts of 
> things), I believe.



smime.p7s
Description: S/MIME cryptographic signature

Re: Questions re: VPN protocols globally

[Eric Germann]

I’m aware.  We’re considering them down the line.

So, back to the question, any ITAR gotchas with any of these companies?

Thanks

EKG

> On Oct 5, 2016, at 11:05 AM, Peter Beckman  wrote:
> 
> There is a Mumbai, India three letter company region available as of June 27, 
> 2016
> 
> https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-mumbai-region/
> 
> On Tue, 4 Oct 2016, Eric Germann wrote:
> 
>> I’ve been charged with building a global VPN as an overlay on top of a 
>> certain 3 letter company who also sells lots of stuff.
>> 
>> We’re looking at
>> 
>> US East
>> US West
>> US Central (eventually)
>> Brazil
>> Singapore
>> Frankfurt
>> Ireland
>> Sydney
>> Maybe Canada
>> Maybe India (outsourcesrs)
>> 
>> In the planning stages now and wondering if there are any protocols I need 
>> to stay away from ITAR wise with this list of countries.
>> 
>> Contemplating Suite B with GCM, etc and AES acceleration.
>> 
>> Any land mines?
>> 
>> Thanks in advance
>> 
>> EKG
>> 
>> 
> 
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com http://www.angryox.com/
> ---



smime.p7s
Description: S/MIME cryptographic signature

RE: Level 3 voice outage

[Gareth Tupper]

Looks like a fat finger event...

>From Level 3:
"On October 4, our voice network experienced a service disruption affecting 
some of our customers in North America due to a configuration error. We know 
how important these services are to our customers. As an organization, we're 
putting processes in place to prevent issues like this from recurring in the 
future. We were able to restore all services by 9:31am Mountain time."


http://www.theregister.co.uk/2016/10/05/level3_voip_blackout_cause/



-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mel Beckman
Sent: Tuesday, October 4, 2016 1:09 PM
To: Marco Teixeira 
Cc: Shawn Ritchie ; NANOG list 
Subject: Re: Level 3 voice outage

Possibly somebody YANGed when they should have yinged :)

 -mel beckman

On Oct 4, 2016, at 1:06 PM, Marco Teixeira 
> wrote:

Yeap, i know, it was what i understood, as it is my opinion that a zero day 
would fit better... in the pure speculation world :) At the end of the day... 
maybe some undocumented fault int some obscure functionality that was 
activated/deployed a long time ago, and just revealed it self now... There are 
so many things that can go wrong on complex networks even with all the controls 
imposed on changes...




On Tue, Oct 4, 2016 at 8:54 PM, Shawn Ritchie 
> wrote:
Well, Level3 has by no means said that this was the result of a DDoS, that's 
just speculation on behalf of folks who do not work at Level3 so far.

On Tue, Oct 4, 2016 at 2:49 PM Marco Teixeira 
> wrote:
I won't believe a company like Level3 would not deploy backplane 
protection/policing on routers. Also, 1Tb/s aggregated DDoS towards OVH network 
didn't pause or rebooted routers. And i guess both companies have had their 
share of (D)DoS in the past, so they had the time to get up to the challenge. 
Now... there where times where one malformed IP packet would cause a memory 
leak leading to a router reboot... :)?




On Tue, Oct 4, 2016 at 8:23 PM, Mel Beckman 
> wrote:

> 765 Gbps per second directed at a router's interface IP might give the
> router pause, so to speak :)
>
>  -mel
>
> On Oct 4, 2016, at 12:10 PM, Marco Teixeira
> >
> wrote:
>
> Multiple reboots across several markets... Does not seem something
> that full pipes would trigger. Had it been an approved chance it would
> have been rolled back i guess... On the other hand, a zero day could apply...
>
> Em 04/10/2016 19:54, "Mel Beckman" 
> > escreveu:
>
>> Sure. The recent release of the IoT DDoS attack code in the wild.
>>
>>  -mel
>>
>> > On Oct 4, 2016, at 11:42 AM, 
>> > valdis.kletni...@vt.edu wrote:
>> >
>> > On Tue, 04 Oct 2016 18:14:54 -, Mel Beckman said:
>> >
>> >> This could be DoS attack.
>> >
>> > Or a missing comma in a code update.
>> >
>> > Or a fumble-fingered NOC monkey.
>> >
>> > Or
>> >
>> > You have any reason to suspect a DoS attack rather than all the
>> > other possibilities?
>>
>>
>
--

--
Shawn



This electronic mail transmission contains information from Warner Pacific 
Insurance Services that may be confidential or privileged. Such information is 
solely for the intended recipient, and use by any other party is not 
authorized. If you are not the intended recipient, be aware that any 
disclosure, copying, distribution or use of this message, its contents or any 
attachments is prohibited. Any wrongful interception of this message is 
punishable as a Federal Crime. If you have received this message in error, 
please notify the sender immediately by telephone (800) 801-2300 or by 
electronic mail at postmas...@warnerpacific.com.

Re: Legislative proposal sent to my Congressman

[Stephen Satchell]

On 10/05/2016 09:46 AM, jim deleskie wrote:
> Can we please not get the government ( who's gov ) involved. I fully agree
> that it will not only not help, but will make some things worse.  This is
> why we can't have nice things.

I would be in favor of your pleas if you would accompany it with your
proposal for eliminating exploitable devices from accessing the Internet
and being the source of damaging traffic.

This IS the NANOG mailing list.  So far, the "solutions" I've seen put
foreward are like requiring government ID at polling places.

Re: Legislative proposal sent to my Congressman

[jim deleskie]

Can we please not get the government ( who's gov ) involved. I fully agree
that it will not only not help, but will make some things worse.  This is
why we can't have nice things.


On Tuesday, October 4, 2016, Anne Mitchell  wrote:

> (Interesting and inarguably well-intentioned, and possibly even sound,
> idea snipped, but noted.)
>
> There are a handful of reasons that this will never happen (well, I'm 98%
> certain it will never happen, nothing is every 100% sure when it comes to
> the law, and legislation)... among them the manufacturer's lobby is much
> more well-girded than is the   'home internet security' lobby;  the
> cyber-security concerns of the Federal government are focussed on other
> things (whether they should be or not, they are);  and for the most part
> legislators are still fairly unsavvy about tech in general, and these
> things make their eyes glaze over.
>
> That said, there are already tort (negligence, etc.) laws and precedents
> under which such manufacturers can be sued, along with things like breach
> of contract between the manufacturer and consumer, and breach of implied
> warranty of fitness for a particular purpose and breach of implied warranty
> of merchantability.
>
> A couple of winning lawsuits against manufacturers under these laws and
> theories - which judges *already understand* - is, I think, not only a more
> likely, but a much faster, route to industry reform.
>
> All that said, much of this faces the same issues that spam lawsuits faced
> - the people who care the most about it are not the ones who can afford to
> finance such lawsuits.
>
> Anne
>
> Anne P. Mitchell,
> Attorney at Law
> Legislative Consultant
> CEO/President, Institute for Social Internet Public Policy
> Member, Cal. Bar Cyberspace Law Committee
> Member, Colorado Cyber Committee
> Member, Asilomar Microcomputer Workshop Committee
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop

Re: Questions re: VPN protocols globally

[Christopher Morrow]

On Tue, Oct 4, 2016 at 11:15 PM, Eric Germann 
wrote:

> I’ve been charged with building a global VPN as an overlay on top of a
> certain 3 letter company who also sells lots of stuff.
>
>
you say 'vpn' do you mean 'mpls vpn' or 'ipsec vpn over intertubes' ?


> We’re looking at
>
> US East
> US West
> US Central (eventually)
> Brazil
> Singapore
> Frankfurt
> Ireland
> Sydney
> Maybe Canada
> Maybe India (outsourcesrs)
>
> In the planning stages now and wondering if there are any protocols I need
> to stay away from ITAR wise with this list of countries.
>
> Contemplating Suite B with GCM, etc and AES acceleration.
>
>
most places dont' really care about encryption if your use is 'for
corporate use', not providing use by external parties (internet access
sorts of things), I believe.

Re: Questions re: VPN protocols globally

[Peter Beckman]

There is a Mumbai, India three letter company region available as of June 27, 
2016

https://aws.amazon.com/blogs/aws/now-open-aws-asia-pacific-mumbai-region/

On Tue, 4 Oct 2016, Eric Germann wrote:


I’ve been charged with building a global VPN as an overlay on top of a certain 
3 letter company who also sells lots of stuff.

We’re looking at

US East
US West
US Central (eventually)
Brazil
Singapore
Frankfurt
Ireland
Sydney
Maybe Canada
Maybe India (outsourcesrs)

In the planning stages now and wondering if there are any protocols I need to 
stay away from ITAR wise with this list of countries.

Contemplating Suite B with GCM, etc and AES acceleration.

Any land mines?

Thanks in advance

EKG




---
Peter Beckman  Internet Guy
beck...@angryox.com http://www.angryox.com/
---

Re: 10G tester recommendations?

[Saku Ytti]

On 5 October 2016 at 15:54, Bryan Holloway  wrote:
> Mainly RFC2544 and physical media. QoS could be handy, but it's not as
> important as proving that the circuit is meeting our expectations from the
> carrier(s).

Then then EXFO is fine and much more affordable than Spirent or IXIA.

-- 
  ++ytti

Re: 10G tester recommendations?

[Bryan Holloway]

Mainly RFC2544 and physical media. QoS could be handy, but it's not as 
important as proving that the circuit is meeting our expectations from 
the carrier(s).



On 10/4/16 1:12 PM, Saku Ytti wrote:

On 3 October 2016 at 22:09, Bryan Holloway  wrote:

We're in the market for a hand-held 10G ethernet tester, and I was curious
if the NANOG community had any recommendations or experiences they would be
willing to share, negative or positive.


What are you looking to test? Are you interested in having the kit
emulate many devices? Do you want to be able to test QoS
realistically? Do you care about one-way latency accurately?
Or is this more about proving the physical media is fine?

Questions re: VPN protocols globally

[Eric Germann]

I’ve been charged with building a global VPN as an overlay on top of a certain 
3 letter company who also sells lots of stuff.

We’re looking at 

US East
US West
US Central (eventually)
Brazil
Singapore
Frankfurt
Ireland
Sydney
Maybe Canada
Maybe India (outsourcesrs)

In the planning stages now and wondering if there are any protocols I need to 
stay away from ITAR wise with this list of countries.

Contemplating Suite B with GCM, etc and AES acceleration.

Any land mines?

Thanks in advance

EKG



smime.p7s
Description: S/MIME cryptographic signature

Re: nested prefixes in Internet

[Martin T]

Florian:

> Are the autonomous systems for the /19 and /24 connected directly?

Yes they are.


> (1) can be better from B's perspective because it prevents certain routing 
> table optimizations (due to the lack of the covering prefix)

What kind of routing table optimizations are possible if covering /19
prefix is also present in global routing table?


> But (1) can also be worse for B and A's other customers if /24s (and slightly 
> shorter prefixes) in this part of the IPv4 address space are commonly 
> filtered.

Based on my experience /24 is allowed in prefix-filters.. Longer IPv4
prefixes are not.



Roy, Mel:

Could you please elaborate on that option. What kind of advantages
does this have compared to option 2?


thanks,
Martin


On Tue, Sep 27, 2016 at 8:52 PM, Michael Hallgren  wrote:
> Hi Martin,
>
> What do you want to do? Move from A to B or add A to B?
>
> Cheers,
> mh
>
>
>
> Le 27 sept. 2016 17:52, à 17:52, Mel Beckman  a écrit:
>>Precisely. This is how it's done by providers I've worked with.
>>
>> -mel beckman
>>
>>> On Sep 27, 2016, at 7:06 AM, Roy  wrote:
>>>
>>>
>>>
>>> Option 3?
>>>
>>> ISP A announces the /19 and the /24 while ISP B does just the /24
>>>
 On 9/27/2016 4:20 AM, Martin T wrote:
 Hi,

 let's assume that there is an ISP "A" operating in Europe region who
 has /19 IPv4 allocation from RIPE. From this /19 they have leased
>>/24
 to ISP "B" who is multi-homed. This means that ISP "B" would like to
 announce this /24 prefix to ISP "A" and also to ISP "C". AFAIK this
 gives two possibilities:

 1) Deaggregate /19 in ISP "A" network and create "inetnum" and
>>"route"
 objects for all those networks to RIPE database. This means that ISP
 "A" announces around dozen IPv4 prefixes to Internet except this /24
 and ISP "B" announces this specific /24 to Internet.

 2) ISP "A" continues to announce this /19 to Internet and at the
>>same
 time ISP "B" starts to announce /24 to Internet. As this /24 is
 more-specific than /19, then traffic to hosts in this /24 will end
>>up
 in ISP "B" network.


 Which approach is better? To me the second one seems to be better
 because it keeps the IPv4 routing-table smaller and requires ISP "A"
 to make no deaggregation related configuration changes. Only bit
>>weird
 behavior I can see with the second option is that if ISP "B" stops
>>for
 some reason announcing this /24 network to Internet, then traffic to
 hosts in this /24 gets to ISP "A" network and is blackholed there.


 thanks,
 Martin
>>>