SIDR August 1, 2012 Note takers: John Scudder (Times provided for correlation with audio recording.) (No attempt made to capture anything that can be gleaned by reading the slides.) 9:03 Meeting begins Reminder that authors must disclose IPR. 9:08 Draft status 9:09 Do we need a WG call for combining -cps documents? (various mic comments: no need, WG has already adopted the work, organization of which drafts it goes in is immaterial) 9:11 validation signalling dead unless authors resuscitate it 9:15 randy bush: signaling draft has multiple interoperable implementations, let's move it forward chris morrow: it expired randy bush: will fix. 9:16 randy: what needs to happen for pfx-validate to proceed? chris: I just need to do the writeup randy: ... 9:17 Steve Kent presenting Unified CPS 9:20 soliciting comments from WG, especially IANA, RIRs, and large ISPs 9:21 sandy: have the ISPs and RIRs expressed any opinion about combining the two cps documents? steve: we didn't ask first, we haven't received any feedback and it's been out there for a while. (room polled, no comments) 9:22 Steve presenting Local TA Management 9:23 (obnoxious cell phone, please turn off your ringers) 9:29 should standardize syntax to facilitate interoperable tools (editors, etc) suggests waiting for next version to come out as it "will be an easier read" 9:31 rob austein: about standardizing the syntax, you may want to consider making the syntax recommended, wait for second implementation, then standardize. steve: please send a more detailed message to the mailing list 9:33 Matt Lepinski presenting on BGPSEC Protocol 9:39 technical change needed for problem: some algorithms (ECSDA) will produce different signatures if applied twice to same data. This implies special handling needed for duplicate updates. 9:40 randy: re-keying will change SKI, so something other than the signature will change. matt: yes, ONLY the actual bits of the digital signature are to be ignored. randy: all the implementor has to do is pay attention to the SKI. 9:41 keyur: one request, please document what randy just said steve kent: if we included the hash that would be helpful - easy check for duplicate messages steve bellovin: but then someone could make a new message look like a dup (injecting a hash from a previous message) and make the update get dropped 9:43 rob austein: the router guys can recognize dups, we just had to explain how using signature bits and SKI 9:44 sam weiler: is there an attack here? if you were to revoke a cert, you'd change your SKI. but could an attacker replay the SKI and signature bits? matt: how often are you going to go through your rib-in and revalidate all your signatures just to make sure none have expired or gone bad based on rpki state? matt: this is completely separable and is a general implementation dependent issue having to do with things that were ok when you got them but rpki state has changed such that they now are not. this is unrelated to dup detection. (general nodding) 9:46 sriram: when you get a dup, if state changed from invalid to valid or vice-versa that would be an issue. 9:47 matt: if it's a dup, why would you bother revalidating? wes relaying padma from jabber: mic: is ML suggesting RPKI state sync with RIB in- what woud trigger a sig check trawl thru RIB in? 9:48 randy: rpki update matt: agree but not for this doc jeff haas: the property we're looking for, is that the box receiving a dup suppresses it at that point. we want to preserve that behavior. matt: agree 9:50 john scudder: is it generally the case that the SKI will change whenever the key changes? this isn't specific to ecdsa right? matt, rob: right padma: mic: how would that rpki update be noticed by router? randy: analogously, how does a router notice a bgp update? the tcp stream provides the data. if you're asking how it matches it to the data in the rib-in, then look at the prefix-validate document. I feel we must be missing the question. 9:52 (some missed) randy: now I get it. a new public key comes in that covers some set of prefixes. fair point since rpki-rtr doesn't currently cover router keys. that is because the spec isn't done, we'll update rpki-rtr when needed. sorry for misunderstanding. 9:53 doug m: should be clear in spec about whether you must validate update, vs. are allowed to skip validation step. matt: there may be disagreement on that point, we should discuss on the list. (agree to disagree, move to list) 9:55 john scudder: suggest making validation inside confed optional. otherwise, looks good. matt: sounds reasonable, I'll make the change unless there's an objection. 9:56 Sandy summarizing interim 10:05 eric osterweil (sp?): nice to see we're starting to model larger sets. Any intention take this approach up to something as big as or bigger than today's internet, then plot performance curves to show how performance degrades with scale? I don't mind seeing rsync included, but this kind of methodology can be applied to other distribution protocols. this may teach us something about the underlying architecture, independent of specific distribution protocol. 10:06 randy: yes. eric: that's not sufficient. randy: almost yes. i.e. we're trying to do that kind of modelling, look at other distribution protocols. adding bittorrent, trying to do it at scale, specifically not presuming it won't scale. eric: nothing scales forever, but don't read into my words something that's not there. 10:08 randy: coherency isn't easy to define in this case. it's a lot like dns. at any instant in time there is no "correct" global view. some protocols (rsync) will have more homogenous views than flooding protocols (bittorrent). we would be glad of more collaborators for the research! 10:09 eric: great. I disagree that my implication was that this won't work, it's just that any system has scaling limits. as for consistency model I don't care about that for micro benchmarks, where we can just focus on fetch time. 10:11 randy: this was all in the presentation. (vigorous bickering at mic, ignoring chairs) sandy (voluably): please take this to the list. tim: I think randy and rob's focus has been on how this data can be shared between relying parties and such. We on the other hand have looked mostly at server load. As Eric said, there's an end to all scaling. ... Current repo about 4000 objects, at current size I see no issues. We're doing test and modelling to let us forsee problems before we encounter them. 10:13 randy: server load and router load are salient points. these are also susceptible to operational fixes. broken protocol, otoh, not so much. chris: the numbers you're using to do scaling testing. we talked in may about 2/5/10 year target numbers. today's testing should test for the projected numbers. finally, a lot of the discussion that was at the mic should be recapitulated on the list. 10:15 randy: your two questions are, how big a number? we are shooting for 1M prefixes. will buy dinner for anyone who can gen the whole rpki data set from bgp data. second, timing? totally dependent on (missed, maybe cycle/refetch time?). 10:17 eric o: thanks chris, that was what I was trying to say. 4000 sounds great, what does that mean? (something about chickens, elephants and tigers.) tim: after paris meeting I asked on the list for people's ideas about requirements, not much feedback, but very happy to discuss it. also, I do believe that current deployment works, I just want to look to the future. 10:18 rob: 1. the way I'd characterize the discussion: we have early measurements that indicate we have the potential for a success disaster. we can get going but need to plan ahead. 2. we are starting to look at things like bittorrent potentially even for top-level publication. we'll report back when we have data. 3. we had a protocol observation from steve kent on friday. one of the drawbacks of the current approach is that we don't have (something mumble something). there is a time til next manifest, steve pointed out that this could be a hint for time until next poll. 10:20 danny mcpherson: agree with chris and randy. (something about implications for architecture) i imagine we would see more churn in the rpki than the actual routing system. 10:21 sandy: geoff was on remotely at a previous interim (