SIDR WG, TUESDAY, November 15,
2011
Draft status (Chairs)
Slides: http://tools.ietf.org/agenda/
The 14 drafts in RFC editor queue
(see slide 12) will be published together as they reference each other.
BGPSEC Protocol
draft-ietf-sidr-bgpsec-
Matt Lepinski
Slides: http://tools.ietf.org/agenda/
Thanks to Wes George and Sandy Murphy
for comments on -01 already. Please keep the comments coming,
you too could be publicly thanked in the next presentation. :-)
This verion added the pCount field
to accommodate router servers that do not wish to put themselves in
the AS path because they are not really an intermediate AS hop on the
data path. This also allows an AS to insert pCount copies of the AS
number in the AS_PATH.
Wes George: I note that this is not
clear in the document.
A router server can add a signature,
but adds a pCount value of 0 to indicate that they are not adding an
AS to the AS_PATH.
If your peer is not a route server and sends you an update with pCount = 0, drop the update.
Wes: The correct behavior would be to drop the update rather than call it invalid?
Randy Bush: We need a consistent view of what happens. Some of the implementation folks say watch out, a drop is equivilent to a withdrawal so there's work to do here.
Matt: This is the correct behavior
for dealing with a BGPSEC peer who does not send conforming BGPSEC data.
For an invalid update this should be the behavior.
This is the major change in this
version of the I-D.
Preventing replay protection is an
additional goal of BGPSEC. The current -01 has an expire-time
mechanisms to limit vulnerability to replay attacks. Its goal is to
make sure that ancient business relationships do not come back to haunt
you.
Active discussions on the lists regarding
beacons is not going to be solved today. We need to understand the cost
of sending the refresh information. I welcome ideas on the list on cost.
Wes: This is largely a human timescale issue, but sometimes business relationships flame out in a fantastically short period of time and this is the point when you need protection. Maybe it would be correct to ratchet the beacons down until you're out of the woods, but then you might be pissing people off so need to converge on that.
Matt: The threat is real, what's
technically challenging is to protect against that without high cost.
Danny McPherson ("relying party"): Four points:
1) SIDR should ask IDR on periodic updates to BGP.
2) On "Preventing Replay Attacks" Slide the 1st bullet is incorrect. It doesn't prevent a malicious entity that is not legitimately on the path. I can divert an update to a peer and forward sign to them, and they will be on the path and be malicious.
3) With pcount we expose route servers which are not intended to be revealed, and people can use this for policy which we said we did not want to do.
Sandy: We asked Chris Hall to take this to the ISP community. We have not heard back from him yet.
Matt: I stuck this in -01 to get this kind of feedback from people who use RSs. Point well taken.
4) I use route servers today.
Elisa J: I use router servers, don't want to be influenced by a host that down't show up in the AS path. It will show up, right?
<differening answers>
Warren K: It is possible for someone to see the route server but it won't show up in the AS path length
Elisa: Some of these don't even have AS numbers.
Warren: They use 'private' AS numbers.
Randy: Interactions: private AS problem, handled separately (see John Scudder's talk). If they are truly transparent, no problem.
Matt: More discussion on list, please.
Alisa: There are sItuations where
you get an update from a BGPSEC speaker, send it to a non-BGPSEC speaker
and questions like that.
Shane A (Level 3): I sent a BGPSEC requirements draft question on list but no response. Are we accommoding AS migration scenarios inside of BGPSEC or not? E.g., L3 acquired Global Crossing. It is feasible that we might consolidate to a single AS in the future. The question is that because the AS_PATH length is so sensitive, router vendors provide knobs to allow customers to not change the ASes they are dealing with or to keep the path length short to prefer traffic in the same way. Now in securing the AS path are we accommodating for this or not?
Matt: I don't have a definitive answer as to whether we address the 1st one. The only way I can think of to allow the AS migration scenario but not open the door to man in the middle attacks pretending to do the same is to have another count=0 where you mark one of them as transparent, just an extra signature to show the migration is authorized.
Randy: Very good point. We've talked
about the kinky knobs and John might have a bunch of this in his presontation.
BGP Prefix Origin Validation
draft-ietf-sidr-pfx-validate-
John Scudder
Slides: http://tools.ietf.org/agenda/
The major change in -03, after several
people misunderstood -02 in the same way, is that we re-wrote section
2 to be even clearer about what implementations should do.
Pending changes for -04:
- Default validation states for routes that don't have one explicitly assigned. Proposed default is "not found".
- -03 and earlier restrict the validation
step to EBGP routers. This restriction will be relaxed.
Wes: I agree this is a good thing to do. We need a fairly good explanation around considerations around this that cover the "here be dragons" portion of this.
John: Please send text if you feel
so moved.
Discussion for --04
- If we are going to allow validation
to be run against local routes, what does "local" mean exactly?
This is not obvious.
Danny: The biggest concern I had
was when it means "nothing in the AS path".
Hope to last call after -04.
Operations Considerations
draft-ietf-sidr-bgpsec-ops-01
Randy Bush
Slides: http://tools.ietf.org/agenda/
If you have an upstream you really
trust, steal from their cache. Why bother the world when you can bother
someone you're already paying monty to?
Transparent route servers: May want
a knob to disallow a received pCount ….
Origin Operations
draft-ietf-sidr-origin-ops-12
Randy Bush
Slides: http://tools.ietf.org/agenda/
Slide 3: 'Close'
Shane: My concern is that these are
difficult questions to put in text, but we are not feeding information
via RPKI into routers that is changing their path selection locally
within a network. This has the potential of moving traffic around in
unexpected ways. All I'm asking is to note that this is a risk.
Chris: Some of this is implementation dependent on how you implement caches.
Randy: He's asking why they should be "as close as possible" (?)
Shane: Past versions recommended
to have deployed cache servers in nearly every POP. Why was that advice
in there? There's no recognition that this will influence how traffic
moves around the network. Adding that hopefully will trigger the reader
to think about the tradeoffs.
Slide 5: 'Which Attribute'
Wes: Somewhere else in the document you mention the potential race condition. Now that we're talking about something other than local pref you might have the same problem. You have a way of defeating the RPKI validation.
Randy: The downgrade attack, covered separately, hasn't changed.
Wes: Now you have the same problem due to more knobs.
Randy: Send me an email on that one.
BGPSEC Requirements
draft-ietf-sidr-bgpsec-reqs-01
Randy Bush
Slides: http://tools.ietf.org/agenda/
Slide 3:Transparent route servers.
This is a new requirement.
Slide 4: Route Leaks. What are 'Route Leaks'?
- Not mis-originations … we think
these are all caught today.
Paul Hoffman: Why are we discussing this, since this is a requirements document? Will we have requirements about leaks after the discussion?
Randy: If we learn what we are talking
about then we hope to have requirements on it.
Steve Bellovin: I don't know if we
can come up with a definition. If so, then we'll see if it belongs in
this document.
- Not protocol violations
- Not policy violations … these
are violations of business policy, not BGPSEC policy.
Danny: If you want to call this policy, fine. I don't know what to call it but I'll know it when I see it. :-)
Sandy: As Steve B. said, If we can't write a firm definition, we won't.
Danny: Multi-homed, but not authorized
…. if SIDR can't enable solving the policy issue (in or out), it 's
important. If policy is where we go, but if we say we're securing the
AS path, or advertise reachabilty when they shouldn't, it's a problem.
Maybe I need to solve this differently if BGPSEC won't solve it.
- Protocolis what we know, not intent.
All we know is that no one hacked the protocol itself.
Danny; This is useful.
Slide 11: 'Business Intent is a Human
Concept'
Danny: 36ms?
Randy: Not a measured number
Danny Probably in order of hours.
Steve B: In the whole Internet?
Danny: how many ASes added to the Internet? …
Chris; point is, it happens.
Paul Hoffman: Go back to slide 8.
In the 2nd sub-bullet (Customer offering ….). This may be detectable.
Going forward, we are saying we can't determine it? Maybe we can do
it, maybe we shouldn't.
Geoff Huston: When you say "We cannot know", I disagree because you could know. It's possible. Like many of these things, if everyone published you could understand intent. In the same way as ROAs, etc. plays, if everyone published policy you would know intent.
Randy: that statement is correct.
Randy, Shane will you publish this?
Shane: I'd agree with Geoff, but it's impractical to know everyone's policy in the Internet
Geoff: I never claimed it was practical
Shane: It's impractical though for me to know, but I have business/contactual relationships in place with everyone attached to my network. So I take issue with "I don't know policy" because I know it for those to whom I am attached.
Randy: Would you publish to another ISP?
A: I do.
Ruediger Volk: You usually know the
policy, but Randy understand that some customer I have is announcing
Shane to me, which is breaking the supposed thing. It is important that
i have the reliable information that my customer is messed up and sending
me stuff. BGPSEC gives reliable info that I can match with the reliable
polic I know and I can fix that problem.
Slide 9: Jared Mauch's service publishes
leaks. No one would bet routing on it, but it helps. It's not formal
enough for our use.
Slide 10: IRR and Other Policy Publication
- Not sufficient expressed policy.
Some high level intent but not pre prefix per-path.
Shane: Clarifying question: You say policy, I might not think of the same thing. Traffic info? Local pref, etc?
Randy: Publishing who my customers are is what I mean.
Shane: You're expressing publishing of prefixes that belong to your customers
Randy: And transit and peers.
Business Intent is a human concept
- Those who want to publish intent could then compare it to the BGP state
- But it's not acceptable at any
sufficiently detailed level.
Lets meet in the bar and try to formally
define a route leak.
Chris: If you decide, or are you open to going to IDR and asking to add a bit?
Randy: That's implementation. I'm
trying to be open minded and understand the space. If I do, then we
can formally define it and then detect/control/mark it or whatever.
Steve B: Chris, until we define it
we don't even know where a solution will live.
Wes: Shane said earlier, I know what
is in my cone … my policy … if there's any way to come to conclusion,
we should be able to not share it beyond that cone.
Algorithm Agility
draft-ietf-sidr-algorithm-
Steve Kent
Sides: http://tools.ietf.org/agenda/
Changes are working group last call
issues and fixes based on last call comments. It describes the underlying
assumption for algorithm transition. It states that the
policy OID for RPKI certificates would not change when an algorithm
changed. When a transition happens, an additional document would describe
the transition timetable for the algorithm suite transition.
Describing the types of event that
might cause the timetable to be revised. E.g., if there isn't support
for Suite B in product yet then won't move forward in the timetable.
Corrected the end of life description.
Clarified why a top-down approach
for algorithm transition is required vs. Laissez Faire approach.
One reason is that the CA cannot perform proof-of-possession of the
private key if the CA doesn't support the same algorithm.
Paul H: I'm having a bad flashback to PKIX about PMP that we could prove that we had all the right parameters. Are you talking keys?
Steve: Yes, keys … requirement is proving I hold the private key that matches the public key in certificate request.
Paul H: OK, that is where PMP fell
apart.
Eric O: Back to slide 4 (transition timetable). "… track the progress". As I said on the list this document is describing a formal process. For it to be complete you need to detail the exception cases.
Steve: No, because we decided a different set of people would determine the timetable, then they're going to decide.
Eric: I agree, but that's not what I'm commenting on. You're taking about the procedure to track the change.
Steve: A different set of people should be controlling that process, that includes measuring successful deployment.
Eric: What does that success look
like? What would you be tracking to determine success?
Global vs. Local transition process.
Need to have widespread agreement on when to move and relying parties
need to know what they're expected to do. Must be a global process not
a local one.
Danny: You don't have to answer this comment right now, but in general the handling of expired certificates.
Steve: That has nothing to do with this.
Danny: It does, because if one is invalid you have to address this.
Steve; You can choose to do this locally, but …
Danny: You have to be careful of an attack.
Steve: Our software has a knob for
this.
A Profile for BGPSEC Router Certificates, Revocation Lists, and Certification Requests & BGP Algorithms, Key Formats, & Signature Formats
draft-ietf-sidr-bgpsec-pki-
Sean Turner
Slides: http://tools.ietf.org/agenda/
Diff between drafts
- PKI profiles differences (e.g., standards for Subject Names)
- Omit Subject Information Acesss
extension
Big difference is algorithms
- Algs used to sign the certificatess
is still RSA But BGPSEC uses ECDSA with SHA-256. ECDSA has smaller signatures,
keys and certificates.
Brrian Weis: I thought there were IPR concerns with including an ECDSA public key in a certificates signed with RSA.
Sean: IPR that I'm aware of is for
point compression, parameter validation, and for speedups. We're not
going to use these. We point to NIST but will point to RFC 6090
instead.
Q: Does this have anything to do with algorithm agility document?
Sean: No.
Q: Impact on resource certificate relying parties?
Sean: None
Russ Housley: Did you really make a relative SN with 2 relative value pairs?
Sean: Yes
Russ: Don't.
RPKI-Router Protocol MIB
draft-ymbk-rpki-rtr-protocol-
Bert Wijnen
Slides: http://tools.ietf.org/agenda/
Merged two MIBs into one. It was
too late to submit the I-D before the meeting.
Need to add an object to the BGP4
MIB. Not sure if it will be included int he current MIB4 MIB or one
in development.
John Scudder: We do plan to move
the draft BGP4 MIB forward, not sure when.
John Scudder: What do you need to decide which MIB to extend?
Bert: Decision needs to be made by
the WG.
First Performance Results of RTRLib
Matthias Waehlisch
Slides: http://tools.ietf.org/agenda/
General objective: implement RPKI-RTR
in C. Release v 0.2 has been created. Will be released at the
end of this week. They will show preliminary results for the current
state of PRKI for real BGP streams. THey did benchmark on commodity
hardware.
See slides for results and the project
website location.
Estimating CPU Load of BGPsec on a Router
Sriram Kotikalapudi
Slides: http://tools.ietf.org/agenda/
The study focused on BGPSEC islands rather than the whole Internet. See slides for results. It includes basic measurements of the cost to sign/validate using one core.