September 2023 - MANRS Community - MANRS Mailing Lists

Problem with RPKI measurement in Observatory
by Marcelo Gondim Oct. 19, 2023

Oct. 19, 2023

Dear, It's been a while since I noticed that the RPKI percentage measurement through the Observatory is not correct and showing problems in the RPKI. The tool used for checking is RIPE and RIPE does not contain any problems. All IP prefixes are perfectly announced with their ROAs and duly registered and replicated by krill. However, whenever we access the Observatory it does not appear as 100% and in the past it worked perfectly well. Is there any plan to fix this problem in the system or provide more clear information about where the problem would be? I ask because in the RIPE link provided in the Observatory details, there is no problem with AS262907. Best regards, -- -- *AVISO LEGAL*Com base na Lei Geral de Proteção de Dados, esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada, devendo ser utilizada estritamente para o fim a que se dirige. Se você não for destinatário desta mensagem, não a divulgue, copie, distribua, examine ou utilize a informação contida nela. Caso você tenha recebido esta mensagem por engano, nos retorne este e-mail para eliminação do seu conteúdo em sua base de dados, registros ou sistemas de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação.

3 5

Nominations Open 1 October for MANRS Steering Committee
by Robbie Mitchell Sept. 28, 2023

Sept. 28, 2023

Howdy, As mentioned at yesterday’s meeting, nominations for three seats on the MANRS Steering Committee<https://www.manrs.org/about/governance/steering-committee/> will open on Monday, 2 October and close on 28 October. We’re providing MANRS participants with the links today in advance and will publish this information to the MANRS website on Monday. Seats currently held by Arnold Nipper, Arturo Servin and Nick Hilliard are available. Members of the Steering Committee may serve for a maximum of two consecutive three-year terms, and all three incumbent members are eligible to run again. Everyone is eligible to serve on the Steering Committee - MANRS participation is not required. MANRS participants will vote online from 31 October to 2 November 2023. Make sure you know who your voting representative is and update information as needed. Log into your Observatory account<https://observatory.manrs.org/#/overview> and check your profile (in the top right of the screen). It will tell you if you're the primary contact for your organization, or who it is if it isn't you. Learn more. 2023 Steering Committee Elections: https://www.manrs.org/about/governance/2023-manrs-steering-committee-electi… Appointment Process: https://www.manrs.org/about/governance/2023-manrs-steering-committee-electi… Nominations Form: https://www.manrs.org/about/governance/2023-manrs-steering-committee-electi… If you have any questions about the process, please let us know at contact(a)manrs.org<mailto:contact@manrs.org>. _________________________________________________________ Robbie (on behalf of the MANRS Secretariate)

1 0

[SXINFO-1067] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by SwissIX Sept. 25, 2023

Sept. 25, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1067?sda_s… This is shared with huize.asia, DE-CIX, swissix.ch, Customer Service Bot, joe(a)atomic.ac, Brandon(a)huize.asia, and 3 other people ------------------------------ joe(a)atomic.ac commented: Hi Why do you need to use BGP? You know your own prefixes right? All traffic leaving your network must have source address in your prefix ranges. – Regards, Joe Atomic Access - we make fibre epic! [1]www.atomicaccess.co.za - 021 300 5046 !Atomic-Logo.png|thumbnail! "The new needs friends." – Anton Ego [2]www.facebook.com/AtomicAccess [3]www.instagram.com/AtomicAccess > On 25 Sep 2023, at 18:09, Brandon Zhi <Brandon(a)huize.asia> wrote: > > Hi all, > > Thank you for your suggestions. I have been studying how to add the prefixes received from BGP to tc rules to whitelist them. > > At present, I have not found any relevant tutorials. It would be better if there were relevant tutorials. > > Best, > Brandon Zhi > HUIZE LTD > [4]www.huize.asia | www.ixp.su | Twitter > > This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. > > > On Fri, 15 Sept 2023 at 21:36, Kapteyan Bilişim Teknolojileri AŞ <info(a)kapteyan.com.tr> wrote: > Hello, > > What is an IP address? > — > Best Regards. > Alperen T. AYDIN > C-Level Executive > T: 0850 888 2 507 > F: 0242 922 0 725 > E: info(a)kapteyan.com.tr > Kapteyan Bilişim Teknolojileri AŞ > Tarım Mh. Perge Bulvarı Cd. Perge Plaza İş Merkezi C Blok No: 13/106 > Muratpaşa / ANTALYA > [5]www.kapteyan.com.tr > >> On 15 Sep 2023, at 16:23, Joe Botha <joe(a)atomic.ac> wrote: >> >> Hi >> >> Using x86 routers and Mellanox switches running Debian 12 and FRR 9. >> >> In both cases we disable rp_filter. >> >> On x86 (IPT routers) we use nftables to implement anti-spoofing. Pretty basic - drop all packets that leave our network if source address is not in our IP ranges. >> >> On Mellanox (peering routers) we use tc rules (hardware path). Here we drop packets we receive on the fibre network facing interfaces, based on which subnets are routed there. tc syntax involves more rules to write and maintain (vs nft). >> >> You could probably use tc in both cases. >> >> – >> Regards, >> Joe >> >> Atomic Access - we make fibre epic! >> [6]www.atomicaccess.co.za - 021 300 5046 >> >> >> >> <Atomic-Logo.png> >> >> >> >> "The new needs friends." – Anton Ego >> [7]www.facebook.com/AtomicAccess >> [8]www.instagram.com/AtomicAccess >> >> >> >> >>> On 14 Sep 2023, at 14:30, Brandon Zhi <Brandon(a)huize.asia> wrote: >>> >>> Hi guys, >>> >>> We are currently researching the use of Bird and Debian 11 as a router. Typically, for implementing asymmetric routing, we would disable source address validation on the Linux network interfaces because Bird only imports the preferred BGP routes into the kernel. >>> >>> To disable source address validation, we added the following lines to the /etc/sysctl.conf file: >>> >>> echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf >>> echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf >>> >>> However, this causes the Linux router to no longer inspect inbound traffic, making it susceptible to spoofing attacks. For example: >>> >>> 10:03:26.838383 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 905: 122.50.0.17.3036 > 39.156.66.10.80: Flags [SE], seq 198995835:198996686, win 60981, length 851: HTTP >>> 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.0.152.32073 > 39.156.66.10.80: Flags [S], seq 2101939968:2101940861, win 62208, length 893: HTTP >>> 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 21709, win 0, length 0 >>> 10:03:26.838399 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.0.72.62493 > 124.220.216.71.80: Flags [SE], seq 4095570527:4095571381, win 62133, length 854: HTTP >>> 10:03:26.838400 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 5445, win 0, length 0 >>> 10:03:26.838406 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.1.104.54896 > 39.156.66.10.80: Flags [SE], seq 3597707872:3597708726, win 61211, length 854: HTTP >>> 10:03:26.838414 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 936: 122.50.2.72.7733 > 39.156.66.10.80: Flags [SE], seq 506840124:506841006, win 62528, length 882: HTTP >>> 10:03:26.838421 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 944: 122.50.2.135.47620 > 39.156.66.10.80: Flags [SE], seq 3120826456:3120827346, win 61210, length 890: HTTP >>> 10:03:26.838429 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.2.178.34590 > 39.156.66.10.80: Flags [SE], seq 2266895668:2266896561, win 62280, length 893: HTTP >>> 10:03:26.838438 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 907: 122.50.0.244.59325 > 39.156.66.10.80: Flags [SE], seq 3887931453:3887932306, win 64335, length 853: HTTP >>> >>> The solutions I can think of are as follows: >>> >>> Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. >>> >>> Import all routes into the Linux kernel, similar to ECMP (Equal-Cost Multipath Routing). >>> >>> However, these implementations can be complex. Does anyone have experience using Linux as a BGP router? >>> >>> Thanks, >>> Brandon Zhi >>> HUIZE LTD >>> [9]www.huize.asia | www.ixp.su | Twitter >>> >>> This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. >>> – >>> Manrs-community mailing list >>> Manrs-community(a)elists.manrs.org >>> [10]https://elists.manrs.org/mailman/listinfo/manrs-community >> >> – >> Manrs-community mailing list >> Manrs-community(a)elists.manrs.org >> [11]https://elists.manrs.org/mailman/listinfo/manrs-community > > – > Manrs-community mailing list > Manrs-community(a)elists.manrs.org > [12]https://elists.manrs.org/mailman/listinfo/manrs-community – Manrs-community mailing list Manrs-community(a)elists.manrs.org [13]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] http://www.atomicaccess.co.za [2] http://www.facebook.com/AtomicAccess [3] http://www.instagram.com/AtomicAccess [4] http://www.huize.asia [5] http://www.kapteyan.com.tr [6] http://www.atomicaccess.co.za [7] http://www.facebook.com/AtomicAccess [8] http://www.instagram.com/AtomicAccess [9] http://www.huize.asia [10] https://elists.manrs.org/mailman/listinfo/manrs-community [11] https://elists.manrs.org/mailman/listinfo/manrs-community [12] https://elists.manrs.org/mailman/listinfo/manrs-community [13] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

[SXINFO-1067] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by SwissIX Sept. 25, 2023

Sept. 25, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1067?sda_s… This is shared with huize.asia, DE-CIX, swissix.ch, Customer Service Bot, joe(a)atomic.ac, Brandon(a)huize.asia, and 3 other people ------------------------------ Brandon(a)huize.asia commented: Hi joe, We also provide IP Transit and we have our iBGP session between each node. If we only allowed our own prefixes range, iBGP would not work. Best regards, Brandon Zhi HUIZE LTD [1]www.huize.asia | [2]www.ixp.su | Twitter !https://ci3.googleusercontent.com/mail-sig/AIorK4w5mVhfW4gNpNNG4wjzSr6YXLPGstLI3_79RkgqnXaG2nuFEB1nkGeXOqUOO3ma96TcEVR3iaA! This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Tue, 26 Sept 2023 at 00:18, Joe Botha <[3]joe(a)atomic.ac> wrote: Hi Why do you need to use BGP? You know your own prefixes right? All traffic leaving your network must have source address in your prefix ranges. – Regards, Joe Atomic Access - we make fibre epic! [4]www.atomicaccess.co.za - 021 300 5046 "The new needs friends." – Anton Ego [5]www.facebook.com/AtomicAccess [6]www.instagram.com/AtomicAccess > On 25 Sep 2023, at 18:09, Brandon Zhi <[7]Brandon(a)huize.asia> wrote: > > Hi all, > > Thank you for your suggestions. I have been studying how to add the prefixes received from BGP to tc rules to whitelist them. > > At present, I have not found any relevant tutorials. It would be better if there were relevant tutorials. > > Best, > Brandon Zhi > HUIZE LTD > [8]www.huize.asia | [9]www.ixp.su | Twitter > > This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. > > > On Fri, 15 Sept 2023 at 21:36, Kapteyan Bilişim Teknolojileri AŞ <[10]info(a)kapteyan.com.tr> wrote: > Hello, > > What is an IP address? > — > Best Regards. > Alperen T. AYDIN > C-Level Executive > T: 0850 888 2 507 > F: 0242 922 0 725 > E: [11]info(a)kapteyan.com.tr > Kapteyan Bilişim Teknolojileri AŞ > Tarım Mh. Perge Bulvarı Cd. Perge Plaza İş Merkezi C Blok No: 13/106 > Muratpaşa / ANTALYA > [12]www.kapteyan.com.tr > >> On 15 Sep 2023, at 16:23, Joe Botha <[13]joe(a)atomic.ac> wrote: >> >> Hi >> >> Using x86 routers and Mellanox switches running Debian 12 and FRR 9. >> >> In both cases we disable rp_filter. >> >> On x86 (IPT routers) we use nftables to implement anti-spoofing. Pretty basic - drop all packets that leave our network if source address is not in our IP ranges. >> >> On Mellanox (peering routers) we use tc rules (hardware path). Here we drop packets we receive on the fibre network facing interfaces, based on which subnets are routed there. tc syntax involves more rules to write and maintain (vs nft). >> >> You could probably use tc in both cases. >> >> – >> Regards, >> Joe >> >> Atomic Access - we make fibre epic! >> [14]www.atomicaccess.co.za - 021 300 5046 >> >> >> >> <Atomic-Logo.png> >> >> >> >> "The new needs friends." – Anton Ego >> [15]www.facebook.com/AtomicAccess >> [16]www.instagram.com/AtomicAccess >> >> >> >> >>> On 14 Sep 2023, at 14:30, Brandon Zhi <[17]Brandon(a)huize.asia> wrote: >>> >>> Hi guys, >>> >>> We are currently researching the use of Bird and Debian 11 as a router. Typically, for implementing asymmetric routing, we would disable source address validation on the Linux network interfaces because Bird only imports the preferred BGP routes into the kernel. >>> >>> To disable source address validation, we added the following lines to the /etc/sysctl.conf file: >>> >>> echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf >>> echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf >>> >>> However, this causes the Linux router to no longer inspect inbound traffic, making it susceptible to spoofing attacks. For example: >>> >>> 10:03:26.838383 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 905: 122.50.0.17.3036 > 39.156.66.10.80: Flags [SE], seq 198995835:198996686, win 60981, length 851: HTTP >>> 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.0.152.32073 > 39.156.66.10.80: Flags [S], seq 2101939968:2101940861, win 62208, length 893: HTTP >>> 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 21709, win 0, length 0 >>> 10:03:26.838399 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.0.72.62493 > 124.220.216.71.80: Flags [SE], seq 4095570527:4095571381, win 62133, length 854: HTTP >>> 10:03:26.838400 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 5445, win 0, length 0 >>> 10:03:26.838406 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.1.104.54896 > 39.156.66.10.80: Flags [SE], seq 3597707872:3597708726, win 61211, length 854: HTTP >>> 10:03:26.838414 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 936: 122.50.2.72.7733 > 39.156.66.10.80: Flags [SE], seq 506840124:506841006, win 62528, length 882: HTTP >>> 10:03:26.838421 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 944: 122.50.2.135.47620 > 39.156.66.10.80: Flags [SE], seq 3120826456:3120827346, win 61210, length 890: HTTP >>> 10:03:26.838429 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.2.178.34590 > 39.156.66.10.80: Flags [SE], seq 2266895668:2266896561, win 62280, length 893: HTTP >>> 10:03:26.838438 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 907: 122.50.0.244.59325 > 39.156.66.10.80: Flags [SE], seq 3887931453:3887932306, win 64335, length 853: HTTP >>> >>> The solutions I can think of are as follows: >>> >>> Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. >>> >>> Import all routes into the Linux kernel, similar to ECMP (Equal-Cost Multipath Routing). >>> >>> However, these implementations can be complex. Does anyone have experience using Linux as a BGP router? >>> >>> Thanks, >>> Brandon Zhi >>> HUIZE LTD >>> [18]www.huize.asia | [19]www.ixp.su | Twitter >>> >>> This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. >>> – >>> Manrs-community mailing list >>> [20]Manrs-community(a)elists.manrs.org >>> [21]https://elists.manrs.org/mailman/listinfo/manrs-community >> >> – >> Manrs-community mailing list >> [22]Manrs-community(a)elists.manrs.org >> [23]https://elists.manrs.org/mailman/listinfo/manrs-community > > – > Manrs-community mailing list > [24]Manrs-community(a)elists.manrs.org > [25]https://elists.manrs.org/mailman/listinfo/manrs-community – Manrs-community mailing list Manrs-community(a)elists.manrs.org [26]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] https://huize.asia/ [2] https://www.ixp.su/ [3] mailto:joe@atomic.ac [4] http://www.atomicaccess.co.za [5] http://www.facebook.com/AtomicAccess [6] http://www.instagram.com/AtomicAccess [7] mailto:Brandon@huize.asia [8] http://www.huize.asia [9] http://www.ixp.su [10] mailto:info@kapteyan.com.tr [11] mailto:info@kapteyan.com.tr [12] http://www.kapteyan.com.tr [13] mailto:joe@atomic.ac [14] http://www.atomicaccess.co.za [15] http://www.facebook.com/AtomicAccess [16] http://www.instagram.com/AtomicAccess [17] mailto:Brandon@huize.asia [18] http://www.huize.asia [19] http://www.ixp.su [20] mailto:Manrs-community@elists.manrs.org [21] https://elists.manrs.org/mailman/listinfo/manrs-community [22] mailto:Manrs-community@elists.manrs.org [23] https://elists.manrs.org/mailman/listinfo/manrs-community [24] mailto:Manrs-community@elists.manrs.org [25] https://elists.manrs.org/mailman/listinfo/manrs-community [26] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by Brandon Zhi Sept. 25, 2023

Sept. 25, 2023

Hi guys, We are currently researching the use of Bird and Debian 11 as a router. Typically, for implementing asymmetric routing, we would disable source address validation on the Linux network interfaces because Bird only imports the preferred BGP routes into the kernel. To disable source address validation, we added the following lines to the /etc/sysctl.conf file: echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf However, this causes the Linux router to no longer inspect inbound traffic, making it susceptible to spoofing attacks. For example: 10:03:26.838383 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 905: 122.50.0.17.3036 > 39.156.66.10.80: Flags [SE], seq 198995835:198996686, win 60981, length 851: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.0.152.32073 > 39.156.66.10.80: Flags [S], seq 2101939968:2101940861, win 62208, length 893: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 21709, win 0, length 0 10:03:26.838399 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.0.72.62493 > 124.220.216.71.80: Flags [SE], seq 4095570527:4095571381, win 62133, length 854: HTTP 10:03:26.838400 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 5445, win 0, length 0 10:03:26.838406 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.1.104.54896 > 39.156.66.10.80: Flags [SE], seq 3597707872:3597708726, win 61211, length 854: HTTP 10:03:26.838414 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 936: 122.50.2.72.7733 > 39.156.66.10.80: Flags [SE], seq 506840124:506841006, win 62528, length 882: HTTP 10:03:26.838421 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 944: 122.50.2.135.47620 > 39.156.66.10.80: Flags [SE], seq 3120826456:3120827346, win 61210, length 890: HTTP 10:03:26.838429 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.2.178.34590 > 39.156.66.10.80: Flags [SE], seq 2266895668:2266896561, win 62280, length 893: HTTP 10:03:26.838438 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 907: 122.50.0.244.59325 > 39.156.66.10.80: Flags [SE], seq 3887931453:3887932306, win 64335, length 853: HTTP The solutions I can think of are as follows: Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. Import all routes into the Linux kernel, similar to ECMP (Equal-Cost Multipath Routing). However, these implementations can be complex. Does anyone have experience using Linux as a BGP router? Thanks, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.

4 7

[SXINFO-1067] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by SwissIX Sept. 25, 2023

Sept. 25, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1067?sda_s… This is shared with huize.asia, DE-CIX, swissix.ch, Customer Service Bot, joe(a)atomic.ac, Brandon(a)huize.asia, and 3 other people ------------------------------ Brandon(a)huize.asia commented: Hi all, Thank you for your suggestions. I have been studying how to add the prefixes received from BGP to tc rules to whitelist them. At present, I have not found any relevant tutorials. It would be better if there were relevant tutorials. Best, Brandon Zhi HUIZE LTD [1]www.huize.asia | [2]www.ixp.su | Twitter !https://ci3.googleusercontent.com/mail-sig/AIorK4w5mVhfW4gNpNNG4wjzSr6YXLPGstLI3_79RkgqnXaG2nuFEB1nkGeXOqUOO3ma96TcEVR3iaA! This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Fri, 15 Sept 2023 at 21:36, Kapteyan Bilişim Teknolojileri AŞ <[3]info(a)kapteyan.com.tr> wrote: Hello, What is an IP address? — Best Regards. Alperen T. AYDIN C-Level Executive T: 0850 888 2 507 F: 0242 922 0 725 E: [4]info(a)kapteyan.com.tr Kapteyan Bilişim Teknolojileri AŞ Tarım Mh. Perge Bulvarı Cd. Perge Plaza İş Merkezi C Blok No: 13/106 Muratpaşa / ANTALYA [5]www.kapteyan.com.tr <[6]https://twitter.com/kapteyancomtr> <[7]https://www.facebook.com/kapteyancomtr/> <[8]https://instagram.com/kapteyanteknoloji> On 15 Sep 2023, at 16:23, Joe Botha <[9]joe(a)atomic.ac> wrote: Hi Using x86 routers and Mellanox switches running Debian 12 and FRR 9. In both cases we disable rp_filter. On x86 (IPT routers) we use nftables to implement anti-spoofing. Pretty basic - drop all packets that leave our network if source address is not in our IP ranges. On Mellanox (peering routers) we use tc rules (hardware path). Here we drop packets we receive on the fibre network facing interfaces, based on which subnets are routed there. tc syntax involves more rules to write and maintain (vs nft). You could probably use tc in both cases. – Regards, Joe Atomic Access - we make fibre epic! [10]www.atomicaccess.co.za - 021 300 5046 <Atomic-Logo.png> "The new needs friends." – Anton Ego [11]www.facebook.com/AtomicAccess [12]www.instagram.com/AtomicAccess On 14 Sep 2023, at 14:30, Brandon Zhi <[13]Brandon(a)huize.asia> wrote: Hi guys, We are currently researching the use of Bird and Debian 11 as a router. Typically, for implementing asymmetric routing, we would disable source address validation on the Linux network interfaces because Bird only imports the preferred BGP routes into the kernel. To disable source address validation, we added the following lines to the /etc/sysctl.conf file: echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf However, this causes the Linux router to no longer inspect inbound traffic, making it susceptible to spoofing attacks. For example: 10:03:26.838383 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 905: 122.50.0.17.3036 > 39.156.66.10.80: Flags [SE], seq 198995835:198996686, win 60981, length 851: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.0.152.32073 > 39.156.66.10.80: Flags [S], seq 2101939968:2101940861, win 62208, length 893: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 21709, win 0, length 0 10:03:26.838399 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.0.72.62493 > 124.220.216.71.80: Flags [SE], seq 4095570527:4095571381, win 62133, length 854: HTTP 10:03:26.838400 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 5445, win 0, length 0 10:03:26.838406 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.1.104.54896 > 39.156.66.10.80: Flags [SE], seq 3597707872:3597708726, win 61211, length 854: HTTP 10:03:26.838414 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 936: 122.50.2.72.7733 > 39.156.66.10.80: Flags [SE], seq 506840124:506841006, win 62528, length 882: HTTP 10:03:26.838421 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 944: 122.50.2.135.47620 > 39.156.66.10.80: Flags [SE], seq 3120826456:3120827346, win 61210, length 890: HTTP 10:03:26.838429 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.2.178.34590 > 39.156.66.10.80: Flags [SE], seq 2266895668:2266896561, win 62280, length 893: HTTP 10:03:26.838438 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 907: 122.50.0.244.59325 > 39.156.66.10.80: Flags [SE], seq 3887931453:3887932306, win 64335, length 853: HTTP The solutions I can think of are as follows: Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. Import all routes into the Linux kernel, similar to ECMP (Equal-Cost Multipath Routing). However, these implementations can be complex. Does anyone have experience using Linux as a BGP router? Thanks, Brandon Zhi HUIZE LTD [14]www.huize.asia | [15]www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. – Manrs-community mailing list [16]Manrs-community(a)elists.manrs.org [17]https://elists.manrs.org/mailman/listinfo/manrs-community – Manrs-community mailing list [18]Manrs-community(a)elists.manrs.org [19]https://elists.manrs.org/mailman/listinfo/manrs-community – Manrs-community mailing list [20]Manrs-community(a)elists.manrs.org [21]https://elists.manrs.org/mailman/listinfo/manrs-community – Manrs-community mailing list Manrs-community(a)elists.manrs.org [22]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] https://huize.asia/ [2] https://www.ixp.su/ [3] mailto:info@kapteyan.com.tr [4] mailto:info@kapteyan.com.tr [5] http://www.kapteyan.com.tr/ [6] https://twitter.com/kapteyancomtr [7] https://www.facebook.com/kapteyancomtr/ [8] https://instagram.com/kapteyanteknoloji [9] mailto:joe@atomic.ac [10] http://www.atomicaccess.co.za [11] http://www.facebook.com/AtomicAccess [12] http://www.instagram.com/AtomicAccess [13] mailto:Brandon@huize.asia [14] http://www.huize.asia [15] http://www.ixp.su [16] mailto:Manrs-community@elists.manrs.org [17] https://elists.manrs.org/mailman/listinfo/manrs-community [18] mailto:Manrs-community@elists.manrs.org [19] https://elists.manrs.org/mailman/listinfo/manrs-community [20] mailto:Manrs-community@elists.manrs.org [21] https://elists.manrs.org/mailman/listinfo/manrs-community [22] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

[SXINFO-1110] Problem with RPKI measurement in Observatory
by SwissIX Sept. 20, 2023

Sept. 20, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1110?sda_s… This is shared with brasiltecpar.com.br, swissix.ch, marcelogondim(a)brasiltecpar.com.br, clyde(a)isoc.org, info(a)swissix.ch, and manrs-community(a)elists.manrs.org ------------------------------ clyde(a)isoc.org commented: Many thanks for the offer of help, much appreciated! I think we are ok for now if will reach out if we need anything. Yes, it does seem that other ASNs are affected. We don’t have a full list of ASNs affected but we are working on a resolution to the problem as a top priority. Andy On 19 Sep 2023, at 17:57, SwissIX <info(a)swissix.ch> wrote: __________________________ clyde(a)isoc.org commented: Apologies, I replied to you not realising this was an autogenerated email from your ticket system. Andy On 19 Sep 2023, at 17:57, SwissIX <info(a)swissix.ch> wrote: __________________________ clyde(a)isoc.org commented: Many thanks for the offer of help, much appreciated! I think we are ok for now if will reach out if we need anything. Yes, it does seem that other ASNs are affected. We don’t have a full list of ASNs affected but we are working on a resolution to the problem as a top priority. Thanks Andy On 19 Sep 2023, at 17:38, Marcelo Gondim <marcelogondim(a)brasiltecpar.com.br> wrote: Hi Andy, I just wanted to report the problem and also check that there weren't other ASNs with the same problem. We appreciate the feedback and will wait for news on the resolution of the issue. If we can help in any way, just say so. Thanks and best regards. Em 19/09/2023 06:31, Andy Clyde escreveu: Thanks for flagging this up. We are aware of this issue and we are investigating what might be causing it. We don’t currently have a timeline on when it might be resolved though. Thanks Andy Senior Application Developer, The Internet Society On 18 Sep 2023, at 17:30, Marcelo Gondim [1]<marcelogondim(a)brasiltecpar.com.br> wrote: Dear, It's been a while since I noticed that the RPKI percentage measurement through the Observatory is not correct and showing problems in the RPKI. The tool used for checking is RIPE and RIPE does not contain any problems. All IP prefixes are perfectly announced with their ROAs and duly registered and replicated by krill. However, whenever we access the Observatory it does not appear as 100% and in the past it worked perfectly well. <tBayvtRe2TsQFAD0.png> <U20wFUH7q34ikWOj.png> Is there any plan to fix this problem in the system or provide more clear information about where the problem would be? I ask because in the RIPE link provided in the Observatory details, there is no problem with AS262907. Best regards, – <assinatura_brtecpar.png> AVISO LEGAL Com base na Lei Geral de Proteção de Dados, esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada, devendo ser utilizada estritamente para o fim a que se dirige. Se você não for destinatário desta mensagem, não a divulgue, copie, distribua, examine ou utilize a informação contida nela. Caso você tenha recebido esta mensagem por engano, nos retorne este e-mail para eliminação do seu conteúdo em sua base de dados, registros ou sistemas de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. – Manrs-community mailing list [2]Manrs-community(a)elists.manrs.org [3]https://elists.manrs.org/mailman/listinfo/manrs-community – <assinatura_brtecpar.png> AVISO LEGAL Com base na Lei Geral de Proteção de Dados, esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada, devendo ser utilizada estritamente para o fim a que se dirige. Se você não for destinatário desta mensagem, não a divulgue, copie, distribua, examine ou utilize a informação contida nela. Caso você tenha recebido esta mensagem por engano, nos retorne este e-mail para eliminação do seu conteúdo em sua base de dados, registros ou sistemas de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. – Manrs-community mailing list Manrs-community(a)elists.manrs.org [4]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] mailto:marcelogondim@brasiltecpar.com.br [2] mailto:Manrs-community@elists.manrs.org [3] https://elists.manrs.org/mailman/listinfo/manrs-community [4] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

[SXINFO-1110] Problem with RPKI measurement in Observatory
by SwissIX Sept. 19, 2023

Sept. 19, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1110?sda_s… This is shared with brasiltecpar.com.br, swissix.ch, marcelogondim(a)brasiltecpar.com.br, clyde(a)isoc.org, and manrs-community(a)elists.manrs.org ------------------------------ marcelogondim(a)brasiltecpar.com.br commented: Hi Andy, I just wanted to report the problem and also check that there weren't other ASNs with the same problem. We appreciate the feedback and will wait for news on the resolution of the issue. If we can help in any way, just say so. Thanks and best regards. Em 19/09/2023 06:31, Andy Clyde escreveu: Thanks for flagging this up. We are aware of this issue and we are investigating what might be causing it. We don’t currently have a timeline on when it might be resolved though. Thanks Andy Senior Application Developer, The Internet Society On 18 Sep 2023, at 17:30, Marcelo Gondim [1]<marcelogondim(a)brasiltecpar.com.br> wrote: Dear, It's been a while since I noticed that the RPKI percentage measurement through the Observatory is not correct and showing problems in the RPKI. The tool used for checking is RIPE and RIPE does not contain any problems. All IP prefixes are perfectly announced with their ROAs and duly registered and replicated by krill. However, whenever we access the Observatory it does not appear as 100% and in the past it worked perfectly well. <tBayvtRe2TsQFAD0.png> <U20wFUH7q34ikWOj.png> Is there any plan to fix this problem in the system or provide more clear information about where the problem would be? I ask because in the RIPE link provided in the Observatory details, there is no problem with AS262907. Best regards, – <assinatura_brtecpar.png> AVISO LEGAL Com base na Lei Geral de Proteção de Dados, esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada, devendo ser utilizada estritamente para o fim a que se dirige. Se você não for destinatário desta mensagem, não a divulgue, copie, distribua, examine ou utilize a informação contida nela. Caso você tenha recebido esta mensagem por engano, nos retorne este e-mail para eliminação do seu conteúdo em sua base de dados, registros ou sistemas de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. – Manrs-community mailing list [2]Manrs-community(a)elists.manrs.org [3]https://elists.manrs.org/mailman/listinfo/manrs-community – !assinatura_brtecpar.png|thumbnail! AVISO LEGAL Com base na Lei Geral de Proteção de Dados, esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada, devendo ser utilizada estritamente para o fim a que se dirige. Se você não for destinatário desta mensagem, não a divulgue, copie, distribua, examine ou utilize a informação contida nela. Caso você tenha recebido esta mensagem por engano, nos retorne este e-mail para eliminação do seu conteúdo em sua base de dados, registros ou sistemas de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. – Manrs-community mailing list Manrs-community(a)elists.manrs.org [4]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] mailto:marcelogondim@brasiltecpar.com.br [2] mailto:Manrs-community@elists.manrs.org [3] https://elists.manrs.org/mailman/listinfo/manrs-community [4] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

[SXINFO-1067] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by SwissIX Sept. 15, 2023

Sept. 15, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1067?sda_s… This is shared with huize.asia, DE-CIX, swissix.ch, Customer Service Bot, Brandon(a)huize.asia, manrs-community(a)elists.manrs.org, and averschuren(a)libertyglobal.com ------------------------------ Brandon(a)huize.asia commented: yeah, it is better to compare with getting prefixes from the BGP session. On the other hand, the BGP software only imports the best route into the kernel, which results in the inability to implement asymmetric routing even if loose mode is turned on. Sometimes it doesn't work if I set rp_filter=2. Brandon Zhi HUIZE LTD [1]www.huize.asia | [2]www.ixp.su | Twitter !https://ci3.googleusercontent.com/mail-sig/AIorK4w5mVhfW4gNpNNG4wjzSr6YXLPGstLI3_79RkgqnXaG2nuFEB1nkGeXOqUOO3ma96TcEVR3iaA! This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Fri, 15 Sept 2023 at 17:16, Verschuren, Antoin <[3]averschuren(a)libertyglobal.com> wrote: > Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. Why not use bgpq4 or similar to generate the prefix-filters from IRR data? Works like a charm for prefix filter lists < 5000 aggregated prefixes per AS as long as your peers maintain their IRR data (which is a MANRS requirement 😉). Additional benefit is you can use the same prefix filter lists for route filtering and supports multiple router vendors. Kind regards, Antoin Verschuren Senior Manager Network Security M + 31 6 15682664 Liberty Global Technology Services B.V. Boeing Avenue 53 1119 PE Schiphol-Rijk The Netherlands [4]www.libertyglobal.com From: Manrs-community <[5]manrs-community-bounces(a)elists.manrs.org> On Behalf Of Brandon Zhi Sent: Thursday 14 September 2023 14:30 To: [6]Manrs-community(a)elists.manrs.org Subject: [manrs-community] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers. Hi guys, We are currently researching the use of Bird and Debian 11 as a router. Typically, for implementing asymmetric routing, we would disable source address validation on the Linux network interfaces because Bird only imports the preferred BGP routes into the kernel. To disable source address validation, we added the following lines to the /etc/sysctl.conf file: echo "net.ipv4.conf.default.rp_filter=0" >> /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter=0" >> /etc/sysctl.conf However, this causes the Linux router to no longer inspect inbound traffic, making it susceptible to spoofing attacks. For example: 10:03:26.838383 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 905: 122.50.0.17.3036 > 39.156.66.10.80: Flags [SE], seq 198995835:198996686, win 60981, length 851: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.0.152.32073 > 39.156.66.10.80: Flags [S], seq 2101939968:2101940861, win 62208, length 893: HTTP 10:03:26.838392 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 21709, win 0, length 0 10:03:26.838399 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.0.72.62493 > 124.220.216.71.80: Flags [SE], seq 4095570527:4095571381, win 62133, length 854: HTTP 10:03:26.838400 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 54: 81.161.230.95.80 > 157.245.124.144.80: Flags [R.], seq 0, ack 5445, win 0, length 0 10:03:26.838406 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 908: 122.50.1.104.54896 > 39.156.66.10.80: Flags [SE], seq 3597707872:3597708726, win 61211, length 854: HTTP 10:03:26.838414 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 936: 122.50.2.72.7733 > 39.156.66.10.80: Flags [SE], seq 506840124:506841006, win 62528, length 882: HTTP 10:03:26.838421 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 944: 122.50.2.135.47620 > 39.156.66.10.80: Flags [SE], seq 3120826456:3120827346, win 61210, length 890: HTTP 10:03:26.838429 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 947: 122.50.2.178.34590 > 39.156.66.10.80: Flags [SE], seq 2266895668:2266896561, win 62280, length 893: HTTP 10:03:26.838438 a2:9f:60:36:20:5b > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 907: 122.50.0.244.59325 > 39.156.66.10.80: Flags [SE], seq 3887931453:3887932306, win 64335, length 853: HTTP The solutions I can think of are as follows: Obtain all routes from BGP, e.g., from AS1 and AS2, via different network interfaces. Then, convert these addresses into a whitelist and filter inbound traffic on the network interfaces based on prefixes using nft. Import all routes into the Linux kernel, similar to ECMP (Equal-Cost Multipath Routing). However, these implementations can be complex. Does anyone have experience using Linux as a BGP router? Thanks, Brandon Zhi HUIZE LTD [7]www.huize.asia | [8]www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. – Manrs-community mailing list Manrs-community(a)elists.manrs.org [9]https://elists.manrs.org/mailman/listinfo/manrs-community ---------------------------------------------------------------------------------------- [1] https://huize.asia/ [2] https://www.ixp.su/ [3] mailto:averschuren@libertyglobal.com [4] http://www.libertyglobal.com/ [5] mailto:manrs-community-bounces@elists.manrs.org [6] mailto:Manrs-community@elists.manrs.org [7] https://huize.asia/ [8] https://www.ixp.su/ [9] https://elists.manrs.org/mailman/listinfo/manrs-community ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0

[SXINFO-1067] Implementation of Anti-Spoofing and Asymmetric Routing on Linux Routers.
by SwissIX Sept. 15, 2023

Sept. 15, 2023

—–––—–—–––—––— Reply above this line. View your request in our Service Desk: https://service.de-cix.net/servicedesk/customer/portal/19/SXINFO-1067?sda_s… This is shared with huize.asia, DE-CIX, swissix.ch, Customer Service Bot, Brandon(a)huize.asia, and manrs-community(a)elists.manrs.org ------------------------------ Luzi von Salis resolved this as Done. ------------------------------ *Contact and office hours* *Office hours*: Monday - Friday 08:00 - 22:00 CET/CEST *Telephone*: +49 69 1730902 11 *E-Mail*: support(a)swissix.ch If you need assistance *outside of office hours* or in case of emergency, please call our *hotline* +49 69 1730902 11. -- *SwissIX Internet Exchange* Badenerstrasse 569 CH-8048 Zürich / Switzerland Technical Helpdesk contact 24/7: support(a)swissix.ch / +41 (0)44 330 70 90 Commercial Contact: info(a)swissix.ch VAT-ID: CHE-110.460.993 MWST

1 0