Below you will find the minutes from our meeting at IETF 76 in Hiroshima.
My apologies to Paul Hoffman, who took the minutes and sent them to me
promptly. My fault for the delay.
Please send any comments, corrections or additions to the list.
--Sandy
SIDR
Monday morning 2009-10-09
Sandy Murphy and Goeff Huston
Minutes by Paul Hoffman
Material from the slides is not reproduced here
Blue sheets and groovy RFID thing were passed around
Agenda additions
Sriram has some additional use cases, if we have time
WG Last Call deadline is next Monday
Please comment on the list, we need more feeling about consensus
Current drafts were presented
RPKI Architecture - draft-ietf-sidr-arch-09.txt
Matt Lepinski
Discussion about recommendation about query frequency
Probably doesn't belong in the architecture document
Turns out to be contentious
Possible operational considerations document
Randy Bush: MTTR was correct in the breakup of chains
In WG LC
CP - draft-ietf-sidr-cp-07.txt
Stephen Kent
[[[ Scribe note: Maybe also covered
CPS-IR - draft-ietf-sidr-cps-irs-04.txt
CPS-ISP - draft-ietf-sidr-cps-isp-03.txt but can't tell ]]]
Have a bunch of changes to be made
Forgot to make some changes that were agreed to
Will say "BCP" instead of "Informational"
In WG LC, but knows that there will be another draft with the known
issues
ROA Format - draft-ietf-sidr-roa-format-06.txt
Matt Lepinski
Now points to the algorithms document
Rob Austein: the order of the checking should not be mandated
Maybe suggest an order
Manifests - draft-ietf-sidr-rpki-manifests-05.txt
Matt Lepinski
Gave overview of why we want manifests
Wants more review
Authors know of no outstanding issues
Certificate Profile - draft-ietf-sidr-res-certs-17.txt
George Michaelson
CRL reason codes had little interest from the WG
Do we have to think about algorithm transition?
Rob: algorithm transition just looks like key roll
Steve Kent: what Rob said
Repository Structure - draft-ietf-sidr-repos-struct-03.txt
George Michaelson
Suggestions, not prescriptive statement
ROA Validation - draft-ietf-sidr-roa-validation-03.txt
George Michaelson
No recommendations about how it should be done in BGP
Sandy Murphy: Is that one sentence a recommendation?
George: will review that wording
Sandy: didn't put this through WG LC yet, on purpose
Lots of different questions, including IPR
Should the validation scheme be with an implementation?
John Scudder: This is informational
There is a need for a standards track document telling BGP
implementers what to do
If this was the only draft, that is not a good thing because it
is not helpful to the implementer
George: Similar to previous question on PKIX
Doesn't feel comfortable telling people what will work
Agrees that something normative is needed
John: Do you have concern about the two drafts having a lot of
overlap?
George: Has issues that needs to be thought about
Russ White: Need to be careful with any presecriptive document
Customers want policy to be left on the router
We need to be sure that we understand where the line between is
drawn
R?diger Volk: Objects to the claim that none of the customers want an
external server
Geoff: Can a standards track point to an informational doc?
Russ Housley: Yes, with a few extra steps
Russ White: Lots of concern that off-boxes would would decide the polic
Chris Liljenstrolpe: Off-box process should be providing further input
to BGP best path
George: Sees reason to have differentiation and therefore more than one
documents
TA - draft-ietf-sidr-ta-02.txt
George Michaelson
Not much left to do
Provisioning Protocol - draft-ietf-sidr-rescerts-provisioning-05.txt
Byron Ellacott
In WG LC, couple of identified issues
Rob: HTTPS does not provide replay protection
Might need timestamps
Thinks there is at one real replay attack
If the attacker can capture the PKCS10 attack, might be
able to do something with it
Might be plausible based on whether the keys are kept
online or offline
The consequence is a key compromise of their private
keys for the RPKI
Can ask for a reissued key
Robert Kisteleki: If the parent remembers that the key has been
reovked, it can be prevented in the protocol
Not a use of an old certificate, it's getting a new cert
Steve Kent: Why would one set of key material be protected than
another
Let's be precise in what is being offered
TLS is hiding the details
Will provide pictures
RPKI Algorithms - draft-ietf-sidr-rpki-algs-00.txt
Geoff Huston
Biggest question is handling multiple algorithms at the same time
Three choices
Not the same as key rollover
Rollover overwrites, is not parallel
Algorithm change needs both being valid
If we go down the path of parallel issuance, we need to know *how* they
go parallel
Likes "punt" the best
Rob: Only agreed to the first two thirds
Doesn't like option C
Tim Polk: Transition from one algoirhtm means all the relying parties
can do the new one
Just doesn't work
Need a period of time where are using both
Rob: We already use hashes of public keys, so that may save us
We could require key changes when the transition happens
George: Could make a requirement for top-down
This would make the size of the repository smaller
Paul Hoffman: Don't assume that the top will want to double-sign just
because the ones below do
Rogue Gagliano: Any transition will cause a lot of problems and question
Geoff: There will be tradeoffs regardless
Steve Kent: We are talking alogithm transitions that happen by a change
to the CP
Can only occur when the second set of algorithms have already
been defined
Will take this to the mailing list before revising the draft
Will take it back to the Security ADs and Secdir
Sandy: Security ADs: how to proceed?
Tim Polk: Other drafts can be moved forward
Would like to see a second algorithm specified now;
maybe ECDSA
Would also like to see the transition described
Wants to see at least -00s before the current stuff can
be RFCs
Wants more than just a promise to start
Adrian Farrel: Is the new stuff normative?
Geoff: Noted
Sandy: Implementation report?
Adrian: Not required, but would be nice
Ross Callon: Was required in years past, but not now.
Now new stuff is small enhancements
Rob: Wants algorithms from OpenSSL
Paul: ECDSA is in OpenSSL
Update on Use Cases - draft-manderson-sidr-usecases-01.txt
Terry Manderson
Wants more use cases?
Steve Kent: Problem with definitions
No introduction to how the use cases were chosen
Maybe a decision tree
Danny McPherson: Agrees with Steve
Would like to see a taxonomy
At what point would we bring path validation into scope?
Sandy: Still thinking, but wants to hear from Routing ADs
Ross: Finish complex work first
Wants to hear whether there is consensus to
work on path validation at all
Sam Weiler: Thanks for route announcements that should not be validated
Geoff: please volunteer if you want to see this as a WG item?
Local TA Management
Steve Kent
Basic rule: the relying party is its own trust anchor
Will later have a tool that can automate this
That tool will show some complexities
Danny: Trading autonomy for security
What about conflict resolution
What is the resolution model if there are conflicts?
Steve: you will get warning messages, but that's it
Concern about naive relying parties
Andre Robachevsky: Doesn't understand the use case of protecting a
particular entity
Steve: Want to not be fooled into misrouting
You are not protecting other parties from misrouting
If you have influence, you can have a bigger influence
Sandy: Aware that this only for local power
Gives you the power to shoot yourself in the foot
Is wary of people trading these local decisions around
Don't mke it too easy
R?diger: Fears that there is a perception that everyone has to do this
Could negatively affect those who know how to use this
Would hate to see this become a generally used feature
Randy: RFC 1918 space is the common use
Would be nice to have 1918 space example that is safe
Rob: In the 1918 space, there is a clear partition
Needing a separate trust anchor to do it
Parallel characterization to .mil looking at IANA
Spoke against this in Stockholm, now retracts
Andre: Still uncomfortable because "bar" case is so limited
Thinks that it is only useful if you have influence over other
Steve: Depends on what you mean by "protection"
It is about your own scope
RPKI Operators Roundtable Report and Discussion
John Schnizlein
ISOC meeting for Securing Routing Information
Was not just about RPKI
Succeeded because ISPs did hard work and exposed good info
Gregory Lebovitz: Resolve vs. assuage on the differences
Terry: BOA draft is not dead yet, but depends on the definition of the
ROA
Did not want to subvert the purpose of this WG
Rob: What is a "neighbor"?
Jared Mauch: Some service provide the capability to blackhole an
origin, not just a destination
Randy: When an originator puts a route in, it is to protect themselves
George: Thank you for holding this (general applause)
Wes George: Router behavior in coming up and convergence
Some Remarks on ISOC Roundtable
R?diger Volk
Most operators there do show up at IETF
Ran out of time
Sandy had a long list of things that we didn't get to talk about
All of them will be on the list
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
