SIDR WG IETF 90, Toronto Friday, 25 July 2014 meeting started at 908am EDT Matt Lepinski as scribe, with Samuel Weiler as backup. Wes George as jabber scribe. Jabber log: http://www.ietf.org/jabber/logs/sidr/2014-07-25.html Audio: http://www.ietf.org/audio/ietf90/ietf90-territories-20140725-0900-am1.mp3 ------------------------------------- Chairs gave an update on doc status. ------------------------------------- Details in slides, not repeated here. Rob Austsin reported that interop testing has been happening on rpki-rtr-rfc6810-bis. Expect a report soon. Document changes are minor/textual; ready for WGLC soon. ------------------------------------- Matt Lepinski on bgpsec-protocol. (~15 minutes into the audio recording) ------------------------------------- No normative changes. See slides for changes re: multiple paths; no objections raised. Plans to reference AS-migration rather than incorporate the text. No objections. Discussion of relationship between origin validation and BGPSEC: Sandy had suggested that this doc should reference RFC6811/6483 re: origin validation rather than repeat the rules in this document. That way any changes in the validation algorithm are inherited. Alternatively, Randy had suggested removing the origin check from the BGPSEC validation (BGPSEC could be valid without checking the origin). John Scudder: struggling to think of a case where I'd want to trust a route with a good path but a bad origin; would want to see a use case before going down that path. Mike Baer: as an implementaion choice, those checks are very separate. Randy Bush: BGPSEC is not the universal solution and the implementation is very different. BGPSEC validation has two results but origin valdiation has three, and I don't want that third state hidden - as an operator, I want to apply policy based on that third state. Doug Montgomery: you might prefer to validate origin at time of receipt and then lazily evaluate BGPSEC path, which argues for keeping them separate in implementation and policy. (timestamp: 22:30) Matt: with current text, BGPSEC validation depends on origin validation, but there is no restriction on doing origin validation by iteself or before path validation - the restriction is on doing the opposite. Randy: I should be able to determine for myself what do when AS path validates, and there is no covering ROA. Ruediger: I want separate signals. BGSPSEC should return "authentic path", not "valid path". Rob: suggests explaining in the doc the oddly-appearing state of one valid, one invlaid. Sandy: we've been trying to avoid encoding origin-validation policy into procotol, but this seems to be an exception - we have hard-coded policy into the protocol. Wes George: use case: since OV depends on cert state outside routers, if that is inaccessible, router keys might still be available. Ruediger: if I have a customer who does not buy into RPKI but wants to me announce him, why shouldn't I? So then we have unknown OV state. Matt hears consensus to remove origin validation check from this document and add text explaining the oddly appearing case of OV invalid, BGPSEC path authentic/valid. (timestamp: 28:00) Matt reported that he went carefully through bgpsec-protocol v. the requirements document, and found them mostly aligned. Open issues/questions: Discussion of signature curve choice. Discussion has not converged; CFRG is working on the problem. -protocol references the -algs document. Sean will make a proposal to the list and, if necessary, we'll pick randomly. Matt thinks bgpsec-ops draft seems to satisfy requirement 3.5. Randy (as doc editor) thinks it needs revision. It's two years old and out of sync with both -protocol and the origin-ops doc. Requirement 3.8 re: link protection: do we need to change the SHOULD to a MUST and name a MUST implement or MUST use mechanism? Randy: no one used TCP-AO today - it's a fantasy. BGPSEC provides object security; we don't need transport security - MUST is not needed. Jeff Haas: if link is not protected, you can do MitM attacks, injecting valid BGP frames and/or replaying valid messages from before. Matt: we do want to protect against these attacks. Jared Mauch: if someone is on the link and can MitM, that is a much bigger problem - no need for confideltiality protection on the link. Warren Kumari: this is orthogonal to BGPSEC. Mike Baer concurs - no need for MUST. Doug Montgomery: can't MitM muck with the capability negotiating and downgrade the session? Matt: security considerations should reflect that downgrade attack. Warren Kumari: we all think this is nice, but why say this in the doc? Matt: requirements doc says we need to address this. Rob Austein: let's not confuse the BGPSEC protocol with the grand sweeping solution to all BGP problems. The requirements is primarily talking about other threats. Sean Turner: remember that you're trying to get a doc through the IESG. John Scudder: Rob seems to be suggesting we pull this out into another doc - I prefer we stop polishing. Sandy: another possibility is to cover this in the ops document. Rob Austein: addressing Doug Montgomery and downgrade: I think you'll know what to expect from peer without capability negotiation. John Heasley @ NTT: implementation could simply refuse to downgrade. Doug Montgomery: I think the downgrade thing is different - a MitM could potentially reset the connection just by sending unauthenticated packets. Did not discuss requirement 4.3; Matt will update doc. ------------------------------------- Wes George on AS-Migration (timestamp: 48:00) ------------------------------------- The presentation has several questions for the working group: 1) What status should this document be? Concensus appeared to be the same status as BGPSEC 2) Should this document be merged into BGPSEC-Protocol Concensus appeared to be not to merge 3) Should this document "Update" BGPSEC-Protocol Concensus appeared to be that an update header is not needed if both -------------------------------------- Sean on BGPSEC CSR (Certificate Signing Request) -------------------------------------- Question: Do we need Multiple ASNs in a single Router Certificate? Several comments that a router (e.g. for AS Migration) will need to assert multiple ASNs in BGPSEC. Randy: You as a router always know what ASN you are speaking as. Therefore you can grab the appropriate key for the given ASN. Therefore you don't need multiple keys in the same Concensus appeared to be that one ASN per router certificate is sufficient. Sean's slides also has a change clarifying that the [Subject] field in the request is not omitted but is set to Null. The chairs will consult with the ADs about whether the changes to 6487 require a bis or whether this is just errata. ------------------------------------- Jon Scudder on Origin Validation Signalling (Speaking as a co-author) ------------------------------------- There was significant discussion on the IDR list about this document. Wes: Do we want to rely on idr-custom-decision? Draft is not very far along. Jon: If we take out Section 3 then it is all good. Keyur (author) says we can take out Section 3 Randy (author): You can take out all of the Sectionis Jon: If we just take out Section 3, is the draft small enough to drown in a bathtub. Not quite. Jon: I am not aware of anyone who is relying on the decision process change (Section 3) Question: What to do if there is more than one Origin Validation State Extended Community (with different values) Question: What if the value encoded in the Community isn't in-range? Volk: Why don't you just treat as withdrawl Some support for Rutiger Volk's suggestion. Room seems to be leaning towards "it is an error, treat as withdrawl" Authors will bring this to the list. Discussion at the microphone about off-line validation. Discussion did not lead to a resolution, authors will talk out-of-band with those who have concerns and report back to the working group. ------------------------------ Local Trust by Steve Kent ------------------------------ SLURM is a replacement for the old LTAManagement document. It is simpler and it meets the requirements from the use-case document. Suspenders is designed to address the specific use-case to address concerns about a CA who is being compelled to "tinker" with the RPKI. (E.g., by law enforcement). This is independent of SLURM. TAO addresses the issue of INR transfers and how they are accomplished within the RPKI. Andy: What RIR policy asked for Suspenders? Steve: No RIR asked for Suspenders. However, there are RIR members who have wanted this. Rob: I am glad to see LTAmanagement retired. It is up to the working group whether or not to replace it. Tim: Slurm is an improvement and useful work. Suspenders seems kind of complicated. If the working group thinks this is important, then perhaps there is a simpler mechanism There are a number of concerns related to transfers. I am not sure that how to communicate/represent this in the RPKI is the most significant concern. Not sure if TAO is needed.(This is not the most important part of the transfer problem) Randy Bush: I raised the Dutch Court concern at the RIPE meeting (which is the problem that suspenders tries to solve) This is a very real problem. We need to address this Note: I believe that an NIR need for a custom view is separate from the Dutch Court Attack. (The LTA-use-case document seperates these cases) Sharon Goldberg: We have a paper at SIGCOM on preventing the Dutch Court attack. Please take a look at this draft, we welcome feedback on our work. Author will send a pointer to the list. Authors are considering writing up an Internet Draft for the next IETF. Geoff: Is the answer to every problem back in the RPKI? I would like to have a local policy to take precidence over what I see from other people. I am wondering if in some of these cases there is just a local preference decision going on. I am not sure this requires an RPKI-based solution. The RPKI is not the answer to all local issues. ------------------------------- Validation Reconsidered by Geoff Huston ------------------------------- Kent: New document seems to focus on transfers, as opposed to high-level CA makes a mistake. Are these two problem inextricably linked. Geoff: The only difference between the previous version and the current version is the removal of text that described a particular change to RPKI validation. Geoff: There are times in the publishing cycle where we can observe gaps/inconsistencies between the five RIR repositories. Geoff: Most transfers aren't transfers between organiations, but are movement of businesses between regions and/or mergers and acquisitions. Geoff: It would be wonderful if the RIRs were perfect every hour of every day, but that just isn't realistic. Inconsistencies will occur and we need to make sure that such inconsistencies don't cause major problems. Geoff: I need to be very careful in revoking certificates that claim resources that are no longer in the RIR. Bush: We have been observing the RPKI very carefully and we have trouble observing the problem (within the RPKI) that this document claims to solve. Bush: The prime examples are transfer problems. This working group should carefully documument how transfers are to occur within the RPKI. Tim: Have we seen this problem? We have not yet experienced it, but this is no gaurantee for the future. Volk: There is not a very long delegation at the moment, but delegation chains may become longer. Tim: There can be revocations from a parent that you don't agree with. We should seek to minimize the impact of that. It seems valuable to limit the impact to the particular resource without collatoral damage. Robert K: There is value in this even if the RIRs are perfect. Because LIRs make mistakes as well! Rob A: This is primarily a robust-ness principle argument. It is odd that we are hearing primarily from the senders and not the receivers. I am surprized we don't hear more (besides Rutiger Volk). Ussually for robustness principle issues the receivers complain a lot. Also, perhaps one of the problems here is that typically in the security area we do not follow the robustness principle. Doug M: I talk to people regularly in public-private working groups who are worried about this sort of thing. Unless you can ensure us that this kind of issue will never happen, there are people who are going to be scared to deploy this. I therefore fully support the problem description. Warren: We have a bunch of people who run a system and they are telling us that in the future they might screw up. Anyone who runs a large system will occassionally screw up. If we don't agree there is a problem now, then at some point they will screw up and then we will all agree that there is a problem. But that will be painful and so I don't want that to happen. Chris M: Don't you have the option of how many things you bundle together into a single certificate Geoff: "I can issue you a separate certificate for every /128 in v6 but I don't think either of us want that" Russ Housely: "No you can't!" Carlos: RFC 3779 was legacy. It wasn't built for RPKI, it previously existed. We just took it because it was one less thing to discuss. Kent: It sounds like there is someone below you who isn't doing what they should be doing and you don't want to bring the anvil down on them and some other innocent parties. What I am looking for is a bit less high-level description of the problem to be solved. From my perspective, a high level description that transfers are hard and we can't maintain consistency isn't sufficient. We seem to be looking at only one kind of RIR error (what about the other case where RIR mistakenly revokes a certificate that they shouldn't ... e.g., a variant of the Dutch court attack where the cause is an RPKI whoops) Wes George: We need to address the issue that RIRs might screw up. I hope that this solution might help resolve my legal issue in the ARIN region where my lawyers won't let my company sign ARIN's currently legal agreement. (Where ARIN's current agreement is designed to insulate ARIN from ARIN's mistakes) Randy: Note that in origin-ops we discuss how to ensure that if the ENTIRE RPKI goes away and the packets will still arrive. Terry Manderson: Plus one to Randy. I would want to better understand the impact of any proposed changes. I am not convinced the impact of errors in the current system are all that bad due to text in origin-ops.