[09:54:02] weiler joins the room [09:55:10] weiler leaves the room [15:51:29] Suz joins the room [15:51:36] Suz leaves the room [16:39:55] David.Cooper joins the room [16:41:04] aalain joins the room [16:45:26] aalain leaves the room: Replaced by new connection [16:45:53] aalain joins the room [16:46:15] hello here [16:49:48] arjen joins the room [16:50:19] wouter joins the room [16:50:39] cdl joins the room [16:50:53] rgaglian@lacnic joins the room [16:52:11] m_sekiya joins the room [16:52:27] m_sekiya leaves the room [16:52:34] onakayu joins the room [16:53:05] wouter leaves the room [16:53:07] aalain leaves the room [16:54:13] aalain joins the room [16:55:37] rhe joins the room [16:57:58] aalain leaves the room [16:58:05] aalain joins the room [16:58:29] hello [17:03:59] aalain leaves the room [17:04:08] aalain joins the room [17:05:33] aalain leaves the room [17:06:42] aalain joins the room [17:07:18] this room seems quiet. i am in the right room? sidr ? [17:08:04] Yes, right room. [17:09:38] rgaglian@lacnic leaves the room [17:09:56] rgaglian@lacnic joins the room [17:10:56] rgaglian@lacnic leaves the room [17:11:02] onakayu leaves the room [17:13:06] rgaglian@lacnic joins the room [17:14:38] arjen leaves the room: Replaced by new connection [17:14:39] arjen joins the room [17:15:41] what is going on ? [17:16:11] arjen leaves the room [17:16:14] aalain leaves the room [17:16:41] jpc joins the room [17:16:51] weiler joins the room [17:17:38] aalain joins the room [17:18:04] aalain leaves the room [17:18:54] Cengiz joins the room [17:20:33] jpc leaves the room [17:20:38] Rob's very faint on the audio stream; can anyone there adjust things? [17:20:54] aalain joins the room [17:22:30] Cengiz leaves the room [17:27:10] we have an audio issue in general I believe [17:27:13] even here in the room [17:27:35] would you ask the chairs to at least find us a jabber scribe, since audio is so poor? [17:31:26] ggm joins the room [17:31:40] discussing ROA formats [17:31:45] multiple sigs on ROA [17:31:50] roba: obscure case. [17:32:25] mark: to review philly.. allowing increases complexity, but if ISP has adjacent blocks from 2 upper CAs cannot make optimal ROA [17:32:36] gih (no chair hat) even more of an issue with min-max prefix [17:33:08] when see routing adv. for particular object, trying to find ROA with object inside min-max. not from a jigsaw, *that one* -but, if you get larger than any single signable entity, search alg. doesn't work. [17:33:16] need multiple signers. complexity was [17:33:19] 'what format' [17:33:22] which is defined in CMS [17:33:42] roba. its not the sig format. understand how [17:33:58] issue is - trying to figure out what certs to include, didn't look trivial to me. [17:34:13] still have fundamental suspicions about circumstances when you wind up here [17:34:19] two adjacent blocks, unaggregatable [17:34:31] jpc joins the room [17:34:43] mark possibly not the fault of the parent. could be parent RIR has inherited this. eg from transfers [17:35:07] jpc leaves the room [17:35:09] gih: (no wg hat) if cannot concede possible to get to this point, rather than 'doesn't work' -then its a different argument [17:35:11] jpc joins the room [17:35:25] roba. likelihood is low (strike by lightening) [17:35:29] Cengiz joins the room [17:35:41] gih (hat off) contrary view. situation can happen, likelihood will happen in future is high. [17:35:54] address exhaustion. pol proposals, in 3 regions, to contemplate transfers [17:36:26] if certs have to follow transfer paths, alloc system structure is no longer naturally hierarchical. owner, user may not have aggregatables in single cert. that property disappears. [17:36:35] for us as a stds body to preclude is inappropriate. [17:36:40] Cengiz leaves the room [17:36:40] roba this is philly conversation [17:36:57] mark: seeking guidance from chair [17:37:08] sandy: will consider and respond before end of week [17:38:07] mark by end of year, s/w out there doing verification. don't want to change [17:38:23] Henk joins the room [17:38:46] mark: seeking resolution on nits from interested people. [17:39:25] gerge: the arch doc alse need s to be change [17:39:30] if we do it in this doc [17:39:39] mark also reviewing arch doc [17:40:29] next is provisioning protocol, or 'up-down' [17:40:36] gih last of the updates (no wg chair hat) [17:40:38] draft 02 [17:41:01] proto describes framework, how issuer, and subject of cert, interact. how the subject says 'issue me' and how issuer says 'here it is' [17:41:13] 02, 01 lasted for only a day. so really changes since 00 [17:41:24] CMS profile/wrapper. [17:41:42] now a complete profile of CMS for XML wrapper [17:41:57] has MUST for signing EE cert and CRL [17:42:14] has MUST for content type and signing time attrs. signing time for replay protect [17:42:19] security considerations beefed out [17:42:51] but thats it. probably one more roll. [17:42:58] roba multiple interoperable impls do exist [17:43:37] next is arrrm -alternative RPKI repository retrieval mechanism [17:43:55] Terry Manderson. (tjm) [17:44:19] first draft, got name wrong. reminded by chairs, name wrong. not adopted item. apologies [17:44:35] alg and mechanism for RP to sync local cache of RPKI against original pubpoints [17:44:55] incentive: not to be rsync killer. augmenting what is already there [17:45:05] rsync is MUST but MAY allows alternates, order is followed [17:45:32] gives HTTP. well known. and provides HTTPS. integrity over fetch, who fetched from. what it means when fetching signed, validateable objects, open issue [17:45:40] documents efficient alg for fetching. [17:45:58] protocol agnostic. some things talk about using http. but if covered in another mechanism (FTP, FSP, whatever) it will still work [17:46:07] does rely on the latest manifest draft. [17:46:46] provides additional SIA field. using IETF proto based mechanism. may help get things through the process. and an unambiguous alg to guide how to fetch [17:46:53] questions/comments [17:46:57] roba. [17:47:00] try to be kind [17:47:08] have two major points. [17:47:21] respect not an rsync killer [17:47:30] don't think we need to go back and do another. we have rsync [17:48:12] one thing I didn't see in document. its more effective than blind fetching but round trip times will be massive. rsync is batch proto. it does a block. this is one little thingy at a time. slow. (for a lot of updates) [17:48:41] part of my concern, higher level, not wanting to go down this path. some decisions about repos structure, had to do with how sync times would work. what works quickly. predicated on rsync, but in that neighbourhood. [17:48:50] this changes the dynamics. not sure you get any efficiency at all. slow [17:49:05] not sure we need to start over, change design decisions. dont see the validity. unless trying to avoid rsync [17:49:11] terry: [17:49:16] features of rsync. won [17:49:21] won't argue. [17:49:38] manifest now shifts the sync point out of the server into the manifest. lot or small amount, don't know [17:49:53] roba either TCP connections in parallel. or doing serial [17:50:02] terry pipelined http doesn't work like that [17:50:18] roba to be efficient, requires http 1.1 client integrated into the fetch/manifest walker. [17:50:35] cant farm out to external process. tight integration [17:50:44] andy newton [17:51:13] the draft alg, make reference to closing conns may be open, but doesn't mention when you close or keep open. if not doing 1.1 persistant. we don't want one connect per fetch. [17:51:30] aught to do: make 1.1 a MUST not a SHOULD. secondly define in alg, when to open connection, and when to keep it open [17:51:54] danny mcpherson [17:52:02] talk about motivations. why instead of rsync? [17:52:05] terry [17:52:27] motivation in this, I sit as operator of routing equipment, and also implementing systems to be the presenters of the repository service out to world. [17:52:35] thinking, 'how best would I want to fetch the info' [17:52:41] we know RSYNC is a must, not arguing against. [17:52:45] want backup plan. options. [17:53:06] know I can scale http servers. well known, understood. know how to do cool things with load balancing, not in IETF space, but well known operational technologies. drivers [17:53:17] have to present info, globally, but also a consumer. thinking from consumer side [17:53:30] danny. my concern is ton of work to do. this adds one more thing need to be done [17:53:39] one more attack point. [17:53:41] complication [17:54:34] sandy requesting wg adoption? [17:54:36] terry yes. [17:54:38] onakayu joins the room [17:54:41] sandy will put to ML. [17:54:49] gih (conflict of interest declared) [17:54:55] Henk leaves the room [17:55:31] Rudiger Volker on irr from sidr [17:55:54] sorry Rudiger Volk [17:56:05] involved in routing registries, looking at requirements [17:56:24] looking at what can be done now. figuring out, some low hanging fruit [17:57:10] reporting to sidr wg on what we are doing on data, infrastructure built, picture of how it might be used quickly [17:57:33] other ops? [17:57:40] (vendors) [17:57:56] rhe raises virtual hand as op. :) [17:58:26] (noted) [17:59:02] take RPKI outcomes, feed into traditional routing security tools [17:59:17] problem scenario. look at the world now. [17:59:34] the youtube .pk, show current need for improvements in routing security [17:59:43] many ways how to improve, [18:00:22] need security in protocols, and good inf. structure, sidr working on that [18:00:28] slm joins the room [18:01:02] but until full auth in routing, best we can do, is emulate, do policy config [18:01:22] this is now expected. [18:02:25] people have difficulty installing tools. for tools that exist, are used, RPSL based stuff, done mid-90s in IETF, is the only horse in town [18:02:32] getting old, but its there [18:02:53] ways to progress.. [18:03:07] rpki provides information infrastructure. base security on it [18:03:46] but going to take a long time to deploy into routing. [18:04:23] slides number ? [18:04:26] map relevant info out of RPKI into RPSL [18:04:32] slide 4 [18:04:37] (sorry will try and track from now) [18:04:54] called ROA2RPSL [18:05:16] slide 5. ROA2RPSL [18:05:27] look at payload got out of ROAs. [18:05:55] payload is pairs of prefix, ASN [18:06:35] RPKI repositories said to be complete collection [18:06:41] now look at old world of RPSL [18:06:47] there we have route: object [18:06:50] payload is prefix, ASN [18:06:58] makes a BINGO [18:07:00] exact match [18:07:28] map payload from validated ROA into RPSL [18:07:47] then can map into existing tools [18:08:02] note the source: tag [18:08:04] (from RPSL) [18:08:29] identify management of RPSL data. allow tools to select what sources allowed [18:08:53] slide 6 [18:08:58] basic use of IRR data [18:09:51] ignore lots of functionality, [18:10:17] people find this threatening, not applicable, not understood. [18:10:31] basic usage model starting from -seems to be consensus in US, Eu [18:10:42] every transit net provider should do filters on custs [18:11:17] to do the prefix filtering, approach is to know AS of downstream custs [18:11:59] if know, go and do RPSL query, resolve set of ASs, rules. [18:12:07] match origin AS [18:12:42] onakayu leaves the room [18:13:31] convert RPKI into format RPSL can use to do resolution from this process [18:13:58] some RPSL db ops, do mapping, easy access for their userbase [18:14:04] slide 7 [18:14:11] example ROA2RPSL [18:14:26] (its RPSL) [18:14:50] used IPv6 example. precise match /32 [18:15:00] with an ORIGIN AS of 9.234 [18:15:54] added info to pointers of the ROA, where comes from [18:16:26] source: attr to allow this info to be selected out of larger DB [18:16:30] slide 8 [18:16:34] tactics/priorities [18:16:54] how to make best use of opportunities [18:17:29] jpc leaves the room [18:17:56] no syntax/semantics changes acceptable [18:19:09] can't exploit new functionality without updates [18:20:09] cdl leaves the room: Disconnected [18:20:10] cdl joins the room [18:21:12] long term security wants RPKI, using mapped data should establish practices, use exact match all the time [18:21:32] slide 9 [18:21:52] Geoff: chair hat off. [18:21:55] wonder about this approach. [18:22:05] wondering if makes better, or introduces new vulns into routing system [18:22:21] semantics of the AS and prefix couplein ROA are precicely opposite to the semantics of AS.prefix in route object [18:22:27] a ROA is created by prefix holder. [18:22:37] says, prefix holder gives auth to AS to originate [18:22:56] the AS does not agree, does not sign, does not have any neccessary knowledge and cannot prevent creation. ROA is not assertion by AS holder [18:23:13] route object is used in RPSL for filter construction about an AS. author is the AS [18:23:17] statement is subtly differnt. [18:23:34] statement by AS holder says "I *will* or *may* announce this collection of prefixes *and no others*" [18:23:51] and no others clause, the intended use is in filter list. filter list as last implicit entry is 'deny else' [18:23:53] simple attack: [18:23:56] you are AS 3 [18:23:59] you do not use RPSL. [18:24:11] I create ROA, I claim as holder of some prefix 1, AS3 originates 1. [18:24:18] I jsut make a roa authorising 3 to originate 1 [18:24:25] AS 3 has no knowledge [18:24:37] rob has AS3 as downstream. uses ROA2RPSL. creates filter, [18:25:04] its accept 1, no others. all other prefixes stop working. because binding in ROA is opposite. they do not map 1:1. they express semantically different info [18:25:22] one is giving authority to AS, but AS may not agree. route object is intention of the AS holder [18:25:28] Sandy [18:26:02] as one who does RPSL. those RIRS who support RPSS require both prefix and AS. [18:26:24] geoff: but a ROA has no AS involvement at all. route object, dont have permission/auth of the AS. how is it useful? [18:26:46] sandy disputing that the semantics are only for the AS. (route objects) [18:26:52] geoff stand corrected on that aspect, but does it change fundamental point [18:26:57] Rudiger. [18:27:17] one registry is using RPSS auth. we know is not perfect. but all the others, the secpol is like, two rules. only paying customers [18:27:27] only party who introduced can withdraw or change [18:27:33] am I creating a new threat? [18:27:48] may create a threat, that people who feel secure when they have to look more closely [18:27:56] geoff. I believe you are creating a new threat. [18:28:14] this object that gets generated, are not, and cannot be the complete set of info originated by an AS. different semantic statement [18:28:15] roque [18:28:19] (lacnic) [18:28:30] motivation: want tools to continue working. but not universal. [18:28:49] not everyone uses RPSL, RIR data. if you like this, where implement? the ROA data is differnt [18:28:55] anyone can download. can impl inside network [18:29:06] whats the objecttive here? [18:29:07] weiler leaves the room [18:29:32] new std i/f? [18:29:38] Rudiger. simple answer [18:30:08] aalain leaves the room [18:30:09] make use of existing tools [18:30:21] weiler joins the room [18:31:09] weiler leaves the room [18:31:44] geoff. wg chair hat off [18:31:49] not 'how do I compute a filter' [18:31:52] don't do that, in a ROA [18:32:17] ROA is, origin AS. is it valid in the routing system? differnt question. what did you just tell me as a BGP peer. should I believe that [18:32:34] what do in provisioning? ans: don't know. ROAS designed for bGP because of semantics [18:32:58] rudiger. [18:33:14] put a ROA somewhere, listing AS's but not related, inviting the world to hijack. [18:33:21] do I care? [18:33:27] geoff will if you construct a filter list. [18:33:43] if only source of routes, then, the filter list fatally flawed [18:34:18] danny [18:34:40] if can't use ROAs to populate IRR then if we don't do that, wont go direct to secure routing protocol [18:34:48] if not this, then keen to see what we do [18:35:03] geoff. if want to sign route objects in IRR [18:35:13] then, have ROA for origin AS and secondly, have route object signed by AS. [18:35:35] with that coupling, individual signing of route objects, NOT synthesis gets you there [18:35:41] dave ward. [18:35:49] get past Geoffs issues. [18:35:56] from history, devils in low hanging fruit [18:36:09] tried to do this last 20+ years back. issues with upload of prefix list into routers [18:36:34] can load so much prefix list, run out of memory [18:36:39] disparate capabilities. [18:37:10] going, with just these two, timing of loading, agreement amongst ops, prefix lists loaded every 24h. in draft, if get past geoff stuff, call out the rules and requirements [18:37:30] if run out of room for pfx lists, we know impls that do not tell. only in syslog. silent drop. [18:38:04] problem in deployment scenario. to go forward, call out known problems, say 'nothing we can do' -give hints. soft notifications, syslogs, red alerts to make useful [18:38:27] terry manderson. I think geoffs semantic issues are a showstopper [18:38:39] this makes ops lazy. stay with it, even with bgp security won't move. will maintain [18:38:53] rudiger definitely not the intention. [18:38:59] native real security is considerable time away [18:39:16] do not wish to spend so much time on interim solutions [18:39:51] dave [18:39:58] make prefix lists from IRRS, useful [18:40:10] larry [18:40:17] merit [18:40:25] stefans joins the room [18:40:32] ISPs using irr data for prefix filter gen, exclusively for custs. [18:40:41] do not look at non-cust AS data [18:40:47] potential DoS not applicable [18:41:12] Geoff then why use ROA2RPSL [18:41:23] rudiger but this allows us to prefer custs from anywhere [18:42:44] can do bogon filters, and even allow orign validation between peers [18:42:49] for limited number of rules [18:42:54] danny [18:43:01] nobody ever deletes an IRR object [18:43:16] very interested in SIDR work, deployable [18:43:54] sandy. volunteers to write drafts welcome [18:43:56] gengiz [18:43:59] 2 obs. [18:44:19] reason RPSL didn't take off, why ROA not the same, is issue geoff listed here [18:44:37] consent to register [18:45:04] security not an afterthought. higher potential [18:45:16] what rudiger is proposing may have people to register their route object a little faster [18:46:01] RPSL for 40,000 prefix days [18:46:08] now, 250,000 prefixes [18:46:33] second comment. semantic differences exaggerated [18:46:47] why would yo do it? [18:47:06] ROA semantics. have risks [18:47:15] semantic differences do exist [18:47:24] need both parties signing [18:47:44] hrdle for roa,. how to deploy [18:48:06] george is at mike [18:48:21] I strongly suggest that Ruediger should speak about semantic difference [18:48:43] think about mission that lies behind ROA [18:49:11] the people working on rpsl are proud of this, but need to think about difference from ROA [18:49:49] AS owner shoudl be able to say this is what I want to do [18:50:37] slide 13 [18:50:40] summary [18:50:47] want security in routing protocols [18:50:50] not seeing timelines [18:51:04] sandy [18:51:10] issues to list: adoption of items [18:51:12] rgaglian@lacnic leaves the room [18:51:15] continue discussion on the list [18:51:22] ggm: Many thanks for the (excellent) jabber scribing. [18:51:29] roba [18:51:50] may need to retract a bit of debate with geoff, multiply signed roas, will think about this [18:51:55] ggm leaves the room [18:52:13] ggm joins the room [18:54:43] rhe leaves the room [18:54:51] David.Cooper leaves the room [18:55:14] ggm leaves the room [19:07:18] ggm joins the room [19:07:53] cdl leaves the room: Disconnected [19:15:41] ggm leaves the room [19:32:46] slm leaves the room [19:41:20] stefans leaves the room [20:26:29] jpc joins the room [20:31:15] jpc leaves the room [22:04:41] jpc joins the room [23:03:48] jpc leaves the room