OSPFv3 Graceful Restart
draft-ietf-ospf-ospfv3-graceful-restart-08

[Ballot discuss]
In her SecDir Review, Hilarie Orman pointed out that the message
  described in this document seems to give attackers a new method
  obscuring network configuration changes.  If it is possible to send
  bogus messages, the adjacency of a dead router could be preserved
  indefinitely.

  In response, Acee Lindem indicated that this attack is much more
  difficult than the obvious replay of a normal OSPFv3 hello packets
  to keep the adjacency up.  Since hello packets are sent more
  predictably and knowledge of the key is not required, the risk
  added by OSPFv3 graceful restart is insignificant.

  I would like to see this information added to the Security
  Considerations.

The expected replacement paragraph is:

  [OSPFv3-AUTH] relies on manual key distribution which precludes the
  use of replay protection utilizing sequence numbers.  Replay of an OSPF
  Link-Update containing a grace-LSA would allow an attacker to deceive
  neighboring routers into believing that a router that has been taken
  out of service (either intentionally or via a malicious action by the
  same attacker) is still active and is in the process of graceful
  restart.  However, this attack is much more difficult than the obvious
  replay of standard OSPFv3 hello packets to accomplish the same thing by
  keeping the adjacency up.  Since hello packets are sent more
  predictably and knowledge of the key is not required, the risk added
  by OSPFv3 graceful restart is insignificant. Hence, this  document does
  not raise any new security concerns other than those  covered in
  [OSPFv3], [OSPFv3-AUTH], and [GRACE].

[Ballot discuss]
The IANA considerations section does not properly name the registry that
is used by this document.  While it appears IANA was able to discern
the correct registry as the "OSPFv3 LSA Function Codes" sub-registry of
the "Open Shortest Path First v3 (OSPFv3) Parameters" registry,
the document should actually include the precise names so readers of
the document without in-depth knowledge of IANA can find the registry.

[Ballot discuss]
In her SecDir Review, Hilarie Orman pointed out that the message
  described in this document seems to give attackers a new method
  obscuring network configuration changes.  If it is possible to send
  bogus messages, the adjacency of a dead router could be preserved
  indefinitely.

  In response, Acee Lindem indicated that this attack is much more
  difficult than the obvious replay of a normal OSPFv3 hello packets
  to keep the adjacency up.  Since hello packets are sent more
  predictably and knowledge of the key is not required, the risk
  added by OSPFv3 graceful restart is insignificant.

  I would like to see this information added to the Security
  Considerations.

PROTO writeup by Abhay Roy:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

Yes

    Do you have any concerns about the depth or breadth of the reviews
    that have been performed?

No. This document is a counterpart to rfc3623 and uses similar
mechanism as specified in rfc3623.

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any 
    event, if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

No

  5. 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?

Since it's a similar mechanism as in use by OSPFv2, there is
a strong consensus for this document.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items ?

Yes (used idnits 2.04.16 to verify)

  8. Is the document split into normative and informative references?
    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state?
    (note here that the RFC editor will not publish an RFC with
    normative references to IDs, it will delay publication until all
    such IDs are also ready for publication as RFCs.)

Yes, No

  9. What is the intended status of the document? (e.g., Proposed
    Standard, Informational?)

Proposed Standard

10. For Standards Track and BCP documents, the IESG approval
    announcement includes a write-up section with the following
    sections:

    * Technical Summary

This documents extends OSPF graceful restart as documented
in RFC 3623 to OSPFv3. An OSPFv3 LSA type is used for signaling
and there are additional concerns with respect to avoiding churn
when determining whether pre-restart LSAs need to be reoriginated.

    * Working Group Summary

There was no opposition to this document. There was one proposal
to modify the existing OSPF graceful restart mechanism but it was
not adopted by the working group and the requirement is unclear.

    * Protocol Quality

The OSPFv3 graceful restart exhibits the quality as the
base OSPF Graceful Restart specification (RFC 3623). Both planned
and unplanned restart are supported. Depending on configuration,
OSPF LSAs changes may result in helping routers aborting graceful
restart or allowing the restarting router to proceed.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignment in the "Open Shortest Path First v3 (OSPFv3) Parameters"
registry located at
http://www.iana.org/assignments/ospfv3-parameters
Sub-registry: "OSPFv3 LSA Function Codes"

LSA Function Code LS Type Description Reference
----------------- ---------------------------------- ---------
11 GRACE-LSA [RFC-ospf-ospfv3-graceful-restart-07]

We understand the above to be the only IANA Action for this
document.

From: Acee Lindem
Subject: OSPFv3 Graceful Restart -  draft-ietf-ospf-ospfv3-graceful-restart-04.txt
Date: Tue, May 16 11:53:37
To: Bill Fenner , Ross Callon
Cc: OSPF List , rtg-dir@ietf.org, IESG Secretary

The OSPF WG last call has ended and the comments have been addressed.

http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-graceful-restart-04.txt

Please begin the AD evaluation on this document.

Thanks,
Acee