Secure Inter-Domain Routing WG (sidr) 78th IETF, Maastricht WEDNESDAY, July 28, 2010 1300-1530 Afternoon Session I Auditorium 2 ===================================================== CHAIR(s): Sandra Murphy Chris Morrow (audio recording available) AGENDA: 1) Administrivia - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - WG Resources: http://tools.ietf.org/wg/sidr/ - Minute taker: Vesna Manojlovic - Jabber Scribe: Warren Kumari - Blue Sheets - Agenda Bashing Last Call status (slide #5) New WG documents (slide #6) 2) Requested Discussion Topics a) Removing TLS from the Provisioning Protocol Rob Austein http://www.ietf.org/proceedings/78/slides/sidr-0.pdf TLS was added to "up-down protocol" specification. TLS would theoretically protect from Replay Attack (example). Easier Replay protection; CMS timestamps, serial numbers, CMS introduces another problem, with MitM. Gregory: reboot. There are details that need to be worked out. A: Serial number Robert K.: if the MitM consistently keeps dropping messages, that is DoS. Jabber: Mike Hammond: if you include in your message which time-stampt you are obsoleting, that solves it. A: Gaps in the sequence, clock is not good enough. Speaker: We do not currently have with TLS protection against MitM. It could be a good additional requirement, but we would not lose it if we drop TLS. b) Alternative to the Trust Anchor Format Samuel Weiler http://www.ietf.org/proceedings/78/slides/sidr-11.pdf draft-weiler-sidr-trust-anchor-format Randy Bush: I disagree, we often have opportunities to simplify the drafts. I suggest we do not pass on this one. Robert: I prefer this one. Steve Kent: 1) it tries to re-define trust anchors, no need. 3779 tells you. This is the alternative. Q: What do you call it? Mechanism to verify the ... (?!) "something different". If this is going to become an Equivalent alternative, I've already suggested some changes in the comments to the list... Sandy: So, I hear there are some wording issues, no significant objection? A: If you add Second level, and the CRL. Randy: I would stress "explicit requirements". Rob Austin: I support it. A question to Steve: level of indirection, two level approach is a MUST? Does the WG agree to it being a MUST, or a SHOULD? I seem to recall the list supports the SHOULD. Why MUST? Steve Kent: Mandating good security practices. Sandy: I'll put the question to the mailing list. 3) Key Rollover (a) Key Rollover at RIPE NCC Presenter: Tim Bruijnzeels http://www.ietf.org/proceedings/78/slides/sidr-1.pdf Roque: Is deletion also manual, or the batch process? A: The start is manual, the rest is automated. I'm happy to do it either way. Rob Austin: I understood that all the algorithms are the same. Differences: no waiting period (?!) [staging period?] A: We go straight to the publication. (b) Key Rollover Presenter: Steve Kent http://www.ietf.org/proceedings/78/slides/sidr-7.pdf http://tools.ietf.org/id/draft-huston-sidr-aao-profile-0-keyroll-00.txt http://tools.ietf.org/id/draft-huston-sidr-repos-struct-02.txt Geoff: Step 5 happens after the staging period, not during. Geoff: "short" period means Minutes, not hours. This is the new document, so it needs review. Rob: all the implementations are doing more-less this. Comment: Lock around rsync will be .. pain in the but. I am not sure if the staging is necessary at all. Steve: We disagree. Let me explain why... Rob: OK, I have less problem with that. Rob: Do we really need to have the waiting period and locking so many things out? Geoff: The reason for suspension is to generate the clean overwrite. Sandy: It would be useful for this to happen as the conversation on the list. 4) Algorithm Migration Presenter: Roque Gagliano http://www.ietf.org/proceedings/78/slides/sidr-2.pdf Requested by Security AD. Summary: 3 questions: 1) Do we want to support only top-down algorithm transitions? 2) Do we want to support multiple signatures in CMS objects? 3) Any validation issue...? Robert: No, No, and "as long as there is *one* ROA that validates, you should accept" Paul Hofman: 1) No "top down". It will get in the way... Argue towards the "laisser faire". Rob: 1) I would like to understand it as "the Top-down is the minimum ..." (what?!) relying party is only 2) I am not sure it is worth going through all the trouble... I could live with the (...??) Steve Kent: You can not stop using the OLD algorithm, until the "end of life" / twilight. That is why the top down makes lots of sense. Geoff: I suspect that the transition means the relying party using "current" and "new" Sandy: this validates Steve's argumentation. 6) Updated Drafts (a) Certificate Policy Certificate Policy (CP) for the Resource PKI (RPKI) http://tools.ietf.org/html/draft-ietf-sidr-cp-09 Presenter: Karen Seo http://www.ietf.org/proceedings/78/slides/sidr-6.pdf (b) RPSL Signatures Securing RPSL Objects with RPKI Signatures http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-03 Presenter: Robert Kisteleki http://www.ietf.org/proceedings/78/slides/sidr-5.pdf (c) Use Cases Use Cases and interpretation of RPKI objects for issuers and relying parties http://tools.ietf.org/html/draft-ietf-sidr-usecases-00 Presenter: Sriram Kotikalapudi http://www.ietf.org/proceedings/78/slides/sidr-3.pdf 7) New Drafts (a) Publication Protocol A Publication Protocol for the Resource Public Key Infrastructure (RPKI) http://tools.ietf.org/html/draft-weiler-sidr-publication-00 Presenter: Sam Weiler http://www.ietf.org/proceedings/78/slides/sidr-12.pdf Are we ready to adopt this to the work item? Sandy: Will send a question to the mailing list. 8) New Topic (a) AS_SET, Aggregator Stats and Implications for the {Prefix, Origin} Validation Algorithm Presenter: Sriram Kotikalapudi http://www.ietf.org/proceedings/78/slides/sidr-4.pdf Q: Closest to the origin? A: The most recent AS is the extreme left, origin AS is the extreme right. Almost in all cases, the first AS after the AS_SET is the origin AS, therefore the Recommendation - disregard the aggregator! John Scutter, Juniper networks: OK ?: Can not treat the agreggator like that, .... 4-bite AS purposes: additional consistency checks need to be performed. AS SET is optional Rudiger: I am not sure if the new attack type is any different then any other attack that can be performed by such attacker. Private ASN should not show up. BGP specs need clean-up. Gregory, France Telecom: Conclusions based on current statistics. If we base the algorithm on this, add recommendation to do have the correct ASN behind the aggregator. John Scudder: It does make sense from the PoV of how the AS path is constructed. 5) Use of RPKI in Routers (a) RPKI Use in Routers The RPKI/Router Protocol draft-ymbk-rpki-rtr-protocol-06.txt http://tools.ietf.org/html/draft-ymbk-rpki-rtr-protocol-06 Presenter: Randy Bush http://www.ietf.org/proceedings/78/slides/sidr-8.pdf Q: Alexis: should it also reevaluate discarded prefixes? A: (?) Q: What happens when there is no other cache? A: Start paddling! (b) BGP Prefix Origin Validation draft-pmohapat-sidr-pfx-validate-07 http://tools.ietf.org/id/draft-pmohapat-sidr-pfx-validate-07.txt Presenter: Randy Bush http://www.ietf.org/proceedings/78/slides/sidr-9.pdf Solution: allow the operator to test the validity, and set local policy Q: Does something prevents the router to rewrite the policy? A: (?) John: you want all the routers to follow the same policies Jeff: advertise best-external-always Q: Alexei: if all 3 have different state... A: The reason for this is: Incremental deployment. When I add my first router (with RPKI), I can add this to my existing policy. Dani: If your different routers can have different cashes... then you have bigger problem. Rob Austin: Global distributed DB. They will not have the same view nor consistent state. 6) Updated Drafts Validation Signaling BGP Prefix Origin Validation State Extended Community http://tools.ietf.org/id/draft-pmohapat-sidr-origin-validation-signaling-00.txt Presenter: Keyur Patel http://www.ietf.org/proceedings/78/slides/sidr-13.pptx Defining the new extended community. Randy: Let's have this as the WG draft, so I can disagree with it. Alexis: I don't see why do we need 3 new community space for 3 new communities. Nor global well knows communities. You cna just choose A: It's just one, with 3 bits. Anyway, it is in my opinion, polluting the number space. John Scudder: I mostly agree, but with regular communities there is no transitivity bit. Dani: I support this. Randy: I think it could be useful for diagnostics. Final comment by the Chair: NRO has the deadline at 1.1.2011 to start operations with RPKI. It would be good if our documents be out of the Last Call. Before the Beijging meeting. Please comment on drafts! (next meeting - please send the slides before the day of the session).