Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements
draft-ietf-karp-threats-reqs-07
Yes
(Stewart Bryant)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Wesley Eddy)
Note: This ballot was opened for revision 05 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2012-07-19 for -05)
Unknown
I am pleased to support the publication of this document. Requirement 20 in Section 4 seems to be the only one without an RFC 2119 word. Think this should be: Thus proposed solutions SHOULD be evaluated carefully with
Stewart Bryant Former IESG member
Yes
Yes
(for -05)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2012-07-12 for -05)
Unknown
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- Section 2.1 -- Three basic services may be employed in order to secure any piece of data as it is transmitted over the wire: confidentiality, authenticity, or integrity. You're not talking about *employing* these to secure anything; they're not "services" that you use. You're talking about what you *get* as a benefit from securing the data. Your goal here, by securing the data, is to get authenticity an integrity, but not confidentiality. Please re-word this accordingly. You also say "privacy" right after this. Do you really mean "privacy", or should it be "confidentiality"? -- Section 2.3 -- OLD 3. Ensure that the improved security solutions on currently running routing infrastructure equipment are deployable. This begs the consideration of the current state of processing power available on routers in the network today. This is a bit awkward in phrasing. I suggest this: NEW 3. Ensure that the improved security solutions are deployable on currently running routing infrastructure equipment. This requires consideration of the current state of processing power available on routers in the network today. But anyway, isn't this part of item 4, "Operational deployability"? In item 4: OLD F. There are three use cases for operational peering at play here: peers and interconnection with other operators, iBGP, and other routing sessions within a single operator, and operator-to-customer devices. I'm not sure I see the three cases. I think the problem is that one of the cases is itself a list with commas. You should use semicolons in the outer list when that happens, but in this case maybe you just need to remove the comma after "iBGP"? -- Section 2.4 -- Privacy and confidentiality are not the same thing; please don't use them interchangeably. You mean confidentiality, and you should probably scrub the document of all instances of "privacy", because this happened in Section 2.1 as well. -- Section 3.1.2.1 -- The second paragraph is long, rambling, confused, and confusing. Please tighten it, trim it, and take out the unnecessary stuff about "well, he could be an INSIDER, and he could be BYZANTINE, but he's unauthorized, and then he's *really* unauthorized, so then he's an OUTSIDER and......" May I suggest this for the whole paragraph?: NEW A terminated employee, once an INSIDER, becomes unauthorized and an OUTSIDER at the point of termination -- no longer a legitimate participant in the routing system. It behooves the operator to change the keys, to enforce the revocation of authorization of the old keys, in order to minimize the threat source's window of opportunity. The last two paragraphs also repeat themselves, and should probably be merged. For instance, the penultimate one says that key changes need to happen "very quickly, with zero impact to the routing system, and with little operational expense," and the last paragraph says, "quickly with minimal impact to the routing system, at low operational cost." Whether zero or minimal, you shouldn't say the same thing twice in two paragraphs. Do a merger here. -- Section 3.2 -- attacker sends spoofed packets aimed at halting or preventing the underlying protocol over which the routing protocol runs. I can't parse "preventing the protocol". "Halting the protocol" is OK, but "preventing" doesn't work the same way (you have to prevent it *from doing something*). Re-word. More general: are all DoS attacks on the routing system really spoofing attacks? In general, some DoS attacks are done by spoofing and some aren't. Is that not the case with routing attacks? (I don't know; I'm asking.) -- Section 4 -- Requirement 2: Strong cryptographic algorithms, as defined and accepted by the IETF security community, MUST be specified. The use of non- standard or unpublished algorithms SHOULD BE avoided. These are contradictory: non-standard and unpublished algorithms won't be accepted by the IETF security community, and so are already declared MUST NOT by the first sentence. Make it "MUST be avoided," or "MUST NOT be used." Requirement 3: Algorithm agility for the cryptographic algorithms used in the authentication MUST be specified, i.e. more than one algorithm MUST be specified and it MUST be clear how new algorithms MAY be specified and used within the protocol. Hm. You don't really need to have more than one algorithm specified; you just have to *be able* to specify more than one, and have a way to add new ones. This requirement isn't meant to say that if only one suitable algorithm exists at the time the protocol is written, that's a problem. The "MAY" is also an improper use of 2119 language. How about this?: NEW Algorithm agility for the cryptographic algorithms used in the authentication MUST be specified. That is, it MUST be possible to choose which algorithm is being used, and it MUST be clear how new algorithms are specified and used within the protocol. You may also need to make changes later in the paragraph, where you say "Mandating two algorithms". Requirement 5: Item "A" seems out of place here. It's not a requirement nor an explanation of one. It's a specific threat that you've stuck in the middle of the requirements section. (I also don't see how it directly relates to requirement 5.) It should be moved elsewhere (maybe a new Section 3.1.3?). Requirement 6: A change of security parameters REQUIRES, and even forces, a change of session traffic keys. "REQUIRES" is not a 2119 word. If you want to keep 2119 language here, maybe this: NEW A change of security parameters MUST force a change of session traffic keys. Otherwise, just make "requires" lower case. Requirement 7: Intra-session re-keying which occurs without a break or interruption to the current routing session, and, if possible, without data loss, MUST be specified. There's a little too much in there, and "if possible" seems not to go so well in the same sentence as MUST. How about this?: NEW Intra-session re-keying that occurs without a break or interruption to the current routing session MUST be specified. If possible, this ought to happen without data loss. Requirement 22: The second paragraph looks like it should be a separate requirement, number 23. -- Section 5 -- The second Security Considerations paragraph doesn't seem to belong here. As with paragraph "A" in requirement 5, above, it really looks like it should be moved to the threats discussion, and, in fact, seems like a variation of that attack (a variation that's performed by a Byzantine insider). I suggest putting both attacks into a new Section 3.1.3, because they're so closely related. The first paragraph of the Security Considerations seems to stand alone as sufficient for this document.
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2012-07-13 for -05)
Unknown
- Section 1.1 s/assymetric/asymmetric/ - Section 2.1 * I agree with Barry that the document should not inter-change confidentiality and privacy. They are different components and can be accomplished in vastly different ways. - Section 2.3 * Does backwards compatibility need to be considered? Or is it being implied within the incremental deployment discussion? - Section 4 * It may be the way I am reading them, but requirements 21 and 22 seem to be contradictory. Requirement 21 says "if you can, centralize some features to reduce the work load on all routers". On the other hand, requirement 22 says "don't build in any external dependencies".
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(for -05)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -05)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2012-07-19 for -05)
Unknown
Please consider the editorial comments from the Gen-ART Review by Vijay Gurbani on 18-July-2012. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07639.html
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-12-20)
Unknown
Thank you for addressing my concerns.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-07-19 for -05)
Unknown
- Are there any weird cases where a lack of address aggregtaion (esp for IPv6) could create a privacy issue that would mean that a confidentiality service might be needed? (Just checking) - s/privacy/confidentiality/ please - the language telling secdir reviewers what to do ought be less presecriptive - I agree with Sean's discuss
Wesley Eddy Former IESG member
No Objection
No Objection
(for -05)
Unknown