Notes RPKI - IETF75 - Stockholm, Sweden. July 30th 2009. Minutes - Roque Gagliano. Jabber - Sam 2) Updated Drafts                                             75 minutes     (b) ROA Format                                            15 minutes       A Profile for Route Origin Authorizations (ROAs)     draft-ietf-sidr-roa-format-05.txt     http://tools.ietf.org/html/draft-ietf-sidr-roa-format-05       presenter: Matt Lepinski -  Digest and Signature Algorithms are in all the documents. Has remove all ref in the ROA Format. Personally believe that Alg. information should be in the CP but that is up for discussion in the WG. Geoff has propossed a separate document for that. (Russ) Many WG has make this mistake. To change algorithms need to discuss all the docs. If you use the CP you need to update the complete CP. This has delayed other work in the SEC Area. Recommends addopting a document that described algorithms and this document referenced in the other documents. (Sandy) Roque realized that one of the problem is that you can get inconsistencies between documents. (Rob) problem putting alg in CP: CP makes eyes glaze over, and i'm not sure implementers will read it. No problem w/ a signle doc, but it should not be the CP. (Roque) also our CP is maintained by difference organizations and thus if for same reason we may need an algorithm change, will have to go through their processes. Concurs on having a new doc. (Chair) Thanks Roque for noticing the problem with the key length in different documents.     (b) RPKI Architecture                                     15 minutes       An Infrastructure to Support Secure Internet Routing     draft-ietf-sidr-arch-07.txt     http://tools.ietf.org/html/draft-ietf-sidr-arch-07        presenter: Matt Lepinski - Subject name not longer only for RIRs as requested in SF meeting. CN are not intentended to be meaningfull and MUST be unique. - New Update this morning, please review. (Sam) Is IANA special case? - No.        (c) Certificate Policy                                    15 minutes       Certificate Policy (CP) for the Resource PKI (RPKI)     draft-ietf-sidr-cp-06.txt     http://tools.ietf.org/html/draft-ietf-sidr-cp-06       Presenter: Stephen Kent - Andrei as a commentator for the RIR give us the feedback from the RIR staffs. We applied most changed. - Removed references to which applications are going to use RPKI. - Some terminology changes to apply RIR terms. - ROA ref. text changed. - Removed mention of RIR and trust anchors. - Removed mention of LIR. - Removed CP approval procedures to be made by the organizations administering the CP. - We may need to go back to this as the CP covers also the ISP and other organizations. (Randy) What is call-out? - Organizations administrating the CP (RIR+IANA) will manage the CP Update. (Sandy) Co-chair hat off. The responsability of requesting a renewing is of the subscriber? - Yes. - Key size. Elaborate in a way that the algorithm and key size may change over time. Agree with Geoff and Russ about having a different document. - Remaining issues: - Where will you find the CP? - Non-verified subscriber information? We have the SIA. We could just modify the text. SIA is not critical extension is not needed for path validation. - Revocation. Can anyone revocate a certificate unilateraly? The best is to change it to the CPS. - 6.1.4, what needs to be said there. - Key size, looks like agreement in the meeting, needs to go to the list. (Russ) Who approves changes? Things that are local RIR and ISP policies have impact beyond the CP. What is in the CP and has not been left to the CPS needs to be implement in the complete the Internet. Looks to me that the CP should stay in the IETF and the RIR maintain their CPS. (Randy) If you use a generalization on the RPKI signed object, can we use RPKI to sign purchase orders? - Fair question, we can add text that signed objects needs to be in IETF standard track. (Randy) Reference to the NRO? - No. (Andrei) Thanks for adding the comments, their where from all RIRs. (Randy) Thanks to all the RIRs for checking the doc. (applauses).       (d) RPSL with RPKI Signatures                             15 minutes       Securing RPSL Objects with RPKI Signatures     draft-ietf-sidr-rpsl-sig-01.txt     http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-01       Presenter: Robert Kisteleki - minor changes. - added text on URL safeness. - text normalization modified. - added text on number resource coverage. - certificate that signs must have something to do with what is signing. Future plans: - more normative text. - appendix with example. - running code for next IETF. (Steve) two things concerns me about the certificate that signs the object. You need more specific information, need precision. (Robert) let me know if the text is not sufficient. (Steve) many things in RPSL is orthogonal to RPKI, that worries me. may be no consistency with CP. (Robert) I respectfully dissagree. The holder is making attestation about those resources. (Steve) The application lightwave the CP, we should not allow that. (Randy) The mic is wireless, anyone can make a comment.       (e) BGP Protocol Geekiness                                15 minutes       BGP Prefix Origin Validation     draft-pmohapat-sidr-pfx-validate-01.txt     http://tools.ietf.org/html/draft-pmohapat-sidr-pfx-validate-01     Presenter: Randy Bush & Dave Ward. Randy Bush presentation:(actually referred to:draft-ymbk-rpki-rtr-protocol-04) The RPKI and Origin Validation. Why? Prevent YouTube and 7007 accident. Software described. Based in DNS zone update procedure using SSH channel. Dave Ward presentation: Many people involved. The question is how easy can this do in a routers? showed prefix validation logic. what do I do if about exact/specifics matches? iBGP only. Config and policies reviewed. IOS-XR implementation in lab. Less 10us overhead per prefix. The problem is not in the router, all the heavy lift is not there. Geoff added as editor. Feedback please. Working Group document? (Sandy) ROA validation draft was melt with this draft? (Dave) Should talk to Geoff. (Roque)Do we need both this and Randys document? (Dave) Not really, I am not describing how I get the data. (Matt) I believe it is helpful and should be WG item    3) New Drafts                                                20 minutes       (a) Use Cases                                             20 minutes       Use Cases and interpretation of RPKI objects for issuers and     relying parties     draft-manderson-sidr-usecases-00.txt     http://tools.ietf.org/html/draft-manderson-sidr-usecases-00        presenter: Terry Manderson - The idea is to understand the problem statement. Important learning curve for this group. - Please provide information and comments. (Danny) Question about if this is in charter. (Sandy) I would like documents to reach publication point before getting to other topic. (Danny) Is not other topic. (Sandy) I heard. (Rob) It is odd that path validation is not included. If we want to add the temperature of the ocean, we should try some other degrees. (Ross Callon) We do not want to repeat the fun we had in the RPSEC WG. If we want to reach consensus and add path validation in the charter, it will be more happy to add it to the charter. We believed at the time that this was the first step. What about asking in the ML? (Randy Bush) Origin validation is a mayor win, do not open another issue now. Path validation is another 5 years effort. The DFZ is 70% default. Let us finish this. (Russ) As IETF Chair. The charter is clear, requirements needs to come from the RPSEC WG. The WG needs to ask the AD where are the requirements going to come from. This problem is on the laps of the ADs. (Ross) I want this group to finish the work that is doing. I am interested in feedback. (Danny)What we decide here may restrict route-validation. Origin validation is a good point to start but path validation needs to be considered at some point. We should had have a RPKI WG and a Secure Routing WG. (Sandy) You cannot do path validation without origin validation. Policy validation is not path validation. (Paul Hoffman) You didnt get into adjacencies because is not in the charter, as this will be informational cant we just listen it? You can add it and they would have to ask you to remove it which is harder. You can publish things out of the charter as long as it is informational. (Larry Blunk) It is not only origin validation but also max-length validation, that limit the success of path validation. (Danny) Need clarification on comment about policy issue with adjacencies to peers. (Sandy) The AS path only have numbers but does not says if the route should be liked in that adjacency. (Ruedriger) Wether is policy or path validation it is about authorized relationship beteen ASes. (Sam) The IETF is not TOP-DOWN. But I am simpathetic with this WC not be derrailed. (Russ) I agree, go and talk to your Routing ADs. (Gregory) The though that I had with Russ comment. You can do a lot of work in the WG before the work become a WG document. When the operational of the WG allows those topics to become WG items, they can do it. (Sandy) We would like to work in our plate to be finished. (Randy) We are in the middle of a DDOS attack now. We are nearly finished with RPKI but the job was done outside the IETF and there was running code. (Sandy) Uses cases for incremental deployment. Please pay attention to these topics. ---------- Discussion to clarify the interpretation of ROA. A particular case of issuing ROAs was presented by K. Sriram and discussed in this section of the meeting. This was off-the agenda but as an extension of the use-case study. Question was asked about if the ROA should be invalid or no-match, comments were: (randy) invalid. (terry) wg job. (randy) this is an attack. (ruedriger) yuo wouldnt know because it is a different ROA. (rob) aggred that the text is not clear. The manifest helps you to know the complete set of all the ROAs. The text needs to be update. (sandy) is this valid with the current data structure. (scudder)the confusion comes form the max-length size. That is my confusion. (randy) have a practical example about max-length use. (rob) max-length is an abreviation to avoid a large number of roas. (matt) will update the document. This is another reason to addopt Russ paper. (scudder)We are trying to make our rules that are in Dave draft, it is important to pay attention to this. (randy) lets clean the document. (dave) will change the draft. if there is a ROA for this prefixes, it will be invalid. If there is no ROA it will "not-found".  4) New Topics                                                20 minutes       (a) Local Trust Anchor Management                               20 minutes       Presenter: Steve Kent  -each RP decides which TA it will adopt. -not tools to enable this local choise. -getting budget from DHS to implement tools. (Rob) In what basis is a RP taking the desicion on deleting overlaping RFC3779 data. (Randy) If the TA are the RIRs you are fixing mass amount of RPKI space. - yes, but it is a small peace of software. (Paul) be careful in what realying party wants to do. - I have been told that relying party wants to remove remove IANA for Reserved and Unallocated addresses. (Wes George) Isnt this what we do not want to happen. How does this prevent this effect? - Relaying Party is who makes decisions. You voluntarily make this decisions and choose your TA. - Choosing the TA is always a political problem. Not creating the software does not mean people will not do it. (randy) this is a hack that can be used with no-change to modify your view of the world. (rob) please let steve to finish his slides. - Steve: ME FIRST is the mane. (randy) this has all the problem of unique dns root. You and I can have different views of the routing table of the world. I can see this for 1918 space but worried about global unique addresses. - only an issue if there is an inconsistency in the RPKI space and you believe you have better information. - do you believe the Defense minister example is not a use case? (randy) I belive it is but they are not in the internet. - yes they are. (sandy) can we prevent this? (randy) no just as not possible to prevent the use of alternative root servers. (rob) RP can know more but can also know less that the public universe. the problem with multiple roots is that the RP does not have enough information on what to do when there is a conflict. - I local policy can be to have an IANA list of assigned resources to RIRs. (rob) we can cross-sign. (rob) not sure if this work in all level, need to check RFC3779 path validation check. Two options, if you check in each level or go through the root. (terry) what about "albonia" must use some other algorithm? - This work if you have a close environment, you cannot expect all the world to use your algorithm. Others will not validate your material. (danny) do I need to configure my ISP as a TA. - no, it is your decision. (andrei) I can recognize use cases in this work wouldnt you be creating an alternative PKI. - only when you want to override something that changes. (andrei) you are creating an alternative PKI re-using existen components. - you are specified pieces you trust known better.  5) General Discussion                                        30 minutes (sandy) out of time but had time during the meeting, please submit comments to the mailing list.