Here are the minutes for the meeting, with many thanks again to Henk. (I'll pick on someone else next time, Henk has served his two terms.) I was able to fill in a comment or two that Henk noted he had missed by checking the archive.
Please post modifications/additions to the list by April 9. Apologies to those participating remotely. I started by noting we needed a minute taker and jabber scribe, but did not carry through on getting a scribe "volunteered", as Henk puts it. That, combined with my failure to get slides from presenters for the web site, left remote participants with only the audio feed to rely on. I'll do a better job next time. The audio archive is available at: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch5-mon-noon.mp3 There was one participant who spoke at the mike several times. Neither Henk, nor I, nor two other participants I asked, caught the name or knew the speaker. That speaker is identified as "XX" in the minutes. From the audio feed, his name is phonetically something like EU(oomlat)r-le-ra Row-shan. I'm certain that I butchered that. If anyone recognizes themselves or a friend from this description (you can listen to the audio archive yourself - try the sound bite starting 1:31:26 into the archive), please let me know so the minutes can be amended. (Why 1:30 into the archive? It seems the mics were all on and being recorded in all breaks, so the archive starts with background noise and chatter for the duration of the lunch break.) --Sandy SIDR WG Intro: started a few minutes late, Geoff unable to make it due to health problems, Henk volunteered as scribe. 1. RESCERTS draft. We went from -02 to -05. Geoff has a 1 line summary (see slides), some wording changes, diff of versions on slides, only mentioning those that brought comments from the audience: - Previous language prevented ISP from doing ROAs for same resource subset. Restriction removed. Comment from Steve: In the rewording, did Geoff remove all references to this or did he reword? Language simply taken out, Steve wants to think about it. - Other diffs are on slides but did not raise comments. - Paul Hoffman: rsync: is that an IANA spec? since the Rsync protocol is not - XX? How is this related to RIRs. How is interaction with RIPE DB done? Sandy: we want the RIRs to work on this. - Joe Abley: is rsync: (not a specified protocol) an issue. Sandy: no comments on this issue. Joe: uri that MUST be present, must be a protocol that is specified. Paul Hoffman: not specified, author does not want to bring it to the IETF. There are other protocols that we could use, but they are less popular. - XX? Couldn't find anything in the draft which routes have to be authenticated. Should all 200k routes be certified? Answer: Steve: it is in the architecture document, not here. - XX? Can we do a DOS by overloading the routers with certification checks by inserting false routes? Sandy: the routers don't have to do this. XX?: Is this in scope of draft or to be discussed elsewhere. Sandy: This draft is just certificate formats. We may need an operational use document but this is not in scope of this draft. Joe: this should be seen as a crypto layer added, not a BGP change. 2. Steve Kent/sidr-cp-01.txt - This is a template document, "fill in the right stuff here". - This ID reduces RFC3647 to what is useful for this case. RFC is 100 pages without text filled in, this doc only 47 with text filled in. - Paul: this seems heavily PKI, is this an ownership CP, are there other examples of such we can look at? Steve: I couldn't find any. 3. Steve/cps-rirs-01 - Overview of document - CPS requires a lot of tailoring by a CA. - Status: templates, to provide guidance. - Andrei Robashevsky: Not sure if you are going into this but what is the difference between the rir and isp docs. Steve: deals with different sides of the problem, small difference for RIR/ISP. Minimum security levels for ISPs are a bit lower. That sort of thing. - Paul Hoffman: Since CPS are layer 8 and above, RIRs are very similar. Propose to make this parallel. Steve: it is a template, RIRs to fill in internal procedures. Steve expects that the RIRs want the same starting point, then finetune things. Paul: what about change actual words. Steve: Most CAs follow template as BCP. Paul: be more explicit what can be changed. Steve asks Paul to send the comment to the list. 4. Steve/cps-isp-00: ISP version of the CPS 5. Steve/architecture document/sidr-arch-00.txt - Created in a rush to meet deadline. - PKI section a. Each resource holder is a CA. Because good practice that CA sign only certs, so create an end-entity cert to sign ROA b. Also good because can revoke ROA by revoking EE cert and only need EE private key once - can throw away c. Issues: add discussion of CA certs from multiple allocation sources d. Cert name conventions must be added e. AND WHAT ELSE? - ROA section - Repository system a. Issues: protocol for access b. Need to define access and access controls c. Need more discussion of repository structure d. Need discussion of distribution model RIR will probably maintain a repository of certs they create; but will other ISP's want to maintain their own? Will they want RIR to do it for them? - Discussion of repository section: a. Comment: it seems that you want to set up a repository for certs and don't rely on existing RIR infrastructure. ISPs got used to working with RIRs, why not extend the RIR DBs. Some discussion on what is in the RIR DBs (and what not), and what Certs would add. Certs can be verified. Steve: this is not a replacement of the system, but you can express things with more security. Sandy: an RIR can provide a link between the two (and 3 are considering this). b. Joe: we may need some context to explain interaction between RIPE DB and certs. The RIPE database couples allocation data and routing registry data. It is important to know that this coupling does not exist outside the RIPE region. This cert approach is the correct way. Steve asks Joe to put this in an email. c. Paul Hoffman: why does this need to be a different repository? Steve: whois is not designed for this. Sandy: the RIRs could be a repository, they don't have to be. d. Ruediger Volk: we have to deal with multiple databases of different structure. However, cert data can be mapped on to RPSL, and have existing tools access the data through whois->RPSL->certs. This will improve security, while (slightly modified) existing tools can continue to work. e. Andrei: one of the issues is consistency, how to keep them in sync? At RIR level, all data reflects one authoritative source: the internal RIR DB. CERTS can come from there too. There will be different users of the data and whois/cert. Steve: each RIR has its internal DB, the certs come from there. The internal DBs are not directly accessible, whois is a view. We need a new view though, that supports certs. f. XX: This is different in RIPE region wrt ARIN - Common operations section a. Need to add discuss of cert revocation and renewal b. Need to cite cert profile ID and cite ROA ID c. What else do we need - There is no official WG joke a. A certificate, CRL and ROA walk into an AS b. ... - Joe: how to revoke a ROA if one has lost/thrown away the key. Steve: you are the CA and control the CRL and can revoke the EE that signed the EE. Joe: mnemonic confusion. Sandy: how do you convince ISP when you hand them the ROA that you are the holder of the prefix? Steve: sign with a cert created by the CA that signed the EE cert. Sandy: how far up the chain can that relationship go? Steve: haven't discussed that. - Paul: you answered one of my concerns: You are doing a lot of CA operations instead of End Entity operations with the CA's key which goes against traditional PKI model of doing things. Steve agrees, but here every resource holder has to be a CA. What the CA is doing on behalf of the End Entity is revoking a cert, not signing an object. Paul: more CRL's than usual PKI. Steve: this is not a traditional PKI. - Paul: this document should not be informational. This should be on standards track, this will also allow you to move operational issues here. Steve has no problem with standards track. Sandy: take to list. - Sandy: There is a potential that other companies run repositories, how to make sure that what is uploaded is valid. Steve: this hooks back to the repository access control issue. We mention requirements but this is not complete. Needs another document or text. Sandy: check signature in certificate (or whatever). Steve: checking signature is right thing to do. Sandy: doc says to download certificates and check all signatures. Steve: want to do that anyway, even if repository has checked. - Sandy: draft says creating certificates that overlap is not recommended. Steve: this has to be fixed based on Geoff draft change. Sandy: RIRs sometimes keep half of a large block in reserve when allocating. Joe: what with 2 customers with adjacent /24's. Steve: this last one is in ROA space. Sandy: proxy aggregation is a problem we're not addressing. 6. Steve/ROA document - Last document. Introduction, new document. - Andrei R: ROA contains a list of AS. Steve: previous documents did. Now there is one per AS. Why? In a few slides. - Just one AS per ROA (Randy): in order to keep design simple. Geoff: if one AS#, the ROA authorizes only one ISP. If you need to ROA more, just issue more ROAs. Question from the floor - what do you do during merger? some companies use more than one AS#?. Steve comments that you can issue as many ROAs as you need, for multiple AS or upstreams or whatever. Downside: more things in repository, but disk is cheap. - ROA includes prefixes, not necessary but makes it easier in operations. You don't have to get the cert to find the prefixes. Richard Bones: does ROA prefix have to match EE cert prefix? Steve: yes. - Joe: is this v4 only? No, this is v4 and v6. - Discussion on ASN32. The issue is that the transition AS may pop up in route filters. This can be done by fixing things at the end. This needs text. Ruediger: as a 16 bit system, you cannot distinguish ASN32s. The system won't add security in this case, as anybody can use AS23456. Sandy: an ISP generating filters from certs would be able to adjust for ANS32s it doesn't understand. Steve will add text. - Steve points out that one can create as many ROAs as needed. Sandy: if enterprise is changing ISPs but retaining prefix for a while, it may want to get original ISP to sign ROA for new ISP. Steve: or have original ISP issue CA to enterprise so enterprise can sign ROA. - Discussion of match of ROA prefix to Update NLRI: exact match, or exact and more specific NLRI, or ROA expression of allowed NLRI. - Joe: some allocations are ranges that don't match a cidr boundary. Can't do exact match of NLRI against such a range. - Paul: what about range matching. Steve: ranges don't have to be prefixes. Exact match won't always work for ranges. One thing to do is to discuss what happens with multiple ROAs. This has to be checked and documented. The document doesn't talk about it yet. Take to list. - Sandy: where does stipulation of matching belong? - XX? Matching should allow fast implementation, when building/using large filters. Otherwise it won't work in practice. Need involvement with equipment manufacturers. Sandy: it is not necessarily to do this online, or to do this by building filter lists. Joe: should not get hung up on current router capabilities. Need these certs as a building block for future routers. - Ruediger: it is essential to have true, reliable information. Very hard to check some customer's claims. Revocation feature is also very helpful. End of meeting. _______________________________________________ Sidr mailing list [email protected] https://www1.ietf.org/mailman/listinfo/sidr
