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

[Dan Li <[e-mail]>]

Hi Adrian,

Thanks for the very detailed comments!

The proposed text for most of the editorial issues will be accepted in the next version. Still have several issues letf, and II proposed the text:
> ===
> 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.
> 
[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."

> ===
> 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).
> 
[Dan Li] Proposed text:
"...In this case, the Egress node may not aware of the LSPs...."

> 7. Security Considerations
[SNIP]
>    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.

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


Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[e-mail]>
To: "BRUNGARD, DEBORAH A, ATTLABS" <[e-mail]>; <[e-mail]>
Sent: Monday, May 19, 2008 5:13 AM
Subject: Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02


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