[15:48:46] ggm joins the room [15:50:41] ggm has set the subject to: SIDR WG. Agenda is: http://www.ietf.org/proceedings/09mar/agenda/sidr.html [15:59:19] Robert Raszuk joins the room [16:03:37] roque joins the room [16:05:18] carl-ietf joins the room [16:05:29] benno joins the room [16:05:30] Sandy Murphy kicks off [16:06:08] aalain joins the room [16:06:14] weiler joins the room [16:06:35] agenda bashing [16:06:50] now discussing http://tools.ietf.org/html/draft-lebovitz-kmart-roadmap-01 [16:07:09] Greg Lebovitz. [16:07:26] John Schnizlein joins the room [16:07:30] just an 'advertizement' [16:07:52] jpcerezo joins the room [16:07:53] today in routing area wg, presentation/discussion about doc from routing/security ADs & others [16:08:10] Henk Uijterwaal joins the room [16:08:14] talking about improving the security of the routing infrastructure, particularly bits-on-wire of the transport. [16:08:29] not message verification, privacy, but authentication of the msgs sent from neighbour to neighbour. [16:08:40] prevent rogue neighbours, hostiles, some DoS. [16:08:42] gih joins the room [16:09:12] two step process. 1) look at existing auth mechs in routing protocols. modernize. strong crypto, alg agility, secure use of pre-shared keys [16:09:13] David Cooper joins the room [16:09:26] first step taking time to achieve eg in BGP [16:09:38] then second step 2) put key mgt protocol on top. making it easier to implement [16:09:42] rekey simpler. [16:10:04] avoid keys being written, staff leaving with secrets. [16:10:18] basic roadmap. classes of protocols, recognizes can't do it the same for all classes. [16:10:35] work on KMART mail list kmart@ietf.org. docs in I-D repos. come to routing area. [16:10:36] Qs? [16:11:05] now discusing http://tools.ietf.org/html/draft-ietf-sidr-arch-06 [16:11:19] Matt Lepinski [16:11:32] before meeting released 06. [16:11:51] changes, removed TA text, default TA configs, pointing to new TA-00 draft being discussed here. [16:12:06] removed ROA usage text, pointer to draft roa validation. [16:12:24] clarify terminology. helpful review from Danny McPherson. call for more reviewers. [16:12:42] changed text on subject names, APNIC implementation experience [16:12:51] On subject names. [16:13:20] NIR/RIR can have meaningful subject names. subject names for other parties should not be meaningful. unlike other PKI, not asking CAs to make any statement regarding identity. [16:13:48] want low barrier to entry. meaningless strings [16:14:05] one property vital for certificate paths. can be meaningless, MUST be unique among all certs a given authority issues. [16:14:18] previously recommendation, Subject Name, distinguished name should only have CN attribute [16:15:07] recommendation now to use two. CN, other is serial attribute. based on APNIC implementation experience, allows one string (CN) to persist across rekey, another, (believe serial is appropriate) can change, when re-issue key. even derived from key, chosen in another fashion. [16:15:11] Randy IIJ [16:15:30] Henk Uijterwaal leaves the room [16:15:31] clarify, why RIR, NIR cert names meaningful, yet IANA, other LIR are not. [16:15:38] Henk Uijterwaal joins the room [16:15:52] Matt: no good answer for that. [16:15:57] Kent: IANA should be included, oversight. [16:16:11] the LIR, what Matt said: don't want to impose requirement to verify right-to-use name. [16:16:21] small number of entities, RIRs IANA, NIRs do not impose that problem. [16:16:36] Randy [16:16:52] Certifying those names? [16:17:05] Kent, no, self-certify. RIPE certifies own name. [16:17:15] Randy, RIRs self certify their names but LIRs don't ? [16:17:53] Kent. the two things, the names for those entities, presumed not to be contentious. [16:18:01] Randy? name vorizon contentious? [16:18:11] Kent we had this discussion a few years ago. [16:18:19] Randy there are first class citizens, and there are others. [16:18:35] Kent rationale just as we said, and not changed. goal is to reduce impediment [16:18:41] Randy don't issue attestations based on the DB? [16:19:04] Sandy. what advantage is there for having the RIR names certified? [16:19:30] Kent only advantage is to encounter one of those certs, small number of entities. can do away with it, human factors issue, doesnt run into problems. [16:19:46] Sandy are other authorities forbidden to use these strings? [16:20:01] satoru.matsushima joins the room [16:20:30] Kent. in most PKI subject proposes name, want CA to sign for, attest. this one does not have that property. issuer assigns. makes easier to match up with their internal DB. but does not have to verify assertion to use that name. goal is NOT to turn CAs into DNS registrars. [16:20:40] Sandy having the RIR named in its cert, would be good. [16:20:49] are other Cas forbidden to choose one of those set-aside names? [16:21:12] Randy I believe she's asking am I, as member of JPNIC, issues me a cert, can I ask that my subject is IIJ? [16:21:31] Sandy, no, saying I'm IIJ, issuing certs, am I forbidden to put RIPE, JPNIC whatever in the (subject) name field. [16:21:41] Henk Uijterwaal leaves the room [16:21:50] Henk Uijterwaal joins the room [16:21:55] Kent syntax allows a common name. you would be needlessly incurring liability but from a mechanical standpoint, system would still work [16:22:35] Within the syntactic constraints one could but not consistent with policy [16:22:50] Randy. trying to understand the word meaningful in this context [16:23:04] Roque. is this distinction can be moved to CPS, discussed by any CA, take that decision? [16:23:11] community led decision? [16:23:23] if we have to put meaningful info in the CN, difficult to know whats meaningful. [16:24:05] Kent could move to CPS? if establishing syntactic constraints overall then no. this is a slippery slope. [16:24:27] why not add C, org, orgunit, garden variety X509 issuer distinguished name. reluctant to go that way. [16:24:33] Randy best way off slippery slope is don't start [16:25:31] Rob Austein. minor issue with topic. current text appears to be recommending I have a stable common name. not 'option' of stable common name? what if I just use hex of hash of public key? [16:25:42] geoff huston, not as cochair. explain origin of request from APNIC [16:25:53] previous version precluded any other form of name expression other than varying common name. [16:26:15] implementation being done by APNIC wanted structured namespace. one part persistant, DB key, other part varied with rekey. when put request in, became single model 'must go the other way' [16:26:26] we didn't ask for that. we just wanted restriction lifted. [16:26:39] as APNIC, one impl, thats fine by us, if others don't want the constraint, we don't have a problem [16:26:46] Rob fine with that. if we allow both, I'm ok [16:27:12] Matt next version will clarify. structured allowed, for persitent, will clarify. apologies [16:27:41] Open Q. need to resolve ML wether or not, RIR/NIR/IANA names should be proscribed as meaningfull or make all cert names not intended to convey identity [16:28:03] other topic. current text has example of how one RIR would delegate resources to another RIR [16:28:17] eg for ERX, or deal with future policy for inter-region transfer. [16:28:31] illustrates how RIR root certificate, TA material need not be re-issued to accommodate such an exchange [16:28:33] was discussion on the ML. [16:28:46] Q1. is this example helpful? outlived its usefulness? can remove. [16:29:54] Q2. came up during discussion, wether or not, Arch draft or some other doc, clarification on the make before break principle. propagation time inherent, publish, ROA, repos, then RPs need to go to repos to grab. important to auth using resource PKI new routing before you revoke old? [16:30:03] Terry Manderson. [16:30:16] think ERX example should be removed. in light of the TA draft, ETA RTA. [16:30:35] ROA format draft: not revved, wish to after meeting [16:30:39] overlapping prefixes in ROA. [16:31:25] this can be meaningful. [16:31:31] Rob Austein [16:31:41] if the intent is to allow, please make it explicit. [16:31:54] Matt currently no text. unless objections, new ROA draft will explicitly permit this behaviour [16:32:00] Randy [16:32:10] from a user PoV can achieve issuing two ROA. [16:32:22] check with implementors, wether getting away from canonic 3779 is annoying. [16:32:35] Rob Austein. [16:32:53] didn't make issue. Randy, yes this is a bit of a pain. code in OpenSSL doesn't like this overlap very much. can work around. [16:33:04] recollection. Kisteleki argued me into the ground on this. need to allow. he thought he had a use case [16:33:42] Matt you/randy both expressed concern about it. Kisteleki, Volk & Huston all thought need [16:34:25] Rudiger Volk have to do multiple ROA in some cases and not others, may come as a surprise. nice systems, provide nice user i/f could be managed in i/f layer. getting whole thing off the ground nice to have smooth homogeneous definitiion, explicitly ok. [16:34:33] Randy same crap in either case, who bears it [16:34:58] glenncarl joins the room [16:35:00] Henk Uijterwaal leaves the room [16:35:11] Henk Uijterwaal joins the room [16:35:24] Randy other way thinking about it. if RobA does formal check is 3779 congruent, have more formal nail in the floor. [16:35:31] Steve? Matt? who is doing the hack. [16:35:44] Matt being written by another person not here but our code is able to accommodate these overlaps [16:35:55] Rob Austein. take to ML [16:35:59] too many ppl not present [16:36:26] Matt. need another version of ROA draft, nearly ready to last call. thanks to Roque, Danny [16:36:29] Sandy [16:36:43] in arch draft, said certain discussion on use of ROA should move to validation draft [16:36:51] glenncarl leaves the room [16:36:59] Matt validation draft now describes how one uses ROA in a transitional period better than today [16:37:17] some overlapping text. now say "for info how to use ROA to improve, first steps please see " [16:37:29] Sandy do you beleive validation draft adequately covers issues removed? could look? [16:37:38] Matt high level covers topics [16:37:59] Q do I agree? don't want to be sidelined to agree, but scope of discussion in that draft is apprpp[raite division of labour [16:38:08] Sandy Q2 names required to be unique under particular CA. [16:38:14] recall long discussion what a CA meant. [16:38:27] when the CA rekeys, is it removed from requirement to maintain uniqueness? [16:38:59] Matt ok. arch draft not sufficiently clear on this point. yes, when CA rekeys we do need uniqueness to persist [16:39:11] Rob. we are not rekeying a CA. we are creating new CA, destroying old one [16:39:29] strictly, uniqueness does not persist, but its x.509 voodoo [16:39:37] Sandy good thing. then certs don't have to be redone [16:39:56] Kent. to answerQ, rekey doesn't remove this requirement unless the name changes. irrespective of context. [16:40:08] we're not trying to violate that. remain consistent to 5280 [16:40:14] if name changes, then its equiv. [16:40:21] if rekey and don't change name, then no. [16:40:31] want there to be no ambiguity with regard to serial numbers being issued to certs [16:40:48] Matt. next version of arch draft, clarify name uniqueness, to remove ambiguity, [16:41:13] can mention in arch draft if rekey of auth results in new name for auth, then uniqueness requirement is no longer needs to persist. saying poorly. needs to be said somewhere well! [16:41:26] heather.skanks joins the room [16:41:38] David Cooper. want to point out, if follow X509 name uniqueness, single CA doesnt issue 2 certs [16:41:47] Kent but thats not reaility as we all know, for any PKI that exists [16:41:59] Cooper examples? [16:42:11] Kent do you know examples of any CA issuing certs to two different subjects same name? [16:42:48] Cooper two CAs with one name. validate, put CRL in cache, another CA, use precached CRL ,, [16:43:13] Kent. agree with characterization when re-cast in terms of X509 naming model. there is not a global naming auth for PKI names in general. the notion of these names all being unique [16:43:23] satoru.matsushima leaves the room [16:43:36] what X509 assumed, which has never happened, one directory inf tree for the universe, certs issued to entities to namein that one universe of names. directory names unique. not reality [16:43:38] nice idea [16:43:49] ryanshea joins the room [16:44:57] now discussing http://tools.ietf.org/html/draft-ietf-sidr-cp-05 [16:45:01] Steve Kent [16:45:24] is the inverse bad too? issuing multiple certs to the same org, where the org name is slightly different (ie, INC. .. Inc.. ) [16:45:30] quick reminder. one CP for the RPKI [16:45:43] [do you wish a Q raised at mike? we have moved to another doc -ggm] [16:46:04] no - s'ok [16:46:11] RPKI arch, profile doc point to OID for CP, shows up in every certificate issued. everybody is implicitly signing off to follow this policy [16:46:31] as pointed out by Randy, all prospective CAs, not just RIR,NIR but all LIRS should pay attention. signing up to abide by this policy [16:46:42] at previous meeting Andrei said 'want shorter' [16:46:45] satoru.matsushima joins the room [16:46:49] we made it 15% shorter. [16:46:55] doesn't get to size he likes: isn;'t going to happen [16:47:08] but did revisit, things being specified in CP, can be relegated to CPS. reasonable request. [16:47:13] John Schnizlein leaves the room [16:47:15] aalain leaves the room [16:47:19] fewer things universal, put differences in CPS, reasonable way to accommodate [16:47:31] scrubbed it, found some, went ahead and pushed to CPS. [16:47:38] bkuerbis joins the room [16:47:42] doesn't make it much shorter, same subsections but points to CPS [16:48:07] could drop a few more, if AUDIT section, not proscriptive, indicative, could delete and move to CPS. [16:48:17] aren't really telling you HAVE TO, more indicative [16:48:30] also responded to suggestions from ppl revise scope. now not as narrow as was before. [16:48:55] not just ROA. covers PKI for certs to resource holdings. examples include ROA, but mention transfer as application. [16:49:06] what was moved? [16:49:21] few. in multilpe places. [16:49:29] time constraints, how quickly publish CRL in repos [16:49:34] carl-ietf leaves the room [16:49:47] CRLs carry next issue date so already telling R-Ps when to look. don't need to state globally [16:50:24] details of enrollment, not neccessary here. per CA basis. issues of contention. eg contracts grace periods, after fees due. local matter. tried to remove. [16:50:42] these things, only 4 bulleted, but RFC structure demanded 20+ refs change [16:50:44] removed specific things. [16:50:55] ROA before expire, not stipulated. [16:51:39] Proof of Posession of private key, good practice removed [16:51:56] John Schnizlein joins the room [16:52:00] all sections marked as ommitted, but retained numbering for sections. helpful for people familiar with overall format, ties back to base RFC [16:52:10] some informative refs not that informative [16:52:24] default TA model, like evrything else, given new doc, removed [16:52:26] next? [16:52:29] can't get much smaller. [16:53:01] Henk Uijterwaal leaves the room [16:53:08] andrei raised issue. lawyers. the people I talked to, if they know PKI. will find it comforting it follows this style. non-PKI lawyer will be intimidated. need another lawyer. [16:53:17] bkuerbis leaves the room [16:53:19] Henk Uijterwaal joins the room [16:53:19] liked parallels with 3647. [16:53:24] jpcerezo leaves the room [16:53:29] aalain joins the room [16:53:29] want to request review again. includes all the registries [16:53:55] Adiel did provide comments, thanks [16:54:12] Qs? [16:54:14] it is alain, not adiel [16:54:18] Andrei. [16:54:24] thank you very much for this work. [16:54:40] when about to send comments, realized new version CP available. addressed many issues raised last time. [16:55:01] wonder if can make one or two steps even further. strip even more. not worried about length, appreciate template, RFC3647 compliance. [16:55:06] content, defns good. [16:55:09] much less in new version [16:55:18] still wonder if we can strip refs to potential apps, with informative nature only [16:55:30] only have full stop at validation of claims of internet number validity [16:55:35] not refer to route, tx, anything. [16:55:46] intro can in principle. but like to see this really bare-bones [16:56:09] still needs work on sections regards to reasons for revokation. may clash with more volatile stuff eg policy development in RIR, business changes. [16:56:16] either reference, or move outside CP [16:56:30] as example, termination of CA. also may be mis-interpreted [16:56:56] talks about termination of CA as conquence of addr holding moving upstream. wonder if LIR cease to exist, CA still exist, can see clash/misinterp [16:57:17] willing to contribute, just want to clarify not terrified by 47 pages, see potential problems if enter into areas subject to different discussions [16:57:18] Kent [16:57:21] easy to remove examples. [16:57:29] bkuerbis joins the room [16:57:32] if point out other places, (clearly have read and welcome that) [16:57:35] will take comments into account [16:57:50] Randy IIJ Andrei, speaks to serious concerns. support. especially termination. [16:58:19] Kent. Randy reiterated what Andrei said, particularly part to revokation/termination to be dealt with [16:58:37] its a CPS thing, thought we'd done adequate job, but will do again [16:59:03] Randy RIPE dubai, there was very serious concern of the 'impedence mismatch' between ripe policy and certificate policy in areas of expiration, revokation, etc etc [16:59:19] I think Andrei was speaking to that. I seriously support his concerns. Steve was also at meeting and understands them [16:59:47] Henk Uijterwaal leaves the room [16:59:47] lixia joins the room [16:59:55] Henk Uijterwaal joins the room [17:00:00] now discussing http://tools.ietf.org/html/draft-ietf-sidr-ta-00 [17:00:03] Geoff Huston [17:00:31] gigix73 joins the room [17:00:34] glenncarl joins the room [17:00:58] this has been the discussion of a number of IETFs, on the ML [17:00:58] the topics sort themselves into two areas. [17:01:09] which entities should nominate for putative TA, secondly mechanics [17:01:13] originally this was in section 6.3 of rescert profile [17:01:24] when that document was offered for WGLC, that particular section had substantive comments [17:01:38] either we fixed it there, or split it out as distinct doc, let rest of profile doc be less contentious [17:01:43] concentrate issues [17:02:01] in discussion with WG chair sandy, authors decided to place in new document [17:02:09] cleave document into two. new draft with material, few changes [17:02:15] small number of editorial changes [17:02:25] but do talk to WHO as opposed to HOW. [17:02:31] draft is silent on being proscriptive on WHO should do what [17:02:43] exact text. "does not nominate any organizations as default TA for PRKI" [17:03:00] reasons in opinion of authors, falls outside WG direction relating to proto param function [17:03:13] goes beyond normal IETF WG direction to IANA. [17:03:47] second reason. many forms of use, of technology. not entirely, exclusively relating to public use number resources. can be used in private, semi-private contexts, Trust anchors would not revolve around public number space. [17:04:00] for spec to be broadly applicable. don't nominate WHO, just HOW. [17:04:14] does make oblique obs, for MOST relying parties, IANA in a unique role to do PUBLIC [17:04:18] as far as document goes. [17:04:27] rest of document is HOW. no real change, some terminology clarifications [17:05:06] works on two-tier model of TA. allows, 3779 extensions in root cert to vary, while still allowing tA material to be constant. works pub, priv, and aligns with PKIX working group. [17:05:09] diagram how works [17:06:00] Henk Uijterwaal leaves the room [17:06:07] aalain leaves the room [17:06:16] Henk Uijterwaal joins the room [17:07:33] Randy IIJ [17:07:51] nice to see RIR social, political disfunction in one document [17:08:05] given your previous, starts to point to IANA as indeed the root TA. why this complexity [17:08:20] why use an ETA, and an RPKI TA? why wrap in CMS? [17:08:40] if going to have the trust anchor, where RIR gets next /8 why complexity [17:09:19] Geoff intention here is to create structure which can be used in many contexts, not just private spaces. VPNs, communities, same technology, without using [17:09:24] Randy prefer simpler technology [17:09:36] Geoff, if material inside 3779 TA changes, that trust anchor has just changed. [17:09:45] Rob are there actual cases, where that material has to change? [17:10:06] Geoff in terms of creating certificate structure, community of use, not neccessarily wrapped up in the public domain, has advantages. [17:10:17] in a related draft, profile draft, use of RPKI by SEND. [17:10:32] once start moving into more general uses in other domains, 3779 ext is not always permanent and constant [17:10:38] this allows some movement without change in trust. [17:10:57] second reason, working in conformance with PKIX with TA work. busy creating structure, conforms to this, more generalized, [17:11:14] Rob. understand mechanism. part of group designed [17:11:19] understand circumstance want to use. [17:11:25] want recommendation only used when neccessary [17:11:41] use case in public space is dependent as the RIR disfunction not ack IANA [17:11:46] if that was resolved, would not need this mechanism [17:12:01] said repeatedly. ETA, ETA-EE are conform to arch profile in allr espects except 3779. [17:12:29] suspect its not correct. things in profile, might want to consider changing eg AIA exts, certpol might not be the same, laundry list not all applicable. did go through when wrote words. [17:12:34] Geoff did check, will do another look. [17:12:46] Steve [17:13:00] to clarify. we do have work in PKIX with TA mgt. is a format for base level TA representation [17:13:16] we are using that, the next rev will clearly show. email with carl wallace, doc in PKIX [17:13:46] using that low level rep inside this environment. not quite fair to say what we're doing has this compound structure, but in PKIX, the TAMP activity is focussed on how entities which manage and control TAs in a set of devices do it. [17:14:04] different to whole model. its a push model. this is how I do it. we can't take advantage in this env. [17:14:09] Henk Uijterwaal leaves the room [17:14:12] other Q, on the table, raised [17:14:21] Henk Uijterwaal joins the room [17:14:41] are there uses? in other contexts, yes, only for passing around. ultimately, in my TA store I can create self-signed, declare it to be, and do what I want. [17:14:51] Randy sign anything I want [17:15:18] Steve but this is useful when have environment halfway inbetween. pre-assembled stuff, if incorperate locally, consistent with other things. [17:15:25] ULAs [17:15:35] for passing around [17:15:56] Rob suspicion is, for straightforward 1918 doesn' [17:16:00] doesn't need this [17:16:16] steve does raise interesting point, more complex. don't want to run pvt that way but who knows [17:16:26] Geoff look at the touting of ULAs erzatz pi space [17:16:30] there are issues around [17:16:39] Rob. disagree about use, but hear you [17:17:04] PKIX wg, there is no proof of termination [17:17:22] this is a little bit of future proofing. we're bad at that [17:17:46] If there was something here, which said "for pub space, not needed" [17:17:58] can do in strange private situations, consent, might feel more comfortable [17:18:33] Rudiger [17:18:44] well ok, not really into deep details of PKI mechanisms [17:19:03] find it kind of threatening, to see additional complexity, VPN stuff would be supported this way [17:19:09] would seem pretty obscure to practitioners [17:19:30] what I would expect, either explicit how VPN supported, how different addrspaces administered, identified not here, [17:19:39] or, keep the thing simple or straight for public use [17:19:44] Geoff quick response. [17:20:14] if concept of trust anchor, material long lived, constant, for decades, and, create one of these, using 3779 ext, describe resources you have, and may changein next few months, years, then you have a problem. [17:20:28] Henk Uijterwaal leaves the room [17:20:29] cannot create the material with a lifetime of decades, when the material doesnt [17:20:37] Henk Uijterwaal joins the room [17:20:42] identity may be long lived, unchangeing, bits are not [17:20:59] if wish to make long-lived material distribute using 'granite' rather than 1/0 becomes difficult if the payload changes [17:21:13] this substitutes something at the top, long lived, persistent, to wrap the changing part [17:21:19] thats the motivation behind this structure [17:21:25] at the BACK of this is a second debat [17:21:29] what are we building this fore. [17:22:01] inside the number model, always no part, has long lived persistent constant association with the resource set. not the RIR, not LIR, not ISP. none of us do. apart from IANA [17:22:19] we then get into this issue, at the heart of this. Should the IETF scribe in, by the tech, a role for IANA or should it be a more generalized view [17:22:28] in the heart of everyone here, aty the mike, me too, is this debate [17:22:36] inside this, I am deeply conflicted [17:22:48] I represented that view of the employer, had a view, unwilling to script IANA a priori [17:22:52] as far as I can see it at this point [17:23:02] I am not going to represent this view. hve to be represent independently [17:23:05] document doesn't come down either ways [17:23:19] the WG can do, standardized technology, general applicability, tried to do in this document [17:23:31] what position is neutral, allow any position [17:23:45] don't be wishywashy, describe one view let everyone else [17:23:49] Randy [17:24:08] the first part. there are two address space comes in two, comes into three, not two segments [17:24:31] 1918, came from IETF, speaks to pvte, rudiger could for VPN, cut 3779 for all 1918 [17:24:37] everything else will come out of natural public [17:24:40] never has to change [17:24:58] more to the other. [17:25:17] how much encode, complicate technology to allow the RIRs to continue the social agenda, don't support [17:25:22] Danny McPherson. individ [17:25:33] ryanshea leaves the room [17:25:37] given self admitted conflict, and RIR, WG chair, TA, direct implication, take issue with document [17:25:37] glenncarl leaves the room: Disconnected [17:25:45] 5x size of original [17:26:00] if other requirements exist, need to be enumerated, give heavy discus [17:26:07] prefer not WG chair [17:26:23] Geoff. [17:26:27] not 5x [17:26:30] its boilerplate [17:26:40] secondly changes shown here [17:26:43] Henk Uijterwaal leaves the room [17:26:47] thirdly, sandy did call. [17:26:52] Henk Uijterwaal joins the room [17:27:03] Sandy. my call: consider it to be already adopted by WG [17:27:16] material already in rescerts draft. if you feel was wrong call, can discuss [17:27:22] Randy agree with Danny wrong call [17:27:29] but propose work adopted WG draft [17:27:37] Danny given conflict, recommend care [17:27:39] Rob Austein [17:27:46] Geoff did pretty good job summing up. [17:27:48] the WHO slide. [17:28:00] motivation, some of us unhappy with RIR position on this [17:28:03] its a cost transfer. [17:28:15] the RIR have internal issue with respect to each other, IANA, vexed space. not trying to trash [17:28:28] difficulty is exposing in public PKI tx cost to R-Ps [17:28:54] if you have at this point, 6 trust anchors, then there is a matter of local policy, every RP has to apply local policy, sort out conflicts [17:29:00] I know IANA, RIRs swear won't happen [17:29:03] but, stuff happens [17:29:29] embedding dont make the rest of us deal with this [17:29:31] don't give the RIRs a hard time [17:29:34] want a single tree [17:29:37] want it cleaned up [17:29:48] me too :) [17:29:51] Sandy [17:30:00] not certain how to proceed. should this be a WG draft? [17:30:07] people wish to see Q of adoption sent to list? [17:30:42] Randy in the spirit of Geoffs well phrased tactlessness, think some of the feeling people may have about that, if the document does not have the complexity we've just discussed, is it neccessary at all? [17:30:49] Not saying it isn't [17:30:56] but saying emotionall thats whats in people [17:31:16] which is why, I as a strong opponent of encoding this social dysfunction,was willing to adopt to discuss [17:31:23] Sandy do think should be accepted [17:31:40] Randy WG should decide. but I do support [17:32:11] Jason Schiller Vorizon/UUNET [17:32:15] discomfort as Op. [17:32:23] need mechanism to deal with inconsistencies if multiple roots [17:32:33] satoru.matsushima leaves the room [17:32:38] dont care what mechanism is. single tree is fine. have to do something else for pvte [17:32:57] or not single tree, some mech, maybe this isn't the right form. uncomfortable if move on multiple trees. [17:32:59] Henk Uijterwaal leaves the room [17:33:07] aalain joins the room [17:33:08] Henk Uijterwaal joins the room [17:33:14] Geoff. do you believe that there is clean unambiguous repos of knowledge of disposition of number space, today? [17:33:22] not could, IS. exists [17:33:26] Jeff. could be better [17:33:34] Geoff I would assert the same. no such clean understanding [17:33:53] satoru.matsushima joins the room [17:34:03] given, then how resolve? 7/8 43/8 188/8 191/8. long history here. when try and craft 'who has what' right now, there is massive problems. [17:34:13] Randy one root will clarify [17:34:24] Geoff but awfully difficult to construct cert chain [17:34:35] Rudiger. whats the value of certificates about fuzzy stuff. [17:34:43] are there parts of resource world, where things are clear? [17:34:49] can we certify thjis? [17:34:52] this is easy [17:34:56] from root? [17:35:09] Geoff gets down to deep Q. heart of the debate. is all of the numberspace clear? [17:35:16] are parts clear who did what/when? [17:35:22] do you certify what you understand? yes [17:35:23] to get certified, you have to go through some process to verify your right to the resource [17:35:29] is that a 0/0 no? [17:35:38] so if not 0/0 how do you get there? [17:35:39] RIR's have process for that today - and it has nothing to do w/ issuing certificates [17:35:43] Randy red herring? [17:35:49] Geoff. no think its substantive issue [17:35:54] Randy total red herring [17:36:22] benno leaves the room [17:36:29] benno joins the room [17:36:32] having 5 or 6 roots, doesnt change problem. still don't know 41/8 goes. [17:36:37] that problem exists whether you try to sign a resource or not - it's entirely beside the point [17:36:48] you can still with one, or 93, same people have to decide [17:36:51] I am willing to say what happens to 41/8 [17:37:07] in other words, if one, or 6, ARIN still has to say "am I willing" or IANA or RIPE or [17:37:10] or Bill [17:37:26] anywhere in the tree somebody could say, willing to do it, go up tree, willing to certify if you will [17:37:29] does this WG decide? [17:37:53] Geoff I belive saying 0/0 forces it to IANA [17:38:00] Rob/Randy its their job description [17:38:07] I want to see where APNIC goes for its next /8 [17:38:11] Geoff thats a Red Herring [17:38:16] its not about the future, nor recent past [17:38:20] its the dead and buried history [17:38:36] Rudiger. I don't want my admin staff figure out, believe certain certs from ARIN, in competition withone from APNIC [17:38:56] if both claim are authoritative, would like IANA as neutral judge. if no decision, that address space can't be used. [17:39:04] Geoff net 7. IANA and ARIN record differ [17:39:08] its a problem [17:39:20] Henk Uijterwaal leaves the room [17:39:23] if you say the IANA reference holds, I'm not sure everyone would agree, including holders of /7 [17:39:26] sorry net 7 [17:39:29] Henk Uijterwaal joins the room [17:39:38] Rudiger if people disagree small parts, local significance doesn't matter [17:39:51] global significance, need somebody to take global role [17:40:16] probably will have to bear a cost, figure out whats there [17:40:20] then the resource holders need to take that up with the RIR's - or the RIR's with ARIN.. they could have/should have done that long ago, if they saw it as a problem [17:40:51] [if want thing said to mike, say so =ggm] [17:40:55] if disagreement *ever* occurs: isn't that a signal of some errors creeping into the system? (or I'm totally confused here) [17:41:01] Jason. don't want conflicting info in different roots [17:41:13] carl-ietf joins the room [17:41:18] or mechanism to ensure don't have conflicts. don't care what process is, so lopng as exists [17:41:32] not having process, makes uncomfortable moving forward with multiple roots. [17:41:37] value is global uniqueness. [17:41:44] if not case, fragment internet. not valuabel for customers [17:42:09] lixia: geoff is saying there are disagreements today, how do you handle that... Geoff's answer is multiple roots.. I'm saying, conflicts exist today, resolve them.. the SIDR stuff doesn't change anything, they should be resolved just to be resolved [17:42:09] Geoff. to be brutally frank. certain amount of info held at IANA doesnt reflect reality what next? [17:42:27] Jason start with well documented case, let ppl make decisions independently [17:42:28] clean up the data [17:42:41] benno leaves the room [17:42:51] benno joins the room [17:43:20] Rob Austein. be careful about this argument. because. asking for, with multiple root solution, take ARIN 7/8. take as read its a disaster don't know details [17:43:29] asking that users make decision ARIN more trustworthy with IANA [17:43:36] Geoff mistunderstood but press on [17:43:50] Rob but asking users make decision local policy. asking them to decide, because IANA and ARIN can't agree [17:44:11] choosing which party to believe in a dispute is really hard for a global company [17:44:17] do not believe that is appropriate. Jasons arg is correct. will get sorted out when needed. who cares? get on with things. [17:44:30] dont have to solve here. here, build system RPs can use without getting into this [17:44:37] Thanks for the explanation! So that moves the question to next one: so the desire is that all conflicts get successfully resolved/removed? (I might call it a wish:) [17:44:38] Geoff I think thats a mischaracterization of what I said [17:44:50] Rob ppl trust RIRs more than IANA game. [17:45:05] then why not 'trust NIR more than APNIC' or 'RANDOM ISP more than RIR' -sounds ugly to me. [17:45:11] from PoV RP, be careful what you ask for [17:45:21] Geoff. entirely mischaracterization of players. [17:45:43] jpcerezo joins the room [17:45:45] its not what is, or will be happening. its what happened in 1985, 6, 7 tape records, printed records, handed down in incomplete forms. various parties duplicated [17:45:56] not clear understanding about it. legacy agreement debate has shown [17:46:01] its not about the new stuff. its the old stuff [17:46:11] so the issue is. is it possible to say all is certified? [17:46:22] Rob not only disaster [17:46:35] Randy its not what happened in the past,. its who will sign what? [17:46:55] Sandy have argued about this many times. have 45min left to go. spiralling. not making progress [17:47:06] Dave outgoing AD. last word. [17:47:21] make clear. WG must decide if going to preclude mutiple trust anchors [17:47:34] eng pov. very hard to preclude mutiples without strong arguments [17:47:57] if going to include, the discuss pro.con must be clearly written down. not at mike, ML. pro and con of single, multiple need to be clearly discussed, enumerated. [17:48:09] please decide if going to preclude, then have answer. if include, must discuss pro/con [17:48:21] will not decide layer 9. but layer9 needs information [17:48:36] present in that way. accept doc as starting point, decide. then debate [17:48:39] first to decide [17:48:55] Randy has been written before [17:49:16] Dave not consensus pro/cons well understood. but please decide if going to exclude an entire scope of engineering from this [17:49:17] ASHIDA joins the room [17:49:27] I recommend, its impossible to preclude a decision set since interest in using it [17:49:54] Randy do other PKis have justify not having multiple roots? in other PKIs in the internet is this done? [17:49:59] Dave solving other problems not applicable [17:50:10] appears to be lot of justification for long period of time [17:50:36] Geoff now presents ROAs and detecting "bad" originations [17:50:54] follows on from discussions over a number of meetings on ROA/BOA. scope [17:50:57] place issue into context [17:51:04] whats the problem [17:51:08] farias joins the room [17:51:17] aim of SIDR work is to identify bad routing info [17:51:21] benno leaves the room [17:51:21] Henk Uijterwaal leaves the room [17:51:22] not good, but the bad ones. [17:51:29] Henk Uijterwaal joins the room [17:51:30] benno joins the room [17:51:55] Danny. august of this year, one of 3 ppl who supports the BOA work now withdraw [17:52:15] No, I believe explicit whats good, and implicit whats bad. [17:52:18] Randy AN aim. [17:52:25] Geoff minor quibble but ok [17:52:37] say everyone all trying his/her the very best of the best to remove any/all conflict, did I get it right by saying that no one needs to worry about conflict ever occurs. [17:52:37] aalain leaves the room [17:53:19] want to make point, if assume world is black and white, then thats fine. [17:53:22] Randy don't have to do that, to know whats black or white. [17:53:30] Randy can say whats true and what you don't know [17:53:41] if you start from the assumption the aim is to find whats bad. leads to some thoughts [17:53:52] when you ask what sort of routing info is bad, two kinds come from RPSEC. [17:54:06] integrity of whats passed, based on provenance: who passed it to you. represented in AS APTH [17:54:13] at this time, ASPATH not in charter [17:54:21] restricted work is more about ORIGINATION not provenance [17:54:38] venn diagram, deterministic world, if everyone uses ROA, everyone. all the time [17:54:58] then its easy: what isn't inside a ROA is ok, the anti set is the complement [17:55:03] partial use of same information. [17:55:09] you don't know everyone is using ROA [17:55:25] the rest is difficult. some is valid, but not in ROA, some is lie [17:55:33] set of ROA is easy, distinguish lies, and not playing is fuzzy [17:55:45] can;'t cleanly tell absense of ROA means anything at all. [17:55:51] whats bad? [17:56:08] if no ROA then its whats not in public use [17:56:20] but if ROA, and I say one thing and more specific seen, thats bad. [17:56:29] aggregate of whats AUTH. [17:56:38] same prefix, but not Authorized [17:56:45] [17:57:12] what seen in ML, discussion [17:57:15] 3 basic approaches [17:57:39] benno leaves the room [17:57:43] Henk Uijterwaal leaves the room [17:57:47] precicely define semantics of ROA. authorised for prefix/range, no other AS have auth, except whats in ROA. unless another ROA authorizes [17:57:51] benno joins the room [17:57:53] Henk Uijterwaal joins the room [17:58:26] another approach. Attribute to Steve Kent [17:58:28] AS0 approach. [17:58:42] if issue ROA, giving AS0, then will never see. now bump maxlength to /32 or /128 in v6 [17:58:54] says, NO as should originate the prefix or a more specific. [17:59:07] a refinement of original antiset model. authorizes nobody unless explicit ROA. [17:59:12] thats how I understand AS0 semantics [17:59:29] and BOA drafts said, see signed BOA, set of prefixes should never be seen [17:59:34] open issues [17:59:44] why use BOA? fair question. [17:59:52] ML fodder [18:00:09] in AS0 approach. explicit mechanism of denyal. [18:00:18] does it assume negative semantics of a ROA? [18:00:23] in AS0 have list, and 0 is PART of the list [18:00:36] interesting concept. probably not valid [18:00:59] no no, a ROA only talks about range of prefixes between length, maxlength and doesn't speak to any more. [18:01:06] aggregates? in either ROA/BOA [18:01:14] seen spamming, deliver /8, spam from holes. [18:01:24] no mechanisms allow to say 'thays wrong' [18:01:34] should any of these methods handle the problem? [18:01:39] comes from 'partial deployment' [18:01:54] underlying question, when only some ppl playing, what does it mean? [18:02:07] one arg: issue ROA, then safe in assuming, issued for all possible uses of prefix [18:02:13] if seen not in ROA, set of ROA, call it bad. [18:02:34] that definition is "its all or nothing" if you play with ROA. for prefix, nominate all potential valid, all or none. one view of partial deployment [18:02:45] another arg: play with ROA, reserve right to not ROA elsewhere [18:02:51] some folk might say silly, but possible [18:03:10] should issuing ROA force more specifics to issue? forced more specifics? some yes some no [18:03:16] inside the charter we HAVE to deal with partial deployment. [18:03:32] in world of partial deployment. black and white? or relative local pref setting? [18:03:48] are some omissions more serious than others? b&w or shades of grey [18:03:55] one way forward. [18:04:02] take first two approaches, mash together in this way. [18:04:02] Henk Uijterwaal leaves the room [18:04:10] Henk Uijterwaal joins the room [18:04:15] explicitly define semantics of ROA, what it says, and no more. [18:04:40] AND if want to talk about more specifics, use AS0 with longer max. [18:04:44] interested in other approaches. [18:04:56] the BOA draft is dead. but need to replace with exact semantics of a ROA. [18:05:08] searching for contributtions, what the explciit, not implicit semantics of a ROA should be [18:05:10] Rudiger. [18:05:13] very simple [18:05:42] ROA stands for authorizing the set of routes it lists with exact match. and it IS a positive statement [18:05:53] what we need is the opposite of BOA. the AS0 thing can be used for it. [18:06:16] what you want to have, is, the owner of address space states in some way, that this chunk of address space will have full ROA coverage, where it is authorized [18:06:31] having the actual ROA saying "this prefix, range of prefixes is authorized" [18:06:58] gives positive statement anyway, having no ROA registered, and having statement of AS0 covering the space of the prefix "if we see a route with that prefix, and no ROA,. then its fake" [18:07:32] we don't make statement about things not covered, by positive ROA, as far as the space also is not covered by AS0. if covered by AS0, then look if positive statement or not, and know if good or bad [18:07:46] for things which have no explicit positive ROA, and not signalled by owner of address space to be covered with ROA, don't know [18:07:48] thats partial [18:07:59] thats pretty simple, straightforwward semantics [18:08:11] Geoff that is precisely what this slide says. we agree [18:08:21] ROb if parsing this, completely agree first part. [18:08:27] do not currently see need for second. [18:08:38] believe its inoffensive way of explicitly stating the deny, it works [18:08:48] benno leaves the room [18:08:55] benno joins the room [18:08:55] if people playing on this in routers, this is plausible way to do it. want to hear if rtr ppl want this capability [18:09:02] Randy three things [18:09:22] AS0 hack, was steve kents inner 'socal' getting out. put semantics into comment statement [18:09:33] secondly, person writing code, into writing keeps looking down at laptop. [18:09:48] thirdly. does have draft out there, it does speak to this issue. says how the router is going to decide [18:10:18] first statement is correct. it gets more complex [18:11:31] Geoff whats maxlength of a ROA in this model [18:12:15] Ross two overlapping ROA, choose more specific [18:12:21] Randy if validatable, yes its ok [18:12:33] Ross depends on way go. [18:12:51] from my perspective, first para I am happy with that [18:13:03] if you want to block, no subdeleg, max /32 or /128 be done with it [18:13:12] if you want to play with AS0. playing magic numbers. bad things. [18:13:22] Randy separate two issues. disagree. [18:13:42] common case I have 12/8, ROA for 12/8 to my AS, also delegate 12.1/16 to jason [18:14:12] i issue a cert. no difference what max prefix length. NOT IN CERT. I issued cert. [18:14:33] so, if you hve overlapping ROA, then, check certs on longer, if validated by own, chain, then its fine [18:14:43] not issue ROA for all /8, to issue the part down/ [18:14:54] Randy no. ROA looks ugly [18:15:23] Rudiger if you keep AS0 mechanism in, just have to decide, if you cover in AS0 the chunks of space hand out to custs. If you assert AS0, then are saying 'only custs with ROA, can be supported' [18:15:58] AS0 hack, allows to kind of help you document to rest of world if you want to have exclusive source for announcements for address space, or leave open [18:16:12] Randy. please stop calling it AS0. as opposed to a magic widgit [18:16:33] Bellovin calls them negative attestations, I call them Detestations [18:16:37] Geoff. clarify Q, please help me [18:17:00] a prefix owner can nominate any AS. what is the semantics in your view, PFX owner creating for AS0. [18:17:10] Randy probably should not allow [18:17:16] don't like overloading syntax. [18:17:32] Geoff. semantics, syntax, second sentence, is indeed, consistent with the first. its the same thing. [18:17:46] Randy want to argue the semantics separately [18:18:03] Geoff. where I get confused, that first red part on slide [18:18:07] Randy with which I disagree. [18:18:14] Henk Uijterwaal leaves the room [18:18:19] Henk Uijterwaal joins the room [18:19:59] gigix73 leaves the room [18:20:08] Ross its the parenthetical statement which needs to be left in. [18:20:27] Henk Uijterwaal leaves the room [18:20:29] Robert Raszuk leaves the room [18:20:56] Sandy we need use cases [18:22:05] Roque. [18:22:14] carl-ietf leaves the room [18:22:20] whats the need for the maxlength in a ROA? [18:22:28] if delete more specific [18:22:38] Geoff if I auth 10.0/8 and you see 10.0/9 [18:22:47] with that alone, the answer is "I have no clue" [18:23:05] Roque. decision made by RP. up to every ISP take decision [18:23:38] Geoffl. the other meaning is whats struck out: unless there is a ROA. [18:23:49] one mechanism of parsing, make it explicit with AS0. [18:24:15] the other way, is to say, talking about all of it, and the maxlength, says 'no beyond' [18:24:32] Roque. is this an issue characterized when issue or receive? [18:24:34] Geoff both. [18:24:55] Roque ROA today, current spec, I when receive, will be change in validation doc,. how to do, document [18:25:08] Geoff. none of the documents are explicit about the second bit "what it doesnt say" [18:25:18] made BOA. people said "wrong thing to do" [18:25:27] so, lets make ROA explicit about what it says and what it does NOT say [18:26:14] Dave Ward [18:26:49] issue having conv. way approaching problem, abstract way have now, difficult, to understand how to proceed. [18:27:09] need examples. prefix, with/without ROA what to do. AS not match [18:27:21] Geoff brains work differently. I can write alg from this. you want to code, then write this [18:27:46] discuss in Stockholm [18:27:57] benno leaves the room [18:28:04] benno joins the room [18:28:25] John Schnizlein leaves the room [18:28:42] Jason [18:28:44] 3 points [18:28:54] Allocate, Assign [18:29:03] David Cooper leaves the room [18:29:03] allocate is downstream and can subassign [18:29:07] assign means not sub-delegatable [18:29:25] two types of routes for me as provider. infra, in my own. need to protect "only me" [18:29:35] rest of space, allocations to downstreams. want to document. part of my agg to them [18:29:42] they can originate, and more specif and subdeleg to custs [18:29:58] may be cases have agg, mutliple custs, some may use ROA, some not. want to make sure doesn't break [18:30:13] satoru.matsushima leaves the room [18:30:17] farias leaves the room [18:30:19] Randy would you issue ROA [18:30:22] Jason don't have answer right now [18:30:32] subdelegs, dont want to keep carving up ROA. [18:30:52] want 'I own entire, there aremore spefics, go use' thats how routing works. lets make it work how routing works [18:30:59] chunks moving down the chain [18:31:00] Randy what he said [18:31:04] Danny indiv. [18:31:16] agree with objective in clarifying. clarifying to remove need for BOA is good thing [18:31:21] steve kent bbn. [18:31:34] if you have chunk, big piece, not alloc to anyone [18:31:49] are you saying want no mech to distinguish its not auth? thought I heard that. [18:31:55] Jason. didn't mean that [18:31:57] weiler leaves the room [18:32:20] if get /16, ROA then cust assign. don't want to come back, have to continuously shrink unalloc [18:32:26] easier for me, more specific to take on that functionality [18:32:43] HEather. disagrees. some use ROAS, some not, should break [18:32:49] more security focussed than I [18:32:57] Roque clarify. want to work as routing today [18:33:30] dont see whats new. [18:33:55] Sandy can you be more specific about what Heather said about some suballoc with sub do ROA, and some don't that should break? what? [18:34:06] Geoff considered an invalid use. once Jason has covered, anything not in ROA is bad. [18:34:08] benno leaves the room [18:34:14] Danny agree with your wife. sorry [18:34:17] benno joins the room [18:34:24] Sandy over time. [18:34:28] cut at this point. [18:34:29] lixia leaves the room [18:34:33] thanks [18:34:34] continue on ML [18:34:38] look forward to use cases [18:34:39] nail down. [18:34:44] will continue [18:35:07] ggm leaves the room [18:35:44] jpcerezo leaves the room [18:36:37] benno leaves the room [18:40:06] bkuerbis leaves the room [18:40:58] roque leaves the room [18:41:06] roque joins the room [18:41:31] roque leaves the room [18:41:51] roque joins the room [18:43:32] roque leaves the room [18:48:14] gih leaves the room [18:50:12] heather.skanks leaves the room [19:31:19] Henk Uijterwaal joins the room [19:32:34] ggm joins the room [19:38:45] Henk Uijterwaal leaves the room [19:53:45] ggm leaves the room [20:00:14] gih joins the room [20:08:34] ggm joins the room [20:09:15] gih leaves the room [20:14:01] John Schnizlein joins the room [20:15:53] John Schnizlein leaves the room [22:06:24] ggm leaves the room [22:20:03] ASHIDA leaves the room