Re: Input for Draft Document on Terminology in BGP/Global Routing
Moin, (Repost to list as my original reply had a wrong From:) On Thu, 2024-10-03 at 07:57 +0300, Saku Ytti wrote: > On Thu, 3 Oct 2024 at 07:04, Jeff Behrns via NANOG > wrote > > > This seems like a total misuse of the RFC framework / process and > > more a grab at publicity, but I'll play along...bogon. You should > > include the term "bogon". Someday when I'm done keeping actual > > production networks alive, I may wade into the morass of IETF & > > IEEE and work on trimming the fat...or maybe just retire. It's a > > tough call. > > Not saying I agree or disagree, what is the definition of appropriate > use and how does this particular draft violate in comparison to the > existing corpus? > > Someone might want to argue RFCs are for technical implementations, > but there are increasingly many RFCs with no relevance to technical > implementations at all, which are significantly more soft ball than > the work proposed here. There are a couple of operations focused WGs (DNSOP, GROW) that indeed produce mostly operational documents; And, i mean, operational guidance is at least as old as RFC1032 (being the first one springing to my mind; Likely older ones exist, but I don't have them at the top of my head.). The purpose of this document is mostly just summarizing the terms currently used, as the ambiguity of terms makes documents sometimes a bit difficult: The peer [BGP neighbor] to which our router peers [has established a session] so we can peer [process of having a peering relationship] with our peer [AS relationship] has been depeered [removal of BGP sessions]. It is not meant to be authoritative, i.e., unlike RFC8499 for DNS, to ensure that it has some chance of actually making progress without having to order dedicated truckloads of planks for the new bikeshed to build (yes, i know, the shed should be made of concrete instead of wood; But that is how i'd build it). With best regards, Tobias
Input for Draft Document on Terminology in BGP/Global Routing
Moin, I have been working on a document listing terms & abbreviations used in the context of BGP/Global Routing Operations (leftovers from the cut- down of the attempts to update documents in BCP194): https://datatracker.ietf.org/doc/draft-fiebig-grow-routing-ops-terms/02/ I just setup a web-form to collect further terms & abbreviations people would like to also see in the document; If you have a minute, it would be appreciated if you could scroll the document and drop a few lines on what you would like to see added https://files.measurement.network/apps/forms/s/CMXjrtCPD8QyG6CAWmSLmg4y (In case anyone is concerned: Responses will only be used to update the I-D, and not for any form of research. ;-)) With best regards, Tobias P.S.: No, I will not open the box of defining what a Tier-1 is; That definition can stay in RFC7454, and I believe it is better not to touch that topic. ;-) -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tob...@fiebig.nl
Mail Sending Self-Test Platform
Heho, after our paper on mail sending configurations some time ago [1], we now glued that together into a self-service site: https://email-security-scans.org/ Even though some of you might have already seen this at the APNIC blog or on other lists, i though i'd still drop it here as well, especially given that it includes a full IPv6 readiness test for mail infra (recursive DNS, authoritative DNS, and v6 mail delivery ;-)). I'd be happy to hear your feedback, especially if things do not work as expected (then, your test ID and ideally stored emails would be really helpful, so i can double check what went wrong). More details below (also see [2] for an overview of the tests we run). Please note that setting up the tests (as we have to configure vhosts for some MTA-STS cases etc.) takes some time on our site. The test-site should periodically reload and provide the status. As we use JS for that part, please reload it manually every few minutes if you block JS. I would also be interested to hear what you think should be included in addition to the current tests; Some of our plans for the future below as well. We already found some interesting bits, like Vultr having lame v6 delegation for their AuthNS servers' domain, making their domain and rDNS non v6-resolvable [3], or mail-in-a-box using relaxed/simple for DKIM, which breaks signature validity on long To: headers [4]. If you want me to block certain domains/IPv(4|6) ranges or ASes for the service to keep your users from using it, please let me know and i will implement it asap. # Overview The site tests a variety of parameters about mail sending (details: [2]), by evaluating mails a user sends us in reply to a message that can be requested on the site. Simply requesting a message on the site does not start any evaluation or measurements, i.e., you have to send a reply-all to a requested message to start the evaluation. After the test, you can also delete the test or download a copy of your data, and if you opted to do so, a copy of the emails as we received them. # Method Users send emails to us (in reply-all to a message we sent, for easier usability).Target MXes on our site are either configured in a fully RFC compliant way, or intentionally misconfigured in a common way (broken DNSSEC for the domain, for example, or a broken DANE record, again, see [2] for an overview). Thereby, we can determine the configuration/support of features by the senders' MXes. # Possible Harm The worst thing that should happen to mail operators is finding specific undeliverable mails (broken DNSSEC if DNSSEC is validated, v6 only DNS if no IPv6 DNS resolution is supported) in their mail queue, or users receiving bounces (see FAQ on the page). So far the system has been tested with several hundred mail-setups, without encountering issues. If you encounter other unintended side-effects, please reach out to ab...@email-security-scans.org or me directly off-list. # Test details Specifically, we are testing: - v4 Mail sending - v6 Mail sending - Greylisting support - Transport encryption (Plaintext/TLS cipher strength and version support, opportunistic encryption) - DANE support outbound, i.e., if you honor DANE - MTA-STS support outbound, i.e., if you honor MTA-STS (incl. whether you prefer DANE over MTA-STS, as it should be) - Sending of TLS reports and whether these are standard compliant, also providing a copy of the received report (Even though so far only three operators delivered TLS-RPT). - DNS resolvers used by the mailserver - Whether the mailers' DNS servers resolve via IPv6 - Whether the mailers' DNS servers validate DNSSEC - If all names relevant for email delivery resolve via IPv6 - If all names relevant for email delivery are DNSSEC signed - Mailer-basics (ehlo=rdns=fcrdns), SPF (from/envelope) - SPF policy size (by retrieving your policy, up to 20 referrals deep) - DKIM (also checking key-sizes, algorithm mismatches and canonicalization issues; These are surprisingly common, i.e., simple being set breaking only in cases not caught by standard dkim testers) - DMARC (policy validity, conformance of sent mails, displaying implicit defaults) - DMARC report deliverability by sending one(1) valid DMARC report for a received email, including authorization of out-of-domain RUA/RUF (also providing a copy of any bounces received) - Full IPv6 readiness (join over three previous IPv6 tests) - Whether any headers that should not be duplicated are duplicated - Whether any mandatory headers are missing - If From/Envelope match # Planned tests - ARC - evaluate outbound spam filtering - evaluate received_from stripping - test for inbound-link parsers - cluster by provider (via MTA sets), not domain - Add DANE checks for senders' MXes - test for host-addresses in SPF prefixes - add MTA-STS check for senders' domains - add test for handling more than 5 MX with only the lowest-prio one(s) being reachable - requesting-domains' MX aspects (null MX, IPv4/6 addr
RE: any dangers of filtering every /24 on full internet table to preserve FIB space ?
Heho,
Let alone $all the /24 assigned under the RIPE waiting list policy.
In the Geoff Huston spirit, I quickly took a look how less specifics for /24s
looks in my table:
8 {'no_less_specific': 16, 'has_less_specific': 0, 'sum': 16,
'least_specific_length': {}}
9 {'no_less_specific': 9, 'has_less_specific': 4, 'sum': 13,
'least_specific_length': {'8': 4}}
10 {'no_less_specific': 38, 'has_less_specific': 0, 'sum': 38,
'least_specific_length': {}}
11 {'no_less_specific': 98, 'has_less_specific': 4, 'sum': 102,
'least_specific_length': {'10': 4}}
12 {'no_less_specific': 269, 'has_less_specific': 31, 'sum': 300,
'least_specific_length': {'9': 5, '11': 23, '8': 1, '10': 2}}
13 {'no_less_specific': 490, 'has_less_specific': 98, 'sum': 588,
'least_specific_length': {'11': 46, '8': 2, '12': 48, '10': 2}}
14 {'no_less_specific': 1022, 'has_less_specific': 188, 'sum': 1210,
'least_specific_length': {'13': 99, '8': 4, '12': 44, '11': 33, '10': 8}}
15 {'no_less_specific': 1641, 'has_less_specific': 476, 'sum': 2117,
'least_specific_length': {'14': 210, '13': 95, '12': 87, '11': 37, '8': 21,
'9': 3, '10': 23}}
16 {'no_less_specific': 10319, 'has_less_specific': 3286, 'sum': 13605,
'least_specific_length': {'15': 577, '14': 527, '12': 470, '13': 548, '9': 14,
'11': 446, '8': 173, '10': 531}}
17 {'no_less_specific': 4474, 'has_less_specific': 3942, 'sum': 8416,
'least_specific_length': {'16': 1816, '14': 536, '12': 276, '13': 343, '8': 44,
'15': 324, '9': 4, '10': 181, '11': 418}}
18 {'no_less_specific': 6926, 'has_less_specific': 7179, 'sum': 14105,
'least_specific_length': {'17': 888, '14': 1367, '16': 2394, '15': 776, '12':
289, '13': 487, '9': 15, '11': 514, '8': 108, '10': 341}}
19 {'no_less_specific': 15056, 'has_less_specific': 10151, 'sum': 25207,
'least_specific_length': {'17': 813, '16': 2561, '15': 1113, '13': 758, '14':
1373, '12': 544, '18': 1213, '8': 198, '9': 28, '11': 770, '10': 780}}
20 {'no_less_specific': 19592, 'has_less_specific': 24430, 'sum': 44022,
'least_specific_length': {'17': 1319, '14': 3435, '16': 6868, '12': 1216, '11':
1568, '13': 2221, '15': 1919, '18': 1450, '19': 2465, '9': 45, '8': 374, '10':
1550}}
21 {'no_less_specific': 22889, 'has_less_specific': 30065, 'sum': 52954,
'least_specific_length': {'17': 1886, '16': 5234, '14': 2569, '13': 1346, '19':
5019, '18': 1717, '12': 2011, '9': 78, '20': 3210, '15': 1760, '8': 513, '11':
3001, '10': 1721}}
22 {'no_less_specific': 59137, 'has_less_specific': 51280, 'sum': 110417,
'least_specific_length': {'17': 3787, '16': 10049, '13': 5469, '19': 4100,
'14': 3784, '21': 3287, '18': 3128, '11': 2965, '12': 3428, '20': 4152, '15':
3157, '8': 1018, '9': 166, '10': 2790}}
23 {'no_less_specific': 41052, 'has_less_specific': 60043, 'sum': 101095,
'least_specific_length': {'17': 3844, '21': 3382, '14': 3324, '16': 10032,
'22': 13207, '19': 5658, '15': 3007, '18': 2973, '11': 2243, '13': 1645, '12':
1752, '9': 277, '20': 4941, '8': 1260, '10': 2498}}
24 {'no_less_specific': 257032, 'has_less_specific': 295714, 'sum': 552746,
'least_specific_length': {'22': 38330, '17': 19319, '16': 51487, '21': 16799,
'23': 14813, '13': 10067, '14': 14328, '20': 26634, '18': 19216, '12': 9440,
'11': 10001, '15': 14437, '9': 2700, '19': 31119, '10': 7992, '8': 9032}}
So it seems like there is a healthy amount (~260k) prefixes which lack a less
specific.
With best regards,
Tobias
-Original Message-
From: NANOG On
Behalf Of Stephane Bortzmeyer
Sent: Monday, 10 October 2022 17:21
To: Edvinas Kairys
Cc: NANOG Operators' Group
Subject: Re: any dangers of filtering every /24 on full internet table to
preserve FIB space ?
On Mon, Oct 10, 2022 at 05:58:45PM +0300, Edvinas Kairys
wrote a message of 35 lines which said:
> But theoretically every filtered /24 could be routed via smaller
> prefix /23 /22 /21 or etc.
I don't think this is true, even in theory, specially for legacy prefixes.
There is probably somewhere a Geoff Huston survey on /24 without a covering
route.
Study on understanding email configuration quality
Dear all, I am a researcher at TU Delft in the Netherlands, looking into Security & Protocol Adoption. My student Olamide is looking into how well email setups are maintained around the globe. For this, we need many people, ideally from smaller providers, i.e., with non gmail/hotmail/yahoo addresses, to send us emails. Please consider participating in this study, and sharing it in your networks. To help us, please follow the instructions at: https://www.email-security-scans.org/ Important caveat: If your mailer validates recipient addresses before accepting mails, you might be unable to send to destination addresses that are (a) only resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test DNSSEC validation. If this is the case, please just remove the 1-3 offending addresses from the To: header. Please also note that our test setups will test whether the host delivering mails to us is an open relay. Also note that you may receive bounces from your mailserver for some of the destination addresses, e.g., if mails can not be delivered via IPv6, or if your mail-setup validates DANE records for our DANE test domain. We do _not_ need a copy of those bounces. In case you want to get results for a domain you operate or use early, please just drop me an email from the same domain and delivering servers after you participated, and I will share the data with you. :-) Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft
