SIDR IETF 83
Two sessions: Mon 26 Mar 2012 and Wed 28 Mar 2012
Minutes of both meetings
= = = = = = = = = = = = = = = = = = = = = =
Mon 26 Mar 2012 IETF 83
No skype or webex due to issues with Sandy being unable to get online.
Jabber log for Mon 26 Mar 2012: http://www.ietf.org/jabber/logs/sidr/2012-03-26.html
13:19
Sriram:
Estimating CPU cost of BGPSEC on a router
- Incrementally deployed
- Each gets benefit of origin validation
- Depends on neighbor participation.
13:22
Provider in the process of deploying BGPSEC may have a few paths from ebgp that are signed, but many that aren't. "Cones"
Slide showing ISP "cones" - distribution of prefixes vs. length
i7 2.7 3400MHz core able to do 2215 verifications per sec, 2500 signatures per sec.
Compare vs. number of updates per second that can be processed as a function of AS Path length.
Signing curve is flat since only one signature needs to be computed no matter the path length.
13:28
Order of 35 seconds to process at R ~40k prefixes. Compared for peering session reset.
"No need to sign to stubs"
Graph showing that ~84% of ASes are stubs.
13:31
Slide from data supplied by Randy Bush - four providers, < 8 ebgp peers (not customers). One sample with 29 peers. If only doing bgpsec for non-stubs, this is a small number.
13:33
Scenario showing one incoming session reset and readvertising to 3 other ebgp customers. Receives 30k prefixes, validate and send to 3 peers ~73 secs.
Summary:
Islands of BGP sec, costs examined vs. Intel Sany Bridge i7 (3.4GHz) single core. Not concerned in this platform.
13:35
Q&A
Wes George: It'd be helpful to compare these figures to what it looks like without bgpsec.
Sriram: Currently around 300 us per update. BGPSEC adds about 2 ms per update. We'll try to provide this in tables.
Ruediger Volk: It depends on the amount of policy processing, and that is impossible to predict.
Randy Bush: This is not my work, it's impossible to predict this stuff.In order for this to be accurate, we need measurements with actual BGPSEC
implementation.
Wes: I'm not asking what this does in my network. I'm asking for comparison under same conditions.
13:38
Randy: (Reiterates that these numbers don't represent much.)
Wes: I'm not sure I'd say the times cited are "OK" or "negligable".
Chris: Would it be helpful if you had a tool with the methodology (Sriram’s) [in which you can input parameter values yourself
assuming no BGPSEC]?
Wes George: I'm not asking what this does in my network. I'm asking for comparison under same conditions.
Shane Amante: I had a hard time interpreting your table "Data* on Number of Peers per Router". The numbers in the first row don't seem to add up to the # of peers in the second column.
Sriram: he first two columns on the left are non-customer (core facing) peers. The last two columns are customers. Last (right most) column is BGPSEC customers which is just a percentage (16%) of the 3rd column (i.e.,
total customers).
Shane: By "peers" you mean what? "Settlement-free peer" or "BGP peer"? What terminology are you using?
Randy: settlement-free.
Wes George: Are the 30 sec and 70 sec type of numbers (for convergence after BGPSEC peering reset) small enough? May not be (did not elaborate why he thought so).
13:41
Jeff Haas: From PoV of overhead, everyone implements peer groups. BGPSEC breaks these optimizations.
Randy: We look forward to having code so we can do some measurement!
Brian Weis: There will be more overhead than just signature checking. But on the signature timings, were there any speedup tricks done, or were these generic numbers?
Sriram: Where hardware optimization exists, it was reflected. See the table (slide 7) with signing/verification numbers for Intel and Cavium
processors.
Brian: For s/w based, were "software based tricks" reflected?
Sriram: perhaps some. Not many. The code descriptions are available on the eBACS web site (cited on slide 7).
(From Jabber room: Dave Freedman
1:44
so I'm looking forward to retro-fitting my routers with graphics cards..)
13:47
Brian Dickson communicating via skype from joelja's laptop on the desk.
14:01
Now on All->Customer - Good slide
14:02
Transit -> Transit/Peer - Leak slide
14:03
Peer -> Transit/Peer - Leak slide
Diagrams - Now with Mutual Transit slide
14:04
Our Customer -> All - Good
14:05
All (via MT) -> Customer - Good
Peer -> Any Transit/Peer - Leak
14:06
skipped ahead to Color Markings and Transitions at Sandy's request
14:09
The BIG PICTURE slide
14:11
Route Leak Blocking Logic
14:13
Q&A
Q&A on Brian’s presentation:
Chris Morrow: Quick discussion on SIDR and IDR lists would be good.
Wes George: I have serious misgivings about that discussion. We need better
solution/approach rather than say everybody do everything and hope it works
– that might drag on for 1.5 years – we should avoid that.
John Scudder: Solutions cannot be pursued until we know what we need to
accomplish.
Steve Bellovin: This (method of detecting/stopping route leaks) is a change
to BGP. The work belongs in IDR.
Doug Montgomery: The idea of encoding peering relationships in BGP updates
goes back to the late 80’s; it was even in early versions of the BGP spec,
see RFC 1105. Three types of exceptions always cause such proposals to
rat hole: (1) Exceptions to the labeling for specific prefixes (so don't
label the session, label each update); (2) Exceptions to the willingness
to label (so include an "undisclosed" option); (3) Exceptions to policies
on how to react to the labels in the path (so don't write normative MUST
text on receiver side processing. Just label the shape of the path and let
local policy decide which shapes are to be preferred/ignored/etc.
Ruediger Volk: If route leak occurs essentially due to some
misconfiguration on the sender side, proposal (solution) should not depend
on that party doing the right thing (i.e., configuring correctly).
14:18
Ruediger Volk: If route leaks occur, it's due to a misconfiguration on a sender. In doing such proposals you'd better be sure the proposal doesn't depend on the misconfigured party, being configured correctly!
14:18
Randy Bush:
14:19
Randy Bush presenting pfx-validate
14:25
Should updates learned via iBGP be marked?
He said there was disagreement between him and another author about
validating or not validating prefixes received in iBGP.
Q&A on Randy’s presentation:
Wes George: You have explained your thinking. Can you also explain why the
other author thinks differently than you?
John Scudder: In iBGP if there is a lack of synchronization, then you are
screwed.
Randy Bush: Is there a large operator that doesn’t apply policy to iBGP?
Ruediger Volk: Two diff problems – what is done on ingress processing vs.
what are we checking against RPKI? We want to have some way of checking
at the ingress point; I don’t think there is much harm if we move the policy
(to iBGP).
Goff Huston: eBGP does loop protection; iBGP does not. That is why iBGP
floods so loop detection can happen in eBGP. If I am filtering in iBGP,
I am creating different views. Then I have no guarantee that I am avoiding
loops.
Steve Bellovin: Question is do you do consistent provisioning on your iBGP
speakers? Weather it is harmful or not depends on how you configure
internally.
Joel Jaeggli: I am a good person to respond to that; I have policy on RR
(note taker: could not understand the rest).
Keyur Patel: Edge routers do not reflect – there is no loop detection
problem. It would be hard to form a loop if you are evaluating this (prefix
validation) at any point in the AS (other than in the RR and only in the
RR).
Geoff Huston: OK, it wasn’t clear Randy was talking about edge routers.
Igor: If you know you may form a loop there is always a way to stop the
loops from forming.
14:38
Igor: One way to avoid loops is MPLS.
14:38
Rob Austein presenting A Few Months In The Life Of An RPKI Validator
14:42
Clarifying question on connection counts slide:
Shane: Session goes down, when is retry?
Rob: One hour later.
14:46
Wes George: Can you correlate duration with number of objects transferred?
Rob: Nope. Maybe quality of connectivity? We don't know.
14:50
Eric Osterweil: Are you considering scale tests in the future?
Rob: Yes. Basic idea is "take a BGP feed, pretend everything will be valid, create X.509 stuff for that, and use that for test runs."
14:51
Jeff Haas: Re duration for session connections, are you looking for TCP funnies like a missing Fin-Ack?
Rob: Our instrumentation doesn't give us that.
Jeff: You can get it out of netstat.
Rob: All we're measuring is how long it took to run rsync.
Martin Levy: (something about v6)
Martin Levy: This is for the birds. We have 5 repos in extremely diverse locations, and yet we're doing single-location pulling of data. Can you talk about why we can't distribute the data more usefully.
Rob: We have a whole nother presentation on this, but the basic problem is this is not fully funded yet.
Martin: I'm a big fan but this is clearly not ready for prime time yet.
14:54
Still Rob, Now "RPKI Over BitTorrent".
15:01
Rob's masterful summation cut off for lack of time. (Apologies from the chairs.)
Chris talking about interim meetings, virtual meetings.
= = = = = = = = = = = = = = = = = = = = = = = = =
Wed 28 Mar 2012 SIDR meeting IETF 83
Jabber log for Wed 28 Mar 2012: http://www.ietf.org/jabber/logs/sidr/2012-03-28.html
Wednesday meeting
-----------------
09:06 meeting begins
chairs presenting slides
9:09
brian haberman: rpsl-sig will be submitted imminently, no outstanding comments.
9:10
applause and macaroons for authors of published RFCs
9:11
BGPSec Protocol
Matt Lepinski presenting
9:13
Vehement call for comments from implementors. Want to set attribute format in stone, so speak now or forever hold your peace.
9:15 or so
Rob A: "Unicast, right?" (XXX I missed the context of this)
9:23
-03 version will mandate that there be NO AS4_PATH if the signature attribute is included (to remove/reduce redundancy and concomitant error cases).
9:26
expire time removed, 8 bytes "signed stuff" added for future use (could be expire time). MBZ on Tx, validate-but-ignore on Rx.
9:28
Jeff Haas: I suggest we make the reserved stuff a TLV instead of a fixed 8 bytes.
Matt: so then it's length zero for -03?
Jeff: You could do it with no sub-TLVs, or specify a format for sub-TLVs and a registry.
Matt: please send recc to list.
9:30
Sriram: How do we tell receiver to look for two signature blocks?
Matt: Inferred from overall attribute length field. Maybe we should signal it explicitly? Maybe by always including the second signature block but make it zero-length? Guess we'll do that.
9:33
Use of flag bits could indicate what other attributes get covered by the signature. Important point is bits might be useful later... (Apropos comment from Jeff Haas on secured meetings, evidently repeated from earlier meeting.)
9:37
SKI collisions -- if an attacker has your private keys, SKI collisions are the least of your worries!
9:38
Interested in making SKIs fixed-length for convenience of implementors. Comments?
Sean Turner (sec AD): (comments about PKIX and algorithm agility went by too fast for the minute-taker, but) upshot is: Go ahead and use a fixed-length SKI, I'm not worried about it.
9:40
Paul Hoffman: Everyone has to be using the same algorithm? Does the relying party have to know the algo?
Matt: The RPKI specs mandate SHA1. However, it's not a security property that the relying party be able to calculate the SKI.
Paul: So it's really just an arbitrary 20 bytes.
Matt: Yes, you'd be non-compliant...
Paul: ... but interoperably non-compliant so who cares!
Matt: Yes. Aaaaaand we've just gotten rid of a length field!
9:44
Replay Protection
Doug M: Just to be clear, the original discussion was generalized to the freshness problem, not just replay.
Matt: I'm not done talking! The attack I described (in slide and at mic) is one instance of that attack. This is a general problem with BGP (minute taker note: I disagree, sort of).
9:47
S. Zhou: You could use a generation number instead of an expire time/beacon.
Matt: Yes, that came up at the interim.
9:48
Concerns about beaconing were that it was abusive of the routing system and to go back to discussion. (See slide 14 or so for summary of beaconing costs.)
We need more discussion! On list, at meetings.
Now there's a "reserved" field approximately the same size as the former expire time.
9:50
Sriram: If you make the beacon interval very large, then cost is reasonably well bounded.
Matt: Yes, and the problem is that there are incentives (see slide) to abuse the system.
9:51
Randy Bush: Expiry is good at preventing short-term replays. The pain is everywhere, the gain is to one party. An alternate mechanism is simply re-key your router if there is a breach (including a change in business relationship).
9:53
Matt: Yes, goes to next slide that covers that exact idea, hereafter to be known as "rekey your fracking router", or RkYFR.
(XXX missed some useful discussion of beaconing, sorry)
9:56
Randy: Operationally the way to do this is when you bring up a new router, you create two keys: your current key and your future key. When you want to invalidate your current key, start using N+1 key and then update RPKI.
Andrew Chi: (XXX missed comment and reply)
9:57
Doug: I could roll my key every five minutes, so the abuse has been moved to the RPKI from BGP but not solved.
vasily dolmatov: "When you revoke cert it becomes invalid? No! It only becomes invalid after it's revoked and the revocation is distributed throughout the network!"
Matt: Yes.
9:59
Vasily: I want to stress this makes the RPKI distribution mechanism a first-class part of revocation/replay prevention.
Matt: This is a good point, please bring it up on the mailing list.
10:01
Rob A: The nice thing about doing it in RPKI instead of BGP is that the 'victims' can control the rate at which they poll for updates.
Jeff Haas: Could put into BGP a hint to systems that the RPKI has changed so go poll now.
Matt: It got tail-dropped from San Diego meeting. Need to revive the idea and think about it some more. Seems feasible.
(discussion of mechanism)
Jeff: I had been thinking of a new AFI/SAFI, but maybe something similar to DNS SoA instead? (More detail, will send to list.)
10:04
Steve Kent: I want to reply to Vasily. Yes, it's true as long as it goes, but it behooves relying parties to stay up to date since if they don't, they will be relying on potentially bad information. This is the fundamental limitation of a distributed system.
10:05
Paul Hoffman: ATOM protocol would be perfect for this. Scales well. You can put your CRLs there, etc. Bittorrent is a horrible way to do this, but ATOM/RSS is great.
10:07
Randy Bush: Rathole! I don't care what the transport is. As Steve notes, as long as relying parties are doing their jobs, the rest is details.
10:08
Sandy: Validity periods of keys (in cert) could be used to order them.
10:08
Back to slides
For example, set expire-time units in days, half-weeks, fortnights. If we do this, discussion of units is crucial.
10:10
John Scudder: Insofar as there are also other mechanisms (invalidation in RPKI) this is belt-and-suspenders and getting the exact right unit is less crucial.
Sriram: In SD I presented some analysis. A few hours of units seems to produce a good beaconing load compared to current BGP flux.
Steve B: The problem with this granularity idea is that if it's long enough that it doesn't impose significant load, it's no good against automated-scale attacks. There may not be a happy medium.
Matthias (mekking?), NLNet: You could have minimum validity period, inception time like DNSSec, etc.
10:12
Doug M: Agree with John. Combining two or more mechanisms may provide a happy medium.
10:13
Randy Bush: We have demonstrated that we need some replay protection. (I take this to be a joke, about the fact we have had this conversation before.)
10:14
Randy Bush presenting origin-ops.
10:15
One issue raised by John Scudder. Doc currently says you can accept invalids and downpref them. There is a problem with that: Suppose Mary has ROA for 10/8 for her AS and there's another for 10.1/16. An announcement comes in, in the latter space, that is an invalid announcement (say, wrong AS). Classic hole-punch attack. If you downpref it, it will still be selected since there is no covering route. The hijack will succeed. The doc will need to be patched to point that out and maybe state even more strongly that invalid should be dropped.
10:17
Ruediger: you have to deal with that in a different way. Recent work led me to the idea that any advice we are giving out that hints that invalid may not be taken seriously is a REALLY BAD IDEA. Tell people that if you do put information into the RPKI that makes things invalid, you should expect it to be acted on, so make sure you get it right!
10:18
Doug M: I know one implementation chose never to install an invalid beneath a valid aggregate. Does that heuristic capture the attack?
Sandy: So the implementation mandates that policy?
Doug: Yes.
10:19
Sandy: Mnadated policy vs. complete local control.
Jakob H: Invalid is bad whether hole-punch or not. Invalid's gotta go!
Randy: Agree.
10:20
Wes G.: Definitely worth documenting Doug M's implementation, so it could be turned into a policy feature.
10:22:
Jeff H: Possible to put invalid and valid into different FIBs. Could make choice at forwarding time instead of policy, might work with present routers. Not sure if it's a good idea.
10:23
Ruediger: the argument about protecting people who might have put bad info into the RPKI is an argument for getting it right to begin with, including simulation tools so that when the RPKI is used in anger it can be used carefully and correctly.
10:24
Randy presenting on bgpsec-req
Shane asked to add AS migration scenario. My comment is to ask, why is this different from two routers in two different ASes? Express signature internally by pretending to be two routers.
10:25
Shane: it's not a temporary period of time, this lives in the net for periods of years, since downstream customers are not very ... quick ... to change their AS. So the solution has to cover it as a semi-permanent state. Second, given there's a different between AS4_PATH and bgpsec signature, there needs to be understanding of what happens when the two are not aligned.
John Scudder: Could use pcount=0 to solve this.
Shane: So we're going to abuse pcount?
John: Yes.
10:29
Jeff H: There are some other operational practices that we'll need to think about. Prepending is one. Also, to Shane's example, as part of migration people use local-as, in some implementations once you have more than one local-as, these get inserted as an AS_SET. Need to look for and deal with that!
10:30
Steve B: If you're doing this you have multiple signatures. Might encourage people to migrate away?
10:31
Doug M: In current spec, forward AS is under the sig, can't I sign toward one of your IDs. Doesn't that cover the transition problem?
(muttering)
subsequently on Jabber:
dougm
10:33
Never mind .... my sign toward A, check A and A' doesn't work two hops away ... AS transition is still a problem.
(so this is a retraction of the above)
Randy speaking on bgpsec-req
Randy: Re expiry issue, bgpsec-req has NOT changed 4.3 on replay defense since 00.
If you have any comments on sec-req, tell me again. I have no pending updates.
10:32 Steve Kent speaking on threat model, see slides
10:36
Shane A: Current doc focuses on threats to bgpsec and rpki but not threats to the control plane itself. No ref to your preso from Prague, e.g. shortening, lengthening, P-K attack, not even a ref to the preso or better a discussion of such attacks. Would be valuable to provide testable criteria.
10:38
Steve: If there's no ref to that class of attacks I'll go fix it. Note this is a threat doc, not an attack doc, so we don't try to list examples exhaustively. But it would be fine to list some more examples. Threats are different since to be a threat you must be both *motivated* and *capable*. Anyone who is one but not the other, is not a threat.
10:40
Shane: In particularly please cover path shortening and path lengthening. In any case, please cover these examples.
Steve: We'll have further discussion of this, especially lengthening.
10:41
Randy: I need examples!
10:41 Andrew Chi presenting "RPKI Gray Area: Inheritance?" (See slides)
10:45
Steve Kent: You're right CACert2 can be created by anyone, but the question is what's above it, it still has to be anchored somewhere.
Rob A: There are some complex cases, for example in make-before-break
. Basic observation is that explicitness makes analysis easier.
Steve: Inherit is only for space saving, so we don't HAVE TO use it anywhere. If the WG wants to get rid of it, no problem, just add an errata.
10:47
Andy Newton: Wow, we could use this for transfers. We do use nherit, it's not like this, it's for fanout. We don't do join, just fork.
10:48
Randy presenting on rekey (no slides)
There are two ways of doing it, both violate existing practice. Issue is router has private key on it. If we wish to allow the operator to quickly replace the routing engine or whatever holds the private key that signs the bgp updates, then they have to be able to move the exising key from one to the other. So,
So there are two ways to think about it. Generate the key in the NOC (private/public pair, can be wrapped up nicely to router). Other way is router can generate pair for itself wrap it up in pkcs7, send public key only to NOC, NOC puts it in cert etc etc and publishes it in RPKI. Private key CAN come out too. But problem is routers today don't let keys out (e.g. ssh key).
10:51
Ruediger: this is a *feature*.
10:51
Yes, we have to decide if we are going to step out of that boundary. Swapping in spares entails rpki propagation time, is the issue. "Wes, will you be happy letting your secret key off the router?"
10:53
Wes G: This goes back to what I've been saying repeatedly through evolution of this suite. There are many of us ops who are n00bs when it comes to managing this stuff. The more we can say about how to do it without screwing up , the better.
Terry M: I still have to think about this, but hasn't it been solved elsewhere? For example in DNS world? Key signing keys, zone signing keys? Analogous to NOC key that does work and you instantiate it on the router?
10:54
Randy: I agree completely, you need to think about it.
Paul H: Most people in *security* don't understand key wrapping well! But to Terry, this has nothing to do with KSKs and ZSKs.
10:56
Steve: Please don't use "wrapping". It's "rollover". Also there is work in PKIX on lightweight provisioning, we have asked for support for (XXX lost detail, "this".)
(off-mic banter, Russ Housely)
10:57
Brian W presenting, see slides
10:58
Steve B: Last bullet of (2), do you mean a replay PREVENTION mechanism?
Brian: Uh yeah.
11:05
Steve K: I'm concerned about using this as a replay mechanism approach, but we'll take that to the list. But on Monday we discussed that if we use the separate transit vs origination model, that doubles the number of keys everyone always has to have. If we're worried about the ability to have public keys be rapidly accessible, doubling them is not so great. Throw in another factor of two for transition windows.
11:07
Brian: good point.
Sandy: In the twilight-to-crl publication period where bgp update is propagating, we discussed that beacons need to have special processing so that even though they don't change bestpath they're propagated.
Several people (Jeff, John, Doug): No special processing needed.
Sandy: then why do we need withdraw?
Doug: new update is implicit withdraw
Sriram: When key rolls over, say it's the transit key, if the router has let's say 10 peers to whom it gives full tables, it'd have to send 10x the full table to those 10 peers, that's a whole bunch of work all at once to re-sign those updates. have you thought about hte possibility of jittering the workload in time?
11:09
Brian: As long as it's not an emergency, smearing the re-originations seems like a good idea.
Sriram: same principle as beaconing.
Brian: good idea.
11:10
Request adoption.
Sandy: can you say something about your discussion of keyroll and randy's rekey doc?
Randy: My mistake to call my doc rekey. Sorry. It's just key provisioning.
11:11 Dan Massey + Joe Gersch presenting ROVER gersch-grow-revdns-cidr and grow-revdns-bgp (see slides)
11:13
can deploy in short time frame. (i.e., before I'm done with this talk you could have your reverse dns records installed)
From Jabber:
weiler
11:14
bzzzzzt. incorrect in many cases.
this was while slide 3 was being presented. fwiw.
From Jabber:
Wes George
state for the record, PLEASE use slide numbers on your presos!! Chairs, please enforce this
11:19
weiler
+1
11:20
John Scudder
11:20
++
10:23
speaker now Joe talking about prototype
10:25
Shopping for WG.
10:26
Russ M: I'm a dnssec fan, but I think this is a really bad idea from an architecgtural perspective. In securing dns with dnssec one of the architectural concepts was that if something deoesn't have to use dnssec, if you force use of dnssec, you are inserting an unnecessary circular dependence. to reiterate, this is an architecturally bad idea.
10:27
Steve K: Several parts of your sales pitch puzzle me. RPKI is opt-in too, so opt-in compared to what?
Dan: agreed, equivalent.
Steve: You say "can do this today". Don't I have to have permission from the guy above me to do this signing? I.e. is in-addr already signed and does that all just work now?
Dan: disagree
(conversation lost, not at mic, devolved into free-for-all)
11:30
(author): yes it requires new DNS records but (lost)
Rob A: As randy was saying, there are new RR types. There are places where new RR type is a PITA. There are many orgs where people who op DNS and operate routers are mutually hostile. Third, fundamentally diff operational model. RPKI set up for complete local copy of db, but in dns that's not possible since zone xfr prohibited commonly.
(author): I disagree with enumeration.
11:31
Sam W: Object to 'can put in dns right now'. I agree I could do that if I had a byte boundary. How about bit boundary? I've read the draft, don't believe it works.
11:32
arturo, lacnic. Marketing slides are BS. Not easy to deploy. Small ISPs in Latin America have a hard time with DNS/reverse DNS. Guess how many will sign their zones. They have a nice i/f for RPKI, but not so int he case of DNSSec.
Shane A: As an operator I love this. I don't know if it's sidr or grow. I think it deserves more discussion. To respond to comments about operation of dns, delegation to subzone allows delegation to router guys to allow busting silos. Also as I understand curr proposal it's not meant to allow for enumeration in dns. "I've seen prefix, let me look it up in DNS"?
randy: dynamically? real time?
shane: that's one mechanism. my point is I don't think enumeration is what they're proposing. notice several different ways to consume data, including building prefix filters offline or rpki-rtr. don't get carried away.
sandy: presenters said "alternative". (disagreement ensues)
11:35
eric o: if you guys want to know about penetration of in-addr dnssec you can look it up . it's pretty good. also RIRs don't need to pick it up first for byte-boundary delegation.
shane: I just did this for 204.199/16. it is now signed in in-addr.
11:36
ruediger: I see the claim you can build prefix filters. I'm also hearing you're not going to walk the tree. HOW then?
(presenter): I'll defer to shane.
11:37
shane: enumaration, but with IRR too, (minute taker confused)
ruediger: you're saying this is complementary, preso clear that many systems can be used in parallel. any proposals how to deal with inconsistencies and contraditioncions between systems?
(presenter): that's a FEATURE
11:39
ruediger: oh GREAT. (missed)
sam w: so you're selling us more complexity? I don't get the 'complementary' point. can you elaborate?
(prsenter): (words, didn't make sense to minute taker)
sam w: if half folks choose rover, half choose rpki, that sounds like balkanization, not complementarity
11:40
(presenter): we in this group aren't going to dictate
chris m, chair: take it to the list!
eric o: (talked way too fast, no idea what he said, listen to the audio)