From james.braunegg at micron21.com Wed May 1 20:35:15 2024 From: james.braunegg at micron21.com (James Braunegg) Date: Wed, 1 May 2024 10:35:15 +0000 Subject: [AusNOG] Wanted - Network Engineer BGP VXLAN ISIS In-Reply-To: References: Message-ID: <71960dd46b1d4b099402486286cf6505@micron21.com> Dear All I am looking for a Highly Motivated and Talented Network Engineer to join my Melbourne team to help operate AS38880. If you or someone you know is skilled in BGP, ISIS, and VXLAN (eVPN) plus have a love for automation and SDN (OpenStack) and looking for a change please reach out to me! Information regarding this position can be found here https://www.seek.com.au/job/75184007 Kindest Regards James Braunegg [cid:image001.jpg at 01DA9C07.12154960] 1300 769 972 / 0488 997 207 james at micron21.com www.micron21.com/bbp-fibre-connect [cid:image002.jpg at 01DA9C07.12154960] [cid:image003.jpg at 01DA9C07.12154960] [cid:image004.jpg at 01DA9C07.12154960] Follow us on Twitter for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 428 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 2651 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 771 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 816 bytes Desc: image004.jpg URL: From david at hughes.id Mon May 6 11:43:11 2024 From: david at hughes.id (david at hughes.id) Date: Mon, 6 May 2024 11:43:11 +1000 Subject: [AusNOG] AusNOG 2024 registration is open Message-ID: <32C80E7F-682C-4F33-B891-326D4E75B8E8@hughes.id> Good morning everyone, AusNOG 2024 will be held in Sydney on 5 & 6 September at the Fullerton Hotel. I'm pleased to announce that registration is now open. This will be the largest AusNOG conference we've ever held so grab yourself a ticket at the link below and join your peers for 2 days of excellent content and industry networking in September. I look forward to seeing you there. https://www.ausnog.net/events/ausnog-2024/registration Regards, David Hughes On behalf of the AusNOG Board -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at slampt.net Mon May 6 14:11:35 2024 From: joe at slampt.net (Joe) Date: Mon, 6 May 2024 12:11:35 +0800 Subject: [AusNOG] Adelaide catchup Message-ID: <961F2CD7-CECC-44ED-8930-94629F142E42@slampt.net> Hey AusNOG folks, I am heading over to Adelaide on the 14th May to do some upgrades on EdgeIX and have organised to catch up with a few Adelaide locals at The Cumby (https://thecumby.com.au/) on the Thursday, 15th May from 5pm. If you want to catch up for a beer or something to eat let me know, or just rock on up. Replies off list. Cheers Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at slampt.net Mon May 6 14:50:05 2024 From: joe at slampt.net (Joe) Date: Mon, 6 May 2024 12:50:05 +0800 Subject: [AusNOG] Adelaide catchup In-Reply-To: <961F2CD7-CECC-44ED-8930-94629F142E42@slampt.net> References: <961F2CD7-CECC-44ED-8930-94629F142E42@slampt.net> Message-ID: Correction - to clarify that is a Wednesday, not Thursday. My bad. (Thanks to those who spotted this.) :) Joe > On 6 May 2024, at 12:11?PM, Joe wrote: > > Hey AusNOG folks, > > I am heading over to Adelaide on the 14th May to do some upgrades on EdgeIX and have organised to catch up with a few Adelaide locals at The Cumby (https://thecumby.com.au/) on the Thursday, 15th May from 5pm. > > If you want to catch up for a beer or something to eat let me know, or just rock on up. > > Replies off list. > > Cheers > Joe > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From noel.butler at ausics.net Tue May 7 12:51:50 2024 From: noel.butler at ausics.net (Noel Butler) Date: Tue, 07 May 2024 12:51:50 +1000 Subject: [AusNOG] Netcomm wireless enters vol administration In-Reply-To: References: Message-ID: <16c3cc5fd7ec4a75c43b611ac7028214@ausics.net> https://www.smartcompany.com.au/finance/mergers-and-acquisitions/netcomm-wireless-acquisition-dzs-voluntary-administration/ _"A Texan broadband access company has rescued Australian telco equipment provider NetComm Wireless from administration, pledging US$7 million (AU$10.6 million) to obtain the 40-year-old venture."_ On 20/03/2024 21:18, Noel Butler wrote: > https://www.smartcompany.com.au/exclusive/netcomm-wireless-voluntary-administration/ > > Telecom equipment supplier NetComm Wireless has entered voluntary > administration after operating for over 40 years. > > Documents listed by the Australian Securities and Investments > Commission (ASIC) on March 13 show Kate Conneely and Rahul Goyal from > Cor Cordis have been appointed administrators of the company > > story continues in link > > -- > Regards, > Noel Butler > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -- Regards, Noel Butler -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.sweetser at apnic.net Wed May 8 15:13:44 2024 From: terry.sweetser at apnic.net (Terry Sweetser) Date: Wed, 8 May 2024 05:13:44 +0000 Subject: [AusNOG] munnari.oz.au Message-ID: So ... AusNOG, What is the status of that server for DNS and other "very old things from long" ago? ________________________________ Terry Sweetser Training Delivery Manager South Asia and Oceania e: terry.sweetser at apnic.net p: +61 7 3858 3100 www.apnic.net [cid:image001.png at 01DAA15A.4FFFE570] Book time with Terry Sweetser -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3665 bytes Desc: image001.png URL: From mmc at mmc.com.au Wed May 8 16:22:52 2024 From: mmc at mmc.com.au (Matthew Moyle-Croft) Date: Wed, 8 May 2024 15:52:52 +0930 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: Dunno but pretty wild it's now in Thailand. On Wed, 8 May 2024 at 14:44, Terry Sweetser wrote: > So ? AusNOG, > > > > What is the status of that server for DNS and other ?very old things from > long? ago? > > > ------------------------------ > > *Terry Sweetser* > Training Delivery Manager > South Asia and Oceania > e: terry.sweetser at apnic.net > p: +61 7 3858 3100 > www.apnic.net > > > > Book time with Terry Sweetser > > > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3665 bytes Desc: not available URL: From roddy at ibrox.org Wed May 8 16:23:39 2024 From: roddy at ibrox.org (Roddy Strachan) Date: Wed, 8 May 2024 16:23:39 +1000 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: <49CA2270-A4F4-42E5-836C-6E0432B02FD6@ibrox.org> Ahhhh memories :) > On 8 May 2024, at 16:22, Matthew Moyle-Croft wrote: > > Dunno but pretty wild it's now in Thailand. > > On Wed, 8 May 2024 at 14:44, Terry Sweetser > wrote: >> So ? AusNOG, >> >> >> >> What is the status of that server for DNS and other ?very old things from long? ago? >> >> >> >> Terry Sweetser >> Training Delivery Manager >> South Asia and Oceania >> e: terry.sweetser at apnic.net >> p: +61 7 3858 3100 >> www.apnic.net >> >> >> >> >> Book time with Terry Sweetser >> >> >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From terry.sweetser at apnic.net Wed May 8 16:45:36 2024 From: terry.sweetser at apnic.net (Terry Sweetser) Date: Wed, 8 May 2024 06:45:36 +0000 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: I have just found out Robert moved to a Southern Thai University and took the name with him ... TCS From: Matthew Moyle-Croft Sent: Wednesday, May 8, 2024 4:23 PM To: Terry Sweetser Cc: ausnog at lists.ausnog.net Subject: Re: [AusNOG] munnari.oz.au Dunno but pretty wild it's now in Thailand. On Wed, 8 May 2024 at 14:44, Terry Sweetser > wrote: So ... AusNOG, What is the status of that server for DNS and other "very old things from long" ago? ________________________________ Terry Sweetser Training Delivery Manager South Asia and Oceania e: terry.sweetser at apnic.net p: +61 7 3858 3100 www.apnic.net [cid:image001.png at 01DAA167.24EF0AC0] Book time with Terry Sweetser _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3665 bytes Desc: image001.png URL: From glenn.satchell at uniq.com.au Wed May 8 17:35:57 2024 From: glenn.satchell at uniq.com.au (glenn.satchell at uniq.com.au) Date: Wed, 08 May 2024 17:35:57 +1000 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: <66dd2b22758d23641847d5d546eab6d0@uniq.com.au> as you do :) so I saw the ssh port is open but no DNS and given the location probably no other old services either. regards, Glenn On 2024-05-08 16:45, Terry Sweetser wrote: > I have just found out Robert moved to a Southern Thai University and > took the name with him ? > > TCS > > From: Matthew Moyle-Croft > Sent: Wednesday, May 8, 2024 4:23 PM > To: Terry Sweetser > Cc: ausnog at lists.ausnog.net > Subject: Re: [AusNOG] munnari.oz.au > > Dunno but pretty wild it's now in Thailand. > > On Wed, 8 May 2024 at 14:44, Terry Sweetser > wrote: > >> So ? AusNOG, >> >> What is the status of that server for DNS and other "very old things >> from long" ago? >> >> ------------------------- >> >> Terry Sweetser >> Training Delivery Manager >> South Asia and Oceania >> e: terry.sweetser at apnic.net >> p: +61 7 3858 3100 >> www.apnic.net [1] >> >> Book time with Terry Sweetser [2] >> >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog Links: ------ [1] https://www.apnic.net/ [2] https://outlook.office.com/bookwithme/user/51c6c3e4cff6432ba38eae3bdd203753 at apnic.net?anonymous&ep=pcard -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3665 bytes Desc: not available URL: From jaedwards at gmail.com Wed May 8 17:36:50 2024 From: jaedwards at gmail.com (John Edwards) Date: Wed, 8 May 2024 17:06:50 +0930 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: From: dns at dns.god Newsgroups: aus.jokes Subject: The Holy DNS Commandments Date: 22 Aug 1995 06:13:04 GMT And behold, there were great thunder and lightnings, and the mighty prophet Gehofrey came down from the temple of Munnari and told Children of AU that the Lord God Kre had vouchedsafe unto them these Holy Commandments, graven upon stone tablets:- 1. Thou SHALT NOT send DNS information to the Lord God Kre's personal mailbox, lest the Wrath of the Lord Kre be kindled and wax hot against thee. 2. Thou shalt format thy request in a mysterious format known unto none save the holiest priesthood of the order of DNS, that thy days may be long in the domain that the Lord Kre hath given thee. 3. If thy requests be incorrectly seconded or ill formatted, thou shalt NOT be added to the root AU domain but shalt be forever cast out of the named boot into the outer darkness where there is great weeping and wailing and gnashing of teeth. 4. Thine entries must be DNS walkable, or naught shall be delegated. 5. Thou shalt wait in vain for a reply. Ever. 6. If the Lord deigneth to reply at all, it is because thou art incredibly stupid, dullwitted, blind and slow of understanding, and comprehendeth not such simple DNS concepts; therefore shall He quote thee large inscriptions of the Holy DNS Bible, so that thy mailbox runneth over. 7. If not large inscriptions of the Holy DNS Bible, then large inscriptions of the sacred RFC tomes. 8. Thou shalt not complain about the Lord's ineffable doings or Commandments in news; "My Ways are not your ways, neither are My Thoughts your thoughts" saith the Lord Kre, and He shall pour out the vials of His scorn upon thine head from on High in the sight of all the multitudes. On Wed, 8 May 2024 at 14:44, Terry Sweetser wrote: > So ? AusNOG, > > > > What is the status of that server for DNS and other ?very old things from > long? ago? > > > ------------------------------ > > *Terry Sweetser* > Training Delivery Manager > South Asia and Oceania > e: terry.sweetser at apnic.net > p: +61 7 3858 3100 > www.apnic.net > > > > Book time with Terry Sweetser > > > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 3665 bytes Desc: not available URL: From gih902 at gmail.com Wed May 8 18:07:00 2024 From: gih902 at gmail.com (Geoff Huston) Date: Wed, 8 May 2024 17:07:00 +0900 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: Truly, a classic post! Geoff > On 8 May 2024, at 4:36?PM, John Edwards wrote: > > > From: dns at dns.god > Newsgroups: aus.jokes > Subject: The Holy DNS Commandments > Date: 22 Aug 1995 06:13:04 GMT > > And behold, there were great thunder and lightnings, and the mighty prophet Gehofrey came down from the temple of Munnari and told Children of AU that the Lord God Kre had vouchedsafe unto them these Holy Commandments, graven upon stone tablets:- > > 1. Thou SHALT NOT send DNS information to the Lord God Kre's personal mailbox, lest the Wrath of the Lord Kre be kindled and wax hot against thee. > > 2. Thou shalt format thy request in a mysterious format known unto none save the holiest priesthood of the order of DNS, that thy days may be long in the domain that the Lord Kre hath given thee. > > 3. If thy requests be incorrectly seconded or ill formatted, thou shalt NOT be added to the root AU domain but shalt be forever cast out of the named boot into the outer darkness where there is great weeping and wailing and gnashing of teeth. > > 4. Thine entries must be DNS walkable, or naught shall be delegated. > > 5. Thou shalt wait in vain for a reply. Ever. > > 6. If the Lord deigneth to reply at all, it is because thou art incredibly stupid, dullwitted, blind and slow of understanding, and comprehendeth not such simple DNS concepts; therefore shall He quote thee large inscriptions of the Holy DNS Bible, so that thy mailbox runneth over. > > 7. If not large inscriptions of the Holy DNS Bible, then large inscriptions of the sacred RFC tomes. > > 8. Thou shalt not complain about the Lord's ineffable doings or Commandments in news; "My Ways are not your ways, neither are My Thoughts your thoughts" saith the Lord Kre, and He shall pour out the vials of His scorn upon thine head from on High in the sight of all the multitudes. > From markzzzsmith at gmail.com Wed May 8 18:19:04 2024 From: markzzzsmith at gmail.com (Mark Smith) Date: Wed, 8 May 2024 18:19:04 +1000 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: On Wed, 8 May 2024 at 15:14, Terry Sweetser wrote: > > So ? AusNOG, > > > > What is the status of that server for DNS and other ?very old things from long? ago? Details of what it was originally used for are in the "AARNet - 20 Years of the Internet in Australia" book at the following link. Quite a number of familiar faces and names. Also some good introductory history of the development of packet switching networks and the ARPANET/Internet itself. https://www.aarnet.edu.au/history > > > > ________________________________ > > Terry Sweetser > Training Delivery Manager > South Asia and Oceania > e: terry.sweetser at apnic.net > p: +61 7 3858 3100 > www.apnic.net > > > > Book time with Terry Sweetser > > > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog From spoofer-info at caida.org Thu May 9 03:00:26 2024 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Wed, 8 May 2024 10:00:26 -0700 Subject: [AusNOG] Spoofer Report for AusNOG for Apr 2024 Message-ID: <1715187626.419300.31170.nullmailer@caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within aus. Inferred improvements during Apr 2024: ASN Name Fixed-By 132458 PENTANET 2024-04-15 Further information for the inferred remediation is available at: https://spoofer.caida.org/remedy.php Source Address Validation issues inferred during Apr 2024: ASN Name First-Spoofed Last-Spoofed 138311 LIMERICK 2020-02-26 2024-04-22 151133 2024-04-12 2024-04-28 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=aus&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From elliott at willink.net.au Thu May 9 19:34:26 2024 From: elliott at willink.net.au (Elliott Willink) Date: Thu, 9 May 2024 09:34:26 +0000 Subject: [AusNOG] Contact at GTT for a routing issue Message-ID: Sorry for the noise - possibly a long shot but does anyone have a contact at GTT who may be able to assist resolve routing issues with US traffic? NOC emails get a generic replying saying they are investigating on loop, NOC phone number seems to be disconnected and their general phone number won't do anything without a service ID. Cheers, Elliott -------------- next part -------------- An HTML attachment was scrubbed... URL: From markzzzsmith at gmail.com Fri May 10 02:41:57 2024 From: markzzzsmith at gmail.com (Mark Smith) Date: Fri, 10 May 2024 02:41:57 +1000 Subject: [AusNOG] Contact at GTT for a routing issue In-Reply-To: References: Message-ID: You might be better off contacting the party who bought GTT, because in my relatively limited experience, GTT haven't existed for something like 10 to 15 years (i.e., how long I haven't heard "GTT" mentioned at all ????) On Thu, 9 May 2024, 19:34 Elliott Willink, wrote: > Sorry for the noise - possibly a long shot but does anyone have a contact > at GTT who may be able to assist resolve routing issues with US traffic? > > NOC emails get a generic replying saying they are investigating on loop, > NOC phone number seems to be disconnected and their general phone number > won't do anything without a service ID. > > Cheers, > > Elliott > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltd at interlink.com.au Fri May 10 07:55:56 2024 From: ltd at interlink.com.au (Lincoln Dale) Date: Fri, 10 May 2024 07:55:56 +1000 Subject: [AusNOG] Contact at GTT for a routing issue In-Reply-To: References: Message-ID: On Thu, May 9, 2024 at 7:35?PM Elliott Willink wrote: > Sorry for the noise - possibly a long shot but does anyone have a contact > at GTT who may be able to assist resolve routing issues with US traffic? > > NOC emails get a generic replying saying they are investigating on loop, > NOC phone number seems to be disconnected and their general phone number > won't do anything without a service ID. > How about you post the prefix in question that you see looping and then others can maybe look deeper into it. Did you also check to see that its legitimate in various looking glasses and e.g. do you see the same in ripe probes or similar? There are definitely cases where loops can/do happen beyond being transient. Router software bugs ("stuck bgp routes" / "timing race conditions on programming hardware") can/do/have happened, but are less common these days. But if its your prefix that you control, you can probably resolve it either by withdraw/re-announce of it, changing a transitive attribute that forces a refresh of it, possibly doing so via announcing either a more-specific or less-specific to backstop it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elliott at willink.net.au Fri May 10 08:45:14 2024 From: elliott at willink.net.au (Elliott Willink) Date: Thu, 9 May 2024 22:45:14 +0000 Subject: [AusNOG] Contact at GTT for a routing issue In-Reply-To: References: Message-ID: Thanks everyone who responded, this is now sorted. Special thanks to James @ Micron21 who managed to work some magic for us and get this resolved. ________________________________ From: Lincoln Dale Sent: Friday, May 10, 2024 7:55 AM To: Elliott Willink Cc: AusNOG at lists.ausnog.net Subject: Re: [AusNOG] Contact at GTT for a routing issue On Thu, May 9, 2024 at 7:35?PM Elliott Willink > wrote: Sorry for the noise - possibly a long shot but does anyone have a contact at GTT who may be able to assist resolve routing issues with US traffic? NOC emails get a generic replying saying they are investigating on loop, NOC phone number seems to be disconnected and their general phone number won't do anything without a service ID. How about you post the prefix in question that you see looping and then others can maybe look deeper into it. Did you also check to see that its legitimate in various looking glasses and e.g. do you see the same in ripe probes or similar? There are definitely cases where loops can/do happen beyond being transient. Router software bugs ("stuck bgp routes" / "timing race conditions on programming hardware") can/do/have happened, but are less common these days. But if its your prefix that you control, you can probably resolve it either by withdraw/re-announce of it, changing a transitive attribute that forces a refresh of it, possibly doing so via announcing either a more-specific or less-specific to backstop it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.braunegg at micron21.com Fri May 10 11:13:46 2024 From: james.braunegg at micron21.com (James Braunegg) Date: Fri, 10 May 2024 01:13:46 +0000 Subject: [AusNOG] Contact at GTT for a routing issue In-Reply-To: References: Message-ID: <004ae11939b5450abcc616a278831601@micron21.com> Dear Elliott It is always my pleasure to help out fellow Australian Network Owners where I can?. Plus it helps knowing the right people to ask the right question to get things fixed? Kindest Regards James Braunegg [cid:image001.png at 01DAA2CB.1F52C5B0] 1300 769 972 / 0488 997 207 james.braunegg at micron21.com www.micron21.com/virtual-datacentre-tour [cid:image002.png at 01DAA2CB.1F52C5B0] [cid:image003.png at 01DAA2CB.1F52C5B0] [cid:image004.png at 01DAA2CB.1F52C5B0] Follow us on m21status.com for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer. From: AusNOG On Behalf Of Elliott Willink Sent: Friday, 10 May 2024 8:45 AM To: Lincoln Dale Cc: AusNOG at lists.ausnog.net Subject: Re: [AusNOG] Contact at GTT for a routing issue Thanks everyone who responded, this is now sorted. Special thanks to James @ Micron21 who managed to work some magic for us and get this resolved. ________________________________ From: Lincoln Dale > Sent: Friday, May 10, 2024 7:55 AM To: Elliott Willink > Cc: AusNOG at lists.ausnog.net > Subject: Re: [AusNOG] Contact at GTT for a routing issue On Thu, May 9, 2024 at 7:35?PM Elliott Willink > wrote: Sorry for the noise - possibly a long shot but does anyone have a contact at GTT who may be able to assist resolve routing issues with US traffic? NOC emails get a generic replying saying they are investigating on loop, NOC phone number seems to be disconnected and their general phone number won't do anything without a service ID. How about you post the prefix in question that you see looping and then others can maybe look deeper into it. Did you also check to see that its legitimate in various looking glasses and e.g. do you see the same in ripe probes or similar? There are definitely cases where loops can/do happen beyond being transient. Router software bugs ("stuck bgp routes" / "timing race conditions on programming hardware") can/do/have happened, but are less common these days. But if its your prefix that you control, you can probably resolve it either by withdraw/re-announce of it, changing a transitive attribute that forces a refresh of it, possibly doing so via announcing either a more-specific or less-specific to backstop it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 1047 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 4219 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1137 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 1246 bytes Desc: image004.png URL: From narellec at gmail.com Mon May 13 17:02:39 2024 From: narellec at gmail.com (Narelle Clark) Date: Mon, 13 May 2024 17:02:39 +1000 Subject: [AusNOG] munnari.oz.au In-Reply-To: References: Message-ID: On Wed, 8 May 2024 at 18:19, Mark Smith wrote: > On Wed, 8 May 2024 at 15:14, Terry Sweetser wrote: > > > > So ? AusNOG, > > > > What is the status of that server for DNS and other ?very old things from long? ago? > > Details of what it was originally used for are in the "AARNet - 20 > Years of the Internet in Australia" book at the following link. Quite > a number of familiar faces and names. Also some good introductory > history of the development of packet switching networks and the > ARPANET/Internet itself. > > https://www.aarnet.edu.au/history Including a picture that has me with a babe in arms. If anyone has a copy of the "outage notice" I posted to the ops mailing list of that era on his birth, I would appreciate a copy as it disappeared in the great disk crash of 2003... yes, he's somewhat older now, but that notice is my claim to the then 'internet birth notice record'. [apologies for the slightly off topic post] -- Narelle narellec at gmail.com From matt.keen at opsys.com.au Tue May 14 14:42:58 2024 From: matt.keen at opsys.com.au (Matt Keen | OpSys) Date: Tue, 14 May 2024 04:42:58 +0000 Subject: [AusNOG] Adelaide catchup In-Reply-To: References: <961F2CD7-CECC-44ED-8930-94629F142E42@slampt.net> Message-ID: SEC-Private This got caught in my filters so may have for others as well, so just looping it around as this is on tomorrow for those who would like to head out. Matt Keen From: AusNOG On Behalf Of Joe Sent: Monday, May 6, 2024 2:20 PM To: ausnog at lists.ausnog.net Subject: Re: [AusNOG] Adelaide catchup You don't often get email from joe at slampt.net. Learn why this is important Correction - to clarify that is a Wednesday, not Thursday. My bad. (Thanks to those who spotted this.) :) Joe On 6 May 2024, at 12:11?PM, Joe > wrote: Hey AusNOG folks, I am heading over to Adelaide on the 14th May to do some upgrades on EdgeIX and have organised to catch up with a few Adelaide locals at The Cumby (https://thecumby.com.au/) on the Thursday, 15th May from 5pm. If you want to catch up for a beer or something to eat let me know, or just rock on up. Replies off list. Cheers Joe _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From jocelyn at ausnog.net Tue May 14 14:44:17 2024 From: jocelyn at ausnog.net (Jocelyn Bateman) Date: Tue, 14 May 2024 14:44:17 +1000 Subject: [AusNOG] AusNOG 2024 registration is open In-Reply-To: <32C80E7F-682C-4F33-B891-326D4E75B8E8@hughes.id> References: <32C80E7F-682C-4F33-B891-326D4E75B8E8@hughes.id> Message-ID: Hi Everyone, We are closing the Call For Papers on May 30th. The CPF website only requires you submit your topic's title and summary, and not the full paper yet. So go ahead and submit your ideas! https://www.ausnog.net/events/ausnog-2024/cfp Here's a list of topic ideas we are actively seeking: Optical Satellite Data Centre (Facilities) Operations Network Architecture Routing Security (specific to Networking) DC Network Applications Protocols/Standards Policy/Industry CDN's *And don't forget to buy your ticket before they sell out, like they do every year!* Kind Regards, Program Chair Australian Network Operators Group (AusNOG) On Mon, May 6, 2024 at 11:43?AM wrote: > Good morning everyone, > > AusNOG 2024 will be held in Sydney on 5 & 6 September at the Fullerton > Hotel. I'm pleased to announce that registration is now open. This will > be the largest AusNOG conference we've ever held so grab yourself a ticket > at the link below and join your peers for 2 days of excellent content and > industry networking in September. I look forward to seeing you there. > > https://www.ausnog.net/events/ausnog-2024/registration > > > Regards, > > *David Hughes* > On behalf of the AusNOG Board > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From misterpink at gmail.com Tue May 14 16:23:06 2024 From: misterpink at gmail.com (Mister Pink) Date: Tue, 14 May 2024 16:23:06 +1000 Subject: [AusNOG] AusNOG 2024 registration is open In-Reply-To: References: <32C80E7F-682C-4F33-B891-326D4E75B8E8@hughes.id> Message-ID: On this topic I have been ruminating on a paper about SMS spam and how much of it we encounter in Australia, Specifically if there is more we can as an industry to reduce it. I'm conscious that there have been a lot of promises made about it's reduction recently, but I also seem to be on the receiving end of a hell of a lot of it! So I'm genuinely fascinated by why it's seemingly so hard to combat? The talk I envisage would delve in to: - What it looks like from a criminal's perspective - What it looks like from a telco perspective - How if at all is Australia different to other countries - What can be done to combat it and from where - What has been done so far, and what has been the impact of that - What is the regulatory landscape for this and is it a help or a hinderance For me to put a talk like that together, I will need to find some people willing to speak to me on or off the record about any of the above topics that they can share insight on.. If you think this would be a worthwhile talk, and you have any interesting insight, or stories to share, even anonymously please drop me a line, and if I think I have enough to build a talk I may even pull Noah out of retirement! Thanks in advance Pinky! On Tue, 14 May 2024 at 14:44, Jocelyn Bateman wrote: > > Hi Everyone, > > We are closing the Call For Papers on May 30th. > > The CPF website only requires you submit your topic's title and summary, > and not the full paper yet. So go ahead and submit your ideas! > https://www.ausnog.net/events/ausnog-2024/cfp > > Here's a list of topic ideas we are actively seeking: > > Optical > Satellite > Data Centre (Facilities) > Operations > Network Architecture > Routing > Security (specific to Networking) > DC Network > Applications > Protocols/Standards > Policy/Industry > CDN's > > > *And don't forget to buy your ticket before they sell out, like they do > every year!* > > > Kind Regards, > > Program Chair > > Australian Network Operators Group (AusNOG) > > > On Mon, May 6, 2024 at 11:43?AM wrote: > >> Good morning everyone, >> >> AusNOG 2024 will be held in Sydney on 5 & 6 September at the Fullerton >> Hotel. I'm pleased to announce that registration is now open. This will >> be the largest AusNOG conference we've ever held so grab yourself a ticket >> at the link below and join your peers for 2 days of excellent content and >> industry networking in September. I look forward to seeing you there. >> >> https://www.ausnog.net/events/ausnog-2024/registration >> >> >> Regards, >> >> *David Hughes* >> On behalf of the AusNOG Board >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog >> > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at leschnik.me Mon May 20 11:11:37 2024 From: jason at leschnik.me (Jason Leschnik) Date: Mon, 20 May 2024 11:11:37 +1000 Subject: [AusNOG] Understanding the WHS responsibilities when served a LAAN by a Telco In-Reply-To: References: Message-ID: Hi all, NB: This is not a request for legal advice. This a hypothetical situation where a Team (Network Communications Group) and more indirectly a Maintenance Group are served LAANs by Telcos. This group operates Public infrastructure (say Hospital sites). For the Network group, The LAANs are generally served for new circuits that have been requested, for the Maintenance group, they are for establishing or accessing Services on Tower Blocks (Mobile Antenna). Currently, said business has an Internal Contractor Management System operated by an External Vendor (Championed by an Asset Management and WHS group), this requires the Telcos to enroll and pay a yearly account fee (say $600). One could imagine that the Telcos would push back against this, being well within their rights to refuse a "fee to enter". I have a concern/question that I'm struggling to get clear answers to based on this hypothetical situation: If they refuse to enroll in the SYSTEM (Possibly invoking their Powers to access the site via. the correct channels) or possibly it's agreed they do not need to enter into the SYSTEM and the LAAN is accepted (based on reviewing of their SWMS and Liability Insurances) by a site owner. Is the onus on the site owner to manage/own the WHS risks while they are operating onsite? Or does that fall under the Telco? Regards, Jason. -- Personal Email Account -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitchkelly24 at gmail.com Mon May 20 11:43:52 2024 From: mitchkelly24 at gmail.com (Mitch Kelly) Date: Mon, 20 May 2024 09:43:52 +0800 Subject: [AusNOG] Understanding the WHS responsibilities when served a LAAN by a Telco In-Reply-To: References: Message-ID: Hi, Note: *None of the following should be taken as legal advice* This is a real world scenario from Mid 2018. Ive dealt with a similar issue on an LIN (Low Impact Notice) being served on a rural property owner. The issue arose when the owner refused entry to the Telco and did not negotiate (Not the right thing to do) The best thing we found (From Legal Advice) Was to advise YES, You can install your equipment on this property, The Fee Per Month will be 200k. You haven't Refused entry and, You've provided a compensation amount for the installation/inconvenience on the property. On the topic of the LIN and Safety, Due to the location of the installation, There was overhead HV Lines (12m), (6.4m clearance generally required) across the entryway to the property, The owner of the property had a duty of care to advise to the best of their knowledge hazards that may exist (Loose ground, sinkholes, unstable ground, overhead wires, etc) to the Telco entering the property of the LIN The Telco was responsible for their own SWIMS/JHA and complying with WHS laws, The Property owner distanced himself from any liability (He had a pretty good lawyer) The Property owner gave all the information to the telco to the best of his knowledge, Yet they still managed to knock down a power pole and pole pig (transformer) causing the OWNER of the property to have to pay Horizon power to fix it along with Horizon stating that further damage may be brought upon the owner if other customers were impacted (The lawyer got onto this pretty quick smart) The tower eventually fell over in Mid 2021 due to salinity issues in the soil, The Telco went insolvent in late 2022. The owner never saw a cent from the Telco for damages to the power infrastructure and likely never will. Stay well clear, Seek legal advice. If they have issued a LIN then they are probably already disgruntled. On Mon, May 20, 2024 at 9:12?AM Jason Leschnik wrote: > Hi all, > > NB: This is not a request for legal advice. > > This a hypothetical situation where a Team (Network Communications Group) > and more indirectly a Maintenance Group are served LAANs by Telcos. This > group operates Public infrastructure (say Hospital sites). For the Network > group, The LAANs are generally served for new circuits that have been > requested, for the Maintenance group, they are for establishing or > accessing Services on Tower Blocks (Mobile Antenna). > > Currently, said business has an Internal Contractor Management System > operated by an External Vendor (Championed by an Asset Management and WHS > group), this requires the Telcos to enroll and pay a yearly account fee > (say $600). One could imagine that the Telcos would push back against this, > being well within their rights to refuse a "fee to enter". > > I have a concern/question that I'm struggling to get clear answers to > based on this hypothetical situation: If they refuse to enroll in the > SYSTEM (Possibly invoking their Powers to access the site via. the correct > channels) or possibly it's agreed they do not need to enter into the SYSTEM > and the LAAN is accepted (based on reviewing of their SWMS and Liability > Insurances) by a site owner. Is the onus on the site owner to manage/own > the WHS risks while they are operating onsite? Or does that fall under the > Telco? > > Regards, > Jason. > -- > Personal Email Account > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at nickbrown.id.au Mon May 20 12:28:16 2024 From: nick at nickbrown.id.au (=?UTF-8?Q?Nick_Brown?=) Date: Mon, 20 May 2024 02:28:16 +0000 Subject: [AusNOG] Understanding the WHS responsibilities when served a LAAN by a Telco In-Reply-To: References: Message-ID: <0101018f93d40553-090e7cb7-8916-4413-b91c-45ff6c2c51bd-000000@us-west-2.amazonses.com> Even if the relationship between the carrier & the land or site owner is amicable, the carrier should still be issuing a LAAN as part of their pack in every instance. In fact, a LAAN (or the Act) facilitates recourse for damage caused by the carrier. I appreciate though that only works if the carrier isn?t broke.? Further, a freestanding tower of substance is unlikely to be considered a low impact facility if challenged.? To the OP, everyone knows if you?ve prepared a SWMS, listed your controls, and the receiving party ticks their compliance box without even reading it, it?s impossible for there to be a WHS issue! /s I?d suggest an approach of if it were a customer site charge any induction platform or contractor management fees back to the customer (perhaps indirectly), though I appreciate this is easier when building high value services. If installing network infra onto a site, cop the fees.? While site contacts should be relied on to inform of site specific hazards, the onus is on the carrier to identify and implement controls for risks, and that even if there is an opportunity for recourse the onus is on the carrier the to work safely. They want their team to make it home at the end of the day, appointing responsibility or fault should secondary. I am sure Workcover would agree.? Plus you know, public liability insurance!? *My views are personal, but based on experience in fibre & microwave construction.? Nick. On 20 May 2024, at 11:43 am, Mitch Kelly wrote: Hi, Note: None of the following should be taken as legal advice This is a real world scenario from Mid 2018. Ive dealt with a similar issue on an LIN (Low Impact Notice) being served on a rural property owner. The issue arose when the owner refused entry to the Telco and did not negotiate?(Not the right thing to do) The best thing we found (From Legal Advice) Was to advise YES, You can install your equipment on this property, The Fee Per Month will be 200k.? You haven't Refused entry and, You've provided a compensation amount for the installation/inconvenience on the property. On the topic of the LIN and Safety, Due to the location of the installation, There was overhead?HV Lines (12m), (6.4m clearance generally required) across the entryway?to the property, The owner of the property had a duty of care to advise to the best of their knowledge hazards that may exist (Loose ground, sinkholes, unstable ground, overhead wires, etc) to the Telco entering the property of the LIN The Telco was responsible for their own SWIMS/JHA and complying with WHS laws, The Property owner distanced himself from any liability (He had a pretty good lawyer) The Property owner gave all the information to the telco to the best of his knowledge, Yet they still managed to knock down a power pole and pole pig (transformer) causing the OWNER of the property to have to pay Horizon power to fix it along with Horizon stating that further damage may be brought upon the owner if other customers were impacted (The lawyer got onto this pretty quick smart) The tower eventually fell over in Mid 2021 due to salinity issues in the soil, The Telco went insolvent in late 2022. The owner never saw a cent from the Telco for damages to the power infrastructure and likely never will. Stay well clear, Seek legal advice. If they have issued a LIN then they are probably already disgruntled. On Mon, May 20, 2024 at 9:12?AM Jason Leschnik > wrote: Hi all, NB: This is not a request for legal advice. This a hypothetical?situation where a Team (Network Communications Group) and more indirectly a Maintenance Group are served LAANs by Telcos. This group operates Public infrastructure?(say Hospital sites). For the Network group, The LAANs are generally served for new circuits that have been requested, for the Maintenance group, they are for establishing or accessing Services on Tower Blocks (Mobile Antenna). Currently, said business has an Internal Contractor Management System operated by an External Vendor (Championed by an Asset Management and WHS group), this requires the Telcos to enroll and pay a yearly account fee (say $600). One could imagine that the Telcos would push back?against this, being well within their rights to refuse a "fee to enter". I have a concern/question that I'm struggling to get clear answers to based on this hypothetical situation:?If they refuse to enroll in the SYSTEM (Possibly invoking their Powers to access the site via. the correct channels) or possibly it's agreed they do not need to enter into the SYSTEM and the LAAN is accepted (based on reviewing of their SWMS and Liability Insurances) by a site owner. Is the onus on the site owner to manage/own the WHS risks while they are operating onsite? Or does that fall under the Telco? Regards, Jason. -- Personal Email Account _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net https://lists.ausnog.net/mailman/listinfo/ausnog _______________________________________________ AusNOG mailing list AusNOG at lists.ausnog.net https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaedwards at gmail.com Mon May 20 16:30:19 2024 From: jaedwards at gmail.com (John Edwards) Date: Mon, 20 May 2024 16:00:19 +0930 Subject: [AusNOG] Understanding the WHS responsibilities when served a LAAN by a Telco In-Reply-To: References: Message-ID: I have seen a few variations of this theme, and here's a couple of ways it has been worked out, but they still require a lawyer to draft something: - The site has various risks associated with it, so the Telco must use an approved contractor - then have that contractor pay the fee and be part of the WHS - The Telco agrees to indemnify the site for any liability incurred while on the premises (this tends to force a re-evaluation of any other suggested fees) Generally the cost of enforcing a LAAN in the courts is going to make any fees seem trivial, so it may be best to offer a path of less resistance rather than saying "No". John On Mon, 20 May 2024 at 11:14, Mitch Kelly wrote: > Hi, > > Note: *None of the following should be taken as legal advice* This is a > real world scenario from Mid 2018. > > Ive dealt with a similar issue on an LIN (Low Impact Notice) being served > on a rural property owner. The issue arose when the owner refused entry to > the Telco and did not negotiate (Not the right thing to do) The best thing > we found (From Legal Advice) Was to advise YES, You can install your > equipment on this property, The Fee Per Month will be 200k. > > You haven't Refused entry > and, > You've provided a compensation amount for the installation/inconvenience > on the property. > > On the topic of the LIN and Safety, Due to the location of the > installation, There was overhead HV Lines (12m), (6.4m clearance generally > required) across the entryway to the property, The owner of the property > had a duty of care to advise to the best of their knowledge hazards that > may exist (Loose ground, sinkholes, unstable ground, overhead wires, etc) > to the Telco entering the property of the LIN The Telco was responsible for > their own SWIMS/JHA and complying with WHS laws, The Property owner > distanced himself from any liability (He had a pretty good lawyer) > > The Property owner gave all the information to the telco to the best of > his knowledge, Yet they still managed to knock down a power pole and pole > pig (transformer) causing the OWNER of the property to have to pay Horizon > power to fix it along with Horizon stating that further damage may be > brought upon the owner if other customers were impacted (The lawyer got > onto this pretty quick smart) > > The tower eventually fell over in Mid 2021 due to salinity issues in the > soil, The Telco went insolvent in late 2022. > The owner never saw a cent from the Telco for damages to the power > infrastructure and likely never will. > > Stay well clear, Seek legal advice. If they have issued a LIN then they > are probably already disgruntled. > > > On Mon, May 20, 2024 at 9:12?AM Jason Leschnik wrote: > >> Hi all, >> >> NB: This is not a request for legal advice. >> >> This a hypothetical situation where a Team (Network Communications Group) >> and more indirectly a Maintenance Group are served LAANs by Telcos. This >> group operates Public infrastructure (say Hospital sites). For the Network >> group, The LAANs are generally served for new circuits that have been >> requested, for the Maintenance group, they are for establishing or >> accessing Services on Tower Blocks (Mobile Antenna). >> >> Currently, said business has an Internal Contractor Management System >> operated by an External Vendor (Championed by an Asset Management and WHS >> group), this requires the Telcos to enroll and pay a yearly account fee >> (say $600). One could imagine that the Telcos would push back against this, >> being well within their rights to refuse a "fee to enter". >> >> I have a concern/question that I'm struggling to get clear answers to >> based on this hypothetical situation: If they refuse to enroll in the >> SYSTEM (Possibly invoking their Powers to access the site via. the correct >> channels) or possibly it's agreed they do not need to enter into the SYSTEM >> and the LAAN is accepted (based on reviewing of their SWMS and Liability >> Insurances) by a site owner. Is the onus on the site owner to manage/own >> the WHS risks while they are operating onsite? Or does that fall under the >> Telco? >> >> Regards, >> Jason. >> -- >> Personal Email Account >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog >> > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at leschnik.me Tue May 21 19:38:28 2024 From: jason at leschnik.me (Jason Leschnik) Date: Tue, 21 May 2024 19:38:28 +1000 Subject: [AusNOG] Understanding the WHS responsibilities when served a LAAN by a Telco In-Reply-To: References: Message-ID: I appreciate all the replies (both Public and Private). This has given me plenty to consider! On Mon, 20 May 2024 at 16:30, John Edwards wrote: > > I have seen a few variations of this theme, and here's a couple of ways it has been worked out, but they still require a lawyer to draft something: > > - The site has various risks associated with it, so the Telco must use an approved contractor - then have that contractor pay the fee and be part of the WHS > > - The Telco agrees to indemnify the site for any liability incurred while on the premises (this tends to force a re-evaluation of any other suggested fees) > > Generally the cost of enforcing a LAAN in the courts is going to make any fees seem trivial, so it may be best to offer a path of less resistance rather than saying "No". > > John > > > On Mon, 20 May 2024 at 11:14, Mitch Kelly wrote: >> >> Hi, >> >> Note: None of the following should be taken as legal advice This is a real world scenario from Mid 2018. >> >> Ive dealt with a similar issue on an LIN (Low Impact Notice) being served on a rural property owner. The issue arose when the owner refused entry to the Telco and did not negotiate (Not the right thing to do) The best thing we found (From Legal Advice) Was to advise YES, You can install your equipment on this property, The Fee Per Month will be 200k. >> >> You haven't Refused entry >> and, >> You've provided a compensation amount for the installation/inconvenience on the property. >> >> On the topic of the LIN and Safety, Due to the location of the installation, There was overhead HV Lines (12m), (6.4m clearance generally required) across the entryway to the property, The owner of the property had a duty of care to advise to the best of their knowledge hazards that may exist (Loose ground, sinkholes, unstable ground, overhead wires, etc) to the Telco entering the property of the LIN The Telco was responsible for their own SWIMS/JHA and complying with WHS laws, The Property owner distanced himself from any liability (He had a pretty good lawyer) >> >> The Property owner gave all the information to the telco to the best of his knowledge, Yet they still managed to knock down a power pole and pole pig (transformer) causing the OWNER of the property to have to pay Horizon power to fix it along with Horizon stating that further damage may be brought upon the owner if other customers were impacted (The lawyer got onto this pretty quick smart) >> >> The tower eventually fell over in Mid 2021 due to salinity issues in the soil, The Telco went insolvent in late 2022. >> The owner never saw a cent from the Telco for damages to the power infrastructure and likely never will. >> >> Stay well clear, Seek legal advice. If they have issued a LIN then they are probably already disgruntled. >> >> >> On Mon, May 20, 2024 at 9:12?AM Jason Leschnik wrote: >>> >>> Hi all, >>> >>> NB: This is not a request for legal advice. >>> >>> This a hypothetical situation where a Team (Network Communications Group) and more indirectly a Maintenance Group are served LAANs by Telcos. This group operates Public infrastructure (say Hospital sites). For the Network group, The LAANs are generally served for new circuits that have been requested, for the Maintenance group, they are for establishing or accessing Services on Tower Blocks (Mobile Antenna). >>> >>> Currently, said business has an Internal Contractor Management System operated by an External Vendor (Championed by an Asset Management and WHS group), this requires the Telcos to enroll and pay a yearly account fee (say $600). One could imagine that the Telcos would push back against this, being well within their rights to refuse a "fee to enter". >>> >>> I have a concern/question that I'm struggling to get clear answers to based on this hypothetical situation: If they refuse to enroll in the SYSTEM (Possibly invoking their Powers to access the site via. the correct channels) or possibly it's agreed they do not need to enter into the SYSTEM and the LAAN is accepted (based on reviewing of their SWMS and Liability Insurances) by a site owner. Is the onus on the site owner to manage/own the WHS risks while they are operating onsite? Or does that fall under the Telco? >>> >>> Regards, >>> Jason. >>> -- >>> Personal Email Account >>> _______________________________________________ >>> AusNOG mailing list >>> AusNOG at lists.ausnog.net >>> https://lists.ausnog.net/mailman/listinfo/ausnog >> >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at hughes.id Wed May 22 15:33:53 2024 From: david at hughes.id (david at hughes.id) Date: Wed, 22 May 2024 15:33:53 +1000 Subject: [AusNOG] Accommodation at AusNOG 2024 Message-ID: <961F4482-8E53-46AA-A088-8A802FFCE2C5@hughes.id> Good afternoon everyone. We've added a link on the AusNOG web site for accessing the discounted accommodation rate at the Fullerton Sydney (the conference hotel). To access the discounted rate, please follow the link on the page below. Please ensure you grab your room early as the room block reduces in size as we get closer to the event (so AusNOG isn't left with a commitment for unused rooms). Last year some people left it late to book a room and were disappointed by a lack of availability. Your rooms can be booked via the link at : https://www.ausnog.net/events/ausnog-2024/accommodation Thanks David ... From joseph at goldman.id.au Thu May 23 15:46:53 2024 From: joseph at goldman.id.au (Joseph Goldman) Date: Thu, 23 May 2024 05:46:53 +0000 Subject: [AusNOG] Experiences with RPKI Message-ID: G'day list, In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? All help appreciated :) Thanks, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.mawson at gmail.com Thu May 23 15:52:54 2024 From: phil.mawson at gmail.com (Phil Mawson) Date: Thu, 23 May 2024 15:52:54 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Hi Joe, First up, well done on working on your RPKI roll out. Signing your own routes is the most important step you can take to protect your own network. In regards to using max length, I do advise against that as what it means someone can still hijack one of your un-advertised routes and it would be treated as real. IE: If you advertise and sign a /19, but have a ROA created for each route up to a /24. If you are not advertising all of those, a third party could advertise one of our /24s and spoof your ASN and it would be treated as valid on the internet. APNIC portal make it very easy to create ROAs for your own routes as it has the route table view so it can see what is already publicly advertise. I recommend looking at that and then signing routes based on that. DDoS mitigation providers and ROAs is an interesting topic and not sure the community can agree on what is the best technical solution for that. Regards, Phil > On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: > > G'day list, > > In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. > > We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. > > Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? > > i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? > > My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. > > Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. > > Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? > > All help appreciated :) > > Thanks, > Joe > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From awal at psg.com Thu May 23 16:07:16 2024 From: awal at psg.com (Md Abdul Awal) Date: Thu, 23 May 2024 16:07:16 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: <72E38ADD-003E-4748-9CE8-2D79B2E55925@psg.com> Hi Joe, Great work on ROA and RPKI. Like you said, it is recommended to create ROAs for the prefixes that you advertise. In other words, create minimum number of ROAs to cover the exact prefixes that you advertise to avoid ?Validated Hijack?. > On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: > > i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? > > My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. In the given example, there will be no issue in terms of validation. The announcements are covered by the ROAs and are valid, so they will be accepted, doesn?t matter whether the ROA covers other prefixes or ranges that are not visible in the global routing table. Cheers, Abdul Awal -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at goldman.id.au Thu May 23 16:08:36 2024 From: joseph at goldman.id.au (Joseph Goldman) Date: Thu, 23 May 2024 06:08:36 +0000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Hi Phil, Thanks - I 100% understand the point of best practice of not using maxLength and the potential for hijacking, what im most worried about is the statement i've been told about 'unused' ROAs affecting used ROAs, which just seems counter-intuitive to me, in terms of (as per the example given) having ROAs ready for failover or TE purposes. This is the RFC im referring to: https://datatracker.ietf.org/doc/html/rfc9319 Specifically 5.1 which indicates having dormant ROAs available for use, but I am being told having any dormant ROAs is grounds for all routes to be marked invalid based on stricter validators, which is the answer im trying to ascertain right now. In a failover sense, say for example I am advertising /22 out of my Brisbane POP and some /24's out of my Sydney POP, my Sydney POP goes down and im no longer originating those /24's, by what i've been told my /22 would now become invalid on next check as my /24's are not being advertised, even though I have ROAs for the /22 and /24's. I believe i've been given somewhat wrong information but they were basing it off experiences with other APNIC members, I just dont want to end up in a position where our routes are dropped after implementing our ROAs, and maintain flexibility to not wait multiple hours before we can advertise a new prefix if required. Thanks, Joe ------ Original Message ------ From: "Phil Mawson" To: "Joseph Goldman" Cc: "ausnog at lists.ausnog.net" Sent: 23/05/2024 3:52:54 PM Subject: Re: [AusNOG] Experiences with RPKI >Hi Joe, > >First up, well done on working on your RPKI roll out. Signing your own >routes is the most important step you can take to protect your own >network. > >In regards to using max length, I do advise against that as what it >means someone can still hijack one of your un-advertised routes and it >would be treated as real. > >IE: If you advertise and sign a /19, but have a ROA created for each >route up to a /24. If you are not advertising all of those, a third >party could advertise one of our /24s and spoof your ASN and it would >be treated as valid on the internet. > >APNIC portal make it very easy to create ROAs for your own routes as it >has the route table view so it can see what is already publicly >advertise. I recommend looking at that and then signing routes based >on that. > >DDoS mitigation providers and ROAs is an interesting topic and not >sure the community can agree on what is the best technical solution for >that. > >Regards, >Phil > > >>On 23 May 2024, at 3:46?PM, Joseph Goldman >>wrote: >> >>G'day list, >> >> In the process of rolling out RPKI - and while I thought I had a good >>grasp on everything, there is one niggling piece of information that >>I've come against and can't verify. Was hoping people can share their >>experiences. >> >> We are only doing our ROA's to begin with and not implementing >>validation until later, the initial thought was to create an ROA for >>all our 'supernets' and use maxLength to 24 to help cover any prefix >>we may want to advertise. We are a much simpler setup, single AS only >>and we do advertise many of our ranges down to /24 but not all of >>them. I do know of the best practices of not using maxLength based on >>a draft rfc doc, but I am personally not super concerned for our >>relatively small use-case to the issues brought up in that doc. >> >> Where I have come into trouble is a source (APNIC helpdesk) >>indicating that if we have any ROAs that exist for prefixes we are not >>directly advertising - it may lend some validators to mark all our >>routes as invalid? >> >>i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently >>advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are >>'unused' in that we are not advertising those specific resources - >>would that cause issues with strict validators out in the wild? >> >> My understanding reading through the RFC's is this should not be the >>case. If any ROA that matches the prefix for the origin AS exists it >>should be valid, regardless of other ROAs signed by the same resource >>holder etc. >> >> Matching ROAs to exact advertisements is great, but it seems to lend >>itself to much less flexibility in traffic engineering and failover >>scenarios - a good scenario is having dormant /24 ROAs for say a DDoS >>mitigation service to use when needed, so you dont have to wait for >>RPKI propagation before scrubbing kicks in. >> >> Based on your experience, is having all-encompassing (using >>maxLength), or unused ROAs an acceptable way to use RPKI or will we >>run into issues? >> >>All help appreciated :) >> >>Thanks, >>Joe >>_______________________________________________ >>AusNOG mailing list >>AusNOG at lists.ausnog.net >>https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltd at interlink.com.au Thu May 23 16:18:00 2024 From: ltd at interlink.com.au (Lincoln Dale) Date: Thu, 23 May 2024 16:18:00 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: You can look up any entries. So maybe go look at what others do. For example, we do use maxlength 24 even on 3.0.0.0/10. https://rpki-validator.ripe.net/ui/3.0.0.0%2F10/16509 We do have automated things that will announce more specifics if there is a hijack, so we do want that in place. That may not be what everyone does, but is e.g. a counterpoint to how it can be done. On Thu, May 23, 2024 at 4:09?PM Joseph Goldman wrote: > Hi Phil, > > Thanks - I 100% understand the point of best practice of not using > maxLength and the potential for hijacking, what im most worried about is > the statement i've been told about 'unused' ROAs affecting used ROAs, which > just seems counter-intuitive to me, in terms of (as per the example given) > having ROAs ready for failover or TE purposes. > > This is the RFC im referring to: > > https://datatracker.ietf.org/doc/html/rfc9319 > > Specifically 5.1 which indicates having dormant ROAs available for use, > but I am being told having any dormant ROAs is grounds for all routes to be > marked invalid based on stricter validators, which is the answer im trying > to ascertain right now. > > In a failover sense, say for example I am advertising /22 out of my > Brisbane POP and some /24's out of my Sydney POP, my Sydney POP goes down > and im no longer originating those /24's, by what i've been told my /22 > would now become invalid on next check as my /24's are not being > advertised, even though I have ROAs for the /22 and /24's. > > I believe i've been given somewhat wrong information but they were basing > it off experiences with other APNIC members, I just dont want to end up in > a position where our routes are dropped after implementing our ROAs, and > maintain flexibility to not wait multiple hours before we can advertise a > new prefix if required. > > Thanks, > Joe > > ------ Original Message ------ > From: "Phil Mawson" > To: "Joseph Goldman" > Cc: "ausnog at lists.ausnog.net" > Sent: 23/05/2024 3:52:54 PM > Subject: Re: [AusNOG] Experiences with RPKI > > Hi Joe, > > First up, well done on working on your RPKI roll out. Signing your own > routes is the most important step you can take to protect your own network. > > In regards to using max length, I do advise against that as what it means > someone can still hijack one of your un-advertised routes and it would be > treated as real. > > IE: If you advertise and sign a /19, but have a ROA created for each route > up to a /24. If you are not advertising all of those, a third party could > advertise one of our /24s and spoof your ASN and it would be treated as > valid on the internet. > > APNIC portal make it very easy to create ROAs for your own routes as it > has the route table view so it can see what is already publicly advertise. > I recommend looking at that and then signing routes based on that. > > DDoS mitigation providers and ROAs is an interesting topic and not sure > the community can agree on what is the best technical solution for that. > > Regards, > Phil > > > On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: > > G'day list, > > In the process of rolling out RPKI - and while I thought I had a good > grasp on everything, there is one niggling piece of information that I've > come against and can't verify. Was hoping people can share their > experiences. > > We are only doing our ROA's to begin with and not implementing validation > until later, the initial thought was to create an ROA for all our > 'supernets' and use maxLength to 24 to help cover any prefix we may want to > advertise. We are a much simpler setup, single AS only and we do advertise > many of our ranges down to /24 but not all of them. I do know of the best > practices of not using maxLength based on a draft rfc doc, but I am > personally not super concerned for our relatively small use-case to the > issues brought up in that doc. > > Where I have come into trouble is a source (APNIC helpdesk) indicating > that if we have any ROAs that exist for prefixes we are not directly > advertising - it may lend some validators to mark *all *our routes as > invalid? > > i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently > advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' > in that we are not advertising those specific resources - would that cause > issues with strict validators out in the wild? > > My understanding reading through the RFC's is this should not be the > case. If any ROA that matches the prefix for the origin AS exists it should > be valid, regardless of other ROAs signed by the same resource holder etc. > > Matching ROAs to exact advertisements is great, but it seems to lend > itself to much less flexibility in traffic engineering and failover > scenarios - a good scenario is having dormant /24 ROAs for say a DDoS > mitigation service to use when needed, so you dont have to wait for RPKI > propagation before scrubbing kicks in. > > Based on your experience, is having all-encompassing (using maxLength), > or unused ROAs an acceptable way to use RPKI or will we run into issues? > > All help appreciated :) > > Thanks, > Joe > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > > > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gih902 at gmail.com Thu May 23 16:20:22 2024 From: gih902 at gmail.com (Geoff Huston) Date: Thu, 23 May 2024 16:20:22 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Hi Joe, Well you are alwayus going to run into issues! All of these tools introduce novel forms of failure! :-) In answer to you specific question, not advertising all of the prefixes for with you have ROAs will not cause any issuesa at all. When you create a ROA you, as the prefix holder, are proving an authority for the listed AS to origate that particular route. You are not making any attestation at all about any other prefixes that the AS is originating. A few other points: - DONT rely on the RPKI as a real time or near real time signalling method, such as a DDOS mitigation. You are relying on everyoine else performing suiper frequent checks on the state of the RPKI repositories, and while a lot of software use 2 - 10 m,inute timers there are still some tjhat operate at hourly frequency or longer. There is not standard for the polling interval. - advertising a shorter (or is that longer?) maxlength when you are not using it does make you more vulnerawble to more specific routing attacks. Don't forget the speed of standardaziation of AS Path protection makes continental draft look speedy, and the current draft, ASPA, tends to get very confgused between topology and connectivity which make the entire process far sillier and more complex than it need be. - in general the ROA / ROV drop tools as they exist today provide only weak resistance to determined attack. They are great tools to counter some forms of inadvertant route leaks, but without a far better form of topology protection they are little more than a veneer in terms defense against a capable adversary in a routing context. The problem is that they do represent one more task for you as a network operator and one more thing to go wrong (expired keys, badly formed ROAs, nbadly formed RPKI certificates, etc and while it might be fund to set things up initially manually yuou need to pay attention as to how you will automate the maintenance of all of this to ensure that the machinery will work smoothly when you will not be around to nurse it. good luck! regards, Geoff > On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: > > G'day list, > > In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. > > We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. > > Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? > > i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? > > My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. > > Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. > > Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? > > All help appreciated :) > > Thanks, > Joe > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog From gih902 at gmail.com Thu May 23 16:25:50 2024 From: gih902 at gmail.com (Geoff Huston) Date: Thu, 23 May 2024 16:25:50 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: I measured the responsiveness of the RPKI system in the transitions of good to bad and bad to good a few years ago. See https://www.potaroo.net/presentations/2020-06-24-rpki.pdf tldr; - invalid to valid takes about 5 minutes to propagate but valid to invalid takes around 30 minutes. Which as a DDOS mitigation tool is a pretty crap response! Geoff > On 23 May 2024, at 4:18?PM, Lincoln Dale wrote: > > You can look up any entries. So maybe go look at what others do. > > For example, we do use maxlength 24 even on 3.0.0.0/10. https://rpki-validator.ripe.net/ui/3.0.0.0%2F10/16509 > We do have automated things that will announce more specifics if there is a hijack, so we do want that in place. That may not be what everyone does, but is e.g. a counterpoint to how it can be done. > > > > On Thu, May 23, 2024 at 4:09?PM Joseph Goldman wrote: > Hi Phil, > > Thanks - I 100% understand the point of best practice of not using maxLength and the potential for hijacking, what im most worried about is the statement i've been told about 'unused' ROAs affecting used ROAs, which just seems counter-intuitive to me, in terms of (as per the example given) having ROAs ready for failover or TE purposes. > > This is the RFC im referring to: > > https://datatracker.ietf.org/doc/html/rfc9319 > > Specifically 5.1 which indicates having dormant ROAs available for use, but I am being told having any dormant ROAs is grounds for all routes to be marked invalid based on stricter validators, which is the answer im trying to ascertain right now. > > In a failover sense, say for example I am advertising /22 out of my Brisbane POP and some /24's out of my Sydney POP, my Sydney POP goes down and im no longer originating those /24's, by what i've been told my /22 would now become invalid on next check as my /24's are not being advertised, even though I have ROAs for the /22 and /24's. > > I believe i've been given somewhat wrong information but they were basing it off experiences with other APNIC members, I just dont want to end up in a position where our routes are dropped after implementing our ROAs, and maintain flexibility to not wait multiple hours before we can advertise a new prefix if required. > > Thanks, > Joe > > ------ Original Message ------ > From: "Phil Mawson" > To: "Joseph Goldman" > Cc: "ausnog at lists.ausnog.net" > Sent: 23/05/2024 3:52:54 PM > Subject: Re: [AusNOG] Experiences with RPKI > >> Hi Joe, >> >> First up, well done on working on your RPKI roll out. Signing your own routes is the most important step you can take to protect your own network. >> >> In regards to using max length, I do advise against that as what it means someone can still hijack one of your un-advertised routes and it would be treated as real. >> >> IE: If you advertise and sign a /19, but have a ROA created for each route up to a /24. If you are not advertising all of those, a third party could advertise one of our /24s and spoof your ASN and it would be treated as valid on the internet. >> >> APNIC portal make it very easy to create ROAs for your own routes as it has the route table view so it can see what is already publicly advertise. I recommend looking at that and then signing routes based on that. >> >> DDoS mitigation providers and ROAs is an interesting topic and not sure the community can agree on what is the best technical solution for that. >> >> Regards, >> Phil >> >> >>> On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: >>> >>> G'day list, >>> >>> In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. >>> >>> We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. >>> >>> Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? >>> >>> i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? >>> >>> My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. >>> >>> Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. >>> >>> Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? >>> >>> All help appreciated :) >>> >>> Thanks, >>> Joe >>> _______________________________________________ >>> AusNOG mailing list >>> AusNOG at lists.ausnog.net >>> https://lists.ausnog.net/mailman/listinfo/ausnog >> >> > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog From gih902 at gmail.com Thu May 23 16:27:17 2024 From: gih902 at gmail.com (Geoff Huston) Date: Thu, 23 May 2024 16:27:17 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: "I am being told having any dormant ROAs is grounds for all routes to be marked invalid based on stricter validators, which is the answer im trying to ascertain right now." They are not telling you the truth! Geoff > On 23 May 2024, at 4:08?PM, Joseph Goldman wrote: > > Hi Phil, > > Thanks - I 100% understand the point of best practice of not using maxLength and the potential for hijacking, what im most worried about is the statement i've been told about 'unused' ROAs affecting used ROAs, which just seems counter-intuitive to me, in terms of (as per the example given) having ROAs ready for failover or TE purposes. > > This is the RFC im referring to: > > https://datatracker.ietf.org/doc/html/rfc9319 > > Specifically 5.1 which indicates having dormant ROAs available for use, but I am being told having any dormant ROAs is grounds for all routes to be marked invalid based on stricter validators, which is the answer im trying to ascertain right now. > > In a failover sense, say for example I am advertising /22 out of my Brisbane POP and some /24's out of my Sydney POP, my Sydney POP goes down and im no longer originating those /24's, by what i've been told my /22 would now become invalid on next check as my /24's are not being advertised, even though I have ROAs for the /22 and /24's. > > I believe i've been given somewhat wrong information but they were basing it off experiences with other APNIC members, I just dont want to end up in a position where our routes are dropped after implementing our ROAs, and maintain flexibility to not wait multiple hours before we can advertise a new prefix if required. > > Thanks, > Joe > > ------ Original Message ------ > From: "Phil Mawson" > To: "Joseph Goldman" > Cc: "ausnog at lists.ausnog.net" > Sent: 23/05/2024 3:52:54 PM > Subject: Re: [AusNOG] Experiences with RPKI > >> Hi Joe, >> >> First up, well done on working on your RPKI roll out. Signing your own routes is the most important step you can take to protect your own network. >> >> In regards to using max length, I do advise against that as what it means someone can still hijack one of your un-advertised routes and it would be treated as real. >> >> IE: If you advertise and sign a /19, but have a ROA created for each route up to a /24. If you are not advertising all of those, a third party could advertise one of our /24s and spoof your ASN and it would be treated as valid on the internet. >> >> APNIC portal make it very easy to create ROAs for your own routes as it has the route table view so it can see what is already publicly advertise. I recommend looking at that and then signing routes based on that. >> >> DDoS mitigation providers and ROAs is an interesting topic and not sure the community can agree on what is the best technical solution for that. >> >> Regards, >> Phil >> >> >>> On 23 May 2024, at 3:46?PM, Joseph Goldman wrote: >>> >>> G'day list, >>> >>> In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. >>> >>> We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. >>> >>> Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? >>> >>> i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? >>> >>> My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. >>> >>> Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. >>> >>> Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? >>> >>> All help appreciated :) >>> >>> Thanks, >>> Joe >>> _______________________________________________ >>> AusNOG mailing list >>> AusNOG at lists.ausnog.net >>> https://lists.ausnog.net/mailman/listinfo/ausnog >> >> > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog From raphael.timothy at gmail.com Thu May 23 16:34:45 2024 From: raphael.timothy at gmail.com (Tim Raphael) Date: Thu, 23 May 2024 16:34:45 +1000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Hey Joe, I don?t believe this to be the case - there are many networks much larger than yours that use max-length as coverage extensively. 5.1 in RFC9319 is precisely the reason why these networks choose to do this - the propagation latency for ad-hoc records is too slow for effective DDoS mitigation. If your network is relatively small and you have infrequent route changes, I recommend creating minimal ROAs for exactly what you intend to announce. If that means creating a parent /22 ROA and child /24 ROAs (because you intend to advertise more specifics as well) then that?s the best approach. You?re limiting your exposure for hijacks on other prefix lengths but giving enough flexibility for your advertisements. Making ROA creation part of the ?new route advertisement? process should just become the norm. Larger networks with more frequent changes should, ideally, use automation to create ROAs on the fly - e.g. driven from Netbox - once the prefix is created, hit up your friendly RIR API to create the ROA. And finally, I don?t believe there is validation logic to invalidate perfectly valid routes - if a ROA exists for a /24 and that?s what you?re advertising, it will be considered valid. Creating ROAs for your existing advertisements is the absolute lowest risk thing you can do. Cheers, Tim > On 23 May 2024, at 16:08, Joseph Goldman wrote: > > Hi Phil, > > Thanks - I 100% understand the point of best practice of not using maxLength and the potential for hijacking, what im most worried about is the statement i've been told about 'unused' ROAs affecting used ROAs, which just seems counter-intuitive to me, in terms of (as per the example given) having ROAs ready for failover or TE purposes. > > This is the RFC im referring to: > > https://datatracker.ietf.org/doc/html/rfc9319 > > Specifically 5.1 which indicates having dormant ROAs available for use, but I am being told having any dormant ROAs is grounds for all routes to be marked invalid based on stricter validators, which is the answer im trying to ascertain right now. > > In a failover sense, say for example I am advertising /22 out of my Brisbane POP and some /24's out of my Sydney POP, my Sydney POP goes down and im no longer originating those /24's, by what i've been told my /22 would now become invalid on next check as my /24's are not being advertised, even though I have ROAs for the /22 and /24's. > > I believe i've been given somewhat wrong information but they were basing it off experiences with other APNIC members, I just dont want to end up in a position where our routes are dropped after implementing our ROAs, and maintain flexibility to not wait multiple hours before we can advertise a new prefix if required. > > Thanks, > Joe > > ------ Original Message ------ > From: "Phil Mawson" > > To: "Joseph Goldman" > > Cc: "ausnog at lists.ausnog.net " > > Sent: 23/05/2024 3:52:54 PM > Subject: Re: [AusNOG] Experiences with RPKI > >> Hi Joe, >> >> First up, well done on working on your RPKI roll out. Signing your own routes is the most important step you can take to protect your own network. >> >> In regards to using max length, I do advise against that as what it means someone can still hijack one of your un-advertised routes and it would be treated as real. >> >> IE: If you advertise and sign a /19, but have a ROA created for each route up to a /24. If you are not advertising all of those, a third party could advertise one of our /24s and spoof your ASN and it would be treated as valid on the internet. >> >> APNIC portal make it very easy to create ROAs for your own routes as it has the route table view so it can see what is already publicly advertise. I recommend looking at that and then signing routes based on that. >> >> DDoS mitigation providers and ROAs is an interesting topic and not sure the community can agree on what is the best technical solution for that. >> >> Regards, >> Phil >> >> >>> On 23 May 2024, at 3:46?PM, Joseph Goldman > wrote: >>> >>> G'day list, >>> >>> In the process of rolling out RPKI - and while I thought I had a good grasp on everything, there is one niggling piece of information that I've come against and can't verify. Was hoping people can share their experiences. >>> >>> We are only doing our ROA's to begin with and not implementing validation until later, the initial thought was to create an ROA for all our 'supernets' and use maxLength to 24 to help cover any prefix we may want to advertise. We are a much simpler setup, single AS only and we do advertise many of our ranges down to /24 but not all of them. I do know of the best practices of not using maxLength based on a draft rfc doc, but I am personally not super concerned for our relatively small use-case to the issues brought up in that doc. >>> >>> Where I have come into trouble is a source (APNIC helpdesk) indicating that if we have any ROAs that exist for prefixes we are not directly advertising - it may lend some validators to mark all our routes as invalid? >>> >>> i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are 'unused' in that we are not advertising those specific resources - would that cause issues with strict validators out in the wild? >>> >>> My understanding reading through the RFC's is this should not be the case. If any ROA that matches the prefix for the origin AS exists it should be valid, regardless of other ROAs signed by the same resource holder etc. >>> >>> Matching ROAs to exact advertisements is great, but it seems to lend itself to much less flexibility in traffic engineering and failover scenarios - a good scenario is having dormant /24 ROAs for say a DDoS mitigation service to use when needed, so you dont have to wait for RPKI propagation before scrubbing kicks in. >>> >>> Based on your experience, is having all-encompassing (using maxLength), or unused ROAs an acceptable way to use RPKI or will we run into issues? >>> >>> All help appreciated :) >>> >>> Thanks, >>> Joe >>> _______________________________________________ >>> AusNOG mailing list >>> AusNOG at lists.ausnog.net >>> https://lists.ausnog.net/mailman/listinfo/ausnog >> > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at goldman.id.au Thu May 23 16:50:44 2024 From: joseph at goldman.id.au (Joseph Goldman) Date: Thu, 23 May 2024 06:50:44 +0000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Thank you to everyone who reached out on and off list! I have curbed the fears of what APNIC Helpdesk told me and am confident to continue with my original assumptions :) ------ Original Message ------ From: "Joseph Goldman" To: "ausnog at lists.ausnog.net" Sent: 23/05/2024 3:46:53 PM Subject: [AusNOG] Experiences with RPKI >G'day list, > > In the process of rolling out RPKI - and while I thought I had a good >grasp on everything, there is one niggling piece of information that >I've come against and can't verify. Was hoping people can share their >experiences. > > We are only doing our ROA's to begin with and not implementing >validation until later, the initial thought was to create an ROA for >all our 'supernets' and use maxLength to 24 to help cover any prefix we >may want to advertise. We are a much simpler setup, single AS only and >we do advertise many of our ranges down to /24 but not all of them. I >do know of the best practices of not using maxLength based on a draft >rfc doc, but I am personally not super concerned for our relatively >small use-case to the issues brought up in that doc. > > Where I have come into trouble is a source (APNIC helpdesk) indicating >that if we have any ROAs that exist for prefixes we are not directly >advertising - it may lend some validators to mark all our routes as >invalid? > >i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently >advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are >'unused' in that we are not advertising those specific resources - >would that cause issues with strict validators out in the wild? > > My understanding reading through the RFC's is this should not be the >case. If any ROA that matches the prefix for the origin AS exists it >should be valid, regardless of other ROAs signed by the same resource >holder etc. > > Matching ROAs to exact advertisements is great, but it seems to lend >itself to much less flexibility in traffic engineering and failover >scenarios - a good scenario is having dormant /24 ROAs for say a DDoS >mitigation service to use when needed, so you dont have to wait for >RPKI propagation before scrubbing kicks in. > > Based on your experience, is having all-encompassing (using >maxLength), or unused ROAs an acceptable way to use RPKI or will we run >into issues? > >All help appreciated :) > >Thanks, >Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph at goldman.id.au Sat May 25 11:55:36 2024 From: joseph at goldman.id.au (Joseph Goldman) Date: Sat, 25 May 2024 01:55:36 +0000 Subject: [AusNOG] Experiences with RPKI In-Reply-To: References: Message-ID: Thank you again to all for the advice :) ------ Original Message ------ From: "Joseph Goldman" To: "ausnog at lists.ausnog.net" Sent: 23/05/2024 4:50:44 PM Subject: Re: [AusNOG] Experiences with RPKI >Thank you to everyone who reached out on and off list! > >I have curbed the fears of what APNIC Helpdesk told me and am confident >to continue with my original assumptions :) > > >------ Original Message ------ >From: "Joseph Goldman" >To: "ausnog at lists.ausnog.net" >Sent: 23/05/2024 3:46:53 PM >Subject: [AusNOG] Experiences with RPKI > >>G'day list, >> >> In the process of rolling out RPKI - and while I thought I had a good >>grasp on everything, there is one niggling piece of information that >>I've come against and can't verify. Was hoping people can share their >>experiences. >> >> We are only doing our ROA's to begin with and not implementing >>validation until later, the initial thought was to create an ROA for >>all our 'supernets' and use maxLength to 24 to help cover any prefix >>we may want to advertise. We are a much simpler setup, single AS only >>and we do advertise many of our ranges down to /24 but not all of >>them. I do know of the best practices of not using maxLength based on >>a draft rfc doc, but I am personally not super concerned for our >>relatively small use-case to the issues brought up in that doc. >> >> Where I have come into trouble is a source (APNIC helpdesk) >>indicating that if we have any ROAs that exist for prefixes we are not >>directly advertising - it may lend some validators to mark all our >>routes as invalid? >> >>i.e. say we had /22 ROA, 2x /23 ROAs and 4x /24 ROAs - are currently >>advertising the /22 and 2x /24's, so 2x /23's and 2x /24 ROAs are >>'unused' in that we are not advertising those specific resources - >>would that cause issues with strict validators out in the wild? >> >> My understanding reading through the RFC's is this should not be the >>case. If any ROA that matches the prefix for the origin AS exists it >>should be valid, regardless of other ROAs signed by the same resource >>holder etc. >> >> Matching ROAs to exact advertisements is great, but it seems to lend >>itself to much less flexibility in traffic engineering and failover >>scenarios - a good scenario is having dormant /24 ROAs for say a DDoS >>mitigation service to use when needed, so you dont have to wait for >>RPKI propagation before scrubbing kicks in. >> >> Based on your experience, is having all-encompassing (using >>maxLength), or unused ROAs an acceptable way to use RPKI or will we >>run into issues? >> >>All help appreciated :) >> >>Thanks, >>Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0lqmu0sl.png Type: image/png Size: 3437 bytes Desc: not available URL: