Progress with draft-ietf-ccamp-rsvp-restart-ext

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

The Routing ADs and chairs got together with Sam (as Security AD) to work 
through Sam's Discuss on this I-D.

Sam had some clear concerns about the trust model and security consequences 
introduced by the restart mechanisms introduced by this I-D. By dint of some 
hard work and open communication we have netted down the concerns and come 
up with a small set of changes to the draft that address Sam's concerns and 
make the draft clearer.

I don't believe that these edits in any way change the technical content of 
the draft, but they do make it clearer what you are not allowed to do. So I 
won't be issuing another WG last call, and there won't be another IETF last 
call.

But please look through the changes (below) and shout if there are any 
issues. It is still not too late to fine tune.

Thanks,
Adrian
===
Abstract
Add new 4th paragraph.

  These extensions are not used to create or restore data plane state.

===
Section 3. Introduction

Paragraph 2 begins...

  This document presents extensions to address two aspects of graceful
  restart not previously supported.  The presented extensions enable a
  restarting node to recover all objects in previously transmitted Path
  messages including the Explicit Route Object (ERO), from its
  downstream neighbors.

Append to this...

  and so recover control plane state. The extensions do not facilitate
  the recovery or creation of data/forwarding plane state, and can only
  be used to re-establish control plane state which matches in-place
  data/forwarding state.

===
Section 4.3.  Related Procedures

Add new 4th paragraph.

  There are no changes to the procedures with respect of the
  data/forwarding plane as described in [RFC3473]. In particular, a
  restarting node MUST NOT create data/forwarding plane state as the
  result of any of the extensions defined in this document.

===
4.5.2.  Procedures for the Restarting Node

Add to end of first paragraph.

  The restarting node MUST NOT create data plane or forwarding
  state to match the received RecoveryPath message.

===
4.5.2.2.  Re-Synchronization Procedures

Replace the final paragraph

OLD
  If no forwarding state is located, the node treats the path message
  as a setup for a new LSP.  The outgoing interface and label(s)
  indicated in the RecoveryPath message SHOULD be reused, when
  possible.  All other information contained in the RecoveryPath
  message MAY also be used.

NEW
  If no forwarding state is located, the node treats the received Path
  message as a setup request for a new LSP.  The outgoing interface and
  label(s) indicated in the RecoveryPath message SHOULD be reused, when
  possible.  All other information contained in the RecoveryPath
  message MAY also be used. That is, forwarding state MUST NOT be
  created except after receipt of a Path message from upstream or, at
  an ingress node, the receipt of a command from the management plane.
  Further, the forwarding state created is subject to local policy and
  the information received from downstream in the RecoveryPath message
  is treated only as advisory.

===
6.  Security Considerations

Add a final paragraph.

  Note that the procedures defined in this document cannot be used to
  create false forwarding state.  The restarting node that receives a
  RecoveryPath message that does not match the existing forwarding
  state MUST NOT create or modify its forwarding state to match.  A
  restarting node SHOULD log such an event or otherwise notify the
  operator since it might represent an attack.