Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
draft-ietf-karp-ospf-analysis-06
Yes
(Stewart Bryant)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Wesley Eddy)
Note: This ballot was opened for revision 05 and is now closed.
Stewart Bryant Former IESG member
Yes
Yes
(for -05)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-11-13 for -05)
Unknown
I have no objection to the publication of this document, but I have a number of comments that I hope you will look at and consider as ways to improve the value of the document. --- Section 1 This document performs the initial analysis of the current state of OSPFv2 and OSPFv3 according to the requirements of [RFC6518]. This suggests that a further analysis is required. What should it cover? When will it be done? Who will do it? --- Section 2.2 There is another serious problem with the OSPFv3 security: rather than being integrated into OSPF, it is based on IPsec. In practice, this has lead to deployment problems. I think you probably need to expand on this to indicate what deployment problems have been seen, and maybe why this is caused by the dependency on IPsec. Section 4 compounds the issue by saying In order to encourage deployment of OSPFv3 security, an authentication option is required that does not have the deployment challenges of IPsec. This challenges need to be described or you need to point at a reference. --- Section 3 I am a little surprised not to find any discussion of physical link security. Replay attacks rely on being able to send packets to an OSPF receiver. On P2P links there are only three possibilities: 1. The peer has been subverted. In this case, a replay attack is the least damage that can be done! 2. A replay packet is tunneled to the receiver over multiple IP hops. This case is simply prevented by not allowing OSPF packets to be received in this way. (I see you finally get round to talking about GTSM and ACLs in Section 7). 3. A node has been physically inserted on the link. So it would appear that the third case needs to be discussed, and it may be the case that the greatest vulnerability is on a multi-access link because the ability to insert a node between two OSPF peers would seem to allow far more amusing attacks than just replay. --- Section 4 In order to support the requirement for simple preshared keys, OSPF needs to make sure that when the same key is used for two different purposes, no problems result. This is the first mention of this issue. --- Section 4 In order to support packet prioritization, the information needed to prioritize OSPF packets (the packet type) MUST be at a constant location in the packet. I don't agree with this. Previously you said (section 2.2)... For this reason, prioritizing packets may be more complex for OSPFv3. One approach is to establish per-SPI filters to find the packet type and act accordingly. ...and that seems to agree with me that it is perfectly acceptable to operate with the packet type being located at different points in the packet. I would agree if you said it is desirable to enable a simplification, but "MUST" seems way too strong. --- Section 5 The key components of this solution work are already underway. OSPFv3 now supports an authentication option [RFC6506] that meets the requirements of this section, except that it does not describe how the key tables are used for OSPF. This is really weird! We have read this document so far in the belief that OSPFv3 is missing some key security aspects. And now you tell us that RFC 6506 (which is part of the OSPFv3 suite) already meets some of the requirements. Now my understanding of the gap analysis is completely confused. Are you saying that there is actually only one remaining gap for OSPFv3? === The following are nits you should consider if you have the document open for further edits... --- Obviously need to fix the line that is longer than 72 characters. --- Looks like [I-D.ietf-opsec-routing-protocols-crypto-issues] can be dropped fromthe references as it has become RFC 6039. --- Refer to this document as a "document" not a "draft" to reduce the work of the RFC Editor at a later stage.
Barry Leiba Former IESG member
No Objection
No Objection
(2012-11-10 for -05)
Unknown
Well written. I just have a couple of minor non-blocking editorial suggestions for Section 1.1, which you may take or leave as you please: There are a number of requirements described in section 3 of [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet: What follows this is indented, and appears to all the world as a quotation from karp-threats-reqs. I knew it couldn't be, and found that confusing. I had to go look at karp-threats-reqs to check. I suggest that you un-indent the subsequent paragraphs, and that you rephrase the above somewhat like this: "There are a number of requirements described in section 3 of [I-D.ietf-karp-threats-reqs] that OSPF does not currently meet. The gaps are as follows:". That would make it clearer that what follows is text in this document, not anything quoted from the other. Replay Protection: OSPFv3 has no replay protection at all. OSPFv2 has most of the mechanisms necessary for intra-connection replay protection. Unfortunately, OSPFv2 does not securely identify the neighbor with whom replay protection state is associated in all cases. This weakness can be used to create significant denial-of- service issues using intra-connection replays. OSPFv2 has no inter-connection replay protection; this creates significant denial-of-service opportunities. I found it hard to follow the combination of different versions of OSPF and different aspects of replays, put into the same paragraph. Maybe a bullet list would be clearer: Replay Protection: * OSPFv3 has no replay protection at all. * OSPFv2 has most of the mechanisms necessary for intra-connection replay protection. Unfortunately, OSPFv2 does not securely identify the neighbor with whom replay protection state is associated in all cases. This weakness can be used to create significant denial-of- service issues using intra-connection replays. * OSPFv2 has no inter-connection replay protection; this creates significant denial-of-service opportunities.
Benoît Claise Former IESG member
No Objection
No Objection
(for -05)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2012-11-13 for -05)
Unknown
I agree with Adrian's comments.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -05)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(2012-11-15 for -05)
Unknown
I agree with Adrian's comments and would be tempted to raise some of them, esp. regarding section 5, to a Discuss. Formerly a discuss, addressed in an RFC Editor note: Regarding the first sentence of section 5: A security solution will be developed for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. In general, passive voice is to be avoided. In particular, how can this document make an unilateral statement about what will be developed and the technical details of the solution?
Robert Sparks Former IESG member
No Objection
No Objection
(for -05)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(2012-11-13 for -05)
Unknown
It be useful to note that most networks running OSPF mitigate its vulnerabilities by blocking all OSPF traffic at the network edge.
Russ Housley Former IESG member
No Objection
No Objection
(2012-11-13 for -05)
Unknown
Please consider the non-blocking comments from the Gen-ART Review by Elwyn Davies on 5-Nov-2012. You can find the review here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07898.html
Sean Turner Former IESG member
No Objection
No Objection
(2012-11-13 for -05)
Unknown
Nicely done - one comment and then some nits: There's but one requirement in this draft: In order to support packet prioritization, the information needed to prioritize OSPF packets (the packet type) MUST be at a constant location in the packet. Seems like an odd requirement for a security analysis draft. Can you explain the motivation for it in this draft a bit more? And now for the nits: 0) You've got two requirements language paragraphs. 1) I thought the same thing as Adrian did about the 1st sentence in s1. Maybe: r/performs the initial analysis of the /analyzes the 2) s1, para 2: Should you specify that when OSPF is used you're referring to both OSPFv2 and OSPFv3? Also, the mention of OSPFv2 in the last paragraph made me wonder whether you should also say something like: while the currently OSPFv3 security solution can interfere with prioritization. 3) s1, para 3: Can you strike " the requirements" from the following: However, some gaps remain between the current state and the requirements for manually keyed routing security expressed in [I-D.ietf-karp-threats-reqs] the requirements. 4) s1.1, PSK (and later s4 and s5): Could drop "simple" because it doesn't appear in the karp requirement and one person's simple is another person's complex. 5) s2.1, para 2: Shameless plug for RFC 6151, which provides an update to the MD5 security considerations and supports your assertion that MD5 ought not be used going forward. 6) s2.2, para 1: Maybe add IPsec in the first para: r/how the authentication header/how the IPsec authentication header 7) s2.2, last para: Are you saying that just the integrity algorithm matters here? Isn't it the entire suite? When IPsec is used with OSPFv3, the offset of the packet type, which is used to prioritize packets, depends on what integrity transform is used.
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-11-12 for -05)
Unknown
I think it'd be good if this: "The key components of this solution work are already underway." was stated up front. Keeping the good news for the very end seem mean:-)
Wesley Eddy Former IESG member
No Objection
No Objection
(for -05)
Unknown