[18:47:06] Geoff Huston joins the room [19:07:10] ggm joins the room [19:11:17] Brian Weis joins the room [19:11:38] onakayu joins the room [19:11:48] the meeting is starting. Sandy is doing administrivia [19:11:53] Samuel.Ashmore joins the room [19:12:07] David.Cooper joins the room [19:12:16] Melinda joins the room [19:12:37] roque@ietf73 joins the room [19:12:37] your scribe is me (ggm) [19:12:40] Geoff Huston leaves the room [19:12:42] satoru.matsushima joins the room [19:12:49] Geoff Huston joins the room [19:12:52] satoru.matsushima leaves the room [19:13:01] satoru joins the room [19:13:10] weiler joins the room [19:13:10] who is doing minutes? [19:13:15] We're discussing SIDR-ARCH-03 and ROA-FORMAT-04 [19:13:23] Matt Lepinski does updates [19:13:28] (somebody at front of room) [19:14:17] Major changes: improved abstract, intro [19:14:26] consistency with other documents [19:14:29] avoid duplication [19:14:48] Suzanne joins the room [19:14:55] http://www.ietf.org/proceedings/08nov/agenda/sidr.html [19:15:00] calls for comments on Arch draft. [19:15:14] Ricardo Patara joins the room [19:15:16] Sandy: notice speak of producing route filters from material in RPKI. [19:15:26] discussion on use of filters, exclusionary semantics. [19:15:31] included considerations of issues? [19:15:38] Matt: what issue? [19:16:18] Sandy: geoff's comment, route filters, list included, its exclusionary. if you have a list, then a filter is those and no others. thus, if produced from arch, if route not in AS approval, can construct/introduce material, to make filter, will exclude ppl [19:16:37] Matt: short ans. no, current text doesn't deal with that consideration [19:16:43] second, may need offline discuss how to deal with. [19:16:54] if remember correctly, issue in partial deployment? [19:16:57] Sandy don't think so. [19:17:08] Ruediger: gave starting point for discussion [19:17:20] PoV on route filter gen. [19:17:34] filter use is not really for validation, its policy implementation, definition [19:17:41] it MAY make use of many different sources of information [19:17:44] preferably good info [19:18:02] it may be kind of 'bad idea' to claim that kind of use is part of arch. [19:18:27] are uses in various contexts. consider route filter gen as policy/defn thing, makes some of Geoffs remarks moot. [19:18:37] discussion will be had. guilty of not persuing it. [19:18:54] what we do, to get to final/full validation, not sure will happen this century. hasn't happend this far. [19:18:57] Matt thankyou [19:19:21] intention of route filter text in arch doc. possibly unclear, author view, the validated pairings between AS and IP are potentially useful input to gen of filters. [19:19:28] here is how to use the arch to create validated pairings. [19:19:55] Geoffry Haas. in support, SIDR should talk about create filters from data. RPSEC work leading should talk about using this data for sec preference. if net chooses not to use, thats fine. [19:20:04] Ricardo Patara leaves the room [19:20:07] if use only to bias, not binary choice [19:20:11] Matt agree [19:20:13] Randy [19:20:33] dont think you want to get into what shades of lipstick on the pig. [19:21:12] Matt intention is to suggest this type of data, can validate using RPKI, potential input to policy decisions. current text not saying well, suggest text improvements. [19:21:30] (roque is taking minutes btw) [19:21:49] Roque: comment was, to arch doc, mentioned wanted detailed information on trust anchor material, CMS wrap. [19:22:03] don't reference DNSSEC root. [19:22:06] not relevant [19:22:22] Matt second point, will look at DNSSEC in light of email [19:22:38] jpc joins the room [19:22:59] first point, spec of TA material, Q for WG, whats the right place for normitive spec of the format of trust material. happy to have in arch, looked at most recent version of doc, seems to specify format for material, in general, with arch doc, don't normatively specify in 2 places [19:23:11] if right here, have here, but, one or other [19:23:15] The res cert document provides a normative specification for the TA material [19:23:18] Roque. prefer in arch doc. [19:23:26] Sandy whats intended status of document [19:23:28] the architecture document should not provide such a detailed specification [19:23:32] thats a NOT [19:23:52] i.e. I disagree with Roque [19:24:08] Steve. fine to have overall description here, point somewhere else [19:24:46] Sandy. personal opinion. [19:24:53] arch docs dont do format. do relationships [19:25:09] Matt ROA Format [19:25:24] clarify ROA validity, [19:25:40] as per list discuss, check made against EE cert of encompass, not exact match [19:26:05] now implementing, seems not efficiency from exact, use cases cannot handle well with exact. [19:26:17] Randy. Rob here? [19:26:25] problem of overlapping prefixes? [19:26:34] need you to outlaw overlapping prefixes [19:26:45] Robert K [19:27:00] have found corner case, regarding implementing roa, made one with overlapping. [19:27:04] found nothing prevented it. [19:27:15] doesn't make sense, but nothing prevent, in the doc, to have overlapping prefixes. [19:27:17] karen.s.seo joins the room [19:27:18] Matt just to make sure. [19:27:32] saying currently no prohibition against issuing single ROA auth 10/8 and 10.0.0.0/24 ? [19:27:43] Rudiger. what is problem if do? why rule out? [19:28:12] Kisteleki. impl disagreed on validation. raised issue. should doc change, or impl? [19:28:22] Randy. separate codepath. cannot canonicalize to 3779. [19:28:28] don't see win. why do I want it? [19:28:38] can give subset prefix, or the big thing [19:29:09] Ruediger. have situation, have aggregate, handed out in legacy, and several frags, under, more delegated in dark ages to other parties, then, person with agg can announce. [19:29:17] should be able to announce the more specifics for whatever [19:29:26] express that is fine. [19:29:36] is different from, 'all more specifics are fine' [19:29:54] even though, some more specifics belong to different parties, only with original origins [19:30:02] Randy if with other ASorgin not in this ROA [19:30:07] Ruedeiger [19:30:19] defining some parts are fine, others not, needs to have overlap prefixes in roa [19:30:22] Randy keep them separate. [19:30:41] what you're saying. want to announce overall agg, and want to announce subsets, from same AS. with different max prefix lengths. [19:30:48] otherwise can put max on agg. [19:31:00] Ruediger not essentially with different max lengthm, but with diff start prefix length [19:31:15] do say exact match on /13 is fine, have some /20 to treat separately [19:31:18] Randy really have this? [19:31:22] Ruediger. sure. [19:31:24] in RIPE [19:31:28] plenty of examples [19:31:29] Randy OK [19:31:39] Ruediger, sorry, which way were you coming? [19:31:54] Randy wants it the way it is. overlapping prefixes, listed in ROA, makes sense, expresses something [19:31:55] Ruediger wants to have a ROA for explicit prefix lengths without a particular range - which sits within the current spec [19:31:57] happens in real world [19:32:03] RobA. [19:32:22] Kisteleki kindly didn't name me as validator. specific reasons rejected, no easy way to translate into 3779 set. [19:32:32] given now have usecase, have to change code. [19:33:07] Kent needs to be subset of 3779 extension as expressed in EE cert, but allows inherit bit [19:33:22] inherit bit dosn't give direct comparison, have to walk chain. developers want to say no inherit bit, want to see extension [19:33:36] doesnt say one way or other explicitly. how do people feel? [19:33:44] RobA [19:34:00] agree, slightly easier to impl if only explicit resource, no inherit bit. in practice need entire chain anyway. [19:34:04] downside makes ROA bigger [19:34:09] Matt [19:34:28] since now including EE in CMS, seems advantageous, do as many as possible with 2 objects inhand before other checks eg in chain. [19:34:33] Randy [19:34:37] Matt continues [19:34:42] Q to group. [19:34:59] if prohibit inherit bit, is right place in ROA format, or RESCERT profile that defines EE certs? [19:35:06] only 'which is easier for impl to find' [19:35:11] depends if you want to generalize the constraint [19:35:14] Kisteleki. even if prohibit [19:35:17] steve ulrich joins the room [19:35:20] of its its specific to a ROA [19:35:36] have ROA in hand, has cert covers resources in roa, still don't know if valid. still have to validate. see no point in prohibit [19:35:45] Matt efficiency thing. if can determin INVALID from wrapper [19:35:46] Brian Weis leaves the room [19:36:01] Randy. mostly valid. 99% efficiency gain [19:36:15] RobA prefer ROA document. other cases where EE cert requires inherit bit. have close to thing related to [19:36:28] Kent Agree with RobA. eg EE in manifests. ROA specifc. dont put in overall doc [19:36:44] john.direwolf joins the room [19:37:08] john.direwolf leaves the room [19:37:12] depends on order of processing from repository. can have circumstances in which, Kisteleki is right, have to do full-chain, but doing acquisition, in different order, does this offer benefit with certain level of verification, [19:37:47] later, can make sure chain it is part of, valid relative to issuing CA, [19:37:58] rather than having to say nothing about ROA until entire tree done. [19:38:06] Matt. looks like take issue to list. [19:38:12] Randy on previous issue [19:38:32] Ruedgier and I had side conversation. we do not have resolution. if Ruediger feels strongly will yield. [19:38:55] but feel, jsut make max prefix /35 or issue two ROA. wierd corner case. don't kludge [19:39:02] but will continue to discuss. consider unresolved. [19:39:10] Sandy. case overlapping prefix causes harm? [19:39:30] But this is silly - there is no canonical format for the IP addresses in ROAS and the spec allows any form of overlap [19:39:45] taiji joins the room [19:39:46] Randy I have the prefix. I want to put differnt restrictions on parts of it. a) unusual b) common enough to kludge all roas? make codepaths, or, just issue 2 ROA [19:40:01] code example of outcome of funny architecture [19:40:01] I can't hear Sandy at all. I can hear other speakers just fine. Is Sandy using a microphone? [19:40:08] yes, she is. [19:40:10] the comments at the mic appear to assume the existence of a canonical format in a ROA - which at present there is no such canonical format for the ip addresses in ROAs [19:40:14] (yes. I will tell her to speak up) [19:40:32] Thank you. [19:41:02] done. [19:41:09] Matt messages to list, resolve quickly [19:41:20] other thing discussed on list, open issue in doc for several drafts. multiple sigs on single roa [19:41:32] lot of discussion. not consensus to change to multi sig proposal. want to check with room [19:41:40] Randy I do not consent [19:41:56] Ruedgier. use cases rare enought, doesnt warrant [19:42:05] RobA views on record already [19:42:11] but, did not see signs of consensus [19:42:15] Sandy as WG chair me neither. [19:42:47] Q was, what are we going to do? request to add functionality to draft. no consensus to add, will keep as-is. [19:42:50] sandy is inaudible [19:42:57] (I asked her to speak up) [19:43:10] she needs to turn her microphone ON [19:43:10] Geff Haas doc requires multiple sigs, CMS allows for? [19:43:21] Matt in general yes. the Q is, do we need in this std. [19:43:25] Hass don't care. [19:43:26] anyone know where the audio mixer is? We could just turn up that microphone... [19:43:36] Russ author of CMS [19:43:48] certainly far from first profile to say one and only one. no problem going that way. [19:43:52] (her mike is on) [19:44:04] (if somebody ELSE in room can go ask for mixer work thats fine. I can't jabber and do that) [19:44:29] Matt if only a few people buying into this infrastructure, and determining can issue but don't vs cannot issue. [19:44:54] one proposal, add text to ROA format doc, to indicate that AS0 or similar is interpreted semantically as indication the bearer can issue ROA, chooses not to issue [19:45:05] do not want AS to originate routes. want to put forward. what do you think [19:45:28] this AS 0 concept is overlapping the BOA concept [19:45:40] Randy. detestation, is a detestation, weather for AS666 or BOA. arch issue, Q of detestation or not. some perceive a semantic difficulty in the decision space, multiple location that this causes [19:45:51] posted examples [19:45:58] where this is going to cause manual TA config, non trivial scale [19:46:14] fear is manual routing config will be like bogon filters. 6mo later, still can't route. [19:46:21] not comfortable. no matter how you dress the pig [19:47:18] Matt. first bit of info. does this type of proposal address the concern. second is, if the document makes clear that a ROA issued to AS0 is indication that the owner of space is CAPABLE of issuing, opting in, but no other semantics on the address routing [19:47:28] Randy what do they put in their routers or not. Detestation or not? [19:47:36] if supposed to put in routing, care a lot. [19:47:42] Sandy pig is now dressed up. [19:47:45] Randy not going to fly [19:47:50] Ruediger. apply thrust. [19:47:59] Steve Kent I have different spin on this [19:48:08] unlike BOA, this convention for ROA does not require any different treatment. [19:48:12] Randy then why do it? [19:48:57] Steve motivation, during transition period, will be, assertions are unvalidated outside of RPKI, done in the context of RPKI. provides ability for players to use mechanisms supporte dalready, zero changes to interpret, to deny folks from making unauth statements taking precedence than ones which could be said or not [19:49:03] Randy will it affect BGP or not? [19:49:07] Sandy require changes to validation code [19:49:08] Randy no [19:49:25] whrn the router gets this thing, zero, whatever, or BOA, does it affect BGP decision process or not. [19:49:34] Kent, will, if, someone makes a competing assertion which is not validatable. yes. [19:49:43] does it require change to code as described so far? no. both true [19:49:57] Sandy. want to close mike at this point. 15min alloted, well into 30min [19:50:14] Ruediger. using same argument trick as before [19:50:15] any better luck hearing sandy? [19:50:39] nope [19:50:41] in interim period, we have validatable, and stuff where algs work. also have stuff where it doesn't. routers will have some policy knobs to introduce additional Rules [19:50:45] but I can guess [19:50:47] (It looks like the lavalier and the 2 audience mikes go into the stream mixer, but I can't tell where Sandy's desk mike goes -- possibly into the hotel's mixer directly. [19:50:54] those rules can include 'please dont trust announcements not validated' [19:51:17] I like to have a way, for ppl to buy into, wording would be different, semantically the same, to indicate, for certain range, everything showing up should be validated. [19:51:26] this implies of course, detestation of anything which doesnt work this way [19:51:52] in the interim, want polmech to divide addr space, know RPKI should apply, and other address space, where things may work out depending on ROA or not, or something else [19:52:20] Want to have that kind of prefix filter, based on information, security strength of RPKI [19:52:27] is filter based on RPKI, or whatever. [19:52:35] Ward. the issue here [19:52:38] as far as I can tell, [19:52:41] the BOA draft answers Rudiger's desires in this case [19:52:45] by the code, I mean ' in router' [19:52:53] Randy to do the BGP path selection. [19:53:03] Ward. this mechanism has the same semantics as a bogon [19:53:14] Kent, lets make sure. what it says according to semantics for ROA [19:53:25] if it has origin AS in Q, then only allowable origin AS is 0. thats what it sayd [19:53:32] Ward that is a bogon filter. [19:54:07] Matt to clarify, if recieve validatable ROA for AS1, and validatable for AS2 I accept from either 1 or 2. Kent says, if have one of these things for AS0, and someone issues validatable AS2 ROA will accept roa for AS2. [19:54:18] Ward. in BGP code, select alg, its the same. do the same op. [19:54:21] to do this, I write code. [19:54:25] same code for BOA. [19:54:27] (randy) [19:54:34] new way to do semantics,. either in ROA, or BOA [19:54:42] Randy this is syntactic suger. semantics is Q [19:54:45] Roba is major commment [19:54:56] this is the same as the BOA conv. how we dress it up., in certain request easier if ROA, but [19:55:04] thats not the issue. issue is semantics in routing [19:55:27] Kent to respond, we don't have authenticated bogon mechanisms. have proposal, but same way, the other thing has no current mechanism. bogons maintained arbitrariily [19:55:34] notion to do this, maintain in consnstent manner [19:55:45] Ward. in BGP select alg, code will be the same [19:56:10] between BOGON and this. doing same thing. discussing move to Bogon discuss, this way as well. [19:56:19] Sandy. when do Bogons, do you mean filters, or BOA? [19:56:22] Ward mean BOA. [19:56:31] Danny BOA later? [19:56:34] Sandy believe yes. [19:56:43] Terry Manderson. skipping semantics, [19:56:50] if use AS0, skip past alloc hierarchy. [19:56:57] ruediger. doesnt matter which label is used. [19:57:00] just convention [19:57:17] Roque [19:57:31] from RIR perspecitve, have problem seeing BOAs or this mechanism , what we do as registration service [19:58:04] Ruediger, expect to have overlapping, ? [19:58:12] issue what they can route? do we do an AS0 [19:58:24] Ruediger. registry never do ROA [19:58:30] Roque for unalloc space? [19:58:35] Ruediger? avoid the effort. [19:58:38] Danny. clarify [19:59:01] Registries would issue these for bogon space. [19:59:35] if, have unalloc, then IANA allocates to RIR, then to ISP, each one, says 'no more specifics' so do these detestations or whateve, then for each one, HAVE to withdraw, then withdraw next stage down, [19:59:40] Steve not like that [19:59:55] when lacnic gets new alloc, it could issue cert in RPKI has to change. [20:00:06] can then issue under that, an EE cert, and ROA for entire /8 it owns it. cert says so. [20:00:14] it hasn't alloc. it can authoritatively ;'not announced' [20:00:33] as it hands chunks out, issues certs, CA certs to them, or amend existin, and will shrink, issue new EE cert and roa shrinking the non0suballoc part. [20:00:35] that is the mechanism [20:00:42] doesnt trickle down except at alloc. [20:00:47] then ISP can do same if wish [20:01:25] then if hasnt suballoc, and spammers using, at each point in hierarchy, have not suballoc, this semantic allows you to declare it off limits [20:01:34] thats a mechanism this can do. [20:02:12] Randy points out requires trust anchor diffs, if IANA as holder of reserve, issues ee and roa for those, then anybody wanting to use these mechs in private net space, using net 10 etc have to have ability in Rlying party s/w have to be able to add local TA to ignore IANA. [20:02:24] Randy is correct this requires more work to do this. price paid for out of band bogons management. [20:02:46] this makes it clean in hierarchy. no changes to processing of ROA. cannot speak for router vendors. its consistent. BOA mechanism requires new code. [20:03:01] Roque. think my worry, in registration services, empty spaces [20:03:22] we do this much more work. [20:03:40] but generates delay on time can be routed. don't know expectations, thats my Q [20:03:51] Danny [20:04:04] traditionally, when ANS did filters, had to bounce BGP, etc, to get new adv. [20:04:19] once they update filters, reason they stopped, was that time to market thing. 'now wait 12 hrs' type thing [20:04:35] can you update filters, bounce route, readv. tedious. why stopped using inter-provider filer. [20:04:37] this reintroduces [20:04:44] Sandy. now next speaker. [20:05:27] updates to Certificate Policy draft, Steve Kent [20:05:44] thanks to Geoff/Randy/Tim [20:06:10] also added own text, clarify IANA role co-administrator of CP. [20:06:29] additional changes since draft published. will accomodate. the hope to go to WGLC [20:06:54] Randy pointed out previously. document that every CA in RPKI arch signs up to. only one doc. applies to entire RPKI. [20:07:02] unlike CPS, per CA/issuer. there is only one for the entire PKI. [20:07:13] IANA, RIRs, ISPS, all sign up for this policy at top level. [20:07:16] it includes YOU. [20:07:55] global changes from feedback. [20:08:02] corrected defn of bogus routes, broadend [20:08:11] include 'other signed objects' [20:08:39] Randy asks 'what objects' [20:08:42] these comments from the floor are totally inaudible [20:08:45] Steve other signed objects [20:08:53] I assume that they are nonsensical ravings? [20:09:08] Steve the Q was, other signed objects, text defining in RFCS? [20:09:17] A is no, doesnt say at this time. if felt to be important, send text [20:09:56] Randy. therefore, I as participant in RPKI service, contracting to the semantics of objects which are verifyable up the tree, whose actual semantics are undefined? [20:10:00] Steve I wouldnt say it that way [20:10:08] Randy? am I correct? [20:10:11] Steve no. [20:10:23] Randy you do not insist that the objects are defined? only verifyable, not defined? [20:10:38] Steve. CPs talk about issuance of certificates. do not talk about the semantics of what can be verified with certificates [20:10:42] there are signed objects out there. [20:10:54] there are certs, CRLS, they are covered. what you sign with these certs, is broader issue [20:11:01] when you as issuer hand out, clear what they attest to, thats the scope [20:11:19] just point out, in response to comment, objects involved will be verified with certs issued, relate to route security, may be others in future [20:11:22] not inconsistent with other CPs [20:11:46] Randy. contracting to some verb for any objects, signed by certificate, have to do with Routing security. [20:11:58] Steve you as CA, are issuing certs which attest to the holding of resource. thats it. [20:12:12] now Q is, if take EE cert, take key, use to verify that signed object? what responsibility? [20:12:25] answer is, nothing. issuer cannot say what is signed [20:12:34] Randy can we not draw a line, say sign EE, sign ROA, thats it? [20:12:45] worried, sign bank auth, or other thing in RPKI., agreeing to some validity. [20:12:57] Steve you as issuer of certificate, only agree to rules , cirumstances issue certs. [20:13:03] not what end entity go ahead and sign [20:13:13] cannot control what end entity does [20:13:28] but, this policy, makes clear scope is routing security, not bank transacts, bunch of other things. [20:13:46] cant have it both ways. if want to restrict in CP, what might ever be validated, can do, but then have to amend CP if other thing came along [20:14:00] Randy no problem making such a restriction [20:14:08] Steve. then I will ask cochair to discuss on list [20:14:14] Steve continues [20:14:24] added text, uses are routing related, not just route filters [20:14:44] added IANA in cert auth section, clarify [20:15:03] hta joins the room [20:15:13] noted publication/outsourcing [20:15:19] noted co-administering [20:15:29] Mark Kosters [20:15:33] I have Question about all this. [20:15:44] you took the CP doc, let the RIRs tussle with it, brought back into process. [20:15:56] do we tussle again? some of these things not asked for by RIR [20:16:13] Randy given to RIRs some months ago, review, say, deadline was 1 week before draft cutoff. begged. [20:16:20] Randy youre part of process like everyone else [20:16:36] Steve intent is, review again, but hope RIR partticipate like everyone else, input for changes. [20:16:44] Randy all of us sign, attest to this CP. [20:17:09] I do not understand, since Trust anchor is what a relying party does, what this doc says about default trust anchors? [20:17:26] Do we need to get into the wars between the RIRS, and the RIRs and IANA [20:17:38] Steve common for CP to have information about TAs. I can go back and see if we can amend that. [20:18:04] ultimately up to each relying party what they trust. also up to each party who puts out a CP, they say something, but its understood each relying party makes the decision. [20:18:14] Randy considering its a contentious issue, finesse as much as possible [20:18:27] Paul Hoffman [20:19:06] agree with steve, disagree with randy, naming a default TA. contentious in every CP. relying party want to get as much as possible from this agreement. no different from any other CP. just needs to be clear is default. [20:19:36] Danny McPherson [20:19:40] on TA bit, IANA, RIRs [20:19:51] I know there have been discussions, but not in IETF. not sure politics in here [20:20:08] but has architectural implications on internet, if not here. want to see pro's and cons and implications before published, and see in IETF [20:20:16] Steve [20:20:32] minor things, add IANA, NIRs at 3.1.1 [20:20:39] add text on key changeover. [20:20:47] add text on resumption/cease operations [20:21:11] Randy on 5.6 this is not just RIR to LIR, its sub-LIR to ... [20:21:25] Steve open to specific suggestions [20:21:53] more changes, IANA refs, periodis, [20:22:02] one change, referencing IANA holding all resources. [20:22:21] not acceptable text from RIR standpoint, finding other text to finesse, finding text to explain why RIR self sign, why change, IANA doesn't [20:22:40] diagram of most recent version, cert, crl profile. version 15 [20:23:25] the trust anchor model. 2 tier model [20:23:46] second dia, showing non-3779 TA signing over 3779 TA. [20:24:02] realize problems caused, would have written differently. but, thats what we have. [20:24:27] the non-3779 get to remain constant. the changing TA certs, (except for IANA) require periodic reissuance, which makes them less good choices for traditional TA [20:24:41] just threw slides together to help inform ppl [20:24:47] much omitted text removed [20:24:51] 'look in CPS' [20:25:04] amendments, after submission, needs more work. will do, [20:25:06] Q? [20:25:39] looking for ISP input [20:25:47] thats 99% of all the CAs [20:25:50] Andrei [20:25:59] appreciate effort put into doc. aplogize for lack of feedback [20:26:16] doc is tricky, multi-faceted, reason not getting enough feedback. 30page. difficult to read for normals [20:26:26] being reviewed by RIPE legal team. time taken says 'not simple doc' [20:26:45] goes into on one side, business commitments on CAs, possible liability issues, and on other, relying party acceptance [20:26:59] not sure relying parties OR businesses have looked precicely enough, to make choice, if CP suits or not [20:27:14] also have feeling doc is superfluous. goes into areas like policy issues being discussed now in RIPE region [20:27:24] eg circumstances for revokation. hot topic in policy discussion. [20:27:43] so how can we cast in stone, while still being discussed, subject to local agreements. [20:28:02] another issue. says 'used for routing' -but, rights of use, can be used in many way. trading, transfer, or routing is secondary matter [20:28:17] so, appreciate formal doc, contains the sections, all kinds of best practice from PKI, but wonder if we can boil down to 1 page [20:28:19] Steve no [20:28:24] Andre and have no numbering [20:28:27] Steve no [20:28:41] Andrei different parties, different legal systems, dont see how hundreds can converge [20:29:22] Steve format used here, used worldwide by all significant PKI. this is how its done, attorneys, acting for Cas, accustomed to seeing it with these sction numbers, as is. thus not trivial. reasonable size [20:29:33] if desire to make changes, broaden scope, rights of use, open to feedback [20:29:59] at this point, based on comments, feedback, all in favour of more but can we make it 1 page? no. won't cut it, nor with RP attorneys [20:30:03] if any experience in PKI [20:30:26] words differ, but extroardinarily widely adopted form document. base doc may be most widely cited doc in PKIX aside from 3280 [20:30:42] want laywers with CP experience [20:30:47] Andrei understand. [20:31:00] maybe exagerrated. two sides. [20:31:07] standard template goes into areas you dont want to go [20:31:18] call it template [20:31:34] Steve NO. there can be only one CP for the RPKI. CPS are for each party. thats were specific parts are addressed [20:31:47] concrete things, case by case. CPS yes, CP no. [20:31:57] Andrei as an IETF doc, as template [20:32:13] not sure status, if CP goes to last call, becomes informational, whats status and implications for RPKI? [20:32:18] Steve becomes published ref. [20:32:21] Andrei can we commit? [20:32:33] Randy dont have this in the DNS [20:32:38] (for example) [20:32:44] similar infrastructure, common understanding [20:32:49] Steve but it doesnt use X509. [20:33:06] Randy but we havent written down the contract. one reasons havent have to, long enough, pre-existed when we were cooperative society [20:33:21] problem think Andrei, from relying party, what is this thing on which I am relying, [20:33:40] you say, in a sense, that Q in this format is causing us to have to discuss, agree to things, socially, politically, contentius and undecided [20:33:44] have sympathy [20:33:54] but as relying party, like those commitments. [20:34:09] dont feel too badly, asking for what I am relying on [20:34:17] I;m betting packets on it [20:34:47] Apoologies from Sandy saying her mike not fed [20:34:52] jabber scribe can feed my words (she says) [20:35:03] Russ each certificate contains OID on policy. [20:35:16] this document defines this policy. CPS defines how each entity conforms to these requirements [20:35:23] Danny McP. had diagram. the IANA/RIR [20:35:29] eric.brunner joins the room [20:35:35] stated, sorry it has to be this way, 3779 is written, deal with it. [20:35:37] elaborate plz [20:35:46] Steve. 3779 defines extensions that contain resources. [20:35:56] clarified something, ambiguous in PKIX with regard to TA. [20:36:16] when validate chain of certs, that contain 3779, validate to TA< and TA must have 3779 extensions forming superset. [20:36:22] not just some CA cert, last in chain. it says TA. [20:36:31] in discussion in PKIX wg, which things declare to be TA. [20:36:35] those things, terminate chain. [20:36:46] 3779 made it clear, consistent with standards. but, some other things bit more wishywashy [20:36:56] for 3779. says "validation stops here' [20:37:11] but these certs, for registries, change with allocation. not ideal TA in traditional sense. thats why have 2tier model [20:37:13] wherrin joins the room [20:37:49] John Scudder. BGP prefix origin validation [20:38:09] talk about this validation draft, edited by myself, Pradosh [20:38:17] list of contributers. [20:38:30] editors accept blame, offer credit to other contributors [20:38:48] problem statement [20:39:03] differentiate between invalid and legit routes for BGP destination [20:39:40] approach [20:39:59] thought about this from a router perspective. others talk about top level down. [20:40:07] from the perspective of the 'iron in the PoP' [20:40:27] iterated. the notion of data, sources, potentially RPKI, others [20:40:35] purport to tell router what to do. [20:40:48] undesirable to ask router to deal with [20:41:12] have in PoP, infrastructure, does exciting crypto, creates, lightweight normalized DB to router [20:41:32] given normalized DB, router does policy-like operation to do something to give/take routes [20:41:46] way of securing data in PoP [20:41:54] way of conveying to router. not addressed in draft [20:42:20] normalized DB is prefix-ranges, origin AS.sets, (includes min/max lengths on prefix) [20:42:35] three categories of outcome: valid, invalid, or not found [20:42:51] because of partial deployment, not found [20:43:12] change BGP decision process. before LOCAL_PREF step [20:43:20] 2 bits on the LOCAL_PREF is mental model [20:43:28] path with lowest valid state winds [20:43:29] wins [20:43:48] all paths, regardless of validity state, help in Adj-RIB-in [20:43:59] auth data can change: want to re-validate [20:44:25] control knobs. [20:44:36] explicit exclusion control [20:44:41] jpc leaves the room: offline [20:44:42] eric.brunner leaves the room [20:44:53] jpc joins the room [20:45:11] iBGP same semantics as IGP. do not want to second guess. [20:45:15] believe only do this on eBGP [20:45:45] performance [20:45:57] origin AS can be cached on BGP dest, avoid lookup per path [20:46:05] looks viable for realtime [20:46:13] multiple walks into trie [20:46:20] differences with ROA validation [20:46:26] does overlap [20:46:48] different animal. different starting place. [20:47:07] arrived at something, accidentally, parallel evolution, looked like, but not identical to roa-validation [20:47:09] oops [20:47:24] in no way publication of draft repudiates the roa-validation draft. just means work to do [20:47:34] no 'linked validation' [20:47:48] not interested in changing [20:48:06] roa-validation considers push outcome to localpref. some authors here, think not good idea. [20:48:15] almost certainly identical. but drives different deployment decisions [20:48:29] fewer outcome states. roa-validation has?6? ?9? [20:48:40] can introduce more, but, start and build up not build-down approach [20:48:56] BGP validation dissociated from DB. normalized DB, prefixes, origins, [20:49:09] works with, tailored to RPKI but not only data source [20:49:20] can imagine other things. data, talking to RPKI, objects talk to other data sources [20:49:42] operator wishes to consider in policy, decide put all into normalized data. BGP router agnostic as to origin of data [20:49:43] David.Cooper leaves the room [20:49:48] future work: [20:49:53] how to get the data into the router [20:50:16] important problem. not in draft. W-I-P [20:50:28] consideration of merge with roa-validation (talking to authors) [20:50:41] comments welcome [20:50:46] Danny [20:51:04] on validation. valid/invalid/not-detected. assume all for common prefix. more specific wins/trumps [20:51:22] valid not dected, but a more specific hijack. this wont protect [20:51:38] John no. not the case. want, that it can semantically express in ROA, will do for you [20:51:42] Danny didnt see that in preso. [20:51:47] John in draft. if not, need to fix. [20:52:03] Danny origin-AS, easy to spoof. attack, youtube-PK, actual/expected. [20:52:25] John. understand. protects against misconfig and sloppyness rather than clever attacks. 80:20 thing [20:52:26] Melinda leaves the room [20:52:31] Danny brings up a charter point [20:52:41] once RPSEC completes its work on requirements for path validation [20:52:48] Danny. recommend store in adj-rib-in. but, some routers fall over [20:52:48] then sidr can work on path validation [20:52:53] until then its origination [20:52:54] rate limiting of funcs, may be come [20:53:23] John hard to know how rtr like you describe does with ANY validation. not particular to h/w. anytime need to do validation and material can change, have to re-eval routes. [20:53:27] consider BR leak [20:53:41] 267,000 prefixes? store when would drop because my valid later? Ddos [20:53:45] John has to be limted [20:54:16] Danny consider implications [20:54:23] Ward add sentence. [20:54:26] Randy in draft, add words [20:54:38] hta leaves the room [20:54:41] Dont read draft on prefix length matching will be fixed. [20:55:02] scaling. serious Q. want to hear from any Relying party, user of router, what range of routers think need this on [20:55:23] size of router is critical [20:55:49] DFZ router in enterprize should handle this [20:56:09] prefix length and origin-AS in next years, validated routing table, 10meg of cheap ram [20:56:42] if big enough to be multihomed, DFZ, will have the memory [20:56:50] Geff Haas [20:56:58] no different than any other policy [20:57:03] when you change policy, route refersh [20:57:09] Roque [20:57:27] thing heard a lot, from big providers, problems of filtering peering sessions, thousands of prefixes. many different BGP sessions. [20:57:30] different tiers. [20:57:39] i cant have configs of that many lines. [20:57:48] wonder if you propose addresses those issues [20:58:22] John as Geoff (Haas) pointed out, its a policy mechanism, instead of config language, use proto to get it in. responsive to that exact point [20:58:34] Ward. object/transp format to BGP speaker, brought here to WG? [20:58:40] Sandy [20:58:48] Ward thats what we have to do next. how to get data to router ppl [20:59:00] Sandy not sure in charter as stated. its build arch, POSS make changes, but not new proto [20:59:04] Ward sounds in charter to me [20:59:11] Sandy would/could be added to charter [20:59:45] Kisteleki, securing RPSL objects with RPKI [20:59:56] worked on for some time, in RIPE, bring to WG [20:59:59] wherrin leaves the room [21:00:02] RPSLSIG? why? [21:00:25] problem, not all IRR do filtering on input. even if do, mirroring, between IRRs objects in DB, Questionable authenticity [21:00:34] fetch obj, become flat text once divorced from DB. no context [21:00:49] Solution. apply RPKI sigs, keys. [21:00:50] any better luck hearing Sandy? [21:00:58] via digisigs. express in RPSLlike way. [21:01:06] show, creator/maintainer is holder of resource. [21:01:10] nope - but filling in the gaps works! [21:01:13] introduces object security [21:01:23] genrally applicable method to number of objects. [21:01:23] (I sent a help ticket to meeting support, and just got back an note saying the ticket was closed, but w/ no substance.) thanks, geoff; i'll escalate. [21:01:36] could support multiple sigs, handy for route objects. AS and prefix holder can both sign. [21:01:49] meaning of sigs. "says I maintain it, contents are what I think" [21:02:04] what to sign. initially blob sign, in CMS, put somewhere. doesn't work. [21:02:28] need sign in RPSL format to put back in DB. and, over content, not format [21:02:47] signer can select what parts to sign, will be signed. come up with mechanism. minor issues [21:02:54] yoav.nir joins the room [21:03:04] attribute:val pairs, looks like SMTP header, which led to DKIM. [21:03:38] list minimum sets, allow extras [21:03:42] issues [21:03:48] require normalization, DB can change data [21:03:56] submit, let DB alter, then fetch [21:04:11] details on canonicalization [21:04:42] signature. could be DKIM, or CMS. evaluated, picked DKIM style. (stated reasons) [21:04:55] place signature in remarks: field or make signature: attribute [21:05:18] pick attr with no operational value (remarks:) problem, makes difficult to multi sign, needs label/structure [21:05:52] introduce new attr signature: new extension, some clients can have problems. believe solution, db by default does not give attr, has to be asked for. [21:05:59] Suzanne leaves the room [21:06:14] if users do not u/g client s/w will not see sigs so will not break. if already upgraded, add switch, see sigs can validate [21:06:24] example inetnum: signed object [21:07:34] expiry time useful. other signatures introduces cosign model, clarifies that all signing parties aware [21:08:39] open Qs [21:08:44] how things behave. [21:08:50] yoav.nir leaves the room [21:08:55] we know other RIR colleagues, IRR< think this way. want to synchronize. JPNIC [21:09:11] Q. does this proposal justify adoption? [21:09:15] Randy [21:09:20] useful work [21:09:33] but, have enough problems. not here. [21:09:41] Sandy: which WG better [21:10:00] This particular co-chair is of the view that this document is in charter for this WG [21:10:04] Geoff Haas [21:10:18] this looks like another WG. [21:10:29] Kisteleki. brought here, specific usage of RPKI certificates. tight connection. [21:10:35] use of the certificate. useful? thats a Q. [21:10:45] Randy. thousand uses. having problems getting this out. [21:10:51] Randy fine work, but a distraction [21:10:56] Henk [21:11:15] did some work on RPSL year or two ago, posted to RPSL WG list, told to do this as indivd submit. so if not picked up, thats the path [21:11:41] Danny. observe. need charter discuss. working on routing directly, John, but wont do RPSL, want to understand charter better [21:11:43] Sandy thanks [21:11:56] As co-chair I am in favor of picking up this document , subject to an email poll of the WG through the usual process [21:12:01] given thought to conflict with things in RPKI, tings in RPSL objects [21:12:20] Kisteleki. could validate which objects in IRR are for real. [21:12:28] satoru leaves the room [21:12:28] Sandy thanks for staying for extra time. [21:12:31] we're done [21:12:42] weiler leaves the room [21:12:44] onakayu leaves the room [21:13:03] Samuel.Ashmore leaves the room [21:13:43] Thank you, ggm. [21:14:20] ggm leaves the room [21:14:47] taiji leaves the room [21:15:40] Geoff Huston leaves the room [21:15:49] steve ulrich leaves the room [21:16:49] roque@ietf73 leaves the room [21:18:06] opsarea@jabber.ietf.org [21:21:28] Is this the ops-area jabber session? [21:24:03] jpc leaves the room [21:26:26] karen.s.seo leaves the room [23:03:49] ggm joins the room