Minutes interim-2020-sidrops-01: Tue 16:00
minutes-interim-2020-sidrops-01-202004281600-00
| Meeting Minutes | SIDR Operations (sidrops) WG | |
|---|---|---|
| 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.