Matt Lepinski took minutes for the SIDR session in the IETF etherpad. I've uploaded a copy to the meeting materials site. http://www.ietf.org/proceedings/89/minutes/minutes-89-sidr
The etherpad site (temporary) is http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-sidr?useMonospaceFont=true Below is the text of those minutes. Please review and send any corrections or additions to the list. --Sandy, speaking as one of the wg co-chairs SIDR Meeting at IETF 89 March 4, 2014 9:00am UTC Chair Slides: http://www.ietf.org/proceedings/89/slides/slides-89-sidr-7.pdf Chris Marrow (Chair) will work with the authors on the mailing list to resolve the one outstanding issue in the requirments document. draft-ietf-sidr-bgpsec-reqs-09 -------------- RFC 6490bis - Geoff Huston : http://www.ietf.org/proceedings/89/slides/slides-89-sidr-2.pdf Rob Austein: It would be nice if there was an easy way to find the delimiter between the URIs and the Public Key Also, it would be nice to keep this simple. I would like not to have to include a JSON library just to parse the TAL file Geoff Huston: Will look into whether carriage return characters can appear in the public key If there can be a carriage return in the public key, Geoff will put in the blank line delimiter Sandy: Are we just dealing with the one issue (multiple publication) or when we re-opened this document, was the working group's intention that Rob A: If we are going to change the document, let's make the smallest change possible to address the issue (multiple publication) Tim B: It is not important to me that we use JSON. I think JSON is a good idea and it is well-defined, but I don't want to hold anything up Randy: Isn't Klingon as well-defined as JSON? Wes: No, but it is easier to understand Sandy: The Working Group Chairs see a high bar for accepting any changes other than the muliple URI change ---------------- George Michaelson - OID issue in RF6485 : http://www.ietf.org/proceedings/89/slides/slides-89-sidr-5.pdf This errata is actually a change to base document Stewert AD: We are not allowed to make any technical change through the Errata process ... spin a new RFC if there is any doubt ... please include a note to be removed by the RFC Editor Make it clear what the change is and why this change is being made -------------- Rob Austein - No Slides The current draft for BGPSEC router certificates requires there be only one AS in the Router Certificate Steve Kent: As an author, we can fix this Matt L: It may be helpful to have cautionary text in bgpsec-ops telling people not to use multiple keys for a router that happens to be in multiple ASes. Fixing the router certificate draft is important, but even with the change bad/dangerous behaivor would be permissible. Jeff H: Wes and Sandy's document on AS Migration might be relevant here. We want to make sure whatever we recommend for router certificates is consistent with AS migration scenarios ------------ Randy Bush : Use Cases - No Slides Randy Bush: I know Steve Kent has issues with the prose. Does anyone have issues with the semantics Steve Kent: I will provide suggested text to improve the prose. Randy Bush: Note: If you swallow this pill then proposals to change the world will need to address these three use-cases ------------ Geoff Huston : RPKI Validation - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-3.pdf draft-huston-rpki-validation Randy: This doesn't have an Internet draft? Geoff: There is now an Internet draft Randy and Geoff talk past each other regarding whether this proposal is top-down and bottom-up Rob Austein: I am not concerned about the responsibility that RIRs have to do the job that they are paid to do I am concerned about caching/timing issues. I am somewhat If we go forward, we need a new OID for a new certificate extension that is not RFC 3779 but is like 3779 We would not want to implement this in the core of OpenSSL However, I think that joins in the tree are not as easy as you make them out to be. Getting the issuer names to match is probably doable with X.509 games, but it isn't easy Doug Montegomery made a point that was missed by the minute taker <sorry> Claim: If we go down this path we won't be able to understand the RPKI by looking at Geoff: We didn't have this to begin with in the PKI model because everything we have in a PKI is relative to the Trust Anchors that you happen to trust David Mandelberg: On Slide 15, Geoff doesn't mean "Local Trust Anchor" in the LTA sense of other SIDR documents. <talking past each other ensues> David is concerned that adding joins makes things a lot more complicated (at least for the people doing the validation) Steve Bellovin: I am concerned that I don't understand the formal semantics of this evaluation you are proposing When we move from a tree to a graph, I am concerned that the consistency proof isn't obvious Geoff: The semantics are equivalent to if we had a separate tree for each address and for each AS number Rob Astein: "Twitch ... Joins ... Twitch" Tim B: It might be useful to consider the two cases separately -- where you have no joins, and where you do have joins I think the former issue need not be that hard to implement (although as Rob said maybe we need a new OID) I like that the tree structure allows me to validate in paralell without one branch affecting another Geoff: The paralellization isn't a major issue. I can give you pseudo-code Steve Kent: There are a lot of problems with the joins. Key roll-over won't work smoothly in the event of a join What you propose is a MAJOR change to validation I am sympathetic to the issues you raise But I think the joins are a foundamentally flawed idea and then we can discuss whether there is a way to address the other issues you raise Warren Kumari: Doesn't it make sense for the guy at the bottom to just claim 0/0 and all AS number? Geoff: An issuer should never issue for 0/0 Carlos Martinez (Lacnic): I think (like Tim) that there are two use-cases that should be addressed separately When I explain the technology to new people, new people imagine that things currently work with the relaxed rules that Geoff is proposing [1st use-case] ------------ David Mandelberg : SLURM - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-0.pdf Tim B: We have a web interface for ignoring particular resources It would be great to have a standard way of doing/configuring this Rob A: This misses some shared central configuration In this you need to distribute SLURM files, you can't just point your validator at someone you trust This isn't bad Randy: This doesn't solve Alice and carol's case We should think about about how to solve the whole problem (all three use-cases) Discussion with Jeff and Chris about whether the draft needs both del and add statements. Would there ever be a del without an add? Wes George: Why are we coming up with new and interesting ways to poke holes and not trust the system? Won't people just use this do to kinky things? If we insert this work-around for the system, at what point do we just decide that implementing RPKI isn't worth the overhead ---------- David Mandelberg: TAO - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-1.pdf Rob A: What if Eve doesn't exist? Randy: We are missing (from the 2007 discussion) the agreement that the externalities have been met Requiring that the externalities have been met requries Eve existing and getting the resources Reference to "torn Euro" protocol Steve K: This is an automation of the update of the RPKI data for a transfer It is not a replacement for existing procedures/contractual arrangements Carol can issue a trivial resource to Eve to put her into the system (e.g., give Eve a /32 and take it back after this is all done) Byron [Jabber]: SKI is not identity ... this needs clarification, will take to the list Tim B: I think these are valid goals. But this seems to add complexity to provisioning Maybe this can just be solved informally and doesn't require a new standard But I need to read this draft fully ---------- George Michaelson : Rsync Harmful - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-8.pdf Note: Much of this presentation was given in a different context on Sunday at IEPG Note: When George's slides refer to East Coast and West Coast he is referring to North America. (As opposed to, say, the East and West Coast of Japan or Australia) Rob A: I have been viewing Rsync as phase 1 I imagine at some point we will need to do something else I like this presentation, but it doesn't change my opinion I really don't recommend running as root. (Our software does not make it easy to run Rsync as root) Tim B: I think it is an important design decision to have validators seperate from routers I don't think sending the RPKI data in BGP is a good idea I have some other ideas for replacing Rsync, which I will bring up again if appropriate. Randy: Thanks for doing this work However, for the time being, Please follow RFC 7115. (Recommendation with regard to directory system) ----------- Fabian Mejia : RPKI Experience in Ecudor - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-4.pdf Volk: Is there use in actual routing in Ecudor? Ans: On March 15, invalid routes will be dropped at the IXP (Currently just monitored) _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
