Re: Follow up to "has virtualization become obsolete in 5G"?

[Laurent Dumont]

The amount of buzzwords in that page is quite incredible.

I'm also unsure where it mentions that virtualization is now obsolete. NFV
solutions are moving to VM based deployments as a stop-gap and for the
future, towards micro-services built in containers.

On Fri, Jan 15, 2021 at 6:38 AM Etienne-Victor Depasquale 
wrote:

> Hello folks,
>
> Last year, I posted to this list and asked "has virtualization become
> obsolete in 5G"?
>
> A similar opinion seems to be gaining ground
> 
> .:
>
> "Once the darling of the telecoms industry, NFV has had a rough ride in
> recent years and has even lead some industry observers to proclaim that NFV
> is dead."
>
> Cheers,
>
> Etienne
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale
>

Re: opportunistic email encryption by the MTA (not MUA)

[Randy Bush]

fyi, i was contacted by a clue holder from protonmail.  my guess was
correct.  they pointed me to the wkd section of

   https://protonmail.com/blog/security-updates-2019/

as i responded to them:

  i am definitely wondering how well it scales.  it adds query
  burden, often toward a server different than the smtp target.
  e.g. the wkd server could have sucky performance.

randy

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 16 Jan, 2021

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

Analysis Summary


BGP routing table entries examined:  836570
Prefixes after maximum aggregation (per Origin AS):  320991
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  400559
Total ASes present in the Internet Routing Table: 70300
Prefixes per ASN: 11.90
Origin-only ASes present in the Internet Routing Table:   60483
Origin ASes announcing only one prefix:   25027
Transit ASes present in the Internet Routing Table:9817
Transit-only ASes present in the Internet Routing Table:303
Average AS path length visible in the Internet Routing Table:   4.4
Max AS path length visible:  34
Max AS path prepend of ASN (135582)  32
Prefixes from unregistered ASNs in the Routing Table:   888
Number of instances of unregistered ASNs:   890
Number of 32-bit ASNs allocated by the RIRs:  34690
Number of 32-bit ASNs visible in the Routing Table:   28828
Prefixes from 32-bit ASNs in the Routing Table:  133357
Number of bogon 32-bit ASNs visible in the Routing Table:14
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:441
Number of addresses announced to Internet:   2864864896
Equivalent to 170 /8s, 194 /16s and 94 /24s
Percentage of available address space announced:   77.4
Percentage of allocated address space announced:   77.4
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:  284676

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   219462
Total APNIC prefixes after maximum aggregation:   65065
APNIC Deaggregation factor:3.37
Prefixes being announced from the APNIC address blocks:  215317
Unique aggregates announced from the APNIC address blocks:88009
APNIC Region origin ASes present in the Internet Routing Table:   11211
APNIC Prefixes per ASN:   19.21
APNIC Region origin ASes announcing only one prefix:   3205
APNIC Region transit ASes present in the Internet Routing Table:   1599
Average APNIC Region AS path length visible:4.7
Max APNIC Region AS path length visible: 34
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6352
Number of APNIC addresses announced to Internet:  778254080
Equivalent to 46 /8s, 99 /16s and 55 /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-143673
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:241554
Total ARIN prefixes after maximum aggregation:   111774
ARIN Deaggregation factor: 2.16
Prefixes being announced from the ARIN address blocks:   242098
Unique aggregates announced from the ARIN address blocks:115757
ARIN Region origin ASes present in the Internet Routing Table:18692
ARIN Prefixes per ASN:12.95
ARIN Region

Re: tiny gorillas, was opportunistic email encryption by the MTA (not MUA)

[John Levine]

In article  you 
write:
>It's a real pity that there appears to be no real-world
>use/implementation of RFC8689.

I implemented RFC8689 as soon as Jim proposed it. My MTA recognizes
the REQUIRETLS option and then ignores it.

A lot of people who really should know better imagine that they can
announce something on the Internet and other people will have to do
what they say. It has never been true, and it is still not true. We've
seen this before with SPF -all where people are surprised that other
mail systems accept mail anyway.

Opportunistic TLS is fine, as is MTA-STS which says "if it doesn't
offer STARTTLS it's not me". Neither of those purport to tell other
systems what to do.

R's,
John

building your broadband - interview with jared mauch (live)

[Mehmet Akcin]

hey one of our own Jared has built a broadband network for his neighborhood

i am hosting him live on youtube now, come in and ask questions if you have!

Article about this -
https://arstechnica.com/information-technology/2021/01/jared-mauch-didnt-have-good-broadband-so-he-built-his-own-fiber-isp/

Youtube - https://www.youtube.com/watch?v=mUIPbym3rXs

great work @Jared Mauch 

mehmet

Re: opportunistic email encryption by the MTA (not MUA)

[Brian J. Murrell]

On Fri, 2021-01-15 at 10:26 -0500, Bryan Fields wrote:
> 
> It's still stored unencrypted on the server, and the admin can see
> all.

This is true.  I was just referring to transit leakage.

> If
> you want it secure, you have to run gpg and encrypt the body.

Again, true.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Re: opportunistic email encryption by the MTA (not MUA)

[Bryan Fields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 1/15/21 7:22 AM, Brian J. Murrell wrote:
> I think in practice the old adage that "e-mail is insecure" is becoming
> untrue, by a significant amount, I suspect, due to the prevalence of
> STARTTLS.

It's still stored unencrypted on the server, and the admin can see all.  If
you want it secure, you have to run gpg and encrypt the body.

- -- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAmABtBgACgkQYTmgYVLG
kUBjBQ/+McM45Kab7YdmzeqIeoZcR8Hy2JIZo4cWj/bQdKxzjIhZmvxacK8FJWwJ
06Vd3QynYLO2pRi/7GAJ6vLhNFd6Q2Nhh5ABADpwj6h0hWz4ULQ7hm1Wn8vdIofN
lOCef4xHYTIXGVN//QgWaUqdogwup3QdBbbWQsAh3rNbW9jYq4UrIGaEpVXJ+tsp
h55eoDcmX8P/SGkL4B0WBiv3IzMGfRMlcPHCRU7xCrQLCW34KEOcog2QyBv6ZSAk
yT3fsy8uiNg5S464YqXGEQT9/LuWDl1yMSJ4nhVDDAp+mbAcMCbpl7Hb3IWzUAJj
0v8D5yoUhYBeamCfTj19DSCnMONUAMlPlEiIlfQXvdrQaRBL2QJjwooGU5lDG+Zm
u/8M+M8bUNjSF2V7Y7JwszBkx1lkGuVMdXKjhnMM2/M+56AD9BJAsq2M2nEzE8Xz
CoAglEhUoL3vNN7HiLBrN8heGtF2aOXSI2cU9qzgL44d28nz+OyxWyiv3GWTYETA
mWCIz8RuYLwOh+EzAsx9AzsPhAYPUJnTMwdZb65QYsdXpDKtw3fvKrASHcJtn4I4
lxhCD66wOsJY/mypaDB973L7eyvUTVL/2E1qkXYbGVw/X5wxv6ohWr5zR7IbqLVY
FBTMsVnV4VcJsSLtCYku4BNWl4knYN7f8tQcVcMbpiToEYJXP3Q=
=Mo06
-END PGP SIGNATURE-

Re: opportunistic email encryption by the MTA (not MUA)

[Brian J. Murrell]

On Fri, 2021-01-15 at 03:33 -0800, Randy Bush wrote:
> email from a friend who uses protonmail as their MTA suddenly started
> to
> be opportunistically encrypted with pgp; i.e. the sender's MUA did
> nothing to cause the encryption.  i believe this started when i
> provided
> my pgp public key over WKD [0].

Interesting.  When I read the subject though, I have to admit that I
was hoping your e-mail was going to be about REQUIRETLS/RFC8689.

It's a real pity that there appears to be no real-world
use/implementation of RFC8689.

I think in practice the old adage that "e-mail is insecure" is becoming
untrue, by a significant amount, I suspect, due to the prevalence of
STARTTLS.

The problem with STARTTLS of course is that it is opportunistic only
and with no way for the sender to indicate that a message MUST use TLS
or not be delivered at all.

I routinely send things by e-mail that, while they are not the
combination to the big safe at Fort Knox, they are not something I
would staple to utility poles.

When doing such I will typically look up the MXes for the recipient and
test their SMTP port for STARTTLS to see if the mail will at least ride
the wires with TLS.

It would be so much easier to have a checkbox in my MUA to do this
though.  :-)

All of that said, thanks for the pointer to WKD.  I didn't know about
that.

Use of it at the MTA level is interesting.

Cheers,
b.



signature.asc
Description: This is a digitally signed message part

Follow up to "has virtualization become obsolete in 5G"?

[Etienne-Victor Depasquale]

Hello folks,

Last year, I posted to this list and asked "has virtualization become
obsolete in 5G"?

A similar opinion seems to be gaining ground

.:

"Once the darling of the telecoms industry, NFV has had a rough ride in
recent years and has even lead some industry observers to proclaim that NFV
is dead."

Cheers,

Etienne

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

opportunistic email encryption by the MTA (not MUA)

[Randy Bush]

email from a friend who uses protonmail as their MTA suddenly started to
be opportunistically encrypted with pgp; i.e. the sender's MUA did
nothing to cause the encryption.  i believe this started when i provided
my pgp public key over WKD [0].

i have a guess.  i suspect that protonmail opportunistically tests for a
WKD for the recipient and, if found, uses it.  i do see protonmail
queries to my WKD service

/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:41 +] 
"HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 
curl/7.29.0 PHP/7.4.11"
/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:08:44:42 +] 
"GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy 
HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11"
/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:44 +] 
"HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 
curl/7.29.0 PHP/7.4.11"
/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:10:49:45 +] 
"GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy 
HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11"
/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] 
"HEAD /.well-known/openpgpkey/policy HTTP/1.1" 200 - "-" "GuzzleHttp/6.5.5 
curl/7.29.0 PHP/7.4.11"
/var/log/httpd-access.log:185.70.40.57 - - [14/Jan/2021:15:02:49 +] 
"GET /.well-known/openpgpkey/hu/pbe8wr5gm5b4gf43adj411yrreqyib6u?l=randy 
HTTP/1.1" 200 26027 "-" "GuzzleHttp/6.5.5 curl/7.29.0 PHP/7.4.11"

my interest is whether WKD publication is triggering opportunistic
encryption; if anything else might be using it opportunistically, and if
this can actually scale.

i really do not want to discuss if pgp encryption is a good thing,  if
opportunistic encryption is the spawn of the frog goddess, or if there
are viable alternatives to emacs.

anyone with protonmail clue or contact(s)?

randy

[0] - https://git.rg.net/randy/randy/src/master/pgp-WKD.md