IRR Mandatory at MICE / New Route Servers
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. *What* * You MUST have an as-set object listing your AS and your downstream ASes (if any). o You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. *When* * *If you are a transit AS (i.e. have ASes behind you) and don't have an /as-set/ object, fix this **/now/**.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the /first/ new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. ** *Where* If you are not sure /where/ to create IRR records, use ARIN (assuming you are in the ARIN region). *How (with ARIN)* 1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! *Examples* Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) -- Richard
Thanks for your work on this, Richard! This is most excellent to see progress on. Will there be any "self-service" and/or visibility of this moving forward? (ie: IXP Manager login per member). Is RPKI validation part of this as well, or a future item (at least rejecting RPKI invalids from route servers)? Thanks, Andrew
On May 9, 2023, at 5:19 AM, Richard Laager <rlaager@WIKTEL.COM> wrote:
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.]
MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs.
What
You MUST have an as-set object listing your AS and your downstream ASes (if any). You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com <mailto:rlaager@wiktel.com> please). A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. When
If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. Where
If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region).
How (with ARIN)
Login to ARIN Online. (Go to arin.net and click Login in the top right.) On the left side, expand "Routing Security" and click "IRR". Click "as-set" at the top. Click "Create an Object". Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). Click "Review". Once ready, click "Submit". Click "route/route6" at the top. Click "Create an Object". Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. Click "Review". Once ready, click "Submit". Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! Examples
Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL
Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20
(I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.)
-- Richard
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
MICE members are able to see their AS-SET entry in IXP manager but not edit the entries. If members would like to check what is currently in the system, here is the link: https://ixpmgr.micemn.net Log in with PeeringDB credentials for your network. RPKI invalids will be rejected on the new route servers upon deployment. On Tue, May 9, 2023 at 10:57 AM Andrew Hoyos <hoyosa@gmail.com> wrote:
Thanks for your work on this, Richard! This is most excellent to see progress on.
Will there be any "self-service" and/or visibility of this moving forward? (ie: IXP Manager login per member).
Is RPKI validation part of this as well, or a future item (at least rejecting RPKI invalids from route servers)?
Thanks, Andrew
On May 9, 2023, at 5:19 AM, Richard Laager <rlaager@WIKTEL.COM> wrote:
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.]
MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs.
What
You MUST have an as-set object listing your AS and your downstream ASes (if any).
You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com please).
A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set.
When
If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now.
Where
If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region).
How (with ARIN)
Login to ARIN Online. (Go to arin.net and click Login in the top right.) On the left side, expand "Routing Security" and click "IRR". Click "as-set" at the top. Click "Create an Object". Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). Click "Review". Once ready, click "Submit". Click "route/route6" at the top. Click "Create an Object". Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. Click "Review". Once ready, click "Submit". Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6!
Examples
Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL
Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20
(I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.)
-- Richard
________________________________
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
________________________________
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
Thank you for your efforts in making routing more secure for the entire MICE community. Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers. On 2023-05-09 6:19 a.m., Richard Laager wrote:
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.]
MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs.
*What*
* You MUST have an as-set object listing your AS and your downstream ASes (if any). o You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set.
*When*
* *If you are a transit AS (i.e. have ASes behind you) and don't have an /as-set/ object, fix this **/now/**.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the /first/ new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now.
*Where*
If you are not sure /where/ to create IRR records, use ARIN (assuming you are in the ARIN region).
*How (with ARIN)*
1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6!
*Examples*
Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL
Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20
(I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.)
-- Richard
------------------------------------------------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
-- Best regards August Yang
Here are the current IRR sources. Please note ARIN-NONAUTH is not included. whois.radb.net RIPE whois.radb.net RIPE,RIPE-NONAUTH whois.radb.net RADB whois.radb.net LACNIC whois.radb.net AFRINIC whois.radb.net APNIC whois.radb.net LEVEL3 whois.radb.net ARIN whois.radb.net RADB,ARIN whois.radb.net ALTDB whois.radb.net RADB,RIPE whois.radb.net RADB,APNIC,ARIN whois.radb.net RIPE,ARIN On Tue, May 9, 2023 at 11:14 AM August Yang < 0000001654c01f33-dmarc-request@lists.iphouse.net> wrote:
Thank you for your efforts in making routing more secure for the entire MICE community.
Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers. On 2023-05-09 6:19 a.m., Richard Laager wrote:
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.]
MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs.
*What*
- You MUST have an as-set object listing your AS and your downstream ASes (if any). - You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com please). - A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set.
*When*
- *If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this **now**.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the *first* new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. - Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now.
*Where*
If you are not sure *where* to create IRR records, use ARIN (assuming you are in the ARIN region).
*How (with ARIN)*
1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6!
*Examples*
Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL
Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20
(I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.)
-- Richard
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
-- Best regards August Yang
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
I am specifically interested in feedback on this point. But please, only real-world scenarios, no speculation ("someone might ..."). Background: * This setting is per-participant. * Order is important. When looking for a given IRR object, the first source that includes that object will be used. * I think we want to prefer RIR-authenticated sources over others. Questions: 1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using it by the end of this, I'll just remove it. 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If nobody is using it by the end of this, I'll just remove it. 5. How do I set the source per participant? I /think/ what we want is the following, for each participant: 1. I use RADB's web interface to view the specified as-set. If the "source" of that object is an RIR registry, e.g. ARIN, I set the source in IXP Manager to that RIR source. If the source is RADB, I set the source to $RIR,RADB where $RIR is the RIR that issued the participant's ASN. For example, if someone is in the ARIN region, ARIN. If someone is in the RIPE region, RIPE. The idea is to make it easy for them to move to the RIR registry in the future. 2. I manually trigger the AS and prefix update and make sure I get results. 3. If the source is just $RIR, I then change this to $RIR,RADB. I manually trigger the AS and prefix update. If that second update changed nothing, I remove RADB. If that update did change something, then I eyeball it and make a decision. I would be looking to detect the scenario where e.g. the as-set is in the ARIN region but references customer ASes/as-sets that are in RADB; in such a case, I need to allow RADB. In contrast, if the records in RADB appear to be outdated and someone has moved to ARIN, I would want to remove RADB. If that becomes too tedious, a fallback option is to set everyone to something like ARIN,RIPE,RADB or ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is negotiable. I don't really know much about non-ARIN IRR.) On 5/9/23 11:25, Jay Hanke wrote:
Here are the current IRR sources. Please note ARIN-NONAUTH is not included.
whois.radb.net <http://whois.radb.net> RIPE whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH whois.radb.net <http://whois.radb.net> RADB whois.radb.net <http://whois.radb.net> LACNIC whois.radb.net <http://whois.radb.net> AFRINIC whois.radb.net <http://whois.radb.net> APNIC whois.radb.net <http://whois.radb.net> LEVEL3 whois.radb.net <http://whois.radb.net> ARIN whois.radb.net <http://whois.radb.net> RADB,ARIN whois.radb.net <http://whois.radb.net> ALTDB whois.radb.net <http://whois.radb.net> RADB,RIPE whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN whois.radb.net <http://whois.radb.net> RIPE,ARIN
On Tue, May 9, 2023 at 11:14 AM August Yang <0000001654c01f33-dmarc-request@lists.iphouse.net> wrote:
Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers.
-- Richard
Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources.
Should I drop RIPE-NONAUTH choices? Should I drop LEVEL3? Yes and no. RIPE-NONAUTH is essentially a dead database with no editing or new objects possible while LEVEL3 is actively used and there's no advantage in excluding it.
Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? At this point all RIR databases are authenticated.
On 2023-05-09 2:20 p.m., Richard Laager wrote:
I am specifically interested in feedback on this point. But please, only real-world scenarios, no speculation ("someone might ...").
Background:
* This setting is per-participant. * Order is important. When looking for a given IRR object, the first source that includes that object will be used. * I think we want to prefer RIR-authenticated sources over others.
Questions:
1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using it by the end of this, I'll just remove it. 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If nobody is using it by the end of this, I'll just remove it. 5. How do I set the source per participant? I /think/ what we want is the following, for each participant:
1. I use RADB's web interface to view the specified as-set. If the "source" of that object is an RIR registry, e.g. ARIN, I set the source in IXP Manager to that RIR source. If the source is RADB, I set the source to $RIR,RADB where $RIR is the RIR that issued the participant's ASN. For example, if someone is in the ARIN region, ARIN. If someone is in the RIPE region, RIPE. The idea is to make it easy for them to move to the RIR registry in the future. 2. I manually trigger the AS and prefix update and make sure I get results. 3. If the source is just $RIR, I then change this to $RIR,RADB. I manually trigger the AS and prefix update. If that second update changed nothing, I remove RADB. If that update did change something, then I eyeball it and make a decision. I would be looking to detect the scenario where e.g. the as-set is in the ARIN region but references customer ASes/as-sets that are in RADB; in such a case, I need to allow RADB. In contrast, if the records in RADB appear to be outdated and someone has moved to ARIN, I would want to remove RADB.
If that becomes too tedious, a fallback option is to set everyone to something like ARIN,RIPE,RADB or ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is negotiable. I don't really know much about non-ARIN IRR.)
On 5/9/23 11:25, Jay Hanke wrote:
Here are the current IRR sources. Please note ARIN-NONAUTH is not included.
whois.radb.net <http://whois.radb.net> RIPE whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH whois.radb.net <http://whois.radb.net> RADB whois.radb.net <http://whois.radb.net> LACNIC whois.radb.net <http://whois.radb.net> AFRINIC whois.radb.net <http://whois.radb.net> APNIC whois.radb.net <http://whois.radb.net> LEVEL3 whois.radb.net <http://whois.radb.net> ARIN whois.radb.net <http://whois.radb.net> RADB,ARIN whois.radb.net <http://whois.radb.net> ALTDB whois.radb.net <http://whois.radb.net> RADB,RIPE whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN whois.radb.net <http://whois.radb.net> RIPE,ARIN
On Tue, May 9, 2023 at 11:14 AM August Yang <0000001654c01f33-dmarc-request@lists.iphouse.net> wrote:
Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers.
-- Richard
------------------------------------------------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
-- Best regards August Yang
On 2023-05-09 14:01, August Yang wrote:
Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources.
In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard
I think a global list of sources would be easier to maintain and document. Is NTTCOM no longer trusted? I took a look at the AS11232 customer cone and there are a few objects in NTTCOM but it looked as though all of them also appear in another database so I don't have strong feelings that NTTCOM needs to be included. [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie@midco.com Midco.com From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 3:58 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email originated from outside of MIDCO. Do not click links or open attachments unless you recognize the sender and know the content is safe. On 2023-05-09 14:01, August Yang wrote: Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources. In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On 2023-05-11 05:58, Miles McCredie wrote:
I think a global list of sources would be easier to maintain and document.
Excellent point.
Is NTTCOM no longer trusted?
The available sources are here: https://www.radb.net/query/?advanced_query=1 That does include NTTCOM, so we could use it. But if nobody is speaking up in favor of it, I'm not currently planning on it. The list I gave was the union of all choices that exist in IXP Manager by default, minus ARIN-NONAUTH and RIPE-NONAUTH. -- Richard
I did a spot check of a few ASNs and it looks to me as though the following ASNs have route(6) objects that only exist in NTTCOM: 2906, 20940 and 33438. (Stopped looking after I found these three.) My recommendation is to include NTTCOM. The cruft in the database should be suppressed according to https://www.gin.ntt.net/support-center/policies-procedures/routing-registry/.... [http://images.midcocomm.com/ES_MidcoLogo.png] Miles McCredie Principal Network Engineer II-Core IP Office: 6052755192 Miles.McCredie@midco.com Midco.com From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 11:52 PM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [EXTERNAL] - Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers On 2023-05-11 05:58, Miles McCredie wrote: I think a global list of sources would be easier to maintain and document. Excellent point. Is NTTCOM no longer trusted? The available sources are here: https://www.radb.net/query/?advanced_query=1 That does include NTTCOM, so we could use it. But if nobody is speaking up in favor of it, I'm not currently planning on it. The list I gave was the union of all choices that exist in IXP Manager by default, minus ARIN-NONAUTH and RIPE-NONAUTH. -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
I do not see a need for per participant IRR, I would rather that they all just default to your example below. From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 3:58 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers On 2023-05-09 14:01, August Yang wrote: Should I reorder RADB,ARIN to be ARIN,RADB? Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources. In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3? -- Richard _____ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1> &A=1
Can't folks just specify which IRR in their IRR entry if desired? Ie ARIN::AS1234 FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used. Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example? --Chris On 5/11/23 10:01, Jeremy Lumby wrote:
External
I do not see a need for per participant IRR, I would rather that they all just default to your example below.
*From:*MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> *On Behalf Of *Richard Laager *Sent:* Thursday, May 11, 2023 3:58 AM *To:* MICE-DISCUSS@LISTS.IPHOUSE.NET *Subject:* Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers
On 2023-05-09 14:01, August Yang wrote:
Should I reorder RADB,ARIN to be ARIN,RADB?
Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources.
In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3?
--
Richard
------------------------------------------------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
------------------------------------------------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
-- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965
Would it be safe to assume that squatting wouldn't happen in the RIR's authenticated IRRs? And that if multiple entries exist among them, that keeping them in sync or free of bad data would be on the individual participant? If so placing the authenticated RIRs above everything else seems a pretty safe bet. Order among them wouldn't really matter. Personally given that I would love to see us grab the sets from the aut-num object for the participants ASN. Seems like ignoring the routing policy in the aut-num object in favor of PeeringDB or a manual process is only half using the IRR system. (That said I understand that bgpq3 doesn't use the aut-num object.) Tom Krenn Network Architect Enterprise Architecture - Information Technology -----Original Message----- From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Chris Wopat Sent: Thursday, May 11, 2023 10:30 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [External] Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. Can't folks just specify which IRR in their IRR entry if desired? Ie ARIN::AS1234 FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used. Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example? --Chris On 5/11/23 10:01, Jeremy Lumby wrote:
External
I do not see a need for per participant IRR, I would rather that they all just default to your example below.
*From:*MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> *On Behalf Of *Richard Laager *Sent:* Thursday, May 11, 2023 3:58 AM *To:* MICE-DISCUSS@LISTS.IPHOUSE.NET *Subject:* Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers
On 2023-05-09 14:01, August Yang wrote:
Should I reorder RADB,ARIN to be ARIN,RADB?
Definitely. We have objects registered in all databases feasible to prevent AS-SET squatting, which has occurred in the past, while only RADB has the actual members listed. Turns out correct prefix list can be generated using bgpq4 regardless of the order, so it's better to prioritize authenticated sources.
In thinking about this some more... Is IXP Manager's behavior of per-participant IRR sources actually useful? In other words, what's wrong with just setting everyone to: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,LEVEL3?
--
Richard
---------------------------------------------------------------------- --
To unsubscribe from the MICE-DISCUSS list, click the following link: https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF NQAWWg%3D&reserved=0 <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa FNQAWWg%3D&reserved=0>
---------------------------------------------------------------------- --
To unsubscribe from the MICE-DISCUSS list, click the following link: https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists .iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7C 01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8aef df9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7C TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC I6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2FaF NQAWWg%3D&reserved=0 <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist s.iphouse.net%2Fcgi-bin%2Fwa%3FSUBED1%3DMICE-DISCUSS%26A%3D1&data=05%7 C01%7Ctom.krenn%40HENNEPIN.US%7C2f7c1b8d95af410486a008db5234a38e%7C8ae fdf9f878046bf8fb74c924653a8be%7C0%7C0%7C638194158303151171%7CUnknown%7 CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV CI6Mn0%3D%7C3000%7C%7C%7C&sdata=hdjzW0mk8Kd2pgvauE5I0544Xhlox3CaSJ%2Fa FNQAWWg%3D&reserved=0>
-- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965 Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.
On 2023-05-11 10:30, Chris Wopat wrote:
Can't folks just specify which IRR in their IRR entry if desired? Ie
ARIN::AS1234
1. bgpq3 does not accept that format, at least in my limited testing. 2. IXP Manager would likely need changes to support that, specifically not passing the argument for sources to bgpq3 if a disambiguation was provided. 3. I think the more important fundamental issue is that a transit AS's as-set might need to reference customer ASes/as-sets that are in other registries.
FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used.
Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example?
See #3 above. For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used. -- Richard
For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used.
The provided list is the list of IRR (+ IRR combinations) that shows up in the pulldown menu in the admin interface of IXP Manager. It points to the where the AS-SET record is located for the directly attached member. So when you put the information in you select the IRR and type in (or pull) the AS-SET record. bgpq3/4 will then pull all the prefixes and generate a filter list from the union of all the prefixes listed. The AS_set name in the DB::NAME format will just need to be reformatted when entered into IXP Manager web interface.
FWIW, AS3128 uses some homegrown stuff to wrap bgpq4, bgpq4 provides an ability to deal with concern #3 below for recursion [if you choose to accept the caveats]. See https://github.com/bgp/bgpq4#notes-on-sources. It also handles the $REGISTRY::$THING model. This may just be cool info for the time being, but you may find it interesting. For AS3128 peers I've had to provide a way to list sources per peer; look up AS-SUPRANET in RIPE vs ARIN. The one I want is in ARIN so the ordering matters. Yes, I know AS-$number is a better idea and AS-UWSYSNET is also guilty as charged. -Michael
-----Original Message----- From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Thursday, May 11, 2023 11:27 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers
On 2023-05-11 10:30, Chris Wopat wrote:
Can't folks just specify which IRR in their IRR entry if desired? Ie
ARIN::AS1234
1. bgpq3 does not accept that format, at least in my limited testing.
2. IXP Manager would likely need changes to support that, specifically not passing the argument for sources to bgpq3 if a disambiguation was provided.
3. I think the more important fundamental issue is that a transit AS's as-set might need to reference customer ASes/as-sets that are in other registries.
FWIW we only use RADB but are fine if the common IRR's (but not legacy arin) are used.
Also is there any reason at all to use non-ARIN teritory IRR data? Do any MICE participants have anything in RIPE for example?
See #3 above.
For example, someone like Hurricane Electric can't ask all of their customers worldwide to be in ARIN. Given the way this has historically developed, I don't think it's even reasonable to expect that only-RIR registries are used.
-- Richard
I am currently allowing the following sources across the board: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,NTTCOM,LEVEL3 On 2023-05-12 11:14, Michael Hare wrote:
It also handles the $REGISTRY::$THING model.
Thanks for the tip! I switched from bgpq3 to bgpq4. IXP Manager doesn't support bgpq4, but the only difference was one flag. I used a wrapper script for now, and filed a feature request with IXP Manager: https://github.com/inex/IXP-Manager/issues/844 Arnold Nipper, via the IXP Manager mailing list, gave me an example of how to get this information out of PeeringDB. With that, I was able to write a script to interact with the IXP Manager database. It pulls the current settings from IXP Manager, pulls from PeeringDB, reports any changes, updates IXP Manager, and triggers the ASN & prefix updates in IXP Manager. I have that set to run hourly. The route servers will update their configuration hourly, offset by 30 minutes. That is, route server 1 will update at xx:08 and route server 2 will update at xx:38. -- Richard
This is the current cutover plan: Phase 1: On Tuesday, May 23, starting around 10:00 AM US/Central, we will upgrade route server 1. It will enforce the IRR as-set requirement for transit ASes, but will NOT enforce the IRR prefix requirement. Since route server 2 will still exist, even the as-set requirement is only a soft requirement. Phase 2: On Wednesday, May 31, starting around 10:00 AM US/Central, we will upgrade route server 2. It will be fully enforcing. At that point, the as-set requirement will be a hard requirement. The prefix IRR requirement will still be a soft requirement, as route server 1 will still not be enforcing. Phase 3: Tentatively, on Wednesday, June 7, starting around 10:00 AM US/Central, we will configure route server 1 to be fully enforcing. At that point, all IRR requirements will hard requirements. This date is subject to change based on what we see filtered. *We ask that you do /not/ take down your route server BGP sessions for these changes, as that will make it harder for us to know if things are working. If you are going to do so (e.g. because your organization's policies require it), then please let me know so I can expect your session to be down.* -- Richard
I added some bits about IXP Manager and IRR to the website: https://micemn.net/technical.html I also updated the communities bit to reflect what the new route servers will support. Suggestions welcome. -- Richard
On 2023-05-13 02:02, Richard Laager wrote:
Phase 2: On Wednesday, May 31, starting around 10:00 AM US/Central, we will upgrade route server 2. It will be fully enforcing. At that point, the as-set requirement will be a hard requirement. The prefix IRR requirement will still be a soft requirement, as route server 1 will still not be enforcing.
This work is about to commence.
Phase 3: Tentatively, on Wednesday, June 7, starting around 10:00 AM US/Central, we will configure route server 1 to be fully enforcing. At that point, all IRR requirements will hard requirements. This date is subject to change based on what we see filtered.
*We ask that you do /not/ take down your route server BGP sessions for these changes, as that will make it harder for us to know if things are working. If you are going to do so (e.g. because your organization's policies require it), then please let me know so I can expect your session to be down.*
-- Richard
We have sent emails to those networks with sessions down on route server 2. The following networks are known to have prefixes filtered on route server 2 by the new IRR filtering. For some of these networks, it is a prefix here or there. For others, it is a significant fraction or all prefixes. AS57: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0030_as57 AS803: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0053_as803 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0053_as803 AS3663: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0161_as3663 AS5056 has too many routes for IPv4 for me to check in the looking glass's web interface. You should probably compare the number of received prefixes to the number you are advertising. If there is a difference and you need help sorting it out, please get in touch. AS6939 has too many routes for IPv4 for me to check in the looking glass's web interface. I assume you know what you're doing, so I am not taking further action. AS11796: https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0051_as11796 AS12042: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0062_as12042 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0062_as12042 AS13335: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0078_as13335 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0078_as13335 AS13746: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0111_as13746 AS13767: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0141_as13767 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0141_as13767 AS14230: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0149_as14230 AS14828: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0059_as14828 AS15011: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0075_as15011 AS15169 has too many routes for IPv4 for me to check in the looking glass's web interface. I assume you know what you're doing, so I am not taking further action. AS15250: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0064_as15250 AS16851: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0060_as16851 AS16904: https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0033_as16904 AS18451: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0138_as18451 AS18883: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0026_as18883 AS20412: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0073_as20412 AS22402: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0088_as22402 AS25694: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0072_as25694 AS26794: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0048_as26794 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0048_as26794 https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0054_as26794 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0054_as26794 AS27204: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0095_as27204 AS31834: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0152_as31834 AS32097: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0020_as32097 AS40160: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0183_as40160 AS46692: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0118_as46692 AS53597: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0122_as53597 https://ixpmgr.micemn.net/lg/rs2-ipv6/routes/protocol/pb_0122_as53597 AS54578: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0105_as54578 AS55043: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0084_as55043 AS64227: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0093_as64227 AS396410: https://ixpmgr.micemn.net/lg/rs2-ipv4/routes/protocol/pb_0063_as396410 -- Richard
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. -- Richard
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
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
Update: We are now down to 2 prefixes with exceptions. One fixed 13 of 14 prefixes but seemingly missed one, so hopefully that will get fixed now that I've prodded them. The other hasn't responded in a while. I emailed again and left a voicemail. If I don't hear back, I'll probably just drop that one if/when the other network fixes theirs. Then the exceptions will be gone. -- Richard
Change as of yesterday: ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB,ALTDB*,*NTTCOM,LEVEL3,*BELL* -- Richard
On Tue, 2023-05-09 1:20 p.m., Richard Laager wrote:
I am specifically interested in feedback on this point. But please, only real-world scenarios, no speculation ("someone might ...").
Background:
* This setting is per-participant. * Order is important. When looking for a given IRR object, the first source that includes that object will be used.
In my (limited) experience, the filter generator makes a prefix-list using objects from all the approved IRRs that match the contents of the AS-SET. In my case, that means route(6) objects from ARIN and RADB are combined to make a prefix-list that's bigger than just ARIN or RADB-sourced objects. The order has not been relevant, nor specified. No need for NONAUTH sources, and ARIN has completely retired theirs. Cheers, Jonathan Jonathan Stewart Network Engineer LES.NET - AS18451 Desk: 1-204-666-6191 Mobile: 1-204-990-2120 130 Portage Avenue E Winnipeg, MB R3C 0A1 CANADA
* I think we want to prefer RIR-authenticated sources over others.
Questions:
1. Should I reorder RADB,ARIN to be ARIN,RADB and similar for RADB,RIPE and RADB,APNIC,ARIN? Tentative: Yes. 2. Should I drop RIPE-NONAUTH choices? Tentative: If nobody is using it by the end of this, I'll just remove it. 3. Does anyone know if AFRINIC, APNIC, and LACNIC are authenticated? 4. Does anyone know if people care about LEVEL3's IRR? Tentative: If nobody is using it by the end of this, I'll just remove it. 5. How do I set the source per participant? I /think/ what we want is the following, for each participant:
1. I use RADB's web interface to view the specified as-set. If the "source" of that object is an RIR registry, e.g. ARIN, I set the source in IXP Manager to that RIR source. If the source is RADB, I set the source to $RIR,RADB where $RIR is the RIR that issued the participant's ASN. For example, if someone is in the ARIN region, ARIN. If someone is in the RIPE region, RIPE. The idea is to make it easy for them to move to the RIR registry in the future. 2. I manually trigger the AS and prefix update and make sure I get results. 3. If the source is just $RIR, I then change this to $RIR,RADB. I manually trigger the AS and prefix update. If that second update changed nothing, I remove RADB. If that update did change something, then I eyeball it and make a decision. I would be looking to detect the scenario where e.g. the as-set is in the ARIN region but references customer ASes/as-sets that are in RADB; in such a case, I need to allow RADB. In contrast, if the records in RADB appear to be outdated and someone has moved to ARIN, I would want to remove RADB.
If that becomes too tedious, a fallback option is to set everyone to something like ARIN,RIPE,RADB or ARIN,RIPE,LACNIC,APNIC,AFRINIC,RADB. (The order of the RIRs is negotiable. I don't really know much about non-ARIN IRR.)
On 5/9/23 11:25, Jay Hanke wrote:
Here are the current IRR sources. Please note ARIN-NONAUTH is not included.
whois.radb.net <http://whois.radb.net> RIPE whois.radb.net <http://whois.radb.net> RIPE,RIPE-NONAUTH whois.radb.net <http://whois.radb.net> RADB whois.radb.net <http://whois.radb.net> LACNIC whois.radb.net <http://whois.radb.net> AFRINIC whois.radb.net <http://whois.radb.net> APNIC whois.radb.net <http://whois.radb.net> LEVEL3 whois.radb.net <http://whois.radb.net> ARIN whois.radb.net <http://whois.radb.net> RADB,ARIN whois.radb.net <http://whois.radb.net> ALTDB whois.radb.net <http://whois.radb.net> RADB,RIPE whois.radb.net <http://whois.radb.net> RADB,APNIC,ARIN whois.radb.net <http://whois.radb.net> RIPE,ARIN
On Tue, May 9, 2023 at 11:14 AM August Yang <0000001654c01f33-dmarc-request@lists.iphouse.net> wrote:
Could you please clarify which IRR source will be included for filter generation? We currently rely on RADb instead of ARIN for our IRR records, and it would be helpful to confirm if this will be used with the new route servers.
-- Richard
------------------------------------------------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 <http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1>
On 2023-05-09 14:16, Jonathan Stewart wrote:
In my (limited) experience, the filter generator makes a prefix-list using objects from all the approved IRRs that match the contents of the AS-SET.
In my case, that means route(6) objects from ARIN and RADB are combined to make a prefix-list that's bigger than just ARIN or RADB-sourced objects.
The order has not been relevant, nor specified.
FWIW, MICE is going to use IXP Manager's direct bird templating, not arouteserver (like MBIX uses), so the way this works may be slightly different. -- Richard
Will the filters be built off our aut-num object or just the as-set listed on PeeringDB? Tom Krenn Network Architect Enterprise Architecture - Information Technology [Hennepin County logo] From: MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> On Behalf Of Richard Laager Sent: Tuesday, May 9, 2023 5:20 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers CAUTION: This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments. [I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.] MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs. What * You MUST have an as-set object listing your AS and your downstream ASes (if any). * You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com<mailto:rlaager@wiktel.com> please). * A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set. When * If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now. Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the first new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. * Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now. Where If you are not sure where to create IRR records, use ARIN (assuming you are in the ARIN region). How (with ARIN) 1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6! Examples Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20 (I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.) -- Richard ________________________________ To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 Disclaimer: If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.
This is what we are seeing in IXP Manager. Looks like your config got pulled from PeeringDB. Network Information =================== Name : HENNEPIN-COUNTY Primary ASN : 40382 Also Known As : Website : https://www.hennepin.us/ IRR AS-SET : AS40382:AS-MEMBERS Network Type : Government Approx IPv6 Prefixes : 100 Approx IPv4 Prefixes : 100 Looking Glass : Route Server : Created at : 2021-12-21T16:47:05Z Updated at : 2022-08-29T22:55:11Z PrefixFirst seenLast seen 137.70.0.0/16 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-43ffe576808e1d023202af4faec3221d> 2023-03-27 00:08:07 2023-05-09 12:55:43 204.73.55.0/24 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-74fb2430d7d8ea4b1f390414b0a43269> 2023-03-27 00:08:07 2023-05-09 12:55:43 50.217.178.0/24 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-4add3bae394355548a2e897378a42546> 2023-03-27 00:08:07 2023-05-09 12:55:43 PrefixFirst seenLast seen 2606:e540::/32 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-62695e9e020d26faf9540f3747ba5728> 2023-03-27 00:08:07 2023-05-09 12:55:43 2606:e540::/36 <https://ixpmgr.micemn.net/index.php#ixpm-prefix-whois-5ed6e7f9e0a5db531a80d933ec61cdcf> 2023-03-27 00:08:07 2023-05-09 12:55:43 On Tue, May 9, 2023 at 12:54 PM Tom Krenn < 00000015253bd7fc-dmarc-request@lists.iphouse.net> wrote:
Will the filters be built off our aut-num object or just the as-set listed on PeeringDB?
Tom Krenn
Network Architect
Enterprise Architecture - Information Technology
[image: Hennepin County logo]
*From:* MICE Discuss <MICE-DISCUSS@LISTS.IPHOUSE.NET> * On Behalf Of *Richard Laager *Sent:* Tuesday, May 9, 2023 5:20 AM *To:* MICE-DISCUSS@LISTS.IPHOUSE.NET *Subject:* [External] [MICE-DISCUSS] IRR Mandatory at MICE / New Route Servers
*CAUTION:* This email was sent from outside of Hennepin County. Unless you recognize the sender and know the content, do not click links or open attachments.
[I plan to send this to MICE-ANNOUNCE too, but I want to see if anyone has corrections.]
MICE will soon be deploying new route servers which will require IRR (Internet Routing Registry) records, as is a best practice at IXPs.
*What*
- You MUST have an as-set object listing your AS and your downstream ASes (if any).
- You MUST either list that as-set in PeeringDB or email the name of your as-set to me (off-list to rlaager@wiktel.com please).
- A route/route6 object MUST exist for each prefix you announce to the route servers (whether originated by you or transited through you) and it must list an Origin AS that is in your as-set.
*When*
- *If you are a transit AS (i.e. have ASes behind you) and don't have an as-set object, fix this now.* Without an as-set object, your downstream ASes announcements will be blocked (filtered) immediately when the *first* new route server is cut in. (Granted, they will still work through the second route server until it is upgraded.) Figure you have 1-2 weeks at most. - Enforcement of the route/route6 objects (for both transit and non-transit ASes) will come later, but not a lot later. So please, start on this now.
*Where*
If you are not sure *where* to create IRR records, use ARIN (assuming you are in the ARIN region).
*How (with ARIN)*
1. Login to ARIN Online. (Go to arin.net and click Login in the top right.) 2. On the left side, expand "Routing Security" and click "IRR". 3. Click "as-set" at the top. 4. Click "Create an Object". 5. Fill in the fields: The "AS Set Name" is what you will list in PeeringDB (or email to me). "Description" is unparsed, but they suggest the location and have a button to "Copy the Address from My Org ID". "Members" is where you list your ASN and downstream ASes (if any). 6. Click "Review". Once ready, click "Submit". 7. Click "route/route6" at the top. 8. Click "Create an Object". 9. Fill in the fields: "Prefix" is the prefix, e.g. 192.0.2.0/24. "Origin" is your ASN. 10. Click "Review". Once ready, click "Submit". 11. Repeat to create additional route objects until all of your announcements are covered. Don't forget IPv6!
*Examples*
Here is my as-set: https://www.radb.net/query?keywords=AS-WIKTEL
Here is one example route: https://www.radb.net/query?keywords=69.89.192.0%2F20
(I created the AS33362 one. The AS19905 one is because another AS can originate this route for DDoS scrubbing reasons.)
--
Richard
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
*Disclaimer:* If you are not the intended recipient of this message, please immediately notify the sender of the transmission error and then promptly permanently delete this message from your computer system.
------------------------------
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On 5/9/23 12:54, Tom Krenn wrote:
Will the filters be built off our aut-num object or just the as-set listed on PeeringDB?
I /think/ they just use the as-set. Last night, I tested the underlying command against someone who does not have an aut-num, but does have route objects referencing their AS. Their prefixes were found. The underlying command is bgpq3. So if you really want to get low level, install that somewhere and run bgpq3 AS_SET_NAME and bgpq3 -6 AS_SET_NAME. IXP Manager actually runs that with more flags, but they aren't particular relevant (other than minimum prefix length). -- Richard
participants (10)
-
Andrew Hoyos -
August Yang -
Chris Wopat -
Jay Hanke -
Jeremy Lumby -
Jonathan Stewart -
Michael Hare -
Miles McCredie -
Richard Laager -
Tom Krenn