Re: de-peering for security sake

[Colin Johnston]

cats are nice

colin

Sent from my iPhone

> On 19 Jan 2016, at 15:12, "Michael O'Connor"  wrote:
> 
> Why do we believe network administrators can advocate perfectly for
> customer access?
> I couldn't control my own children's access without making us all
> miserable.
> 
> Nation state access control in a free country at the network layer is bound
> to fail, way too many cats to herd.
> 
> 
> 
>> On Mon, Jan 18, 2016 at 2:31 PM,  wrote:
>> 
>> 
>> On January 18, 2016 at 00:21 valdis.kletni...@vt.edu (
>> valdis.kletni...@vt.edu) wrote:
>>> On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
 How about if backed by an agreement with the 5 RIRs stating no new
 resource allocations or transfers etc unless a contract is signed and
 enforced? Or similar.
>>> 
>>> Then they'd just resort to hijacking address space.
>>> 
>>> Oh wait, they already do that and get away with it
>> 
>> I think we're talking about two different problems, both valid.
>> 
>> One is legitimate operators who probably mostly want to do the right
>> thing but are negligent, disagree (perhaps with many one this list) on
>> what is an actionable problem, etc.
>> 
>> The other are those actors prone to criminality.
>> 
>> I was addressing the first problem though I'd assert that progress on
>> the first problem would likely yield progress on the second, or
>> cooperation anyhow.
>> 
>>> 
>>> (And a threat of withholding IP address space from long-haul providers
>> isn't as
>>> credible - they have much less need for publicly routed IP addresses
>> than
>>> either eyeball farms or content farms, so you'll have to find some
>> other way to
>>> motivate them to not accept a hijacked route announcement...)
>>> 
>> 
>> No man is an island entire of himself -- John Donne.
>> 
>> First one has to agree to the concept of creating a network based on
>> contractual agreements.
>> 
>> I gave some examples of how to encourage actors to enter into those
>> contracts, my list wasn't intended to be exhaustive, it was intended
>> to be an existence proof, some pressure points exist and are easy to
>> understand even if not complete.
>> 
>> Besides, why make the perfect the enemy of the good? If many, perhaps
>> not all (or not at first), agreed to a common set of contractual
>> obligations that would be progress, no?
>> 
>> Is there even a document which describes what a "hijacked" net block
>> is and why it is bad? Obvious? No, it is not obvious. The best one can
>> say is there exist obvious cases.
>> 
>> --
>>-Barry Shein
>> 
>> Software Tool & Die| b...@theworld.com |
>> http://www.TheWorld.com
>> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
>> The World: Since 1989  | A Public Information Utility | *oo*
>> 
> 
> 
> 
> -- 
> Michael O'Connor
> ESnet Network Engineering
> m...@es.net
> 631 344-7410

Re: de-peering for security sake

[bzs]

On January 19, 2016 at 10:12 m...@es.net (Michael O'Connor) wrote:
 > Why do we believe network administrators can advocate perfectly for
 > customer access?

Which is why I was advocating for some sort of generally agreed upon
standards and process written into contractual agreements.

This doesn't mean that someone has any inherent right to a private
company's (typically) resources, one could block whatever they please,
or nothing.

But when there's some agreement that there's been a consistent breech
of agreed-upon standards of behavior which should be responded to by
the broader community at least there'd be some guidance and process
beyond just urging everyone else to "de-peer" some sites on an
operations mailing list.

The goal would be setting standards for what is reasonable to send
(e.g., not DDoS), not what is received.

 > I couldn't control my own children's access without making us all
 > miserable.
 > 
 > Nation state access control in a free country at the network layer is bound
 > to fail, way too many cats to herd.
 > 
 > 
 > 
 > On Mon, Jan 18, 2016 at 2:31 PM,  wrote:
 > 
 > >
 > > On January 18, 2016 at 00:21 valdis.kletni...@vt.edu (
 > > valdis.kletni...@vt.edu) wrote:
 > >  > On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
 > >  > > How about if backed by an agreement with the 5 RIRs stating no new
 > >  > > resource allocations or transfers etc unless a contract is signed and
 > >  > > enforced? Or similar.
 > >  >
 > >  > Then they'd just resort to hijacking address space.
 > >  >
 > >  > Oh wait, they already do that and get away with it
 > >
 > > I think we're talking about two different problems, both valid.
 > >
 > > One is legitimate operators who probably mostly want to do the right
 > > thing but are negligent, disagree (perhaps with many one this list) on
 > > what is an actionable problem, etc.
 > >
 > > The other are those actors prone to criminality.
 > >
 > > I was addressing the first problem though I'd assert that progress on
 > > the first problem would likely yield progress on the second, or
 > > cooperation anyhow.
 > >
 > >  >
 > >  > (And a threat of withholding IP address space from long-haul providers
 > > isn't as
 > >  > credible - they have much less need for publicly routed IP addresses
 > > than
 > >  > either eyeball farms or content farms, so you'll have to find some
 > > other way to
 > >  > motivate them to not accept a hijacked route announcement...)
 > >  >
 > >
 > > No man is an island entire of himself -- John Donne.
 > >
 > > First one has to agree to the concept of creating a network based on
 > > contractual agreements.
 > >
 > > I gave some examples of how to encourage actors to enter into those
 > > contracts, my list wasn't intended to be exhaustive, it was intended
 > > to be an existence proof, some pressure points exist and are easy to
 > > understand even if not complete.
 > >
 > > Besides, why make the perfect the enemy of the good? If many, perhaps
 > > not all (or not at first), agreed to a common set of contractual
 > > obligations that would be progress, no?
 > >
 > > Is there even a document which describes what a "hijacked" net block
 > > is and why it is bad? Obvious? No, it is not obvious. The best one can
 > > say is there exist obvious cases.
 > >
 > > --
 > > -Barry Shein
 > >
 > > Software Tool & Die| b...@theworld.com |
 > > http://www.TheWorld.com
 > > Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
 > > The World: Since 1989  | A Public Information Utility | *oo*
 > >
 > 
 > 
 > 
 > -- 
 > Michael O'Connor
 > ESnet Network Engineering
 > m...@es.net
 > 631 344-7410

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: de-peering for security sake

[Michael O'Connor]

Why do we believe network administrators can advocate perfectly for
customer access?
I couldn't control my own children's access without making us all
miserable.

Nation state access control in a free country at the network layer is bound
to fail, way too many cats to herd.



On Mon, Jan 18, 2016 at 2:31 PM,  wrote:

>
> On January 18, 2016 at 00:21 valdis.kletni...@vt.edu (
> valdis.kletni...@vt.edu) wrote:
>  > On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
>  > > How about if backed by an agreement with the 5 RIRs stating no new
>  > > resource allocations or transfers etc unless a contract is signed and
>  > > enforced? Or similar.
>  >
>  > Then they'd just resort to hijacking address space.
>  >
>  > Oh wait, they already do that and get away with it
>
> I think we're talking about two different problems, both valid.
>
> One is legitimate operators who probably mostly want to do the right
> thing but are negligent, disagree (perhaps with many one this list) on
> what is an actionable problem, etc.
>
> The other are those actors prone to criminality.
>
> I was addressing the first problem though I'd assert that progress on
> the first problem would likely yield progress on the second, or
> cooperation anyhow.
>
>  >
>  > (And a threat of withholding IP address space from long-haul providers
> isn't as
>  > credible - they have much less need for publicly routed IP addresses
> than
>  > either eyeball farms or content farms, so you'll have to find some
> other way to
>  > motivate them to not accept a hijacked route announcement...)
>  >
>
> No man is an island entire of himself -- John Donne.
>
> First one has to agree to the concept of creating a network based on
> contractual agreements.
>
> I gave some examples of how to encourage actors to enter into those
> contracts, my list wasn't intended to be exhaustive, it was intended
> to be an existence proof, some pressure points exist and are easy to
> understand even if not complete.
>
> Besides, why make the perfect the enemy of the good? If many, perhaps
> not all (or not at first), agreed to a common set of contractual
> obligations that would be progress, no?
>
> Is there even a document which describes what a "hijacked" net block
> is and why it is bad? Obvious? No, it is not obvious. The best one can
> say is there exist obvious cases.
>
> --
> -Barry Shein
>
> Software Tool & Die| b...@theworld.com |
> http://www.TheWorld.com
> Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
> The World: Since 1989  | A Public Information Utility | *oo*
>



-- 
Michael O'Connor
ESnet Network Engineering
m...@es.net
631 344-7410

Re: de-peering for security sake

[bzs]

On January 18, 2016 at 00:21 valdis.kletni...@vt.edu (valdis.kletni...@vt.edu) 
wrote:
 > On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
 > > How about if backed by an agreement with the 5 RIRs stating no new
 > > resource allocations or transfers etc unless a contract is signed and
 > > enforced? Or similar.
 > 
 > Then they'd just resort to hijacking address space.
 > 
 > Oh wait, they already do that and get away with it

I think we're talking about two different problems, both valid.

One is legitimate operators who probably mostly want to do the right
thing but are negligent, disagree (perhaps with many one this list) on
what is an actionable problem, etc.

The other are those actors prone to criminality.

I was addressing the first problem though I'd assert that progress on
the first problem would likely yield progress on the second, or
cooperation anyhow.

 > 
 > (And a threat of withholding IP address space from long-haul providers isn't 
 > as
 > credible - they have much less need for publicly routed IP addresses than
 > either eyeball farms or content farms, so you'll have to find some other way 
 > to
 > motivate them to not accept a hijacked route announcement...)
 > 

No man is an island entire of himself -- John Donne.

First one has to agree to the concept of creating a network based on
contractual agreements.

I gave some examples of how to encourage actors to enter into those
contracts, my list wasn't intended to be exhaustive, it was intended
to be an existence proof, some pressure points exist and are easy to
understand even if not complete.

Besides, why make the perfect the enemy of the good? If many, perhaps
not all (or not at first), agreed to a common set of contractual
obligations that would be progress, no?

Is there even a document which describes what a "hijacked" net block
is and why it is bad? Obvious? No, it is not obvious. The best one can
say is there exist obvious cases.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sun, 17 Jan 2016 19:39:52 -0500, b...@theworld.com said:
> How about if backed by an agreement with the 5 RIRs stating no new
> resource allocations or transfers etc unless a contract is signed and
> enforced? Or similar.

Then they'd just resort to hijacking address space.

Oh wait, they already do that and get away with it

(And a threat of withholding IP address space from long-haul providers isn't as
credible - they have much less need for publicly routed IP addresses than
either eyeball farms or content farms, so you'll have to find some other way to
motivate them to not accept a hijacked route announcement...)



pgpM7i77CxkzJ.pgp
Description: PGP signature

Re: de-peering for security sake

[bzs]

On January 17, 2016 at 13:09 do...@dougbarton.us (Doug Barton) wrote:
 > On 1/17/2016 12:44 PM, b...@theworld.com wrote:
 > > We need an effective forum with effective participation perhaps
 > > eventually leading to signed contractual obligations agreed to by all
 > > parties.
 > 
 > Not gonna help. The same people who have no incentive to do the right 
 > thing now will still have no incentive to join the group you propose.

How about if backed by an agreement with the 5 RIRs stating no new
resource allocations or transfers etc unless a contract is signed and
enforced? Or similar.

Anyhow the point is that the same methods can be used, it's just that
if one uses a contractual obligation (or refusal to sign thereto) and
some process for adjudication at least it can take on the appearance
of transparent fair play and violation of rules everyone has agreed to
abide by rather than vigilantism.

 > 
 > I've said it before, and it's an unpopular option, but the only way that 
 > this will change is to make it more expensive to do the wrong thing than 
 > it is to do the right thing. That means lawsuits filed by companies that 
 > have been harmed as a result of those that are not doing the right 
 > thing. That will produce the incentives which will be recognized and 
 > understood by all layers of management, and result in real action for 
 > the better.

Lawsuits are just looking for some external authority (a court, of
what jurisdiction?) to do what should have been done within the
industry itself. So now we'd have a court, and a jury of bus drivers
and senior citizens, trying to figure out what the problem really is?

I thought a lot of this started over international problems. Ever
tried to get a court order or subpoena enforced in Lower Slobbovia?

(no, because there is no such place as Lower Slobbovia, but you can
fill in that blank I'm sure.)

 > As nice as it would be if everyone were to do the right thing because 
 > it's the right thing, we already have ample evidence that won't happen. 
 > Time to stop pretending otherwise.

Might have something to do with the unsophisticated way this is being
approached?

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: de-peering for security sake

[bzs]

On January 17, 2016 at 13:06 goe...@sasami.anime.net (Dan Hollis) wrote:
 > On Sun, 17 Jan 2016, b...@theworld.com wrote:
 > > Sure, you have your hands on BGP etc, so what router commands (hammer)
 > > can effect international policy (nail)?
 > >
 > > This is fundamentally a social and political issue and needs to be
 > > dealt with on that level, not with changes in router configs.
 > 
 > bgp blackhole fed by rbl?
 > 
 > at the very least, scavenger queue packets by rbl.
 > 
 > complacency / willful negligence needs to have a monetary cost.

How well is this approach working so far?

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: de-peering for security sake

[Ca By]

On Sunday, January 17, 2016, Dan Hollis  wrote:

> On Sun, 17 Jan 2016, b...@theworld.com wrote:
>
>> Sure, you have your hands on BGP etc, so what router commands (hammer)
>> can effect international policy (nail)?
>>
>> This is fundamentally a social and political issue and needs to be
>> dealt with on that level, not with changes in router configs.
>>
>
> bgp blackhole fed by rbl?
>
> at the very least, scavenger queue packets by rbl.
>
>
If you are not already scoring packets by reputation, you are at very least
behind what AWS is doing for volumetric ddos mitigation

Check out around minute 12 and 13

http://youtu.be/Ys0gG1koqJA

As stated earlier, ip packets are going the way of spam mail :(

complacency / willful negligence needs to have a monetary cost.
>
> -Dan
>

Re: de-peering for security sake

[Dan Hollis]

On Sun, 17 Jan 2016, Doug Barton wrote:

On 1/17/2016 12:44 PM, b...@theworld.com wrote:

We need an effective forum with effective participation perhaps
eventually leading to signed contractual obligations agreed to by all
parties.
Not gonna help. The same people who have no incentive to do the right thing 
now will still have no incentive to join the group you propose.


I've said it before, and it's an unpopular option, but the only way that this 
will change is to make it more expensive to do the wrong thing than it is to 
do the right thing.


I think it can happen without lawsuits. look at RBLs and spamhaus. a bit 
sad that spamhaus has to exist in order to motivate operators to clean up 
their cesspools, but it does work to a certain extent.


-Dan

Re: de-peering for security sake

[Doug Barton]

On 1/17/2016 12:44 PM, b...@theworld.com wrote:

We need an effective forum with effective participation perhaps
eventually leading to signed contractual obligations agreed to by all
parties.


Not gonna help. The same people who have no incentive to do the right 
thing now will still have no incentive to join the group you propose.


I've said it before, and it's an unpopular option, but the only way that 
this will change is to make it more expensive to do the wrong thing than 
it is to do the right thing. That means lawsuits filed by companies that 
have been harmed as a result of those that are not doing the right 
thing. That will produce the incentives which will be recognized and 
understood by all layers of management, and result in real action for 
the better.


As nice as it would be if everyone were to do the right thing because 
it's the right thing, we already have ample evidence that won't happen. 
Time to stop pretending otherwise.


Doug

Re: de-peering for security sake

[Dan Hollis]

On Sun, 17 Jan 2016, b...@theworld.com wrote:

Sure, you have your hands on BGP etc, so what router commands (hammer)
can effect international policy (nail)?

This is fundamentally a social and political issue and needs to be
dealt with on that level, not with changes in router configs.


bgp blackhole fed by rbl?

at the very least, scavenger queue packets by rbl.

complacency / willful negligence needs to have a monetary cost.

-Dan

Re: de-peering for security sake

[bzs]

When all you have is a hammer the whole world looks like a nail.

That's what "de-peering for security sake" sounds like to me.

Sure, you have your hands on BGP etc, so what router commands (hammer)
can effect international policy (nail)?

This is fundamentally a social and political issue and needs to be
dealt with on that level, not with changes in router configs.

We need an effective forum with effective participation perhaps
eventually leading to signed contractual obligations agreed to by all
parties.

Perhaps way at the end of that process router commands can be used to
enforce agreed contracts and respond to adjudicated breeches, if and
when necessary.

Otherwise it's just rule by an angry mob. The internet has gotten way
too big and critical for that sort of approach.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 16 Jan 2016 11:09:27 -0800, Owen DeLong said:

> > Making the owner of the host responsible for an attack -personally-
> > responsible would require every grandma & 6 year old to have insurance 
> > before
> > buying a laptop or Xbox. And would bankrupt your favorite startup no matter 
> > how
> > smart & competent the first time a zero-day caught them by surprise.

> Agreed… I think, instead, that the commercial purveyors of vulnerable 
> software
> should be held liable.

And this is another one that needs *really* careful definitions.

How much time does Redhat get to patch a bug in (say) OpenSSH or the kernel
or any other package from upstream, before you want to hold them liable?


pgpg8YjlIAiXC.pgp
Description: PGP signature

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 16 Jan 2016 09:53:40 -0500, Rich Kulawiec said:

> I've said this many times: abuse does not magically fall out of the sky.
> It comes from hosts, on networks, run by people.  It is time -- well
> past time -- to hold those people *personally* acountable.

And who, *exactly*, are you planning to hold *personally* accountable? The Joe
Sixpack who didn't patch his system? The guy who's doing as much as he can with
the resources he's given? The guy above him who didn't hire 3 more people
because his group isn't given the budget for it?  The CFO who didn't give
budget for 3 more people because 3 qualified people plus benefits would wipe
out the small ISP's profits and then somee?



pgpWDOF5IuCgJ.pgp
Description: PGP signature

Re: de-peering for security sake

[Owen DeLong]

> On Jan 16, 2016, at 07:15 , Patrick W. Gilmore  wrote:
> 
> On Jan 16, 2016, at 9:53 AM, Rich Kulawiec  > wrote:
>> On Sat, Jan 16, 2016 at 05:43:56AM -0800, Ca By wrote:
> 
>>> I see a great deal of folks on nanog clamoring to buy ddos gear. Packets
>>> are starting to become like spam email, where 90% are pure rubbish,   and
>>> us good guys have to spend a lot of money and time sorting signal from
>>> noise.
>> 
>> I've said this many times: abuse does not magically fall out of the sky.
>> It comes from hosts, on networks, run by people.  It is time -- well
>> past time -- to hold those people *personally* acountable.
>> 
>> Not doing so leaves us where we are today: millions -- heck, hundreds
>> of millions -- of dollars are being spent on defenses THAT WOULD NOT
>> BE NECESSARY if those people performed their jobs at a mere baseline
>> level of competence and diligence.
> 
> Shared fate systems suck in some ways. But I disagree that “a mere baseline 
> level of competence and diligence” is even close to what is required.
> 
> Making the owner of the host responsible for an attack -personally- 
> responsible would require every grandma & 6 year old to have insurance before 
> buying a laptop or Xbox. And would bankrupt your favorite startup no matter 
> how smart & competent the first time a zero-day caught them by surprise.

Agreed… I think, instead, that the commercial purveyors of vulnerable software 
should be held liable.

> Of course, forcing Uncle Bob to call his insurance carrier before buying a 
> smartphone, and having San Hill Road take even greater risks when investing, 
> and giving lawyers yet another vector for frivolous lawsuits, wouldn’t have 
> the slightest effect on the global economy.
> 
> On the other hand, that 100s of millions of dollars is a rounding error in 
> the wealth & public good created by that same shared fate system.
> 
> Overall, I think we’re doing well.

While I agree with you (scary, huh) about most of this, I do think that there 
is legitimate liability to be had by commercial software vendors that have so 
far held themselves immune to prosecution.

We have already seen that vulnerabilities in open source software tend to get 
corrected much faster than in closed commercial software. We’ve also seen that 
opening up source code to inspection by the community tends to make the 
vulnerabilities known faster (which is a double-edge sword to be certain).

I’m not saying we should eliminate closed commercial software, but I do think 
giving it a free pass on the liability for the damage it inflicts is something 
that should no longer be tolerated.

> Before anyone pounces on me, I hate spam, dos, etc. as much as anyone else. 
> (You know how much personal, unpaid time I’ve put into fighting both, Rich.) 
> If we can find the originators of these things, we should hang them by their 
> thumbs and beat them senseless. We should do everything we can to make ISPs 
> implement BCP38, get software vendors to QA better, and educate users to be 
> less, well, idiotic.

+1

> But I am also pragmatic. Life sucks, it is not fair. But the idea of making 
> either grandma or the network engineer at an ISP or even the CEO of a hosting 
> company personally responsible for things like zero-days or minor errors 
> which can be exploited to the tune of greater than their personal wealth or 
> even their corporate market cap is a recipe for bringing everything to a 
> screeching halt.

Agreed. Perhaps liability with some sort of safe harbor provision for 
corrections released within 30 days of notification of vulnerability would be a 
better choice than outright complete liability.

However, if you want to sell software without giving users the ability to plug 
the holes you created, whether by design or by accident, should come with a 
responsibility to plug them on a timely basis.

> I kinda like the ride we’re on, bumps and all. Let’s not bring it to a 
> screeching halt.

Meh… If we did, a new ride would soon take its place.

Owen

Re: de-peering for security sake

[Owen DeLong]

> The pessimistic side of me believes cloudflare and akamai want the internet
> to be choked with bots such that everyone must pay their toll, so the
> information on the bots is a trade secret... But please prove me wrong so
> we can drive higher accountability on the internet.

I am not speaking for Akamai here and I have nothing to do with dDOS product
development there.

However, I will say that there is great expense involved in collecting the kind
of data you are now asking them to aggregate and release for free and there is
commercial value in selling protection services.

However, just as there is great value in providing health care services, I doubt
that physicians are out there cheering for disease and affliction. I’m quite
certain we would all be happy to market other services in the absence of a need
for dDOS mitigation services.

However, if you want to see this kind of data captured and disseminated for 
free,
I suggest you build a consortium to do so and find a way to fund it. I have no
input into the decision, but I think it would be absurd for a commercial entity
to give away data which is so expensive to obtain.

Owen

Re: de-peering for security sake

[Ca By]

On Saturday, January 16, 2016, Patrick W. Gilmore  wrote:

> On Jan 16, 2016, at 9:53 AM, Rich Kulawiec >
> wrote:
> > On Sat, Jan 16, 2016 at 05:43:56AM -0800, Ca By wrote:
>
> >> I see a great deal of folks on nanog clamoring to buy ddos gear. Packets
> >> are starting to become like spam email, where 90% are pure rubbish,
>  and
> >> us good guys have to spend a lot of money and time sorting signal from
> >> noise.
> >
> > I've said this many times: abuse does not magically fall out of the sky.
> > It comes from hosts, on networks, run by people.  It is time -- well
> > past time -- to hold those people *personally* acountable.
> >
> > Not doing so leaves us where we are today: millions -- heck, hundreds
> > of millions -- of dollars are being spent on defenses THAT WOULD NOT
> > BE NECESSARY if those people performed their jobs at a mere baseline
> > level of competence and diligence.
>
> Shared fate systems suck in some ways. But I disagree that “a mere
> baseline level of competence and diligence” is even close to what is
> required.
>
> Making the owner of the host responsible for an attack -personally-
> responsible would require every grandma & 6 year old to have insurance
> before buying a laptop or Xbox. And would bankrupt your favorite startup no
> matter how smart & competent the first time a zero-day caught them by
> surprise.
>
> Of course, forcing Uncle Bob to call his insurance carrier before buying a
> smartphone, and having San Hill Road take even greater risks when
> investing, and giving lawyers yet another vector for frivolous lawsuits,
> wouldn’t have the slightest effect on the global economy.
>
> On the other hand, that 100s of millions of dollars is a rounding error in
> the wealth & public good created by that same shared fate system.
>
> Overall, I think we’re doing well.
>
>
> Before anyone pounces on me, I hate spam, dos, etc. as much as anyone
> else. (You know how much personal, unpaid time I’ve put into fighting both,
> Rich.) If we can find the originators of these things, we should hang them
> by their thumbs and beat them senseless. We should do everything we can to
> make ISPs implement BCP38, get software vendors to QA better, and educate
> users to be less, well, idiotic.
>
> But I am also pragmatic. Life sucks, it is not fair. But the idea of
> making either grandma or the network engineer at an ISP or even the CEO of
> a hosting company personally responsible for things like zero-days or minor
> errors which can be exploited to the tune of greater than their personal
> wealth or even their corporate market cap is a recipe for bringing
> everything to a screeching halt.
>
> I kinda like the ride we’re on, bumps and all. Let’s not bring it to a
> screeching halt.
>
> --
> TTFN,
> patrick
>
>
Tar and feather bad, yes.

Name and shame so i can sick my "enterpise account manager" on the shamed =
good.

For example, i have an aws account manager.  He likes to come in quartly
and tell me and the exec team about how great aws is and how we need to buy
more reserved instances.   Like with ipv6, I will make his life hell with
my execs on our quartly business review citing spamhaus. My account manager
will squeel in a very unsatifying way, but he will muster his sales org
muscle to pass on the discomfort to the folks who can increase
accountability and address abuse internally.

That is how transparency and accountability work, put $ and reputation on
the line with big spenders.

So, thanks Spamhaus.

Now, looking at the ddos protection folks to do something similar so we can
get to the root of this ddos epidemic instead of constantly applying
network chemo

CB

Re: de-peering for security sake

[Patrick W. Gilmore]

On Jan 16, 2016, at 9:53 AM, Rich Kulawiec  wrote:
> On Sat, Jan 16, 2016 at 05:43:56AM -0800, Ca By wrote:

>> I see a great deal of folks on nanog clamoring to buy ddos gear. Packets
>> are starting to become like spam email, where 90% are pure rubbish,   and
>> us good guys have to spend a lot of money and time sorting signal from
>> noise.
> 
> I've said this many times: abuse does not magically fall out of the sky.
> It comes from hosts, on networks, run by people.  It is time -- well
> past time -- to hold those people *personally* acountable.
> 
> Not doing so leaves us where we are today: millions -- heck, hundreds
> of millions -- of dollars are being spent on defenses THAT WOULD NOT
> BE NECESSARY if those people performed their jobs at a mere baseline
> level of competence and diligence.

Shared fate systems suck in some ways. But I disagree that “a mere baseline 
level of competence and diligence” is even close to what is required.

Making the owner of the host responsible for an attack -personally- responsible 
would require every grandma & 6 year old to have insurance before buying a 
laptop or Xbox. And would bankrupt your favorite startup no matter how smart & 
competent the first time a zero-day caught them by surprise.

Of course, forcing Uncle Bob to call his insurance carrier before buying a 
smartphone, and having San Hill Road take even greater risks when investing, 
and giving lawyers yet another vector for frivolous lawsuits, wouldn’t have the 
slightest effect on the global economy.

On the other hand, that 100s of millions of dollars is a rounding error in the 
wealth & public good created by that same shared fate system.

Overall, I think we’re doing well.


Before anyone pounces on me, I hate spam, dos, etc. as much as anyone else. 
(You know how much personal, unpaid time I’ve put into fighting both, Rich.) If 
we can find the originators of these things, we should hang them by their 
thumbs and beat them senseless. We should do everything we can to make ISPs 
implement BCP38, get software vendors to QA better, and educate users to be 
less, well, idiotic.

But I am also pragmatic. Life sucks, it is not fair. But the idea of making 
either grandma or the network engineer at an ISP or even the CEO of a hosting 
company personally responsible for things like zero-days or minor errors which 
can be exploited to the tune of greater than their personal wealth or even 
their corporate market cap is a recipe for bringing everything to a screeching 
halt.

I kinda like the ride we’re on, bumps and all. Let’s not bring it to a 
screeching halt.

-- 
TTFN,
patrick

Re: de-peering for security sake

[Rich Kulawiec]

On Sat, Jan 16, 2016 at 05:43:56AM -0800, Ca By wrote:
> I see a great deal of folks on nanog clamoring to buy ddos gear. Packets
> are starting to become like spam email, where 90% are pure rubbish,   and
> us good guys have to spend a lot of money and time sorting signal from
> noise.

I've said this many times: abuse does not magically fall out of the sky.
It comes from hosts, on networks, run by people.  It is time -- well
past time -- to hold those people *personally* acountable.

Not doing so leaves us where we are today: millions -- heck, hundreds
of millions -- of dollars are being spent on defenses THAT WOULD NOT
BE NECESSARY if those people performed their jobs at a mere baseline
level of competence and diligence.

---rsk

Re: de-peering for security sake

[Mike Hammett]

Agreed. A "Top 10" report would be awesome. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Ca By"  
To: "Rich Kulawiec"  
Cc: nanog@nanog.org 
Sent: Saturday, January 16, 2016 7:43:56 AM 
Subject: Re: de-peering for security sake 

On Saturday, January 16, 2016, Rich Kulawiec  wrote: 

> On Thu, Dec 24, 2015 at 11:44:10PM +, Colin Johnston wrote: 
> > We really need to ask if China and Russia for that matter will not 
> > take abuse reports seriously why allow them to network to the internet ? 
> 
> One could ask the exact same question about Amazon -- which, as of 
> the moment, is the worst spam-supporting operation on the planet: 
> 
> https://www.spamhaus.org/statistics/networks/ 
> 
> Are they merely incompetent? negligent? stupid? lazy? Or are they 
> taking payoffs and bribes from spammers? Of course from outside there's 
> no way to know. But this is not how responsible, ethical, professional 
> operations behave: those operations promptly read, analyze, answer, and 
> act on every single abuse report that they get. 
> 
> ---rsk 
> 

I really like what spamhaus has done here. 

I see a great deal of folks on nanog clamoring to buy ddos gear. Packets 
are starting to become like spam email, where 90% are pure rubbish, and 
us good guys have to spend a lot of money and time sorting signal from 
noise. 

Can Cloudflare, Akamai, and the others in the ddos protection racket please 
do as spamhaus has done? It would really be a great service to aggregate 
and release high level data on where these ddos bots are hosted. 

The pessimistic side of me believes cloudflare and akamai want the internet 
to be choked with bots such that everyone must pay their toll, so the 
information on the bots is a trade secret... But please prove me wrong so 
we can drive higher accountability on the internet. 

Re: de-peering for security sake

[Ca By]

On Saturday, January 16, 2016, Rich Kulawiec  wrote:

> On Thu, Dec 24, 2015 at 11:44:10PM +, Colin Johnston wrote:
> > We really need to ask if China and Russia for that matter will not
> > take abuse reports seriously why allow them to network to the internet ?
>
> One could ask the exact same question about Amazon -- which, as of
> the moment, is the worst spam-supporting operation on the planet:
>
> https://www.spamhaus.org/statistics/networks/
>
> Are they merely incompetent? negligent? stupid? lazy?  Or are they
> taking payoffs and bribes from spammers?  Of course from outside there's
> no way to know.  But this is not how responsible, ethical, professional
> operations behave: those operations promptly read, analyze, answer, and
> act on every single abuse report that they get.
>
> ---rsk
>

I really like what spamhaus has done here.

I see a great deal of folks on nanog clamoring to buy ddos gear. Packets
are starting to become like spam email, where 90% are pure rubbish,   and
us good guys have to spend a lot of money and time sorting signal from
noise.

Can Cloudflare, Akamai, and the others in the ddos protection racket please
do as spamhaus has done? It would really be a great service to aggregate
and release high level data on where these ddos bots are hosted.

The pessimistic side of me believes cloudflare and akamai want the internet
to be choked with bots such that everyone must pay their toll, so the
information on the bots is a trade secret... But please prove me wrong so
we can drive higher accountability on the internet.

Re: de-peering for security sake

[Rich Kulawiec]

On Thu, Dec 24, 2015 at 11:44:10PM +, Colin Johnston wrote:
> We really need to ask if China and Russia for that matter will not
> take abuse reports seriously why allow them to network to the internet ?

One could ask the exact same question about Amazon -- which, as of
the moment, is the worst spam-supporting operation on the planet:

https://www.spamhaus.org/statistics/networks/

Are they merely incompetent? negligent? stupid? lazy?  Or are they
taking payoffs and bribes from spammers?  Of course from outside there's
no way to know.  But this is not how responsible, ethical, professional
operations behave: those operations promptly read, analyze, answer, and
act on every single abuse report that they get.

---rsk

Re: de-peering for security sake

[Randy Bush]

> Purposefully hosting an "inflammatory" site that the Russians or
> Chinese object to is a valid way to get your AS null routed inside
> those countries.  Same goes for Turkey, India, Australia...

luckily this is not true in the US.  oh wait.

>> We really need to ask if China and Russia for that matter will not
>> take abuse reports seriously why allow them to network to the
>> internet ?

luckily all american and ukranian isps respond to abuse in minutes.

moving right along ...

randy

Re: de-peering for security sake

[Richard Hesse]

Purposefully hosting an "inflammatory" site that the Russians or Chinese
object to is a valid way to get your AS null routed inside those countries.
Same goes for Turkey, India, Australia...

Solves the DDoS and malware problem inside their borders, not yours.
On Dec 25, 2015 4:43 AM, "Max Tulyev"  wrote:

> Come on, keep calm and wait a year: Russia and China will de-peer with
> all the world for their security (AKA censorship) reasons! ;)
>
> On 25.12.15 01:44, Colin Johnston wrote:
> > see
> > http://map.norsecorp.com
> >
> > We really need to ask if China and Russia for that matter will not take
> abuse reports seriously why allow them to network to the internet ?
> >
> > Colin
> >
> >
>
>

Re: de-peering for security sake

[James Downs]

> On Dec 26, 2015, at 12:34, Owen DeLong  wrote:
> 
> Also, note that the only difference between a good long passphrase and a 
> private key is,
> uh, wait, um, come to think of it, really not much.

Are you equating a long PSK with PKE? They’re quite different.

Re: de-peering for security sake

[Mike Hale]

Also think of it from the perspective of the authenticating host.

That SSH connection relies *only* on the key for authentication.  It
requires nothing else.  How you protect that key is irrelevant.  All
that matters is that the host is accepting a single form of
authentication.  It's clearly single-factor.

You can call pseudo-multi-factor if you want.  It's certainly better
than a shitty password.  But it's not multi-factor by the generally
accepted definition (although I'd place it under 'something you have'
rather than the 'something you know' section).

On Sun, Dec 27, 2015 at 5:08 PM, Owen DeLong  wrote:
>
>> On Dec 27, 2015, at 14:33 , Baldur Norddahl  
>> wrote:
>>
>>
>>
>> On 27 December 2015 at 22:08, Owen DeLong > > wrote:
>> This is a bit of a tangent, really. The discussion was about authentication 
>> factor
>> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
>> private key authentication as two-factor to bolster his claim that it was, 
>> in fact
>> two-factor, when it clearly isn’t actually two-factor as has been stated 
>> previously.
>>
>> I wanted to stay out of this, but Owen you are full of shit here. I am 
>> pointing out that your homemade definition does not match up with what 
>> others think two factor means. PCI DSS might be utter crap, but they are 
>> still more than "Owen DeLong and his personal opinion”.
>
> Dude… It’s not just my opinion. Virtually every one else who chimed in on the 
> thread other than you backed my position on this.
>
>> You are utterly confused about the meaning about two factor. You apparently 
>> believe the magic words "two factor" is a statement about the security of a 
>> system, while it is in fact just a simple property. A property that even an 
>> inherently insecure and weak system can have.
>
> No, as I pointed out, you can have very weak security with two weak factors.
>
> However, the property two-factor means something and it’s not what you 
> apparently think.
>
>> It is not, as you have said, about strengthen the search space of a crypto 
>> key (just double the key length if you need that). In fact, many two factor 
>> systems do not use crypto keys at all. An example of such a non crypto based 
>> system is a credit card with magnetic strip plus pin. The magnetic strip 
>> contains just the card number, which can also be read directly from the card 
>> and even memorized by the owner.
>
> Actually, the magnetic stripe contains quite a bit more than the card number, 
> but that’s another tangent.
>
> I never said you had to have crypto for two-factor, nor did I say that two 
> factor magically made things stronger.
>
>> We need two factor because if you have just one factor, say the password, 
>> the hacker will simply call the user and ask him to tell the password. And 
>> the users will happily obligate. Experience shows this. On the other hand, 
>> if you give the users a single factor system with a physical token (a key), 
>> that gets stolen, misplaced or "borrowed" far too easily. Therefore industry 
>> standard is card + pin to enter a building (=two factor). Secure places 
>> require three factor (card + pin + biometric).
>
> Card+pin is an example of two factors… You _HAVE_ the card and you _KNOW_ the 
> PIN.
>
> Password-encrypted Key, OTOH, is something you _KNOW_ and something else you 
> _KNOW_. It’s not something you _HAVE_ or something you _ARE_.
>
> There are three generally accepted categories of Factors for authentication…
>
> 1.  Something you HAVE
> 2.  Something you KNOW
> 3.  Something you ARE
>
> In order to qualify as 2-factor, a system must require something from two of 
> the categories. Two things from the same category do not qualify.
>
>> SSH keys are two factor because people do not in general memorize the key 
>> file. Because they do not, you can not gain access to the system with only 
>> what you know (=in your mind). Unless the user violated protocols and 
>> changed the passphrase to null, you can not gain access just by possession 
>> of the key file. That is all that is required to name it two factor. That 
>> Owen DeLong believes the system stinks does not change that at all.
>
> Something on disk counts as something you know. A private/public key pair is 
> not something you HAVE because it’s not a physical object and it’s certainly 
> not something you ARE.
>
> It’s clearly in the something you KNOW category for all practical purposes, 
> even if you don’t memorize it into your mind.
>
> Now, a private key in black box where you feed it encrypted stuff to be 
> decrypted or decrypted stuff to be encrypted and you cannot extract the 
> private key, that could be something you HAVE.
> But at that point, it’s the black box that is the thing you have, not the key 
> itself. The key in the box and the boxes ability to decrypt/encrypt using 
> that key is merely a mechanism for proving
> that you have the correct black box.
>
>> Historically the

Re: de-peering for security sake

[Owen DeLong]

> On Dec 27, 2015, at 14:33 , Baldur Norddahl  wrote:
> 
> 
> 
> On 27 December 2015 at 22:08, Owen DeLong  > wrote:
> This is a bit of a tangent, really. The discussion was about authentication 
> factor
> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
> private key authentication as two-factor to bolster his claim that it was, in 
> fact
> two-factor, when it clearly isn’t actually two-factor as has been stated 
> previously.
> 
> I wanted to stay out of this, but Owen you are full of shit here. I am 
> pointing out that your homemade definition does not match up with what others 
> think two factor means. PCI DSS might be utter crap, but they are still more 
> than "Owen DeLong and his personal opinion”.

Dude… It’s not just my opinion. Virtually every one else who chimed in on the 
thread other than you backed my position on this.

> You are utterly confused about the meaning about two factor. You apparently 
> believe the magic words "two factor" is a statement about the security of a 
> system, while it is in fact just a simple property. A property that even an 
> inherently insecure and weak system can have. 

No, as I pointed out, you can have very weak security with two weak factors.

However, the property two-factor means something and it’s not what you 
apparently think.

> It is not, as you have said, about strengthen the search space of a crypto 
> key (just double the key length if you need that). In fact, many two factor 
> systems do not use crypto keys at all. An example of such a non crypto based 
> system is a credit card with magnetic strip plus pin. The magnetic strip 
> contains just the card number, which can also be read directly from the card 
> and even memorized by the owner.

Actually, the magnetic stripe contains quite a bit more than the card number, 
but that’s another tangent.

I never said you had to have crypto for two-factor, nor did I say that two 
factor magically made things stronger.

> We need two factor because if you have just one factor, say the password, the 
> hacker will simply call the user and ask him to tell the password. And the 
> users will happily obligate. Experience shows this. On the other hand, if you 
> give the users a single factor system with a physical token (a key), that 
> gets stolen, misplaced or "borrowed" far too easily. Therefore industry 
> standard is card + pin to enter a building (=two factor). Secure places 
> require three factor (card + pin + biometric).

Card+pin is an example of two factors… You _HAVE_ the card and you _KNOW_ the 
PIN.

Password-encrypted Key, OTOH, is something you _KNOW_ and something else you 
_KNOW_. It’s not something you _HAVE_ or something you _ARE_.

There are three generally accepted categories of Factors for authentication…

1.  Something you HAVE
2.  Something you KNOW
3.  Something you ARE

In order to qualify as 2-factor, a system must require something from two of 
the categories. Two things from the same category do not qualify.

> SSH keys are two factor because people do not in general memorize the key 
> file. Because they do not, you can not gain access to the system with only 
> what you know (=in your mind). Unless the user violated protocols and changed 
> the passphrase to null, you can not gain access just by possession of the key 
> file. That is all that is required to name it two factor. That Owen DeLong 
> believes the system stinks does not change that at all.

Something on disk counts as something you know. A private/public key pair is 
not something you HAVE because it’s not a physical object and it’s certainly 
not something you ARE.

It’s clearly in the something you KNOW category for all practical purposes, 
even if you don’t memorize it into your mind.

Now, a private key in black box where you feed it encrypted stuff to be 
decrypted or decrypted stuff to be encrypted and you cannot extract the private 
key, that could be something you HAVE.
But at that point, it’s the black box that is the thing you have, not the key 
itself. The key in the box and the boxes ability to decrypt/encrypt using that 
key is merely a mechanism for proving
that you have the correct black box.

> Historically the banks used to depend on a system that is the same as ssh 
> keys: certificate files you have on your computer to access the bank website. 
> That also is a two factor system. The users did not usually memorize the 
> content of the certificates. The system is weak because bad guys used malware 
> to steal the certificate files and install key loggers to also get the other 
> factor, the password. 

Again, real two-factor authentication depends on factors from different 
categories above. The certificate, like it or not, whether you memorize it or 
not, is something you KNOW, not something you HAVE.

To qualify as something you HAVE, it has to be a unique physical token with 
some degree of difficulty in duplication. Some physical 

Re: de-peering for security sake

[Baldur Norddahl]

On 27 December 2015 at 22:08, Owen DeLong  wrote:

> This is a bit of a tangent, really. The discussion was about
> authentication factor
> counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
> private key authentication as two-factor to bolster his claim that it was,
> in fact
> two-factor, when it clearly isn’t actually two-factor as has been stated
> previously.
>

I wanted to stay out of this, but Owen you are full of shit here. I am
pointing out that your homemade definition does not match up with what
others think two factor means. PCI DSS might be utter crap, but they are
still more than "Owen DeLong and his personal opinion".

You are utterly confused about the meaning about two factor. You apparently
believe the magic words "two factor" is a statement about the security of a
system, while it is in fact just a simple property. A property that even an
inherently insecure and weak system can have.

It is not, as you have said, about strengthen the search space of a crypto
key (just double the key length if you need that). In fact, many two factor
systems do not use crypto keys at all. An example of such a non crypto
based system is a credit card with magnetic strip plus pin. The magnetic
strip contains just the card number, which can also be read directly from
the card and even memorized by the owner.

We need two factor because if you have just one factor, say the password,
the hacker will simply call the user and ask him to tell the password. And
the users will happily obligate. Experience shows this. On the other hand,
if you give the users a single factor system with a physical token (a key),
that gets stolen, misplaced or "borrowed" far too easily. Therefore
industry standard is card + pin to enter a building (=two factor). Secure
places require three factor (card + pin + biometric).

SSH keys are two factor because people do not in general memorize the key
file. Because they do not, you can not gain access to the system with only
what you know (=in your mind). Unless the user violated protocols and
changed the passphrase to null, you can not gain access just by possession
of the key file. That is all that is required to name it two factor. That
Owen DeLong believes the system stinks does not change that at all.

Historically the banks used to depend on a system that is the same as ssh
keys: certificate files you have on your computer to access the bank
website. That also is a two factor system. The users did not usually
memorize the content of the certificates. The system is weak because bad
guys used malware to steal the certificate files and install key loggers to
also get the other factor, the password.

In my country (Denmark) they decided hardware keys are still too expensive,
so they developed a two factor system based on paper keys. You will get a
piece of paper with a few hundred random numbers. When you log in, you are
asked to type one of the numbers in to prove that you are in possession of
the key paper. The codes are just 6 digits and infinite weak if you believe
them to be part of any crypto scheme. This system has also been broken
because now bad guys ask the users to take pictures of the key paper to
prove something, and the users happily do just that. Banks are still happy
though, because the loss is less than the cost to ship hardware keys to
everyone.

Only strong two factor systems are really resistant to the users defeating
the system by doing stupid things. That does not mean that only strong two
factor systems are two factor. That would be silly - Owen what would you
then name weak and broken two factor systems? It is a property - nothing
more.

Regards,

Baldur

Re: de-peering for security sake

[Owen DeLong]

> On Dec 27, 2015, at 11:26 , Christopher Morrow  
> wrote:
> 
> On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>> 
>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>> yes it is in fact two factor.
>> 
>> They also accept NAT as "security".  If anything, PCI DSS is yet another 
>> example
>> of a money grab masquerading as security theater (not even real security).
> 
> is it that? or is it that once you click the checkboxes on /pci audit/
> 'no one' ever does the daily due-diligence required to keep their
> security processes updated/running/current/etc ?

You ask this as if those two were mutually exclusive. They are not. I believe
that both are actually true. The PCI-DSS checklist can be completed without
relatively weak security and involves a lot of theatrical requirements that have
nothing to do with actual security.

Beyond that, yes, most organizations survive the audit and then go back to
ignore it until time for the next audit mode.

> I'm not a fan of the compliance regimes, but their goal (in a utopian
> world where corporations are not people and such) is the equivalent of
> the little posterboard person 42" tall before the roller-coaster
> rides, right?
> 
> "You really, REALLY should have at least these protections/systems/etc
> in place before you attempt to process credit-card transactions…"

Right. And that’s a decent goal. Unfortunately, if you read the actual document,
the standards require lots of things that don’t actually improve (and in some
cases can actually degrade) security, such as NAT.

> In the utopian world this list would be sane, useful and would include
> daily/etc processes to monitor the security controls for issues... I
> don't think there's a process bit in PCI about: "And joey the firewall
> admin looks at his logs daily/hourly/everly for evidence of
> compromise" (and yes, ideally there's some adaptive/learning/AI-like
> system that does the 'joey the firewall admin' step... but let's walk
> before running, eh?)

Yeah, it doesn’t actually require anyone or anything to ever really look at
logs at all.

> so, it's not really a mystery why failures like this happen.

This is a bit of a tangent, really. The discussion was about authentication 
factor
counts and Baldur tried to use PCI-DSS acceptance of password-encrypted
private key authentication as two-factor to bolster his claim that it was, in 
fact
two-factor, when it clearly isn’t actually two-factor as has been stated 
previously.

The comments about PCI-DSS being a non-credible standard were primarily
an additional note that his argument was built on thin air.

>> I remember seeing a story a while ago that stated that of companies hit
>> by a data breach on a system that was inside their PCI scope, something
>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>> the breach.  The only conclusion to be drawn is that the PCI set of 
>> checkboxes
>> are missing a lot of really crucial things for real security.  (And let's
>> not forget the competence level of the average PCI auditor, as the ones
>> I've encountered have all been very nice people, but more suited to checking
>> boxes based on buzzwords than actual in-deopth security analysis).
> 
> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
> guilty of this i'm sure as well, but really ... if you put systems on
> the tubes and you don't take the same care you would for your
> brick/mortar places ... you're gonna have a bad day. 'cyber security'
> really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security.

Conceptually, sure. However, in actual implementation, there’s a plethora of
decent locksmiths and reasonably good security contractors out there to provide
good solutions for physical security.

In the cyber security world, the waters are a lot murkier. There are no good
standards to allow a lay person to identify a good capable contractor vs. a
charlatan with a flashy web site. Most of the widely known standards are
crap. I’ve met some really good CISSPs in my day, but I’ve also met a number
of people touting their CISSP certification who don’t realize that NAT is 
actually
detrimental to security and a few who even claimed that NAT was good.

Several couldn’t even get the concept of separating NAT from stateful inspection
after repeated attempts to explain it to them in kindergarten terms.

Cyber security is a lot harder to understand well and quite a bit more 
complicated
than physical security.

Owen

Re: de-peering for security sake

[Mike Hale]

"please cite useful numbers"

For what?  IDS?  SIEM?  Log aggregation in general?  For companies
that have none of that, spinning up the best practice systems can
easily cost half a mil a year (QRadar is 200k for our sized
environment; a good netflow system is like 50 [100k+ for something
like Lancope], one FTE to support and manage this as and additional
workload on server and network guys in dealing with issues these tools
find).  And that's just the tip of the iceberg.  An additional 500k a
year is tough to justify (and costs way, way more than simply locking
the doors or hiring a team of security guards at 10 an hour).
Simplistic, of course, but one example of the cost difference.

"Sure it's a new expense (not really, since ... you've always had
security costs) but it's not 'massive'."

Depends on the organization.  For those who don't have a
security-specific team, it is new spend.

"ideally you need 2-3 people (for a larger operation, less for small
shops) with a bunch of automation to help things run along."

Absolutely agree.  So we're looking at 200-300k just in pure salary
cost, plus what, 40% extra for various benefits?

That automation piece too is incredibly pricey (either in time and
labor of software).

"though the parts aren't quite in place today :(
which is sad."

One hundred percent in agreement.  This is much, much harder for the
smaller organizations to take.  I wish there were services that made
this way easier.  I think this is where small system integrators could
partner with security services that provide tier one security response
(something like arctic wolf) and provide that needed coverage...but
that's not inexpensive either (though way cheaper than hiring your own
security dudes).

"the return is not having to fend off the WSJ reporters of the world,
and consequent lawsuits from your customers, subscribers, partners,
etc..."

True.  But how do you put that in money terms?

Obviously, I think the spend is absolutely important, and it's
something that is vitally important to the business.  But I've found
it very challenging in making that case in a way that works, precisely
because of that increased amount of spending.

"but that is changing as more and more get
pwned and the public and legal costs become greater and more apparent.
patience."

It is.  Sony and Target were really useful in that regard.

On Sun, Dec 27, 2015 at 12:51 PM, Christopher Morrow
 wrote:
> On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale  wrote:
>> "done right the cost shouldn't be super much more."
>> I disagree.  Done wrong, it's not super much more.
>>
>> Done right, it's massively more.
>
> please cite useful numbers... It's not (I think) really all that much
> more. Sure it's a new expense (not really, since ... you've always had
> security costs) but it's not 'massive'.
>
>> Like Randy said, compare salaries alone.  A good security employee
>> will run you, what, 100k or more in the major job markets?  And how
>> many do you need, full time, to provide acceptable coverage for your
>> environment?
>>
>
> ideally you need 2-3 people (for a larger operation, less for small
> shops) with a bunch of automation to help things run along. Ideally
> your 2-3 experts aren't responding to the pager, almost all of that is
> offloaded to your noc/etc staff in a manner that they can actually
> deal with problems NOT as pager-spam which gets turned off. 'high
> quality alerts' with actionable playbooks.
>
> it'd be great if more of this was COTS-able for the smaller shops... I
> bet a bunch of it IS, though the parts aren't quite in place today :(
> which is sad.
>
>> The costs add up really fast without a corresponding return.
>
> the return is not having to fend off the WSJ reporters of the world,
> and consequent lawsuits from your customers, subscribers, partners,
> etc...
>
> -chris
>
>> On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
>>  wrote:
>>> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale  
>>> wrote:
 "really isn't a whole lot different from 'lock your damned doors and
 windows' brick/mortar security."

 Except it's *massively* more expensive.

>>>
>>> is it? how much does a datacenter pay for people + locks + card-key +
>>> pin-pad + ...
>>>
>>> vs
>>>
>>>  the requisite bits for security their customer portal/backoffice/etc ?
>>>
>>> done right the cost shouldn't be super much more.
>>>
>>> -chris
>>>
 On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
  wrote:
> On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>
>>> SSH password + key file is accepted as two factor by PCI DSS auditors, 
>>> so
>>> yes it is in fact two factor.
>>
>> They also accept NAT as "security".  If anything, PCI DSS is yet another 
>> example
>> of a money grab masquerading as security theater (not even real 
>> security).
>
> is it that? or is it that once you click the checkboxes on /pci audi

Re: de-peering for security sake

[Christopher Morrow]

On Sun, Dec 27, 2015 at 3:32 PM, Mike Hale  wrote:
> "done right the cost shouldn't be super much more."
> I disagree.  Done wrong, it's not super much more.
>
> Done right, it's massively more.

please cite useful numbers... It's not (I think) really all that much
more. Sure it's a new expense (not really, since ... you've always had
security costs) but it's not 'massive'.

> Like Randy said, compare salaries alone.  A good security employee
> will run you, what, 100k or more in the major job markets?  And how
> many do you need, full time, to provide acceptable coverage for your
> environment?
>

ideally you need 2-3 people (for a larger operation, less for small
shops) with a bunch of automation to help things run along. Ideally
your 2-3 experts aren't responding to the pager, almost all of that is
offloaded to your noc/etc staff in a manner that they can actually
deal with problems NOT as pager-spam which gets turned off. 'high
quality alerts' with actionable playbooks.

it'd be great if more of this was COTS-able for the smaller shops... I
bet a bunch of it IS, though the parts aren't quite in place today :(
which is sad.

> The costs add up really fast without a corresponding return.

the return is not having to fend off the WSJ reporters of the world,
and consequent lawsuits from your customers, subscribers, partners,
etc...

-chris

> On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
>  wrote:
>> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale  wrote:
>>> "really isn't a whole lot different from 'lock your damned doors and
>>> windows' brick/mortar security."
>>>
>>> Except it's *massively* more expensive.
>>>
>>
>> is it? how much does a datacenter pay for people + locks + card-key +
>> pin-pad + ...
>>
>> vs
>>
>>  the requisite bits for security their customer portal/backoffice/etc ?
>>
>> done right the cost shouldn't be super much more.
>>
>> -chris
>>
>>> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>>>  wrote:
 On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>
>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>> yes it is in fact two factor.
>
> They also accept NAT as "security".  If anything, PCI DSS is yet another 
> example
> of a money grab masquerading as security theater (not even real security).

 is it that? or is it that once you click the checkboxes on /pci audit/
 'no one' ever does the daily due-diligence required to keep their
 security processes updated/running/current/etc ?

 I'm not a fan of the compliance regimes, but their goal (in a utopian
 world where corporations are not people and such) is the equivalent of
 the little posterboard person 42" tall before the roller-coaster
 rides, right?

 "You really, REALLY should have at least these protections/systems/etc
 in place before you attempt to process credit-card transactions..."

 In the utopian world this list would be sane, useful and would include
 daily/etc processes to monitor the security controls for issues... I
 don't think there's a process bit in PCI about: "And joey the firewall
 admin looks at his logs daily/hourly/everly for evidence of
 compromise" (and yes, ideally there's some adaptive/learning/AI-like
 system that does the 'joey the firewall admin' step... but let's walk
 before running, eh?)

 so, it's not really a mystery why failures like this happen.

> I remember seeing a story a while ago that stated that of companies hit
> by a data breach on a system that was inside their PCI scope, something
> insane like 98% or 99% were in 100% full PCI compliance at the time of
> the breach.  The only conclusion to be drawn is that the PCI set of 
> checkboxes
> are missing a lot of really crucial things for real security.  (And let's
> not forget the competence level of the average PCI auditor, as the ones
> I've encountered have all been very nice people, but more suited to 
> checking
> boxes based on buzzwords than actual in-deopth security analysis).

 people toss pci/sox/etc auditors under the bus 'all the time', and i'm
 guilty of this i'm sure as well, but really ... if you put systems on
 the tubes and you don't take the same care you would for your
 brick/mortar places ... you're gonna have a bad day. 'cyber security'
 really isn't a whole lot different from 'lock your damned doors and
 windows' brick/mortar security.

> So excuse me for not taking "is accepted by PCI auditors" as grounds for
> a claim of strong actual security.
>>>
>>>
>>>
>>> --
>>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: de-peering for security sake

[Randy Bush]

> The costs add up really fast without a corresponding return.

i think there is a corresponding return, just not one that is perceived
by the pointy heads.  yet.  but that is changing as more and more get
pwned and the public and legal costs become greater and more apparent.
patience.

randy

Re: de-peering for security sake

[Mike Hale]

"done right the cost shouldn't be super much more."
I disagree.  Done wrong, it's not super much more.

Done right, it's massively more.

Like Randy said, compare salaries alone.  A good security employee
will run you, what, 100k or more in the major job markets?  And how
many do you need, full time, to provide acceptable coverage for your
environment?

The costs add up really fast without a corresponding return.



On Sun, Dec 27, 2015 at 12:27 PM, Christopher Morrow
 wrote:
> On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale  wrote:
>> "really isn't a whole lot different from 'lock your damned doors and
>> windows' brick/mortar security."
>>
>> Except it's *massively* more expensive.
>>
>
> is it? how much does a datacenter pay for people + locks + card-key +
> pin-pad + ...
>
> vs
>
>  the requisite bits for security their customer portal/backoffice/etc ?
>
> done right the cost shouldn't be super much more.
>
> -chris
>
>> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>>  wrote:
>>> On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
 On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:

> SSH password + key file is accepted as two factor by PCI DSS auditors, so
> yes it is in fact two factor.

 They also accept NAT as "security".  If anything, PCI DSS is yet another 
 example
 of a money grab masquerading as security theater (not even real security).
>>>
>>> is it that? or is it that once you click the checkboxes on /pci audit/
>>> 'no one' ever does the daily due-diligence required to keep their
>>> security processes updated/running/current/etc ?
>>>
>>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>>> world where corporations are not people and such) is the equivalent of
>>> the little posterboard person 42" tall before the roller-coaster
>>> rides, right?
>>>
>>> "You really, REALLY should have at least these protections/systems/etc
>>> in place before you attempt to process credit-card transactions..."
>>>
>>> In the utopian world this list would be sane, useful and would include
>>> daily/etc processes to monitor the security controls for issues... I
>>> don't think there's a process bit in PCI about: "And joey the firewall
>>> admin looks at his logs daily/hourly/everly for evidence of
>>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>>> system that does the 'joey the firewall admin' step... but let's walk
>>> before running, eh?)
>>>
>>> so, it's not really a mystery why failures like this happen.
>>>
 I remember seeing a story a while ago that stated that of companies hit
 by a data breach on a system that was inside their PCI scope, something
 insane like 98% or 99% were in 100% full PCI compliance at the time of
 the breach.  The only conclusion to be drawn is that the PCI set of 
 checkboxes
 are missing a lot of really crucial things for real security.  (And let's
 not forget the competence level of the average PCI auditor, as the ones
 I've encountered have all been very nice people, but more suited to 
 checking
 boxes based on buzzwords than actual in-deopth security analysis).
>>>
>>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>>> guilty of this i'm sure as well, but really ... if you put systems on
>>> the tubes and you don't take the same care you would for your
>>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>>> really isn't a whole lot different from 'lock your damned doors and
>>> windows' brick/mortar security.
>>>
 So excuse me for not taking "is accepted by PCI auditors" as grounds for
 a claim of strong actual security.
>>
>>
>>
>> --
>> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: de-peering for security sake

[Christopher Morrow]

On Sun, Dec 27, 2015 at 2:49 PM, Mike Hale  wrote:
> "really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security."
>
> Except it's *massively* more expensive.
>

is it? how much does a datacenter pay for people + locks + card-key +
pin-pad + ...

vs

 the requisite bits for security their customer portal/backoffice/etc ?

done right the cost shouldn't be super much more.

-chris

> On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
>  wrote:
>> On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
>>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>>
 SSH password + key file is accepted as two factor by PCI DSS auditors, so
 yes it is in fact two factor.
>>>
>>> They also accept NAT as "security".  If anything, PCI DSS is yet another 
>>> example
>>> of a money grab masquerading as security theater (not even real security).
>>
>> is it that? or is it that once you click the checkboxes on /pci audit/
>> 'no one' ever does the daily due-diligence required to keep their
>> security processes updated/running/current/etc ?
>>
>> I'm not a fan of the compliance regimes, but their goal (in a utopian
>> world where corporations are not people and such) is the equivalent of
>> the little posterboard person 42" tall before the roller-coaster
>> rides, right?
>>
>> "You really, REALLY should have at least these protections/systems/etc
>> in place before you attempt to process credit-card transactions..."
>>
>> In the utopian world this list would be sane, useful and would include
>> daily/etc processes to monitor the security controls for issues... I
>> don't think there's a process bit in PCI about: "And joey the firewall
>> admin looks at his logs daily/hourly/everly for evidence of
>> compromise" (and yes, ideally there's some adaptive/learning/AI-like
>> system that does the 'joey the firewall admin' step... but let's walk
>> before running, eh?)
>>
>> so, it's not really a mystery why failures like this happen.
>>
>>> I remember seeing a story a while ago that stated that of companies hit
>>> by a data breach on a system that was inside their PCI scope, something
>>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>>> the breach.  The only conclusion to be drawn is that the PCI set of 
>>> checkboxes
>>> are missing a lot of really crucial things for real security.  (And let's
>>> not forget the competence level of the average PCI auditor, as the ones
>>> I've encountered have all been very nice people, but more suited to checking
>>> boxes based on buzzwords than actual in-deopth security analysis).
>>
>> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
>> guilty of this i'm sure as well, but really ... if you put systems on
>> the tubes and you don't take the same care you would for your
>> brick/mortar places ... you're gonna have a bad day. 'cyber security'
>> really isn't a whole lot different from 'lock your damned doors and
>> windows' brick/mortar security.
>>
>>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>>> a claim of strong actual security.
>
>
>
> --
> 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: de-peering for security sake

[Randy Bush]

> 'cyber security' really isn't a whole lot different from 'lock your
> damned doors and windows' brick/mortar security.

hellofalot more holes to cover.  and the salaries of the guards are a
bit higher for the net; so more incentive for pointy heads to skimp.

randy

Re: de-peering for security sake

[Mike Hale]

"really isn't a whole lot different from 'lock your damned doors and
windows' brick/mortar security."

Except it's *massively* more expensive.

On Sun, Dec 27, 2015 at 11:26 AM, Christopher Morrow
 wrote:
> On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
>> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>>
>>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>>> yes it is in fact two factor.
>>
>> They also accept NAT as "security".  If anything, PCI DSS is yet another 
>> example
>> of a money grab masquerading as security theater (not even real security).
>
> is it that? or is it that once you click the checkboxes on /pci audit/
> 'no one' ever does the daily due-diligence required to keep their
> security processes updated/running/current/etc ?
>
> I'm not a fan of the compliance regimes, but their goal (in a utopian
> world where corporations are not people and such) is the equivalent of
> the little posterboard person 42" tall before the roller-coaster
> rides, right?
>
> "You really, REALLY should have at least these protections/systems/etc
> in place before you attempt to process credit-card transactions..."
>
> In the utopian world this list would be sane, useful and would include
> daily/etc processes to monitor the security controls for issues... I
> don't think there's a process bit in PCI about: "And joey the firewall
> admin looks at his logs daily/hourly/everly for evidence of
> compromise" (and yes, ideally there's some adaptive/learning/AI-like
> system that does the 'joey the firewall admin' step... but let's walk
> before running, eh?)
>
> so, it's not really a mystery why failures like this happen.
>
>> I remember seeing a story a while ago that stated that of companies hit
>> by a data breach on a system that was inside their PCI scope, something
>> insane like 98% or 99% were in 100% full PCI compliance at the time of
>> the breach.  The only conclusion to be drawn is that the PCI set of 
>> checkboxes
>> are missing a lot of really crucial things for real security.  (And let's
>> not forget the competence level of the average PCI auditor, as the ones
>> I've encountered have all been very nice people, but more suited to checking
>> boxes based on buzzwords than actual in-deopth security analysis).
>
> people toss pci/sox/etc auditors under the bus 'all the time', and i'm
> guilty of this i'm sure as well, but really ... if you put systems on
> the tubes and you don't take the same care you would for your
> brick/mortar places ... you're gonna have a bad day. 'cyber security'
> really isn't a whole lot different from 'lock your damned doors and
> windows' brick/mortar security.
>
>> So excuse me for not taking "is accepted by PCI auditors" as grounds for
>> a claim of strong actual security.



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0

Re: de-peering for security sake

[Christopher Morrow]

On Sun, Dec 27, 2015 at 1:59 PM,   wrote:
> On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:
>
>> SSH password + key file is accepted as two factor by PCI DSS auditors, so
>> yes it is in fact two factor.
>
> They also accept NAT as "security".  If anything, PCI DSS is yet another 
> example
> of a money grab masquerading as security theater (not even real security).

is it that? or is it that once you click the checkboxes on /pci audit/
'no one' ever does the daily due-diligence required to keep their
security processes updated/running/current/etc ?

I'm not a fan of the compliance regimes, but their goal (in a utopian
world where corporations are not people and such) is the equivalent of
the little posterboard person 42" tall before the roller-coaster
rides, right?

"You really, REALLY should have at least these protections/systems/etc
in place before you attempt to process credit-card transactions..."

In the utopian world this list would be sane, useful and would include
daily/etc processes to monitor the security controls for issues... I
don't think there's a process bit in PCI about: "And joey the firewall
admin looks at his logs daily/hourly/everly for evidence of
compromise" (and yes, ideally there's some adaptive/learning/AI-like
system that does the 'joey the firewall admin' step... but let's walk
before running, eh?)

so, it's not really a mystery why failures like this happen.

> I remember seeing a story a while ago that stated that of companies hit
> by a data breach on a system that was inside their PCI scope, something
> insane like 98% or 99% were in 100% full PCI compliance at the time of
> the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
> are missing a lot of really crucial things for real security.  (And let's
> not forget the competence level of the average PCI auditor, as the ones
> I've encountered have all been very nice people, but more suited to checking
> boxes based on buzzwords than actual in-deopth security analysis).

people toss pci/sox/etc auditors under the bus 'all the time', and i'm
guilty of this i'm sure as well, but really ... if you put systems on
the tubes and you don't take the same care you would for your
brick/mortar places ... you're gonna have a bad day. 'cyber security'
really isn't a whole lot different from 'lock your damned doors and
windows' brick/mortar security.

> So excuse me for not taking "is accepted by PCI auditors" as grounds for
> a claim of strong actual security.

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sun, 27 Dec 2015 05:35:19 +0100, Baldur Norddahl said:

> SSH password + key file is accepted as two factor by PCI DSS auditors, so
> yes it is in fact two factor.

They also accept NAT as "security".  If anything, PCI DSS is yet another example
of a money grab masquerading as security theater (not even real security).
I remember seeing a story a while ago that stated that of companies hit
by a data breach on a system that was inside their PCI scope, something
insane like 98% or 99% were in 100% full PCI compliance at the time of
the breach.  The only conclusion to be drawn is that the PCI set of checkboxes
are missing a lot of really crucial things for real security.  (And let's
not forget the competence level of the average PCI auditor, as the ones
I've encountered have all been very nice people, but more suited to checking
boxes based on buzzwords than actual in-deopth security analysis).

So excuse me for not taking "is accepted by PCI auditors" as grounds for
a claim of strong actual security.


pgpXtWYoHA6th.pgp
Description: PGP signature

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 20:35 , Baldur Norddahl  wrote:
> 
> Owen you misunderstood what two factor is about. It is not practical to
> brute force the key file. Nor is it practical to brute force a good
> passphrase or password. Both have sufficient strength to withstand attack.

This simply isn’t as true as it’s assumed to be, but let’s move on for the 
moment.

> But two factor is about having two things that needs to be broken. The key
> can be stolen, but the thief needs the password. The password can be
> stolen, but the thief needs the key. He needs both.

If the key file is stolen, you have one search space, the pass phrase to unlock 
the key.

If the key file is not stolen, you have one search space: the key.

> SSH password + key file is accepted as two factor by PCI DSS auditors, so
> yes it is in fact two factor.

PCI DSS auditors think that NAT is a form of security, so don’t get me started 
on the
fact that the PCI DSS auditors haven’t a clue about actual security. PCI DSS is 
more
about security theater than security. In some ways, they’re even less competent 
than
the TSA.

> But it is weak two factor because the key file is too easily stolen. NOT
> because the key file can be brute forced. Nor because hypothetically
> someone could memorize the content of the key file.

Either way, you only have one search space. If you don’t have the key file, 
then the
key is your search space. If you have the key file, then the passphrase may be 
an
easier search space.

> It is also weak because the key file can be duplicated. Note it does not
> stop being two factor because of this, but stronger hardware based two
> factor systems usually come with the property that it is very hard to
> duplicate the key. Other examples of a two factor system were the key is
> easy to duplicate is credit card with magnetic strip + pin. Example where
> it is hard to duplicate is credit card with chip + pin. Both are examples
> of where the password (the pin) is actually very weak, but it is still two
> factor.

To actually be two-factor, it needs to be two of something you have, something
you know, something you are. The strongest combination is something you know
and something you are (e.g. Retina, hand scan, etc. combined with PIN/Password).

SSH Key protected by pass phrase is just two things you know. Admittedly, one
of them is a thing you know because you stored it on disk instead of memorizing
it, but it’s not really something you have because as you pointed out, it can be
easily duplicated and also it can be transported without requiring physical
movement.

Something you have, in order to truly be a second factor, has to be a unique
item that is:
1.  In your possession
2.  Cannot be (easily) duplicated without your knowledge
(The greater the degree of difficulty for duplication, the 
better this is,
but a Schlage key, for example, is sufficiently difficult to 
qualify in most
cases).
3.  Theft can be reliably detected by the fact it is no longer in 
your possession.

An RSA or DSA key does not meet those criteria because it can be copied without
your knowledge and without removing the key from your possession.

> Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
> fact have a strength equal to 1024 bits entropy. It was considered equal to
> about 128 bit of entropy, but is believed to be weaker now. I am using ECC
> ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
> with tin foil hats believe we should stay away from NIST altogether. Unless
> someone breaks the crypto, you are NOT going to brute force that key.

I think you’re the first person to bring up 1024 RSA keys here. I only said 
private
keys. A very large fraction of SSH users are still using 1024 bit DSA keys in 
the
real world. I am still using 2048 bit DSA keys. ECC would be better.

I also didn’t say that a 1024 bit key had 1024 bits of entropy. I said that a 
1024
bit key and a 256-character pass phrase have about the same entropy. There
are about 128 bits of entropy in a good 256 character pass phrase. There are
about 128 bits of entropy in a 1024 bit DSA key.

> Yes I get your argument, you are saying break the key and you won't need
> the password, but a) you can't actually break the key before the universe
> ends, b) it is still two factor, just a extremely tiny in the academic

If you have enough cheap GPUs, you can actually break a 1024 bit key
well before the universe ends. In fact, you can probably break it before
the end of 2016 if you’re willing to put about $30k into the process.

> sense little bit weaker two factor. All crypto based two factor systems

No, it’s not a second factor. See above… It’s two things you know and not
something you have and something you know as you have claimed.

Calling a private key something you have instead of something you know
is the same kind of slight of hand that Wall St

Re: de-peering for security sake

[Colin Johnston]

interesting:)
but useful to make a attempt at cleaning up traffic from china and russia

colin

Sent from my iPhone

> On 27 Dec 2015, at 06:32, Hugo Slabbert  wrote:
> 
>> On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian 
>>  wrote:
>> 
>> Hmm, has anyone at all kept count of the number of times such a discussion 
>> has started up in just the last year...
> 
> Not on an ongoing basis, but I was curious as well, so a quick mailbox search 
> for 2015:
> 
> http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
> subject: Facebook outage?
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
> subject: AOL Postmaster
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
> http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
> subject: Getting hit hard by CHINANET
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
> subject: BGP offloading (fixing legacy router BGP scalability issues)
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
> subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 24 
> hours
> author: Colin Johnston 
> 
> http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
> subject: de-peering for security sake
> author: Colin Johnston 
> 
> I tried to be pretty wide in the search and filter through a decent chunk of 
> false positives manually, though of course I could have missed some.  It does 
> skip a few of the "all of their traffic is crap and abuse reports are 
> ignored" messages that don't *explicitly* call for wholesale country-level 
> blocks or de-peering.
> 
>> ...and how many more times in the past 16 or so years?
> 
> I was curious, but not masochistic ;)
> 
> -- 
> Hugo
> 
> h...@slabnet.com: email, xmpp/jabber
> PGP fingerprint (B178313E):
> CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E
> 
> (also on textsecure & redphone)
> 
> 
>> 
>> Mind you, back in say 2004, this discussion would have run to 50 or 60 
>> emails at a bare minimum, in no time at all.
>> 
>> --srs
>> 
>> On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:
>> 
>>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>>> Let’s just cut off the entirety of the third world instead of having
>>>> a tangible mitigation plan in place.
>>> 
>>> While you thing you are making a snarky response, it would be handy for end 
>>> users to be able to turn on and off access to other countries retail.

Re: de-peering for security sake

[Hugo Slabbert]

On Fri 2015-Dec-25 08:55:24 +0530, Suresh Ramasubramanian  
wrote:


Hmm, has anyone at all kept count of the number of times such a discussion has 
started up in just the last year...


Not on an ongoing basis, but I was curious as well, so a quick mailbox 
search for 2015:


http://mailman.nanog.org/pipermail/nanog/2015-January/072841.html
subject: Facebook outage?
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-February/073556.html
subject: AOL Postmaster
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-March/074251.html
http://mailman.nanog.org/pipermail/nanog/2015-March/074241.html
subject: Getting hit hard by CHINANET
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-April/074432.html
subject: BGP offloading (fixing legacy router BGP scalability issues)
author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-July/077790.html
subject: 20-30Gbps UDP 1720 traffic appearing to originate from CN in last 
24 hours

author: Colin Johnston 

http://mailman.nanog.org/pipermail/nanog/2015-December/083104.html
subject: de-peering for security sake
author: Colin Johnston 

I tried to be pretty wide in the search and filter through a decent chunk 
of false positives manually, though of course I could have missed some.  It 
does skip a few of the "all of their traffic is crap and abuse reports are 
ignored" messages that don't *explicitly* call for wholesale country-level 
blocks or de-peering.



...and how many more times in the past 16 or so years?


I was curious, but not masochistic ;)

--
Hugo

h...@slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on textsecure & redphone)




Mind you, back in say 2004, this discussion would have run to 50 or 60 emails 
at a bare minimum, in no time at all.

--srs

On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:


On 12/24/2015 04:50 PM, Daniel Corbe wrote:
Let’s just cut off the entirety of the third world instead of having
a tangible mitigation plan in place.


While you thing you are making a snarky response, it would be handy for end 
users to be able to turn on and off access to other countries retail.


signature.asc
Description: PGP signature

Re: de-peering for security sake

[Damian Menscher via NANOG]

On Sat, Dec 26, 2015 at 10:06 PM, Matthew Petach 
wrote:

> Thanks for the reminder to look at it from multiple perspectives.
>

The key attribute missing from the discussion so far is that the factors be
*different*, from the set of:
  - something you know (password / PIN)
  - something you have (keyfob / OTP generator / chip)
  - something you are (fingerprint / retina scan)

Claiming a passphrase and key are two "factors" is missing the point --
they both come from the same set (a secret which could be cloned).  If you
believe those are two factors then a password alone is 10 factors (one for
each character)! ;)

Damian

Re: de-peering for security sake

[Matthew Petach]

On Sat, Dec 26, 2015 at 6:37 PM, Owen DeLong  wrote:
>> On Dec 26, 2015, at 15:54 , Baldur Norddahl  
>> wrote:
>>
[...]

>> The key approach is still better. Even if the password is 123456 the
>> attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect… It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of 
> entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do not 
> need
> the passphrase for the on-disk key. As was pointed out elsewhere, the 
> passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass 
> phrase, the
> difficulty is roughly equivalent.

Intriguing point.   I was thinking about it
from the end-user perspective; but you're
right, from the bits-on-the-wire perspective,
it's all just a stream of 1's and 0's, whether
it came from a private key + passphrase
run through an algorithm or not.

Thanks for the reminder to look at it from
multiple perspectives.  ^_^


Matt

Re: de-peering for security sake

[Baldur Norddahl]

Owen you misunderstood what two factor is about. It is not practical to
brute force the key file. Nor is it practical to brute force a good
passphrase or password. Both have sufficient strength to withstand attack.

But two factor is about having two things that needs to be broken. The key
can be stolen, but the thief needs the password. The password can be
stolen, but the thief needs the key. He needs both.

SSH password + key file is accepted as two factor by PCI DSS auditors, so
yes it is in fact two factor.

But it is weak two factor because the key file is too easily stolen. NOT
because the key file can be brute forced. Nor because hypothetically
someone could memorize the content of the key file.

It is also weak because the key file can be duplicated. Note it does not
stop being two factor because of this, but stronger hardware based two
factor systems usually come with the property that it is very hard to
duplicate the key. Other examples of a two factor system were the key is
easy to duplicate is credit card with magnetic strip + pin. Example where
it is hard to duplicate is credit card with chip + pin. Both are examples
of where the password (the pin) is actually very weak, but it is still two
factor.

Btw, you should not be using RSA anymore and a 1024 bit RSA key does not in
fact have a strength equal to 1024 bits entropy. It was considered equal to
about 128 bit of entropy, but is believed to be weaker now. I am using ECC
ecdsa-sha2-nistp521 which is equal to about 256 bits. Although some people
with tin foil hats believe we should stay away from NIST altogether. Unless
someone breaks the crypto, you are NOT going to brute force that key.

Yes I get your argument, you are saying break the key and you won't need
the password, but a) you can't actually break the key before the universe
ends, b) it is still two factor, just a extremely tiny in the academic
sense little bit weaker two factor. All crypto based two factor systems
suffers from the possibility that one could break the crypto and possibly
escape the need to know one or even both factors. But Owen - come one -
this silly argument pales and is so infinite insignificant to the real
problem with the ssh key two factor system, which is that the key is easily
stolen and duplicated and there is no way to check the quality of the
password (users might even change the key password to NO password).

Regards,

Baldur


On 27 December 2015 at 03:37, Owen DeLong  wrote:

>
> > On Dec 26, 2015, at 15:54 , Baldur Norddahl 
> wrote:
> >
> > On 27 December 2015 at 00:11, Owen DeLong  wrote:
> >
> >> No… You are missing the point. Guessing a private key is roughly
> >> equivalent to guessing a really long
> >> pass phrase. There is no way that the server side can enforce password
> >> protection of the private key
> >> on the client side, so if you are assuming that public-key
> authentication
> >> is two-factor, then you are
> >> failing miserably.
> >>
> >
> > The key approach is still better. Even if the password is 123456 the
> > attacker is not going to get in, unless he somehow stole the key file.
>
> Incorrect… It is possible the attacker could brute-force the key file.
>
> A 1024 bit key is only as good as a ~256 character passphrase in terms of
> entropy.
>
> If you are brute force or otherwise synthesizing the private key, you do
> not need
> the passphrase for the on-disk key. As was pointed out elsewhere, the
> passphrase
> for the key file only matters if you already stole the key file.
>
> In terms of guessing the private key vs. guessing a suitably long pass
> phrase, the
> difficulty is roughly equivalent.
>
> > Technically it is two-factor even if the user made one of the factors
> > really easy. And that might save the day if you have users that chooses
> bad
> > passwords.
>
> Technically it’s not two-factor and pretending it is is dangerous.
>
> > The system is weak in that it is too easy to steal the key file. It is
> not
> > unlikely that a user with sloppy passwords is also sloppy with his key
> file.
>
> Right… No matter what you do it is virtually impossible to protect against
> sloppy
> users.
>
> This has been true for decades even before the internet with teenagers
> given house
> keys.
>
> > Too bad ssh does not generally support a challenge-response protocol to a
> > write only hardware key device combined with server side passwords that
> can
> > be checked against a blacklist.
>
> There’s no reason that it can’t if you use PAM.
>
> Owen
>
>

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 15:54 , Baldur Norddahl  wrote:
> 
> On 27 December 2015 at 00:11, Owen DeLong  wrote:
> 
>> No… You are missing the point. Guessing a private key is roughly
>> equivalent to guessing a really long
>> pass phrase. There is no way that the server side can enforce password
>> protection of the private key
>> on the client side, so if you are assuming that public-key authentication
>> is two-factor, then you are
>> failing miserably.
>> 
> 
> The key approach is still better. Even if the password is 123456 the
> attacker is not going to get in, unless he somehow stole the key file.

Incorrect… It is possible the attacker could brute-force the key file.

A 1024 bit key is only as good as a ~256 character passphrase in terms of 
entropy.

If you are brute force or otherwise synthesizing the private key, you do not 
need
the passphrase for the on-disk key. As was pointed out elsewhere, the passphrase
for the key file only matters if you already stole the key file.

In terms of guessing the private key vs. guessing a suitably long pass phrase, 
the
difficulty is roughly equivalent.

> Technically it is two-factor even if the user made one of the factors
> really easy. And that might save the day if you have users that chooses bad
> passwords.

Technically it’s not two-factor and pretending it is is dangerous.

> The system is weak in that it is too easy to steal the key file. It is not
> unlikely that a user with sloppy passwords is also sloppy with his key file.

Right… No matter what you do it is virtually impossible to protect against 
sloppy
users.

This has been true for decades even before the internet with teenagers given 
house
keys.

> Too bad ssh does not generally support a challenge-response protocol to a
> write only hardware key device combined with server side passwords that can
> be checked against a blacklist.

There’s no reason that it can’t if you use PAM.

Owen

Re: de-peering for security sake

[Baldur Norddahl]

On 27 December 2015 at 00:11, Owen DeLong  wrote:

> No… You are missing the point. Guessing a private key is roughly
> equivalent to guessing a really long
> pass phrase. There is no way that the server side can enforce password
> protection of the private key
> on the client side, so if you are assuming that public-key authentication
> is two-factor, then you are
> failing miserably.
>

The key approach is still better. Even if the password is 123456 the
attacker is not going to get in, unless he somehow stole the key file.

Technically it is two-factor even if the user made one of the factors
really easy. And that might save the day if you have users that chooses bad
passwords.

The system is weak in that it is too easy to steal the key file. It is not
unlikely that a user with sloppy passwords is also sloppy with his key file.

Too bad ssh does not generally support a challenge-response protocol to a
write only hardware key device combined with server side passwords that can
be checked against a blacklist.

Regards,

Baldur

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 26 Dec 2015 15:11:13 -0800, Owen DeLong said:
> Or contexts where the user is sloppy about securing their private key, e.g. 
> the real world.

I seem to remember that enough people stashed their entire home directory
to github, including their keys, that github had to put in special hacks
to stop that.


pgpUuzuP4j6c7.pgp
Description: PGP signature

Re: de-peering for security sake

[Valdis . Kletnieks]

On Sat, 26 Dec 2015 12:50:27 -0800, Matthew Petach said:

> No, the difference is that a passphrase works
> in conjunction with the private key, which is
> the "something you have" vs the "something
> you know" in two-factor authentication.
>
> With password authentication, there's only a
> single solution space for the attacker to
> sift through; with private key authentication,
> unless you're sloppy about securing your
> private key, there's two massive solution spaces
> for the attacker to sift through to find the unique
> point of intersection.

Actually, to be pedantic (and this is crypto, where failure to be pedantic
can be fatal), the online attacker still has only one large space to search
through.  The private key you have on disk isn't the private key you
present to the remote server - the passphrase is used to convert from
one to the other.

(Hint: Consider the case of an ssh key generated without a passphrase.
Yes, there's valid reasons for doing this, such as allowing an ssh from
within a cronjob or other place where providing a passphrase is difficult.
And yes, if you do this, you should be securing it at the server end to
only allow that key to invoke the one command it was intended to, by using
the 'command="/your/one/command/here" option in authorized_keys)

> unless you're sloppy about securing your private key, there's two massive
> solution spaces for the attacker to sift through to find the unique point of
> intersection.

Actually, you have that backwards.  The attacker only has 2 solution
spaces if you *have* been sloppy and  your private key is captured.

The passphrase only helps if your private key on disk is captured - the
length of it determines how many possible on-the-wire private keys could
correspond to that on-disk copy.  Just remember that if they captured that,
they almost certainly also captured your known_hosts file - you *did* hash
that, right? :)

And of course, nothing hardens it like an iptables rule that only accepts
inbound port 22 (or whatever you chose) to only address space you *expect*
to see inbound ssh from. :)


pgpj6pFjmkpx0.pgp
Description: PGP signature

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 12:50 , Matthew Petach  wrote:
> 
> On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong  > wrote:
>>> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
>>> On Dec 26, 2015, at 10:09, Stephen Satchell  wrote
 My gauge is volume of obnoxious traffic.  When I get lots of SSH probes 
 from a /32, I block the /32.
> [...]
>>> With respect to ssh scans in particular -- disable all forms of
>>> password authentication and insist upon public key authentication
>>> instead. If the password scan log lines still upset you, stop logging
>>> them.
>> 
>> This isn’t a bad idea, per se, but it’s not always possible for the guy 
>> running the server
>> to dictate usage to the people using the accounts.
>> 
>> Also, note that the only difference between a good long passphrase and a 
>> private key is,
>> uh, wait, um, come to think of it, really not much.
>> 
>> The primary difference is that nobody expects to have to remember a private 
>> key so we don’t
>> get fussed when they contain lots of entropy. Users aren’t good at choosing 
>> good long secure
>> passphrases and the automated mechanisms that attempt to enforce strong 
>> passwords just
>> serve to increase user confusion and actually reduce the entropy in 
>> passwords overall.
> 
> 
> No, the difference is that a passphrase works
> in conjunction with the private key, which is
> the "something you have" vs the "something
> you know" in two-factor authentication.

No… You are missing the point. Guessing a private key is roughly equivalent to 
guessing a really long
pass phrase. There is no way that the server side can enforce password 
protection of the private key
on the client side, so if you are assuming that public-key authentication is 
two-factor, then you are
failing miserably.

> With password authentication, there's only a
> single solution space for the attacker to
> sift through; with private key authentication,
> unless you're sloppy about securing your
> private key, there's two massive solution spaces
> for the attacker to sift through to find the unique
> point of intersection.

The point here is that securing the private key is a user task and not under 
the control of the administrator.
As such, you have to assume sloppy.

> Massively different solution space volumes
> to deal with.  Equating the two only has meaning
> in cosmological contexts.

Or contexts where the user is sloppy about securing their private key, e.g. the 
real world.

Owen

Re: de-peering for security sake

[Mike Hammett]

Different network types will have different abilities to enforce this. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Jared Mauch"  
To: "Joe Abley"  
Cc: nanog@nanog.org 
Sent: Saturday, December 26, 2015 3:21:03 PM 
Subject: Re: de-peering for security sake 


> On Dec 26, 2015, at 11:14 AM, Joe Abley  wrote: 
> 
> With respect to ssh scans in particular -- disable all forms of 
> password authentication and insist upon public key authentication 
> instead. If the password scan log lines still upset you, stop logging 
> them. 

Or if you can’t get users to use keys (aside from remove the users) consider 
things like: 

example /etc/ssh/sshd_config 
Match User root 
PasswordAuthentication no 

for users that should not be permitted to fall-back to password authentication. 

- Jared 

Re: de-peering for security sake

[Jared Mauch]

> On Dec 26, 2015, at 11:14 AM, Joe Abley  wrote:
> 
> With respect to ssh scans in particular -- disable all forms of
> password authentication and insist upon public key authentication
> instead. If the password scan log lines still upset you, stop logging
> them.

Or if you can’t get users to use keys (aside from remove the users) consider 
things like:

example /etc/ssh/sshd_config
Match User root
PasswordAuthentication no

for users that should not be permitted to fall-back to password authentication.

- Jared

Re: de-peering for security sake

[Jared Mauch]

> On Dec 25, 2015, at 3:10 PM, Colin Johnston  wrote:
> 
> why do the chinese network folks never reply and action abuse reports, normal 
> slow speed network abuse is tolerated, but not high speed deliberate abuse 
> albeit compromised machines

Biggest reason I’ve seen is the same reason I delete spam in 
Chinese/Japanese/charset that is foreign to me.

When I know I’m supposed to be reading something I toss it into google 
translate, when I don’t expect it, it may not even reach my $inbox.  I’d expect 
writing to people in their non-native language is more likely to result in 
things being ignored or misclassified[1].

I work for a part of a multinational that doesn’t use the roman alphabet and 
mails are sometimes missed for this reason between our groups.

This is far more of a two way street than people realize.  When you find that 
person who speaks both languages it can remove hurdles.

- Jared

1 - Think of the setting ok_languages in spamassassin.

Re: de-peering for security sake

[Matthew Petach]

On Sat, Dec 26, 2015 at 12:34 PM, Owen DeLong  wrote:
>> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
>> On Dec 26, 2015, at 10:09, Stephen Satchell  wrote
>>> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes 
>>> from a /32, I block the /32.
[...]
>> With respect to ssh scans in particular -- disable all forms of
>> password authentication and insist upon public key authentication
>> instead. If the password scan log lines still upset you, stop logging
>> them.
>
> This isn’t a bad idea, per se, but it’s not always possible for the guy 
> running the server
> to dictate usage to the people using the accounts.
>
> Also, note that the only difference between a good long passphrase and a 
> private key is,
> uh, wait, um, come to think of it, really not much.
>
> The primary difference is that nobody expects to have to remember a private 
> key so we don’t
> get fussed when they contain lots of entropy. Users aren’t good at choosing 
> good long secure
> passphrases and the automated mechanisms that attempt to enforce strong 
> passwords just
> serve to increase user confusion and actually reduce the entropy in passwords 
> overall.


No, the difference is that a passphrase works
in conjunction with the private key, which is
the "something you have" vs the "something
you know" in two-factor authentication.

With password authentication, there's only a
single solution space for the attacker to
sift through; with private key authentication,
unless you're sloppy about securing your
private key, there's two massive solution spaces
for the attacker to sift through to find the unique
point of intersection.

Massively different solution space volumes
to deal with.  Equating the two only has meaning
in cosmological contexts.

> Owen
>

Matt

Re: de-peering for security sake

[Owen DeLong]

> On Dec 26, 2015, at 08:14 , Joe Abley  wrote:
> 
> On Dec 26, 2015, at 10:09, Stephen Satchell  wrote:
> 
>> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from 
>> a /32, I block the /32.
> 
> ... without any knowledge of how many end systems are going to be affected.
> 
> A significant campus or provider user base behind a NAT is likely to
> have more infections in absolute terms, which means more observed bad
> behaviour. It also means more end-systems (again, in absolute terms)
> that represent collateral damage.

Living with IPv4 sucks. It’s only going to get worse. This not news.
There are no good IPv4 answers.

> 
>> When I get lots of SSH probes across a range of a /24, I block the /24.
> 
> [...]
> 
>> When I see that the bad traffic has caused me to block multiple /24s, I will 
>> block the entire allocation.
> 
> Your network, your rules. But that's not the way I would manage things
> if I thought my job was to optimise and maximise connectivity between
> my users and the Internet.

So what is your approach?

> With respect to ssh scans in particular -- disable all forms of
> password authentication and insist upon public key authentication
> instead. If the password scan log lines still upset you, stop logging
> them.

This isn’t a bad idea, per se, but it’s not always possible for the guy running 
the server
to dictate usage to the people using the accounts.

Also, note that the only difference between a good long passphrase and a 
private key is,
uh, wait, um, come to think of it, really not much.

The primary difference is that nobody expects to have to remember a private key 
so we don’t
get fussed when they contain lots of entropy. Users aren’t good at choosing 
good long secure
passphrases and the automated mechanisms that attempt to enforce strong 
passwords just
serve to increase user confusion and actually reduce the entropy in passwords 
overall.

Owen

Re: de-peering for security sake

[Owen DeLong]

I think as granular as practicable. In some cases, that will be a /32 or /128. 
In some cases, that will be a /24 or /64.

In some cases, it may be an entire ASN.

Each network will need to decide for themselves based on the constraints of the 
time they have to address the issue, the level of automation for addressing 
these things, memory in their routing platform(s), etc.

There is no one-size-fits all answer.

Owen

> On Dec 26, 2015, at 06:19 , Mike Hammett  wrote:
> 
> How much is an acceptable standard to the community? Individual /32s ( or 
> /64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 
> equivalent would be) has made your naughty list that you block the whole 
> prefix? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> - Original Message -
> 
> From: "Owen DeLong"  
> To: "Dan Hollis"  
> Cc: "Mike Hammett" , "NANOG"  
> Sent: Saturday, December 26, 2015 1:00:35 AM 
> Subject: Re: de-peering for security sake 
> 
> 
>> On Dec 25, 2015, at 22:16 , Dan Hollis  wrote: 
>> 
>> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>>> Merely because people are asleep at the switch does not give those of us in 
>>> a position to understand the consequences license to abuse our position. 
>> 
>> At what point do you cut the wire? How abusive is acceptable? 
> 
> IMHO, you never cut the wire. You may filter selectively, but cutting the 
> wire comes with far more collateral damage than actual useful effect. 
> 
> Owen 
> 

Re: de-peering for security sake

[William Waites]

On Sat, 26 Dec 2015 11:14:25 -0500, Joe Abley  said:

>> My gauge is volume of obnoxious traffic.  When I get lots of
>> SSH probes from a /32, I block the /32.

> ... without any knowledge of how many end systems are going to
> be affected.  A significant campus or provider user base behind
> a NAT is likely to have more infections in absolute terms, which
> means more observed bad behaviour. It also means more
> end-systems (again, in absolute terms) that represent collateral
> damage.

Indeed this is only going to get worse with pressure on IPv4
addressing space. I often see this with small rural providers that
have not yet progressed to the level of getting their own address
space, and the available space is already insufficient in many cases.

Another important scenario where this happens is Tor exit nodes. I
have not observed any de-peering or network-layer filtering around
exit nodes, but the milder, but still very obnoxious, tactic of
application-layer capchas happens a lot. This is a serious problem for
privacy or security conscious users (i.e. most of Tor's userbase) that
tend not to enable JavaScript unless there is good reason. And a lot
of these capcha systems require JavaScript.

I see this every day since I live in a country where it would be
foolish not to use Tor as a matter of course. Large CDNs like
Cloudflare are guilty of this and this exascerbates the problem
because it prevents access to a very large set of resources and not
just a single web site. It's not nice. It has the effect of turning
the privacy-conscious into second-class netizens.

Rachel Greenstadt is presenting some research tomorrow at the CCC on
the effect this has on excluding contributions to common goods such as
Wikipedia:

https://events.ccc.de/congress/2015/Fahrplan/events/7324.html


--
William Waites   |  School of Informatics
   https://tardis.ed.ac.uk/~wwaites/  | University of Edinburgh
 https://hubs.net.uk/ |  HUBS AS60241

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Re: de-peering for security sake

[Joe Abley]

On Dec 26, 2015, at 10:09, Stephen Satchell  wrote:

> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes from 
> a /32, I block the /32.

... without any knowledge of how many end systems are going to be affected.

A significant campus or provider user base behind a NAT is likely to
have more infections in absolute terms, which means more observed bad
behaviour. It also means more end-systems (again, in absolute terms)
that represent collateral damage.

> When I get lots of SSH probes across a range of a /24, I block the /24.

[...]

> When I see that the bad traffic has caused me to block multiple /24s, I will 
> block the entire allocation.

Your network, your rules. But that's not the way I would manage things
if I thought my job was to optimise and maximise connectivity between
my users and the Internet.

With respect to ssh scans in particular -- disable all forms of
password authentication and insist upon public key authentication
instead. If the password scan log lines still upset you, stop logging
them.


Joe

Re: de-peering for security sake

[Mike Hammett]

1) Automation is your friend. 
2) If a host is compromised and doing an SSH scan, it's likely going to also be 
attempting SMTP, WordPress, home router, etc. attacks. Use a canary to block 
that host altogether to better your network. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Baldur Norddahl"  
To: nanog@nanog.org 
Sent: Saturday, December 26, 2015 9:19:15 AM 
Subject: Re: de-peering for security sake 

On 26 December 2015 at 16:09, Stephen Satchell  wrote: 

> On 12/26/2015 06:19 AM, Mike Hammett wrote: 
> 
>> How much is an acceptable standard to the community? Individual /32s 
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's 
>> IPv6 equivalent would be) has made your naughty list that you block 
>> the whole prefix? 
>> 
> 
> My gauge is volume of obnoxious traffic. When I get lots of SSH probes 
> from a /32, I block the /32. When I get lots of SSH probes across a range 
> of a /24, I block the /24. 
> 


Do you people have nothing better to do than scan firewall log files and 
insert rules to block stuff that was already blocked by default? 

Hint: if ssh probes spams your log then move your ssh service to a non 
standard port. 

Regards, 

Baldur 

Re: de-peering for security sake

[Baldur Norddahl]

On 26 December 2015 at 16:09, Stephen Satchell  wrote:

> On 12/26/2015 06:19 AM, Mike Hammett wrote:
>
>> How much is an acceptable standard to the community? Individual /32s
>> ( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
>> IPv6 equivalent would be) has made your naughty list that you block
>> the whole prefix?
>>
>
> My gauge is volume of obnoxious traffic.  When I get lots of SSH probes
> from a /32, I block the /32.  When I get lots of SSH probes across a range
> of a /24, I block the /24.
>


Do you people have nothing better to do than scan firewall log files and
insert rules to block stuff that was already blocked by default?

Hint: if ssh probes spams your log then move your ssh service to a non
standard port.

Regards,

Baldur

Re: de-peering for security sake

[Stephen Satchell]

On 12/26/2015 06:19 AM, Mike Hammett wrote:

How much is an acceptable standard to the community? Individual /32s
( or /64s)? Some tipping point where 50% of a /24 (or whatever it's
IPv6 equivalent would be) has made your naughty list that you block
the whole prefix?


My gauge is volume of obnoxious traffic.  When I get lots of SSH probes 
from a /32, I block the /32.  When I get lots of SSH probes across a 
range of a /24, I block the /24.


When I see that the bad traffic has caused me to block multiple /24s, I 
will block the entire allocation.


By "lots" I mean hundreds or more.  When the criminals try to bust my 
door down, I take stops to stop them.


Ditto with attempts to relay mail through my mail servers.

My goal isn't to reduce traffic.  My goal is to stop irresponsible 
people from finding a rat-hole to do things I don't authorize them to 
do.  Defense in depth.


This is in addition to selecting the TCP and UDP ports carefully that I 
expose to the outside world.  Indeed, I have separate ACLs for inbound, 
outbound, and DMZ ports.  So, I've limited service from the inside to 
the outside to this:



#   ---originated by LAN host to Internet
FORWARD_TCP="ftp ssh snmp telnet smtp smtps submission domain http https ntp nicname 
rwhois pop3 pop3s imap imaps radius"
FORWARD_TCP="$FORWARD_TCP 465 8008 webcache 8443  snpp rsync"
#   xmpp-client
FORWARD_TCP="$FORWARD_TCP 5222 5223 8002"
#   Microsoft Notification Protocol (msnp) [Messenger]
FORWARD_TCP="$FORWARD_TCP 1863"
#   Microsoft PPTP
FORWARD_TCP="$FORWARD_TCP 1723"
#   Timbuktu client, Service Ports 1-4
FORWARD_TCP="$FORWARD_TCP 407 1417:1420"
#   memoq
FORWARD_TCP="$FORWARD_TCP 2705"
#
FORWARD_UDP="domain ntp snmp 407 443 500 1419 1701 1812 4500 snmp 3389 1 5 
"


Your client base and my client base differ.  I make NNAP difficult to 
use against the world from my people.  But I don't hamstring them; if 
they want access to an outside service, they have but to ask.


I also terminate spammers.

Re: de-peering for security sake

[Mike Hammett]

How much is an acceptable standard to the community? Individual /32s ( or 
/64s)? Some tipping point where 50% of a /24 (or whatever it's IPv6 equivalent 
would be) has made your naughty list that you block the whole prefix? 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Owen DeLong"  
To: "Dan Hollis"  
Cc: "Mike Hammett" , "NANOG"  
Sent: Saturday, December 26, 2015 1:00:35 AM 
Subject: Re: de-peering for security sake 


> On Dec 25, 2015, at 22:16 , Dan Hollis  wrote: 
> 
> On Fri, 25 Dec 2015, Owen DeLong wrote: 
>> Merely because people are asleep at the switch does not give those of us in 
>> a position to understand the consequences license to abuse our position. 
> 
> At what point do you cut the wire? How abusive is acceptable? 

IMHO, you never cut the wire. You may filter selectively, but cutting the wire 
comes with far more collateral damage than actual useful effect. 

Owen 

Re: de-peering for security sake

[Mark Tinka]

On 25/Dec/15 14:14, Nick Hilliard wrote:

> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?

And watch the transit per-Mbps price go up? Who do we think funds the
low bandwidth costs of the "first world"?

Mark.

Re: de-peering for security sake

[Owen DeLong]

> On Dec 25, 2015, at 22:16 , Dan Hollis  wrote:
> 
> On Fri, 25 Dec 2015, Owen DeLong wrote:
>> Merely because people are asleep at the switch does not give those of us in 
>> a position to understand the consequences license to abuse our position.
> 
> At what point do you cut the wire? How abusive is acceptable?

IMHO, you never cut the wire. You may filter selectively, but cutting the wire 
comes with far more collateral damage than actual useful effect.

Owen

Re: de-peering for security sake

[Andrew Kirch]

Speaking as a former DNSBL operator, NANOG has a poor history of
dealing with those who report abuse as well.

On Fri, Dec 25, 2015 at 4:52 PM, Mikael Abrahamsson  wrote:
> On Fri, 25 Dec 2015, Colin Johnston wrote:
>
>> why do the chinese network folks never reply and action abuse reports,
>> normal slow speed network abuse is tolerated, but not high speed deliberate
>> abuse albeit compromised machines
>
>
> This is not a chinese problem, this is a general ISP problem. Most ISPs do
> not respond to abuse reports.
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: de-peering for security sake

[TR Shaw]

ARF (http://www.rfc-editor.org/rfc/rfc5965.txt 
, 
https://www.rfc-editor.org/rfc/rfc6650.txt) and X-ARF 
(http://www.x-arf.org/index.html ) are used 
quite alot and many, like Yahoo, only accept ARF reports on abusive emails.

you might want to read MAAWG’s BCP: 
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Feedback_Reporting_Recommendation_BP-2014-02.pdf
 


Tom

> On Dec 25, 2015, at 5:12 PM, Clayton Zekelman  wrote:
> 
> Just an off the cuff thought but if the format of the abuse messages could be 
> standardized so handling them would be semi-automated somewhat like ACNS 
> notices, it might improve response.
> 
> Maybe such a format already exists and just isn't widely used.
> 
> Sent from my iPhone
> 
>> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson  wrote:
>> 
>>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>>> 
>>> why do the chinese network folks never reply and action abuse reports, 
>>> normal slow speed network abuse is tolerated, but not high speed deliberate 
>>> abuse albeit compromised machines
>> 
>> This is not a chinese problem, this is a general ISP problem. Most ISPs do 
>> not respond to abuse reports.
>> 
>> -- 
>> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: de-peering for security sake

[Hugo Slabbert]

Just in case I missed the /s on there:

> Maybe such a format already exists and just isn't widely used.

It does and it isn't.

http://www.x-arf.org/

--
Hugo
h...@slabnet.com: email, xmpp/jabber
also on Signal

 From: Clayton Zekelman  -- Sent: 2015-12-25 - 14:12 

> Just an off the cuff thought but if the format of the abuse messages could be 
> standardized so handling them would be semi-automated somewhat like ACNS 
> notices, it might improve response.
>
> Maybe such a format already exists and just isn't widely used.
>
> Sent from my iPhone
>
>> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson  wrote:
>>
>>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>>>
>>> why do the chinese network folks never reply and action abuse reports, 
>>> normal slow speed network abuse is tolerated, but not high speed deliberate 
>>> abuse albeit compromised machines
>>
>> This is not a chinese problem, this is a general ISP problem. Most ISPs do 
>> not respond to abuse reports.
>>
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se
>




signature.asc
Description: PGP/MIME digital signature

Re: de-peering for security sake

[Clayton Zekelman]

Just an off the cuff thought but if the format of the abuse messages could be 
standardized so handling them would be semi-automated somewhat like ACNS 
notices, it might improve response.

Maybe such a format already exists and just isn't widely used.

Sent from my iPhone

> On Dec 25, 2015, at 4:52 PM, Mikael Abrahamsson  wrote:
> 
>> On Fri, 25 Dec 2015, Colin Johnston wrote:
>> 
>> why do the chinese network folks never reply and action abuse reports, 
>> normal slow speed network abuse is tolerated, but not high speed deliberate 
>> abuse albeit compromised machines
> 
> This is not a chinese problem, this is a general ISP problem. Most ISPs do 
> not respond to abuse reports.
> 
> -- 
> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: de-peering for security sake

[Mikael Abrahamsson]

On Fri, 25 Dec 2015, Colin Johnston wrote:

why do the chinese network folks never reply and action abuse reports, 
normal slow speed network abuse is tolerated, but not high speed 
deliberate abuse albeit compromised machines


This is not a chinese problem, this is a general ISP problem. Most ISPs do 
not respond to abuse reports.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: de-peering for security sake

[Owen DeLong]

I think that even in the US, a provider would want a more specific complaint 
than “The network abuses”.

Owen

> On Dec 25, 2015, at 12:40 , Colin Johnston  wrote:
> 
> been there, done that
> 网络滥用 fix you ntp reflection servers :)
> 
> Sent from my iPhone
> 
>> On 25 Dec 2015, at 20:29, Baldur Norddahl  wrote:
>> 
>>> On 25 December 2015 at 21:10, Colin Johnston  wrote:
>>> 
>>> why do the chinese network folks never reply and action abuse reports,
>>> normal slow speed network abuse is tolerated, but not high speed deliberate
>>> abuse albeit compromised machine
>> 
>> They do not speak the same language as you. They barely understand your
>> complaint and you would not understand their reply (in chinese!) - or do
>> you expect everyone to know english?
>> 
>> Why does everyone expect the chinese to use Google Translate? Try it
>> yourself before sending off your complaint in Mandarin...
>> 
>> Regards,
>> 
>> Baldur

Re: de-peering for security sake

[Colin Johnston]

been there, done that
网络滥用 fix you ntp reflection servers :)

Sent from my iPhone

> On 25 Dec 2015, at 20:29, Baldur Norddahl  wrote:
> 
>> On 25 December 2015 at 21:10, Colin Johnston  wrote:
>> 
>> why do the chinese network folks never reply and action abuse reports,
>> normal slow speed network abuse is tolerated, but not high speed deliberate
>> abuse albeit compromised machine
> 
> They do not speak the same language as you. They barely understand your
> complaint and you would not understand their reply (in chinese!) - or do
> you expect everyone to know english?
> 
> Why does everyone expect the chinese to use Google Translate? Try it
> yourself before sending off your complaint in Mandarin...
> 
> Regards,
> 
> Baldur

Re: de-peering for security sake

[Baldur Norddahl]

On 25 December 2015 at 21:10, Colin Johnston  wrote:

> why do the chinese network folks never reply and action abuse reports,
> normal slow speed network abuse is tolerated, but not high speed deliberate
> abuse albeit compromised machine
>

They do not speak the same language as you. They barely understand your
complaint and you would not understand their reply (in chinese!) - or do
you expect everyone to know english?

Why does everyone expect the chinese to use Google Translate? Try it
yourself before sending off your complaint in Mandarin...

Regards,

Baldur

Re: de-peering for security sake

[Colin Johnston]

why do the chinese network folks never reply and action abuse reports, normal 
slow speed network abuse is tolerated, but not high speed deliberate abuse 
albeit compromised machines

Sent from my iPhone

> On 25 Dec 2015, at 19:43, Baldur Norddahl  wrote:
> 
>> On 25 December 2015 at 20:06, Lee  wrote:
>> 
>> Enable IPv6 for your users.  1) it's not going to have any "history" &
>> 2) ipv6 probably isn't blocked.
>> 
> 
> I am not aware of just one single government site in this country (Denmark)
> that is IPv6 enabled. There are zero danish news sites that are IPv6
> enabled. In fact, nothing here is IPv6 enabled - with the exception of all
> major ISP sites. For some strange reason all ISPs have IPv6 on their
> websites (but they do not provide IPv6 to their customers). It is sad
> really.
> 
> 
>> 
>>> So now my users can not access government sites because the IP ranges
>> were
>>> owned by a company in a different country two years ago.
>> 
>> Find one of your users that's a citizen of said gov't & forward their
>> complaint to the gov't sites.  Non-citizen complaints are much easier
>> to ignore..
>> 
> 
> I am a citizen and yes, they do ignore us. If you can manage to find the
> right guy, he can probably fix it in a few minutes. It is just that there
> is no way to get to that guy. The front desk has no clue what you are
> talking about. To these people we should just stop sending traffic from
> Romania and it would all be fixed, no?
> 
> To make it worse it is a really boring game of whack a mole. The users are
> constantly finding new sites that are either blocking us or are showing the
> site in the wrong language. Each time we open up a new IP series, it all
> starts over again. We do not have enough cash on hand to simply buy a real
> large chunk of IPv4, so we have multiple smaller blocks.
> 
> With regards to this thread, I am finding a worrying trend for websites to
> block out of country IP-addresses at the firewall. In the past you could
> expect that some content would not play or that your credit card payment
> would be blocked. But now you never get to that stage because sites are
> dropping the packets at the firewall.
> 
> Regards,
> 
> Baldur

Re: de-peering for security sake

[Baldur Norddahl]

On 25 December 2015 at 20:06, Lee  wrote:

> Enable IPv6 for your users.  1) it's not going to have any "history" &
> 2) ipv6 probably isn't blocked.
>

I am not aware of just one single government site in this country (Denmark)
that is IPv6 enabled. There are zero danish news sites that are IPv6
enabled. In fact, nothing here is IPv6 enabled - with the exception of all
major ISP sites. For some strange reason all ISPs have IPv6 on their
websites (but they do not provide IPv6 to their customers). It is sad
really.


>
> > So now my users can not access government sites because the IP ranges
> were
> > owned by a company in a different country two years ago.
>
> Find one of your users that's a citizen of said gov't & forward their
> complaint to the gov't sites.  Non-citizen complaints are much easier
> to ignore..
>

I am a citizen and yes, they do ignore us. If you can manage to find the
right guy, he can probably fix it in a few minutes. It is just that there
is no way to get to that guy. The front desk has no clue what you are
talking about. To these people we should just stop sending traffic from
Romania and it would all be fixed, no?

To make it worse it is a really boring game of whack a mole. The users are
constantly finding new sites that are either blocking us or are showing the
site in the wrong language. Each time we open up a new IP series, it all
starts over again. We do not have enough cash on hand to simply buy a real
large chunk of IPv4, so we have multiple smaller blocks.

With regards to this thread, I am finding a worrying trend for websites to
block out of country IP-addresses at the firewall. In the past you could
expect that some content would not play or that your credit card payment
would be blocked. But now you never get to that stage because sites are
dropping the packets at the firewall.

Regards,

Baldur

Re: de-peering for security sake

[Lee]

On 12/24/15, Baldur Norddahl  wrote:
> I am afraid people are already doing this. Every time I bring a new IP
> series into production, my users will complain that they are locked out
> from sites including many government sites. This is because people will
> load IP location lists into their firewall and drop packets at the border.
> Of course they will not update said lists and load year old lists into
> their firewalls.

Enable IPv6 for your users.  1) it's not going to have any "history" &
2) ipv6 probably isn't blocked.

> So now my users can not access government sites because the IP ranges were
> owned by a company in a different country two years ago.

Find one of your users that's a citizen of said gov't & forward their
complaint to the gov't sites.  Non-citizen complaints are much easier
to ignore..

Regards,
Lee


> Take a guess on how responsive site owners are when we complain about their
> firewall. Most refuse to acknowledge they do any blocking and insist the
> problem is at our end. That is if they respond at all.
>
> Regards,
>
> Baldur
>
>
> On 25 December 2015 at 02:25, Stephen Satchell  wrote:
>
>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>
>>> Let’s just cut off the entirety of the third world instead of having
>>> a tangible mitigation plan in place.
>>>
>>
>> While you thing you are making a snarky response, it would be handy for
>> end users to be able to turn on and off access to other countries retail.
>> If *they* don't need access to certain third world countries, it would be
>> their decision, not the operator's decision.
>>
>> For example, here on my little network we have no need for connectivity
>> to
>> much of Asia, Africa, or India.  We do have need to talk to Europe,
>> Australia, and some countries in South America.
>>
>>
>

Re: de-peering for security sake

[Owen DeLong]

> On Dec 25, 2015, at 06:18 , Mike Hammett  wrote:
> 
> To the thread, not necessarily Daniel, if blocking countries\continents is a 
> bad thing (not saying I disagree), how do you deal with the flood of trash? 
> Just take it on the chin? 

Allowing hate speech is the price of having free speech. I will decry, 
denounce, and object to all of the statements promoting racism or banning entry 
of people based on religion, or other forms of discrimination, but I will not 
claim that any person has no right to make those statements. In fact, I will 
strongly defend the right of those people to make fools of themselves in public 
every bit as strongly as I will defend my right to make opposing statements. 
Unless we tolerate unpopular speech, we risk a tyranny of the majority which is 
both detrimental to society overall and antithetical to freedom of speech, the 
principles of democracy, and the entire concept of a free society.

To some extent, some of the trash we take on the chin on the internet is the 
price of having a free and open internet.

I’m not opposed to localized depeering or blockage when warranted, but it is 
important to keep such actions as granular as practicable. Otherwise, the 
collateral damage to the free and open internet becomes greater than the damage 
done by the miscreants we are attempting to block.

Surely blocking an entire nation is well beyond “as granular as practicable”.

I realize that reactionary overreach has become fashionable in the US since 
9/11. Some great examples include the U.S.A.P.A.T.R.I.O.T. act, warrantless 
wiretapping and the associated unconstitutional laws of ex post facto granting 
retroactive immunity to the phone companies that lacked the will to say no. 
Examples abound even today in the surveillance bill that got buried in the 
recent budget act.

> The degree of splash damage by blocking this way will vary based upon what 
> kind of network you are. Residential eyeballs? You could probably block most 
> of a lot of things and people wouldn't notice or care, as long as it wasn't 
> Google, Facebook, Netflix, etc. 

That may be true, but even if it is, it still doesn’t make broad censorship a 
concept we should support or accept in practice.

The extent to which it is true reminds me of the story (apocryphal as it is) of 
the frog in a pot of water with the temperature being raised slowly.

Merely because people are asleep at the switch does not give those of us in a 
position to understand the consequences license to abuse our position.

Owen

Re: de-peering for security sake

[Daniel Corbe]

You know, without actually looking I’m willing to lay money down that the 
people beating the blocklist drum are the same people who scream the loudest 
about net neutrality when they can’t actually get to the content they want. 

> On Dec 25, 2015, at 11:25 AM, Daniel Corbe  wrote:
> 
> 
>> On Dec 25, 2015, at 9:18 AM, Mike Hammett  wrote:
>> 
>> To the thread, not necessarily Daniel, if blocking countries\continents is a 
>> bad thing (not saying I disagree), how do you deal with the flood of trash? 
>> Just take it on the chin? 
> 
> If you as an end user want to be the cyber-equivalent of a xenophobe because 
> OMG BAD INTERNETS then be my guest.  On the other hand, I’m a network 
> operator so I don’t have the luxury of dictating to my users what they can 
> and cannot reach.  
> 
>> 
>> The degree of splash damage by blocking this way will vary based upon what 
>> kind of network you are. Residential eyeballs? You could probably block most 
>> of a lot of things and people wouldn't notice or care, as long as it wasn't 
>> Google, Facebook, Netflix, etc. 
> 
> As a residential ISP with many first and second generation American 
> immigrants in my service footprint I can assure you this notion is patently 
> false.  People will definitely notice and care if they can’t communicate with 
> their relatives and consume content in their home countries.  
> 
>> 
>> 
>> 
>> 
>> - 
>> Mike Hammett 
>> Intelligent Computing Solutions 
>> http://www.ics-il.com 
>> 
>> 
>> 
>> Midwest Internet Exchange 
>> http://www.midwest-ix.com 
>> 
>> 
>> - Original Message -
>> 
>> From: "Daniel Corbe"  
>> To: "Nick Hilliard"  
>> Cc: "NANOG"  
>> Sent: Friday, December 25, 2015 8:11:55 AM 
>> Subject: Re: de-peering for security sake 
>> 
>> 
>>> On Dec 25, 2015, at 7:14 AM, Nick Hilliard  wrote: 
>>> 
>>> Daniel Corbe wrote: 
>>>> Let’s just cut off the entirety of the third world instead of having 
>>>> a tangible mitigation plan in place. 
>>> 
>>> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
>>> 
>>>> https://en.wikipedia.org/wiki/Third_World 
>>> 
>>> What an enormously silly idea. 
>>> 
>>> Seasons greetings to all, 
>>> 
>>> Nick 
>>> 
>> 
>> It was a stupid idea even before you corrected me. 
>> 
>> 
> 

Re: de-peering for security sake

[Daniel Corbe]

> On Dec 25, 2015, at 9:18 AM, Mike Hammett  wrote:
> 
> To the thread, not necessarily Daniel, if blocking countries\continents is a 
> bad thing (not saying I disagree), how do you deal with the flood of trash? 
> Just take it on the chin? 

If you as an end user want to be the cyber-equivalent of a xenophobe because 
OMG BAD INTERNETS then be my guest.  On the other hand, I’m a network operator 
so I don’t have the luxury of dictating to my users what they can and cannot 
reach.  

> 
> The degree of splash damage by blocking this way will vary based upon what 
> kind of network you are. Residential eyeballs? You could probably block most 
> of a lot of things and people wouldn't notice or care, as long as it wasn't 
> Google, Facebook, Netflix, etc. 

As a residential ISP with many first and second generation American immigrants 
in my service footprint I can assure you this notion is patently false.  People 
will definitely notice and care if they can’t communicate with their relatives 
and consume content in their home countries.  

> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> - Original Message -
> 
> From: "Daniel Corbe"  
> To: "Nick Hilliard"  
> Cc: "NANOG"  
> Sent: Friday, December 25, 2015 8:11:55 AM 
> Subject: Re: de-peering for security sake 
> 
> 
>> On Dec 25, 2015, at 7:14 AM, Nick Hilliard  wrote: 
>> 
>> Daniel Corbe wrote: 
>>> Let’s just cut off the entirety of the third world instead of having 
>>> a tangible mitigation plan in place. 
>> 
>> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
>> 
>>> https://en.wikipedia.org/wiki/Third_World 
>> 
>> What an enormously silly idea. 
>> 
>> Seasons greetings to all, 
>> 
>> Nick 
>> 
> 
> It was a stupid idea even before you corrected me. 
> 
> 

Re: de-peering for security sake

[Stephen Satchell]

On 12/25/2015 06:18 AM, Mike Hammett wrote:

To the thread, not necessarily Daniel, if blocking
countries\continents is a bad thing (not saying I disagree), how do
you deal with the flood of trash? Just take it on the chin?

The degree of splash damage by blocking this way will vary based
uponwhat kind of network you are. Residential eyeballs? You could
probably block most of a lot of things and people wouldn't notice
or care, as long as it wasn't Google, Facebook, Netflix, etc.


In my networks, different users have different requirements.  So I have 
to be careful in my ACLs to allow what they need, while reducing access 
by those who view the Internet as a sewer, and not as a privilege. (Used 
to be a BOFH in the NSF days.)


So my blocking list has grown, as I have identified bad actors from the 
information in my logs.  Keeping in mind that people with one bad habit 
will most likely have other bad habits as well, I keep it simple: if you 
don't play nice, you are blocked at the demarc.


For of the majority of my users, I provide access behind a router with 
the block list shown below.  For those customers who want an unblocked 
feed, I provide that by having the edge bypass the filtering router. (No 
one has asked yet for custom filters -- 1841s are cheap and easy, and 
don't take much power.)


I don't intend to provide this list for others to use.  I provide this 
list as an example of how I exercise my right of Internet Freedom of 
Assocation, and keep my own network safe from intruders.  Abuse reports? 
 I've given up on them, frankly.  My logs don't include enough 
information for some admins, so they drop my reports without further 
comment.  When there is an admin listed.


The nice thing about IPTABLES is that I can pull a report, if I want to, 
of which of these blocks are still generating traffic.  As we go farther 
down the IPv4-split road, I may just set up a database of the blocks, 
and monitor the traffic to see which ones have gone silent and thus can 
be removed.  Or not -- that's a lot of work and time, both of which I 
can direct to activities that bring in revenue.



1.93.34.222/32  china ssh abuser2014 August
5.79.75.0/24netherlands spam2015 January
8.27.235.155Microsoft   2015 September
14.139.172.0/24 india ssh abuser2015 April
23.19.26.250ubiquityservers.com ssh 2015 January
23.90.39.0/24   eonix.net   spam2014 October
23.90.51.0/24   eonix.net   spam2014 October
23.227.196.0/24 Swiftway.comspammer 2014 October
23.228.74.0/24  globalfrag.com  spam2015 January
23.228.78.0/24  Blanckeart (NY) spam2014 September
23.228.96.0/24  globalfrag.com  spam2015 January
23.228.103.0/24 spam2015 April
23.229.2.0/24   servermania.com spam2015 January
23.229.97.0/24  servermania.com spam2015 January
23.247.12.0/24  globalfrag.com  spam2015 January
23.254.59.0/24  spam2015 April
31.184.194.114  russia  ssh 2015 January
36.72.228.0/24  India ssh abuser2014 October
38.113.188.0/24 cogent.net  spam2015 January
41.186.0.0/16   Rwanda  ssh 2015 May
43.229.52.0/24  unknown ssh 2015 May
43.229.53.0/24  unknown ssh 2015 September
43.255.189.0/24 unknown ssh 2015 June
46.166.136.0/24 spam2015 April
46.166.189.0/24 spam2015 April
50.2.0.0/15 eonix.net spam  2014 October
50.7.38.0/24fdcservers.net  spam2015 January
50.162.224.109  comcast.net ssh 2015 January
52.28.227.79amazonaws   ssh 2015 September
58.208.0.0/12   china ssh abuser2015 May
58.217.106.0/24 china ssh   2014 November
58.218.166.241/24   china ssh abuser2015 April
58.218.204.241/24   china ssh abuser2015 April
60.173.8.0/24   china shellshock2014 September
60.173.9.0/24   china shellshock2014 September
60.173.10.0/24  china shellshock2014 September
60.173.11.0/24  china shellshock2014 September
60.173.14.0/24  china shellshock2014 September
60.173.26.0/24  china shellshock2014 September
60.174.233.0/24 china shellshock2014 September
60.184.82.0/24  china spam  2014 October
61.153.105.0/24 china ssh abuser2014 August
61.153.110.0/24 china ssh abuser2014 August
61.174.49.0/24  china smtp abuser   2014 August
61.174.50.0/24  china ssh abuser2014 August
61.174.51.0/24  china ssh abuser2014 August
61.168.229.114/24   china ssh abuser2015 February
62.210.78.0

Re: de-peering for security sake

[Mike Hammett]

To the thread, not necessarily Daniel, if blocking countries\continents is a 
bad thing (not saying I disagree), how do you deal with the flood of trash? 
Just take it on the chin? 

The degree of splash damage by blocking this way will vary based upon what kind 
of network you are. Residential eyeballs? You could probably block most of a 
lot of things and people wouldn't notice or care, as long as it wasn't Google, 
Facebook, Netflix, etc. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Daniel Corbe"  
To: "Nick Hilliard"  
Cc: "NANOG"  
Sent: Friday, December 25, 2015 8:11:55 AM 
Subject: Re: de-peering for security sake 


> On Dec 25, 2015, at 7:14 AM, Nick Hilliard  wrote: 
> 
> Daniel Corbe wrote: 
>> Let’s just cut off the entirety of the third world instead of having 
>> a tangible mitigation plan in place. 
> 
> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel? 
> 
>> https://en.wikipedia.org/wiki/Third_World 
> 
> What an enormously silly idea. 
> 
> Seasons greetings to all, 
> 
> Nick 
> 

It was a stupid idea even before you corrected me. 

Re: de-peering for security sake

[Daniel Corbe]

> On Dec 25, 2015, at 7:14 AM, Nick Hilliard  wrote:
> 
> Daniel Corbe wrote:
>> Let’s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?
> 
>> https://en.wikipedia.org/wiki/Third_World
> 
> What an enormously silly idea.
> 
> Seasons greetings to all,
> 
> Nick
> 

It was a stupid idea even before you corrected me.

Re: de-peering for security sake

[Max Tulyev]

Come on, keep calm and wait a year: Russia and China will de-peer with
all the world for their security (AKA censorship) reasons! ;)

On 25.12.15 01:44, Colin Johnston wrote:
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse 
> reports seriously why allow them to network to the internet ?
> 
> Colin
> 
> 

Re: de-peering for security sake

[Nick Hilliard]

Daniel Corbe wrote:
> Let’s just cut off the entirety of the third world instead of having
> a tangible mitigation plan in place.

You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?

> https://en.wikipedia.org/wiki/Third_World

What an enormously silly idea.

Seasons greetings to all,

Nick

Re: de-peering for security sake

[Colin Johnston]

> On 25 Dec 2015, at 00:48, valdis.kletni...@vt.edu wrote:
> 
> On Thu, 24 Dec 2015 23:44:10 +, Colin Johnston said:
>> We really need to ask if China and Russia for that matter will not take abuse
>> reports seriously why allow them to network to the internet ?
> 
> Well, first off, it isn't like China or Russia are just one ASN.  You'd have
> to de-peer a bunch of ASN's - and also eliminate any paid transit connections.
> 
> Note that even North Korea has managed to land at least a small presence on
> the Internet.  Are you going to ban them too?
> 
> While we're banning countries, how about the country that's known for
> widespread surveillance both foreign and domestic, has one of the strongest
> cyber warfare arsenals around, and has been caught multiple times diverting 
> and
> backdooring routers sold to foreign countries?
> 
> Oh wait, that's the US. Maybe we better rethink this?
> 
> Obviously, there's a lot of organizations that think that being able to
> communicate with China and Russia outweighs the security issues.  You are
> of course welcome to make a list of all Russian and Chinese ASNs and block
> their prefixes at your border.

So therefore we must somehow engage and enforce best practice for abuse alerts 
and action issues

Colin

Re: de-peering for security sake

[Joel Jaeggli]

While you have a great deal of control over what prefixes you choose to 
accept... You have very little control over your advertised prefixes once they 
exit your ASN. Maybe your transits offer communities to control their peer 
advertisements. In general assuming you're paying for the Internet cone, you 
have a vested interest in them propagating everywhere otherwise the party that 
is partitioned is you.

Sent from my iPhone

> On Dec 24, 2015, at 15:44, Colin Johnston  wrote:
> 
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse 
> reports seriously why allow them to network to the internet ?
> 
> Colin
> 
> 

Re: de-peering for security sake

[Suresh Ramasubramanian]

Well, at least she's here rather than sprinkling eggnog and brandy flavoured 
pixie dust on our gear over the Christmas break.

--srs

> On 25-Dec-2015, at 9:08 AM, Owen DeLong  wrote:
> 
> Yes… Isn’t it impressive just how persistent the bad idea fairy can be?
> 
> Owen

Re: de-peering for security sake

[Owen DeLong]

Yes… Isn’t it impressive just how persistent the bad idea fairy can be?

Owen

> On Dec 24, 2015, at 19:25 , Suresh Ramasubramanian  
> wrote:
> 
> Hmm, has anyone at all kept count of the number of times such a discussion 
> has started up in just the last year, and how many more times in the past 16 
> or so years?
> 
> Mind you, back in say 2004, this discussion would have run to 50 or 60 emails 
> at a bare minimum, in no time at all.
> 
> --srs
> 
> On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:
> 
>>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>>> Let’s just cut off the entirety of the third world instead of having
>>> a tangible mitigation plan in place.
>> 
>> While you thing you are making a snarky response, it would be handy for end 
>> users to be able to turn on and off access to other countries retail.

Re: de-peering for security sake

[Owen DeLong]

> On Dec 24, 2015, at 17:25 , Stephen Satchell  wrote:
> 
> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>> Let’s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> While you thing you are making a snarky response, it would be handy for end 
> users to be able to turn on and off access to other countries retail.  If 
> *they* don't need access to certain third world countries, it would be their 
> decision, not the operator's decision.
> 
> For example, here on my little network we have no need for connectivity to 
> much of Asia, Africa, or India.  We do have need to talk to Europe, 
> Australia, and some countries in South America.

Yes… Balkanization has been such a wonderful and useful strategy in the 
physical world, let’s bring it to cyberspace and we should be able to expect 
the same level of success…

Oh, wait, that wouldn’t be so good. Maybe this should be rethought.

One of the definitions of insanity is doing the same thing over and over again, 
expecting different results. This would seem to me to fit that particular 
definition.

Owen

Re: de-peering for security sake

[Suresh Ramasubramanian]

Hmm, has anyone at all kept count of the number of times such a discussion has 
started up in just the last year, and how many more times in the past 16 or so 
years?

Mind you, back in say 2004, this discussion would have run to 50 or 60 emails 
at a bare minimum, in no time at all.

--srs

On 25-Dec-2015, at 6:55 AM, Stephen Satchell  wrote:

>> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>> Let’s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
> 
> While you thing you are making a snarky response, it would be handy for end 
> users to be able to turn on and off access to other countries retail.

Re: de-peering for security sake

[Baldur Norddahl]

I am afraid people are already doing this. Every time I bring a new IP
series into production, my users will complain that they are locked out
from sites including many government sites. This is because people will
load IP location lists into their firewall and drop packets at the border.
Of course they will not update said lists and load year old lists into
their firewalls.

So now my users can not access government sites because the IP ranges were
owned by a company in a different country two years ago.

Take a guess on how responsive site owners are when we complain about their
firewall. Most refuse to acknowledge they do any blocking and insist the
problem is at our end. That is if they respond at all.

Regards,

Baldur


On 25 December 2015 at 02:25, Stephen Satchell  wrote:

> On 12/24/2015 04:50 PM, Daniel Corbe wrote:
>
>> Let’s just cut off the entirety of the third world instead of having
>> a tangible mitigation plan in place.
>>
>
> While you thing you are making a snarky response, it would be handy for
> end users to be able to turn on and off access to other countries retail.
> If *they* don't need access to certain third world countries, it would be
> their decision, not the operator's decision.
>
> For example, here on my little network we have no need for connectivity to
> much of Asia, Africa, or India.  We do have need to talk to Europe,
> Australia, and some countries in South America.
>
>

Re: de-peering for security sake

[Stephen Satchell]

On 12/24/2015 04:50 PM, Daniel Corbe wrote:

Let’s just cut off the entirety of the third world instead of having
a tangible mitigation plan in place.


While you thing you are making a snarky response, it would be handy for 
end users to be able to turn on and off access to other countries 
retail.  If *they* don't need access to certain third world countries, 
it would be their decision, not the operator's decision.


For example, here on my little network we have no need for connectivity 
to much of Asia, Africa, or India.  We do have need to talk to Europe, 
Australia, and some countries in South America.

Re: de-peering for security sake

[Daniel Corbe]

Let’s just cut off the entirety of the third world instead of having a tangible 
mitigation plan in place.

> On Dec 24, 2015, at 6:44 PM, Colin Johnston  wrote:
> 
> see
> http://map.norsecorp.com
> 
> We really need to ask if China and Russia for that matter will not take abuse 
> reports seriously why allow them to network to the internet ?
> 
> Colin
> 

Re: de-peering for security sake

[Valdis . Kletnieks]

On Thu, 24 Dec 2015 23:44:10 +, Colin Johnston said:
> We really need to ask if China and Russia for that matter will not take abuse
> reports seriously why allow them to network to the internet ?

Well, first off, it isn't like China or Russia are just one ASN.  You'd have
to de-peer a bunch of ASN's - and also eliminate any paid transit connections.

Note that even North Korea has managed to land at least a small presence on
the Internet.  Are you going to ban them too?

While we're banning countries, how about the country that's known for
widespread surveillance both foreign and domestic, has one of the strongest
cyber warfare arsenals around, and has been caught multiple times diverting and
backdooring routers sold to foreign countries?

Oh wait, that's the US. Maybe we better rethink this?

Obviously, there's a lot of organizations that think that being able to
communicate with China and Russia outweighs the security issues.  You are
of course welcome to make a list of all Russian and Chinese ASNs and block
their prefixes at your border.


pgpqI8bdHjqAm.pgp
Description: PGP signature

de-peering for security sake

[Colin Johnston]

see
http://map.norsecorp.com

We really need to ask if China and Russia for that matter will not take abuse 
reports seriously why allow them to network to the internet ?

Colin