SIDROPS at IETF-120

Tuesday, July 23, 2024 15:30-17:00 Local Time in Canada (GMT-7)
Room: Plaza B

1) Agenda bashing and Chair's slides

Job: Need to be bit more orgnized while setting up the agenda
Russ: Ack, we'll put some process in place to better manage cfp

2) Tim Bruijnzeels - draft-timbru-sidrops-publication-server-bcp-02

Tim: pub server BCP
Tim: RFC 8181, different impact of outage compared to repos
RRDP:

• ensure deltas and snapshots are available before notification file
• Beware of bad feedback loop in case of all reverting to snapshots
• Usage of CDN recommended
  RSYNC:
• symlink to latest content
• deterministic timestamps

RIR / NIR pub server RECOMMENDED

• Use them if available

Expected for -01

• discuss some nasty corner cases
• document pub server restore scenarios

Some topics out of scope

Mic Line:
Ben Maddison: quotas out of scope in your previous slide, seems fairly
obvious to be in scope. Why ?
Tim: Not only that, other topics left also out of scope, you dont have
good ways to communicate some of these parameters in-band

Ben: ...missed that(carlos)...

Niklas Vogel: publication at the RIRs, is it the point of rpki to be
more centralized or good it bee good for others to operate pub servers
Tim: even you have centralized pub servers the keys are in held by
users, currently only pub in one place. Maybe in future other things can
be though of

Job: what we want is that pub servers are monitored and operated
appropiately, the less pub servers the better.

3) Alexander Azimov - ASPA documents update

... hard to understand for me...

ASPA Profile:
Experiment about processing many routers , does not affect profile doc

ASPA Verification:

• Sum of lengths up up and down ramp, less than N , then INVALID
• Measuring ramps

RTR Protocol

• all aspa documents are now afi agnostic
• modeling behaviour

Open Questions:

• security section

  • removed comment on ipv4 and ipv6 topologies

• rtr aspa pdu

  • do we need provider as count ? are there any disadvantages to
    moving it up

Are we ready to move on ? the spec is solid, are we ready to move on

MIC LINE
Nan Geng: rtr aspa pdu, ... feel do not need to change the position of
the Flags field in the ASPA pdu ...
AA: glad conversation kickstarted

Rudiger Volk: rewrites improved documents, after major re write , it is
expected that some work needed to fix small things, actually i think we
need to go through a little bit of details. Security considerations
needs more work. I'm likely to provide some feedback

Job: I feel we are almost ready. Our focus should be the RTR document,
five topics need attention, in particular ordering data within the PDU.
Randy, Rob, if you need help, i'm happy to chip in. Do not rush , fix
open issues

Tim Bruijnzeels: thank you AA, similar to job my feeling we are close.
Please resolve issues that need to be resolved.

4) Sofía Silva Berenguer - NRO RPKI Program

slide 2, What is your role in the routing system ?
s3, provide input please
s4, a short intro about me
s5, about the nro, number resource organization
s6, intro to the nro rpki programme
s7, why is important, there is diversity / divergence among the rirs
s8, differences in services provides, in how services are provided,
differences in ui , api signatures
s10, are those differences hindering rpki adoption in some way
s11, purpose and expeced specific outcomes, including improving
resilience and security and keeping the communities informed
s12, how would a single global rpki system look like ? problem statement
around single TA,
s13, who is we ?
s14, pointers to further information
s15, please reach of to rpki_program@nro.net

MIC LINE:
Randy Bush: how do you measure rpki adoption ? is not just about how
much is published?
Sofia: i'm not measuring myself, using what's out there

Ben Maddison: i think this is really useful, informal coord has happened
but having some more formal coord is good. One comment, it is to ack
that there is disconnect between experts. More important, look at the
current TA structure , current is fragile

Sofia: thanks for that, please provide feedback for the program

5) Job Snijders - draft-spaghetti-sidrops-rpki-crl-numbers and ⁠draft-spaghetti-sidrops-rpki-ta-tiebreaker

CRL-Numbers:

• athene pointed to to crl numbers compliance issues
• tom harrison from apnic, concern reg crl numbers field maxing out

• what a crl rpki looks like

  • crl number is non critical ex
  • monotically increasing seq number for a given scope

• manifest

  • manifestNumber is the same as the crl number
  • crl numbers are purposeless for the rpki, because a well formed
    manifest contains a one single entry for a CRL. The named entry
    contains a hash. RPs can decide which crl to use just by using
    this information in the manifest

• Solves case 1: maxing out crl number

  • both numbers can max out , for manifestNumber theres is already
    a draft to solve

• Solves case 2: using the crl number is complicated

  • the crl number has no constructive purpose
  • ignoring the crl number actually fixes how the failed fetch
    mechanism should work

• Next steps

  • rp developers please check what you are doing with crl numbers
  • wg adoption?

MIC LINE:
Q Misell: why are you checking the crl at all ?
Job: historical reasons, use x.509 profiles as-is. Removing the
extension makes the RPKI no longer compliant with existing x509
profiles.

Q Misell: it may be nicer to say now rp ignores, in the future CA stop
including them
Job: reasonable converstaion to have

Bob Beck: are we certain there are no implementations doing other types
of fetches
Job: to my knowledge, all implementations use the manifest as a starting
point and not the AIA

Ben Maddison: there is disagreement among authors,

... cross talk among line and participants ...

Job: let's take it to the hallway

TIE BREAKING TAs

• RPs periodically fetch TA certs from well known remote locations
• Verify using tal
• on failure, there is an option to use local cached copy

• What if older TA issuances are accidentally re-introduced ?

  • TAs still valid that are out there and have stale information
  • analisis of older tas visible

• move towards shorted lived TA certificates

• already some agility in place

• on the rp side, how to distinguish among TA replay

  • tricky , no current extensions acutally help much
  • use not before and not after
  • the source of the object can also be used

• Proposed tiebreaking scheme

  • for manifests, easy , take largest number
  • for certificates, more steps are needed (see slide)

• Justification:

  • notBefore , rps should prefer shorter validity periods
  • prefer fresh

• next steps

  • please take a look

Chairs: please provide discussion on the mailing list

6) Yu Fu/Nan Geng - draft-fu-sidrops-enhanced-slurm-filter

Only fetch what is needed from the network , for example only ipv6 data

Improves storage in routers , introduce some unnecesary steps
Discussion:

• does a network require all types of rpky data ?
• whether sync data not required ?
• which solution is best ?

MIC LINE
Jeffrey Haas: filtering data could be potentially useful, when rpki is
being fed slowly you can get some thrash in the routers. Secod thing is
to pvovide via protocol priorization.

7) Weiqiang Cheng - draft-cheng-sidrops-consistency-forwarding-00

Consistency routing and forwarding.
Causes of inconsistency.
Risks of inconsistencies.
Consistency in inter domain routing and forwarding.
How to keep consistency:

• obtain deviation as paths
• advertise deviation path
  Use cases.
  Next steps

MIC LINE:

8) Chongfeng Xie/Xing Li - draft-xie-sidrops-moa-profile

Overview, new digitally signed object for rpki used for mapping
announcements in underlay ipv6 networks
Scenario

• ipv4 over ipv6 underlay (see v6ops draft)
  Problem statement:
  MOA:
• signed binding between an ipv4 address block and its right ipv6
  prefix that is allowed to be declared in bgp announcements

... missing ...

Chairs: lets continue discussion on list

9) Qi LI - draft-li-sidrops-rpki-moasgroup-00

Masurement, limits in routing origin leave moas vulnerable
problem analysis
proposal : signed moas groups
smg ASSERT a group of ASes intended to collaboratively announce an IP
prefix
issue an SMG based on aggregate signature
smg validation
interaction between roa-rov and smg-rov

• no changes to roa rov, smg designed to augment
  performance evaluation
  Conclusions

10) Zhuotao Liu - draft-wang-sidrops-fcbgp-protocol

FC BGP Basics

• adopts per pathlet validation scheme for path validation in BGP
  Feedback since ietf 119
  Changes from v0 to v1
  fc-bgp treats partial deployability as a first class citizen
  rpki / bgpsec cert / key
  processing bgp updates
  route selection policies
  as confedereation
  route servers

11) Lancheng Qin - draft-li-sidrops-bicone-sav

Chairs: no time for all slides , please provide highlights as we are way
over time

Background, goal, create ingress SAV blocklist filters based on roas,
aspas
comments received since ietf 119
prefixes in allowlists / blocklists
recommendations
request for adoption