Minutes for IETF SIDR Meeting IETF73. November 17th 2008. 1300-1500 Salon AB - Hilton. Minneapolis, MN. USA. Chairs: Sandra Murphy Geoff Huston (participating remotely). Minutes taker: Roque Gagliano - LACNIC Jabber scriber: George Michaelson - APNIC 1300: Session called to order. A) Administrivia B) Updated Drafts 1) Two presentations by Matt Lepinski BBN Technologies: a) RPKI Architecture Document (draft-ietf-sidr-arch-04.txt): - 04 Document out, differences with 03: Improved abstract and consistency with other SIDR doc. No open issues, please read. Comments?: Sandy - Route Filters and semantic issues raised by Geoff (the list is exclusionary, the issue was raised during the RPSL discussion last time). Matt - Not in the current version, need to have private discussion of how go deal with this issue. Ruediger - Route Filter Use is not real validation but to implement policy. For doing this you can use different sources of information, better if it is good sources. This discussion of what do we do until we get to the final form of validation has not happen yet (will it in this century?). Geoffry Haas - in support, SIDR should talk about create filters from data. RPSEC work leading should talk about using this data for security preference. If a network chooses not to use, that should be fine. Randy Bush - dont think you want to get into what shades of lipstick on the pig?. Matt - The intention of the arch, document is just that the date in the RPKI can be used as an input for policy desicion. Roque - Please do not mention DNSSEC and what happened with trust anchor material information? Matt - Ok. Stephen - We need to keep detailed information in only one document, open to know about which one. The Cert profile version 15 has reasonable information but we need to keep it in one place. Sandy- Architecture document do not normally have formatting information. a) ROA Format document (draft-ietf-sidr-roa-format-04.txt): Version-04. Changes since 03: - Clarified text on ROA validity. - Addresses in ROA must be a subset of EE certificate Prefixes (not need for exact match). RobertK - Currently you can have prefixes overlapping from different ROAs, the problem is that it can be confusing for implementors. One implementation takes it as "wrong.". Ruediger - What is the problem? this can be a feature. I may want to announce the aggregate and have particular policies for some and not all the more specifics. Overlapping ROAs should be allowed. Rob Austein - Now that we have a use for these, I will change the code. S. Kent - How does people feel about inherit bit in the ROA. Looks to us that can be a problem to developers to have those and not the explicit cert. Rob Austein - Agreed may be simpler to implement RobertK - You still need to go up the chain. Rob Austein - This issue is only for ROAs, do not put in more generic doc. Leave it in the ROA doc. Matt - Will take this issue to the list. Randy - Overlapping Prefixes: Will be working with Ruediger on the unusual cases. Do we want to give funny code about this? Sandy - Any harm to overlapping ROAs? Randy - The code, but it is a consequence of funny arch. Matt - Hopefully will discuss this on the list. Other issue: multiple signature proposal, believe there is not consensus to change. Randy - I do not consent. Ruediger - Cases are so rare that I do not consent. Rob Austein - I do not consent. Sandy - As a WG chair I also believe there is not consensus for this. What is the process on for multiple ROA? The ROA draft continue alive but not consensus on adding multiple signatures to the ROAs. Russ (Author CMS) - No problem going that way. Next discussion raised: BOA & ROA ASN=0: Matt - Transition period, ROA for AS = 0. Can we add text that it should be interpreted as "should not be routable". Randy - Fear of manual trust anchor configuration can be a consequence and we will finish similarly to the current bogon filters. S Kent - Unlike BOA during the transition period this idea will not mean a new mechanism, this is zero changes. Sandy - Would it require changes in the validation software? S Kent - NO. Randy - It would require changes in the BGP path selection in routers? S Kent - Maybe. Ruediger - I would like to have detestation as a way to tell "everything should validate PKI", also in the transition I would like to have detestation for things that I know that should not be there. Dave - Is this the same as BOA? S. Kent. - What it says is that the origin ASN for this prefix is 0. Rob Austein - The issue is the semantic in routing that is a different discussion. Roque - Ruediger mentioned that want to have a detestation mechanism, the question is what is he expecting from the RIR when generating ROA ASN=0 or BOA, that impacts our registration software and may have consequences in time to route. Presentation by Stephen Kent from BBN - Certificate Policy document: draft-ietf-sidr-cp-04.txt Thanks comments. Stephen explained the meaning of the CP document and particularly pointed out that this is the one document every party in RPKI agrees to. Changes from version 03: - inclusion of "bogon" route. possibility of different signed objects (not just ROA). Randy: do we need an RFC? Stephen: not in the current text. Randy: So I have to agree to accept signed objects that I do not know its semantics? Stephen: CP area about issuing Certs by CA. Randy: What contract am I making? Stephen: There is no responsibility of the issuer of the Certs on what it is used to signed. You cannot control what the end users do, you can point out what the intend is: routing security. Randy: Do not have problem to make this distinction. Stephen: will take it to the mailing list. - Change Cert. Authorities, added IANA. CP will be co-adminitrated by IANA and the five RIRs. Mark: You gave it to the RIR and you asked for feedback, what is next? Stephen: Would like more participation from the RIR. And listen to their feedback. Randy: Why does the document mentions "default-trust-anchor" that is something that relying party decides. Stephen: It is normal practice to have that information in the CP, the "normally used" but yes the RP may decide. Randy: As it is a touchy issue, please finesse it. Stephen: Will try. Paul Hoffman: We need this, as it is common practice in every CP. RP will like to have as much information as possible in the CP document. Danny McPherson: There are implications on the decision of the trust anchors and would like to have discussion in the IETF. Stephen: I have some slides. - Key changeover. Includes ISP/LIR, etc. Randy: there are also LIR to sub-LIR, needs to get the appropriate text here. - 6.3.2 trying to explain why the RIR cert change periodically while IANA do not, but the language needs to be modified. - Trust anchor material, showed the current practice. Check the new version of the CERT Profile draft. End of Presentation. Question section: Andrei - I apologize for the lack of feedback. The problem is that it is "tricky". Our legal team is checking it, for the time it takes I can see it is not a simple thing. I also believe that the doc. goes to issues that are still "hot discussions". Example, re-allocation policies are still under discussion. Another thing it states that the use is "secure routing", but the trust is that we are talking about "right of use". Can we put it in one page document? we are talking about different laws, etc. Stephen - This is the formal for all PKI. You are correct it is not trivial. If you want to make changes, we are open to receive them. Not a lot of feedback yet. Can we make it in one page document, NO. You need to ask people that already reviewed a CP before to check it. Andrei - The problem is that the standard template takes you to area you do not want to go. Stephen - We can have sections that can be moved from the CP to the CPS which can be regionalized. Andrei - This is an IETF doc. What would be the status after approved? Stephen - After approval will be publicly available. Randy - Check DNS, for DNSSEC is not PKI and do not need a CP. For Andrei, the CP is for relying parties to tell them what we are telling them they can rely on. Feels Sympathy on the concerns but as a RP likes having CP. Russ - One of the reason for having this document agreed by all the parties is that all the material refers to a policy document, and this is that document. Danny - Can you explain your comment to RFC3779 and trust anchors? Stephen - When validating prefixes and ASNs you need on the top a self-signed cert, with RFC3779 extension, not any CA cert. C) New Drafts section: 1) Presentation by John Mohapatra - Juniper: draft-pmohapat-sidr-pfx-validate-00.txt The idea is: given RPKI, what can the router really do? A work in progress, several contributions received. Need a mechanism to differentiate between invalid and legitimate prefixes been announced. Maintain in POP authenticated prefix and AS cache database. You can also have a database inside the router. The drat talks about the database structure. BGP decision process changed to compare the lookup result before LOCAL_PREF. iBGP vs eBGP: No validation on iBGP sessions. Can we do it in real time? looking to performance issues. There may be an overlap with the roa validation document: the draft started from a different angle, what can we really do?, finished with something that has similarities with the roa validation draft. However there are differences: no "linked validation", #states for validation outcomes, BGP Speaker validation dissociated from Database, can work with any database (or data-source), ex RPLS. Future Work: Work on the protocol bits for interaction in-PoP database and in-Speaker database.Also, Talking with the roa validation draft authors to check for possible merge. Danny - Validation side: What about protecting against hijacking a more specific? John - Anything that can be expressed by a ROA can use this mechanism. Danny - What about ASN spoofing? John - Yep that is a problem. Danny - What about soft-reconfiguration, rate limit for the connection to the database, that is something that needs to be deal with. Should I store prefixes that I know are false? Need some guidance in the doc about what to store and implications. Randy - Have serious question about scaling issues. Want to hear about what gears are going to be used. The size of the router that you expects is critical. John - This is a policy mechanism. Ward - The protocol to the BGP Speaker and the PoP Database is it part of the WG work?. I believe so. Sandy - Need to check the charter or include it in the charter. 2) Presenation by Robert Kisteleki from RIPE NCC - (draft-kisteleki-sidr-rpsl-sig-00.txt). Use of RPKI signatures to sign RPSL object. Not specific to one object type. Can have multiple signature and that is helpful for route objects when you can sign by the prefix and the ASN authoritative party. Signature in RPSL "like" format to feed back the database. Some canonization examples shown. Signature formats: chose DKIM format. Where to put the signature? "remarks: Signature is" or new attribute: "signature", may be problem with some legacy software. Example given. Open questions: Multiple signatures? Unicode? Sync with other people that are thinking on the same line. Is there support in the Working Group? Randy - I believe this is valid work however not the proper working group. have too much work here. Sandy - Which WG should be? Randy - Not recommendation. Haas - This looks like another WG. Randy - We are having problem getting our work out. Henk - Some time ago did some RPSL work and were by individual submission. Danny - Need Charter discuss. Geoff (form jabber) - As co-chair I am in favor of picking up this document. Thanks for staying late. Adjourned.