Re: Google uploading your plain text passwords

[Damian Menscher via NANOG]

On Fri, Jun 11, 2021 at 12:48 PM Matthew Petach 
wrote:

>
> That's the part that would leave me concerned.
> Having my email password compromised?
> That's a bit of a "meh" moment.
> Suddenly discovering that one password now gave access to
> potentially all my financial accounts as well?
> That's a wake up in the night with cold sweats moment.  :(
>

Just a note about security threat modeling: your email password can
generally be used to reset all your other passwords, so actually having
your email password compromised is one of the most terrifying situations of
all.  Unless, of course, you use a security key with gmail, in which case
compromise of your password may not get the attacker very far. ;)

The Chrome password manager is convenient, and the sync can be incredibly
handy (I can sign into stuff on different computers or even my phone
without needing to copy over the passwords), but you might consider leaving
your highest-value passwords out of that system, or really any system.
Personally, my financial passwords are not known by Chrome, myself, or even
my password manager.  (Yes, you heard that right -- no single entity knows
the passwords.  How?  By using a simple secret-splitting scheme -- I
memorize part of the password, and my password manager stores the rest.)

Damian

Re: [nanog] Famous operational issues

[Dan Mahoney]

I only just now found this thread, so I'm sorry I'm late to the party, but 
here, I put it on Medium.

https://gushi.medium.com/the-worst-day-ever-at-my-day-job-beff7f4170aa

> On Mar 12, 2021, at 10:07 PM, Mark Tinka  wrote:
> 
> Hardly famous and not service-affecting in the end, but figured I'd share an 
> incident from our side that occurred back in 2018.
> 
> While commissioning a new node in our Metro-E network, an IPv6 point-to-point 
> address was mis-typed. Instead of ending in /126, it ended in /12. This 
> happened in Johannesburg.
> 
> We actually came across this by chance while examining the IGP table of 
> another router located in Slough, and found an entry for 2c00::/12 floating 
> around. That definitely looked out of place, as we never carry parent blocks 
> in our IGP. 
> 
> Running the trace from Slough led us back to this one Metro-E device in 
> Jo'burg.
> 
> It took everyone nearly an hour to figure out the typo, because for all the 
> laser focus we had on the supposed link of the supposed box that was creating 
> this problem, we all overlooked the fact that the /12 configured on the 
> point-to-point link was actually supposed to have been a /126.
> 
> The reason this never caused a service problem was because we do not 
> redistribute our IGP into BGP (not that anyone should). And even if we did, 
> there are a ton of filters and BGP communities on all devices to ensure a 
> route such as that would have never made it out of our AS. 
> 
> Also, the IGP contains the most specific paths to every node in our network, 
> so the presence of the 2c00::/12 was mostly cosmetic. It would have never 
> been used for routing decisions.
> 
> Mark.

Re: Google uploading your plain text passwords

[Stephen Bertram]

-- Forwarded message -
From: William Herrin 
Date: Fri, 11 Jun 2021, 17:04
Subject: Google uploading your plain text passwords
To: nanog@nanog.org 


Howdy,

My gmail account prompted me today to change a compromised password.
It wasn't compromised; it was an offline system where I intentionally
used a generic password. But in the process...

It turns out that every password I allowed Chrome on Android to
remember, it uploaded to Google. In plain text!! And it could prove it
by displaying the plain text passwords for me on my laptop. And I
can't turn the upload off!

To the google folks on here: Are you INSANE!?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
All
https://bill.herrin.us/to beaa

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 1:05 PM César de Tassis Filho
 wrote:
> Google uses your Google Account's password to encrypt passwords synced to the 
> cloud. That is why passwords saved on Android and synced to the cloud can be 
> read elsewhere (including passwords.google.com).
>
> As I mentioned before, if you want to avoid this behavior Google offers you a 
> way to use a different sync passphrase (which inhibits access to 
> passwords.google.com and also disables other features). Instructions here: 
> https://support.google.com/chrome/answer/165139#passphrase

Hi César ,

This would be fine had I intended this behavior. That it magically
happened because I told my phone it could sync my gmail is very very
disturbing.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[Michael Thomas]

On Fri, Jun 11, 2021 at 12:01 PM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 10:27 AM Michael Thomas  wrote:
> > Isn't that what lots of password managers do? I understand that one of
> them syncs point to point, but that has the downside that it probably needs
> to be on the same subnet.
>
> It's exactly what lots of password managers with browser extensions
> do. I don't personally use them because I don't want my passwords
> reversibly stored on a computer that I don't directly control. I have
> no great philosophical problem with their existence and use by those
> who want them, I just don't want them for myself.
>

Well, browser extensions in and of themselves scare the living hell out of
me.  It really surprises me that they aren't a major attack vector and in
the news all of the time.

But yes, I agree that even encrypted they are a *very* tempting target for
hackers, and especially foreign governments. A breach would mean that
everybody is instantly screwed since they don't have to break into
individual computers, install malware, etc.

Mike

Re: Google uploading your plain text passwords

[César de Tassis Filho]

Google uses your Google Account's password to encrypt passwords synced to
the cloud. That is why passwords saved on Android and synced to the cloud
can be read elsewhere (including passwords.google.com).

As I mentioned before, if you want to avoid this behavior Google offers you
a way to use a different sync passphrase (which inhibits access to
passwords.google.com and also disables other features). Instructions here:
https://support.google.com/chrome/answer/165139#passphrase

César

On Fri, Jun 11, 2021 at 4:50 PM Matthew Petach 
wrote:

>
>
> On Fri, Jun 11, 2021 at 12:32 PM Peter Beckman 
> wrote:
>
>> On Fri, 11 Jun 2021, William Herrin wrote:
>>
>> > On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
>> >  wrote:
>> >> Google does not have access to your plain-text passwords in either
>> case.
>> >
>> > If they can display the plain text passwords to me on my screen in a
>> > non-Google web browser then they have access to my plain text
>> > passwords. Everything else is semantics.
>>
>>   Untrue. If you have a key on your computer, such as was mentioned that
>>   the Google key may be stored locally in the MacOS Keychain, and you
>> unlock
>>   your MacOS Keychain with your local laptop login password, which is also
>>   stored on an encrypted disk volume, that does not mean those passwords
>>   have left your computer in plain text, or that Google has this key that
>>   lives in your keychain.
>>
>>   I agree, if they do, that's terrible. But I haven't seen any evidence
>> that
>>   they do.
>>
>
> However, if the password is entered on one device (Android device, for
> example,
> as mentioned in the original post), and then is visible in clear-text on a
> different
> browser on a different device (laptop, for example, again, from the
> original post),
> then clearly the password has left the original device in a form which is
> reversible
> to the original clear text.  You can argue that it may be stored "in the
> cloud" in
> encrypted form; but it's clearly being stored in a manner which can be
> reversed
> to gain access to the original clear text, and using a key which is known
> to both
> devices involved, and to the cloud system validating that authentication.
>
> This isn't about seeing the passwords in clear text on the same device
> upon which they were entered; this is about a *separate* device having
> visible access to the clear text of a password that was not entered via
> that device.
>
> If the laptop had required Bill to enter a decryption key first in order
> to
> see the clear text, and that decryption key was one he had manually
> configured on both devices, stored only locally on each device, then
> you might be able to argue that the cloud never has visibility into the
> passwords; but if the keys are encrypted using a gmail login credential,
> which is itself stored and verified within the same cloud environment as
> the encrypted password strings it is protecting, then your two factor
> security has collapsed back down into a single point of compromise;
> compromise the google password, and you have access to all the
> passwords that were uploaded and stored in the system unbeknownst
> to the user.
>
> That's the part that would leave me concerned.
> Having my email password compromised?
> That's a bit of a "meh" moment.
> Suddenly discovering that one password now gave access to
> potentially all my financial accounts as well?
> That's a wake up in the night with cold sweats moment.  :(
>
> Matt
>
>

Operational Implications of IPv6 Extension Headers (Fwd: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt)

[Fernando Gont via NANOG]

Hi, folks,

After almost 7+ years of working on this topic, our internet-draft 
entitled Operational Implications of IPv6 Packets with Extension 
Headers¨ 
(
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08
),  has been approved for publication as an IETF RFC.

I believe it iś of value for folks working in security and/or network 
operations.

Kudos to my co-authors for enduring the process, and to Nick Hilliard 
who did the last push to get this one approved. :-)

Thanks!

Cheers,
Fernando




 Forwarded Message 
Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-
08.txt
Date: Fri, 11 Jun 2021 09:28:16 -0700
From: internet-drafts at ietf.org
Reply-To: v6ops at ietf.org
To: i-d-announce at ietf.org
CC: v6ops at ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

 Title   : Operational Implications of IPv6 Packets
with 
Extension Headers
 Authors : Fernando Gont
   Nick Hilliard
   Gert Doering
   Warren Kumari
   Geoff Huston
   Will (Shucheng) Liu
Filename: draft-ietf-v6ops-ipv6-ehs-packet-drops-08.txt
Pages   : 20
Date: 2021-06-11

Abstract:
This document summarizes the operational implications of IPv6
extension headers specified in the IPv6 protocol specification
(RFC8200), and attempts to analyze reasons why packets with IPv6
extension headers are often dropped in the public Internet.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
v6ops mailing list
v6ops at ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

Re: irrd 4.1.2 deployed at NTT

[Randy Bush]

>> i am sure there are more things to do; and hope that wiser folk will
>> expand, comment, and correct.
> 
> Stay far away from AS0...

one of 42 ways, invented by clever people, to shoot yourself in the foot

randy

Re: Google uploading your plain text passwords

[Matthew Petach]

On Fri, Jun 11, 2021 at 12:32 PM Peter Beckman  wrote:

> On Fri, 11 Jun 2021, William Herrin wrote:
>
> > On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
> >  wrote:
> >> Google does not have access to your plain-text passwords in either case.
> >
> > If they can display the plain text passwords to me on my screen in a
> > non-Google web browser then they have access to my plain text
> > passwords. Everything else is semantics.
>
>   Untrue. If you have a key on your computer, such as was mentioned that
>   the Google key may be stored locally in the MacOS Keychain, and you
> unlock
>   your MacOS Keychain with your local laptop login password, which is also
>   stored on an encrypted disk volume, that does not mean those passwords
>   have left your computer in plain text, or that Google has this key that
>   lives in your keychain.
>
>   I agree, if they do, that's terrible. But I haven't seen any evidence
> that
>   they do.
>

However, if the password is entered on one device (Android device, for
example,
as mentioned in the original post), and then is visible in clear-text on a
different
browser on a different device (laptop, for example, again, from the
original post),
then clearly the password has left the original device in a form which is
reversible
to the original clear text.  You can argue that it may be stored "in the
cloud" in
encrypted form; but it's clearly being stored in a manner which can be
reversed
to gain access to the original clear text, and using a key which is known
to both
devices involved, and to the cloud system validating that authentication.

This isn't about seeing the passwords in clear text on the same device
upon which they were entered; this is about a *separate* device having
visible access to the clear text of a password that was not entered via
that device.

If the laptop had required Bill to enter a decryption key first in order to
see the clear text, and that decryption key was one he had manually
configured on both devices, stored only locally on each device, then
you might be able to argue that the cloud never has visibility into the
passwords; but if the keys are encrypted using a gmail login credential,
which is itself stored and verified within the same cloud environment as
the encrypted password strings it is protecting, then your two factor
security has collapsed back down into a single point of compromise;
compromise the google password, and you have access to all the
passwords that were uploaded and stored in the system unbeknownst
to the user.

That's the part that would leave me concerned.
Having my email password compromised?
That's a bit of a "meh" moment.
Suddenly discovering that one password now gave access to
potentially all my financial accounts as well?
That's a wake up in the night with cold sweats moment.  :(

Matt

Re: Any2 LAX

[Mike Lyon]

Like Seth, i haven’t gotten anything from them.

-Mike

> On Jun 11, 2021, at 12:08, Bryan Holloway  wrote:
> 
> 
> 
>> On 6/11/21 8:25 PM, Seth Mattinen wrote:
>>> On 6/11/21 11:18 AM, Bryan Holloway wrote:
>>> This is what I got from those guys ...
>>> 
>>> -- 
>>> 
>>> CoreSite Incident Notification
>>> 
>>> 
>>> Description:  During a planned maintenance event to integrate new hardware 
>>> into our MPLS core an extreme dip in Any2 traffic was observed. After about 
>>> 4 hours running in a degraded state, an emergency case was opened with the 
>>> hardware vendor. After working with the hardware vendor to rule out any 
>>> possible hardware or software bugs, the network engineering team located 
>>> the source of the traffic loss. It was an errant configuration applied by 
>>> the custom automation written to build LSP's in our MPLS network. A formal 
>>> IR will be provided for this event.
>>> 
>>> 
>> Was that an automated email? Last time I got any email from Coresite was 
>> April 22.
> 
> 
> Automated.

Re: Google uploading your plain text passwords

[Peter Beckman]

On Fri, 11 Jun 2021, William Herrin wrote:


On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
 wrote:

Google does not have access to your plain-text passwords in either case.


If they can display the plain text passwords to me on my screen in a
non-Google web browser then they have access to my plain text
passwords. Everything else is semantics.


 Untrue. If you have a key on your computer, such as was mentioned that
 the Google key may be stored locally in the MacOS Keychain, and you unlock
 your MacOS Keychain with your local laptop login password, which is also
 stored on an encrypted disk volume, that does not mean those passwords
 have left your computer in plain text, or that Google has this key that
 lives in your keychain.

 I agree, if they do, that's terrible. But I haven't seen any evidence that
 they do.

 You can have multiple keys to encrypted data, and it is still stored in a
 cryptographically secure way, assuming it is implemented well, despite
 those multiple keys having the ability to decrypt your data.

 I use 1Password. There are multiple keys that can unlock the other key
 that can unlock my encrypted data. But just because I can see my passwords
 in the app, and that there is a mechanism/code that can do the same
 without the 1Password app to unlock and view my data, this does not mean
 that 1Password has my keys, nor access to all my passwords.

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

Re: Any2 LAX

[Bryan Holloway]

On 6/11/21 8:25 PM, Seth Mattinen wrote:

On 6/11/21 11:18 AM, Bryan Holloway wrote:

This is what I got from those guys ...

--

CoreSite Incident Notification


Description:  During a planned maintenance event to integrate new 
hardware into our MPLS core an extreme dip in Any2 traffic was 
observed. After about 4 hours running in a degraded state, an 
emergency case was opened with the hardware vendor. After working with 
the hardware vendor to rule out any possible hardware or software 
bugs, the network engineering team located the source of the traffic 
loss. It was an errant configuration applied by the custom automation 
written to build LSP's in our MPLS network. A formal IR will be 
provided for this event.






Was that an automated email? Last time I got any email from Coresite was 
April 22.



Automated.

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 10:27 AM Michael Thomas  wrote:
> Isn't that what lots of password managers do? I understand that one of them 
> syncs point to point, but that has the downside that it probably needs to be 
> on the same subnet.

It's exactly what lots of password managers with browser extensions
do. I don't personally use them because I don't want my passwords
reversibly stored on a computer that I don't directly control. I have
no great philosophical problem with their existence and use by those
who want them, I just don't want them for myself.

My problem was suddenly finding Google in possession of passwords I
never intentionally allowed it to have. This sneak around behind my
back stuff means I wasn't in control of my passwords.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Cogent and Altice Contacts for Routing Issue

[Vinny Abello via NANOG]

This issue now seems resolved. If anyone here was directly responsible 
for the resolution, thank you.


-Vinny

Vinny Abello via NANOG wrote on 6/11/2021 11:17 AM:

Hello,

Please excuse the noise. If there are any network engineers from 
Cogent and Altice on the list, could you please email me directly. 
This is regarding a specific Altice IPv4 aggregate in the NYC area 
that Cogent in the NYC area is handing off to Zayo in San Jose for 
some reason. It subsequently seemingly has a lot of packet loss coming 
back to the NYC area through Zayo's network. It's affecting my remote 
employees.


I can provide traceroutes privately as not to clutter up the list.

Bad Altice Aggregate in question: 67.84.0.0/14

Good Altice aggregate routing properly: 68.196.0.0/14

Thanks in advance.

-Vinny

Re: Any2 LAX

[Seth Mattinen]

On 6/11/21 11:18 AM, Bryan Holloway wrote:

This is what I got from those guys ...

--

CoreSite Incident Notification


Description:  During a planned maintenance event to integrate new 
hardware into our MPLS core an extreme dip in Any2 traffic was observed. 
After about 4 hours running in a degraded state, an emergency case was 
opened with the hardware vendor. After working with the hardware vendor 
to rule out any possible hardware or software bugs, the network 
engineering team located the source of the traffic loss. It was an 
errant configuration applied by the custom automation written to build 
LSP's in our MPLS network. A formal IR will be provided for this event.






Was that an automated email? Last time I got any email from Coresite was 
April 22.

Re: Any2 LAX

[Bryan Holloway]

This is what I got from those guys ...

--

CoreSite Incident Notification


Description:  During a planned maintenance event to integrate new 
hardware into our MPLS core an extreme dip in Any2 traffic was observed. 
After about 4 hours running in a degraded state, an emergency case was 
opened with the hardware vendor. After working with the hardware vendor 
to rule out any possible hardware or software bugs, the network 
engineering team located the source of the traffic loss. It was an 
errant configuration applied by the custom automation written to build 
LSP's in our MPLS network. A formal IR will be provided for this event.





On 6/11/21 8:03 PM, jim deleskie wrote:
Also saw a major traffic drop. There is a Root Cause to be issued early 
in the week I'm told.



-jim

On Fri, Jun 11, 2021 at 2:42 PM Siyuan Miao > wrote:


Yea, it was down but both RS are online and feeding us unreachable
nexthops during the outage .

On Sat, Jun 12, 2021 at 1:27 AM Seth Mattinen mailto:se...@rollernet.us>> wrote:

On 6/11/21 10:16 AM, Jon Lewis wrote:
 > On Fri, 11 Jun 2021, Seth Mattinen wrote:
 >
 >> Did Any2 LAX barf last night between about 1am and 8am
Pacific time?
 >
 > More like 00:00-7:45 (Pacific time).
 >
 > Anyone know what broke, and why the IX was dead for nearly 8
hours?
 > This is our second recent issue with "an Any2 IX", having
dealt with an
 > IX partition event at Any2 Denver just a few weeks ago.
 >


What I saw was a lot of unreachable nexthops (I'm in LA2) on routes
advertised through the route servers. Most of my direct BGP
sessions
were down, but a handful were still working including the route
servers.

For example, I was getting routes for AS29791 from the route
servers,
but nexthop 206.72.211.106 was dead to me. Not to pick on
Internap other
than a mutual customer called me directly at 1am and wanted to
know why
things were down.

I killed the route server sessions and went back to sleep.

Feels like LA1 and LA2 got split, but however the route servers
interconnect still worked, which was problematic.

Re: Any2 LAX

[jim deleskie]

Also saw a major traffic drop. There is a Root Cause to be issued early in
the week I'm told.


-jim

On Fri, Jun 11, 2021 at 2:42 PM Siyuan Miao  wrote:

> Yea, it was down but both RS are online and feeding us unreachable
> nexthops during the outage .
>
> On Sat, Jun 12, 2021 at 1:27 AM Seth Mattinen  wrote:
>
>> On 6/11/21 10:16 AM, Jon Lewis wrote:
>> > On Fri, 11 Jun 2021, Seth Mattinen wrote:
>> >
>> >> Did Any2 LAX barf last night between about 1am and 8am Pacific time?
>> >
>> > More like 00:00-7:45 (Pacific time).
>> >
>> > Anyone know what broke, and why the IX was dead for nearly 8 hours?
>> > This is our second recent issue with "an Any2 IX", having dealt with an
>> > IX partition event at Any2 Denver just a few weeks ago.
>> >
>>
>>
>> What I saw was a lot of unreachable nexthops (I'm in LA2) on routes
>> advertised through the route servers. Most of my direct BGP sessions
>> were down, but a handful were still working including the route servers.
>>
>> For example, I was getting routes for AS29791 from the route servers,
>> but nexthop 206.72.211.106 was dead to me. Not to pick on Internap other
>> than a mutual customer called me directly at 1am and wanted to know why
>> things were down.
>>
>> I killed the route server sessions and went back to sleep.
>>
>> Feels like LA1 and LA2 got split, but however the route servers
>> interconnect still worked, which was problematic.
>>
>

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 12 Jun, 2021

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

Analysis Summary


BGP routing table entries examined:  854593
Prefixes after maximum aggregation (per Origin AS):  322645
Deaggregation factor:  2.65
Unique aggregates announced (without unneeded subnets):  409480
Total ASes present in the Internet Routing Table: 71406
Prefixes per ASN: 11.97
Origin-only ASes present in the Internet Routing Table:   61421
Origin ASes announcing only one prefix:   25365
Transit ASes present in the Internet Routing Table:9985
Transit-only ASes present in the Internet Routing Table:319
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 48366)  51
Prefixes from unregistered ASNs in the Routing Table:  1077
Number of instances of unregistered ASNs:  1084
Number of 32-bit ASNs allocated by the RIRs:  36302
Number of 32-bit ASNs visible in the Routing Table:   30177
Prefixes from 32-bit ASNs in the Routing Table:  140528
Number of bogon 32-bit ASNs visible in the Routing Table:25
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:568
Number of addresses announced to Internet:   3040471936
Equivalent to 181 /8s, 57 /16s and 235 /24s
Percentage of available address space announced:   82.1
Percentage of allocated address space announced:   82.1
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:  284846

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   230126
Total APNIC prefixes after maximum aggregation:   65630
APNIC Deaggregation factor:3.51
Prefixes being announced from the APNIC address blocks:  225887
Unique aggregates announced from the APNIC address blocks:90032
APNIC Region origin ASes present in the Internet Routing Table:   11623
APNIC Prefixes per ASN:   19.43
APNIC Region origin ASes announcing only one prefix:   3330
APNIC Region transit ASes present in the Internet Routing Table:   1646
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6792
Number of APNIC addresses announced to Internet:  774990592
Equivalent to 46 /8s, 49 /16s and 107 /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-147769
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:248453
Total ARIN prefixes after maximum aggregation:   113685
ARIN Deaggregation factor: 2.19
Prefixes being announced from the ARIN address blocks:   248607
Unique aggregates announced from the ARIN address blocks:118550
ARIN Region origin ASes present in the Internet Routing Table:18832
ARIN Prefixes per ASN:13.20
ARIN 

Re: Google uploading your plain text passwords

[Eric Kuhnke]

I think you have only found the tip of the iceberg of things that Chrome
and Google does without your express consent.

On Fri, Jun 11, 2021 at 9:48 AM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 9:38 AM Jan Schaumann via NANOG 
> wrote:
> > William Herrin  wrote:
> > > It turns out that every password I allowed Chrome on Android to
> > > remember, it uploaded to Google. In plain text!!
> >
> > Chrome does not store your passwords in plain text.
> > It encrypts them locally, on e.g. macOS using, I
> > think, a secret stored in the keychain under "Chrome
> > Safe Storage", on Windows using a similar API and
> > secret probably unlocked via your login credentials.
>
> Hi Jan,
>
> I'm fine with Chrome encrypting them locally. That's what I want it to
> do. I'm not at all fine with it uploading them to my Google account. I
> don't want any trace of my non-google passwords present in my google
> account. I'm very very not fine that it happened behind my back
> without my express consent.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Any2 LAX

[Siyuan Miao]

Yea, it was down but both RS are online and feeding us unreachable nexthops
during the outage .

On Sat, Jun 12, 2021 at 1:27 AM Seth Mattinen  wrote:

> On 6/11/21 10:16 AM, Jon Lewis wrote:
> > On Fri, 11 Jun 2021, Seth Mattinen wrote:
> >
> >> Did Any2 LAX barf last night between about 1am and 8am Pacific time?
> >
> > More like 00:00-7:45 (Pacific time).
> >
> > Anyone know what broke, and why the IX was dead for nearly 8 hours?
> > This is our second recent issue with "an Any2 IX", having dealt with an
> > IX partition event at Any2 Denver just a few weeks ago.
> >
>
>
> What I saw was a lot of unreachable nexthops (I'm in LA2) on routes
> advertised through the route servers. Most of my direct BGP sessions
> were down, but a handful were still working including the route servers.
>
> For example, I was getting routes for AS29791 from the route servers,
> but nexthop 206.72.211.106 was dead to me. Not to pick on Internap other
> than a mutual customer called me directly at 1am and wanted to know why
> things were down.
>
> I killed the route server sessions and went back to sleep.
>
> Feels like LA1 and LA2 got split, but however the route servers
> interconnect still worked, which was problematic.
>

Re: Google uploading your plain text passwords

[Michael Thomas]

[sorry meant to send this to the list]

Isn't that what lots of password managers do? I understand that one of them
syncs point to point, but that has the downside that it probably needs to
be on the same subnet.

The actual problem here is that sites only allow a single password. if you
could enroll more than one password you wouldn't need to sync at all.
Better: use asymmetric keys and enroll public keys so the secret never
leaves your device.

Mike

On Fri, Jun 11, 2021 at 9:53 AM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
>  wrote:
> > Google does not have access to your plain-text passwords in either case.
>
> If they can display the plain text passwords to me on my screen in a
> non-Google web browser then they have access to my plain text
> passwords. Everything else is semantics.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Any2 LAX

[Seth Mattinen]

On 6/11/21 10:16 AM, Jon Lewis wrote:

On Fri, 11 Jun 2021, Seth Mattinen wrote:


Did Any2 LAX barf last night between about 1am and 8am Pacific time?


More like 00:00-7:45 (Pacific time).

Anyone know what broke, and why the IX was dead for nearly 8 hours?
This is our second recent issue with "an Any2 IX", having dealt with an 
IX partition event at Any2 Denver just a few weeks ago.





What I saw was a lot of unreachable nexthops (I'm in LA2) on routes 
advertised through the route servers. Most of my direct BGP sessions 
were down, but a handful were still working including the route servers.


For example, I was getting routes for AS29791 from the route servers, 
but nexthop 206.72.211.106 was dead to me. Not to pick on Internap other 
than a mutual customer called me directly at 1am and wanted to know why 
things were down.


I killed the route server sessions and went back to sleep.

Feels like LA1 and LA2 got split, but however the route servers 
interconnect still worked, which was problematic.

Re: DANE of SMTP Survey

[John Levine]

It appears that Tom Ivar Helbekkmo via NANOG  said:
>John Levine  writes:
>
>> I have signed all 300 zones on my DNS servers, but only about half of
>> them have working DNSSEC because there is no practical way to install
>> the DS records.
>
>Sounds like ICANN, having told us for a very long time that they want
>DNSSEC everywhere, should attempt to get a requirement in place that
>registrars have to make it reasonably easy for customers to get those DS
>records installed. ...

Hahahahaha.  At ICANN, anything that might put even the tiniest extra
cost on registrars is a non-starter.  Look at the endless fight about
WHOIS redaction.

Re: Google uploading your plain text passwords

[John Levine]

It appears that William Herrin  said:
>On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
> wrote:
>> Google does not have access to your plain-text passwords in either case.
>
>If they can display the plain text passwords to me on my screen in a
>non-Google web browser then they have access to my plain text
>passwords. Everything else is semantics.

I tried it in Firefox.  I can log into my Google account with my Google password
and see the saved passwords but unless Firefox is doing some impressively
sophisticated content snooping, it can't do anything with them.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Any2 LAX

[Jon Lewis]

On Fri, 11 Jun 2021, Seth Mattinen wrote:


Did Any2 LAX barf last night between about 1am and 8am Pacific time?


More like 00:00-7:45 (Pacific time).

Anyone know what broke, and why the IX was dead for nearly 8 hours?
This is our second recent issue with "an Any2 IX", having dealt with an IX 
partition event at Any2 Denver just a few weeks ago.


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

Re: Any2 LAX

[Mike Lyon]

Something happened... All my traffic dropped between 1am to 3am.

-Mike

> On Jun 11, 2021, at 10:11, Seth Mattinen  wrote:
> 
> Did Any2 LAX barf last night between about 1am and 8am Pacific time?

Any2 LAX

[Seth Mattinen]

Did Any2 LAX barf last night between about 1am and 8am Pacific time?

Re: DANE of SMTP Survey

[Tom Ivar Helbekkmo via NANOG]

John Levine  writes:

> I have signed all 300 zones on my DNS servers, but only about half of
> them have working DNSSEC because there is no practical way to install
> the DS records.

Sounds like ICANN, having told us for a very long time that they want
DNSSEC everywhere, should attempt to get a requirement in place that
registrars have to make it reasonably easy for customers to get those DS
records installed.  Certificate authorities are now required to honor
CAA records, which need DNSSEC in place to really make sense, so it
would, IMHO, be natural to follow up like this.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: irrd 4.1.2 deployed at NTT

[Mark Tinka]

On 6/10/21 20:08, Randy Bush wrote:


i am sure there are more things to do; and hope that wiser folk will
expand, comment, and correct.


Stay far away from AS0...

Mark.

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 9:42 AM César de Tassis Filho
 wrote:
> Google does not have access to your plain-text passwords in either case.

If they can display the plain text passwords to me on my screen in a
non-Google web browser then they have access to my plain text
passwords. Everything else is semantics.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 9:38 AM Jan Schaumann via NANOG  wrote:
> William Herrin  wrote:
> > It turns out that every password I allowed Chrome on Android to
> > remember, it uploaded to Google. In plain text!!
>
> Chrome does not store your passwords in plain text.
> It encrypts them locally, on e.g. macOS using, I
> think, a secret stored in the keychain under "Chrome
> Safe Storage", on Windows using a similar API and
> secret probably unlocked via your login credentials.

Hi Jan,

I'm fine with Chrome encrypting them locally. That's what I want it to
do. I'm not at all fine with it uploading them to my Google account. I
don't want any trace of my non-google passwords present in my google
account. I'm very very not fine that it happened behind my back
without my express consent.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: DANE of SMTP Survey

[John Levine]

It appears that Tom Ivar Helbekkmo via NANOG  said:
>Jeroen Massar via NANOG  writes:
>
>> No, not even kidding. For many organisations DNSSEC is 'scary' and a
>> burden as it feels 'fragile' for them.
>
>Unfortunately, yes.  And those of us who use it know that this is a
>myth.  With modern software, DNSSEC is quick and easy to set up, and
>works just fine, with no reason for any problems. ...

I wish that were true.  I have signed all 300 zones on my DNS
servers, but only about half of them have working DNSSEC because there
is no practical way to install the DS records.  For names that are
registered through my registrar reseller account, it's easy since my
registrar (Tucows) has an API.  But for the rest of them that my
users have registered somewhere else, either I have to try and walk
them through the process of uploading the DS data themselves, or
they have to give me their account passwords, neither of which is
workable if you have 100 domains, much less thousands.

I know about CDS, and have tried publishing CDS, but none of my
unsigned domains are at the handful of registries that do CDS
bootstrapping.

I've been grousing about this at the IETF and ICANN for years,
people say yes, that's a problem, and nothing happens.

Re: Google uploading your plain text passwords

[César de Tassis Filho]

Google stores encrypted passwords. By default it uses your own Google
Account password as part of the key to decrypt your other synced passwords.
But you can change that and use a custom "sync passphrase".

Once you're logged in your device can decrypt your passwords and compare
them against databases of known compromised passwords.

Google does not have access to your plain-text passwords in either case.

More info:
https://support.google.com/accounts/answer/6208650
https://security.googleblog.com/2020/10/new-password-protections-and-more-in.html

Regards,
César

On Fri, Jun 11, 2021 at 1:05 PM William Herrin  wrote:

> Howdy,
>
> My gmail account prompted me today to change a compromised password.
> It wasn't compromised; it was an offline system where I intentionally
> used a generic password. But in the process...
>
> It turns out that every password I allowed Chrome on Android to
> remember, it uploaded to Google. In plain text!! And it could prove it
> by displaying the plain text passwords for me on my laptop. And I
> can't turn the upload off!
>
> To the google folks on here: Are you INSANE!?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[Jan Schaumann via NANOG]

William Herrin  wrote:
 
> It turns out that every password I allowed Chrome on Android to
> remember, it uploaded to Google. In plain text!!

Chrome does not store your passwords in plain text.
It encrypts them locally, on e.g. macOS using, I
think, a secret stored in the keychain under "Chrome
Safe Storage", on Windows using a similar API and
secret probably unlocked via your login credentials.

If you use your favorite internet search engine to
look for "how does Chrome store passwords", you'll
find the local sqlite file and more detailed
explanations.

-Jan

Re: Google uploading your plain text passwords

[Alain Hebert]

    Hi,

    I use Firefox and saved its profile inside a VeraCrypt disk, inside 
a Bitlocked disk, inside a Surface3 used only for that purpose =D.
    ( Yeah that include a few physical MFA device and Shutdown instead 
of Sleeping, and yadi yada )


    So GL with Chrome =D.

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 6/11/21 12:12 PM, William Herrin wrote:

On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman
 wrote:

That's wrong, you CAN turn it off.  I believe it's encrypted between Google and 
your Chrome browser, it says so but I haven't confirmed this myself.

Chrome can be configured to not remember passwords at all (makes a
browser pretty useless), but it won't keep them only on the local
device. If allowed to remember passwords, it uploads them to Google.
No knob to turn sync off.

-Bill

Re: Google uploading your plain text passwords

[Josh Luthman]

Disable "auto sign-in" and "Save and fill addresses" and there's more for
payment methods, too.

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Jun 11, 2021 at 12:12 PM William Herrin  wrote:

> On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman
>  wrote:
> > That's wrong, you CAN turn it off.  I believe it's encrypted between
> Google and your Chrome browser, it says so but I haven't confirmed this
> myself.
>
> Chrome can be configured to not remember passwords at all (makes a
> browser pretty useless), but it won't keep them only on the local
> device. If allowed to remember passwords, it uploads them to Google.
> No knob to turn sync off.
>
> -Bill
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 9:16 AM Matthias Merkel
 wrote:
> On mobile: Chrome Settings -> Sync -> Uncheck Sync All -> Uncheck Passwords

This works. Thank you.

Still, on by default? How many billions of passwords does google now
have stored with reversible encryption?

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[William Herrin]

On Fri, Jun 11, 2021 at 9:06 AM Josh Luthman
 wrote:
> That's wrong, you CAN turn it off.  I believe it's encrypted between Google 
> and your Chrome browser, it says so but I haven't confirmed this myself.

Chrome can be configured to not remember passwords at all (makes a
browser pretty useless), but it won't keep them only on the local
device. If allowed to remember passwords, it uploads them to Google.
No knob to turn sync off.

-Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: Google uploading your plain text passwords

[Josh Luthman]

That's wrong, you CAN turn it off.  I believe it's encrypted between Google
and your Chrome browser, it says so but I haven't confirmed this myself.

Chrome Settings, Password, disable "Offer to save passwords"

Josh Luthman
24/7 Help Desk: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373


On Fri, Jun 11, 2021 at 12:03 PM William Herrin  wrote:

> Howdy,
>
> My gmail account prompted me today to change a compromised password.
> It wasn't compromised; it was an offline system where I intentionally
> used a generic password. But in the process...
>
> It turns out that every password I allowed Chrome on Android to
> remember, it uploaded to Google. In plain text!! And it could prove it
> by displaying the plain text passwords for me on my laptop. And I
> can't turn the upload off!
>
> To the google folks on here: Are you INSANE!?
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>

Google uploading your plain text passwords

[William Herrin]

Howdy,

My gmail account prompted me today to change a compromised password.
It wasn't compromised; it was an offline system where I intentionally
used a generic password. But in the process...

It turns out that every password I allowed Chrome on Android to
remember, it uploaded to Google. In plain text!! And it could prove it
by displaying the plain text passwords for me on my laptop. And I
can't turn the upload off!

To the google folks on here: Are you INSANE!?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Cogent and Altice Contacts for Routing Issue

[Vinny Abello via NANOG]

Hello,

Please excuse the noise. If there are any network engineers from Cogent 
and Altice on the list, could you please email me directly. This is 
regarding a specific Altice IPv4 aggregate in the NYC area that Cogent 
in the NYC area is handing off to Zayo in San Jose for some reason. It 
subsequently seemingly has a lot of packet loss coming back to the NYC 
area through Zayo's network. It's affecting my remote employees.


I can provide traceroutes privately as not to clutter up the list.

Bad Altice Aggregate in question: 67.84.0.0/14

Good Altice aggregate routing properly: 68.196.0.0/14

Thanks in advance.

-Vinny

Re: DANE of SMTP Survey

[Tom Ivar Helbekkmo via NANOG]

Jeroen Massar via NANOG  writes:

> No, not even kidding. For many organisations DNSSEC is 'scary' and a
> burden as it feels 'fragile' for them.

Unfortunately, yes.  And those of us who use it know that this is a
myth.  With modern software, DNSSEC is quick and easy to set up, and
works just fine, with no reason for any problems.  The effort invested
is a very low price to pay for the added protection, both directly (by
making sure that spoofing attacks  make resolving fail noticeably),
and through the various added mechanisms you can then apply, such as CAA
records.

> And replacing a DNS key can take a few moments, especially with
> caching of records etc.
> Thus downtime is then ensured.

Not if you do it right.  Add the new key, wait a while, then remove the
old key.  On installations I manage, this is scripted, and done from
cron, rotating ZSKs on a monthly basis.

> Combine that with many shops not having much DNS knowledge in the
> first place, they won't easily get their heads around that barrier.

Now that's a real problem.  If you're going to do X, you should have
someone on staff who knows enough about X to do it right, safely.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay