Skip to main content

Security Extension for OSPFv2 When Using Manual Key Management
draft-ietf-ospf-security-extension-manual-keying-11

Revision differences

Document history

Date Rev. By Action
2015-04-09
11 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-04-07
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-04-06
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-04-05
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-03-31
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-03-31
11 (System) IANA Action state changed to In Progress from RFC-Ed-Ack
2015-03-31
11 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-03-31
11 Amy Vezza IESG has approved the document
2015-03-30
11 Alia Atlas IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead
2015-03-25
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2015-03-24
11 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-03-24
11 Amanda Baber
IESG/Authors/WG Chairs:

IANA completed the actions for draft-ietf-ospf-security-extension-manual-keying-11 after it was approved for publication. We understand that the changes to this document do not affect …
IESG/Authors/WG Chairs:

IANA completed the actions for draft-ietf-ospf-security-extension-manual-keying-11 after it was approved for publication. We understand that the changes to this document do not affect its registrations, which are still in place. If this is correct, no further IANA actions are required.

The references in the registry will be replaced with the RFC number after the RFC Editor notifies us that the number has been assigned.
2015-03-11
11 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Extension for OSPFv2 when …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Extension for OSPFv2 when using Manual Key Management) to Proposed Standard

The IESG has approved the following document from the Open Shortest Path
First IGP WG (ospf):
  'Security Extension for OSPFv2 when using Manual Key Management'
  as Proposed
Standard

However, the document has had substantive changes to section 4 during the final document
review period. These changes are to better align with RFC 7210 and the
best practices in RFC 7211. There is also a correction in the last
paragraph of section 5. Hence, we are going to WG last call the final
document (now RFC 7474) as well as have a simultaneous IETF Last Call on
these specific changes.

The final document is located here:

http://www.rfc-editor.org/authors/rfc7474.txt
http://www.rfc-editor.org/authors/rfc7474-diff.html

This diff file shows changes since the last posted version:
  http://www.rfc-editor.org/authors/rfc7474-lastdiff.html

This rfcdiff file shows side-by-side changes since the last posted version:
  http://www.rfc-editor.org/authors/rfc7474-rfcdiff.html


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 2015-03-25. 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


  The current OSPFv2 cryptographic authentication mechanism as defined
  in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
  intra-session replay attacks when using manual keying.  Additionally,
  the existing cryptographic authentication mechanism does not cover
  the IP header.  This omission can be exploited to carry out various
  types of attacks.

  This document defines changes to the authentication sequence number
  mechanism that will protect OSPFv2 from both inter-session and intra-
  session replay attacks when using manual keys for securing OSPFv2
  protocol packets.  Additionally, we also describe some changes in the
  cryptographic hash computation that will eliminate attacks resulting
  from OSPFv2 not protecting the IP header.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-manual-keying/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-manual-keying/ballot/


No IPR declarations have been submitted directly on this I-D.


2015-03-11
11 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-03-11
11 Alia Atlas Last call was requested
2015-03-11
11 Alia Atlas
We're doing a second round of quick Last Calls on this document due to some technical changes during AUTH48 to match up with RFC7210 and …
We're doing a second round of quick Last Calls on this document due to some technical changes during AUTH48 to match up with RFC7210 and RFC7211.

I've updated the last call text.
2015-03-11
11 Alia Atlas IESG state changed to Last Call Requested from AD is watching
2015-03-11
11 Alia Atlas Last call announcement was changed
2015-03-11
11 Alia Atlas Last call announcement was generated
2015-03-11
11 Alia Atlas The updated version (http://www.rfc-editor.org/authors/rfc7474-lastdiff.html ) needs a fast WGLC and IETF Last Call to handle the key table related issues.
2015-03-11
11 Alia Atlas The updated version (http://www.rfc-editor.org/authors/rfc7474-lastdiff.html ) needs a fast WGLC and IETF Last Call to handle the key table related issues.
2015-03-11
11 Alia Atlas Tag Other - see Comment Log set.
2015-03-11
11 Alia Atlas
Due to the changes around the key table that Sam Hartman raised, there is agreement on new text. 

http://www.rfc-editor.org/authors/rfc7474-lastdiff.html
has the new text included.

Since …
Due to the changes around the key table that Sam Hartman raised, there is agreement on new text. 

http://www.rfc-editor.org/authors/rfc7474-lastdiff.html
has the new text included.

Since this is a technical change, we're going to go through a fast WGLC and IETF Last Call to get it finalized.
2015-03-11
11 Alia Atlas IESG state changed to AD is watching from RFC Ed Queue
2015-03-02
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-02-26
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-01-28
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-01-27
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-01-27
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-01-22
11 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-01-22
11 (System) RFC Editor state changed to EDIT
2015-01-22
11 (System) Announcement was received by RFC Editor
2015-01-22
11 (System) IANA Action state changed to In Progress
2015-01-22
11 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-01-22
11 Cindy Morgan IESG has approved the document
2015-01-22
11 Cindy Morgan Closed "Approve" ballot
2015-01-22
11 Cindy Morgan Ballot approval text was generated
2015-01-22
11 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss
2015-01-20
11 Alia Atlas Awaiting confirmation from Jari that his DISCUSS has been properly handled.
It looks good to me.
2014-11-10
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2014-11-10
11 Acee Lindem IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-11-10
11 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-11.txt
2014-10-30
10 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for Writeup
2014-10-30
10 Cindy Morgan Changed consensus to Yes from Unknown
2014-10-30
10 Joel Jaeggli
[Ballot comment]
  If the non-volatile storage is ever repaired
  or upgraded such that the contents are lost or the OSPFv2 router is
  …
[Ballot comment]
  If the non-volatile storage is ever repaired
  or upgraded such that the contents are lost or the OSPFv2 router is
  replaced, the authentication keys MUST be changed to prevent replay
  attacks.

or if you ever replace the router...

part of the reason manual keying is used is changing the authentication is quite hard particularly in cases where there are multiple neighbors on the same subnet.
2014-10-30
10 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-10-30
10 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-10-30
10 Jari Arkko
[Ballot discuss]
I'm happy to recommend the document move forward. However, Suresh Krishnan pointed out that the reference to RFC 4222 regarding snmpEngineBoots seems incorrect. …
[Ballot discuss]
I'm happy to recommend the document move forward. However, Suresh Krishnan pointed out that the reference to RFC 4222 regarding snmpEngineBoots seems incorrect. Can that be fixed? Thanks.
2014-10-30
10 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko
2014-10-29
10 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2014-10-29
10 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-10-29
10 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-10-29
10 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-10-29
10 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2014-10-29
10 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-10-29
10 Suresh Krishnan Request for Last Call review by GENART Completed: Ready. Reviewer: Suresh Krishnan.
2014-10-29
10 Suresh Krishnan Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Suresh Krishnan.
2014-10-28
10 Barry Leiba [Ballot comment]
It seems that this document should be marked as "updates 5709", but it isn't.  Why not?
2014-10-28
10 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2014-10-28
10 Alissa Cooper [Ballot comment]
= Section 3 =
s/This section of this/This section/
2014-10-28
10 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-10-28
10 Shaun Cooley Request for Last Call review by SECDIR Completed: Ready. Reviewer: Shaun Cooley.
2014-10-28
10 Brian Haberman [Ballot comment]
I support the publication of this document, but agree with Adrian's suggestion to include some discussion on backwards compatibility.
2014-10-28
10 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-10-28
10 Adrian Farrel
[Ballot comment]
Thanks for this work. I am happy to ballot Yes, but have a couple of
minor points I think would benefit the document. …
[Ballot comment]
Thanks for this work. I am happy to ballot Yes, but have a couple of
minor points I think would benefit the document.

---

It would be good to add a very short note on backward compatiblity.  I
don't find anything in 2328, but I assume that a legacy implementation
receiving an unknown AuType is supposed to fail authentication.  Could
you state this with the appropriate reference?

---

The Abstract needs to be updated as:
s/draft/document/
s/proposes/defines/

---

Section 1 para 1
s/propose/define/

---

Section 1 final para

s/proposes/defines/

---

Section 1.2. The RFC Editor will move this sections to be consistent
with their editorial guidelines.

---

I think it is a mistake to quote the whole OSPF header in Figure 1.
This opens up questions of editorial mismatches and future changes etc.
It would be better to model this on Appendix D of RFC 2328.

Additionally, it may be better to name the packet-trailing field as
"Extended Authentication Data" to avoid confusion with the field in the
generic packet header shown in RFC 2328 and called "Authentication"
2014-10-28
10 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2014-10-27
10 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-10-27
10 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2014-10-27
10 Alia Atlas Ballot has been issued
2014-10-27
10 Alia Atlas [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas
2014-10-27
10 Alia Atlas Created "Approve" ballot
2014-10-27
10 Alia Atlas Ballot writeup was changed
2014-10-26
10 Acee Lindem IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-10-26
10 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-10.txt
2014-10-17
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-10-16
09 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Linda Dunbar.
2014-10-13
09 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-10-13
09 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-security-extension-manual-keying-08  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-ospf-security-extension-manual-keying-08  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there are two actions which IANA must complete.

First, in the Open Shortest Path First (OSPF) Authentication Codes registry located at:

https://www.iana.org/assignments/ospf-authentication-codes/

a new authentication code will be registered as follows:

Code: [ TBD-at-registration ]
Authentication Method: Cryptographic Authentication with Extended Sequence Numbers
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a code value of 3.

Second, in the Authentication Cryptographic Protocol ID registry located at:

https://www.iana.org/assignments/authentication-cryptographic-protocol-id/

a new ID is to be registered as follows:

Value: [ TBD-at-registration ]
Description: OSPFv2
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested an ID value of 2.

IANA understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.
2014-10-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2014-10-12
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2014-10-09
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-10-09
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shaun Cooley
2014-10-08
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2014-10-08
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2014-10-07
09 Manav Bhatia New version available: draft-ietf-ospf-security-extension-manual-keying-09.txt
2014-10-03
08 Amy Vezza IANA Review state changed to IANA - Review Needed
2014-10-03
08 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Extension for OSPFv2 when …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Extension for OSPFv2 when using Manual Key Management) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document:
- 'Security Extension for OSPFv2 when using Manual Key Management'
  as Proposed
Standard

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 2014-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


  The current OSPFv2 cryptographic authentication mechanism as defined
  in RFC 2328 and RFC 5709 is vulnerable to both inter-session and
  intra-session replay attacks when using manual keying.  Additionally,
  the existing cryptographic authentication mechanism does not cover
  the IP header.  This omission can be exploited to carry out various
  types of attacks.

  This draft proposes changes to the authentication sequence number
  mechanism that will protect OSPFv2 from both inter-session and intra-
  session replay attacks when using manual keys for securing OSPFv2
  protocol packets.  Additionally, we also describe some changes in the
  cryptographic hash computation that will eliminate attacks resulting
  from OSPFv2 not protecting the IP header.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-manual-keying/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ospf-security-extension-manual-keying/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-10-03
08 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2014-10-03
08 Alia Atlas Placed on agenda for telechat - 2014-10-30
2014-10-03
08 Alia Atlas Last call was requested
2014-10-03
08 Alia Atlas Last call announcement was generated
2014-10-03
08 Alia Atlas Ballot approval text was generated
2014-10-03
08 Alia Atlas Ballot writeup was generated
2014-10-03
08 Alia Atlas IESG state changed to Last Call Requested from Publication Requested
2014-06-24
08 Amy Vezza Notification list changed to : ospf-chairs@tools.ietf.org, draft-ietf-ospf-security-extension-manual-keying@tools.ietf.org, vishwas.ietf@gmail.com
2014-06-24
08 Amy Vezza Document shepherd changed to Vishwas Manral
2014-06-24
08 Amy Vezza
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Standards Track

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  This document describes a non backward-compatible technique that may
  be used by OSPF (Open Shortest Path First) implementations to prevent
  replay attacks even on cryptographically secured messages. The draft
  increases the sequence number size to 8 bytes and carries it in OSPF
  packet trailers.

Working Group Summary:

  There were some discussions around the technique and some additional
  issues with existing implementations were found, which increased the
  applicability of the given solution.
 

Document Quality:

  The document updates RFC2328 and RFC5709. The document has existed
  for more than 3 years as a WG document and has undergone 9 revisions
  in the period.

Personnel:

  Vishwas Manral is the document shepherd and Alia Atlas is the
  responsible AD.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

  The draft updates a critical flaw in RFC2328 which leaves it exposed
  to replay attacks. There has been significant review and discussion of
  this draft on the mailing list. There are no outstanding issues with
  this draft.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  No

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

  None

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

  Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

  No

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

  Strong consensus from WG with many participating in discussions.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

  No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  Authors have resolved all nits. Some small nits like the RFC the document updates etc, needs to be looked at which will be caught at the next review cycle.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

  Not applicable

(13) Have all references within this document been identified as either normative or informative?

  Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

  No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

  No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

  No, need to be updated.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

  IANA Considerations section exists.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

  There is no new IANA registery.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

  Not applicable
2014-06-24
08 Amy Vezza Intended Status changed to Proposed Standard
2014-06-24
08 Amy Vezza IESG process started in state Publication Requested
2014-06-24
08 Amy Vezza Working group state set to Submitted to IESG for Publication
2014-05-18
08 Manav Bhatia New version available: draft-ietf-ospf-security-extension-manual-keying-08.txt
2014-04-08
07 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-07.txt
2013-11-25
06 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-06.txt
2013-05-27
05 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-05.txt
2013-02-25
04 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-04.txt
2012-10-22
03 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-03.txt
2012-04-24
02 Acee Lindem New version available: draft-ietf-ospf-security-extension-manual-keying-02.txt
2011-10-26
01 (System) New version available: draft-ietf-ospf-security-extension-manual-keying-01.txt
2011-05-06
00 (System) New version available: draft-ietf-ospf-security-extension-manual-keying-00.txt