Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Mark Tinka]

On 9/Nov/18 02:22, Todd Underwood wrote:

>
> i generally find it amusing when people from other countries mock the
> US for not having PINs.  this is just another way of saying "my
> country has high fraud rates and yours appears not to."  :-) . you can
> see this in the comment below "If we were swipe-based here, we'd all be
> broke :-).".  the payments systems are architected to minimize cost
> and maximize adoption and they are usually at (or moving towards) some
> locally optimal point.  the US is no exception in that.

That was me - and "low" (fraud rates) is not "zero" (fraud rates).

Personally, I don't want to add to the statistic. The inconvenience
isn't worth the bragging right :-)...

Mark.

Re: CVV

[Simon Leinen]

Todd Underwood writes:
> [interesting and plausible reasoning about why no chip in US]
> anyway, let's talk about networks, no?

This topic is obviously "a little" off-topic, but I find some
contributions (like yours) relevant for understanding adoption dynamics
(or not) of proposed security mechanisms on the Internet (RPKI, route
filtering in general, DNSSEC etc.).

In general the regulatory environment in the Internet is quite different
from that of the financial sector.  But I guess credit-card security
trade-offs are still made mostly by private actors.
(Maybe they sometimes discuss BGP security on their mailing lists :-)
-- 
Simon.

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Chris Adams]

Once upon a time, Scott Christopher  said:
> Swipe-and-sign (and now just swipe for small amounts) is for Visa, 
> Mastercard, Discover transactions (called credit)

Signatures are no longer required for chip card transactions in the US,
except I think for transactions where the auth is done on the amount
before an added tip (restaurants).

> Skimming and card fraud is actually uncommon in the U.S. these days, and the 
> police are very effective at combating it. It's just cheaper for the industry 
> to eat fraud losses than to "upgrade" systems. The transition to chip-based 
> cards was a debacle.

Skimming is still highly active at gas pumps, where chip support was
pushed off (current requirement I believe is late 2020, but may be
delayed again).

The skimmers get more creative all the time; they're getting inside
pumps (possibly with help of low-paid station attendants, but also
because of poor physical security) and installing the skimmer hardware
out of sight.  The hardware has Bluetooth, so the bad guys just pull up
and get gas and someone in the car can retrieve the data (from multiple
pumps even).

-- 
Chris Adams 

Re: Amazon now controls 3.0.0.0/8

[Steve Meuse]

It's still in use, I believe Level(3)/CenturyLink uses it for either their
VPN or Voice network.

-Steve

On Thu, Nov 8, 2018 at 9:44 PM Ross Tajvar  wrote:

> Speaking of AS1 - I've been wondering, what's it being used for? It looks
> like Level3 owns it, and it's announcing a handful of prefixes and peering
> with a bunch of random ASes from many different countries.
>
> On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse  wrote:
>
>>
>> John Orthoefer and I (and dozens of other BBN folks on this list) both
>> worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned.
>> John was one of the folks who built and ran that system.
>>
>> So when he said "I wish we could have used 4.4.4.4" and my comment of "I
>> think the dial modem folks beat us to..." was referring to the fact that
>> when 4/8 was first being deployed on AS1 we started assigning blocks to
>> various groups and they realized that 4.4.4.0/XX had already been
>> delegated to another internal group (I think it was the dial group).
>>
>>
>>
>> On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher  wrote:
>>
>>> 4.0.0.0/8 has been GTE/Level3 forever.
>>>
>>> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember.
>>>
>>> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood 
>>> wrote:
>>>
 google used 4.4.4.4 for DNS in the past (2010, IIRC).

 t

 On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:

>
> I think it was the dial modem team that beat us to 4.4.4.0/24?
>
> -Steve
>
> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer 
> wrote:
>
>> I wish we could have used 4.4.4.4. Although at the time I suspect we
>> would have used 4.4.4.[123].
>>
>> Johno
>>
>> On Nov 8, 2018, at 18:58, Matt Erculiani 
>> wrote:
>>
>> So it looks like GE will be solvent for a few more years and 3.3.3.3
>> DNS is incoming.
>>
>> -Matt
>>
>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >
>>> https://news.ycombinator.com/item?id=18407173
>>>
>>> Quoting from the post:
>>>
>>> "
>>>
>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>>>
>>> Previous owner was GE.
>>>
>>> Anecdotal reports across the Internet that AWS EIPs are now being
>>> assigned in that range.
>>>
>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>>>
>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>>> "
>>>
>>>
>>>
>>>
>

Re: Amazon now controls 3.0.0.0/8

[Ross Tajvar]

Speaking of AS1 - I've been wondering, what's it being used for? It looks
like Level3 owns it, and it's announcing a handful of prefixes and peering
with a bunch of random ASes from many different countries.

On Thu, Nov 8, 2018 at 9:19 PM, Steve Meuse  wrote:

>
> John Orthoefer and I (and dozens of other BBN folks on this list) both
> worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned.
> John was one of the folks who built and ran that system.
>
> So when he said "I wish we could have used 4.4.4.4" and my comment of "I
> think the dial modem folks beat us to..." was referring to the fact that
> when 4/8 was first being deployed on AS1 we started assigning blocks to
> various groups and they realized that 4.4.4.0/XX had already been
> delegated to another internal group (I think it was the dial group).
>
>
>
> On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher  wrote:
>
>> 4.0.0.0/8 has been GTE/Level3 forever.
>>
>> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember.
>>
>> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood 
>> wrote:
>>
>>> google used 4.4.4.4 for DNS in the past (2010, IIRC).
>>>
>>> t
>>>
>>> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:
>>>

 I think it was the dial modem team that beat us to 4.4.4.0/24?

 -Steve

 On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:

> I wish we could have used 4.4.4.4. Although at the time I suspect we
> would have used 4.4.4.[123].
>
> Johno
>
> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>
> So it looks like GE will be solvent for a few more years and 3.3.3.3
> DNS is incoming.
>
> -Matt
>
> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke 
>> https://news.ycombinator.com/item?id=18407173
>>
>> Quoting from the post:
>>
>> "
>>
>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>>
>> Previous owner was GE.
>>
>> Anecdotal reports across the Internet that AWS EIPs are now being
>> assigned in that range.
>>
>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>>
>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>> "
>>
>>
>>
>>

Re: Amazon now controls 3.0.0.0/8

[Matt Perkins]

3.141.59.27  might be handy.


Matt

On 9/11/18 1:22 pm, Dan Lowe wrote:

Maybe Amazon will do something cool with 3.1.33.7 ...

dan


On Thu, Nov 8, 2018, at 8:30 PM, Todd Underwood wrote:

google used 4.4.4.4 for DNS in the past (2010, IIRC).

t

On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse > wrote:



I think it was the dial modem team that beat us to 4.4.4.0/24
?

-Steve

On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer mailto:j...@direwolf.com>> wrote:


I wish we could have used 4.4.4.4. Although at the time I
suspect we would have used 4.4.4.[123].

Johno

On Nov 8, 2018, at 18:58, Matt Erculiani
mailto:merculi...@gmail.com>> wrote:

So it looks like GE will be solvent for a few more years and
3.3.3.3 DNS is incoming.

-Matt

On Thu, Nov 8, 2018, 17:54 Eric Kuhnke
mailto:eric.kuh...@gmail.com> wrote:

https://news.ycombinator.com/item?id=18407173

Quoting from the post:

"


Apparently bought in two chunks: 3.0.0.0/9
 and 3.128.0.0/9 .

Previous owner was GE.

Anecdotal reports across the Internet that AWS EIPs are
now being assigned in that range.

https://whois.arin.net/rest/net/NET-3-0-0-0-1.html

https://whois.arin.net/rest/net/NET-3-128-0-0-1.html

"







--
/* Matt Perkins
Direct 1300 137 379Spectrum Networks Ptd. Ltd.
Office 1300 133 299m...@spectrum.com.au
   Level 6, 350 George Street Sydney 2000
Spectrum Networks is a member of the Communications Alliance & TIO
*/

Re: Amazon now controls 3.0.0.0/8

[Dan Lowe]

Maybe Amazon will do something cool with 3.1.33.7 ...

dan


On Thu, Nov 8, 2018, at 8:30 PM, Todd Underwood wrote:
> google used 4.4.4.4 for DNS in the past (2010, IIRC).
> 
> t
> 
> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:
>> 
>> I think it was the dial modem team that beat us to 4.4.4.0/24? 
>> 
>> -Steve
>> 
>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer
>>  wrote:>>> 
>>> I wish we could have used 4.4.4.4. Although at the time I suspect we
>>> would have used 4.4.4.[123].>>> 
>>> Johno 
>>> 
>>> On Nov 8, 2018, at 18:58, Matt Erculiani 
>>> wrote: So it looks like GE will be solvent for a few more years and
 3.3.3.3 DNS is incoming. 
 -Matt
 
 On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>> wrote:> https://news.ycombinator.com/item?id=18407173
> 
> Quoting from the post:
> 
> "
> 
> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
> Previous owner was GE.


> Anecdotal reports across the Internet that AWS EIPs are now being
> assigned in that range.> 
> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html


> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html


> "
> 
> 
> 

Re: Amazon now controls 3.0.0.0/8

[Steve Meuse]

John Orthoefer and I (and dozens of other BBN folks on this list) both
worked for BBNPlanet at the time that 4.2.2.1 and 4.2.2.2 were assigned.
John was one of the folks who built and ran that system.

So when he said "I wish we could have used 4.4.4.4" and my comment of "I
think the dial modem folks beat us to..." was referring to the fact that
when 4/8 was first being deployed on AS1 we started assigning blocks to
various groups and they realized that 4.4.4.0/XX had already been delegated
to another internal group (I think it was the dial group).



On Thu, Nov 8, 2018 at 8:45 PM Tom Beecher  wrote:

> 4.0.0.0/8 has been GTE/Level3 forever.
>
> 4.2.2.1 - 6 have been L3 DNS as far back as I can remember.
>
> On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood  wrote:
>
>> google used 4.4.4.4 for DNS in the past (2010, IIRC).
>>
>> t
>>
>> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:
>>
>>>
>>> I think it was the dial modem team that beat us to 4.4.4.0/24?
>>>
>>> -Steve
>>>
>>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:
>>>
 I wish we could have used 4.4.4.4. Although at the time I suspect we
 would have used 4.4.4.[123].

 Johno

 On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:

 So it looks like GE will be solvent for a few more years and 3.3.3.3
 DNS is incoming.

 -Matt

 On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>>
> https://news.ycombinator.com/item?id=18407173
>
> Quoting from the post:
>
> "
>
> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>
> Previous owner was GE.
>
> Anecdotal reports across the Internet that AWS EIPs are now being
> assigned in that range.
>
> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>
> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
> "
>
>
>
>

Re: Amazon network engineering contact? re: DDoS traffic

[Daniel Corbe]

at 8:40 PM, Tom Beecher  wrote:

Nobody should ever be forced to peer to get someone to address abusive  
traffic originating from networks under their control.





Especially considering the fact that Amazon is just a bit selective about  
their peers.  Though, the size of our border probably had a lot to do with  
the fact that we didn’t get a response the first time when we requested  
peering for our 10s of megabits of traffic, we none the less didn’t get a  
response the first time we tried.   Not even a “go away until you have some  
traffic of significance.”


In the end, we had to implore a back channel to get a peering session set up.

Re: Amazon now controls 3.0.0.0/8

[Royce Williams]

Obligatory list of all known same-quad servers and their DNS status -
corrections welcome:

https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1

If there is info about previous/historical use of these IPs, I'd like to
find a way to incorporate that as well.

-- 
Royce


On Thu, Nov 8, 2018 at 4:31 PM Todd Underwood  wrote:

> google used 4.4.4.4 for DNS in the past (2010, IIRC).
>
> t
>
> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:
>
>>
>> I think it was the dial modem team that beat us to 4.4.4.0/24?
>>
>> -Steve
>>
>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:
>>
>>> I wish we could have used 4.4.4.4. Although at the time I suspect we
>>> would have used 4.4.4.[123].
>>>
>>> Johno
>>>
>>> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>>>
>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS
>>> is incoming.
>>>
>>> -Matt
>>>
>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>
 https://news.ycombinator.com/item?id=18407173

 Quoting from the post:

 "

 Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.

 Previous owner was GE.

 Anecdotal reports across the Internet that AWS EIPs are now being
 assigned in that range.

 https://whois.arin.net/rest/net/NET-3-0-0-0-1.html

 https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
 "

Re: Amazon now controls 3.0.0.0/8

[Tom Beecher]

4.0.0.0/8 has been GTE/Level3 forever.

4.2.2.1 - 6 have been L3 DNS as far back as I can remember.

On Thu, Nov 8, 2018 at 8:32 PM Todd Underwood  wrote:

> google used 4.4.4.4 for DNS in the past (2010, IIRC).
>
> t
>
> On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:
>
>>
>> I think it was the dial modem team that beat us to 4.4.4.0/24?
>>
>> -Steve
>>
>> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:
>>
>>> I wish we could have used 4.4.4.4. Although at the time I suspect we
>>> would have used 4.4.4.[123].
>>>
>>> Johno
>>>
>>> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>>>
>>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS
>>> is incoming.
>>>
>>> -Matt
>>>
>>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >>
 https://news.ycombinator.com/item?id=18407173

 Quoting from the post:

 "

 Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.

 Previous owner was GE.

 Anecdotal reports across the Internet that AWS EIPs are now being
 assigned in that range.

 https://whois.arin.net/rest/net/NET-3-0-0-0-1.html

 https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
 "

Re: Amazon network engineering contact? re: DDoS traffic

[Tom Beecher]

Nobody should ever be forced to peer to get someone to address abusive
traffic originating from networks under their control.



On Thu, Nov 8, 2018 at 4:29 PM John  wrote:

> Zach,
>
> As mentioned before, I am open to peering (where possible) but have not
> received a response.
>
> My goal is to connect with someone at Amazon and work with them on a
> technical solution, which is why I posted asking for that here. Various
> factors mean that we can't just upgrade our way out of this one, and
> manual whac-a-mole on the sources has shown to have limited use.
>
> These attacks also impact Amazon and the networks in between the sources
> and targets, and they take time to handle by the abuse teams, so there
> are good reasons to investigate them further and find better ways to
> mitigate or prevent them.
>
> -John
>
> On 11/8/2018 1:12 PM, Zach Puls wrote:
> > Makes sense, that's understandable. Do you peer with AWS? If not, maybe
> opening up a peering agreement will give you a better contact, and a bit
> more pull when attacks occur? I know someone with a peering agreement with
> AWS, and they have been able to get resolutions fairly quickly when issues
> arise.
> >
> > Other than that, I'm not sure of a solution other than more IP transit.
> >
> > Thanks,
> >
> > Zach Puls
> > Network Engineer | MEF-CECP
> > KsFiberNet
> >
> > -Original Message-
> > From: John Weekes 
> > Sent: Thursday, November 08, 2018 15:03
> > To: Zach Puls 
> > Cc: nanog@nanog.org
> > Subject: Re: Amazon network engineering contact? re: DDoS traffic
> >
> > Zach,
> >
> > Yes, RTBH is used to distribute the null-routes that I mentioned.
> >
> > Unfortunately, even brief saturation events lasting just 5-10 seconds (a
> typical amount of time to detect the loss, issue the null-route, and see
> the traffic start to fall off as it is distributed upstream) can cause real
> damage to those customers who are sensitive to latency and packet loss. So
> while null-routes limit the duration of the impact, they can't eliminate it
> entirely. And, of course, the actual target of the attack
> > -- the now-null-routed IP address -- becomes unreachable, which was
> presumably the goal of the attacker.
> >
> > -John
> >
> > On 11/8/2018 12:54 PM, Zach Puls wrote:
> >> No idea about an Amazon abuse contact, but do you have RTBH communities
> enabled with your upstream provider(s)? As a general practice, when you
> detect a (D)DoS attack in progress, it would help to automatically
> advertise that prefix to your upstream(s) with the black-hole community.
> This would at least help mitigate the effects of the attacks when they do
> occur, even if they come from a different source than AWS.
> >>
> >> Thanks,
> >>
> >> Zach Puls
> >> Network Engineer | MEF-CECP
> >> KsFiberNet
> >>
> >> -Original Message-
> >> From: NANOG  On Behalf Of John Weekes
> >> Sent: Thursday, November 08, 2018 14:44
> >> To: nanog@nanog.org
> >> Subject: Amazon network engineering contact? re: DDoS traffic
> >>
> >> We've been seeing significant attack activity from Amazon over the last
> two months, involving apparently compromised instances that commonly send
> 1-10G of traffic per source and together generate Nx10G of total traffic.
> Even when our overall upstream capacity exceeds an attack's overall size,
> the nature of load-balancing over multiple 10G upstream links means that an
> individual link can be saturated by multiple large flows, forcing our
> systems to null-route the target to limit impact.
> >>
> >> We've sent an abuse notification about every traffic source to Amazon,
> and specific sources seem to stop their involvement over time (suggesting
> that abuse teams are following up on them), but there is an endless parade
> of new attackers, and each source participates in many damaging attacks
> before it is shut down.
> >>
> >> Is there anyone at Amazon who can help with an engineering solution in
> terms of programmatically detecting and rate-limiting attack traffic
> sources, to our networks or overall? Or applying the kludge of a rate-limit
> for all Amazon traffic to our networks? Or working with us on some other
> option?
> >>
> >> At least one other large cloud provider has an automatic rate-limiting
> system in place that is effective in reducing the damage from repeat
> high-volume attacks.
> >>
> >> Emails to the Amazon NOC, peering contacts (since that would be another
> possible solution), and abuse department have not connected me with anyone.
> >>
> >> Thanks,
> >> John
> >>
> >
>
>

Re: Amazon now controls 3.0.0.0/8

[Todd Underwood]

google used 4.4.4.4 for DNS in the past (2010, IIRC).

t

On Thu, Nov 8, 2018 at 8:21 PM Steve Meuse  wrote:

>
> I think it was the dial modem team that beat us to 4.4.4.0/24?
>
> -Steve
>
> On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:
>
>> I wish we could have used 4.4.4.4. Although at the time I suspect we
>> would have used 4.4.4.[123].
>>
>> Johno
>>
>> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>>
>> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS
>> is incoming.
>>
>> -Matt
>>
>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke >
>>> https://news.ycombinator.com/item?id=18407173
>>>
>>> Quoting from the post:
>>>
>>> "
>>>
>>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>>>
>>> Previous owner was GE.
>>>
>>> Anecdotal reports across the Internet that AWS EIPs are now being
>>> assigned in that range.
>>>
>>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>>>
>>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>>> "
>>>
>>>
>>>
>>>

Re: Amazon now controls 3.0.0.0/8

[Steve Meuse]

I think it was the dial modem team that beat us to 4.4.4.0/24?

-Steve

On Thu, Nov 8, 2018 at 7:44 PM John Orthoefer  wrote:

> I wish we could have used 4.4.4.4. Although at the time I suspect we would
> have used 4.4.4.[123].
>
> Johno
>
> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>
> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS
> is incoming.
>
> -Matt
>
> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke 
>> https://news.ycombinator.com/item?id=18407173
>>
>> Quoting from the post:
>>
>> "
>>
>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>>
>> Previous owner was GE.
>>
>> Anecdotal reports across the Internet that AWS EIPs are now being
>> assigned in that range.
>>
>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>>
>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>> "
>>
>>
>>
>>

Re: Amazon now controls 3.0.0.0/8

[Eric Kuhnke]

3.4.5.6/24 could be an interesting block to put easily memorable IP
services in...



On Thu, Nov 8, 2018 at 4:44 PM John Orthoefer  wrote:

> I wish we could have used 4.4.4.4. Although at the time I suspect we would
> have used 4.4.4.[123].
>
> Johno
>
> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
>
> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS
> is incoming.
>
> -Matt
>
> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke 
>> https://news.ycombinator.com/item?id=18407173
>>
>> Quoting from the post:
>>
>> "
>>
>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>>
>> Previous owner was GE.
>>
>> Anecdotal reports across the Internet that AWS EIPs are now being
>> assigned in that range.
>>
>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>>
>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>> "
>>
>>
>>
>>

Re: Amazon now controls 3.0.0.0/8

[John Orthoefer]

I wish we could have used 4.4.4.4. Although at the time I suspect we would have 
used 4.4.4.[123]. 

Johno 

> On Nov 8, 2018, at 18:58, Matt Erculiani  wrote:
> 
> So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS is 
> incoming.
> 
> -Matt
> 
>> On Thu, Nov 8, 2018, 17:54 Eric Kuhnke > https://news.ycombinator.com/item?id=18407173
>> 
>> Quoting from the post:
>> 
>> "
>> 
>> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>> Previous owner was GE.
>> 
>> Anecdotal reports across the Internet that AWS EIPs are now being assigned 
>> in that range.
>> 
>> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>> 
>> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
>> 
>> "
>> 
>> 
>> 

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Todd Underwood]

This is a confusing and off-topic discussion with respect to network
engineering.

But for completeness:

Payments systems are architected by fraud rates, not by isolated security
requirements or engineering mandates, as i think most network engineers can
understand.

The fraud rates in the US for credit card transactions were historically
very, very low and being a large jurisdiction with a single national law
enforcement branch (the FBI) enforcement was effective.

Compare this to Europe in the 1980s when credit cards were accepted very
few places.  This was for two reasons:

1) the fraud rates were much, much higher, which created chargebacks for
merchants that they preferred not to eat;
2) trans-national enforcement was virtually nonexistent. interpol had ~zero
time to deal with credit card fraud.

so the best european fraud rings always operated from a different country
than where they perpetrated the fraud.

when chip-and-pin was introduced, the point was actually twofold:
A) security
B) shifting liability to the consumer

somewhat famously, even after chip-and-pin was proven compromised, UK banks
continued to make consumers liable for all fraudulent transactions that
were 'pin used'.  this was very, very good for the adoption of credit cards
in europe but it was very, very bad for a few people.  banks, as usual,
didn't are and made some decent money.

So why did the US get pin-and-signature?  Target.

International fraud rings finally got wise to the ripe opportunity that was
the soft underbelly of the US economy and figured out ways to perpetrate
massive, trans-national fraud in the US.  and as soon as that happened, the
US got chips.  the signature-vs-pin part is mostly about the fact that
there are *still* low rates of fraud here as tracked by chargeback rates
and as a result there's no real need to pay the cost of support to set
everyone up with a pin.

and that's what security is always all about:  cost tradeoffs.  people in
countries where everyone has a pin have eaten that cost already and had to
because the fraud rates were high enough to justify it.  people in the US
do not have PINs that they know and setting those up costs money and
maintaining people's access to them costs money.  so if that's not worth
it, it doesn't get done. nor should it.

i generally find it amusing when people from other countries mock the US
for not having PINs.  this is just another way of saying "my country has
high fraud rates and yours appears not to."  :-) . you can see this in the
comment below "If we were swipe-based here, we'd all be
broke :-).".  the payments systems are architected to minimize cost and
maximize adoption and they are usually at (or moving towards) some locally
optimal point.  the US is no exception in that.

now, the checking/chequing system is a whole other, embarrassing beast and
mocking that one is just the correct thing to do. :-)

anyway, let's talk about networks, no?

cheers,

t

On Thu, Nov 8, 2018, 19:07 Frank Bulk  I have a low-cost/high interest rate account at one of the Canadian bank
> and each "assisted" transaction is $5.
>
> Frank
>
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: Thursday, November 08, 2018 3:35 AM
> To: George Michaelson 
> Cc: North American Network Operators' Group 
> Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling)
>
> 
> Speaking of "cost" as a motivator, in South Africa, most of the banks
> are now using extra fees as a way to force users to do their banking
> online (phone, laptop, app, e.t.c.). If you want to walk into a bank to
> deposit money, withdraw money, make a transfer, e.t.c., you pay for that
> service over and above, while the process costs you zero (0) when done
> online. This has led to banks now renovating banking halls into where
> there was once 23 tellers, you now have 1 service usher, 1 teller, 2
> support agents and 20 self-service computers.
>
> I hope the U.S. does catch-up. If we were swipe-based here, we'd all be
> broke :-). I know a number of major merchants in the U.S. now use PIN's,
> and I always stick to those when I travel there.
>
> Mark.
>
>
>
>

RE: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Frank Bulk]

I have a low-cost/high interest rate account at one of the Canadian bank and 
each "assisted" transaction is $5.

Frank 

-Original Message-
From: NANOG  On Behalf Of Mark Tinka
Sent: Thursday, November 08, 2018 3:35 AM
To: George Michaelson 
Cc: North American Network Operators' Group 
Subject: Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

Re: Amazon now controls 3.0.0.0/8

[Matt Erculiani]

So it looks like GE will be solvent for a few more years and 3.3.3.3 DNS is
incoming.

-Matt

On Thu, Nov 8, 2018, 17:54 Eric Kuhnke  https://news.ycombinator.com/item?id=18407173
>
> Quoting from the post:
>
> "
>
> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>
> Previous owner was GE.
>
> Anecdotal reports across the Internet that AWS EIPs are now being assigned
> in that range.
>
> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>
> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
> "
>
>
>
>

Re: Amazon now controls 3.0.0.0/8

[Job Snijders]

On Fri, Nov 9, 2018 at 0:54 Eric Kuhnke  wrote:

> https://news.ycombinator.com/item?id=18407173
>
> Quoting from the post:
>
> "
>
> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>
> Previous owner was GE.
>
> Anecdotal reports across the Internet that AWS EIPs are now being assigned
> in that range.
>
> https://whois.arin.net/rest/net/NET-3-0-0-0-1.html
>
> https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
> "
>


Seems ALTDB should delete the old AS 80 / GE IRR proxy route registration:
http://irrexplorer.nlnog.net/search/3.0.0.0

Kind regards,

Job

>

Amazon now controls 3.0.0.0/8

[Eric Kuhnke]

https://news.ycombinator.com/item?id=18407173

Quoting from the post:

"

Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.

Previous owner was GE.

Anecdotal reports across the Internet that AWS EIPs are now being assigned
in that range.

https://whois.arin.net/rest/net/NET-3-0-0-0-1.html

https://whois.arin.net/rest/net/NET-3-128-0-0-1.html
"

FCC Launches Re-Examination of Wireless Resiliency Cooperative Framework In Light of Recent Hurricanes

[Sean Donelan]

The public, first responders and other service providers can also submit 
comments to the FCC.




https://www.fcc.gov/document/fcc-seeks-industry-input-review-wireless-resiliency-framework

To that end, Chief Fowlkes’ letters ask wireless companies participating 
in the framework to summarize how it was used for all disaster events to 
which the framework applied. The letters request detailed lists of mutual 
aid and roaming agreements carriers have established with each other, as 
well as any instances where such agreements were modified, impeded, or 
even declined outright. The agency also asks for information as to each 
company’s implementation of industry best practices.

Re: Amazon network engineering contact? re: DDoS traffic

[John]

Zach,

As mentioned before, I am open to peering (where possible) but have not 
received a response.


My goal is to connect with someone at Amazon and work with them on a 
technical solution, which is why I posted asking for that here. Various 
factors mean that we can't just upgrade our way out of this one, and 
manual whac-a-mole on the sources has shown to have limited use.


These attacks also impact Amazon and the networks in between the sources 
and targets, and they take time to handle by the abuse teams, so there 
are good reasons to investigate them further and find better ways to 
mitigate or prevent them.


-John

On 11/8/2018 1:12 PM, Zach Puls wrote:

Makes sense, that's understandable. Do you peer with AWS? If not, maybe opening 
up a peering agreement will give you a better contact, and a bit more pull when 
attacks occur? I know someone with a peering agreement with AWS, and they have 
been able to get resolutions fairly quickly when issues arise.

Other than that, I'm not sure of a solution other than more IP transit.

Thanks,

Zach Puls
Network Engineer | MEF-CECP
KsFiberNet

-Original Message-
From: John Weekes 
Sent: Thursday, November 08, 2018 15:03
To: Zach Puls 
Cc: nanog@nanog.org
Subject: Re: Amazon network engineering contact? re: DDoS traffic

Zach,

Yes, RTBH is used to distribute the null-routes that I mentioned.

Unfortunately, even brief saturation events lasting just 5-10 seconds (a 
typical amount of time to detect the loss, issue the null-route, and see the 
traffic start to fall off as it is distributed upstream) can cause real damage 
to those customers who are sensitive to latency and packet loss. So while 
null-routes limit the duration of the impact, they can't eliminate it entirely. 
And, of course, the actual target of the attack
-- the now-null-routed IP address -- becomes unreachable, which was presumably 
the goal of the attacker.

-John

On 11/8/2018 12:54 PM, Zach Puls wrote:

No idea about an Amazon abuse contact, but do you have RTBH communities enabled 
with your upstream provider(s)? As a general practice, when you detect a (D)DoS 
attack in progress, it would help to automatically advertise that prefix to 
your upstream(s) with the black-hole community. This would at least help 
mitigate the effects of the attacks when they do occur, even if they come from 
a different source than AWS.

Thanks,

Zach Puls
Network Engineer | MEF-CECP
KsFiberNet

-Original Message-
From: NANOG  On Behalf Of John Weekes
Sent: Thursday, November 08, 2018 14:44
To: nanog@nanog.org
Subject: Amazon network engineering contact? re: DDoS traffic

We've been seeing significant attack activity from Amazon over the last two 
months, involving apparently compromised instances that commonly send 1-10G of 
traffic per source and together generate Nx10G of total traffic. Even when our 
overall upstream capacity exceeds an attack's overall size, the nature of 
load-balancing over multiple 10G upstream links means that an individual link 
can be saturated by multiple large flows, forcing our systems to null-route the 
target to limit impact.

We've sent an abuse notification about every traffic source to Amazon, and 
specific sources seem to stop their involvement over time (suggesting that 
abuse teams are following up on them), but there is an endless parade of new 
attackers, and each source participates in many damaging attacks before it is 
shut down.

Is there anyone at Amazon who can help with an engineering solution in terms of 
programmatically detecting and rate-limiting attack traffic sources, to our 
networks or overall? Or applying the kludge of a rate-limit for all Amazon 
traffic to our networks? Or working with us on some other option?

At least one other large cloud provider has an automatic rate-limiting system 
in place that is effective in reducing the damage from repeat high-volume 
attacks.

Emails to the Amazon NOC, peering contacts (since that would be another 
possible solution), and abuse department have not connected me with anyone.

Thanks,
John

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Scott Christopher]

Mark Tinka wrote: 

> I hope the U.S. does catch-up. If we were swipe-based here, we'd all be
> broke :-). I know a number of major merchants in the U.S. now use PIN's,
> and I always stick to those when I travel there.

In the U.S., pin codes are required for EFTPOS transactions (called debit) over 
interbank networks like Pulse, STAR, etc

Swipe-and-sign (and now just swipe for small amounts) is for Visa, Mastercard, 
Discover transactions (called credit)

Skimming and card fraud is actually uncommon in the U.S. these days, and the 
police are very effective at combating it. It's just cheaper for the industry 
to eat fraud losses than to "upgrade" systems. The transition to chip-based 
cards was a debacle.

-- 
S.C.

Re: Amazon network engineering contact? re: DDoS traffic

[John Weekes]

Zach,

Yes, RTBH is used to distribute the null-routes that I mentioned.

Unfortunately, even brief saturation events lasting just 5-10 seconds (a 
typical amount of time to detect the loss, issue the null-route, and see 
the traffic start to fall off as it is distributed upstream) can cause 
real damage to those customers who are sensitive to latency and packet 
loss. So while null-routes limit the duration of the impact, they can't 
eliminate it entirely. And, of course, the actual target of the attack 
-- the now-null-routed IP address -- becomes unreachable, which was 
presumably the goal of the attacker.


-John

On 11/8/2018 12:54 PM, Zach Puls wrote:

No idea about an Amazon abuse contact, but do you have RTBH communities enabled 
with your upstream provider(s)? As a general practice, when you detect a (D)DoS 
attack in progress, it would help to automatically advertise that prefix to 
your upstream(s) with the black-hole community. This would at least help 
mitigate the effects of the attacks when they do occur, even if they come from 
a different source than AWS.

Thanks,

Zach Puls
Network Engineer | MEF-CECP
KsFiberNet

-Original Message-
From: NANOG  On Behalf Of John Weekes
Sent: Thursday, November 08, 2018 14:44
To: nanog@nanog.org
Subject: Amazon network engineering contact? re: DDoS traffic

We've been seeing significant attack activity from Amazon over the last two 
months, involving apparently compromised instances that commonly send 1-10G of 
traffic per source and together generate Nx10G of total traffic. Even when our 
overall upstream capacity exceeds an attack's overall size, the nature of 
load-balancing over multiple 10G upstream links means that an individual link 
can be saturated by multiple large flows, forcing our systems to null-route the 
target to limit impact.

We've sent an abuse notification about every traffic source to Amazon, and 
specific sources seem to stop their involvement over time (suggesting that 
abuse teams are following up on them), but there is an endless parade of new 
attackers, and each source participates in many damaging attacks before it is 
shut down.

Is there anyone at Amazon who can help with an engineering solution in terms of 
programmatically detecting and rate-limiting attack traffic sources, to our 
networks or overall? Or applying the kludge of a rate-limit for all Amazon 
traffic to our networks? Or working with us on some other option?

At least one other large cloud provider has an automatic rate-limiting system 
in place that is effective in reducing the damage from repeat high-volume 
attacks.

Emails to the Amazon NOC, peering contacts (since that would be another 
possible solution), and abuse department have not connected me with anyone.

Thanks,
John

Amazon network engineering contact? re: DDoS traffic

[John Weekes]

We've been seeing significant attack activity from Amazon over the last 
two months, involving apparently compromised instances that commonly 
send 1-10G of traffic per source and together generate Nx10G of total 
traffic. Even when our overall upstream capacity exceeds an attack's 
overall size, the nature of load-balancing over multiple 10G upstream 
links means that an individual link can be saturated by multiple large 
flows, forcing our systems to null-route the target to limit impact.


We've sent an abuse notification about every traffic source to Amazon, 
and specific sources seem to stop their involvement over time 
(suggesting that abuse teams are following up on them), but there is an 
endless parade of new attackers, and each source participates in many 
damaging attacks before it is shut down.


Is there anyone at Amazon who can help with an engineering solution in 
terms of programmatically detecting and rate-limiting attack traffic 
sources, to our networks or overall? Or applying the kludge of a 
rate-limit for all Amazon traffic to our networks? Or working with us on 
some other option?


At least one other large cloud provider has an automatic rate-limiting 
system in place that is effective in reducing the damage from repeat 
high-volume attacks.


Emails to the Amazon NOC, peering contacts (since that would be another 
possible solution), and abuse department have not connected me with anyone.


Thanks,
John

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Mark Tinka]

On 8/Nov/18 11:16, George Michaelson wrote:

> There are two parts of the problem. The first is the assumption of
> risk: the current model of operation in the US (like in other western
> economies) puts the onus of risk of misuse of the card on specific
> actors. When you change the basis from signature (fraud) to chip+pin
> (leak of knowledge) you have to change the legal basis. Remember, this
> is an economy where WRITING CHEQUES is still normal. Clearly, the
> legal basis of money transactions in the US is hugely complicated by
> savings and loan, credit unions, banks, state and federal law, taxes.
> We all have some of this worldwide, they have a LOT.
>
> Secondly, the cost basis. Who pays? In most of the world the regulator
> forced cost onto specific players because they could, and forced
> people to tool up because they could. But, the costs did have to get
> met. Some people paid more than others. In the US, for reasons not
> entirely unlike the first set, *making* people do things with cost
> incursion is remarkably difficult. Making the Walmart brothers re-fit
> every terminal, when they can go down to DC and buy votes to stop it
> happening, Making Bank of America spend money re-working its core
> finance models to suit online chip+pin when it can go down to Walmart
> and lean on the owners to go down to DC and buy votes...
>
> Seriously: Its not lack of clue. Its lack of intestinal political
> fortitude, and a very strange regulatory and federal/state model.

Shame, but I can see how this makes sense as to why things are the way
they are.

Speaking of "cost" as a motivator, in South Africa, most of the banks
are now using extra fees as a way to force users to do their banking
online (phone, laptop, app, e.t.c.). If you want to walk into a bank to
deposit money, withdraw money, make a transfer, e.t.c., you pay for that
service over and above, while the process costs you zero (0) when done
online. This has led to banks now renovating banking halls into where
there was once 23 tellers, you now have 1 service usher, 1 teller, 2
support agents and 20 self-service computers.

I hope the U.S. does catch-up. If we were swipe-based here, we'd all be
broke :-). I know a number of major merchants in the U.S. now use PIN's,
and I always stick to those when I travel there.

Mark.

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[George Michaelson]

There are two parts of the problem. The first is the assumption of
risk: the current model of operation in the US (like in other western
economies) puts the onus of risk of misuse of the card on specific
actors. When you change the basis from signature (fraud) to chip+pin
(leak of knowledge) you have to change the legal basis. Remember, this
is an economy where WRITING CHEQUES is still normal. Clearly, the
legal basis of money transactions in the US is hugely complicated by
savings and loan, credit unions, banks, state and federal law, taxes.
We all have some of this worldwide, they have a LOT.

Secondly, the cost basis. Who pays? In most of the world the regulator
forced cost onto specific players because they could, and forced
people to tool up because they could. But, the costs did have to get
met. Some people paid more than others. In the US, for reasons not
entirely unlike the first set, *making* people do things with cost
incursion is remarkably difficult. Making the Walmart brothers re-fit
every terminal, when they can go down to DC and buy votes to stop it
happening, Making Bank of America spend money re-working its core
finance models to suit online chip+pin when it can go down to Walmart
and lean on the owners to go down to DC and buy votes...

Seriously: Its not lack of clue. Its lack of intestinal political
fortitude, and a very strange regulatory and federal/state model.
On Thu, Nov 8, 2018 at 4:11 PM Mark Tinka  wrote:
>
>
>
> On 11/Oct/18 21:31, Chris Adams wrote:
>
> > Requiring an ID is also a violation of the merchant agreements, at least
> > for VISA and MasterCard (not sure about American Express), unless ID is
> > otherwise required by law (like for age-limited products).  I've walked
> > out of stores that required an ID.
>
> It has always been curious to me how/why the U.S., with one of the
> largest economies in the world, still do most card-based transactions as
> a swipe in lieu of a PIN-based approach.
>
> In South Africa (and most of southern Africa), all banks make the use of
> PIN's mandatory, for all types of cards. With the rest of Africa using
> credit cards more recently, I imagine they are also PIN-based.
>
> Europe also use PIN's, as far as I have experienced.
>
> Asia-Pac was swipe-based for a long time when I lived there, but I know
> places like Malaysia and Singapore have started a major PIN-based
> transaction drive in the past 3 years.
>
> 3D Secure for the online version of the transaction also means your card
> number and CVV number are less susceptible to fraud via restaurants and
> the like. Of course, this is not fool-proof, as both the merchant and
> bank need to support and mandate this, which is not well-done at a
> global level.
>
> Mark.
>
>

Re: CVV (was: Re: bloomberg on supermicro: sky is falling)

[Mark Tinka]

On 11/Oct/18 21:31, Chris Adams wrote:

> Requiring an ID is also a violation of the merchant agreements, at least
> for VISA and MasterCard (not sure about American Express), unless ID is
> otherwise required by law (like for age-limited products).  I've walked
> out of stores that required an ID.

It has always been curious to me how/why the U.S., with one of the
largest economies in the world, still do most card-based transactions as
a swipe in lieu of a PIN-based approach.

In South Africa (and most of southern Africa), all banks make the use of
PIN's mandatory, for all types of cards. With the rest of Africa using
credit cards more recently, I imagine they are also PIN-based.

Europe also use PIN's, as far as I have experienced.

Asia-Pac was swipe-based for a long time when I lived there, but I know
places like Malaysia and Singapore have started a major PIN-based
transaction drive in the past 3 years.

3D Secure for the online version of the transaction also means your card
number and CVV number are less susceptible to fraud via restaurants and
the like. Of course, this is not fool-proof, as both the merchant and
bank need to support and mandate this, which is not well-done at a
global level.

Mark.