Chris Morrow took minutes for IETF 77 that were uploaded to the
proceedings site last week.
I've checked the audio feed and the jabber log and the minutes look
accurate to me. I've made a few changes to the minutes, which are trivial
for the most part (line feeds, etc.) except for one change capturing an
entry from the jabber log where the minutes indicated a comment was
missed.
Unfortunately, there was a problem with uploading the revised minutes, so
this message has the revised minutes attached.
Please check the minutes and see if you have any changes to request.
Note that the audio archive is 2:54 long, but about the first hour of that
time precedes the start of the sidr meeting. Furthermore, there were
difficulties with the audio in the first section of the meeting, so agenda
items (a) on Use Cases and (c) on ROA Validation are not in the audio
archive.
For those who want to listen to the audio:
Start time
0:00:00 white noise
0:57:05 faint voices (Steve Kent, I believe)
1:08:59 Steve Kent on the CP and CPS documents
1:20:26 Robert Kisteleki on RPSL wth RPKI Signatures
1:33:28 Matt Lepinski on Architecture and ROA Format
1:55:57 Pradosh Mohapatra on Prefix Validation
2:25:42 Steve Kent on Local Trust Anchor Management
--Sandy, speaking as wg chair
(from: <http://tools.ietf.org/wg/sidr/agenda>)
Agenda
Secure Inter-Domain Routing WG (sidr)
77th IETF ? Anaheim, CA
WEDNESDAY, March 24, 2010 ? ? 0900-1130 ?Morning Session I
? ? ? ? ? ? ? ? ? ? ? ? ? ? ?1030-1130 Morning Session II
California C
=====================================================
CHAIR(s): Sandra Murphy <Sandra.Murphy at Sparta.com>
? ? ? ? ?Chris Morrow <[email protected]>
AGENDA:
?1) Administrivia ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?5 minutes
? - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html
? - WG Resources: http://tools.ietf.org/wg/sidr/
? - Minute taker?
? - Jabber Scribe?
? - Blue Sheets
? - Agenda Bashing
2) Updated Drafts ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 90 minutes
? ?(a) Use Cases ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 15 minutes
? ?Use Cases and interpretation of RPKI objects for issuers and
? ?relying parties
? ?draft-manderson-sidr-usecases-01
? ?http://tools.ietf.org/id/draft-manderson-sidr-usecases-01.txt
? ?presenter: Kotikalapudi Sriram
? ?Slides: ? ?<http://tools.ietf.org/agenda/77/slides/sidr-1.pdf>
Notes:
?Attempting to outline all cases of validation and usage of the
prefixes in question
?Note the taxonomy slide...
?Note that local ISP preferences/policies will override some/all of
the decision process
?(slide 4 covers the cases list)
?- Request for other use cases not covered to be sent to the list/sriram
?- End-o-Slides -
?RandyBush: Note about use cases vs validation tree options (pradosh's draft)
? ? ? ? ? ? ? ? ? ? The slides show how a validation happens, not how
an ISP uses the output of the validation decision.
?SteveKent: Taxonomy of the use cases missing some of the content,
could you cover how/why (note terry's diagrams) the use cases would be used
in the real life.
?RudigerVolk: Attempt to simplify the work here, define more clearly
the ROA semantics. In the end... does a prefix match a?ROA<period>
?Sriram: If there are more specifics registered, and not the covering
prefix - the covering prefix won't get 'validated', so keep clear on
what
? AndreR: this appears to cover the same ground as the validation
draft (pradosh's draft), covering this in 2 places is asking for
documentation troubles.
?RandyBush: notes that policy of validation decision isn't to be
baked into hardware, if possible, which this preso seems to imply.
?SamWieller: Notes that the draft covers far more, and more on
target, than the slides... perhaps a mismatch of content on slides vs draft.
? ?(b) Manifests ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 10 minutes
? ?Manifests for the Resource Public Key Infrastructure
? ?draft-ietf-sidr-rpki-manifests-06.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-06
? ?Presenter: ?????
No presentation
? ?(c) ROA Validation ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?10 minutes
? ?Validation of Route Origination using the Resource Certificate
? ?PKI and ROAs
? ?draft-ietf-sidr-roa-validation-05.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-roa-validation-05
? ?presenter: george michaelson
? ?Slides: <>
Notes:
?This is a presentation to cover WHY you want to validate, not how
?A quick diff of the 03/04 since this is 05
?removed all content related to BGP Ops
?Call for WG-LC for this doc?
? ?(d) Certificate Policy ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?15 minutes
? ?Certificate Policy (CP) for the Resource PKI (RPKI)
? ?draft-ietf-sidr-cp-08.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-cp-08
? ?Presenter: Steve Kent
? ?Slides: <http://tools.ietf.org/agenda/77/slides/sidr-2.ppt>
Notes:
?Doc structure changes related to MUST/SHOULD/MAY etc (normative
text) usage in this doc
?Geoff added a bunch of comments about
? ?- 'unique' which isn't quite correct, need to remove this.
? ?- AS number distribution by LIR's seems to be precluded, this
seems incorrect and we ought to discuss this, and decide.
? ? ?(Rudiger and Geoff at the mic say how redistribution really does
happen this way, notes about brazil and about coding the
? ? ? limitation in place isn't a good thing. Steve says that the doc
should cover what REALLY DOES HAPPEN at the RIR/LIR/NIR levels, pls
have RIR/NIR/LIR folks come forward and state this, clearly.)
? ?- Should the CRLs, RPKI objects, etc only be published by the CA?
? ? ?RudigerVolk says that there are reasons for ROA's to be done
locally (private addr space)
? ? ?RobAustin says to make sure that if there are ROA's in a
manifest, make sure that if there is a ROA asserted it appears in
the manifest (and vice versa)
? ? ?GeoffHuston you should allow the case where signing a ROA is
possible without having to publish that in the manifest.
? ? ?RobAustin clarification of Geoff's comment
? ?- CA's do not publish revoked/expired items, CRL's cover revoked
but almost never (save some rfc5280 case) publish expired items.
? ?- how to accomplish revocation, the 2 systems in question aren't
equivalent, so the?sections also aren't equivalent.
? ?- There's a discussion of 'the chain', the original comment is to
about a missing portion 'the?chain used to validate', being clear
about the usage of the chain of CA's and associated?certs.
? ?- Should RP's use OSCP/etc or just CRL's published by the CA/TA?
(yes, only the CRLs,?no other services)
? ?- Should CA's that disappear have more into or be treated
differently? Note that everyone?here is a CA, so this text is 'odd'
at best. clarification is needed.
? ?Comments:
? ?DaveWagner - Why should we tell folks how to use/do CRL stuff (why
not do OSCP?)
? ?SteveKent - there's no real private actions here, everyone is
required to publish CRL's in the?pub system,
? ?Russ Housley - No info from the CA about an OCSP server, so if you
publish this individually, you'll have to work out how
to differentiate this.
? ?RandyBush - upstream CP's should not force OSCP on subs, if you
like to do kinky things at home, please feel free.
? ?<random dude> - asking for how the text applies to a global
oscp/scvp service(s)...
? ?RandyBush - Keep in mind that this is for your network/routing
infra, don't rely upon something outside to get information about
outside (bootstrapping) + folks may want to charge you for this, ouch!
? ?(e) CPS for IRs and ISPs ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?15 minutes
? ?Template for an Internet Registry's Certification Practice
? ?Statement (CPS) for the Resource PKI (RPKI)
? ?draft-ietf-sidr-cps-irs-05.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-cps-irs-05
? ?Template for an Internet Service Provider's Certification Practice
? ?Statement (CPS) for the Resource PKI (RPKI)
? ?draft-ietf-sidr-cps-isp-04.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-cps-isp-04
? ?Presenter: Steve Kent
? ?Slides: (see previous set)
Notes:
?basic clarifications of CP -> CPS changes, search/replace of
relevant terms in the templates.
?notes about publication timeframes.
?lots of wordsmithing/terminology changes around clarification of the
processes and uses of the templates.
?AndreR - Should a global CPS conflict with a CP? This doc should
provide the guidance and we should remove the conflicts now to avoid
that conflict later?
? SandyMurphy - conformance language questions, is and how that's
used in the templates.
? ?(f) RPSL with RPKI Signatures ? ? ? ? ? ? ? ? ? ? ? ? ? ? 10 minutes
? ?Securing RPSL Objects with RPKI Signatures
? ?draft-ietf-sidr-rpsl-sig-02.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-02
? ?Presenter: Robert Kisteleki
? ?Slides: <http://tools.ietf.org/agenda/77/slides/sidr-3.pdf>
Notes:
?Quick update on how to push the RPKI info into RPSL
?The parts protected by the cert: name/num/country
?Locked down the parts which are signed over in the cert, an explicit
list is included now.
?Looking for Comments and Co-Author(s) (email robert or chairs)
?Feedback only from SteveKent so far really, though voluminous they were.
?RudigerVolk - The limitation of what to sign over seems strong, why?
?RobertK - The limitations are there to assure people really do know what
they signed/asserted and not more, since that may cause headaches and
danger
?SteveKent - limits are there to assure relevance in what you sign,
and remove danger from the case where you sign over things irrelevant to
the decision this RPKI is?helping you to make.
?RobertK - Some arguement over what should be signed/not-signed. this
is a reasonable suggestion, how about more on-list discussion.
?RudigerVolk - Perhaps mark down what the use cases of this are, that
should drive the things we sign over.
?SteveKent - Clear up the reasons why you'd sign, which may go to
Rudiger's use cases request.
? ? ? ? ? ? ? ? ? ?Nice readable doc, you need to also raise the
canonicalization parts still.
? ? ? ? ? ? ? ? ? ?essentially define in implementation details how
the parts are put together to?sign.
?RandyBush - Comments about sows ears, we need to define what it is
we are attesting to, not how to USE that, but what actually is hear and
signed.
? ?(g) Architecture and ROA Format ? ? ? ? ? ? ? ? ? ? ? ? ? 15 minutes
? ?A Profile for Route Origin Authorizations (ROAs)
? ?draft-ietf-sidr-roa-format-06.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-roa-format-06
? ?An Infrastructure to Support Secure Internet Routing
? ?draft-ietf-sidr-arch-09.txt
? ?http://tools.ietf.org/html/draft-ietf-sidr-arch-09
? ?Presenter: Matt Lepinski
? ?Slides: <http://tools.ietf.org/agenda/77/slides/sidr-4.ppt>
Notes:
? A quick overview of these to docs, which went through LC, all
comments save one addressed in the new version.
? We want to have a future where folks can actually make routing
decisions based on these.
? Some operational guidance (make before break, since these could be
used for routing decisions coming soon)
? Asking for WG consensus on whether or not this doc should include
some operations guidance
? RussHousley - non-normative text is fine here, don't pre-empt the
arch docs, though making it clear seems like a good thing.
? RobAustin - a warning is necessary
? GeoffHuston - This text needs to live in an Architecture Doc, not a
Syntax Doc (not this doc)
? SamWeiler - (Matt: strawman slide text is not what was sent to list)
I think that the text that you had was very gentle, I don't see what
would be wrong with including it.
? Need to take the text changes and resolution to the list for
finalized discussion. (note sam votes to ship it)
? SIDR Arch doc also through LC, more text coming for that once the
issues and comments are resolved.
? There's no conversation in the doc on how the RPKI is to be used,
that was removed intentionally, folks are asking for how this
could/should be used in ROA validation and?partial deployment scenarios.
? GeoffHuston - Notes that adding in the use information is a bad plan.
? WesGeorge - please expand geoff
? GeoffHuston - Noting how use cases would be done may cover ground
which isn't properly decided in the WG yet. (notes about rpsec and
origin vs path validation)
? ?SamWeiler - please hold this doc until we are sure how the
validation scenarios work, even in the case of partial deployment.
? ?DannyMcpherson - worries about conflating use of the data and
storage of the data.?this doc should only be a repository arch doc.
? ?GeoffHuston - agree with danny, disagree with sam
? ?RobAustin - agree with geoff/danny
?Matt asks for consensus call for previous doc + this doc as only an
arch or to include use cases.
? ?(h) Prefix Validation ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 15 minutes
? ?BGP Prefix Origin Validation
? ?draft-pmohapat-sidr-pfx-validate-03
? ?http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-03.txt
? ?Presenter: Pradosh Mohapatra
? ?Slides: <http://tools.ietf.org/agenda/77/slides/sidr-5.pdf>
Notes:
?Draft covers maintenance of the origin db on the router, what states
a path can be marked at,?where the decision is shown in the decision
process
?IOS and XR both have code bits for this today (in exp code at least)
?There's some iBGP state validation concerns:
?Based on your topology, it's possible to have an ibgp reciever see
paths from 3 versions of?the route, valid, invalid, not-supported.
What does the iBGP speaker decide?
?We need to carry the validation state into iBGP as well, to
influence selection over iBGP as?well.
?Options discussed:
? ? - policy changes to match the state, set attributes
(localpref/med/origin. etc)
? ? ? no standardization required here
? ? - well-known community
? ? ? ?requires validation
? ? - new attribute
? ? ? ?requires standardization
?Decision options discussed
?RandyBush - using communities means old routers can play, and
partial deployment is possible/easier.
?policy examples displayed
?process for a route update to appear - route in, validate,
policy-application, adj-rib-in, best-path selection happens, routes
pass into iBGP properly.
?please send feedback
?AndreR - How tightly tied is this tied to rpki/origin-validation?
?Pradosh - not tied to the rpki.
?RandyBush - Policy happens before validity in routers today, this is
a change to validate first, then policy. Origin validation is 'cheap', so
moving it up is simple, and provides?the ability to mix policy with
this later. ?note that when we add path-validation, this is a
potential pain point.
?SriramK - how much info is included at R1 in the internal router
pictures, about the validation system status at each edge router.
?Pradosh - There's no current data/cache for the status of the
validation system.
?RudigerVolk - inconsistent iBGP status, there are caching
status/consistency issues, so?assuming that a route is 'valid' at a remote
point at a consistent point isn't?possible. then discussion about timed-out
out/invalidteded routes and how that?may get missed after a current
validation has happened (stale data on router)
?Pradosh - notes that there's a mechanism to capture changes in the
cache and shove that through rib-in to clean things up as expiry happens.
?DannyMcpherson - Note how folks may already use localpref/etc for
customer over peer decisions, conflating a single attribute
is going to cause problems.
?3) New Drafts ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?20 minutes
? ?(a) Local Trust Anchor Management ? ? ? ? ? ? ? ? ? ? ? ? 20 minutes
? ?Local Trust Anchor Management for the Resource Public Key
? ?Infrastructure
? ?http://openmap.bbn.com/draft-ieft-rpki-ltamgmt-00.txt
? ?Presenter: Steve Kent
? ?Slides: <http://tools.ietf.org/agenda/77/slides/sidr-6.ppt>
Notes:
?how to run your own TA, to certify internally relevant data about routes.
?a process to make your own TA, and put that into the RPKI system as you
see it
?note that this creates a sideline system here, where some parts of the
real-world exist in 2?places. you have to decide how to view that in the
decision process at the router.
?Software was made to do this, happily.
?the software follows along with this draft/process.
?WesGeorge - is this to be configured on all devices the same? or
partial? or ? how large is 'you' in this case. Note how the incomplete
or incorrect TA list at parts of the network could cause inconsistencies.
?SteveKent - each RP is repsonsible for their own fate wrt TA's.
Differences will exist across the whole of the internet network, they
may exist locally.
(NOTE we did not get to these, at all)
?4) General Discussion ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?20 minutes
? ?(a) Second Algorithm and Transition Plan
? ?(a) Validation: Abstract vs Implementation Specific
? ?(a) Implementation Guidance
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
