Skip to main content

Minutes interim-2020-sidrops-01: Tue 16:00
minutes-interim-2020-sidrops-01-202004281600-00

Meeting Minutes SIDR Operations (sidrops) WG
Date and time 2020-04-28 14:00
Title Minutes interim-2020-sidrops-01: Tue 16:00
State Active
Other versions plain text
Last updated 2020-04-29

minutes-interim-2020-sidrops-01-202004281600-00
SIDROps Meeting Notes 107
  - chair slides
  - randy/panel slides
    - opinions are important(ush)
      discussion of CRL changes
      russ - know that a CRL must be created (because CPS)
        to keep the ability to remove resources from use prior to expiry.
      warren - perhaps not equal to the root-dns management, change rates
        are different in bgp/dns.
      steve kent - Software should be ther to make the manifest prior to
        publication, something like RP software but with better error/etc
        for the CA/PubPoint about inconsistencies prior to updating published
        content.
      randy - ideally the verisign/etc folk have solid provisions for this.
      russ - there are 2 tests, ICANN and Verisign, actually.
        tests, ideally change with lessons learned.
      randy - there appear to be authors missing for the proposed document
        updates which must be made (rfc6486 - bis section-6)
      steve - (see last part of randy comment) Section 6 was rough on the
        original authors... much vaccilating due to concerns with ops/etc.
        Time to refresh this, with a new view on ops work and WG discussions.
        See ML discussion with proposed text from ML.
      randy - still need to find authors and use resources (steve/russ/) to
        review and provide updates to said text.
      steve - some choices were made about DoS issues and less (probably)
        focus there should be made. Ideally review George Michaelson's text
        on list about effects of missing content in a repository.
      job - updating an RFC could take ~2yrs, what can we do in the meantime
        to get guidance to the validator folk before then?
      randy - use consensus from WG, to push software changes.
      steve - perhaps the new section6 changes can move the operator/software
        forward? while the doc revision is pushed up ietf poles.
        first goal, get more agreement on section6/etc first.
      tim - pushing for rrdp over rsync, which SHOULD help move atomic changes
        this will help.
      george - if focused on section6, 6.5 is the most important/problem.
        There's only 1 normative word(SHOULD)... need more focus and harder
        language here.
        Put  forth a tabular dos/donts
      steve - yes 6.5 is clearly in need of more hard words.
        warnings are not super helpful (says list traffic)
        for Tim, perhaps rrdp isn't 100%? is rsync REALLY the problem?
        guidance in the doc is to make the PubPoint an atomic change.
        possibly the RP software COULD help here, but not sure.
      russ - with more rigor on the pipeline of publication data we'd have made
        the rsync process work 'better'... regardless rrdp may still be nice :)
      randy - 
      rob - can review docs, can not write so much, lack fo time.
        rrdp may make sense because there's only the manifest to guide download.
        the rsync problems are tied to the FileSystem, this causes continual
        problems.
      randy - now to CRLs - come from PKix history, well defined and understood
        removal of CRLs 
      george - recognize distinction between positive and negative statements.
        all crypto is 'positive' not 'negative'. This means you can't say
        negative things. CRLs are only a negative thing: "Do not accept objs in
        this list"
      randy - 1) are crls undefined 2) should be removed
      russ - perhaps add to 8211 paragraph that discussion consequences about
        supressing a CRL. we learned more recently.
      tim - crl noise can deal with inconsistencies due to race conditions
        based on crl + manifest + ... circular dependencies on crl/manifest.
         (does the manifest get invalidated by the crl? is the crl in the
         manifest?)
        there's usecase still for CRL. With most of section6 dealt with then
        CRLs are more reasonable.
      steve - re 8211 changes... will issue errata for russ's changes.
      russ - possibly a 1para update.
      job - local poiicy point(s) - in last weeks with deployments, the
        local policy changes are being made with SLURM. Local validation
        changes may obviate local policy requirements on routing policy?
      steve - agree with job
      jay - see jabber - 'interesting that a manifest can be revoked in a crl'
      steve/rob - yes that's where it works
      tim - does this make sense? :)
      russ - yea.. no, yea... we should try not to do this, but it is
        possible, because they are cert objects.
      rob - please dont' re-write x509, but provide guidance that doing this
        is a 'bad plan'.
      rudiger - we can make additional constraints, right?
        enforcing that via consistency checks (steve) could make sense.
      tim - checking consistency is important, on publication server.
        check deltas/manifests/etc.
 - Randy slides - ROV Timing discussion
     historical pains (routing updates, dns updates, etc)
     lessons learned, we should learn them. Let's make the timing better
       and or more predictable.
     topology/etc discussion for path of CA/ROA/etc content -> rp -> rooter
     protocols used and timing of each protocol step discussed.
       (see slides for details)
 - Tim slides - Deprecate RSYNC! All Hail RRDP!
     not a WG doc yet, asking for that on list next.
     remove rsync because ...
     Why? see slides (server pains, implemtation problems, etc)
     RRDP should scale far better with CDN help/etc, much better libraries, deltas
     Today we have rsync, so graceful change is required
     Phase 0 - (today) rsync mandatory, rrdp optional
     Phase 1 - both protos MUST be supported (verification required)
     Phase 2 - RP protocols change to MUST RRDP, MUST NOT use rsync (measure)
     Phase 3 - Repositories MUST support RRDP, MAY RSYNC.
       possible to use this for data mining, not HA service.
     (see matrix, very useful)
     Adoption call coming shortly
   George - do we want formalizing in fetch uri's in asn.1?
    this seems unnecessary, fyi... DNS says perhaps ordering matters though.
   Rob - there is no list, there is no spoon. different oids.
   Nathalie - if you leave optional rsync.. we will be stuck forever.
     add phase4 where 'kill it with fire'.
   Tim - not against removal, but seems useful for other things (data science!)
   Rudiger - be cautious about the overlap time, as incosnistencies in the
     dual paths will cause confusion. The 'data science' part seems nice though.
     Possible not rysnc, but an API to review content in the same manner?
   Tim - rsync seems convenient still. With the rrdp urls...

  - ASCones - Max Stoochi
    Is not a sidrops draft, just re-picked up work, however.
      there's similar work here so chatting here now.
    New author! (melichor)
    Looking at security model now to revise that.
    Usage models for making prefix-lists
    Security documentation - ascone addition to new ascone... 
      must required handshake. Adding an ASN to the cone is optionally approved
      ACKs are registered in the as-cone, as a bool.
    Review of 4 models of prefix filter creation (see slides)
    Want to integrate with ASPA if possible.
     consider that these 2 things are closely aligned/similar.
     Do we want both?
    - azimov - ques: 'inheritance between cones?' (customer -> cust -> cust)
      what should happen if the 2nd customer has no verification?
      the inclusion of as-set/as-cones there's very confusing/mesh
        as you get nearer to the edge...
    - max - if the stub is a stub.. <but you don't know>
      won't the people just behave though?
    - azimov - RP is customer-cone, and not provider... this seems tenuous.
    - steve - back to slide 4 'validated' - asserted by publisher, RPs must
      trust this assertion. This is concerning... without verification by the
      RP this seems problematic.
    - max - the validation is in the DB, not by the AS-cone owner.
    - steve - this is still problematic (observation)
    - job - last-slide - integrating the two - as-cones is good thought exp...
      aspa - is an attempt to automate 'peer lock'.
      these two things are pretty different for filter creation.
      these may not combine well, keep them separate.
    - george - as-cones / roas discussion(s). The roa is signed not by an ASN
      but by a resource holder.  "Who signs the objects?"
    - rudiger - security model looks dubious to rudiger. George's remark on
      signing relationship is at least documented oddly/wrongly.
      as-cones are policy statements, and should be signed by the ASN...
      the validated parts are interesting to the security model. This could
      make a good meeting point for ascone/aspa...
    - randy - as-set addict... deconstruct the approval path as it relates
      to removal of ASN from as-cones?
    - max - this is worked out in the new draft version.
    - randy - when removed you must be able to show that the previous version
      is invaild.
    - max - re-read the latest draft, this is covered we believe.

 - ASPA Update - Alexander Azimov
   Slides review
   Data/Comparisons on Yandex network, showing how ASPA functions
   Need for per-family ASPA today.
   Note the usage of internal tooling to verify external leakings
   - rudiger - question on asn.1 change: "Why sequence and not set?"
   - azimov - sure!
   - russ - no way hoza! (sets required to be sorted in DER)
   - job - wglc - perhaps pump the brakes because of manifest/crl changes
     in flight.
   - azimov - perhaps another verification would be nice too :)
     will send note when appropriate.
   - randy - crl/manifest is orthogonal - perhaps ... focus on aspa?
   - yunan - ptp peers are covered? how? will take to the list for question
     discussion.
   - doug - with partial, how do you detect lateral leaks?
   - azimov - possible to detect, looking to the future with as-empty/etc.