Re: [sidr] minutes from the IETF84 sidr meeting

["Murphy, Sandra" <[e-mail]>]

Did not state the obvious, sorry.

Please review the minutes and post any additions or corrections to the list.

--Sandy, speaking as wg co-chair
________________________________________
From: [e-mail] [[e-mail]] on behalf of Murphy, Sandra [[e-mail]]
Sent: Monday, August 06, 2012 2:44 PM
To: [e-mail]
Subject: [sidr] minutes from the IETF84 sidr meeting

The meeting minutes were collected on the etherpad tool and are available at:

http://tools.ietf.org/wg/sidr/minutes

For convenience, below is a copy of the text.

--Sandy


SIDR
August 1, 2012

Note takers: John Scudder

(Times provided for correlation with audio recording.)
(No attempt made to capture anything that can be gleaned by reading the slides.)

9:03
Meeting begins

Reminder that authors must disclose IPR.

9:08
Draft status

9:09
Do we need a WG call for combining -cps documents?
(various mic comments: no need, WG has already adopted the work, organization of which drafts it goes in is immaterial)

9:11
validation signalling dead unless authors resuscitate it

9:15
randy bush: signaling draft has multiple interoperable implementations, let's move it forward
chris morrow: it expired
randy bush: will fix.

9:16
randy: what needs to happen for pfx-validate to proceed?
chris: I just need to do the writeup
randy: ...

9:17
Steve Kent presenting Unified CPS
9:20
soliciting comments from WG, especially IANA, RIRs, and large ISPs
9:21
sandy: have the ISPs and RIRs expressed any opinion about combining the two cps documents?
steve: we didn't ask first, we haven't received any feedback and it's been out there for a while.
(room polled, no comments)

9:22
Steve presenting Local TA Management
9:23
(obnoxious cell phone, please turn off your ringers)
9:29
should standardize syntax to facilitate interoperable tools (editors, etc)
suggests waiting for next version to come out as it "will be an easier read"
9:31


rob austein: about standardizing the syntax, you may want to consider making the syntax recommended, wait for second implementation, then standardize.
steve: please send a more detailed message to the mailing list

9:33
Matt Lepinski presenting on BGPSEC Protocol
9:39
technical change needed for problem: some algorithms (ECSDA) will produce different signatures if applied twice to same data. This implies special handling needed for duplicate updates.
9:40
randy: re-keying will change SKI, so something other than the signature will change.
matt: yes, ONLY the actual bits of the digital signature are to be ignored.
randy: all the implementor has to do is pay attention to the SKI.
9:41
keyur: one request, please document what randy just said
steve kent: if we included the hash that would be helpful
steve bellovin: no
kent: yo mama
bellovin: sez you
(in other words the minute-taker was unable to capture anything other than a disagreement)
9:43
rob austein: the router guys can recognize dups, we just had to explain how using signature bits and SKI
9:44
sam weiler: is there an attack here? if you were to revoke a cert, you'd change your SKI. but could an attacker replay the SKI and signature bits?
matt: how often are you going to go through your rib-in and revalidate all your signatures just to make sure none have expired or gone bad based on rpki state?
matt: this is completely separable and is a general implementation dependent issue having to do with things that were ok when you got them but rpki state has changed such that they now are not. this is unrelated to dup detection.
(general nodding)
9:46
sriram: when you get a dup, if state changed from invalid to valid or vice-versa that would be an issue.
9:47
matt: if it's a dup, why would you bother revalidating?
wes relaying padma from jabber: mic: is ML suggesting RPKI state sync with RIB in- what woud trigger a sig check trawl thru RIB in?
9:48
randy: rpki update
matt: agree but not for this doc
jeff haas: the property we're looking for, is that the box receiving a dup suppresses it at that point. we want to preserve that behavior.
matt: agree
9:50
john scudder: is it generally the case that the SKI will change whenever the key changes? this isn't specific to ecdsa right?
matt, rob: right
padma: mic: how would that rpki update be  noticed by router?
randy: analogously, how does a router notice a bgp update? the tcp stream provides the data. if you're asking how it matches it to the data in the rib-in, then look at the prefix-validate document. I feel we must be missing the question.
9:52
(some missed)
randy: now I get it. a new public key comes in that covers some set of prefixes. fair point since rpki-rtr doesn't currently cover router keys. that is because the spec isn't done, we'll update rpki-rtr when needed. sorry for misunderstanding.
9:53
doug m: should be clear in spec about whether you must validate update, vs. are allowed to skip validation step.
matt: there may be disagreement on that point, we should discuss on the list.
(agree to disagree, move to list)
9:55
john scudder: suggest making validation inside confed optional. otherwise, looks good.
matt: sounds reasonable, I'll make the change unless there's an objection.

9:56
Sandy summarizing interim

10:05
eric osterweil (sp?): nice to see we're starting to model larger sets. Any intention take this approach up to something as big as or bigger than today's internet, then plot performance curves to show how performance degrades with scale? I don't mind seeing rsync included, but this kind of methodology can be applied to other distribution protocols. this may teach us something about the underlying architecture, independent of specific distribution protocol.
10:06
randy: yes.
eric: that's not sufficient.
randy: almost yes. i.e. we're trying to do that kind of modelling, look at other distribution protocols. adding bittorrent, trying to do it at scale, specifically not presuming it won't scale.
eric: nothing scales forever, but don't read into my words something that's not there.
10:08
randy: coherency isn't easy to define in this case. it's a lot like dns. at any instant in time there is no "correct" global view. some protocols (rsync) will have more homogenous views than flooding protocols (bittorrent). we would be glad of more collaborators for the research!
10:09
eric: great. I disagree that my implication was that this won't work, it's just that any system has scaling limits. as for consistency model I don't care about that for micro benchmarks, where we can just focus on fetch time.
10:11
randy: this was all in the presentation.
(vigorous bickering at mic, ignoring chairs)

sandy (voluably): sit down and shut up

tim: I think randy and rob's focus has been on how this data can be shared between relying parties and such. We on the other hand have looked mostly at server load. As Eric said, there's an end to all scaling. ... Current repo about 4000 objects, at current size I see no issues. We're doing test and modelling to let us forsee problems before we encounter them.
10:13
randy: server load and router load are salient points. these are also susceptible to operational fixes. broken protocol, otoh, not so much.
chris: the numbers you're using to do scaling testing. we talked in may about 2/5/10 year target numbers. today's testing should test for the projected numbers. finally, a lot of the discussion that was at the mic should be recapitulated on the list.
10:15
randy: your two questions are, how big a number? we are shooting for 1M prefixes. will buy dinner for anyone who can gen the whole rpki data set from bgp data. second, timing? totally dependent on (missed, maybe cycle/refetch time?).
10:17
eric o: thanks chris, that was what I was trying to say. 4000 sounds great, what does that mean? (something about chickens, elephants and tigers.)
tim: after paris meeting I asked on the list for people's ideas about requirements, not much feedback, but very happy to discuss it. also, I do believe that current deployment works, I just want to look to the future.
10:18
rob: 1. the way I'd characterize the discussion: we have early measurements that indicate we have the potential for a success disaster. we can get going but need to plan ahead. 2. we are starting to look at things like bittorrent potentially even for top-level publication. we'll report back when we have data. 3. we had a protocol observation from steve kent on friday. one of the drawbacks of the current approach is that we don't have (something mumble something). there is a time til next manifest, steve pointed out that this could be a hint for time until next poll.
10:20
danny mcpherson: agree with chris and randy. (something about implications for architecture) i imagine we would see more churn in the rpki than the actual routing system.
10:21
sandy: geoff was on remotely on friday and gave an estimate of the size of the routing sytsem a few years out. of course we have to design for that scale.
10:22
sandy: please look at interim slides, they're all available

10:27
Carlos Martinez presenting on Multiple Publication Points

(hilarious hijinx with recursive comments related to mic placement and use)

questions for group on slide 5; propose WG adoption

10:34
rob a: ok, I oppose it. I think you're solving the problem in the wrong place. I don't see value here, I do see more complexity for relying party. put all the names in the DNS instead of putting in lots of URIs. Also, at least put in a blank line after all the URIs and the key.
carlos: sure, we'll put in a blank line.
10:35
randy: +1 rob. non-problem, added complexity.
ruediger: don't let work on this stop you from fixing whatever problems the current publication points have.
carlos: definitely.
tim: I thought this was good, I do see complexity in RP software. I think it's worth continuing this on-list, we won't reach consensus here.
terry m: I want to see the discussion continue. I don't think it's ready for wg adoption. I'd like to continue on basis of looking at format of TAL.
10:37
(name? bbn): what problem are you actually solving? what is the RP supposed to do if presented multiple choices.
carlos: we might need in the future different things we can tweak, just as we do with the DNS. we may use it, or not, but the possibility will be there. I also like the chance to remove the dependency on DNS. might let us remove a circular dependency.

10:39
Benno presenting on RPKI ond Origin Validation Operational Practices

Don't have a full document yet, we're trying to get interest from the WG.

10:44
randy: first bullet on slide 5 -- we all know RPKI is object-based security, I'm a little lost about 'identity and authority management' and as for 'key management' is that related to how I distribute the IANA TAL? I'm a little confused.
benno: I think the first... I'm putting a lot of things on one pile. I'm also talking about who is authorized *in an organization* to touch key management.
10:46
rob: as far as key management, there's an issue for (something related to private keys)
10:46
doug m: phased adoption model? that's something the community has struggled with. piloting, alerting, before going to full-on 'ignore invalid' all over the world.
10:47
benno: interesting to consider that. wasn't part of the scope we had in mind.

see slide 6 for questions to the WG

10:49
wes george: I support the document, also agree with Doug. To go back to organizational issues, there is typically a gap between router and security staff at an operator, so yes, guidance is needed. As to questions on slide 6, I think this would be best as a wiki, similar to v6 deployment resources. maybe start with a draft and turn it into a wiki, but eventually a wiki is better than bis and ter and what have you.
10:51
randy: philosophically I agree with you but as an ops community we have a poor track record at maintaining wikis. Benno, there is some stuff in there that should go in origin-ops. Plenty of room for co-authors!

10:52
Randy presenting on grandparenting
there are no slides

- There are operational reasons for a large RPKI CA that has children they'ver certified, the children's children may need grandparents to act for them.
- Some of the circumstances are enumerated in the document. Non-exhaustive list. I don't object to adding more, email me.
- Current draft is second iteration, suggests one circumstance. Suppose someone big, like a large ISP or RIR who due to their operational practices needs to provide a facility for grandchildren to request action, might automate (e.g. web portal).
- This draft merely points out that this can already be supported in the existing RPKI structure, and that it is an operationally needed facility.
- That is all.

10:56
sandy:

(here endeth my contribution to the minutes)

(Carlos taking over minutes)

Sandy asks for clarification on the example presented on randy's grandparenting i-d

A. Robatchevsky: what guidance does the draft actually provide? my concern is that the rpki follows the delegation structure 1 to 1, and that this draft somewhat subverts that. Technically is all posible. Why do you want to advertise that?

Randy: because its operationally useful.

(Doug mc henry) different grandparenting schemes are possible, some of them more useful than others. Some people concerned about non-useful uses of the same techniques. Certain possibilities are more indicative of a problem than of a solution.

(Rob Austein) one way of looking at it is providing guidance on how to address these situations.

(T. Manderson) as an interim measure until things smooth over

(Sandy) we already have docs on parents doing things on behalf of the children, i'm not sure why people find the grandchildren case more troubling than the children example

(Randy) due to not having obvious contract relationship

(S. Kent) it's possible to do this in a way that is virtually invisible. I'm in favour of exploring this but share some of the concerns others have expressed

(W. George) this wg has a lot of documents, don't understand why this has to be a separate doc, can be included in an existing one

(Sandy) discussion of interim meetings

(Sandy) in march we did not put one for August, for the date for September, it was proposed to hold one together with the RIPE meeting in september. There will be a LIM (large interim meeting) on sept 29, the saturday after the RIPE event finishes. Chances are the venue will be the same as the RIPE meeting. None of these are final details but pretty firm.

IETF would like to know whether SIDR would hold a meeting in the LIM.

(Sandy asks for opinions)

(W. George) the schedule puts operational items first and policy later. We risk losing the operators.

(Randy) RIPE is different, operators stay over. People doing policy in RIPE actually touch routers.

(R. Volk) Randy's reporting is right.

(W. george) I'm not sure whether other WGs considering using the LIM

(R. Houssley) other WG considering it v6ops and weirds

(Sandy asks for a vote, R. Houssley wants a number)

The number is just over 20

(Sandy)

we can hope we'll get some more attendance.

Beyond september: interim meetings have been productive, we need to set up a plan. There's a nanog/arin meeting in Dallas, IETF in novebmber in Atlanta and we can talk about December

RIPE is end of sept, IETF begn of nobemer

(Randy) could the chairs and authors so that the meeting in AMS is to confirm WG concensus from the list on all the docs we having waiting?

(Randy) yes, all of them if possible

(W. George) i'd like to ask the folks who routinely complain about the interims what can we do to have you participate. i'm getting frustrated by that

() we don't use the meetings to make decisions

() restriction, travel budget. if we can take that out of the equation, then it becames possible to participate

(R. Volk) let me remark that all the interims have had effective remote participation. i have participated in two of them, it is actually possible

(Wes Hardiger) lack of virtual blackboard

(Chris) we're looking at  January, we'll talk about that in November

(Rob Austein) we should use the IM to have deep technical discussions and use the face to face in ATL to push docs out of the door

(Randy) docs should be out the door before dec/jan, it would be nice to have some sidr technical workshops

(Sandy) only concensus i see is for sept 29 with RIPE

(Sandy) we're done, thank you very much



_______________________________________________
sidr mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sidr