Skip to main content

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