Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other comments that you receive, and strive to resolve them through discussion or by updating the draft as appropriate. Document: http://tools.ietf.org/html/draft-ietf-karp-crypto-key-table-07 Reviewer: Danny McPherson Review Date: 08 MAY 2013 Intended Status: Standards Track There is at least one major issue with this document, as it is now written. Comments/Questions: =================== 1) This document specifically restricts itself to only ever talking about symmetric keys, and therefore it is not going to work for public key crypto approaches like RPKI/BGPSEC. If the objective is "Keying and Authentication for routing protocols (not just *routed* protocols) then not accommodating BGP would seem to miss the mark. An array of mechanisms to get keys into routers and store them for a lot of different purposes is precisely one of the reasons why folks don't update keys or perform more authentication functions today. 2) As a Standards Track document it feels entirely too generic. It should employ some specific example usages to illustrate its efficacy and refine its inadequacies, the current "boil the ocean" leaves me wonder what's actually to be implemented from this ID. 3) There is a clear need to discuss proper time synchronization that is conspicuously missing, and this seems the type of place to tackle it rather than avoiding the topic.. 4) There is _no_ error handling recommendations, and plenty of failure modes. 5) There are lots of instances where you might have multiple sessions (link local, IGP, or EGP) between a single peer (e.g., BGP multisession or diverse path) that MAY employ different credentials, this model doesn't seem to accommodate this at all. 6) What about use for authentication data of other sorts? E.g., NTP or SNMP, or L2TPv3, or other types of PWs, etc..? If we're going to define a generic model shouldn't it accommodate those? 7) S.2 text suggests multiple times that "many routing protocols restrict their key names to integers that can be represented in 16 or 32 bits." Is this really the case? Are there ANY that restrict their key *names* to 32 bits today? This really doesn't afford much in the way of operator usability and mnemonic values, etc.. Specific comments: 1) Section 2 starts off by talking about if/when long-lived keys will be reused... It says ``hopefully'' they won't be... Is there a recommendaiton to reference (or provide) here or just well placed aspirations? :-) 2) Section 2 talks about ``ProtocolSpecificInfo'' but stays super vague... not even an example. I would suggest something be provided to demonstrate how this field would be used (or motivate its existence). We don't want it to wind up being used to store plain-text passphrases! 3) Section 2 opens Pandora's box with the SendLifetime[Start|End]/AcceptedLifetime[Start|End]. The inevitability of peers losing time sync w/o a systemic solution (e.g., NTP/TICTOC/Other) is glossed over. Routers would, without persistent sync, eventually stop being able to talk to each other. At no point in the draft is there any discussion of how protocol errors are handled in routing or routed protocols. So, if I'm a sender, and suddenly my receiver can't sync w/ me, then I have no error message to use to debug. Having dealt with this before, I can tell you that it is _no_fun_! Also, this is clearly not just for adjacent peers, as BGP , LSPs, LSAs, etc.. are all preserved multi-hop. Some taxonomy for routed v. routing (session v. multi-hop messages) might be useful here. I think some of the other KARP work touches on this a bit, perhaps references and application are in order? 4) Section 3 the key selection protocol seems a little too generic to be useful... Pre-canning algorithm preference as the first choice seems to miss other degrees of freedom that might be very application specific. Also, I wonder if (as this protocol might evolve) there would be contention between peers in which one would _presume_ a certain algo preference order, but the other might implement a different choice? The point is, codifying that there is a mandate here seems optimistic and reaching, shouldn't that be done in the corresponding protocol specifications?. 5) Section 6's operational considerations seems like a very under powered provision for the need for time synchronization between peers. As suggested, this text essentially acknowledges that there is a problem, and offers a wouldbe solution that (by definition) will fail after prolonged clock drift. 6) Section 7 should include a treatise on the dependency this protocol will have on time sync (such as through NTP or something)... NITs: ===== S.2: --- s/will multiple rows will contain/...?/ --- Under the "Peers" definition what's "unicast keys" mean? --- Also, what do you mean by "name a routing area for a multicast routing protocol"? Are you suggesting reference the area or level in LS protocols, or referring to something in PIM-* et al, or something else? Then intention and context here is unclear? --- Recommend replacing "packet" with "message" in *all* such instances? --- As for "Interfaces", the concept of interface groups would likely be valuable here, or perpaps the notion of "router" or "context" level values? This applies to the TCP-AO example where eBGP v. Transit eBGP for internal would all be large numers with lots of overlap, but may vary across sets and perhaps even across AFI/SAFI. --- In the Protocol section here, it's still unclear to me if we're talking about routing or routed protocols, or PWs, or LS updates in LS protocols, etc.. --- I'm kinda surprised there's nothing some akin to a KDF or AlgID registry already. How to those developers no to include their algorithms in this registry now? --- S.3: --- "Outoing packet" v. "message" again? I think we need to be more precise here. --- What does "loosely bound" mean? --- The conditions outlined in key matches would likely benefit considerably from the notion of interface groups or similar (e.g., internal v. external, etc..). --- You talk in this section about how exceeding the lifetime on a particular long-lived key does not have any impact - how do you know this? SHouldn't that be left to the protocol and deployment model? --- The last graf of S.3 about TCP-AO and other protocols using their own DB - did I miss something about what this should be the case? Is this IF they don't want to use this DB, or is there something else here? The current text isn't very helpful in groking the context. --- S.4 talks again a lot about "packets", when I think sometime you mean messages v. packets, but perhaps sometime not? --- References: Russ, I'm a little surprised you use your home address in these.. --- s/when received in a packet./when received in a message./