Markdown Version | Session Recording

Session Date/Time: 27 Jul 2022 14:00

sidrops

Summary

The sidrops session featured presentations and discussions on four key topics: enhancing Source Address Validation (SAV) with a new approach called BAR-SAV, a proposal for a Trust Anchor Key (TAK) object to simplify RPKI Trust Anchor key rollovers, a method for RPKI repository migration based on key rollovers, and significant updates to the ASPA (AS Path Attestation) profile and verification documents, including a contentious debate on the ASPA object format. Discussions highlighted the challenges of RPKI adoption, operational complexities, and the need for practical, deployable solutions.

Key Discussion Points

Enhancing Source Address Validation (SAV) with BAR-SAV (Igor Lubachev)

• Problem Statement: Current SAV mechanisms (e.g., RFC 8704) are insufficient, leading to low adoption (around 15% of networks for 7 years). They primarily infer data plane forwarding information from BGP signals not designed for it, lacking sufficient signal.
• BAR-SAV Proposal: Augment existing BGP messages with ASPA and ROA information.
  • Strictly improves on RFC 8704 by looking at the entire AS path rather than just the origin AS.
  • Requires no new protocols or changes to existing ones, aiming for easier adoption and immediate benefits for early deployers.
  • Works on both peer and customer links.
  • Mechanism: Two phases:
    1. Discover the "customer cone" using ASPA (when available) and BGP AS paths (iteratively).
    2. Identify prefixes owned by these customer cone ASNs using ROA information and BGP announcements (where origin AS is in the customer cone).
• Use Cases:
  • Direct Server Return (DSR): BAR-SAV can help validate packets sourced from an IP prefix "owned" by an edge CDN AS (S2) even if S2 doesn't advertise that prefix via BGP, as long as a ROA attests S2's ownership.
  • Route Leak Detection: ASPA validation helps BAR-SAV construct a correct customer cone, thus rejecting leaked routes.
• Discussion:
  • iBGP cases: Request to examine how BAR-SAV would apply to iBGP cases, beyond the presented eBGP examples.
  • Economic Cost: Implementing SAV often requires burning FIB resources, adding cost without directly selling "bits." The speaker acknowledged that economics is a driver but emphasized the need for economical solutions, especially for smaller networks.
  • RPKI Fail-Open Semantics: Using RPKI objects (ROAs/ASPA) for SAV might break their traditional fail-open semantics. If RPKI data is temporarily unavailable or incomplete, it could lead to blocking legitimate traffic. This suggests a need for careful consideration of object semantics or defining new purpose-built objects.
  • ASPA Pruning: Using ASPA to prune the customer cone could be problematic. A customer might use a transit link outbound without intending to advertise inbound reachability, potentially leading to valid return traffic being dropped. This highlights a potential mismatch between policy directionality and perceived connectivity.
  • Data Consistency/Availability: Concerns about the reliability of RPKI publication points and partial cache failures. Suggestions for caching mechanisms (e.g., 24-48 hour validity) to mitigate temporary unavailability.
  • Policy vs. Connectivity: A fundamental concern that policy directionality in AS paths might not be isomorphic to straight connectivity, leading to filters that are too enthusiastic and discard valid packets. While BAR-SAV aims to expand the permissive list, it may not achieve perfection.
  • Wider Problem: Attacks can come from peers, and the customer cone concept needs to accurately reflect these relationships, including regionalized peering and partial transit services.

Trust Anchor Key (TAK) Object for RPKI Rollover (Tom Harrison)

• Goal: Simplify RPKI Trust Anchor key rollover (main goal) and update root CA certificate URLs (secondary goal), reducing reliance on specific HSM vendors.
• Current Challenges: Manual distribution of new TA files, client updates, and custom TA update processes.
• TAK Proposal: Define a new signed object to signal TA key/root CA certificate URL changes in-band.
• Comparison with Other Approaches:
  • RFC 4021 (CMP): Involves cross-signing old/new keys and repository distribution, but assumes out-of-band TA distribution and clients receiving certs from other sources, which differs from RPKI's in-band, repository-centric model.
  • RFC 8649 (Hash of Root Key): Includes hash of upcoming key in TA certificate. Issues include potential RP ignored extensions and inability to transition from previous TAL data if old cert is replaced.
  • Web PKI: Relies on cross-certification and issuing new root CA certificates.
  • RFC 5011 (DNSSEC Updates): Introduced the concept of an "acceptance timer."
• Key Document Changes:
  • Acceptance Timer: Incorporated from RFC 5011 (30 days, arbitrary). A client must see the new key consistently for this period before updating its trust store. This mitigates risks of temporary key compromise allowing an attacker to transition clients to their controlled key.
  • Revoked Flag Removed: The revoked flag was removed as it didn't align with the common understanding of "revocation."
  • Predecessor Key Reference: TAK object now includes a reference to the predecessor key for better verification.
  • TA Certificate URL Reuse: Advice for TAs to reuse previous TA certificate URLs for new keys once old key is no longer maintained, to aid client transition.
• Validator Currency: Analysis of validators connecting to NLnet Labs RPKI services shows a significant portion (15-50%) are more than 12 months old, suggesting a concerted effort will be needed to get people onto versions supporting TAK objects for practical reliance.
• Next Steps: Address feedback, update prototype code, and continue development.

RPKI Repository Migration (Tim Bruijnzeels)

• Context: Discussion on different RPKI publication models, from RIR-provided services to dedicated CAs and third-party content providers. Hosted repositories simplify operation and enable wider RPKI adoption.
• Problem: How to migrate from one RPKI repository to another, especially when running one's own.
• Proposal: Leverage the existing key rollover process (new key pair, new certificate, staging, activation, old key removal) for repository migration.
  • During key activation, instead of publishing everything under the new key and immediately removing from the old key, keep objects in both locations for some time to avoid non-atomic updates.
• Challenges:
  • Relying parties might see no objects, both objects, or only the new objects during the transition due to fetching from two different locations.
  • Authority Information Access (AIA) pointers changing might trigger issues in some RP tools.
  • The current provisioning protocol (RFC 6492) and its responses might need re-evaluation if the publication URI changes.
• Call for Action: The presenter seeks group consensus on documenting and standardizing this repository migration process.
• Feedback: Strong support from Chris Morrow to standardize and document the migration process.

ASPA Document Update (Alexander Azimov)

ASPA Profile Document

• Previous (v7): ASPA object defined as customer AS with its provider list, expecting separate objects for IPv4 and IPv6.
• Current (v8): ASPA object now carries a "list of lists," where each item contains a list of providers and may contain an address family (AFI). The idea is to allow a single object for both IPv4 and IPv6 policies, even when they differ.
• Discussion - v7 vs. v8 Format:
  • Arguments for v8 (single object):
    • Fewer RPKI objects for RPs to process.
    • Overwhelmingly common case is same/similar transits for both AFIs.
    • Less surprising to operators if the on-wire format aligns with a mental model of shared topology.
    • Existing implementations (NLnet Labs, others) are already based on v8, rolling back would be significant work.
    • Translation from ASN.1 to RTR format can happen at the RP (where compute is cheap), similar to ROAs with multiple prefixes.
  • Arguments against v8 (preference for v7 simplicity):
    • Increased complexity in the object content (semantic overlaps, need for unions, difficult test cases).
    • Potential for complicated debugging when interacting with routers (e.g., show asp commands per AFI).
    • V4 and V6 topologies are not always congruent and are not guaranteed to remain so, making the "common case" argument potentially temporary.
    • Concern that increased complexity could delay deployment and experience with ASPA.
    • Strong preference to keep complexity north of the router, with the router expecting separate v4/v6 data.
    • Randy Bush: Router separates v4/v6 naturally; "what's presented to the user and the GUI is arbitrary in either of these schemes."
  • Outcome: No consensus was reached. The discussion highlighted the trade-off between on-wire conciseness and operational/implementation complexity. It was suggested to continue the debate on the mailing list.

ASPA Verification Document

• Generalization: Updates devoted to generalizing upstream and downstream verification procedures.
• New Index Types:
  • invalid index: minimal index for which an AS in the path is not authorized to transit.
  • reversed embedded index: calculated similarly but for the reverse AS path.
  • These indexes help detect problems for prefixes from providers, route servers, and peers.
• Leak Detection: Simple rules defined based on these indexes: if invalid index is less than the AS path length, it's a leak (for routes from provider/peer/IX). For routes from providers, if the sum of invalid indexes is less than AS path length, it's invalid.
• Route Servers: If a route server is not transparent, it must be added to the provider list in ASPA, enabling standard upstream verification for all parties at an IX.
• Unknown Paths:
  • Definition: A path that may have been leaked, indicating an AS in the upstream segment without an ASPA record.
  • Detection: Uses unknown index (first AS in upstream segment without ASPA record) and reverse unknown index. A path may be leaked if there's "enough space" for a leak (e.g., unknown index < AS path length).
• AS-Sets: Ongoing discussion to consistently mark routes with AS-sets as invalid, regardless of their position in the path.
• Call for Action: Volunteers needed to read the document and code the ASPA logic for specification checking.
• Discussion:
  • AS0 ASPA: Reiteration that Tier-1 providers and non-transparent IXes/route servers should register an AS0 ASPA.
  • Route Server Clients: Discussion on whether a transit provider acting as a route server client should include the route server's AS in its ASPA, even if the route server is transparent. The draft currently implies they should if non-transparent. Randy Bush strongly opposed adding complexity due to non-standard behavior of IXes putting their AS in the path, urging to reduce complexity.
  • Upstream verification for RS clients: Sriram noted potential issues with this, requiring further discussion.

Decisions and Action Items

• ASPA Object Format: No decision made during the meeting on whether to adopt version 7 or version 8 of the ASPA profile document.
• ASPA Profile & Verification Documents: Alexander Azimov to summarize the mailing list discussion on ASPA object format. Volunteers requested to read the verification document and assist with coding the ASPA logic.
• Repository Migration: Tim Bruijnzeels to write to the mailing list seeking further feedback and support for standardizing the repository migration process.
• BAR-SAV: Discussion points raised (iBGP, fail-open, policy vs. connectivity, customer cone in peering) need further exploration, likely on the mailing list.
• TAK Object: Feedback needed on the document, prototype code to be updated.

Next Steps

• Continue discussion on the ASPA profile document's object format (v7 vs. v8) on the mailing list.
• Alexander Azimov to incorporate feedback into the ASPA verification document and seek volunteers.
• Tim Bruijnzeels to draft a proposal for standardizing RPKI repository migration and circulate it on the mailing list.
• Further discussions and refinement of BAR-SAV concepts, especially regarding operational challenges and edge cases, are expected to continue on the mailing list.
• Feedback for the TAK object document is encouraged.
• The chairs suggested an intermediate interim meeting might be necessary before the next IETF meeting in London if significant progress is made on these topics.