Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 6 May 2008 16:00:37 -0500

CCAMP,
 
This is to initiate a Working Group Last Call on:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-02.t
xt
 
Please send your comments to the mailing list prior to EOB May 20.
 
Adrian and Deborah

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 18 May 2008 22:13:23 +0100

Hi,

Well written draft. Thanks.

Here are some comments. Most of them are small editorial issues.

Regards,
Adrian

===
idnits
tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the 
offending characters are ','

===
1. Introduction

   Recovery Label object

Please be consistent with the names for all objects within this I-D.
Mainly you use upper case, for example, RECOVERY_LABEL object

s/provides and informational/provides an informational/

===
2.1. Procedures defined in [RFC3473]

Please capitalise section heading.

s/2) Recovers its RSVP state/2) Recover its RSVP state/

s/state in data plane/state in the data plane/

s/is not existed/does not exist/

s/state in data plane is existed/state in the data plane exists/

You have:

   For the Restarting Node:
[SNIP]
   4)
[SNIP]
   In addition, if the node is not
   the tail-end of the LSP, the corresponding outgoing Path messages is
   sent with the incoming label from that entry carried in the
   UPSTREAM_LABEL object.
"incoming label from that entry" is correct, but may be confusing.
How about...
   In addition, if the node is not the tail-end of the LSP, the incoming
   label on the downstream interface is retrieved from the forwarding
   state on the restarting node and set in the UPSTREAM_LABEL object in
   the Path message sent to the downstream neighbor.

s/1) Sends the Path message/1) Sends a Path message/

===
2.2. Procedures defined in [RFC5063]

s/in [RFC5063] which is called the/in [RFC5063] called the /

s/From the received Path message the following state can be recovered:/
The following state can be recovered from the received Path message:/

s/From the received RecoveryPath message the following state can be 
recovered:/
The following state can be recovered from the received RecoveryPath 
message:/

s/either by regular Path message or RecoveryPath message, and Resv message./
either from the regular Path and Resv messages, or from the RecoveryPath 
message./

===
3. Multiple Node Restart Scenarios

s/Note that if multi nodes/Note that if multiple nodes/

===
5.2.2. Procedures for Scenario 2

s/node(Node A)/node (Node A)/

===
5.2.3. Procedures for scenario 3

Please capitalise section heading.

s/on the nodes that are waiting/on the node that is waiting/

===
5.2.4. Procedures for scenario 4

Please capitalise section heading.

You have:
   In the event that Node B never restarts, management plane
   intervention may be used at Node A to clean up any LSP state
   restored from the management plane or from local configuration.
More importantly, management plane action is needed to clean up the
data plane.

===
5.2.5. Procedures for scenario 5

Please capitalise section heading.

You have:
   In this scenario the Egress node (Node D) restarts, and its
   upstream neighbor (Node C) has not restarted. In this case, the
   Egress node is completely unaware of the LSPs. It has no downstream
   neighbor to help it, and no management plane or configuration
   information. The Egress node must simply wait until its upstream
   neighbor restarts and gives it the information as Path messages
   carrying RECOVERY_LABEL objects.
It is not quite the case that the egress is "completely unaware" of
the LSP as the data plane will be set up and carrying data (as
described in the next section).

===
6. Clarification of Restarting Node Procedure

In the figure, you have
     X(CON deletion)  X (CON deletion)
I suggest you replace this with
     X(LSP deletion)  X (LSP deletion)

Please add a caption for the figure. Such as,

         Figure 2 Message flow for accidental LSP deletion

c/hello/Hello/  (several times)

   To resolve the aforementioned problem, the following procedures are
   proposed and are meant to work together with the recovery
   procedures documented in [RFC3473]. Here, it is assumed that the
   restarting node and the neighboring node(s) support Hello extension
   as documented in [RFC3209] and recovery procedures documented in
   [RFC3473].
This paragraph implies that there *are* new procedures defined in this
document contrary to the promise in the Abstract and Introduction.
I suggest you change the text as follows...
   To resolve the aforementioned problem, the following procedures which
   are implicit in [RFC3473] and [RFC5063] should be followed. These
   procedures work together with the recovery procedures documented in
   [RFC3473]. Here, it is assumed that the restarting node and the
   neighboring node(s) support Hello extension as documented in
   [RFC3209] and recovery procedures documented in [RFC3473].

===
7. Security Considerations

We had some debate with the Security ADs when RFC 5063 was processed. We
need to fill out the text in this section a little to reflect those
comments.

I suggest replacing the existing text with the following...

   This document clarifies the procedures defined in [RFC3473] and
   [RFC5063] to be performed on RSVP agents that neighbor one or more
   restarting RSVP agents. It does not introduce any new procedures and,
   therefore, does not introduce any new security risks or issues.

   In the case of the control plane in general, and the RSVP agent in
   particular, where one or more nodes carrying one or more LSPs are
   restarted due to external attacks, the procedures defined in
   [RFC5063] and described in this document provide the ability for
   the restarting RSVP agents to recover the RSVP state in each
   restarting node corresponding to the LSPs, with the least possible
   perturbation to the rest of the network. These procedures can be
   considered to provide mechanisms by which the GMPLS network can
   recover from physical attacks or from attacks on remotely controlled
   power supplies.

   The procedures described are such that, only the neighboring RSVP
   agents should notice the restart of a node, and hence only they need
   to perform additional processing. This allows for a network with
   active LSPs to recover LSP state gracefully from an external attack,
   without perturbing the data/forwarding plane state, and without
   propagating the error condition in the control or data plane. In
   other words, the effect of the restart (which might be the result of
   an attack) does not spread into the network.

   Note that concern has been expressed about the vulnerability of a
   restarting node to false messages received from its neighbors. For
   example, a restarting node might receive a false Path message with a
   Recovery Label object from an upstream neighbor, or a false
   RecoveryPath message from its downstream neighbor. This situation
   might arise in one of four cases:

   - The message is spoofed and does not come from the neighbor at all.
   - The message has been modified as it was travelling from the
     neighbor.
   - The neighbor is defective and has generated a message in error.
   - The neighbor has been subverted and has a "rogue" RSVP agent.

   The first two cases may be handled using standard RSVP authentication
   and integrity procedures [RFC3209], [RFC3473]. If the operator is
   particularly worried, the control plane may be operated using IPsec
   [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]

   Protection against defective or rogue RSVP implementations is
   generally hard to impossible. Neighbor-to-neighbor authentication
   and integrity validation is, by definition, ineffective in these
   situations. For example, if a neighbor node sends a Resv during
   normal LSP setup, and if that message carries a GENERALIZED_LABEL
   object carrying an incorrect label value, then the receiving LSR will
   use the supplied value and the LSP will be set up incorrectly.
   Alternatively, if a Path message is modified by an upstream LSR to
   change the destination and explicit route, there is no way for the
   downstream LSR to detect this, and the LSP may be set up to the wrong
   destination. Furthermore, the upstream LSR could disguise this fact by
   modifying the recorded route reported in the Resv message. Thus, these
   issues are in no way specific to the restart case, do not cause any
   greater or different problems from the normal case, and do not warrant
   specific security measure applicable to restart scenarios.

   Note that the RSVP POLICY object [RFC2205] provides a scope by which
   secure end-to-end checks could be applied. However, very little
   definition of the use of this object has been made to date.

   See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS
   networks.

===
10.2. Informative References

Replace with...

   [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS
   Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work
   in progress.

   [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
   Roadmap," November 1998.

   [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
   Protocol," December 2005.

   [RFC4302] S. Kent, "IP Authentication Header," December 2005.

   [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2)
   Protocol", December 2005.

   [RFC4835] V. Manral, "Cryptographic Algorithm Implementation
   Requirements for Encapsulating Security Payload (ESP) and
   Authentication Header (AH)", April 2007.

---

From: Dan Li <[email-masked]>
Date: Mon, 19 May 2008 15:15:13 +0800

Hi Adrian,

Thanks for the very detailed comments!

> More importantly, management plane action is needed to clean up the
[Dan Li] Proposed text:
"In the event that Node B never restarts, management plane intervention is needed at Node A to clean up any LSP state restored from the management plane or from local configuration."

> described in the next section).
[Dan Li] Proposed text:
"...In this case, the Egress node may not aware of the LSPs...."

[SNIP]
>    definition of the use of this object has been made to date.

[Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205?

Thanks,

Dan

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 19 May 2008 08:42:58 +0100

Hi Dan,

Thanks for the speedy response.

Comments in line.

> "In the event that Node B never restarts, management plane intervention is 
> needed at Node A to clean up any LSP state restored from the management 
> plane or from local configuration."

Hmmm, maybe missed the point about the data plane?
How about...

In the event that Node B never restarts, management plane intervention is 
needed at Node A to clean up any LSP control plane state restored from the 
management plane or from local configuration, and to release any data plane 
resources."

> "...In this case, the Egress node may not aware of the LSPs...."

Well, I would suggest....

    In this scenario the Egress node (Node D) restarts, and its
    upstream neighbor (Node C) has not restarted. In this case, the
    Egress node may have no control plane state relating to the LSPs.
    It has no downstream neighbor to help it, and no management
    plane or configuration information, although there will be data plane
    state for the LSP. The Egress node must simply wait until its upstream
    neighbor restarts and gives it the information as Path messages
    carrying RECOVERY_LABEL objects.

> [Dan Li] Do you mean RSVP POLICY_DATA object described in RFC 2205?

Ah, yes. Good catch.

Cheers,
Adrian

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 23 May 2008 14:02:32 -0400

We completed the Last Call with comments incorporated in:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.t
xt
 
I'll do the document shepherding.
 
Thanks,
Deborah

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of BRUNGARD, DEBORAH A, ATTLABS
Sent: Tuesday, May 06, 2008 5:01 PM
To: [email-masked]
Subject: Working Group Last Call: draft-ietf-ccamp-gr-description-02

CCAMP,

 
Adrian and Deborah