(from: ) 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          Chris Morrow 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:     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 validatoin 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  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: ?????    (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: 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.     - 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: 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: 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, thogh 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)   SamWeiller - (I missed this comment, a quesiton about the text and whether or not the                       displayed was what made it to the list)   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)    SamWieler - 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: 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 - incosistent 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/invalided 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: 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. -Chris (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