Re: [sidr] Draft minutes from IETF78 Maastricht

[Sandra Murphy <[e-mail]>]

And this one, too:

On Wed, 25 Aug 2010, Sandra Murphy wrote:

> Here are the draft minutes from IETF78 in Maastricht.  Thanks to Vesna 
> Manojlovic for volunteering to produce the minutes.
>
> Please send corrections, comments, additions, etc., to the list.  Final 
> minutes are due 15 Sept.
>
> These minutes have been uploaded to the IETF web site.
>
> --Sandy

   --Sandy, speaking as wg chair

>
> Secure Inter-Domain Routing WG (sidr)
> 78th IETF, Maastricht WEDNESDAY, July 28, 2010 1300-1530  Afternoon Session I
> Auditorium 2
> =====================================================
> CHAIR(s): Sandra Murphy <Sandra.Murphy at Sparta.com>
>          Chris Morrow <[e-mail]>
> 	(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).
>
>
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr
>