[sidr] minutes for IETF89

["Murphy, Sandra" <[e-mail]>]

Matt Lepinski took minutes for the SIDR session in the IETF etherpad.

I've uploaded a copy to the meeting materials site.  http://www.ietf.org/proceedings/89/minutes/minutes-89-sidr

The etherpad site (temporary) is http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-sidr?useMonospaceFont=true

Below is the text of those minutes.  

Please review and send any corrections or additions to the list.

--Sandy, speaking as one of the wg co-chairs


SIDR Meeting at IETF 89
March 4, 2014
9:00am UTC

Chair Slides: http://www.ietf.org/proceedings/89/slides/slides-89-sidr-7.pdf

Chris Marrow (Chair) will work with the authors on the mailing list to resolve the one outstanding issue in the requirments document.
    draft-ietf-sidr-bgpsec-reqs-09          

--------------    
RFC 6490bis - Geoff Huston : http://www.ietf.org/proceedings/89/slides/slides-89-sidr-2.pdf

Rob Austein: It would be nice if there was an easy way to find the delimiter between the URIs and the Public Key
        Also, it would be nice to keep this simple. I would like not to have to include a JSON library just to parse the TAL file

Geoff Huston: Will look into whether carriage return characters can appear in the public key
        If there can be a carriage return in the public key, Geoff will put in the blank line delimiter
        
Sandy: Are we just dealing with the one issue (multiple publication) or when we re-opened this document, was the working group's intention that 

Rob A: If we are going to change the document, let's make the smallest change possible to address the issue (multiple publication) 

Tim B: It is not important to me that we use JSON. I think JSON is a good idea and it is well-defined, but I don't want to hold anything up

Randy: Isn't Klingon as well-defined as JSON?
 Wes: No, but it is easier to understand
 
Sandy: The Working Group Chairs see a high bar for accepting any changes other than the muliple URI change 

----------------
George Michaelson - OID issue in RF6485 : http://www.ietf.org/proceedings/89/slides/slides-89-sidr-5.pdf

This errata is actually a change to base document

Stewert AD: We are not allowed to make any technical change through the Errata process
   ... spin a new RFC if there is any doubt
   ... please include a note to be removed by the RFC Editor
       Make it clear what the change is and why this change is being made
       
       
--------------
Rob Austein - No Slides

The current draft for BGPSEC router certificates requires there be only one AS in the Router Certificate

Steve Kent: As an author, we can fix this

Matt L: It may be helpful to have cautionary text in bgpsec-ops telling people not to use multiple keys for a router that happens to be in multiple ASes.
       Fixing the router certificate draft is important, but even with the change bad/dangerous behaivor would be permissible.
       
Jeff H: Wes and Sandy's document on AS Migration might be relevant here. We want to make sure whatever we recommend for router certificates is consistent with AS migration scenarios

------------
Randy Bush : Use Cases - No Slides

Randy Bush: I know Steve Kent has issues with the prose. Does anyone have issues with the semantics

Steve Kent: I will provide suggested text to improve the prose. 

Randy Bush: Note: If you swallow this pill then proposals to change the world will need to address these three use-cases

------------
Geoff Huston : RPKI Validation - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-3.pdf
draft-huston-rpki-validation

Randy: This doesn't have an Internet draft? 
 Geoff: There is now an Internet draft
 
Randy and Geoff talk past each other regarding whether this proposal is top-down and bottom-up

Rob Austein: I am not concerned about the responsibility that RIRs have to do the job that they are paid to do
         I am concerned about caching/timing issues. I am somewhat 
         If we go forward, we need a new OID for a new certificate extension that is not RFC 3779 but is like 3779
           We would not want to implement this in the core of OpenSSL
         However, I think that joins in the tree are not as easy as you make them out to be.
           Getting the issuer names to match is probably doable with X.509 games, but it isn't easy
 
Doug Montegomery made a point that was missed by the minute taker <sorry>
       Claim: If we go down this path we won't be able to understand the RPKI by looking at
    Geoff: We didn't have this to begin with in the PKI model because everything we have in a PKI is relative to the Trust Anchors that you happen to trust
    
David Mandelberg: On Slide 15, Geoff doesn't mean "Local Trust Anchor" in the LTA sense of other SIDR documents.
            <talking past each other ensues>
            David is concerned that adding joins makes things a lot more complicated (at least for the people doing the validation)
            
Steve Bellovin: I am concerned that I don't understand the formal semantics of this evaluation you are proposing
            When we move from a tree to a graph, I am concerned that the consistency proof isn't obvious
            
Geoff: The semantics are equivalent to if we had a separate tree for each address and for each AS number

Rob Astein: "Twitch ... Joins ... Twitch"

Tim B: It might be useful to consider the two cases separately -- where you have no joins, and where you do have joins
    I think the former issue need not be that hard to implement (although as Rob said maybe we need a new OID)
    I like that the tree structure allows me to validate in paralell without one branch affecting another 
     
Geoff: The paralellization isn't a major issue. I can give you pseudo-code    

Steve Kent: There are a lot of problems with the joins.
           Key roll-over won't work smoothly in the event of a join
           What you propose is a MAJOR change to validation
           I am sympathetic to the issues you raise
           But I think the joins are a foundamentally flawed idea and then we can discuss whether there is a way to address the other issues you raise
           
Warren Kumari: Doesn't it make sense for the guy at the bottom to just claim 0/0 and all AS number?
       Geoff: An issuer should never issue for 0/0
       
Carlos Martinez (Lacnic): I think (like Tim) that there are two use-cases that should be addressed separately
    When I explain the technology to new people, new people imagine that things currently work with the relaxed rules that Geoff is proposing [1st use-case]
    
------------
David Mandelberg : SLURM - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-0.pdf

Tim B: We have a web interface for ignoring particular resources
      It would be great to have a standard way of doing/configuring this

Rob A: This misses some shared central configuration
      In this you need to distribute SLURM files, you can't just point your validator at someone you trust
      This isn't bad
      
Randy: This doesn't solve Alice and carol's case
      We should think about about how to solve the whole problem (all three use-cases)
      
Discussion with Jeff and Chris about whether the draft needs both del and add statements. Would there ever be a del without an add?

Wes George: Why are we coming up with new and interesting ways to poke holes and not trust the system?
          Won't people just use this do to kinky things? If we insert this work-around for the system, at what point do we just decide that implementing RPKI isn't worth the overhead

----------
David Mandelberg: TAO - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-1.pdf
          
Rob A: What if Eve doesn't exist?
    
Randy: We are missing (from the 2007 discussion) the agreement that the externalities have been met
       Requiring that the externalities have been met requries Eve existing and getting the resources
       Reference to "torn Euro" protocol
       
Steve K: This is an automation of the update of the RPKI data for a transfer
         It is not a replacement for existing procedures/contractual arrangements
         Carol can issue a trivial resource to Eve to put her into the system 
          (e.g., give Eve a /32 and take it back after this is all done)
        
Byron [Jabber]: SKI is not identity
           ... this needs clarification, will take to the list

Tim B: I think these are valid goals. 
      But this seems to add complexity to provisioning
      Maybe this can just be solved informally and doesn't require a new standard
      But I need to read this draft fully
      
----------
George Michaelson : Rsync Harmful - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-8.pdf

Note: Much of this presentation was given in a different context on Sunday at IEPG

Note: When George's slides refer to East Coast and West Coast he is referring to North America. (As opposed to, say, the East and West Coast of Japan or Australia)

Rob A: I have been viewing Rsync as phase 1
      I imagine at some point we will need to do something else
      I like this presentation, but it doesn't change my opinion
      I really don't recommend running as root. (Our software does not make it easy to run Rsync as root)
       
Tim B: I think it is an important design decision to have validators seperate from routers
       I don't think sending the RPKI data in BGP is a good idea
       I have some other ideas for replacing Rsync, which I will bring up again if appropriate.

Randy: Thanks for doing this work
       However, for the time being, Please follow RFC 7115. (Recommendation with regard to directory system)  

-----------
Fabian Mejia : RPKI Experience in Ecudor - http://www.ietf.org/proceedings/89/slides/slides-89-sidr-4.pdf

Volk: Is there use in actual routing in Ecudor?
    
Ans: On March 15, invalid routes will be dropped at the IXP
     (Currently just monitored)