Minutes for SIDR at IETF-93
minutes-93-sidr-1

Sandy Murphy:
        •       introductions, note well
        •       draft status (see slides)
        •       ltam to die unless someone objects
        •       agenda
Tim Bruijnzeels:
        •       RPKI retrieval Delta Protocol - RRDP
        •       Discussion
        ◦       Geoff Houston: Distrusting - what does it mean
        ◦       Rob: I was going to comment on this.  This is a point of
        friendly dispute among the implementors.  Tim is very conservative
        regarding his implementation. ▪       all it really means is the
        protocol is not a trusted conversation.  the objects are what matters;
        we don't really care about who we're speaking to to get the objects ▪  
            so being conservative about believing the web server when it says
        to delete something •       questions/comments? ◦       Randy Bush:
        Channeling Dan McPherson .  He's concern about the distribution of the
        data because he has a product which depends on this work. ◦       Tim:
        no data yet.  The place that is getting work is the notification file.
        ◦       Sandy: I think that you are talking about certificate
        validation not bgp route validation. ◦       Rob: this is really about
        discovery, not validation ◦       Tim:  would like to make
        informational document that explains how both discovery and validation
        work with RRDP
Sandy:
        •       Randy Bush to talk about transfers.
        •       Geoff pointed out careful synchronization requirements to hand
        off back in November.
Randy Bush:
        •       Sandy: Do you think your description of the transfer process
        melds with Geoff' description of careful synchronization? •      
        Randy: probably, what do you think Geoff •       Geoff: ◦      
        validation reconsideration gives more latitude ◦       the two work a
        lot better ◦       if you get timing wrong, things are still ok •      
        Sandy not asking about validation process, was asking about (too fast)
        •       Geoff:  take the 5th, can't answer right now without reading
        carefully •       Sandy:  For those of you who are working at the
        registries, does transfer draft match your operational procedures? •   
           Tim B: no, we support xfers, defined by policies, doc doesn't have
        to define policies, but needs room for decision points on whether xfer
        can happen or not.  Currently don't engage.   Can invalidate resource
        in a certificate in case of xfer, but since we have hosted solution at
        the moment, doesn't really affect us.  We can shrink ROAs, etc as
        neeeded. •       Randy: You don't do inter-rir transfers? •       Tim:
        not yet, almost •       Stephen Kent:  One of the difference between
        Randy's doc and earlier is earlier distinguished between transfers of
        unused and live, thought that former was more common. The discussions
        on the list says having two ways of handling transfers isn't good.  If
        wg decides having only one way is better, the document needs to say why
        that choice was made (why not distinguish between the two).  We
        described in that older draft that ordering constraints aren't that
        bad.  Ordering should be carefuly revisited in detail. •       Sandy: 
        I do not know of any rir that permits live transfers of live address
        space. I do not think that xfers are impossible •       Randy: I assure
        you that transfers of live address space have been going on for years. 
        Mergers and acquisitions •       Sandy:  never considered them an xfer
        •       Andy Newton: we know that transfers have taken. •       rob:
        One particular data object is the tao object that we sign and
        transfer.  I recommend people go back and read the document. •      
        randy:  in original transfer doc, 2007, something like live euro
        protocol, fantasy to handle what the tao object is doing in a different
        way.  essentially need an authenticable /verifiable attestation of
        intent.  tao is one way of approaching that •       sandy:  torn euro,
        not live •       tim:  I like the document that randy and all published
        recently. •       Randy: The transfer document is slowly sneaking up on
        describing the transfer.  We have so little data on those who are
        actually doing the transfer.  One is type going up and the other is
        going down. BBN doc making registry nervous ◦       both trying to
        reach the same place, different directions (one going up, other down) •
              rob:  if you look at either doc, there's a challenge naming
        recipient.  seller identifiable (holding resource), buyer hard to
        find.  tao object, something that names the buyer.  where is this
        supposed to be going?  did the right person get it? •       sandy: 
        would be useful for people to comment.  neither doc is a working group
        document.  do we want both, or one, or neither to be adopted? •      
        randy:  what do we mean when we adopt?  some wgs will talk endlessly,
        others if it means we want to discuss it. •       kent:  don't both
        need to be adopted.  ultimately have a solution that will incorporate
        elements from either document that is adopted.  Randy's document has
        more details regarding on topic.  BBN has working. •       randy:
        illustrates the difference in two procedural approaches.  a group that
        says wg docs are those for discussion, then both should be adopted,
        then drop both, then adopt a new one.  etc.  in idr these wouldn't be
        wg docs until something pristine and ready to publish came out •      
        Rob: Ask if the WG wants to work on this topic. •        Richard
        Hansen: adopting makes it easy for people interested in sidr to keep
        track of what's going on, what the group thinks is interesting •      
        : Adopting this work indicate people want to talk about this document •
              sandy:  we'll go forward in some fashion
Steve Kent, overview of adverse actions draft
        •       (slide 6) Rob: A question that occurred to me, I agree that
        outsourcing CAs.  There is a large publication repository (  what if
        google decides to publish everything?  should we consider that case? • 
             Steve:  good question, should email so we remember to think about
        it. •       (slide 8) Rob:  not exactly mission drift, but originally
        manifests had a specific focus.  just here to solve one problem.  but
        they're useful for other things...   rsync isn't the best.  manifests
        are pretty important for discovery.  Requirements for manifests may
        have changed.  may be worthwhile to revisit manifest doc. •      
        steve:  good point.  if plans to switch to rrdp, then need to go back
        and look at it.  but it's tricky, we're still using rsync.  will have
        tradeoffs •       doug montgomery:  in detection, worth addressing pub
        point might offer different views to different people/regions of the
        world. •       steve: didn't address that.  certainly is possible if
        the primary detection is done by the INR themselves, but they keep
        getting rosy view.  INR might have options for where to get resources. 
        please send email to list so we remember to talk about this •      
        Rudiger Volk:  As distribution tree gets more differentiated, attacks
        it is not sure to determine how to monitor or to detect these attacks.
        It is actually interesting to have some people provide a service of
        monitoring - so the naive people can ask for the current view This
        resource view will show the resource holder. It would be •      
        steve:  One can imagine 3rd party monitors (for money, altruism).  We
        have this in BGP - so why not here. •       mlepinksi:  What is the bad
        thing that can happen if a repository offers different views of the
        world to different people ... provided that both views are otherwise
        valid (not stale) •       steve:  The views could be different due to
        compromises.  I think Matt was asking question in a slightly different
        context. •       tim:  we use manifests in a more authoritative manner
        -- I think they're really useful because they're signed and enumerate
        what they believe we should find •       steve:  complimentary issues: 
        if i can't find something mentioned, then...  #2 if i find something
        not on manifest, what then... #3 what if manifest is stale.  should
        discuss, little squishy •       tim:  people seemed to be ok with
        giving manifest more authority. •       steve:  agreed, need more
        discussion and decisions •       matt:  One can imagine a resource
        holder who wants different people to see different views and therefore
        creates parallel objects for this purpose. I am not sure that this is
        good, but I don't think it is something we should spend a lot of effort
        to stop •       steve:  i don't think we ever viewed this as a feature
        •       randy: lta use cases •       steve:  local matter, we're
        talking about global •       randy:  local can be big, and can have
        subsidiaries.  not as bad, intransitive •       sean turner:  question
        #1 adopt?  yes.  #2 expand scope to expand other EE?  no, let's not. • 
             steve:  router certs? •       sean:  sure.  for other EE we can
        add them later •       sandy:  was reviewing some of the things that
        had happened in registries and rpki, some of availability issues where
        repos were offline, manifest problems cause validation to fail
        everywhere, do those fit in suppression? •       steve:  i'd say yes. 
        if offline, then equivalent to suppressing availability of updates. 
        could try to clarify •       rob:  several RIRs had CA offline.  pub
        point was online, but CA wasn't updating so things went stale.  don't
        know if all rirs have fixed problem of short manifest EE cert lifetimes
        (were using 2-3 day lifetimes).  The problem with RIR would go down for
        a weekend, and everything under other the RIRs. ◦       rir region
        would go away for a while ◦       technically could fit into this
        category...  more like serious operational error •       randy:  have
        had demonstrations of serious problems.  would be nice if it was
        obvious to reader of the doc the nature of those problems and how this
        doc plans to detect and deal with them •       rudiger:  would be good
        to explicitly state whether the intention of this document is to cover
        all of the things that could happen, including all of the operational
        screw-ups.  straight forward that ... classified in theoretical way as
        suppression or similar, but i would guess that addressing seriously all
        kinds of operational errors would take a different approach to those. 
        in the interest of op stability, I would like to see all of it
        addressed, but fine if one doc deals with explicit tampering and
        another deals with operational errs.  one should have a clear
        understanding of what is being addressed. •       steve:  rob, please
        send examples.  what we can do is give examples to make it clear that
        we did intend to include this. •       steve: rudiger:  Did intend for
        this to be comprehensive.  detection is going to be the same.  better
        job of explaining the implications of these things.  want to make
        reader understand this is a concern because of this points. •      
        sandy:  recall happening two registries had issued same resources to
        different people.  how does that fit? •       steve:  send that to the
        list, need to think about that •       sandy:  Possible to do that ..
        for traffic engineering •       steve:  could have daemons looking for
        these, could have false positives •       declan ma:  cover case of ...
        yes, we are looking at that •       all of the above was on slide 8 •  
            Stephen: I'm proud of my penguin picture in the slide set. •      
        Randy: But what is the penguin asking (smile)..
Sandy:
        •       previous q on whether to adopt leads me to think that adoption
        is a moot point •       clear that people are commenting and interested
        in the topic •       if authors want adoption, authors should request
        it from the list •       next:  david mandelberg •       reminder of
        blue sheet
David Mandelberg presentation on SLURM
        •       note: David believes this is ready for adoption.
        •       Rob: The basic mechanism has been around for many
        implementation. You are suggesting we have a file format. •      
        david:  and a specific behavior for what the file says •       rob:You
        are specifying a typical usage, but not limiting it.  The typical usage
        is  layer between validation engine fetching and rpki-rtr stuff.  in my
        implementation, if you choose the right options -- what can you express
        in a perl script? -- it's a text filter.  talking about set of actions
        and file format.  main value is having interchange format in case you
        want to move them around •       david:  yes, that's primary concept, 
        but additonally some corner cases need to be  hash out •       tim:  we
        are doing similar things in our validator.  can only configure in web
        ui at the moment.  woudld be good to have a standard format and a
        dcoument describing behavior. •       doug montgomery:  so this is for
        addrs not globally advertised? •       david: primarily for net 10,
        etc. •       doug montgomery: but used locally and not ebgp? •      
        David: I believe that there are people doing strange things. •      
        doug:  monolithic file per validator? •       david:  per rpki-rtr
        output server •       doug:  router to cache peering? •       david: 
        don’t see why not, if you configure properly •       doug:  worth
        discussing to get correct scope of correct slurm? •       david: 
        asking for ops draft? •       doug:  how to use if different strange
        people do different strange things •       rob:  is identifier field in
        slurm format.  draft is open ended about how that's handled, but one
        way is to limit applicability to certain rpki-rtr instances •      
        rudiger:  ...  people will screw up •       david:  would be nice to
        minimize that •       rudiger: It makes the text for writing the RIR
        easier.  You are not twisting the text for 5 different usage.  And this
        is important because if the standard was not good, it will helpful. •  
            doug:  picking up on rob, if localized special views, if some way
        to bind right router to right view, that would be good •       david: 
        it's in terms of rpki-rtr servers, not routers •       steve kent:  if
        common format is a good thing because of sharing, then we have to have
        semantics be uniform or else we have problems.  that's why it's good to
        have this •       Jeff Haas: slurm is just a filter.  Without that, you
        expect what you generate is expected to be largely uniform.  may want
        to private addresses have scope in some portion but not somewhere else,
        some bit of prefix squatting on, the way to extend this interpretation
        -- treating it as output, do something before handing off.  could get
        same thing if you move the box. •       david: are you asking to put in
        router software? •       jeff:  may make sense.  yang, etc. that people
        know what to do with •       david: made these slides before we talked
        last night.  Being rp implementer, put it where I was comfortable •    
          rob:  leaving slurm out for the moment; from implementation point of
        view easiest to put it there •       randy:  characterization of use of
        other's address space -- people doing that are not announcing globally,
        and they want to validate its use.  that's reasonable.  we may or may
        not like it, but that's reality.  2nd point -- lta-use document tries
        to address similar needs but at higher level; specifically do editing
        by producing different repositories.  distribute modifications through
        repositories.  this is two steps down, not sure which set of needs and
        how this is implemented is the way i'd go. •       david:  draft does
        reference lta use cases.  agree with most of what you said, personally
        think it's easier to distribute text file. •       randy:   want to
        reduce description to a distributable syntax.  would recommend json. • 
             rob:  if one were to use slurm to replace some things in ltam, one
        might want some understanding of way to combine multiple slurm files. 
        how to merge local with isp. •       david:  in the draft. •      
        rob:  yay.  have comment syntax? •       david:  yes
declan ma, rpki in china
        •       Sandy: Any questions?
        •       Rudiger Volk: I wonder if you mentioned any test plans or any
        details on deployment? •       declan:  yes.  zdns has testbed, ran
        tests.  developing distribution mechanism (rsync with optimized hash). 
        We have  testbed to work with manufacturers to see if it works •      
        ??? (afrinic):  modified rsync, did it help you? •       declan:  paper
        will be published, can send slides about thisYou know my email address.
        Please send me a request.
matthias waehlisch on rpki beacons
        •       randy:  would like to change "interval" to "specific published
        times", then can measure propagation.  don't care what the object is. 
        like that each CA does it.  think it's a good idea. I like bgp beacons
        •       kent:  opposite take:  adding churn to the system is something
        i worry about.  secondly, already have by convention, crls that are
        changing daily and thus manifests.  if rate that cas should do this is
        more frequent, then we shouldn't do this.  looking at propagation time
        using existing stuff is pretty good.  if suggesting doing it more
        frequently, have to add new objects.  must pay close attention to make
        sure we don't mess anything up. •       matthias:  first idea, still
        open for discussion. •       kent:  1st question:  how frequently?  if
        not more frequent than existing updates, then we might already be able
        to do what you want to do.  having every ca do this, since we have a
        few entities that operate repositories, propagation will probably be
        the same so it may not add to the precision if each of the hundreds of
        CAs do this for each CA.  seems excessive. Perhaps you needed to think
        you about this? •       matthias:  expect more frequent than once a day
        •       kent:  crls get issued daily, thus manifest changes daily, and
        they have timestamps •       randy:  start time on cert is not
        necessarily publish time.  I agree with kent on managed repositories. 
        .I am interested in the publishing time... per repository not pub point
        timing is of interest to me. if it creates too much churn, then i think
        we have more serious problems •       ??? (ripe):  like idea, but where
        do you want to go with this? •       matthias: •       (ripe):  idea
        good, don't support a mandate that all CAs must do this, but think it's
        good practice.  idea is good •       sandy:  cross product of bgp
        beacons and rpki beacons.  I was trying to see if there's interest in
        trying to measure the publication time vs. announcement time, and when
        changes impacted each other.  I don't agree that crl being published
        daily is sufficient; needs for measurement may not be satisfied by that
        publishing •       matthias:  should we write a draft? •       sandy: 
        I think that a draft is best to progress this work is important.  There
        have been complaints in the past that progression without a draft is
        not good.
Andreas Reuter:  RPKI MIRO
        •       Rob: This is awesome - keep it up. I was trying to feed the
        results into DOTS is difficult. We tried to remove any identifying
        information.  Is this a independent implementation.  If it becomes an
        independent implementation, please join the rp implementor interop
        testing •       andreas:  no, using RIPE's validator library •      
        Randy: I do not care about the file names. We went down a similar path
        for bgpmon.
sriram- draft-idr-route-lead-detection-mitigation-00
        •       Lots of discussion on IDR list and GROW list (presentation
        comes from these comments) •       sandy:  wg chairs list, meetecho
        ends precisely on time... •       questions •       randy:  route leaks
        are a serious problem.  i think this is the only game on the table. 
        not clear that it wins.  concerns are the idiot leaking also marks, so
        they're going to do the downgrade attack.  if they have a misconfigured
        router, why wouldn't their router be misconfigured to downgrade •      
        Siriram: The security is important. •       Randy: We need to take time
        to think through what happens, and get it right. •       Jeff Haas: 
        where do we put these things?  community makes sense.   operators use
        peer groups to associate things together with common policy.  people
        might do what appears to be a downgrade attack.  One might degrate the
        peer grouping.  If you want it to be automatic.  with end communities
        can put it in today, if done correctly, will work.  having policy that
        is automatically maintained ... •       Siriam: You think automating
        this is feasible? •       Jeff: what is required mark peering session
        (peer is customer, peer is provider), would be broadly useful., for
        this and other stuff. Taking this taxonomy and seeing if it is usefu. •
              randy:  #1:  hesitant to use communities because they get
        manipulated, validly so.  therefore can't sign them, so doesn't work
        with bgpsec.  #2 based on Gal-Rexford model, been ranting against this
        for years.  people who have been pushing it have a paper that says that
        they measured, and it's not the case in a significant portion of the
        internet. •       sandy:  found it listed as a tech report, can be
        described as publicly available document. •       sriram:  not
        characterizing peering session as gal-rexford ... •       randy:
        Tjotrnasported between two peers intentionally, this discussion is
        silly •       sandy:  in discussions, always discussed neighbor of
        leaking party being the discoverer.  neighbors aren't correctly doing
        their jobs detecting.  advantage of this is permitting later people to
        detect. •       randy:  not necessarily -- if 2 hops away, don't know
        if the leaker was a bend.  don't know that topology •       rob: 
        assuming they'll get this right but others wrong doesn't work •      
        sriram: •       doug:  that assumption, that you blow everything, is
        what this addresss.  theory is that google knows what it does when it
        passes to hathaway.  multiple hops fail, but eventually hits someone
        who's doing things right, and now that has a chance to detect
sandy:
        •       we're done