Hello,Following up on my earlier comments, If the team got a chance to look into — happy to clarify or discuss further if you have questions.
On RPKI-ROV: Section 4.1 requires "The AS originating NLRI for a prefix MUST be globally authorized", but provides no guidance on how operators verify this authorization. RPKI-ROV is the primary mechanism for origin validation, yet the draft mentions RPKI only once—warning against encoding validation state in transitive attributes. The relationship between IRR-based filtering and RPKI needs clarification: are they complementary, or does RPKI supersede IRR? Additionally, Section 4.1 requires AS_PATH authorization, but doesn't reference ASPA verification (draft-ietf-sidrops-aspa-verification), which directly addresses this requirement. On TCP-AO: Section 3.1 lists "BGP-MD5 / TCP-AO" as example technologies without guidance on preference or migration strategy. TCP-AO was designed to replace MD5, but inconsistent vendor support forces operators to either fragment authentication strategies or default to MD5. The BCP should recommend TCP-AO for new deployments while acknowledging the MD5 transition path. Both gaps affect how operators meet the stated requirements. Happy to propose specific text if helpful. Best regards,Niranjan Sharma On Mon, Feb 9, 2026 at 3:28 PM Niranjan Sharma <[email protected]> wrote: > Hi Nick, > > I agree and appreciate the feedback. Please let me know if you have any > questions for me. > > Best regards, > > Niranjan Kumar Sharma > > On Mon, Feb 9, 2026 at 2:48 PM Nick Hilliard <[email protected]> wrote: > >> Niranjan, >> >> I'd be happy to discuss observations which are not the output from >> generative AI. >> >> >> Nick >> >> >> Niranjan Sharma wrote on 07/02/2026 00:23: >> >> Hello, I reviewed draft-ietf-grow-bgpopsecupd-12 >> <https://datatracker.ietf.org/doc/draft-ietf-grow-bgpopsecupd/>(Updated >> BGP Operations and Security). To ensure this BCP serves as a durable >> reference for modern BGP security architecture, I submit the following >> comments regarding RPKI integration and session authentication: >> >> *1. RPKI-ROV and ASPA Cross-Referencing* >> >> RFC 7454 predates widespread RPKI-ROV deployment. Given that Route Origin >> Validation (RFC 6811) is now operationally deployed by major transit >> providers and IXPs, this BCP should include guidance on ROV deployment >> policy — specifically whether RPKI-Invalid routes should be dropped or >> deprioritized, and the operational tradeoffs of each approach. >> >> Additionally, the relationship between IRR-based prefix filtering (which >> RFC 7454 relied on heavily) and RPKI should be clarified: are they >> complementary, or should RPKI supersede IRR where available? >> >> The companion ASPA verification work >> (draft-ietf-sidrops-aspa-verification) should also be referenced, at >> minimum informatively, as an emerging mechanism for AS_PATH security that >> complements ROV. >> >> A BGP security BCP published in 2025 that omits RPKI-ROV leaves a gap >> that will immediately date the document. Operators will look to this BCP as >> the authoritative reference — it should reflect the current state of the >> art. >> >> *2. BGP Session Authentication: TCP-AO vs. MD5* >> >> RFC 7454 recommended TCP MD5 (RFC 2385) for session authentication. >> TCP-AO (RFC 5925) was designed as its replacement, offering key rotation >> and algorithm agility. However, TCP-AO deployment remains limited due to >> inconsistent vendor support and complex key management in multi-vendor >> environments. >> >> The updated BCP should take a clear position: recommend TCP-AO for new >> deployments where supported, acknowledge MD5 as legacy but still prevalent, >> and provide practical migration guidance for operators in mixed >> environments. The absence of clear guidance here has a real cost — >> operators default to the path of least resistance, which today means MD5 or >> no session authentication at all. >> >> Sincerely, *Niranjan Kumar Sharma *Snowflake Inc >> >> IEEE Senior| CCS| IAENG| ISOC| OWASP >> https://www.linkedin.com/in/niranjan-kumar-sharma-bohra/ >> [email protected] >> >> >>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
