Deploying Validation ReconsideredGeorge Michaelson ggm@apnic.net
Tim Bruijnzeels tim@opennetlabs.nl

1Problem Statement• Deployment requires three things in coordination [*]1. Available code to sign and validate objects under thenew OID
2. Agreement to move to the new model by relying parties
and signers
3. A decision about how to move––

Either it’s like a flag-day as in RFC6916
Or it’s a mixed-mode operation in one tree[*] In no implied order2

Available code to sign and verify• Code changes for signers are minimal– If it’s a flag-day. Its “one line” to move to the new OID in the code
which mints certificates with the private key– If it’s mixed-mode, it’s the option to choose the OID, and UI or
protocol changes to support specification of which OID is to be usedin the specific moment of signing• Code changes for verifiers are less easy
– Can minimally change to permit new OID, for ‘fully covered’ case
• Change to handle oversign properly requires more work
– Parse out and hold the valids, flag the overclaim, move on– Transition moments through intermediate objects. New data structures…

3

Available code (continued)• None of the deployed CA/Signers appears ready yet– but its trivial• (I believe) RIPE Validator team has at least discussed
modified validation and may have code in test
• RPSTIR, Dragon Research not believed to have code
• We have an explicit dependency in the APNIC region ondragon s/w– 3-4 NIR using Dragon for signing (JPNIC, CNNIC in deployment
or near, TWNIC, IDNIC in internal test)

4Agreement to move to the new model by
relying parties and signers• There has been no active engagement to discuss atimeline.
• We (the RIR) wish to propose July 2019 as a ”flag day”
to give one year to prepare to migrate• We want to go into the *-NOG and other forums to seek
consensus to move from operators and related parties
5

What kind of deployment?
• “there can only be one” (OID) demands flag day– Analogous to RFC6916– All or nothing, but simple– Transition happens through a staged window of dual state• “we can mix it up”– Operate mixed-mode, signing CA determines setting over child– RIRs seek flag-day to release TAL which bear the new OID– Still requires acceptance of the new OID to deploy TAL so still
carries the need for consensus in code and userbase

6Tri-partite deployment deadlock• Can’t move without code
• Can’t move without consent/agreement by RPs and Cas• Can’t deploy new TAL without either of the above7

Who is “in the system” as RPs?
• 178 unique ASNs over 302 IP addresses in rsync• 39 unique ASNs over 65 IP addresses in rrdp
– Of which half are demonstrably RIPE code (User Agent Strings)– All of whom also appear in Rsync logs, fetching CA under TAL• Allowing for “don’t upgrade”, possibly more using RIPE
code but certainly not most• The majority of seen clients are probably using Dragon
Research or RPSTIR
8CCCC

CC

CC

38

US23

DE

14RU

12NL

11JP

9FR

6CN

5ZA

5GB

5CH

3CZ

3CA

2UA

2TH

2SE

2PT

2NZ

2NO

2MU

2LU

2IT

2HU

2GR

2BG

2AU

2AT

1ZZ

1VN

1UY

1TW

1SK

1SI

1RS

1RO

1QA

1PL

1MY

1MV

1MN

1MG1LV

1KR1ID

1EC

1CY1CR

1BT

1BR

1BE

1AR

1AM
9

It doesn’t get easier by waiting• Present at *NOG to seek consensus to deploy July 2019
• As it stands, we’re talking a moment of change for < 500entities (more downstream affected parties, IP coverage notmeasured)– It’s already a distributed problem• Flag day move to new OID is logistically simpler– Hack: simply recognize but reject overclaim == current model– In either case, deployment of TAL with new OID would be fatal toRP if validators don’t implement

10