MANRS Community

Download

manrs-community@elists.manrs.org

February 2026

6 participants
2 discussions

REPORT: Routing Security SIG at APRICOT 2026, Jakarta, Indonesia
by Terry Sweetser Feb. 18, 2026

Feb. 18, 2026

(REPOSTED from the Routing Security SIG mail list at APNIC.) *Event:* APNIC 61 / APRICOT 2026 *Location:* Jakarta, Indonesia *Date:* Tuesday, 10 February 2026 *Chairs:* Terry Sweetser, Taiji Kimura Executive Summary The Routing Security SIG at APNIC 61 highlighted a maturing landscape in APAC’s routing hygiene. The standout theme of the session was the *"Indonesia Success Story,"* demonstrating how a coordinated national effort between an NIR (IDNIC) and an IXP (IIX) can achieve >90% ROA coverage and enforce "Drop Invalid" policies at scale. While RPKI ROA adoption is high in Southeast Asia, the session shifted focus toward the next frontier: *Autonomous System Provider Authorization (ASPA)*. The presentations struck a balance between operational realities, real-world hijack incidents, academic research, and the standardization required to future-proof the RPKI transport layer. Session Summaries 1. Securing the Indonesia Routing Table (The "Star" of the Show) *Speaker:* Syarif Lumintarjo (IDNIC/APJII) This was the operational highlight of the SIG, showcasing Indonesia as a global leader in RPKI deployment. - *The Data:* Valid ROA coverage in Indonesia skyrocketed from *1% in Nov 2020* to *86% in Feb 2025*, with a projection of 90% by this month. - *Operational Enforcement:* The Indonesia Internet Exchange (IIX) began strictly dropping RPKI Invalids in 2023. They currently filter invalids for over 790 peers. - *Strategy:* IDNIC achieved this through a "carrot and stick" approach: developing "myIDNIC" for easy ROA creation, implementing "RPKI Badges" for gamification, and taking direct action by emailing members with unsecured BGP advertisements. 2. ASPA in the RPKI Dashboard *Speaker:* Tim Bruijnzeels (RIPE NCC) As ROA adoption saturates, the focus is moving to *Autonomous System Provider Authorization (ASPA)*. Tim provided the technical "rulebook" for deployment based on the IETF profile draft-ietf-sidrops-aspa-profile <https://www.google.com/url?sa=E&q=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%…> . - *The "All Upstreams" Rule:* Operators must include *ALL* IP Transit Providers (upstreams) in their ASPA records. - *The "No Peers" Rule:* Do *NOT* include lateral peers or transparent route servers. If you include a peer, you are authorizing them to act as your upstream, which breaks the valley-free routing logic and security model. - *The "AS 0" Rule:* For Tier-1 networks or those with no upstream providers, an ASPA record should be created authorizing *AS 0*. This explicitly signals that the network has no providers, preventing malicious actors from claiming to be their upstream. 3. Case Study: RPKI vs. Social Engineering *Speakers:* Sanjaya (APNIC) & Carlos Martinez (LACNIC) This session provided the "security justification" for ASPA, moving beyond simple fat-finger error correction. - *The Incident:* A bad actor successfully hijacked LACNIC address space not by hacking a router, but by socially engineering a multinational transit provider (using fake letterheads) into accepting the announcement. - *The Gap:* A ROA existed, but because the attacker convinced a legitimate upstream to propagate the route, the path looked "plausible" to the outside world until manual intervention occurred. - *The ASPA Solution:* The speakers emphasized that *ASPA is the necessary defense against this specific attack vector*. If the victim ASN had an ASPA record, the rest of the internet would have seen that the multinational transit provider was not an authorized upstream for that prefix, and the hijack would have been automatically dampened. 4. RPKI APAC Update *Speaker:* Shane Hermoso (APNIC) Shane provided the regional "report card," revealing a sharp divide in the APAC region. - *Southeast Asia is Leading:* SE Asia has reached *92.4%* IPv4 Valid coverage. Vietnam (98.5%) and the Philippines (96.1%) are top performers. - *East Asia Lagging:* East Asia sits at only *31.0%* valid coverage. This low percentage is primarily driven by the ongoing low adoption rates in *China*, which stands in stark contrast to the near-universal adoption seen in Southeast Asian economies. 5. IETF SIDROPS Update *Speaker:* Tom Harrison (APNIC) Technical updates on the standards track aimed at addressing scalability issues in the RPKI ecosystem. - *Erik Synchronization Protocol:* This protocol was highlighted as a significant optimization for scaling RPKI. By introducing "Erik Relays" and Merkle tree-based repair, it promises to make the propagation of records highly resilient, solving the fragility issues of the current rsync/RRDP dependency. - *Trust Anchor (TA) Constraints:* New mechanisms to prevent a Trust Anchor (like an RIR) from claiming resources it doesn't own. 6. Research: MESec (Minimal-Exposure AS-Path Verification) *Speaker:* Zhan Jiangou (Tsinghua University) - *The Proposal:* A framework to verify AS-Paths without globally exposing business relationships. - *Mechanism:* Uses a "Validator-assisted" architecture where ASes share encrypted relationship data with trusted validators rather than the whole world. Observations & Chair’s Remarks 1. *Synthesized ASPA Deployment Advice:* Combining the insights from Tim, Sanjaya, and Carlos, the SIG offers the following best practice advice for ASPA deployment: - *Authorization:* Create ASPA records authorizing only your transit providers (upstreams). - *Exclusion:* Explicitly exclude lateral peers to prevent route leaks. - *Defense:* View ASPA not just as a leak-prevention tool, but as a defense against social engineering attacks where unauthorized upstreams are tricked into propagating your space. 2. *Resilience via the Erik Protocol:* The introduction of the Erik Synchronization Protocol is timely. As RPKI becomes mission-critical infrastructure, the fragility of current transport mechanisms is a liability. The Erik protocol represents a significant optimization for scaling and high resilience that the industry must track closely. 3. *ASPA Vendor "Catch Up":* With the *Autonomous System Provider Authorization* profile nearing RFC status, the pressure shifts from standards bodies to vendors. There is now an urgent need for significant "catch up" by hardware vendors to bring ASPA support from "experimental" to "production-grade" in router firmware. 4. *The China Gap:* While we celebrate the success in Southeast Asia, the low adoption rate in China remains a critical gap in the regional routing security posture. Targeted outreach to Chinese operators may be required to improve the overall health of the APAC routing table. *Report prepared by:* Terry Sweetser Chair, APNIC Routing Security SIG Transparency Note: This report was drafted with the assistance of Artificial Intelligence tools for transcript ingestion and summarization.

1 0

Best practice over DSCP and priority as an ISP and IX and QOS in General
by Martin Passard Feb. 5, 2026

Feb. 5, 2026

Hello dear MANRS community, We, at IELO (AS29075), are working on the question of DSPC tags transparency as ISP. To give more context, we are a French neutral infrastructure network operator, Tier 2 over France and west-europe and our main focus regarding products like transit or our FTTO with DIA are to be as neutral and efficient using peering over western Europe, PNI and multiple tier1 transits. On our internal network, like a lot of others, we have classification over equipment using for exemple Cisco "Traffic class", seeing old IP Precedence matching to mark signaling protocols from the very old RFC 791 to ensure that for our core interface, signaling protocols are put inside the best queue of the 7 on them. We currently do not (in most of cases) move any of DSCP service fields on our network, however, we do know that on our equipment, by defaults, DSCP fields P.E. of clients traffic will be, by default on the equipements, be interpreted and moved automatically into queues, that we might want to avoid. For exemple any client pushing all DSCP traffic with high priority value would if not changed, be interpreted as important as internal protocols. We do have seen other network resetting DSCP fields to 0 and other QoS parameters of trafic they do transport. On our side, we hesitate on how to manage client trafic "abnormal" trafic. Let's not say it's not non-legitimate, but might be wrongly interpreted by default behavior of network equipment. We do mostly do think that a best practice for a network operator should be to change clients interfaces to restrict high priority queues while not resetting DSCP field. It's an easy way to ensure to this day that we would keep everyone equal, but changing it, is by our current point of view, is a non-neutral action. However, attacks using DSCP field to abuse queuing behavior and might disturb equipment since they don't care what trafic it is before moving the queues is a difficult questions. RFC 4594#section-6 tries to answer a bit of it but lacks content and real issue. So, after exposing that, what we do ask for your opinion on the subject is : Should ISP and IXP remove (for exemple, many variants exists here) DSCP CS6 and CS7 fields from client trafic to reserve them for real signaling protocols and internetworking ? Or should we adapt our equipment policy to explicitly change the queue of such traffic without modifying them, thus making keeping the information of it quite difficult. Or should do not change any of them to keep as transparent as we can even though we might have trafic abusing equipment mechanics appear over the time. Or maybe should we all implement it the other way around by never using high priority to be used unless we exactly know that the trafic is to be treated as is and so only make priorisation where we are perfectly sure of it. Or anything else? What do you all think and manage these fields on your backbone and how we should reacts over them ? What should be/is the best practice for being neutral to them without having abusive flows? I think this question is important as well over IXP, where I think it could be as well be something to watch, and where the answer to the best practice to apply might vary here. I know this question clearly is NOT an hot topic for anyone, and probably is, let's say... not in vogue at all for anyone. But while it went inside our minds as we saw it and talked about it in our own team we could not reach an informed consensus on what's best for both internet transparency while avoiding abuse nor find. Best regards -- Martin Passard AS29075.net ielo.net Peering Manager / Network engineer

5 6