Minutes for SIDR at IETF-89
minutes-89-sidr-5

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)