[sidr] rpki-rtr-25 notes
Wes Hardaker <wjhns1@hardakers.net> Sat, 04 February 2012 17:48 UTC
Return-Path: <wjhns1@hardakers.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9821F8523 for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 09:48:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiHkLARfXJiC for <sidr@ietfa.amsl.com>; Sat, 4 Feb 2012 09:48:35 -0800 (PST)
Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A22F421F84FF for <sidr@ietf.org>; Sat, 4 Feb 2012 09:48:35 -0800 (PST)
Received: from localhost (unknown [IPv6:2001:470:1f00:187:224:7eff:fe6b:2b3e]) by mail.hardakers.net (Postfix) with ESMTPSA id 18DA657C for <sidr@ietf.org>; Sat, 4 Feb 2012 09:48:35 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: sidr@ietf.org
Date: Sat, 04 Feb 2012 09:48:34 -0800
Message-ID: <0lvcnmij65.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: [sidr] rpki-rtr-25 notes
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Feb 2012 17:48:36 -0000
Just finished (finally) scanning the rpki-rtr document (-25 version) and have a few notes about it. Over all, though, nicely done ID. Thanks! A) It's too early for nit edits, but this one just jumped at me and I couldn't ignore it. 5.1, 3rd paragraph(/sentence): is only -> is *the* only B) 5.9: the 2nd and 4th paragraphs seem to contradict each other. I suspect that the intent is that you can send a generic error after a particular PDU, but the way it's phrased is a bit odd and it jumped out at me too. How about: If the error is generic (e.g. "Internal Error") and not associated with the PDU it is responding to, the Erroneous PDU field ... Note that with this exception rule you could still end up in some state where the generic error isn't fatal and you need to respond with a specific and a generic error, but you can't send 2 error reports. Thus, hopefully generic errors will always be fatal? C) 5.10 seems to indicate rcynic (a very fine tool) is ubiquitous because it's quoting it like everyone knows what it is (and always will). I'd leave the example tool name out. D) 7. Transport.... Multiple issues D.1) "Unfortunately there is no protocol to do so on all currently used platforms". I actually doubt the validity of that statement. I suspect SSH is likely available on them all. Or at least "nearly all" (and I doubt anything will ever reach "all"). I'd bet TLS is nearly ubiquitous as well, though probably less than SSH. D.2) The ordering of the 5th-8th(ish) paragraphs seems weird. I'd group them together by subject such that the sections that talked about unprotected TCP should be next to each other and the ones that talked about the protected ones be together. Thus, I think just moving the 2 unprotected paragraphs ("Caches and routers MUST..." and "If unprotected TCP...") to positions 5 and 6 would solve most of the oddities. D.3) I'm not sure that the whole concept of "MUST implement unprotected" is going to fly through a security review. I know I'd flag it. Generally I'm not sure it's wise to mandate insecurity, though I do agree it may be a nice feature to have (did I really just say that???) D.4) There is some confusion regarding whether routers "use" vs "can be configured to use". EG: "Caches and routers SHOULD use TCP-AO..." IMHO, this indicates they have a choice. "SHOULD be able to use" might be a better wording choice implying its subject to configuration by the operator. If you want a more complete list of places where I think this might be a problem, I can supply one of course. D.5) "If available to the operator...". How would the router know what's available to the operator? Or does this mean that if the device already implements protocol X, it must offer it as a configuration choice for rpki-rtr transport? If so, that's not entirely clear. D.6) I'd order the sub-sections to be in the same order as the list above it. IE, TCP-AO is first in the list, so the TCP-AO sub-section should probably come first. E) 7.1 SSH transport "Client routers SHOULD verify the public key of the cache". Similar to D.4, I'd change this to "Client routers MUST be able to verify the public key of the cache". F) 7.2 TLS transports: the CN field is really being deprecated and I'd suggest using the subject alt name instead (SAN). G) section 8, paragraph 2 implies that the cache needs a list of names for the peer and I'm not sure this is true. In fact much of that paragraph talks about the router/client side only, so I'd split the paragraph in two: one for cache requirements and one for the router requirements. H) section 8: I'd change "Key" to either "TheirKey" or "ItsKey" 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. 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. Is the goal to have a preference order list because you want to really only have, ideally, a single cache and the others are fallbacks? Or is it because you want to have N/M established at any point? Either way, if they're all equal then what happens when popular #1 is overloaded and slower and issues an announcement after #2 has issued a withdrawl, or vice versa. Either way you end up in a race-condition based state. This should probably be discussed and at least mentioned, even if you choose not to solve it by a preference setting somewhere. Though I'd certainly want to leave room in the configuration engine to allow for a preference setting even if implementing it is optional. 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] rpki-rtr-25 notes Wes Hardaker
- Re: [sidr] rpki-rtr-25 notes Randy Bush
- Re: [sidr] rpki-rtr-25 notes Wes Hardaker
- Re: [sidr] rpki-rtr-25 notes Wes Hardaker
- Re: [sidr] rpki-rtr-25 notes Stewart Bryant