- mice-discuss - lists.micemn.net

Re: RPKI ROAs

by Richard Laager

I intend to publish the following ROAs on MICE's behalf to indicate that the peering LAN is not to appear in the Internet routing table: On Monday (June 19) around 10:00 AM: 2001:504:27::/48 AS0 maxLength 128 On Wednesday (June 21) around 10:00 AM: 206.108.255.0/24 AS0 maxLength 32 The reason for the maxLength is: "By convention, an AS 0 ROA should have a maxLength value of 32 for IPv4 addresses and a maxlength value of 128 for IPv6 addresses" -- RFC 6483, section 4. This should only be an issue for someone if they are advertising the MICE peering subnet in their iBGP (which we discourage) and are doing RPKI validation of that iBGP (which seems unlikely). If you think this will be a problem for you, let me know. -- Richard

June 14, 2023

Re: RPKI ROAs

by Richard Laager

On 2023-06-14 02:46, David Farmer wrote: > I think we should hold off publishing one just yet Do you have a particular reason for thinking we should hold off? Is there something you're worried about breaking? While I take your point that not everyone is doing it, that APNIC blog post definitely shows that some places /are/ doing it. -- Richard

June 14, 2023

Re: RPKI ROAs

by Richard Laager

On 2023-06-14 07:23, Chris Wopat wrote: > Related to this, is there intent to join the IXP section of MANRS once > we're in good shape with some of this IRR filtering? I submitted the application now. -- Richard

June 14, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

After finishing up with the last minute inquiries, I deployed these changes. As far as I am aware, for everyone that has been in contact with me, things are either: A) resolved, B) been given an exception, or C) are irrelevant (see the "don't count") at the end of this email. The things that are filtered should only be people who never responded. The following routes are being filtered on rs1 (and rs2). That is, this is what is effectively "blocked" (for lack of route/route6 objects, ignoring rejections for other causes) /excluding/ the 4 exceptions: AS5056: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0047_as5056 206.83.43.0/24 AS5056 AS6939: Too many routes to list. They have looser IRR policies <https://routing.he.net/algorithm.html> (specifically, I think the RIR handle matches allow a lot that traditional IRR filtering does not). Bilateral with them if you want those. AS10242: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0028_as10242 23.130.82.0/24 AS398200 AS11796: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0051_as11796 192.236.20.0/24 AS25958 192.236.21.0/24 AS25958 https://ixpmgr.micemn.net/lg/rs1-ipv6/routes/protocol/pb_0051_as11796 2604:f9c0::/32 AS397064 AS16851: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0060_as16851 170.31.248.0/21 AS27534 170.31.160.0/23 AS27534 AS22402: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0088_as22402 206.11.94.0/24 AS22402 AS27204: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0095_as27204 198.98.192.0/21 AS396853 AS40413: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0076_as40413 207.250.207.0/24 AS40413 198.204.66.0/24 AS40413 AS393639: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0112_as393639 192.55.242.0/23 AS393639 These don't really count: AS26794: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0048_as26794 208.85.166.0/24 AS40569 -- IP space and AS recently removed from WHOIS. 208.85.167.0/24 AS40569 -- IP space and AS recently removed from WHOIS. AS55009: https://ixpmgr.micemn.net/lg/rs1-ipv4/routes/protocol/pb_0002_as55009 69.57.200.0/24 AS400080 -- This is going away and they will pull the announcement tomorrow. -- Richard

June 14, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-06-14 00:01, Richard Laager wrote: > > I am on track to make this enforcing tomorrow. > I am still answering last minute queries from people. I expect this will be another hour or so. -- Richard

June 14, 2023

Re: RPKI ROAs

by Chris Wopat

On 6/14/23 01:14, Richard Laager wrote: > > In the ARIN web UI, it looks like a ROA can have multiple prefixes. For > an end network such as myself (Wiktel hat on), what is the best > practice... one ROA per prefix, or list multiple prefixes in the same ROA? As August noted it's an exercise of the user. One note on this - you may not MODIFY an ROA (from what I can tell), so if you publish a single ROA with multiple prefixes and need to change something, you have to delete and recreate the entire thing. We've been doing 1:1 ROA:Prefix for this reason (for now, and we're not fully covered) Related to this, is there intent to join the IXP section of MANRS once we're in good shape with some of this IRR filtering? I believe that would be the final 'Action' (action 1). https://www.manrs.org/ixps/actions/ https://www.manrs.org/ixps/participants/ -- Chris Wopat Network Engineer, WiscNet wopat(a)wiscnet.net 608-210-3965

June 14, 2023

Re: RPKI ROAs

by David Farmer

On Wed, Jun 14, 2023 at 01:14 Richard Laager <rlaager(a)wiktel.com> wrote: > As far as I can see, there's no explicit way to say "do not announce" in > a ROA. But listing something with an origin AS of "0" seems to be a > thing that is done for at least one deliberately invalid ROA > (CloudFlare's 103.21.244.0/23). So, if I were to create a ROA for MICE, > would that be an Origin AS of 53679 or 0? An AS 0 ROA is an explicit statement that a prefix is not to be routed, see section 4 of RFC 6483; https://datatracker.ietf.org/doc/html/rfc6483#section-4 To the question, should we issue an AS 0 ROA for the MICE prefix? Well, there isn’t a strong consensus on that within IX Community. See the following APNIC Blog post; https://blog.apnic.net/2023/03/24/rpki-roa-for-ip-resources-in-the-ix-segme… So I think we should hold off publishing one just yet, but I suspect we will eventually want to publish an AS 0 ROA for the MICE prefix. Thanks > -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

June 14, 2023

Re: RPKI ROAs

by August Yang

RFC6482 doesn't explicitly specify whether to have one ROA per prefix or vice versa. In a delegated setup, Krill aggregates ROAs whenever possible, so it's left up to your preference. https://console.rpki.co/rpki.co/repo/AS945/1/AS50058.roa.html When it comes to MICE, it's recommended to publish a ROA covering the peering LAN. This not only secures against prefix hijacking but also prevents any accidental leaking, which has happened to NL-IX for example. Per RFC6907, an AS 0 ROA serves as an attestation by a prefix holder that the prefix described in the ROA, along with any more specific prefixes, should not be used in a routing context. AS0 is better in that one can simply prepend AS53679 to deliberately hijack the prefix, which could be prevented by ASPA but that's another story, and A BGP speaker MUST NOT originate or propagate a route with an AS number of zero (RFC7606). > From: nlixannounce(a)simplelists.com <nlixannounce(a)simplelists.com> on behalf of NL-ix Support <support(a)nl-ix.net> > Sent: Tuesday, February 22, 2022, 3:48 AM > To: Support-NLix <support(a)nl-ix.net> > Subject: [NL-ix Announce] Recent incidents in peering VLAN > Dear members, > We have recently experienced some unfortunate events on our peering VLAN due to the announcement of a more-specific prefix that is part of our /22 subnet. One of our members accidentally announced 193.239.117.0/24 to one of their upstreams, propagating this prefix to the rest of the internet. Although one would expect this prefix to be dropped early on due to IRR validation failing, it was instead widely propagated. On 2023-06-14 2:14 a.m., Richard Laager wrote: > In the ARIN web UI, it looks like a ROA can have multiple prefixes. > For an end network such as myself (Wiktel hat on), what is the best > practice... one ROA per prefix, or list multiple prefixes in the same > ROA? > > With my MICE hat on, should MICE publish a ROA for the peering network > space? The theoretical advantage would be some amount of hijacking > protection. Though since it's not supposed to be announced, it > probably doesn't matter much either way? > > As far as I can see, there's no explicit way to say "do not announce" > in a ROA. But listing something with an origin AS of "0" seems to be a > thing that is done for at least one deliberately invalid ROA > (CloudFlare's 103.21.244.0/23). So, if I were to create a ROA for > MICE, would that be an Origin AS of 53679 or 0? > -- Best regards August Yang

June 14, 2023

RPKI ROAs

by Richard Laager

In the ARIN web UI, it looks like a ROA can have multiple prefixes. For an end network such as myself (Wiktel hat on), what is the best practice... one ROA per prefix, or list multiple prefixes in the same ROA? With my MICE hat on, should MICE publish a ROA for the peering network space? The theoretical advantage would be some amount of hijacking protection. Though since it's not supposed to be announced, it probably doesn't matter much either way? As far as I can see, there's no explicit way to say "do not announce" in a ROA. But listing something with an origin AS of "0" seems to be a thing that is done for at least one deliberately invalid ROA (CloudFlare's 103.21.244.0/23). So, if I were to create a ROA for MICE, would that be an Origin AS of 53679 or 0? -- Richard

June 14, 2023

Re: IRR Mandatory at MICE / New Route Servers

by Richard Laager

On 2023-06-07 12:37, Richard Laager wrote: > > It turns out I made an error in the IRR prefix enforcement. So while > we were enforcing the as-set requirement as intended, we were /not/ > enforcing the route object requirement on rs2. Accordingly, I did > /not/ make that enforcing on rs1 today as scheduled. Instead, I > corrected it on rs2 and will wait another week before making it > enforced on rs1. > > I have separately emailed everyone who has prefixes being filtered. > From my perspective, I am on track to make this enforcing tomorrow. I have again emailed everyone who has prefixes being filtered. For the last two emails, I added the ARIN WHOIS contacts for the originating ASes (and for one email, the ARIN WHOIS contacts for the IP space involved). I've had a number of email and phone conversations with people. The list has definitely gotten much better. I have begrudgingly made exceptions for two networks. They have ARIN issues to sort out. (Yes, I am aware they could use some other registry and have mentioned that.) These exceptions will be time limited. These exceptions allow specifically the prefixes they are currently announcing that are being rejected. So these exceptions will not defeat IRR security in general (unlike just turning it off for them entirely). These exceptions will be on rs1 only, which will allow them/me to use the looking glass to rs2 to know if things are fixed. As a consequence, their routes will still be filtered when rs1 is down, e.g. for patching. They have been so informed. -- Richard

June 14, 2023