**Session Date/Time:** 10 Nov 2022 13:00

# sidrops

## Summary

The SIDROPS working group meeting covered several important topics, including experiences implementing RPKI protocols, updates on source address validation algorithms (Barsev), trust anchor key objects (TAK), updates on ASPA path verification and updates to the ROA profile. Discussions focused on improving protocol specifications, addressing implementation challenges, and ensuring compatibility across the RPKI ecosystem.

## Key Discussion Points

*   **Challenges and Lessons Learned in Deploying RPKI Protocols (Tim):**
    *   CMS message definitions are loosely specified, leading to interoperability issues.
    *   Replay protection mechanisms need improvement.
    *   Identity key rollover is a scaling challenge.
    *   Consider algorithm agility and impact on child CAs.
    *   Error messages and rate limiting in the provisioning protocol require attention.
    *   Concerns about publication server hygiene and potential rejection of valid objects.
*   **Update on Barsev (Igor & Sriram):**
    *   Barsev augments BGP-based source address validation with RPKI data.
    *   Addressing feedback on operations and management considerations.
    *   Debate on creating Sev-specific RPKI objects vs. using existing ROA/ASPA data.
    *   Need for more implementation guidelines, especially regarding failure handling (fail open).
    *   Importance of ASPA adoption for Sev.
    *   Concerns were raised about Akamai's internal routing use cases.
*   **Update on TAK (Tom):**
    *   TAK objects simplify key rollover for trust anchors.
    *   Semi-automatic transition for relying parties that can't support automatic updates.
    *   Discussions on clarifying text in the signed object registry at IANA.
    *   Debate on whether to include information around temporary TA compromise or certified destruction of key pair material.
*   **Update on ASPA Path Verification (Sriram):**
    *   Corrections and refinements to the ASPA path verification algorithm.
    *   AS set handling: presence of AS set anywhere in the path invalidates it.
    *   Route server AS: removal of the rsasn from the AS path.
    *   Clarification on applicable address families (IPv4/IPv6 unicast).
    *   Treatment of AS confederations.
    *   Focus on improving readability and notation of algorithm description.
*   **Update on RFC 6482 bis (Job):**
    *   Best effort to update the ROA profile specification.
    *   Clarify that AS identifiers should not be present in ROAs.
    *   Strengthen ASN.1 notation with constraints.
    *   Provide an example RoA payload.
    *   Maintain full compatibility with the existing ecosystem.
    *   Detailed discussions about constrains on ASN1 elements.

## Decisions and Action Items

*   **Tim:** Create a problem statement and requirements document regarding RPKI provisioning and publication protocols, including potential improvements and areas of consensus.
*   **Tim:** Draft an informational document describing temporary measures for identity key rollover, if necessary, with external auditing and working group review.
*   **Igor:** Address feedback received on Barsev, particularly regarding implementation guidelines, staleness, object expiration, and potential inconsistency with existing RPKI validation principles.
*   **Igor/Sriram:** Address concerns related to AS object validation for dark origins.
*   **Tom:** Update the TAK draft to address uncontentious suggestions, consolidate server-side implementation process information, and clarify the purpose of the acceptance timer.
*   **Tom:** Consider including the "temporary TA compromise" text as an appendix.
*   **Sriram:** Update ASPA path verification draft to improve readability and notation of the algorithm description, incorporating suggestions from Claudio. Publish version 12 in a few weeks.
*   **Job:** Continue refining RFC 6482 bis to address all known loose ends and inconsistencies before proposing it for working group last call.

## Next Steps

*   Mailing list discussions for further feedback and consensus on the proposed changes.
*   Implementations and testing of updated protocols and specifications.
*   Working group last call for mature drafts.
*   IETF review and publication of updated RFCs.