SIDR AGENDA Tuesday, November3, 2015 (JST) 17:10-18:40 Tuesday Afternoon session III Room 304 Friday, November6, 2015 (JST) 9:00-10:30 Friday Morning session I Room 303 Session 1: Tuesday, November3, 2015 (JST) 17:10-18:40 Tuesday Afternoon session III Room 304 1) Administrivia & Draft status 1710-1720 Presenter: Chairs - Mailing list:http://www.ietf.org/mail-archive/web/sidr/index.html - WG Resources: http://tools.ietf.org/wg/sidr/ - Minute taker? - Sue Hares - Jabber Scribe? Wes George - Note Well - Blue Sheets - Draft status given (seeslides) - Agenda Bashing – no corrections Discussion: · Wes George: What about the SIDR-AS migration draft? Are we doing other WG LC or are we publishingthis draft? I do not think another lastcall is necessary. · Sandy: You had an issuewith the AS migration draft, and a change related to IBGP. After you align the drafts, you can publish. · Just make sure the draftsare aligned, and then publish. · Wes: The drafts are aligned and good to go. I do not thing the issue I raised is blocking. 2) Existing WG Drafts a) RPKI Validation Reconsidered 1720-1750 RPKI Validation Reconsidered draft-ietf-sidr-rpki-validation-reconsidered-02.txt draft-ietf-sidr-rpki-validation-reconsidered-02 · Wes George: What about the SIDR-AS migration draft? · Sandy: Just make sure the drafts are aligned, and then publish. · Wes: The drafts are aligned and good to go. See also related draft: Modified Validation Algorithm Update to RPKI Validation draft-huston-sidr-validity-00.txt http://www.ietf.org/id/draft-huston-sidr-validity-00.txt Presenter: Geoff Huston [no slides] · Geoff: Draft has come through WG for 2 years. The draft is notgoing where. Some folks like it, andsome folks hate. Therefore I floated a personal draft (draft-huston-sidr-validity-00.txt). The feedback on the mechanismswas “Too wordy” and “Too little”. Ihave run out of personal push. I am outof personal bandwidth. I’ve sent an invitation to the list for someone else totake on the WG document. I am fine theWG abandons it or if it keeps. I do notthink this document is going anywhere. · Sandy: There are multiple authors on thedraft-ietf-sidr-prki-validation-reconsidered-02.txt. Have you communicated with other authors? · Tim Bruijnzeels (RIPE, NCC, Co-author): I agree with Geoff. It isnot going anywhere. It feels like a waste of everyone’s time to keep pushing itat this point. · George Michaelson (APNIC, Co-author): Ifwe had achieved consensus on this document, we would have achieved it years agoand shipped this document. There are two ways to look at resources. One says “everything is right all the time”,and the other group that says it is “contextual for the amount of resources”. Many in the working group do not want to gofor the “contextual”. You cannot push astone up the hill. I am not prepared tocarry this work forward. · Randy Bush (IIJ): You’ve only been working on this document for afew years, but for this WG – this time is short. I mean the statement on the time frame (and Ifind that disgusting). I am only who stood up in the [SIDR] WG and stated thereis a case for this draft. I am notstrong for it, and I am not against it. I understand Stephen Kent’s X.509 rigidmethodology (“right all the time”), and it would take something to getcomfortable for the document. You arelosing your patience over far more critical drafts that have been here for 5years. Quit your whining. · Geoff Huston: This author does not find this convincing enough tostay on as an author. · Randy (IIJ): You have my sympathy for pushing a draft for twoyears … · Sandy: Any other the co-authors, e 5 co-authors on this daft. · Carlos Martinez (co-author, LANIC): I remember some heateddiscussions on the beginning of this draft regarding the direction. It is stillthe right path to go. I sympathize withGeoff, the whole process has been hard and frustrating. · Wes George: Not a co-author, and not desiring to become one. Forwhat it is worth, I appreciate the background information in drafts. I think this WG has a horrible habit ofbreaking WG drafts into 15 drafts. Ihate chasing information through many documents. I appreciated the originaldraft with all the information even it runs afoul of what the IETF considersshould be in standards documents. I ask the WG chairs to address the problem ofconsensus. What causes us not to have consensus? Can we unstick this problem?It should not be the responsibility of the authors to address this on theirown. If we have a sticking point, then we need to have the chairs gain “rough”consensus even if it is very rough. I look at the chairs to help us bringconsensus. It should not be that Geoff has to come to the microphone and throw his hands up. If we cannot come toconclusion, do we need to ask Area Directors (ADs) to fix it. If we agree thisis a problem, then there must be something we need to do. If we do not agree this is a problem, then wecan let it die. · Sandy: What we have here istwo diametrically opposed algorithms, and strong camps on both sides. We have noway to meld the two algorithms, and no way to divide the world between the twoalgorithms. We have to pick one of thesetwo ways. We are having trouble pickingone of the two. · Geoff: The authors wrote this draft because we thought we couldlayout part of the validation algorithm, (as Carlos said), it would be lessbrittle because the semantic construct inside the existing validationprocedures treats the bundle of resources as having some innate property as acollection. We thought this innate property is an artifice of X.509 that doesnot have a reality in turns of the operational use. I have three prefix and 2 ASes. I use them independently.I do not need to put all three prefixes and 2 ASes together every since time Iuse them. It is not an operational reality. This draft states if you removethat bundling constraint you actually have a situation where the failure down avalidation path does not cause all subordinates down there to be consideredapriori. We’ve gone through this worktime and time again. We cannot get a headway between people saying “this offermore robustness” and folk saying (as Randy paraphrases) “These are X.509certificates – how dare you much with them”. · Randy: Could the chairs gets some get guts and go on the mail listand declare “there is no consensus”? This will fail and we can more on. Thenask, for people on either side to say “it is ok to let it go”. Does anyone wishto speak strong against this proposal? If they do not, it pass. It they strongobject, then there is no consensus. If they do, then there is no consensus. · Doug Montgomery (NIST): In concept, I support the idea because ofthe resistance to deployment due to the brittle system. I remember going backto a previous meeting we had heard the state of implementations. I recallconflicting viewpoints on the ease of implementation (Easy to implement/hard toimplement). Could you we review the state of implementations at this time? · Shane Keer (?): I can comment on the implementation. It is workingin our implementation. · Tim Bruijnzeels(RIPE NCC): I can comment on the implementation. Itis working in our implementation. For us it was quick simple, ather thanrejecting a certificate, we accept it with a flag. We provide an intersectionof the current resources on the certificate and the new resources on thecertificate. And we have code remember the resources associated with acertificate rather than look it up. We also need to support inherit capabilities. In our case, it was quite easy to implement. · Rob Austein (xx): I’m going to present 1.5 positions. For my ownwork as an implementer it is straight forward, although I have not implemented thismyself. I do not think it is particularly difficult. Essentially, it is movingpieces of code that we wrote years ago to a different place. It is a slighttweak and not that “big a deal”. o I am going out ona limb and try to channel the folks at BBN. I’ve spoken to the folks at BBN, and I think their opinion that the waythe BBN implementation has been done it would be difficult. The reason for thisis the people checked all the CA certificates all the way done. Skipping those checks in the future would beproblematic because the BBN code is doing optimization, and these checks breakthat optimization. o Returning to mepersonally, I’m not sure I care how important that optimization is. I am notsure they have data testing to show the importance of that optimization to the system.I have not heard reports on that optimization. My own testing indicates the optimizationis not that critical. There might be apotential scaling issue here, but I am not personally worried by it. I believe they have a legitimate concernsregarding their optimization. · Rudiger Volk: I am reluctant to throw this in because I am askingabout things that are slightly aside. Nevertheless, I wonder if the motivationfor doing this feature is enforced because the root certificate source setsmight long-term systematically overlap. Last time I check the rootcertifications, there were overlaps and these overlaps did not seem liketemporary things. · Chris: I do not think any of this changes Geoff’s currentposition. Why don’t we stop this portion of the session? We thank this for histime on this draft. Are you willing to hand-off the xml for this draft if atthe end of the mail list discussion, we can · Geoff: Yes. b) RRDP Implementation Experience (1750-1800) RPKI Repository Delta Protocol draft-ietf-sidr-delta-protocol-01 https://tools.ietf.org/html/draft-ietf-sidr-delta-protocol-01 Presenter:Tim Bruijnzeels (RIPE NCC) Discussion: · Tim: Have people read this draft. · [4people raised hands] [Questions] · Tim: Do we stillneed hashes in the notification file to verity the validity of the servers? · Rob: I am not sure weshould remove these notifications. These notifications are still useful as anintegrity check. It is useful to keeparound to determine if you have the things you expected to. · Tim: I can keep this information around. · Jeff Haas (Juniper): Another reason to keep it around, it isimportant to keep the hashes around to check within a network. Another case toconsider is if the data on server is subverted. Some potential is that you can cache the information in your network anduse the hashes for that (security) purpose. · Tim: I can put these back. [Distribution structure] · Tim: Is there a case for polling for notification.xml more oftenthan once per minute? · Jeff: A comment on the one minute. A lot of the issues here revolve around what your distributioninfrastructure looks like. If you are a distribution network the size ofAkamai, then your real problem is distributing the information across yourCDN. If you do not a large distributionnetwork, you are encouraging people to hit the thing often (do theredistribution often). If do you this methodology, you will have a lot of peopleconverging on a single server trying to grab the changes. Please consider howyou want to distribute the information and how the distributions impact theload on a particular machine. · Rob: I have the same point, there are [the following] two differenttiming values you want to consider in the distribution: o Caching lifecycle of the information, and o the polling cycleof the responsible party. How much delay is built into the cachingcycle? · I had been assuming that the polling cycle for responsible partieswould be once per hour. I do not see any strong reason to change this pollingcycle. It is important to keep this about 1 hour. · What the notification file timeout tells you is how much delay isbuilt into the caching system. It is important to keep the notification timesmall so there is little delay in the caching system. · Tim: We have people asking us why do my new ROAs take an hour toappear and be validated. Anotherquestion people e of the question is how bad this delay is for routing system.People create the ROAs, but they want to see that the ROAs appear validatingthat everything is working. o I was hoping the cachinginfrastructure in-front of the ROAs, and every AS (~40,000 ASes) runs thisprogram. The server should be able to handle 40,000 hits per minute if it hasthe right infrastructure in front of it. It is a lot of data, but you can do a deltacall to see what has changed. o We would use aCDN in front of the server. o The draft iswritten with CDN in mind. You can alsodo this yourself in different ways. c) Validating an RPKI Repository 1800-1820 RPKI Repository Validation Using LocalCache draft-tbruijnzeels-sidr-validation-local-cache-02 Presenter: Oleg Muravskiy Discussion: · Rob: Speaking as another implementer,please write this down. · Oleg: Questions? · Sandy: Are you asking for text that describes these events, or areyou asking for WG adoption? · Oleg: I am asking for WG adoption. If the current text is goodenough for this, we would like working group adoption. Otherwise, we canimprove the document and ask for WG adoption later. · Tim: I’ve been presenting this between the scaling things. Wethink it is useful to have a document for ourselves and our users. We would liketo make it a WG informational document, and have the WG scrutinize it.Otherwise we can look at different ways of documenting this information otherthan an Internet draft. · Sandy: Are there interoperability concerns? · [heads shake] · Sandy: No real operability concerns. d) OOB Setup 1820-1830 An Out-Of-Band Setup Protocol For RPKIProduction Services draft-ietf-sidr-rpki-oob-setup-03 https://tools.ietf.org/html/draft-ietf-sidr-rpki-oob-setup-03 Presenter: Rob Austein Discussion: · Rob: Page 4 is what we’ve added to RRDP support in the last 2years. Does people want me to explain it? [no one shoutsout. · Were’ going to skip the explanation of how it works. This is inthe slides. · Go to slide Discussion: Rob: I have anXML to transform between the old specification and the new specification? Wouldanyone who has implemented the old please test the new transform. It seems to work for me. Sandy: How manypeople have implemented it? [I see one] Rob: I heard RIPENCC, ARIN, and APNIC have partial implementations. Only my implementation does thefull protocol because no one is doing the publication set-up. RIPE NCC, ARIN, andAPI do first part which is what the transforms cover. Please test. Rob: Does the WGstill want this? We should get someconfirmation on the list before we put more work into the draft. Dr. Kent as for details on BPKI certificationstructure. I’m not sure this belongs inthe document. What this document is about is shipping the BPKI certificates wehave around along with associated URIs. The fact no one has specified is aproblem, but this does not change what we are using operationally. Do we need to make this document wait for a specificationon what the BPKI format is? This is a question for the WG to decide. Rob: Last question,should we ship this now or wait for publication and RRDP? Sandy: Anyquestions on the mail list? Rob: Fine withme. Sandy: Lastchance for questions on this? [Silence] e) World as seenby one RPKI Validation · Graphs of linear counts – no one is doing up/down protocol. Oncewe up/down protocol we will have to change how we do this protocol. · APNIC was the leader. Now theyare flag Discussion: Tim (RIPE NCC):On the freshness, it is not required by the standards – but we are putting asigning time on the manifest when we publish. This might be something you mightcan use. Rob: The sense offreshness was is “how close are the line parties to the master copy on the repository”. If we had perfect connections, then everyonewould be in sync at all times. As weknow, the connections fail and all the implementations are able to tolerate acertain amount of sliding through periods where connectivity fails and the implementationhas to keep current data. The “freshness” indicates how well the “line parties”are in keeping in sync with the repository. For recent implementation, the signing time and manifests are a goodhit. It is possible to have existingdata that has been there for 6 months, but it is the “freshest” data available.The question is how to measure this. Jeff Haas: Effectivelywhat you are asking for is a log file that indicates how often the manifest isupdated. If you just had a set of time stampsfor a given versions, it would give you the data you are looking for. You do not need a document, you just need theoperational data you can poll from each server. Rob: Themanifests have some time stamps on each server, and you can pull down themanifests. Jeff: You want thefull set. Rob: You could infersomething from the full set. This is agood point. Thank you. Andy Newton.(Arin): Regarding the measuring of UP/DOWN, we had 2 organizations down up/downwith us. Now, we only have one. One of them when you tried to measure RSYNCtimes with them, they were letting their server go offline on a regular basis. Whenwe contacted this organization, they indicated the RFC said they did not haveto keep up the server at all time the time. Rob: Ouch. Thankyou. e) Router Keying 1830-1840 Router Keying for BGPsec draft-ietf-sidr-rtr-keying-10 https://tools.ietf.org/html/draft-ietf-sidr-rtr-keying-10 Presenter: Randy Bush [delayed ?} WG Chairs comments at end: · Sandy: This is the end of the agenda fortoday. I have a few process comments. We had WG LC where they were a tinynumber of comments. It is difficult to judge consensus the tiny number of comments.These WG LC deal with Crypto stuff and many people did not want to look atCrypto stuff. Please try to look at the WG LCs for this work. · Sandy: The routing ADs are encourage every WG toconsider to whether or not drafts which are “process” drafts ( overview, usecase, and requirements) are really of value to future of RFC system. These things are true and valid, but areovercome by events. o We have an overview and use case document. TheWG needs to have additional though regarding these drafts are useful for thefuture. Sandy: We have 2 lesstalk because Rob’s presentations were today. We’ll have two talks on Bad things CA might want to do. We’ll be looking for new notes taker and jabber scribe. Friday's Notes: administrativa (sandy): * intro * note well * administrativa * agenda bashing * randy bush * move recondsidered to the end? * sandy: * steve is presenting remotely, can't move * randy: * rest of them? * ???: * what should be moved? * randy: * move 3a up as much as possible? * ???: * can swap 3a with 2b * alvaro retana, cisco: * may only have the room until 10:30 * sandy: * will begin with steve kent in remote presentation steve kent, bbn: * presentation on update to adverse actions independent submission * slide 2 * reorganization fixed some bugs * slide 3 * slide 4 * slide 5 * slide 6 * slide 7 * slide 8 * questions: * doug montgomery: how envision working in hosted model? * skent: * doug: [didn't quite make out what was said] anyone who cares who has resources should have rp code and should be checking it on a daily basis * skent: yes * rudiger: would twist this, other party to run ca, do not need as doug mentioned, filtering, stuff like that. would be really good to have nicely distributed partities to ffer monitoring services that people can subscribe, get alarms if something happens * skent: see that in bgp today. epople charge for it, don't want to prevent a for-pay service, but inr ought to take the effort to fetch own resources to confirm. if you don't want to do it, could outsource it * rudiger: running such a service, like running rp yourself, comes with costs. if monitoring services were organized, fees that finance certificate could include subscription fee for a service * skent: don't want to speculate on how it would be financed; lots of possibilities. in trans claims of people running monitors and logs for free to secure that environment. premature to narrow down how the service might be offered * geoff huston: against adoption. massively assumptive and presumptive. all bad people have to have tatoos on finger. assumption is that all bad things have been categorized. they have not. history shows that what happens ins a surprise. doesn't conform to patterns/actions, leads to tunnel vision. also, lots of invocation of magic. mitigations are amazingly presumptive. some kind of foo that you can broadcast that what you should be lieve shouldn't. ... don't think it's bad to think about these, presumptive to think that you've thought of all things. really are unknown unknowns. has to take into account that this is only the tip. flawed presumption that it is complete. * skent: 1st of all, could separate suggested migitgation from characterizations, deal with it in a separate fashion. wrt 1st concern (presumptive to characterize), from personal experience would disagree. manyt of the bad things seen happen in internet sdecurity are things that people anticipated well in advance. have adopted in many WGs an approach to provide an attack or threat model knowing that it might not be complete, but ogod for evaluating proposals to adress attacks. fact that it's not comprehensive is not a reason to do this. have done it in a number of place. am open to strip out discussion of mitigation if viewed by WG as premature. separable, doesn't need to be in this document. this can characterize the know bad things. if we encouter new things can add, at least we addressed the ones we did know. that's how we make progress * randy bush: if anticipated, then it's an event, if not a disaster. tone is a complete enumeration. presuming that it's complete is arrogant. tone. publishing known issues is worthwhile. separating issue, meh * rudiger: agree with randy, happy to see work on getting taxonomy of what we know. if limits of knowledge lead to tunnel vision, we should not list what we know, then we're blind * tim b: if adopted, good to separate mitigation actions. have issues with them. if mitigations should look at requirements. keep configuration up to date also update rpki, maintain 3rd system, makes things brittle. should take out * sriram nist: ... if have higher ca that owns ... want to target down in validation chain /24, highest ca with /22 can create /24 roas using their ca cert, can set up as announcing more specifics and draw traffic and deny service to target. have thought about that? included in this? * skent: this type of attack isn't covered at the moment, have uncertainty with transfers. long ago question whether to detect situations where the same chunks of addresses/subsets would be allocated... were advised not a good thing to alarm on due to transfers. this is focusing on changes in rpki that overtly affect rpki items associated with inr holder. example you gave would probably not be covered by this. this is the kind of feedback we're looking for. wg can decide whether this should be added, perhaps under security considerations, that aren't covered by the taxonomy * russ mundy: jabber I support doing the work to describe what we know about problems & threats even though it may turn out to be incomplete - it's better to define what we know than ignore it. With that approach, I support WG adoption * randy: geoff, would be happy if didn't provide complete coverage but only what we know? * geoff: if toned down, more humble approach, would make document more acceptable. gives false sense of control. if you pulled that out, could be useful. really caution against tunnel vision. a solution is only for some ills, not all ills sandy: next speaker is randy randy bush * draft router key talks about getting router keys to rpki. draft has been around for a while. describes 2 modes, 1 is outside, then operator workstation also sends key to ca for signing. 2nd is roiuter generates key internally, never leaves the router. good practice, makes it hard to move keys to another router, but does keep key localized. previous draft has router generating key sending pkcs10 to ca to be signed. confess to being totally idiot. how does ca know that router is ... ? it can't. major change in new draft is for router to generate key internally, hand pkcs10 to operator workstation, workstation adds ... then gets the ca to sign and put in rpki. * questions? * tim b: how operator gets certificate to be signed by ca is not defined in doc, correct? * randy: transport between router and operator * tim: no between operator and ca * sean: hand-waived * tim: like to understand... we have a hosted service, can supply interface for users to allow them to upload request * randy: yes * wes george: present to the workstation" mean barf out text? file transfer? what does it mean? * randy: hard to tell router vendors to how. would be nice if ... but don't think that's going to happen. left unspecified. could get help from netconf yang... specifying don't want to do * ???: given stuff that has to go in router, not unreasonable to say that this is preferred * randy: questionable how much has tob e in router. people believe it can be offloaded * chris morrow: dealing with vendors wrt cert mgmt, all are nieve about how to do this, especially at scale. wes has good point about giving feedback about direction. as operator have been telling vendors how to do it. spirit of document ... not super important how it happens, but want vendors to do it a particular way for me * randy: agree, not sure want to fight that battle here, normative ref to another doc * chris: where should the document go? idr? netconf? grow? * randy: probably netconf; trying to configure router * chris: perhaps ask ads in the room to get direction * sean turner: what else put in there, could put in appendix. "if perfec world, here's how you burn key into router..." could put that text, but will be pie-in-sky text * randy: sean can enumerate packages to move in/out of routers, not very well implemented. if people want us to put this in appendix? would make you happy? yu fu, cnnic * deploy rpki in china * did tests * ... * slide 2 * slide 3 * slide 4 * slide 5 * slide 6 * slide 7 * slide 8 * slide 9 * slide 10 * slide 11 * slide 12 * slide 13 * does this work make sense? maybe someone can join us? * questions: * sandy murphy: have you considered the relationship of work with steve kent and adverse actions? * tim: trying to get head around few things. use case 1, iiuc, software you used refuses to sign certificate. you configure engine to ... actual certifcicate excludes resources parent doesn't have. good behaveior by ca, is careful not to issue certificate that would be ivalid. other issues where other childred receive resources, would this be happening in production environement? in our implementation, technically we could, but what we sign ... internal software registry, code tests provisions to ensure that resources are only given to one member, so not sure... would like to separate out -- if there is a problem that two children have same resources, should be focused on software allowing if you tell it to. * yu fu: maybe some configuration of software, will check configuration * rob austein: ca engine just asks backend (registration db), ca says "i have child, what resources should it get"? if ca has resources from parent, it will do that. if put multiple entries in db and say give it to this child *and* this child, it will do that. the ovreall design is intended to be replaceable, could use a different backend system that has more restrictions. general case it does what you tell it to * ??? jpnic: could you go to solution slide? what is the solution? what should be the correct data? comparing issued certificate with what? with database? the data source for the issued certificate and the ... should be the same, right? so what is the solution? if you have the correct info in db, cert should be issued according to db. is solution in RP or in CA? * ???: can check what can be alloc, what can't, is a necessary ... for 2nd part, rp should check if the data is correct * randy: in both cases, you are using ca software that was designed specifically to give authority to the registry's database, not not enforce it in the ca. was a specific design choice. talking about LIRs etc. who have existing database systems that they believe are authoritative. to have software impose a restriction that is not imposed on the database is going to cause problem. they will say fix the ca software please. the place to fix the problem is in how you enforce constraints on your database. transfers * rudiger: don't have documentation on transfers... asked RIR whether they would contribute ... this year, i guess they will report failure in two weeks (randy: there is a transfer draft). what i'm seeing is... if you are holder of resources, leaf user of system, or intermediate CA, certainly should be interested in monitoring global rpki, which might have multiple roots, about what it says about what you htink are your resources. ... something that needs to be done ... transfers that are ongoing ... get an alarm ... monitoring what's going on is very important for many players * randy: yes, agree. one problem with having 5-6 TAs that they can multiply assert ownership of the same thing. even worse if someone claims 0/0. * rudiger: ... * chris: not clear what problem you're trying to solve. in operations, there may be registry that you are relying on, you believe it is true. set of CA software that will sight wahever you give it. at end of day, process must ... need to look at rest to ensure my view is appropriate. if not, need to tell someone. draft doesn't say that. need to restate drive. would describe the problem you see, then offer the solution you see. right now it just says stuff i already know. if you have a real problem, should try to describe that clearly. * rob: about monitoring. not sure it's obvious, both the web-based version and ripe's interface integrate with the rp side and ca side. for our web interface, see what relying party thinks of it. publish, does full loop, here's what it looks like. is this what you meant? ... important ... integrate rp code with ca code. not practical to run just ca, have to run rp as well. sandy, validation reconsidered in pictures: * slide 2 * slide 3 * slide 4 * slide 5 * slide 6 * slide 7 * slide 8 * slide 9 * slide 10 * slide 11 * questions? * steve kent: Unless the yanking is a suprise by A, the subordinate CAs in your example could have reissued certs to subordinates to prevent this problem. * sandy: yes, it's possible if it's known ahead. geoff likes to point out that parent at the top ... might never cease ... giving you a month, all hell breaks loose. if planned activity, can take action to take care of this chris morrow: * slide 2 * slide 3 * slide 4 * geoff: semantics of cert is one thing; bundle was artificial constriant. thought process was bunch of certs in one resource. the roa, suspect bundling is intentional. roa is an atom of assertion and dcomposition is beyond the semantic intent of issuer. what's in cert and what ... may differ, is cp issue. are we happy for roas .... happy with all or nothing, was intent of roa issuer. * chris: on roa, could view roa as what the world should look like. maybe roa should be entirely invalid, o rmaybe all we really care about is ... * geoff: in theor ee cert and roa are meant to match. if ee cert in roa in terms of what's valid in ee, if they don't match the roa my inclination would be to chuck the roa rather than say it's a good roa but only for that /28. * sandy: lis tof things that would have to change. what it should end up being don't know, but these are the documents that need editing * tim: in our ca, combine multiple prefixes in a single roa, don't need to do that. trying to limit number of objects. could create different objects for different prefixes. * doug montgomery: point about what certs mean, in current modells, what's in current certs is function of ... some have been forensically trying to understand their algorithm. as individual holder ... out of my control ... don't want simple mistakes exploding everything ... whether it's clean or not ... ... i couldn't tell what was right in the first place * steve: not sure what geoff thinks revised step 6 is supposed to do ... ambiguities in it ... that modification to the algorithm works in the intended way only for ee certs, which is fine if you only care about roas. doesn't work for ca certs beecause encompassing aspect ... ca certs themselves would be consideered invalid. rp software validates ca certs using whatever algorithm is specified on step-by-step before moving down. as described in revisited text, does not work for ca certs, so premature to discuss how it would fix things without discussing what it breaks. * sandy: please state that on the list if it wasn't already * steve: it was * robert ripe: certs no longer mean what they say? can you elaborate? * chris: cert says /16 for example. for some reason some part of /16 goes away but don't reissue cert. if /17 of /16 went somewhere else, the other /17s could still work. overclaim. if it breaks in wrong place in the tree a whole lot breaks. * robert: thought contention was ... * chris: ... * robert: bundle ... in a certificate, artifical for efficiency reasons, if make mistake in one, could be a huge problem * geoff: mine trap, steve fell into it body and soul. this is not "cert is valid" and "cert is invalid". now says rpki algorithm for a specific set of resources. not trying to answer is this cert valid in all cicrumstances. what resources can be validated by an rp? using that cert and TAs. ... subtlety is lost. resouce-centric, not certificate-centric. in this case it's useful. * tim: implemented this. look at certs in context. even if certs have resources that would be unvalid, we look at resources that would be valid and remember this. * steve kent: algorithm in 6487 is path validation algorithm. your text says that thing that has changed is step 6. if you want algorithm that does something other than path validation, need to say that clearly, and that it isn't path validation. will take more change than just modifying step 6. you referred to resource being encompassed, but 6487 doesn't say resource is input ... if you want to do something different, need to take another shot at this and look at a bigger set of changes and what the implications will be. text as written ... * slide 5 * slide 6 * tim: no strong urge to make more text, but this question (slide 6) is important. if answer is yes, don't mind revising text. if no, just walk away. * doug mongomery: favor of anything that increases operational robustness or even perception of operational robustness. fragility issue doesn't go away. concerned if we go forward with steve's draft, is this just one mitigation mechanism for one problem ... step back and broader set of problems ... * chris: not clear where steve's draft is going, what form it will take. haven't read it. * alvaro: need to make a decision * chris: will put this question back on the mailing list, 2 weeks * andy newton: willing to help if answer is yes * sandy: misunderstandings about what is in revlaidation considerations. geoff would like to confirm reductions in one resource type * geoff: resource type was irrelevant in my thinking. rudiger: * slide 1 discussion? * none meeting done