Re: Something that should put a smile on everybody's face today

[Mel Beckman]

NANOG is not the right place to post this. This list is not an “interesting 
news group”, and as fascinating as the patent troll take down is, it has 
nothing to do with operational issues. Read the AUP, if your don’t believe me. 
Item 8:

Posts of a political, philosophical, or legal nature are prohibited.

I for one don’t want the list to be overrun again by people with a political 
axe to grind, no matter how noble.

 -mel

On Apr 27, 2021, at 3:34 PM, Justin Paine via NANOG  wrote:


Correction -- another one.  
https://blog.cloudflare.com/winning-the-blackbird-battle/   :)

Here's an except from the new blog post:

offering $100,000 to be shared by the winners who are successful in finding 
such prior art.

Please help!




__
Justin Paine
He/Him/His
Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107

PGP: BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 
314D


On Tue, Apr 27, 2021 at 3:26 PM Michael Thomas 
mailto:m...@mtcc.com>> wrote:

And we can help! Cloudflare is setting out to destroy a patent troll:

https://www.techdirt.com/articles/20210426/09454946684/patent-troll-sable-networks-apparently-needs-to-learn-lesson-cloudflare-wants-to-destroy-another-troll

Mike

TC x IRRd 4.2

[Rubens Kuhl]

Hi all.

TC IRR, an IRR operator focused on Brazilian networks, just changed to IRRd
4.2.
The new version allowed TC to deploy RPKI validation (thanks NTT for
sponsoring that development) and expose HTTPS endpoints for WHOIS and
submission that we hope will foster innovation around the database.

Every precaution was taken for this migration to be seamless for other IRR
operators, including matching of serial numbers. Every IRR server that
mirrored TC and supported -j status query was verified that it followed and
still correctly follows database journals.

But if anything appears broken, please let me know or e-mail
db-ad...@bgp.net.br.

Thanks,
Rubens

Re: Something that should put a smile on everybody's face today

[Justin Paine via NANOG]

Correction -- another one.
https://blog.cloudflare.com/winning-the-blackbird-battle/   :)

Here's an except from the new blog post:

offering $100,000 to be shared by the winners who are successful in finding
such prior art.

Please help!



__
*Justin Paine*
He/Him/His
Head of Trust & Safety
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Tue, Apr 27, 2021 at 3:26 PM Michael Thomas  wrote:

>
> And we can help! Cloudflare is setting out to destroy a patent troll:
>
>
> https://www.techdirt.com/articles/20210426/09454946684/patent-troll-sable-networks-apparently-needs-to-learn-lesson-cloudflare-wants-to-destroy-another-troll
>
> Mike
>
>

Re: DNSSEC Best Practices

[Ca By]

On Tue, Apr 27, 2021 at 12:34 PM Eric Germann via NANOG 
wrote:

> Does anyone have a pointer to a good resource for current best practices
> for deployment of DNSSEC, preferably newer than RFC6781?
>
> What algorithms do you typically sign with (RSASHA256, ECDSAP256SHA256,
> both, something other)?
>
> Feel free to little r me off list if you wish
>

Probably best not to deploy it since it does not solve any practical
problems, yet makes huge ddos possible via dns reflection attacks.


> —
> Eric Germann
> ekgermann (at) semperen.com
> LinkedIn: https://www.linkedin.com/in/ericgermann
>
> GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1
>
>
>
>
>
>

Something that should put a smile on everybody's face today

[Michael Thomas]

And we can help! Cloudflare is setting out to destroy a patent troll:

https://www.techdirt.com/articles/20210426/09454946684/patent-troll-sable-networks-apparently-needs-to-learn-lesson-cloudflare-wants-to-destroy-another-troll

Mike

Re: DNSSEC Best Practices

[Arne Jensen]

Den 27-04-2021 kl. 21:31 skrev Eric Germann via NANOG:
> Does anyone have a pointer to a good resource for current best
> practices for deployment of DNSSEC, preferably newer than RFC6781?

RFC8624 "Algorithm Implementation Requirements and Usage Guidance for
DNSSEC"

-> https://tools.ietf.org/html/rfc8624

>
> What algorithms do you typically sign with
> (RSASHA256, ECDSAP256SHA256, both, something other)?

Those two mentioned are the ones that the vast majority seems to sign with.

As to quote the above mentioned RFC:

>ECDSAP384SHA384 shares the same properties as ECDSAP256SHA256 but
>offers a modest security advantage over ECDSAP256SHA256 (192 bits of
>strength versus 128 bits).  For most DNSSEC applications,
>ECDSAP256SHA256 should be satisfactory and robust for the foreseeable
>future and is therefore recommended for signing.  While it is
>unlikely for a DNSSEC use case requiring 192-bit security strength to
>arise, ECDSA384SHA384 is provided for such applications, and it MAY
>be used for signing in these cases.

I would also allow this one to be used, even if you personally may not
agree with it, or may like that particular algorithm / hash, or whatever.

-> https://www.dns.pl/formularze/ecc_support_in_dns_resolvers.pdf

While looking at Page 4, section 3 (Conclusions), saying:

> A similarobservation was made for DS digest algorithms. SHA-384was,
> unlike GOST R 34.11-94, almost as frequently sup-ported as SHA-256

I would personally say that there is no reasons for you not to allow
your customers/clients to take advantage of the "security advantage", if
they want it.

On the other hand, allowing signing with e.g. SHA1 is definitely a
NO-GO. But as the RFC says:

DNSKEY 8, 13, 14, 15 and 16
DS/CDS 2 and 4

is the only ones i would *eventually* look at, where I would personally
put my priority on 14 4, a.k.a. ECDSAP384SHA384.

A lot of people on the Internet might, like the RFC says, indicate that
13 2 (ECDSAP256SHA256) is more than enough, but I personally see no
reasons not to take the "strongest possible one, while ensuring broad
compatibility".


True or false? Also applicable to the ECDSA @ DNSSEC? Uhm Always a
good question, when you read something "online", but when seeing
multiple independent sources saying the same, ...?

SHA256 and SHA512 have been discussed about vulnerable to length
extension attacks, where SHA384 hasn't:

-> https://news.ycombinator.com/item?id=19916440

> SHA-256 and SHA-512 (not the truncated varieties) are known to be
> vulnerable to length extension attacks. This is only a problem if
> you're using these hash functions in a vulnerable way. (Which isn't as
> uncommon as you'd think in homebrew crypto.)
>
> [...]
>
> SHA-224, SHA-384, SHA-512/224, and SHA-512/256 are not vulnerable to
> length extension attacks.

Other URL's (that I've lost, or which vanished) have likewise been
shouting out things about SHA-224 and SHA-384 not being affected, but
that SHA-256 and SHA-512 was.

That one could probably also yell more and more for 14 4, a.k.a.
ECDSAP384SHA384, ... if you would really care about DNSSEC "done right".

Although, I wouldn't tend to believe that the implementers, according to
above, aren't implementing the DNSSEC "in a vulnerable way", as quoted
from the link above.


In the end, I would simply set up everything with 14 4, a.k.a.
ECDSAP384SHA384, unless any customers/clients could provide valid
justification (including evidence) why it "cannot" be used, such as e.g.
a TLD not supporting it, could be valid justification to make an
exception for that particular TLD. But in order to make that exception,
there would need to be evidence (from the customer/client) documenting
the claim, so they cannot just go with "I don't like this algorithm", or
other useless crap to go down to for example SHA1.

It would likewise be mandatory, if I had anything to say, for public
sector/government and financial institutions (banks, card issuers, and
so on), to run DNSSEC and to always secure that they had the strongest
possible algorithms on it.


NB: The reason I'm writing 14 4, a.k.a. ECDSAP384SHA384 all along is
that I've seen DNSSEC signatures with 14 2 (ECDSAP384SHA256), which I
would find quite weird.

Just my two cents.

-- 
Med venlig hilsen / Kind regards,
Arne Jensen

DNSSEC Best Practices

[Eric Germann via NANOG]

Does anyone have a pointer to a good resource for current best practices for 
deployment of DNSSEC, preferably newer than RFC6781?

What algorithms do you typically sign with (RSASHA256, ECDSAP256SHA256, both, 
something other)?

Feel free to little r me off list if you wish

—
Eric Germann
ekgermann (at) semperen.com
LinkedIn: https://www.linkedin.com/in/ericgermann

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1

Re: Verizon Wireless

[Mike Hammett]

https://puck.nether.net/mailman/listinfo/voiceops 


Also, look up the VZW contacts in the NPAC Helpdesk and ask them directly. I 
learned that little tidbit only a couple of months ago. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Chris Whelan"  
To: nanog@nanog.org 
Sent: Tuesday, April 27, 2021 12:00:00 PM 
Subject: Verizon Wireless 


Hello everyone, I know this is a long shot, but I'm hoping someone on here 
works for Verizon Wireless or knows someone that is in a position to assist us. 
Recently, a change to call routing occurred and Verizon Wireless calls are now 
being delivered across our tandem instead of a SIP peer. Ideally, I would like 
to establish a SIP trunk to Verizon Wireless but changing the call flow is the 
short term goal. Thanks in advance for your help! 



























Christopher Whelan 
Director of Network Engineering 
GWI 

office 207-602-1115 
cell 207-751-5013 www.gwi.net 

Verizon Wireless

[Chris Whelan]

Hello everyone, I know this is a long shot, but I'm hoping someone on here
works for Verizon Wireless or knows someone that is in a position to assist
us.  Recently, a change to call routing occurred and Verizon Wireless calls
are now being delivered across our tandem instead of a SIP peer.  Ideally,
I would like to establish a SIP trunk to Verizon Wireless but changing the
call flow is the short term goal.  Thanks in advance for your help!




Christopher Whelan

Director of Network Engineering

GWI

office 207-602-1115

*cell* 207-751-5013
www.gwi.net

Re: DoD IP Space

[Randy Bush]

>> what i hope is that they publish the results of their experiment.  a
>> bit more depth in discussion in ripe community.
> 
> https://bgp.he.net/AS8003#_prefixes

those are not results of an experiment. those are some visible artifacts
of (possibly part of) an experimental setup.

what i meant was the *results* of their measurements and the insights
gained.

< snark >

( and when i wanted to know what prefixes were being announced, i looked
  at my own router(s).  neither cisco, juniper, nor arcos seemed to have
  the equivalent of
  `show ip bgp regexp _8003$ insight`
  though i have been asking for years
  :)

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: DoD IP Space

[Randy Bush]

>> anyone seeing roas in 11/8?  i am not.
> am not either, I would be curious to know if the RPKI discussion came up
> for the prefixes in the run up to turning up this new service.

what i hope is that they publish the results of their experiment.  a bit
more depth in discussion in ripe community.

---

From: Randy Bush 
Subject: Re: [anti-abuse-wg] AS8003 and U.S. Department of Defense routing
To: Brian Nisbet 
Cc: Anti Abuse WG 
Date: Tue, 27 Apr 2021 08:22:16 -0700

interesting wg to do routing security analysis.

as i do really not know the dod's or their proxy's motive(s), i can not
say much about their tactics let alone strategy.

i do know, and have actually seen and experienced, part of 11/8 being
used as if it was 1918 space; ripe bologna was the first time.  and the
food in that town was fantastic!

a /8 telescope would pick up leakage patterns as well as the current
shotgun blast of announcements (i presume folk have looked at the actual
announcements).  i would naïvely think that the /8 might be slightly
more easily analyzed than the pieces.

maybe, as the telescope analysis shows focused leaks, they are trying to
disrupt those focused uses with these focused announcements.

but, if an op is using 11.12.666.0/23 internally, would they be careless
enough to accept an exogenous announcement of that space?  i guess i
should not underestimate carelessness.

is some random (small, i hope) isp using my address space internally as
1918 equivalent abusive, beyond their customers maybe not be able to
reach my network?  if so, maybe the vigilantes are looking in the wrong
direction.

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: DoD IP Space

[Christopher Morrow]

On Mon, Apr 26, 2021 at 10:18 PM Randy Bush  wrote:

> anyone seeing roas in 11/8?  i am not.
>
>
am not either, I would be curious to know if the RPKI discussion came up
for the prefixes in the run up to turning up this new service.
I'd also love to know if they are planning to publish ROA :) it'd be handy
in telling the rest of the world: "Hey, the owners of the space
authorize ASNFOO/BAR/BAZ that the announcement(s) you see are ok by them"

it might also have closed down some of the initial 'WUT?' conversation
about these prefixes.
-chris

Re: EMail server gets blocked by Microsoft

[Richard]

> Date: Tuesday, April 27, 2021 09:35:35 +0200
> From: Dominque Roux 
>
> is there anyone out there who has some experience with the blocking
> mechanism of Microsofts mail server? We're running a mail server at
> our company which ends up on their blacklist from time to time and
> we're wondering if there are some steps we could take in order to
> prevent this.

You may want to join the mailop mailing list:

   List-Archive: 
   List-Post: 
   List-Subscribe: ,


and ask there as it seems more applicable to that list, and is a
common topic of discussion there.

Re: EMail server gets blocked by Microsoft

[Michael Fallen]

Microsoft seems to be one of the worst offenders in terms of having a 
email blocking blackbox. Good luck getting in contact with someone as 
well. Throughout the years of self-hosting email they have always been 
the most problematic of the large providers.


--
Mike

Dominque Roux wrote on 2021-04-27 3:35 AM:

Hi All,

is there anyone out there who has some experience with the blocking
mechanism of Microsofts mail server? We're running a mail server at our
company which ends up on their blacklist from time to time and we're
wondering if there are some steps we could take in order to prevent this.

Cheers,
Dominique

RE: EMail server gets blocked by Microsoft

[yasuo]

Hi Dominuque,

If you mean "Microsoft 365" mail servers, your mail server is quite possibly 
listed frequently on Spamhaus' blocklists.
https://www.spamhaus.org/

Check back with Spamhaus on your reputation to find out what you can do.

Cheers,
跡部 靖夫 (ATOBE, Yasuo)
ya...@atobe.com

-Original Message-
From: NANOG  On Behalf Of Dominque Roux
Sent: Tuesday, April 27, 2021 4:36 PM
To: nanog@nanog.org
Subject: EMail server gets blocked by Microsoft

Hi All,

is there anyone out there who has some experience with the blocking mechanism 
of Microsofts mail server? We're running a mail server at our company which 
ends up on their blacklist from time to time and we're wondering if there are 
some steps we could take in order to prevent this.

Cheers,
Dominique

RE: EMail server gets blocked by Microsoft

[Brian Turnbow via NANOG]

Hi Dominque,

And sign up for snds
https://sendersupport.olc.protection.outlook.com/snds/index.aspx

It will give you the status of your IPs and  you can get jenkmail reports etc.

Brian

From: NANOG  On Behalf Of Mel Beckman
Sent: Tuesday, April 27, 2021 4:19 PM
To: Dominque Roux 
Cc: nanog@nanog.org
Subject: Re: EMail server gets blocked by Microsoft

Dominque,

Have you read this Microsoft guidance on email servers? It covers the most 
common problems, such as missing SPF records, incorrect or missing IN-ADDR DNS, 
etc:

https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx



 -mel beckman


On Apr 27, 2021, at 6:54 AM, Dominque Roux 
mailto:dominique.r...@ungleich.ch>> wrote:
Hi All,

is there anyone out there who has some experience with the blocking
mechanism of Microsofts mail server? We're running a mail server at our
company which ends up on their blacklist from time to time and we're
wondering if there are some steps we could take in order to prevent this.

Cheers,
Dominique

Re: EMail server gets blocked by Microsoft

[Mel Beckman]

Dominque,

Have you read this Microsoft guidance on email servers? It covers the most 
common problems, such as missing SPF records, incorrect or missing IN-ADDR DNS, 
etc:

https://sendersupport.olc.protection.outlook.com/pm/troubleshooting.aspx



 -mel beckman

On Apr 27, 2021, at 6:54 AM, Dominque Roux  wrote:

Hi All,

is there anyone out there who has some experience with the blocking
mechanism of Microsofts mail server? We're running a mail server at our
company which ends up on their blacklist from time to time and we're
wondering if there are some steps we could take in order to prevent this.

Cheers,
Dominique

EMail server gets blocked by Microsoft

[Dominque Roux]

Hi All,

is there anyone out there who has some experience with the blocking
mechanism of Microsofts mail server? We're running a mail server at our
company which ends up on their blacklist from time to time and we're
wondering if there are some steps we could take in order to prevent this.

Cheers,
Dominique

Re: Peering/Google

[Ahmed Dala Ali]

I’ve been reached out off-list. 

> On Apr 26, 2021, at 10:50 PM, Ahmed Dala Ali  wrote:
> 
> Hi, 
> 
> Could someone from  Google peering team ping me off-list? We have an open 
> ticket, and the last response that we got was on Feb 23th. 
> 
> Regards, 
> Ahmed

Re: Myanmar internet - something to think about if you're having a bad day

[Bjørn Mork]

scott  writes:

> Telenor and Ooredoo, it's time to do the right thing.

Wrt Telenor, please see the info posted at
https://www.telenor.com/sustainability/responsible-business/human-rights/mitigate/human-rights-in-myanmar/directives-from-authorities-in-myanmar-february-2021/


Bjørn