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

["Adrian Farrel" <[e-mail]>]

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.