Re: [sidr] Validation Reconsidered (again/again) question
Christopher Morrow <morrowc.li...@gmail.com> writes: > Pinging this thread to catch anyone who didn't reply but had thoughts > I'd like to close this out tomorrow before 5pm EST (10pm UTC). I've been considering the concept behind this document and whether the concept should be carried forward by the working group. To me the starting ID is frequently badly written or has too few editors, etc. That always changes over time, so I'm not concerned about that issue in particular until it is proven that no one will take it up (and many won't volunteer for a question mark). So, on to the concept: in my younger years I was very strict and I would have been against this concept from the beginning, because it does bring the status of a given certificate into question. But my older and wiser self has seen far too many difficult and failed protocol deployments because of the complexity associated with "everyone everywhere needs to do the right thing all the time". To me, the validation reconsidered proposal mitigates some of the very likely real-world, real-human deployment scenarios. And I don't think that the RPKI publicity side can take too many negative hits (again, because I've watched too many other protocols slow down at the minimum when negative publicity hits them). In short, the validation reconsidered concept reduces the real-world impact of necessary and accidental changes, which to me means a deployment base that will be stronger even though we're "allowing more". Does that do strange things to the status of a given certificate? Yes, it definitely does. I know this will ruffle some feathers: but I believe the goal of the RPKI was to make a decision, based on available data, about the ability to trust that origin's announcement. Everything else has come after, or more likely as a result of implementing, that goal. The RPKI makes use of PKIX and certificates to achieve that goal, and along the way became a fundamental staple that we're hesitant to change. In the end, however, when I look at the primary original goal, along with the need for a robust deployment, the validation reconsidered proposal seems well worth the trade offs. -- Wes Hardaker Parsons ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrI-D Action: draft-ietf-sidr-rpki-grandparenting-00.txt
internet-dra...@ietf.org writes: There are circumstances in RPKI operations where a resource holder's parent may not be able to, or may not choose to, facilitate full and proper registration of the holder's data. As in real life, the holder may form a relationship with their grandparent who is willing to aid the grandchild. This document describes simple procedures for doing so. It's probably worth documenting that the other option for A in the draft is to split C's space into two sub-delegations, with C's consent, and give G a new delegation for it's space directly under A so there is no conflict of G's address space being controlled by both C and G where their relationship has clearly dissolved. Yes, that really was one sentence. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
heasley h...@shrubbery.net writes: This sure smells to me like a solution in need of multicast (or, more accurately, deployed multicast) with a fall back to something like bittorrent for bootstrapping or when you've missed session data and can't recover. Multicast as a data stream would be much more efficient is collecting updates, although there are still issues that would need to be worked through like how do you know you heard everything. Oh, and it only works if you multicast deployed to your site of course. please, we do not want multicast as the only solution. does your noc know how to debug multicast forwarding problems? I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
heasley h...@shrubbery.net writes: Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. understood; i'm registering/re-enforcing that if that is developed it must not be the only mathod. Agreed. If we can't do it over carrier pigeon, we have no real backup. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrKeys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys)
. And possibly, assuming you keep a running memory cache to avoid replay, that it hasn't been seen yet so you should trust it. But, it may have been monitored/stolen from a different path instead, etc. EG, consider two trust caches that neither of which has seen AS R yet. They could both vouch for completely different paths advertised. 5) And in fact, there is no assurance that the random number generated matches anything. Thus any of the following paths would be treated the same: |--| |--| |--| |--| |--| | AS A | | AS A | | AS C | | AS A | | AS B | | R| | R| | N| | R| | Q| |--| |--| |--| |--| |--| | AS B | | AS C | | AS A | | Q| | Q| | R| |--| |--| |--| | ... | | ... | | ... | IE, any update with AS A/num=R in it will verify, but it won't matter if the order is added-to, reversed, deleted, dropped, etc. In the end, it doesn't really provide any of the protection services that the original cryptographically-chained algorithm provides: proof that the path wasn't modified. So, as I said, I'm all for a system that is equally secure, or provides the minimal security properties that we need at a much faster speed. But I fail to see how your system provides any security. At least as you've defined it to date. And even a 50,000x potential improvement you claimed doesn't seem to make me happier if we're getting nothing out of it. Even if we had a more secure random number generator in use (which would be likely slower than the existing one you were testing but still faster than a ECDSA signing system), I fail to see how the designed system with any random number generator will help out because we're loosing all the path binding properties that BGPSEC is trying to secure in the first place. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrSlides for RPKI Over BitTorrent presentation
Rob Austein s...@hactrn.net writes: For those who didn't get to see the end of the RPKI Over BitTorrent presentation in today's SIDR meeting, the full slide deck is available at http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf and should be relatively self-explanatory. I've been thinking about this a lot lately, as it'll certainly be a challenge to ensure everyone is up to date. It doesn't matter whether you should have pulled or whether you pull right when you get a request. Either way, there is an underlying data distribution problem. Most importantly, every bit of the repository needs to pretty much get everywhere. Rdist works well for trying not to duplicate data. Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that indicate you need to refetch and entire .zip file even if you already have most of it anyway. But the real underlying problem is what I said above: every bit needs to get efficiently to every place, ideally at time of initial publication. This sure smells to me like a solution in need of multicast (or, more accurately, deployed multicast) with a fall back to something like bittorrent for bootstrapping or when you've missed session data and can't recover. Multicast as a data stream would be much more efficient is collecting updates, although there are still issues that would need to be worked through like how do you know you heard everything. Oh, and it only works if you multicast deployed to your site of course. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] rpki-rtr-25 notes
On Sat, 04 Feb 2012 15:43:04 -0800, Randy Bush ra...@psg.com said: A) It's too early for nit edits RB not really. as the iesg has approved this one, changes are going to be RB a process pain. so this message pushes back on some of your suggestions RB which i would otherwise have gladly taken. As I said in a private message to you the other day: I think I probably hold the record for people that responded with comments about a draft after the very last cut-off date. I'm exceptionally good at being a day or two late about reviewing drafts. RB if so, probably should be CacheKey. but whose key it is seems very RB clear from the next few words, yes? I think CacheKey is perfect, except that then I'd want to change MyKey to RouterKey. I) section 8: it would be prudent for the client... This seems like a good place for the word SHOULD to sneak in there somewhere. RB eenie meenie. did not see a need to be that strongly prescriptive. J) section 8: if data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation. This one confuses me. It's unclear, after reading the entire document, why you have a preference ordered list if the data from them all must be treated equally. RB proximity and security The above two issues just made me wonder about the interchangeability of the configuration model. Since the text shys away from describing what actually happens when you have multiple caches available, we'll end up with a case where a configuration set on one machine may not act the same way on another. Though there is no standard configuration model at the moment, so maybe it's all moot until someone creates a YANG follow-up. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] rpki-rtr-25 notes
[PPS: I don't expect a response to my just-posted-note since it's really beyond the point of worth in keeping the discussion going] -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] sidrRFC 6480 on An Infrastructure to Support Secure Internet Routing
On Fri, 3 Feb 2012 17:16:03 -0800 (PST), rfc-edi...@rfc-editor.org said: r A [^h MANY] new Request for Comments is now available in online RFC libraries. r RFC 6480 r RFC 6481 r RFC 6482 r RFC 6483 r RFC 6484 (BCP173) r RFC 6485 r RFC 6486 r RFC 6487 r RFC 6488 r RFC 6488 (BCP174) r RFC6490 r RFC6491 r RFC6492 r RFC6493 That's certainly a nice long accomplishment list! Congratulations to all that have put in the time and effort to make that list happen! -- Wes Hardaker My Pictures: http://capturedonearth.com/ My Thoughts: http://pontifications.hardakers.net/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Last Call: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On Thu, 15 Dec 2011 15:56:44 -0800, Randy Bush ra...@psg.com said: RB As you say, NetConf is for *configuring* routers. RPKI-rtr is not used RB for router configuration, but rather dynamic data, a la IS-IS or BGP. RB In fact, the RPKI-rtr payload data go into the same data structure as RB the BGP data. Having finally read through the rtr-25 document, and having some background in following the Netconf work, I finally am in a position to give my opinion on this thread. The thread is a bit old, but consensus never seemed to be full there so I figure one more opinion might be helpful. The short summary: Randy is right (this time; don't let it go to your head Randy :-) ) The longer explanation: Could netconf be used to send this type of data over? Yes. But... Routers, operating in the defacto state of doing what they're supposed to be doing (routing), need to be fast and efficient. And that's an understatement. The rpki-rtr protocol is clearly designed to make sure this is the case. It's a cache-query protocol designed to keep a fairly large, complex and constantly changing data set in sync with the router that actually needs to use it. It's binary in nature (ironically written by some people that used to stamp on the ground about how annoying binary protocols are) because it needs to be in order to be efficient and fast. Especially when the data is large and changing at a rapid rate. Now, lets compare those needs against netconf. Netconf was designed to be a protocol that operated on a data storage full of configuration data. The configuration data is likely to be static, except when rarely manipulated through CLI, netconf or some other actions. But those modifications will be rare, not frequent. The language is verbose (lots of commands/pdus/operations), large (XML encoded) and complex to parse (XML is easy-ish for humans and easy-ish for machines, but not fast for either). And it's designed not for operational data, but for configuration data, which is an entirely separate beast. Could it be used? Yes, but with the drawbacks hinted at above: a reduction in speed and an increase in stealing the memory CPU cycles from what the router really should be doing (routing). Certainly the data isn't the same vein as the normal netconf data, so it would likely need a separate storage container running on a separate port even if the same protocol was used. So if it could be used, should it be used? No it's just not a good fit. I can shoe-horn the rpki-rtr protocol into a number of other shoes, but none of them are right either. Consider tftp, snmp, http, or even bgp itself. They all could be used in theory, but none of them really meet the operational needs either (so don't get any ideas!). Could they be used? Yes. Should they be? No. [and I'd argue that at least one of them might be a better choice than netconf itself]. -- Wes Hardaker SPARTA, Inc. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
[sidr] rpki-rtr-25 notes
. K) I didn't dive heavily into the security considerations because of some of the above that I suspect may affect it. I'd be happy to if it's ready to be dived into though. Again, nicely done document. Clear and straight forward (though at times I had to predict what was coming ahead to make sense of the current paragraph, I think that's generally hard to avoid). -- Wes Hardaker ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
