Subject: [Sidr] minutes from IETF68 sidr meeting

From: [email-masked] (Sandy Murphy)
Date: Tue, 27 Mar 2007 17:29:04 -0400 (EDT)

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-masked]
https://www1.ietf.org/mailman/listinfo/sidr