Re: mail admins?

[Michael Thomas]

On 4/24/20 5:01 PM, Bryan Holloway wrote:

On 4/24/20 4:58 PM, Michael Thomas wrote:


On 4/23/20 8:48 PM, Matt Palmer wrote:

On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote:

On 4/23/20 7:35 PM, Matt Palmer wrote:
While I do think webauthn is a neat idea, and solves at least one 
very real
problem (credential theft via phishing), you do an absolutely 
terrible job

of making that case.
see RFC 4876, it is not about phishing. not even a little bit. 
Never has

been.
Whilst I do *absolutely* agree with you that "A Configuration 
Profile Schema
for Lightweight Directory Access Protocol (LDAP)-Based Agents" is 
"not about
phishing, not even a little bit", I'm not entirely sure how it 
advances your

argument.


sorry, 7486.

Mike



Shall we play a game?

https://en.wikipedia.org/wiki/Mastermind_(board_game)


The point is that shared passwords over the net have nothing to do with 
phishing per se, and everything to do with if I get one of your 
passwords, i get them all. phishing is one way to do that. but there are 
plenty of other ways too. gross incompetence as was the case of LinkedIn 
was my impetus hacking up a pre-webauthn which Steven and Paul happened 
to see which caused us to write our experimental RFC. We weren't think 
about phishing at all, or at least I wasn't.


Here's what i wrote about it in 2012.

https://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

Mike

Re: mail admins?

[Bryan Holloway]

On 4/24/20 4:58 PM, Michael Thomas wrote:


On 4/23/20 8:48 PM, Matt Palmer wrote:

On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote:

On 4/23/20 7:35 PM, Matt Palmer wrote:
While I do think webauthn is a neat idea, and solves at least one 
very real
problem (credential theft via phishing), you do an absolutely 
terrible job

of making that case.

see RFC 4876, it is not about phishing. not even a little bit. Never has
been.
Whilst I do *absolutely* agree with you that "A Configuration Profile 
Schema
for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not 
about
phishing, not even a little bit", I'm not entirely sure how it 
advances your

argument.


sorry, 7486.

Mike



Shall we play a game?

https://en.wikipedia.org/wiki/Mastermind_(board_game)

Re: Phishing and telemarketing telephone calls

[Jon Lewis]

On Fri, 24 Apr 2020, Matthew Black wrote:



Has anyone else noticed a steep decline in annoying phone calls since the FCC 
threatened legal action against three major VOIP gateways if they didn’t make 
efforts to prevent
Caller ID spoofing from scammers?


Not that it's at all on-topic for NANOG, but no.  I still get numerous 
"last chance to renew my car warranty" and whatever the scam is from the 
credit card callers per day on both my home and cell numbers.


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

RE: Phishing and telemarketing telephone calls

[Matthew Black]

Oh, never mind. I just saw a similar thread: FCC and FTC Demand Cut-Off 
Robercallers of Coronavirus Scam

The free Marriott vacation and Social Security Number suspension calls are no 
more!



From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Matthew Black
Sent: Friday, April 24, 2020 4:26 PM
To: North American Network Operators' Group
Subject: Phishing and telemarketing telephone calls

Has anyone else noticed a steep decline in annoying phone calls since the FCC 
threatened legal action against three major VOIP gateways if they didn't make 
efforts to prevent Caller ID spoofing from scammers?


Writing on behalf of myself and not any organization or employer. Please remove 
me from your mailing and contact lists.

Phishing and telemarketing telephone calls

[Matthew Black]

Has anyone else noticed a steep decline in annoying phone calls since the FCC 
threatened legal action against three major VOIP gateways if they didn't make 
efforts to prevent Caller ID spoofing from scammers?


Writing on behalf of myself and not any organization or employer. Please remove 
me from your mailing and contact lists.

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Bottiger]

I highly doubt NTT or any other major transit provider would ever cut off
Korea Telecom or China Telecom. And these are reflectors, they are not part
of a botnet.

On Thu, Apr 23, 2020 at 5:11 PM TJ Trout  wrote:

> Bottiger,
>
> If what you are saying is true and can be backed by documentation, I would
> start at the abuse contact for the offending 'Amplifier' and then start
> working your way up the transits of the offending AS# until someone cuts
> them off.
> The Squeaky wheel gets the grease!
>
> On Thu, Apr 23, 2020 at 3:33 PM Bottiger  wrote:
>
>> There are many decent options for ddos protection in the US and Europe,
>> however there are very few in Brazil and Asia that support BGP. Servers and
>> bandwidth in these areas are much more expensive.
>>
>> Even though we are already doing anycast to split up the ddos attack, a
>> majority of the attack traffic is now ending up in these expensive areas,
>> and to top it off, these ISPs won't respond to abuse emails.
>>
>> It makes me wonder what the point of these abuse email are and if the
>> regional registries have any power to force them to reply.
>>
>> On Thu, Apr 23, 2020 at 3:12 PM Compton, Rich A 
>> wrote:
>>
>>> Good luck with that.    As Damian Menscher has presented at NANOG,
>>> even if we do an amazing job and shut down 99% of all DDoS reflectors,
>>> there will still be enough bandwidth to generate terabit size attacks.
>>> https://stats.cybergreen.net
>>>
>>> I think we need to instead collectively focus on stopping the spoofed
>>> traffic that allows these attacks to be generated in the first place.
>>>
>>> -Rich
>>>
>>>
>>>
>>> *From: *NANOG Email List  on behalf of
>>> Bottiger 
>>> *Date: *Thursday, April 23, 2020 at 3:32 PM
>>> *To: *Siyuan Miao 
>>> *Cc: *NANOG list 
>>> *Subject: *Re: Best way to get foreign ISPs to shut down DDoS
>>> reflectors?
>>>
>>>
>>>
>>> We are unable to upgrade our bandwidth in those areas. There are no
>>> providers within our budget there at the moment. Surely there must be some
>>> way to get them to respond.
>>>
>>>
>>>
>>> On Thu, Apr 23, 2020 at 2:23 PM Siyuan Miao  wrote:
>>>
>>> It won't work.
>>>
>>>
>>>
>>> Get a good DDoS protection and forget about it.
>>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 5:17 AM Bottiger  wrote:
>>>
>>> Is there a guide on how to get foreign ISPs to shut down reflectors used
>>> in DDoS attacks?
>>>
>>>
>>>
>>> I've tried sending emails listed under abuse contacts for their regional
>>> registries. Either there is none listed, the email is full, email does not
>>> exist, or they do not reply. Same results when sending to whatever other
>>> email they have listed.
>>>
>>>
>>>
>>> Example Networks:
>>>
>>>
>>>
>>> CLARO S.A.
>>>
>>> Telefonica
>>>
>>> China Telecom
>>>
>>> Korea Telecom
>>>
>>> The contents of this e-mail message and
>>> any attachments are intended solely for the
>>> addressee(s) and may contain confidential
>>> and/or legally privileged information. If you
>>> are not the intended recipient of this message
>>> or if this message has been addressed to you
>>> in error, please immediately alert the sender
>>> by reply e-mail and then delete this message
>>> and any attachments. If you are not the
>>> intended recipient, you are notified that
>>> any use, dissemination, distribution, copying,
>>> or storage of this message or any attachment
>>> is strictly prohibited.
>>>
>>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 25 Apr, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  807324
Prefixes after maximum aggregation (per Origin AS):  306952
Deaggregation factor:  2.63
Unique aggregates announced (without unneeded subnets):  394895
Total ASes present in the Internet Routing Table: 67870
Prefixes per ASN: 11.90
Origin-only ASes present in the Internet Routing Table:   58291
Origin ASes announcing only one prefix:   24322
Transit ASes present in the Internet Routing Table:9579
Transit-only ASes present in the Internet Routing Table:301
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  45
Max AS path prepend of ASN ( 27978)  31
Prefixes from unregistered ASNs in the Routing Table:  1121
Number of instances of unregistered ASNs:  1124
Number of 32-bit ASNs allocated by the RIRs:  31403
Number of 32-bit ASNs visible in the Routing Table:   25963
Prefixes from 32-bit ASNs in the Routing Table:  119709
Number of bogon 32-bit ASNs visible in the Routing Table:21
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:745
Number of addresses announced to Internet:   2856567040
Equivalent to 170 /8s, 67 /16s and 193 /24s
Percentage of available address space announced:   77.2
Percentage of allocated address space announced:   77.2
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  272367

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   211915
Total APNIC prefixes after maximum aggregation:   62126
APNIC Deaggregation factor:3.41
Prefixes being announced from the APNIC address blocks:  205110
Unique aggregates announced from the APNIC address blocks:86548
APNIC Region origin ASes present in the Internet Routing Table:   10538
APNIC Prefixes per ASN:   19.46
APNIC Region origin ASes announcing only one prefix:   2941
APNIC Region transit ASes present in the Internet Routing Table:   1576
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 27
Number of APNIC region 32-bit ASNs visible in the Routing Table:   5605
Number of APNIC addresses announced to Internet:  767134848
Equivalent to 45 /8s, 185 /16s and 140 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:236391
Total ARIN prefixes after maximum aggregation:   108750
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   233827
Unique aggregates announced from the ARIN address blocks:118675
ARIN Region origin ASes present in the Internet Routing Table:18444
ARIN Prefixes per ASN:12.68
ARIN 

Re: mail admins?

[Michael Thomas]

On 4/23/20 8:48 PM, Matt Palmer wrote:

On Thu, Apr 23, 2020 at 07:47:58PM -0700, Michael Thomas wrote:

On 4/23/20 7:35 PM, Matt Palmer wrote:

While I do think webauthn is a neat idea, and solves at least one very real
problem (credential theft via phishing), you do an absolutely terrible job
of making that case.

see RFC 4876, it is not about phishing. not even a little bit. Never has
been.

Whilst I do *absolutely* agree with you that "A Configuration Profile Schema
for Lightweight Directory Access Protocol (LDAP)-Based Agents" is "not about
phishing, not even a little bit", I'm not entirely sure how it advances your
argument.


sorry, 7486.

Mike

Present Virtually at NANOG 79 - CFP Extended to May 7th

[Vincent Celindro]

Share your insights at NANOG 79

With a remote presentation that brings your research + ideas to life.

Due to the COVID-19 global pandemic, NANOG 79 will now be held as a virtual
meeting  with an abridged program
(June 1-3). The in-person meeting in Boston has been canceled to ensure the
health and safety of our community.

The NANOG Program Committee (PC) is developing a program tailored to the
three-day meeting with an online format, and has extended the Call For
Presentations to May 7. We encourage anyone interested in sharing their
research, ideas, and best practices with the greater NANOG community to
submit a proposal for a talk, tutorial, or panel to be presented virtually.

Submit Now 

View Guidelines 


In addition to proposals focused on current (or soon-to-be deployed)
technologies and industry innovation, we believe our community would also
be interested in the following topics:


   -

   Impact to Networks & Engineers as a result of COVID-19
   -

  Insights on working from home, VPN, sustained traffic, shifting of
  resources, application changes, etc.
  -

  Online conferencing security, BYOD and desktop security, family and
  work.
  -

   RPKI Deployments
   -

   Professional Development
   -

  Advice on white boarding, public speaking, negotiating, etc.



We look forward to reading your proposals, and connecting online this June!



Sincerely,


Vincent Celindro

NANOG - Program Committee Chair

on behalf of the NANOG PC

[NANOG-announce] Present Virtually at NANOG 79 - CFP Extended to May 7th

[Vincent Celindro]

Share your insights at NANOG 79

With a remote presentation that brings your research + ideas to life.

Due to the COVID-19 global pandemic, NANOG 79 will now be held as a virtual
meeting  with an abridged program
(June 1-3). The in-person meeting in Boston has been canceled to ensure the
health and safety of our community.

The NANOG Program Committee (PC) is developing a program tailored to the
three-day meeting with an online format, and has extended the Call For
Presentations to May 7. We encourage anyone interested in sharing their
research, ideas, and best practices with the greater NANOG community to
submit a proposal for a talk, tutorial, or panel to be presented virtually.

Submit Now 

View Guidelines 


In addition to proposals focused on current (or soon-to-be deployed)
technologies and industry innovation, we believe our community would also
be interested in the following topics:


   -

   Impact to Networks & Engineers as a result of COVID-19
   -

  Insights on working from home, VPN, sustained traffic, shifting of
  resources, application changes, etc.
  -

  Online conferencing security, BYOD and desktop security, family and
  work.
  -

   RPKI Deployments
   -

   Professional Development
   -

  Advice on white boarding, public speaking, negotiating, etc.



We look forward to reading your proposals, and connecting online this June!



Sincerely,


Vincent Celindro

NANOG - Program Committee Chair

on behalf of the NANOG PC
___
NANOG-announce mailing list
NANOG-announce@nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce

RE: [EXTERNAL] Re: FlowSpec

[Nikos Leontsinis]

If you can impose a limit on the amount of flowspec rules the customer can send 
you (I assume you are the Service provider) where is the problem
 with offering  flowspec services? Seems more of a vendor challenge.

The tcam issue is relatively addressed with proper dimensioning (throw money to 
the problem)
 and you have created a service revenue opportunity so it is a win win for both
 customer, provider and the entire community.
We cannot go very far with blackholing as a community.


-Original Message-
From: NANOG  On Behalf Of Denys Fedoryshchenko
Sent: 23 April 2020 16:58
To: Colton Conor 
Cc: NANOG 
Subject: [EXTERNAL] Re: FlowSpec

On 2020-04-23 18:13, Colton Conor wrote:
> Do any of the large transit providers support FlowSpec to transit
> customers / other carriers, or is that not a thing since they want to
> sell DDoS protection services? FlowSpec sounds much better than RTBH
> (remotely triggered blackhole), but I am not sure if  FlowSpec is
> widely implemented. I see the large router manufacturers support it.

RETN

They have extended blackholing, and FlowSpec, sure its all have costs.
I'm using both services from them and quite satisfied.

In general operators don't like flowspec, because it is not easy to implement 
it right, there is bugs and most important its "eating" TCAM.
For example:
https://urldefense.com/v3/__https://blog.cloudflare.com/todays-outage-post-mortem-82515/__;!!PcPv50trKLWG!jJCV6iVdjh9kx3oiFfxOwO6BdJfkVq6eY8iqqerUChY1t8qUVWITa00EAx1J1zloDMvF1WX9$
This email is from Equinix (EMEA) B.V. or one of its associated companies in 
the territory from where this email has been sent. This email, and any files 
transmitted with it, contains information which is confidential, is solely for 
the use of the intended recipient and may be legally privileged. If you have 
received this email in error, please notify the sender and delete this email 
immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, 1096 HA 
Amsterdam, The Netherlands. Registered in The Netherlands No. 57577889.