SIDR Monday morning 2009-10-09 Sandy Murphy and Goeff Huston Minutes by Paul Hoffman Material from the slides is not reproduced here Blue sheets and groovy RFID thing were passed around Agenda additions Sriram has some additional use cases, if we have time WG Last Call deadline is next Monday Please comment on the list, we need more feeling about consensus Current drafts were presented RPKI Architecture - draft-ietf-sidr-arch-09.txt Matt Lepinski Discussion about recommendation about query frequency Probably doesn't belong in the architecture document Turns out to be contentious Possible operational considerations document Randy Bush: MTTR was correct in the breakup of chains In WG LC CP - draft-ietf-sidr-cp-07.txt Stephen Kent [[[ Scribe note: Maybe also covered CPS-IR - draft-ietf-sidr-cps-irs-04.txt CPS-ISP - draft-ietf-sidr-cps-isp-03.txt but can't tell ]]] Have a bunch of changes to be made Forgot to make some changes that were agreed to Will say "BCP" instead of "Informational" In WG LC, but knows that there will be another draft with the known issues ROA Format - draft-ietf-sidr-roa-format-06.txt Matt Lepinski Now points to the algorithms document Rob Austein: the order of the checking should not be mandated Maybe suggest an order Manifests - draft-ietf-sidr-rpki-manifests-05.txt Matt Lepinski Gave overview of why we want manifests Wants more review Authors know of no outstanding issues Certificate Profile - draft-ietf-sidr-res-certs-17.txt George Michaelson CRL reason codes had little interest from the WG Do we have to think about algorithm transition? Rob: algorithm transition just looks like key roll Steve Kent: what Rob said Repository Structure - draft-ietf-sidr-repos-struct-03.txt George Michaelson Suggestions, not prescriptive statement ROA Validation - draft-ietf-sidr-roa-validation-03.txt George Michaelson No recommendations about how it should be done in BGP Sandy Murphy: Is that one sentence a recommendation? George: will review that wording Sandy: didn't put this through WG LC yet, on purpose Lots of different questions, including IPR Should the validation scheme be with an implementation? John Scudder: This is informational There is a need for a standards track document telling BGP implementers what to do If this was the only draft, that is not a good thing because it is not helpful to the implementer George: Similar to previous question on PKIX Doesn't feel comfortable telling people what will work Agrees that something normative is needed John: Do you have concern about the two drafts having a lot of overlap? George: Has issues that needs to be thought about Russ White: Need to be careful with any presecriptive document Customers want policy to be left on the router We need to be sure that we understand where the line between is drawn Rüdiger Volk: Objects to the claim that none of the customers want an external server Geoff: Can a standards track point to an informational doc? Russ Housley: Yes, with a few extra steps Russ White: Lots of concern that off-boxes would would decide the polic Chris Liljenstrolpe: Off-box process should be providing further input to BGP best path George: Sees reason to have differentiation and therefore more than one documents TA - draft-ietf-sidr-ta-02.txt George Michaelson Not much left to do Provisioning Protocol - draft-ietf-sidr-rescerts-provisioning-05.txt Byron Ellacott In WG LC, couple of identified issues Rob: HTTPS does not provide replay protection Might need timestamps Thinks there is at one real replay attack If the attacker can capture the PKCS10 attack, might be able to do something with it Might be plausible based on whether the keys are kept online or offline The consequence is a key compromise of their private keys for the RPKI Can ask for a reissued key Robert Kisteleki: If the parent remembers that the key has been reovked, it can be prevented in the protocol Not a use of an old certificate, it's getting a new cert Steve Kent: Why would one set of key material be protected than another Let's be precise in what is being offered TLS is hiding the details Will provide pictures RPKI Algorithms - draft-ietf-sidr-rpki-algs-00.txt Geoff Huston Biggest question is handling multiple algorithms at the same time Three choices Not the same as key rollover Rollover overwrites, is not parallel Algorithm change needs both being valid If we go down the path of parallel issuance, we need to know *how* they go parallel Likes "punt" the best Rob: Only agreed to the first two thirds Doesn't like option C Tim Polk: Transition from one algoirhtm means all the relying parties can do the new one Just doesn't work Need a period of time where are using both Rob: We already use hashes of public keys, so that may save us We could require key changes when the transition happens George: Could make a requirement for top-down This would make the size of the repository smaller Paul Hoffman: Don't assume that the top will want to double-sign just because the ones below do Rogue Gagliano: Any transition will cause a lot of problems and question Geoff: There will be tradeoffs regardless Steve Kent: We are talking alogithm transitions that happen by a change to the CP Can only occur when the second set of algorithms have already been defined Will take this to the mailing list before revising the draft Will take it back to the Security ADs and Secdir Sandy: Security ADs: how to proceed? Tim Polk: Other drafts can be moved forward Would like to see a second algorithm specified now; maybe ECDSA Would also like to see the transition described Wants to see at least -00s before the current stuff can be RFCs Wants more than just a promise to start Adrian Farrel: Is the new stuff normative? Geoff: Noted Sandy: Implementation report? Adrian: Not required, but would be nice Ross Callon: Was required in years past, but not now. Now new stuff is small enhancements Rob: Wants algorithms from OpenSSL Paul: ECDSA is in OpenSSL Update on Use Cases - draft-manderson-sidr-usecases-01.txt Terry Manderson Wants more use cases? Steve Kent: Problem with definitions No introduction to how the use cases were chosen Maybe a decision tree Danny McPherson: Agrees with Steve Would like to see a taxonomy At what point would we bring path validation into scope? Sandy: Still thinking, but wants to hear from Routing ADs Ross: Finish complex work first Wants to hear whether there is consensus to work on path validation at all Sam Weiler: Thanks for route announcements that should not be validated Geoff: please volunteer if you want to see this as a WG item? Local TA Management Steve Kent Basic rule: the relying party is its own trust anchor Will later have a tool that can automate this That tool will show some complexities Danny: Trading autonomy for security What about conflict resolution What is the resolution model if there are conflicts? Steve: you will get warning messages, but that's it Concern about naive relying parties Andre Robachevsky: Doesn't understand the use case of protecting a particular entity Steve: Want to not be fooled into misrouting You are not protecting other parties from misrouting If you have influence, you can have a bigger influence Sandy: Aware that this only for local power Gives you the power to shoot yourself in the foot Is wary of people trading these local decisions around Don't mke it too easy Rüdiger: Fears that there is a perception that everyone has to do this Could negatively affect those who know how to use this Would hate to see this become a generally used feature Randy: RFC 1918 space is the common use Would be nice to have 1918 space example that is safe Rob: In the 1918 space, there is a clear partition Needing a separate trust anchor to do it Parallel characterization to .mil looking at IANA Spoke against this in Stockholm, now retracts Andre: Still uncomfortable because "bar" case is so limited Thinks that it is only useful if you have influence over other Steve: Depends on what you mean by "protection" It is about your own scope RPKI Operators Roundtable Report and Discussion John Schnizlein ISOC meeting for Securing Routing Information Was not just about RPKI Succeeded because ISPs did hard work and exposed good info Gregory Lebovitz: Resolve vs. assuage on the differences Terry: BOA draft is not dead yet, but depends on the definition of the ROA Did not want to subvert the purpose of this WG Rob: What is a "neighbor"? Jared Mauch: Some service provide the capability to blackhole an origin, not just a destination Randy: When an originator puts a route in, it is to protect themselves George: Thank you for holding this (general applause) Wes George: Router behavior in coming up and convergence Some Remarks on ISOC Roundtable Rüdiger Volk Most operators there do show up at IETF Ran out of time Sandy had a long list of things that we didn't get to talk about All of them will be on the list