[07:00:56] ggm joins the room [07:03:46] Melinda joins the room [07:04:19] [tumbleweed] [07:05:26] eburger joins the room [07:07:08] I'm in V6ops next door. I'd love a knock when the RIR implementation status comes up, I'll come in to present [07:07:15] does this reflect the number of people in the room? [07:07:25] negative - about 50 [07:07:41] looks like I'm Jabber scribe by default? :-( [07:08:30] kicking off presentation. How is the audio? [07:09:59] richard.barnes joins the room [07:10:03] Shane Amante joins the room [07:10:08] spturner joins the room [07:10:20] Elmar (DENIC) joins the room [07:10:25] good morning, my name is richard and i'll be your scribe today [07:10:25] Thank you Richard! [07:10:31] I'll back you up :-) [07:10:32] Rob Shakir joins the room [07:10:34] weiler joins the room [07:10:35] are there people here not in the room? [07:10:41] Affirmative. [07:10:42] jgs joins the room [07:10:42] me [07:10:52] and Melinda [07:10:56] I depend on this feed I am in V6ops will come in when RIR status report is needed [07:11:17] ok, i'll turn the chatty knob to 'high' [07:11:24] Sandy going through today's agenda [07:11:46] steve kent presenting status update on algorithm-agility [07:12:07] Thanks, Richard! [07:12:36] Melinda - are you getting the audio? [07:12:44] rvdp joins the room [07:13:03] slide: Algorithm transition document [07:13:19] target: standards track document to describe what a CA does to transition algorithms [07:13:25] what RPs can expect during tranisition [07:13:33] how the repositories handle transition [07:13:42] interactions with key rollover [07:13:50] slide: changes from the individual submission [07:14:13] (basically going through bullets on this slide) [07:15:13] Ed Kern joins the room [07:16:25] slide: CA & RP Transition Process [07:16:51] this is simplified from the previous presentation [07:17:35] Simon Leinen joins the room [07:17:44] (going through the steps) [07:18:28] slide: Algorithm transition milestones (1/2) [07:18:30] slide: Algorithm transition milestones (2/2) [07:18:38] slide: Top-down Transition Model [07:18:54] algorithm changes cascade down the PKI [07:19:03] can't move before your CA does [07:19:29] slide: Repository Management [07:19:51] repository size will grow by 2x during transition [07:20:13] slide: Relying Parties [07:21:20] slide: Observations [07:21:34] Please read and provide feedback! [07:21:44] Only 25 pages, but fairly complex [07:21:58] Questions? [07:22:30] sandy: possible that this document would have similar issues to the key-roll document [07:23:17] randy presenting on origin ops [07:23:19] http://tools.ietf.org/agenda/80/slides/sidr-15.pdf [07:23:47] randy presenting ghostbusters [07:23:48] I'm not listening to the audio - I'm in another session. [07:23:52] slide: Ghostbusters [07:24:24] MUST have one or more of ADR, TEL, EMAIL [07:24:40] slide: Origin Ops [07:25:44] if you're sub-allocating a prefix to a customer who's going to advertise from its own AS, need to issue ROAs in the proper order [07:26:39] signaling with community strings MAY NOT upgrade an Invalid [07:27:34] slide: RPKI-RTR [07:29:11] color ~~> cache nonce [07:29:36] correcting for resets in sequence numbers [07:30:05] randy done [07:30:18] didn't he say he had four drafts? [07:30:48] He did, but he doesn't. Only 3. [07:30:52] sandy: please review these documents [07:31:41] Mingui Zhang presenting on "Secure Extension of BGP by Decoupling Path Propagation and Adoption" [07:31:51] http://tools.ietf.org/agenda/80/slides/sidr-1.pdf [07:32:17] (chairs trying to get the slides to show up) [07:32:24] title slide [07:32:40] Benno Overeinder joins the room [07:32:53] trying to address comments from last ietf meeting [07:32:59] slide: False Routing Announcements [07:34:07] slide: Solutions [07:34:47] "prevention" solutions not widely deployed because of complexity [07:35:07] "detection" solutions react after an attack [07:35:13] "mitigation" solutions ... [07:35:21] slide: DBGP-A New Mitigation Scheme [07:36:19] DAS_PATH option propagates additional routes [07:37:16] Benno Overeinder leaves the room [07:37:16] Benno Overeinder joins the room [07:37:22] slide: Optional & Transit ... [07:37:25] slide: Comments [07:37:34] slide: 1. Cooperate with Prevention [07:38:12] this solution could be complementary / backup to RPKI+ROAs [07:38:25] what does DAS stand for? [07:38:29] slide: 2. Operational Complexity [07:39:02] weiler: "Decoupled" AS_PATH [07:39:07] thank you. [07:39:13] slide: 3. Separate History Database [07:39:23] asonalker joins the room [07:39:41] what's the proposed heuristic for when to move from DAS to real? [07:39:42] slide: 4. Detection Facilitation [07:39:48] weiler: that's what i'm wondering [07:40:25] slide: 5. Multiple DAS_PATHs Export [07:40:35] Questions? [07:40:56] @sam: I missed your note - want me to ask? [07:41:14] randy at the mic [07:41:47] could you relate this to a draft that's in idr, about signaling back with BGP error TLVs and all that stuff [07:41:57] (all randy's pauses make transcribing easier!) [07:42:16] eric: no. I don't want to spend more time on this. [07:42:19] k [07:42:41] sandy at the mic [07:42:49] (flips to slide 3. Separate History Database) [07:43:08] you say this doesn't require a new database, but it does require mroe memory, right? [07:43:11] zhang: yes [07:43:14] a little bit [07:43:29] sandy: how is this better than other mitigation solutions, then? [07:43:54] zhang: because it uses existing databases [07:44:17] keyur: if you're going to pass this info across ASes, won't it translate to an attack by intentionally zapping paths? [07:44:28] randy: can't i attack you by saying you have bad announcements? [07:44:47] ruediger: can't you fake announcements with this? [07:44:59] keyur: this is probably why you want each AS to do its own validation [07:45:18] ???: what's to stop an attacker from injecting a DAS_PATH? [07:45:29] john scudder [07:45:30] ??? = John Scudder [07:45:47] scudder: does this require contiguous deployment? [07:46:06] it's transitive, but ASes it transits need to add their ASNs to make it be valid [07:46:29] automatic quarantining seems to have major implications for ops [07:47:10] encourage feedback from network providers [07:47:49] shane amante: my understanding is that DAS_PATH routes are still available globally, so they can be observed [07:48:20] this looks similar to RFD, in the sense that there's a quarantine; perhaps the authors should look at connections [07:48:41] doug montgomery: just like PGBGP, only you send the potential update all the way [07:50:26] name of this guy? [07:50:32] Alvaro Retana persenting on BGP security and diagnostic messages [07:50:51] (slides are not on tracker) [07:51:19] 2 parts : what to do and how [07:51:35] slide: Motivation [07:52:30] possible that an RPKI-invalid route could be rejected on that basis [07:52:38] proposal to have an error message to indicate this [07:52:48] goal of facilitating troubleshooting [07:53:16] bad grammer on slide. [07:53:21] slide: Operation [07:53:47] slide: implementation [07:54:11] syntax encoded as a TLV in diagnostic message [07:54:31] describes some classes of RPKI failures [07:54:42] slide: Use of BGP Diagnostic Message [07:54:55] maybe use query mechanism? [07:54:57] slide: Summary [07:55:36] slide: Next Steps [07:55:39] Questions? [07:56:27] randy: Your partial deployment case requires that ASes that haven't deployed RPKI deploy this [07:56:47] alvaro: Could provide some social incentives to deploy RPKI [07:56:55] randy: Is this transitive? [07:57:10] alvaro: no [07:57:22] randy: so i can tell my neighbor, but not the source of the problem [07:57:46] ruediger: how will you actually present the relevant information to the receiver [07:58:23] it can be hard to get information on what routes are being rejected with current software [07:58:42] are you assuming that UI will be added for this? [07:59:25] shane amante: good to have the tools here, but this is sort of the point of looking glasses [08:00:08] this is another example of BGP becoming SMTP [08:00:59] ???: There's an existing trust relationship between me and my BGP peer, nice to signal this in band [08:01:06] (who is talking?) [08:01:23] could help NOC ops figure out why routes are being rejected [08:01:34] (C&W dude) [08:01:44] Rob Shakir - C&W, sorry. [08:01:46] jakob heitz: does the converse apply? if i don't get one, you accepted my route? [08:01:47] no [08:02:04] ???: When you get this stuff, how long are you going to store it in your router? [08:02:09] jeff haas? [08:02:22] When you receive it, some sort of transient notification could be helpful [08:02:39] scudder: when you sent this to idr, i said this was Sidr, now i think the opposite [08:03:03] what you're saying is "i filtered this route", why limit to security? [08:03:47] ??? (Cisco): you can communicate other failure cases [08:04:02] that was robert raszuk [08:04:13] and yes the previous was jeff haas [08:04:45] ruediger: consider what information the users need for operations [08:05:31] ed kern: this doesn't seem like an accept/filter thing, it seems like valid/invalid [08:05:50] so it might not be related to policy [08:06:04] jpc joins the room [08:06:16] randy: russ: what do you think about signaling validity state across ASes [08:06:45] ops document says not to signal validity state across boundaries [08:07:14] russ: my concern is that the state of the two ASes will not be harmonious, and that you'll add confusion [08:08:15] Murray Kucherawy presenting on "RPKI use in detecting network/host split" [08:08:16] http://tools.ietf.org/agenda/80/slides/sidr-2.ppt [08:08:51] sidr chairs have fast reflexes. caught glass bottle on way to floor. [08:08:58] murry comes from app area, please be gentle [08:09:03] slide: TOday [08:09:24] use of black lists for mail handling [08:09:38] slide: RBLs [08:09:45] if only they could play whack-a-troll that fast. [08:10:07] uses a reverse DNS like thing to communicate BL state [08:10:10] slide: IPv6 [08:10:25] like other reverse DNS applications, this is probably screwed by IPv6 [08:10:54] slide: RBLs under IPv6 [08:11:19] spammer changing addresses quickly could cause RBLs / resolvers to melt down [08:11:23] slide: What's needed [08:11:39] aggregation of addresses at some level — which level? [08:12:19] started by presenting this to v6ops, got redirecte dhere [08:12:24] slide: Some ideas [08:12:33] WHOIS? not standard, different by registrar [08:12:49] BGP? Don't want MTAs to have to mess with routing info [08:12:56] slide: Can you help? [08:13:06] Is this the right venue? people want to help? [08:13:23] randy: i use DNS-RBL, so i kind of understand the problem here [08:13:40] my understanding is that the change rate in the RBLs is significantly finer granularity than we anticipate in the RPKI [08:13:54] might break the distibution architecture [08:14:24] suspect the address granularity is appreciably different from the routing granularity [08:15:19] austein: don't think this is a particularly good match for RPKI [08:15:58] murray: concern with cutting it at /64 is collateral damage [08:16:07] Bob: could take smaller subnets [08:16:44] murray: OK for queries, but don't want to make arbitrary subnet cut [08:17:02] who is this? [08:17:06] jeff haas: RPKI wrong for this. [08:17:22] RPKI seems close, but not really good for this [08:17:39] v4 approach will not work for v6 - way too big; cannot use wildcards [08:17:46] Richard Barnes: [08:18:06] using RPKI to help figure out where to cut, not to cut itself [08:18:28] since looking to USE RPKI info, what do you need from us: [08:18:33] Arturo Servin [08:18:42] Another "don't use RPKI for this" [08:18:45] Use DNS [08:18:48] (ouch) [08:19:15] Need new algorithms [08:19:18] How about publishing the cut points in the IRRs? [08:19:19] Randy BUsh [08:19:37] let them deal with the scaling.... [08:19:57] given a client IP address, how big is the allocation? [08:20:18] randy: not a BGP query [08:20:24] ggm leaves the room [08:21:01] Problem is ISP will be doing static routing to enterprises, which won't be using BGP at all [08:21:05] Andy Newton [08:21:33] Gets it that not using RPKI for sending info around [08:21:47] Wants to talk about RESTful whois; taking off-line [08:21:52] Ruediger Volk [08:22:39] my /19 will basically have 2 ROAS [08:22:50] you're interested in the couple of hundred records that say how we're dividing that [08:23:01] we're not going to put that in the RPKI [08:23:18] might want to try to state more clearly what sort of information you want [08:23:47] might be able to get more info from providers privately [08:23:57] murray: also worried about providers lying [08:24:18] terry manderson presenting on geo-rpki [08:24:21] Use ROUTEVIEWS for BGP data (from Chris) [08:24:39] http://tools.ietf.org/agenda/80/slides/sidr-3.pptx [08:24:42] slide: Summary [08:25:54] are there any OTHER data elements from the IRRs or the WHOIS that you'd like to duplicate in the RPKI? [08:25:57] dougm.home joins the room [08:26:02] attaching geo information to RPKI objects [08:26:06] slide: Summary [08:26:32] slide: Summary (with GML) [08:26:46] slide: Summary (civic addresses) [08:26:49] ggm joins the room [08:26:56] slide: Feedback [08:27:29] slide: Implementation (ISC rpki) [08:27:44] terry working on implementing based on ISC software [08:27:57] slide: Next Step [08:28:25] Questions [08:28:26] ? [08:28:37] Randy Bush at mic [08:28:44] Use case? For research [08:28:49] Richard Barnes [08:29:23] Could be useful: general problem for customized applications based on geolocation [08:29:33] done today by using IP->geolocation data bases [08:29:50] hard to keep data bases up to date; impact on ISPs [08:29:57] sandy joins the room [08:30:14] So, use case is to use RPKI as a data base for number resources to expose to applications [08:30:49] E.g., enterprise in RPKI announcement says "this /24 is located here" [08:30:50] asdfasdf [08:30:58] Andy Newton at mic [08:31:22] Could sign Ghostbusters as well, which then violates geopriv [08:31:30] A: oops, yes [08:32:10] While it could reduce calls to NOC, if this goes wrong, more goes wrong, but now not in my scope of control [08:32:14] Paul Hoffman at mic [08:32:46] Even if only for research, but now it is signed, it has more value, leaks outside of research realm. [08:32:54] It's "official", with IANA information [08:33:02] REAL geopriv issue [08:33:21] Worse yet, will be out of date, but will look like secure, bad information [08:33:44] Randy B: what is the cost / benefit analysis [08:33:50] Rob Shakr at mic [08:34:15] What if I give enterprise a big allocation. Do I put in "The Earth" as the location? [08:34:20] A: you are the operator. Sure. [08:34:44] A; if you care about research, you will put it in. IF you don't, don't bother [08:35:06] Cost / benefit analysis: comes out near zero. Won't populate information [08:35:31] Real users need more, accurate, diverse information for geolocation anyway. [08:35:50] Are there any other data elements from other data bases you want to copy? [08:36:07] auturso at mic [08:36:11] Don't want to see it in RPKI [08:36:14] Richard Barnes at mic [08:36:20] "Tide is against us" [08:36:38] Are privacy concerns, especially if tied to ghostbusters [08:36:54] Some mitigations: higher granularity, location by reference, etc. [08:36:58] Andy newton at mic [08:37:10] Geopriv looked at this a LOT. Let's not go there. [08:37:16] Rob Austin at mic [08:37:19] "I don't think so" [08:37:51] I get nervous when one comes to IETF saying "others need it". Let those people come here to ask. [08:38:06] If this is research / experimental, do I have to do it? [08:38:49] presentation on a library for RPKI-RTR [08:38:54] slide Project Outline [08:39:09] slide: General C RPKI-RTR library [08:40:25] slide: Integration of RPKI-RTR lib into BIRD [08:41:04] [is the idea that the route server would be an RTR client? or a validator?] [08:41:13] slide: Administration Data Types [08:41:24] slide: Administration Functions [08:41:30] slide; Validation Data Types & Functions [08:41:56] slide: Prefix Validate.... [08:42:03] slide: Conclusion and Further Questions [08:42:04] Rob Shakir leaves the room [08:42:10] spturner leaves the room [08:42:11] rjs joins the room [08:42:46] looking to gauge interest [08:43:34] Randy Bush @ mic [08:43:48] randy: to clarify, this is the RTR end of the protocol [08:44:00] this is the first public, open-source reference implementation [08:44:21] [08:44:38] sandy: can you say anything about the BIRD presentation at lunch? [08:44:49] presenter: don't think they're going to talk about RPKI [08:45:12] andrew chi presenting on Validator Interoperability [08:46:22] slide: interop testing, Mon 3/28/11 [08:46:42] slide: validator comparison [08:47:18] slide: results [08:48:53] Randy Bush at mic [08:49:06] randy: talked to geoff [08:49:18] he said that the intent of the draft was that the valid cert not in manifest would be a manifest error [08:49:34] Rob Austin [08:49:34] if there's ambiguity, please send a bug report to the authors [08:49:56] issue was not so much ambiguity of semantic, but of importance [08:50:07] didn't realize the results could be quite different [08:50:19] Paul Hoffman [08:50:34] there is no such thing as a "stale" CRL in PKIX [08:50:51] Steve Kent @ mic [08:51:14] 5280 doesn't use the term "stale"; CRLs don't expire [08:51:20] so "stale" is an appropriate term [08:51:22] Ruediger Volk at mic [08:51:42] having this testing is extremely valuable [08:51:51] note that validators don't interoperate [08:52:03] since they don't interact with each other [08:52:20] really testing how repositories interact with validators [08:52:44] for operators, important to know that validator software correctly interworks with repositories [08:53:37] chris: could we make a test suite? [08:53:46] George Michaelson at mic [08:53:47] andrew: not sure that the data we used this week would be useful [08:54:02] george: might have an offering that could be useful, in the fullness of time [08:54:21] andrew: glad to share data, talk to the implementors [08:55:03] rob's PDF didn't play nice with the other [08:55:24] rob's slides up [08:55:27] slide: Overview [08:55:35] http://tools.ietf.org/agenda/80/slides/sidr-10.pdf [08:55:48] slide: OpenSSL RFC 3779 Support [08:56:27] slide: RPKI Validator: "rcynic" [08:56:46] yes [08:56:54] yes? [08:57:01] slide: RPKI-Router Protocol [08:57:21] dougm.home leaves the room [08:57:41] slide: RPKI Certificate Production [08:58:22] slide: Back-end Tools [08:58:24] rjs leaves the room [08:59:01] rjs joins the room [08:59:05] rjs leaves the room [08:59:36] slide: GUI [08:59:48] django-based gui [09:00:49] tim b presenting on the RIPE NCC implementation [09:00:57] http://tools.ietf.org/agenda/80/slides/sidr-6.pdf [09:01:10] slide: Current CA Service [09:02:06] slide: Non-hosted: Phase 1 pilot [09:02:34] building their own up/down client [09:03:09] slide: Non-hosted — Interop [09:03:36] slide: Non-hosted CA — Vision... [09:04:17] slide: Validation — Current ad hoc [09:05:00] slide: Validator — Vision... [09:06:18] andrew chi presenting on bbn relying party software [09:07:05] slide: giant diagram [09:07:27] slide: BBN RP Software Key Features (1/2) [09:09:57] slide: BBN RP Software Key Features (2/2) [09:10:46] slide: giant diagram (again) [09:10:54] slide: System Performance [09:11:43] and another how many ghostbusters objects? [09:12:35] Hannes Gredler presenting on Juniper implementation [09:12:45] slide: Implemented Drafts & Functionality [09:13:17] narellec joins the room [09:15:35] slide: client configuration [09:16:17] slide: policy language extensions [09:17:21] randy: what's a group? [09:17:29] hannes: it's a way to optimize the number of sessions [09:18:30] Simon Leinen leaves the room [09:18:54] slide: UI output [09:21:31] sandy: [ missed it ] [09:21:45] hannes: having trouble getting ssh to work as a bulk transport [09:22:01] Randy Bush at mic [09:22:38] to the ssh question, bellovin suggested hmac/sha/md5 [09:22:56] 3 router-side implementors here, we could negotiate [09:23:32] tcp-ao, tcp-md5 would probably be OK for this [09:23:48] ???: What does "mismatch" mean? [09:24:02] hannes: using multiple caches, so they might disagree with each other [09:24:52] rob: you might end up dumbing this down basically to md5 [09:25:35] doug montgomery presenting on BGP-SRx and BRITE [09:25:57] gigix73 joins the room [09:26:03] slide: BGP SRx overview [09:27:17] slide: BGP SRx Implementation [09:27:45] slide: SRx Deployment Options [09:28:39] slide: BRITE Design Overview [09:29:28] seems to be a testing system for RPKI / BGP [09:29:41] eburger leaves the room [09:29:46] slide: BRITE Web Interface [09:31:05] Ed Kern leaves the room [09:31:21] Shane Amante leaves the room [09:32:11] richard: Why do you have an SRx protocol [09:32:25] doug: basically == for RPKI/origin, but other things might need it [09:32:29] Andy Newton presenting on ARIN's implementation [09:32:35] currently 45 users in testbed [09:32:40] slide: General Architecture [09:32:55] tight coupling between registration DB and the RPKI [09:33:02] slide: As of December 2010 [09:33:13] re-using RIPE NCC code, ARIN re-branded [09:33:18] slide: And then... [09:33:51] want to make sure that it takes 2+ people colluding to subvert the RPKI implementation [09:34:02] re-evaluated HSM from a Sun unit to an IBM one [09:34:20] slide: Changes Underway [09:34:36] slide: Status [09:34:51] also using RIPE code for up/down [09:35:02] Questions? [09:35:17] randy: any input you could give us on the decision process w.r.t. HSM? [09:35:58] andy: Need to be able to prove that people can't tamper with this [09:36:29] randy: that's interesting; you're not worried about key compromise, it's about not signing GIFs of naked furries [09:36:46] Arturo Servin: RPKI LACNIC [09:36:52] slide: RPKI CA Infrastructure [09:37:19] working up/down and hosted CAs [09:37:28] slide: Features [09:37:45] [correction: up/down not working now, but Q3 2011] [09:38:04] jpc leaves the room [09:38:34] simon.leinen joins the room [09:39:24] slide: Heatmaps [09:39:46] rvdp leaves the room [09:39:52] ggm leaves the room [09:39:54] simon.leinen leaves the room [09:40:09] using RIPE code with their own interface [09:40:23] George Michaelson on APNIC RPKI Implementation Status [09:40:30] slide: The Operational Model [09:40:45] split between APNIC CA and hosted CA [09:41:09] using up/down internally [09:41:20] slide: The user model [09:41:42] have provided their software to AfriNIC [09:42:01] slide: Implementation Lnaguage [09:43:01] slide: The RPKI features implemented [09:43:58]