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 <morr...@ops-netman.net>
(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
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr