: Secure Inter-Domain Routing WG (sidr) : IETF 96 - Berlin, Germany : : CHAIR(s): Sandra Murphy sandy at tislabs.com : Chris Morrow morrowc at ops-netman.net : : ===================================================== : : : : AGENDA: : : THURSDAY, July 21, 2016 : 1000-1230 Morning Session I Bellevue : : : : 1) Administrivia & Draft status 1000-1010 : : Presenter: Chairs : : - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html : - WG Resources: http://tools.ietf.org/wg/sidr/ : - Minute taker? : - Jabber Scribe? : - Blue Sheets : - Agenda Bashing : : 2) Existing WG Drafts : : a) RRDP and HTTPS 1010-1025 : RPKI Repository Delta Protocol : https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ : https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-03 : : Presenter: Tim Bruijnzeels Rob: Mine https in TAL; trivial implementation with Python/OpenSSL. Tim: Java makes it painful but there is a way to do it, while we have not done it; fall back to accept eveything strategy. : : b) Updates to ROA and BGPSec Router Certificate profiles 1025-1045 : RPKI Validation Reconsidered : https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-validation-reconsidered/ : https://tools.ietf.org/html/draft-ietf-sidr-rpki-validation-reconsidered-06 : : Presenter: Tim Bruijnzeels Tim: Good idea to issue separate ROA for each prefix. Tim: "Intent was to break relying parties... but with plenty of time to update relying party software so it wouldn't ever break in practice." Rob: It is a protocol change (so, agreeing). Also, there's a problem with OpenSSL (the libraries), has been for a decade. I want to make sure that once we've changed the semantics we don't trip over the broken library code. Backward compatibility == a ticking time bomb. Tim: I'll need help to identify OIDs that need to be updated and what refs need to be chased. I'm ok with the idea in principle but need help in practice. Also need to know that there is WG consensus for the general approach -- if you have an objection, please speak up. Sandy: In previous cases everyone has asked Russ to fix anything with "OID" in the sentence. Russ: I don't do that any more. IANA does it now. (Describes the usual early allocation process.) Still expert reviewer for registry. Tim: I knew that but we have lots of docs with refs to 3779, we need to validate all those and it's a lot of detail to get right. Russ: The OIDs we're discussing are in 3779. Doug: The other RIRs should also comment on whether they're comfortable with the plan. Tim: The specific dates on the timeline are just a strawman. We do need to finalize a timeline in the eventual doc. Andy N: All the RIRs are discussing the issue, and do support the idea. Rob: The CA side is a trivial change. Only real work is on the RP side... and the document changes. Tim: And delegated CAs (parent new/child old or vice-versa). Sandy (as WG member): Are we going to need to keep the trees distinct, or can we mix them? In terms of algo transition? I agree that has to be considered. Glad you changed thinking about EE certs. Ruediger: Don't say "ensure all RPs behave the same" when you mean "they use the same algorithm". Tim: Understood. That's what I meant. Rob: To Sandy, I think it works if for each object you obey the rules for the object when in mixed state. You may not get intended results, but you get consistent results. Sandy: I understand that. Reason for OID is to make difference in semantics clear, though. So mix in tree sounds... I'd have to think about semantics of validation-reconsidered -- are they a subset of the other. Other comment was about separate EE certs for distinct prefixes, I understand that's easy for 12/8 and 100/16 in same cert, can separate those, but in cases where you have a /16 and are carving a /18 out of that you can't do that as distinct certs. Tim: It's already best practice to ROA the announcements you're doing. Technically you're right but I don't think it's a huge issue. Sandy: ARIN i/f has org ID and whatnot, you click to certify all at once -- does that make it difficult for them to separate them out? Point being, different RIRs might have architectural complexity to do this. Tim: I think in case of ARIN, actual ROA is specced by the user, not the hosted system. As for us we automatically create the ROA. In ARIN's case, anybody could manually do it. Andy: Confirmed. Tim: It's a recommendation, not a mandate. Identify the risk and offer the option of separation to mitigate it. Sandy: Also I agree with you that more updates may need to be added to the header. Sean Turner: (for the chairs) since bgpsec-pki-profiles is through WGLC the authors are looking to be directed as to whether to incorporate the changes inspired by rpki-considered? Sandy: Since none of the changes are fundamental (they were already possible) it's OK. Sean: great I'll post away! Tim: In our (RIPE) case it is trivial to create separate ROAs. Sandy: We can end up with graph dependency problems between the two docs. Randy: I thought we'd agreed this doc would have in its boilerplate header what docs it modifies and updates. Sandy: We wanted to avoid the inclusion of anything in the PKI profiles that would make the PKI profiles rely normatively on this doc. Tim: To the chairs -- can this doc update the profile doc that's now in the queue? When it's published we'll have a RFC to cite, and this doc will just update it. If that makes the process easier, we can do that. Sandy: Will check with the AD when and if needed. Alvaro (RTG AD): Whatever you want. It's all good. You don't have to wait for an RFC number to put UPDATES in. Process will work. : : 3) Other Work, Not WG Drafts : : a) RPKI vs BGP Global Statistics 1045-1100 : : Presenter: Tim Bruijnzeels Focused on v4, not sure if v6 prefix span is a reasonable proxy for affected users, unlike v4. Lot of big players participating in France. Explains why a lot of address space is covered. Where adoption is low, seems to also correlate with low valid fraction. Sandy (WG member): what's the relevance of PI space to space covered by announcements? Tim: In our terminology these are orgs that have resources but aren't a RIPE member. Less contact with us so probably less likely to use RPKI. Tend to be smaller orgs, less network-oriented, smaller prefixes. Ruediger. Opposite of PI is Provider-Connected, in RIPE region, PI means (more or less) end users, tend to have small blocks, expertise and resources for RPKI are lower than for network operators who do it as a primary business. (Further comment regarding difference between difficulty of PI and PA to update DB because of authentication mechanism, I think I'm suggesting PI has a harder time doing it.) Tim: It's possible but yes, PI has a harder time. (Elided long description of RIPE auth mechanism.) Taiji (JPNIC): Japan is similar. 2000 address holders in PI. They have a web portal but don't necessarily know what AS is origin AS. : : b) Problem Statement and Considerations for ROA Mergence 1100-1112 : https://datatracker.ietf.org/doc/draft-yan-sidr-roa-mergence/ : https://tools.ietf.org/html/draft-yan-sidr-roa-mergence-00 : : Presenter: Yu Fu Approximately, 50% ROAs have single prefix and the other 50% have >=2. Avg # prefixes per ROA is about 7.6. Many prefixes in ROA imples that any change in the ROA causes much churn in RPKI and may impact BGP convergence. Randy: Thanks for teaching me a new word! "Mergence!" It is exactly the right word to have used. Randy: You are right. One prefix per ROA is the right operational thing to do. Multiple optimizes the wrong resource. There are 27 ROAs in the global RPKI with > 100 prefixes. Tim: Touched on this in validation-reconsidered. There we do recommend what you suggest. Might cover what you want, I hope so. Other thing, on one slide you mention that an announcement would be invalid if there were multiple pfx and one was not valid. Actually would be not-found, not invalid. Ruediger: AFAIK mfg ROAs is something no user of a CA actually does. AFAIK in multiple implementations, the CA user works with a frontend system and the CA implementation manufactures the ROAs from that. If you see something that looks weird, the CA front end software is at fault. Good news is a few points can be fixed to correct this. Ruediger: A surprising number of resource holders say "please do this ROA for my /16 and include all more-specifics down to /24" and then I see a long list of more-specifics that are already covered ALSO be explicitly configured. If you look at a current table from the beginning you'll see an example right away, another within a few pages of scroll. It's weird but not harmful. But what were they thinking? Rob: To RV's point, the approach we've taken for years in our implemenation is that's it's possible to do multiple prefixes but we don't make it easy. Our GUI doesn't do it. The CLI can be persuaded to do it, if you try hard enough. Default is one per ROA. Highest we are seeing is about 370 per ROA. Carlos, LACNIC: It's not possible to make general assertions about what GUI does. LACNIC GUI will let you do whatever. It will suggest you pack, will let you unpack if you want. Tim, RIPE NCC: We do bundle, but we're happy to change that. Will make our code easier, glad to do it. : : c) RPKI Deployment Considerations: 1112-1125 : Problem Analysis and Alternative Solutions : https://datatracker.ietf.org/doc/draft-lee-sidr-rpki-deployment/ : https://tools.ietf.org/html/draft-lee-sidr-rpki-deployment-02 : : Presenter: Yu Fu Doug Montgomery: The same comment Tim made earlier. You want be careful about "Invalid". Quite often it would be "Not Found / Unknown" rather than Invalid unless there were specifc actions that cause specifc ROA changes. : Tim: Regarding call for adoption, I think it's good for you, if you see concerns, to bring that up. Good to discuss. For many of these issues, there's been an excess of discussion. Many of these things have solutions. In present form I don't think it's ready for adoption. That doesn't mean we can't talk about it, I hope you see the difference. WG adoption however, implies we agree there is a problem and agree needs a new solution developed. Yu Fu: Question, do you think this work makes sense/is meaningful? Tim: For example, scale of repo, already in RRDP doc. Not sure why we need another doc for it. We can discuss it of course. YF: Information draft for guidance for deployment. Do you think there is a place for RPKI deployment drafts? Tim: Not sure how to make myself better understood. There are a lot of issues you touch on, it's fine that you raise them, but I would prefer to discuss them as a non-WG doc. YF: Thank you. Randy Bush: The word that frames this is "guidance", RIPE and CNNIC have seen issues with deployment. Want to communicate them. Not sure that's strong enough for BCP, but informational doc framed as "best hacking practice", I can live with that. Ruediger: Agree. We haven't yet figured out how to group the problems. So I agree with some of Tim's concerns. Operational concerns and guidance are needed, this is a good contribution. I don't think we are in a state where we feel this is the right grouping of problems to publish. Doug: Don't we have OV operations doc? Sandy: Yes, we do Doug: Distributed system; linkages between components fail. Take the OV operations doc and see of enough is said there about it. If not, revise the doc and see if issues are addressed and recommendations enhanced there. Many of these have been discussed for a long time. Tim: I have no issue w/ a guidance doc, I just don't think this doc is in that state. Let's have the discussion, see what remains to determine what should go in a general document. This is a good initiative, just don't think it's in a state where it's ready to be a general document. YF: Thanks. Randy: Doug, I can't think of anything we haven't discussed repeatedly. There are two religions about doco acceptance by WG. For example IDR, the document must be perfect before adopted, then wait for two implementations. Other, that I learned as a child, this is something we want to work on, doco gives us some place to discuss. It's a placeholder. Sandy (WG member): some of the issues you raise sound related to adverse actions draft (slide 16/19, CAs revoking certs). Have you encountered this issue (CA revocation improperly) in deployment? Or is this a theoretical? IMO it's been built in deliberatly from the beginning. So what am I supposed to do with the observation? How am I supposed to act on it? YF: It could happen. Sandy: Have you experienced it? YF: Testbed. Ruediger: Insistence on observed problems is a bit weird in the security area -- security is about trying to foresee attacks before they are observed in the wild. So those questions are very valid. There is overlap with adverse actions doc. Resolving overlap and producing a result that's useful for a RP to figure out what attacks its implementation might be vulnerable to, is a good goal. This doc is not yet doing that. We should discuss these problems, we should generate docs about them, this doc is not perfect. I would support admitting and discussing this document, refactor with adverse actions doc. Rob: Work is useful. Overlap with existing docs means it is not ready to be moved forward. We should adopt it but understand that it might never be published as an RFC. Main point, WG should work on these issues. Do not assume it will become an RFC. Zhiwei Yan, cnnic: This document is mostly problem statement. I hope in the future it addresses solutions. : d) Observations reported previously and a few new findings. 1125-1135 : : Presenter: Ruediger Volk Canceled. : : e) Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties : 1135-1145 : https://datatracker.ietf.org/doc/draft-madi-sidr-rp/ : https://tools.ietf.org/html/draft-madi-sidr-rp-00 : Presenter: Declan Ma Rob: Abstain from opinion as to whether it should go forward. I am the worst person to evaluate clarity of current doc set. One specific followup -- my current implementation is close to what RIPE does since techniques are dictated by RRDP. I wouldn't say I'm 100% following RIPE, but closer than you might think. Russ H: in PCIX we have similar docs, don't know if implementors find them useful. Would be worth checking before repeating the exercise. Let's not create a write-only document. Oleg: I commented on the list, to reiterate I'm not opposed to your effort, but not sure it won't create yet another document to the 11. So does this simplify matters, or just add one more piece of mandatory reading? If we're going to accept the work, you and the WG have to commit to actively keeping the doc updated and consistent. Declan: So, if we do this work we have to spend more time to keep it up to date? Is that your point? Are you saying that means the work is not reasonable? Oleg: There are two ways forward, either this is yet another doc that describes everything an RP should do, that means it has to be consistent all the time, or it's more informational in which case the document is too specific and detailed. Start by making it all one thing or all the other. Ruediger: Slide 9, the way I look at this is the RIPE NCC doc should be a precise product description, the users need it for operation, potential users need it for procurement. Your doc could be useful for someone evaluating offerings. (more points elided) I very much agree with your bottom line ("appropriate to proceed with both"). Sandy (WG member): I was struck by Oleg's comment about how are we going to keep this current? This doc will have to be updated constantly. John: About keeping the doc up to date for years to come.. we have existence proof that Internet Drafts that are constantly revised and never completed can happen. Options: ID that never goes to RFC or keep it as a wiki instead. De Ma: Requested Tim for a recap of his suggestion. Tim: Time is limited for all of us. Have the same concerns about how you are going to keep it current. It is also a concern for our own doc. Something we need to think about also. May be we consider it (your doc) should be something other than than an RFC. Even that (something else) may be a lot of work. De Ma: May be we continue this topic on the mailing list. : : f) RPKI Multiple "All Resources" Trust Anchors Applicability Statement 1145-1200 : https://datatracker.ietf.org/doc/draft-rir-rpki-allres-ta-app-statement/ : https://tools.ietf.org/html/draft-rir-rpki-allres-ta-app-statement-01 : : Presenter: Carlos M. Martinez No comments Sandy: We'll request WG adoption soon SIDR in OPSarea Presenter: Chris "SIDR is almost done" 3-6 months of work left. (grim chuckling). Proposal for creation of sidr-ops in OPS area. Randy: Will both groups coexist? Chris: AD question but RTG mailing list will continue to exist but otherwise WG will close. Randy: Will there be a relaxation of impl requirement? Chris: Hopefully OPS isn't speccing protocol. Joel J (OPS AD): Hopefully we won't be looking at protocol enhancements. So charter should steer clear of implementation. It's not operationally useful if everyone does everything differently. Alavaro (RTG AD): Yes, protocol enhancements will be done in RTG. We'll recharter WG if required, or find an appropriate home WG (RTGWG, IDR, etc). I would love to see OPS group meet in Korea and RTG group finish before Korea. Don't hope for long coexistence but it's up to you. Randy: To be specific, we don't have interoperable full impls of CAs. That is not FUTURE work. Joel: Call it out in the charter if you want to work on that. That may be a specific work item. We should tease that out. Ruediger: To Randy, what does interoperability testing mean for CAs? Delegation? We've done that in at least one direction. Right? Randy: Not all CAs impl all objects. John: If the documents really are almost done, comments on the previous talk don't apply. If the document set is "done", it makes sense to try to write an overview doc and not have to revise it constantly. Chris: Some focus. FOCUS on "Finish". Get the docs that are ready for publication request to move ahead -- all the protocol related documents (that were listed in the slide). Joel: The preconditin to from an ops group is that we have something that is deployable. Carlos: It's pretty deployable. Rob: To WG as a whole -- how concerned are we about not having complete, interoperable implementations of CA? To my knowlege I implement everything. I think the rest implement almost everything but not quite (e.g. Ghostbuster records). I dunno if Java-based ones handle up/down. How much do we care? Everyone has their own work priorities. Chris: Someone needs to do an implementation report (with fewer guesses). Sandy: RRDP implementations? Tim: RRDP is there. We don't have running "child" code but we have it in a test setup, not blocking from a protocol PoV. We don't implement Ghostbuster records and router certs. Issue for hosted platform. Depends on what our members tell us they want. We could work on it if people tell us to do so. We have constraints just like everyone. Not sure if that blocks protocol. Randy: Let's not go into all the details on the floor, now. Let us do ops testing and inter-op testing. : : g) ROA Misconceptions 1200-1205 : : Presenter: Randy Bush Ruediger: if we'd been more careful in wording we could've avoided using the word "valid" so many times in so many places and contexts. We have used "Valid" in Validation-Reconsidered in one sense also and "Valid" in origin validation in a different sense. In continuing and further work, maybe we should make the language unambiguous. Rob: We tried that. People appear to prefer to be confused. One quibble, Randy stated you never see invalid ROAs in the crypto sense. Not 100% true, if looking at raw data you can see them, else not. Jakob Heitz: Why did you put this up? I didn't think it was a surprise. But anyway, another to add -- if you put a ROA in, you must advertise that prefix. (shouts of "no!") Jakob: If you intend not to advertise it you should put the ROA for AS 0. (shouts of "no!") Randy: I'll tell you why not. I'm Ruediger's customer. I want to switch to Jared. Make-before-break. I'm going to ROA on Jared's network while I switch over. Dup ROAs are a common MBB practice. Jakob: I never said otherwise. Randy: Yes you did. Jakob: If you intend the prefix should be private, then ROA it with AS 0. Randy: Oh sure. Sandy (WG member): Agree w/ RV. (At one point, in path validation (BGPsec), we tried using "not good" but no more.) About never seeing ones that are invalid, RPKIViz will show you such (or ones about to expire). : : h) Berlin's ROA Signing Party 1205-1210 : : Presenter: Markus de Brun (no slides) We had a ROA signing party during the lunch break Wednesday. About 20 attendees. Some knew what RPKI was, some German ISPs being introduced to it. Five ops present, three decided to create ROAs, a success. I would like to see this become a regular thing, invite local ops and introduce them to RPKI, to build traction. Suggests for next time, send invitation more than two weeks in advance. Sandy: We also had network problems. Markus: Nope. We had some trouble with explaining max prefix length. Also a problem w/ web site from RIPE but otherwise no problem. Randy: there is a real running RPKI -- parent/child up/down Taiji: We had a similar event, important for deployment. But sometimes IP address holders aren't network operators. We prepared materials for dissemination w/in organization to connect address holders. Meeting closed 12:35 pm : : 4) Discussion 1210-1230 : :