Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
draft-ietf-karp-ospf-analysis-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-02-22
|
06 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2012-12-20
|
06 | Elwyn Davies | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Elwyn Davies. |
2012-12-14
|
06 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-12-14
|
06 | (System) | IANA Action state changed to No IC |
2012-12-14
|
06 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed |
2012-12-14
|
06 | Amy Vezza | IESG has approved the document |
2012-12-14
|
06 | Amy Vezza | Closed "Approve" ballot |
2012-12-14
|
06 | Amy Vezza | Ballot approval text was generated |
2012-11-30
|
06 | Stewart Bryant | Ballot writeup was changed |
2012-11-26
|
06 | Sam Hartman | New version available: draft-ietf-karp-ospf-analysis-06.txt |
2012-11-18
|
05 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2012-11-15
|
05 | Cindy Morgan | State changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for AD Go-Ahead |
2012-11-15
|
05 | Ralph Droms | [Ballot comment] I agree with Adrian's comments and would be tempted to raise some of them, esp. regarding section 5, to a Discuss. Formerly a … [Ballot comment] 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? |
2012-11-15
|
05 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2012-11-15
|
05 | Stewart Bryant | Ballot writeup was changed |
2012-11-15
|
05 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-11-15
|
05 | Ralph Droms | [Ballot discuss] Regarding the first sentence of section 5: A security solution will be developed for OSPFv2 and OSPFv3 based on the OSPFv2 … [Ballot discuss] 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? |
2012-11-15
|
05 | Ralph Droms | [Ballot comment] I agree with Adrian's comments and would be tempted to raise some of them, esp. regarding section 5, to a Discuss. |
2012-11-15
|
05 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2012-11-14
|
05 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-11-14
|
05 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-11-13
|
05 | Sean Turner | [Ballot comment] Nicely done - one comment and then some nits: There's but one requirement in this draft: In order to support packet prioritization, the … [Ballot comment] 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. |
2012-11-13
|
05 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-11-13
|
05 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-11-13
|
05 | Russ Housley | [Ballot comment] Please consider the non-blocking comments from the Gen-ART Review by Elwyn Davies on 5-Nov-2012. You can find the review here: … [Ballot comment] 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 |
2012-11-13
|
05 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-11-13
|
05 | Brian Haberman | [Ballot comment] I agree with Adrian's comments. |
2012-11-13
|
05 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-11-13
|
05 | Ron Bonica | [Ballot comment] It be useful to note that most networks running OSPF mitigate its vulnerabilities by blocking all OSPF traffic at the network edge. |
2012-11-13
|
05 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-11-13
|
05 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document, but I have a number of comments that I hope you will look … [Ballot comment] 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. |
2012-11-13
|
05 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2012-11-12
|
05 | Stephen Farrell | [Ballot comment] I think it'd be good if this: "The key components of this solution work are already underway." was stated up front. Keeping the … [Ballot comment] 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:-) |
2012-11-12
|
05 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-11-10
|
05 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-11-10
|
05 | Barry Leiba | [Ballot comment] 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 … [Ballot comment] 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. |
2012-11-10
|
05 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-11-08
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2012-11-08
|
05 | Jean Mahoney | Request for Telechat review by GENART is assigned to Elwyn Davies |
2012-11-08
|
05 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-11-05
|
05 | Stewart Bryant | Placed on agenda for telechat - 2012-11-15 |
2012-11-05
|
05 | Stewart Bryant | Ballot has been issued |
2012-11-05
|
05 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2012-11-05
|
05 | Stewart Bryant | Created "Approve" ballot |
2012-11-01
|
05 | Stewart Bryant | Ballot writeup was changed |
2012-10-17
|
05 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-10-08
|
05 | Pearl Liang | IANA has reviewed draft-ietf-karp-ospf-analysis-05, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there … IANA has reviewed draft-ietf-karp-ospf-analysis-05, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there are no IANA Actions that need completion. |
2012-10-04
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-10-04
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Elwyn Davies |
2012-10-04
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2012-10-04
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2012-10-03
|
05 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Analysis of OSPF Security According to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Analysis of OSPF Security According to KARP Design Guide) to Informational RFC The IESG has received a request from the Keying and Authentication for Routing Protocols WG (karp) to consider the following document: - 'Analysis of OSPF Security According to KARP Design Guide' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in section 4.2 of RFC6518. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-karp-ospf-analysis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-karp-ospf-analysis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-10-03
|
05 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-10-03
|
05 | Stewart Bryant | Last call was requested |
2012-10-03
|
05 | Stewart Bryant | Ballot approval text was generated |
2012-10-03
|
05 | Stewart Bryant | Ballot writeup was generated |
2012-10-03
|
05 | Stewart Bryant | State changed to Last Call Requested from Publication Requested |
2012-10-03
|
05 | Stewart Bryant | Last call announcement was generated |
2012-08-13
|
05 | Amy Vezza | Proto writeup for draft-ietf-karp-ospf-analysis (1) This is targeted to be an Informational RFC. It's role is providing guidance to protocol authors. The type is listed … Proto writeup for draft-ietf-karp-ospf-analysis (1) This is targeted to be an Informational RFC. It's role is providing guidance to protocol authors. The type is listed on the title page header. (2) Sample IESG approval announcement: Technical Summary This document analyzes the security mechanisms for OSPFv2 and OSPFv3, according to the guidelines set forth in RFC 6518. In analyzes the current state of each protocol, describes gaps, and discusses work that needs to be done to close those gaps. Working Group Summary This document is the first of a series of documents analyzing routing protocol security, which is the initial mission of the working group. There was little controversy of note. Members and chairs of the OSPF WG were active in its development and review. Document Quality The document meets the criteria for the phase 1 analysis as defined in RFC 6518. Recommendations of methods of closing security gaps have already been included in I-Ds accepted as OSPF WG documents. Personnel Brian Weis is the document shepherd. Stewart Bryant is the responsible AD. (3) The document shepherd has reviewed the document and believes it is ready for publication. (4) The document shepherd believes the document achieved sufficient review during its development and Working Group last call process. (5) Although this document is generated in the Routing Area, the entire document relates to security. A substantial amount of the working group comprises individuals who participate in the Security Area and the document shepherd believes an adequate security review was obtained. (6) The document shepherd has no specific concerns or issues with the document. (7) Each author has confirmed that any and all appropriate IPR disclosures have been filed. (8) No IPR disclosures have been filed. (9) WG consensus is solidly behind this document. (10) There are no appeals expected, or claims of discontent expected. (11) Three very minor id-nits issues remain with this document, and will be fixed in the next version. (12) There are no required formal reviews. (13) All references within this document have been identified as either normative or informative. (14) All normative references are stable published RFCs. (15) There are no downward normative references. (16) Publication of this document will not change the status of any existing RFCs. (17) There are no IANA considerations in this document. (18) There are no new IANA registries added with this document. (19) None of the document is written in a formal language. |
2012-08-13
|
05 | Amy Vezza | Note added 'Brian Weis is the document shepherd. ' |
2012-08-13
|
05 | Amy Vezza | Intended Status changed to Informational |
2012-08-13
|
05 | Amy Vezza | IESG process started in state Publication Requested |
2012-08-13
|
05 | (System) | Earlier history may be found in the Comment Log for draft-hartman-ospf-analysis |
2012-08-13
|
05 | Brian Weis | Changed protocol writeup |
2012-07-10
|
05 | Brian Weis | IETF state changed to Submitted to IESG for Publication from WG Document |
2012-07-10
|
05 | Brian Weis | Annotation tag Doc Shepherd Follow-up Underway set. |
2012-07-10
|
05 | Brian Weis | Document shepherd wrietup has been entered, and the WG chairs request an IETF LC. |
2012-07-10
|
05 | Brian Weis | Preparing for submission to AD following WGLC. |
2012-07-10
|
05 | Dacheng Zhang | New version available: draft-ietf-karp-ospf-analysis-05.txt |
2012-07-03
|
04 | Brian Weis | Changed shepherd to Brian Weis |
2012-06-06
|
04 | Sam Hartman | New version available: draft-ietf-karp-ospf-analysis-04.txt |
2012-03-12
|
03 | Sam Hartman | New version available: draft-ietf-karp-ospf-analysis-03.txt |
2012-02-25
|
02 | (System) | Document has expired |
2011-08-24
|
02 | (System) | New version available: draft-ietf-karp-ospf-analysis-02.txt |
2011-06-03
|
01 | (System) | New version available: draft-ietf-karp-ospf-analysis-01.txt |
2011-03-07
|
00 | (System) | New version available: draft-ietf-karp-ospf-analysis-00.txt |