Re: [secdir] comments on draft-ietf-rtgwg-ipfrr-framework-12

[mike shand <[e-mail]>]

Thank you for your comments. We propose to address them as follows. 
Please see inline.

Sandra Murphy wrote:
> I am reviewing this document draft-ietf-rtgwg-ipfrr-framework-12 as 
> part of the security directorate's ongoing effort to review all IETF 
> documents being processed by the IESG.  These comments were written 
> primarily for the benefit of the security area directors.  Document 
> editors and WG chairs should treat
> these comments just like any other last call comments (that you
> received well after last call). Feel free to forward to any 
> appropriate forum.
>
> This draft describes a framework for mechanisms to  compute backup 
> "repair" paths that allow traffic to continue to forward to the 
> destination around failed links or nodes.  This is similar to a
> mechanism in MPLS to provide backup LSPs by using RSVP-TE.
>
> For background, I also looked at
> RFC4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels
> RFC 5296 Basic Specification for IP Fast Reroute: Loop-Free Alternates
> draft-ietf-rtgwg-lf-conv-frmwk-06 A Framework for Loop-free Convergence
> draft-bryant-ipfrr-tunnels-03 IP Fast Reroute using tunnels
> draft-ietf-rtgwg-ipfrr-notvia-addresses-03 IP Fast Reroute Using
>                 Not-via Addresses
>
> The security considerations covers some concerns introduced by using 
> fast-reroute mechanisms where providing repair paths may introduce
> vulnerabilities, particularly where the repair paths could interfere
> with existing robustness mechanisms (reverse path forwarding and
> TTL limits).

Our assumption is that there are no document actions above this point.
>
> I wonder if the knowledge of computed repair paths could
> be useful to an attacker in doing traffic-shaping, i.e., an attacker who
> was doing link-cutting to affect traffic flow.  Similarly, the ability
> to influence the computation of the repair path could be valuable.
> Perhaps the framework document could mention that the proposed solutions
> should consider the need to protect the computation from exposure (to the
> same extent infrastructure information is protected from exposure) and
> corruption/contamination if such an attack were a concern.
These considerations are equally applicable to routing protocols in 
general and it does not seem appropriate to conduct a detailed analysis 
in this document.

>
> Note:
> RFC5286 dismisses this concern, without noting the benefit of an
> attacker to be able to producing a desired forwarding change if a
> failure (and therefore repair activity) could be induced:
>
>    Traffic to certain
>    destinations can be temporarily routed via next-hop routers that
>    would not be used with the same topology change if this mechanism
>    wasn't employed.  However, these next-hop routers can be used anyway
>    when a different topological change occurs, and hence this can't be
>    viewed as a new security threat.
>
> The notvia-addresses draft does seem to recognize this risk from repair
> paths:
>
>    The repair endpoints present vulnerability in that they might be used
>    as a method of disguising the delivery of a packet to a point in the
>    network.
>
> The loop-free convergence framework draft in the last-called version
> said:
>
>    All micro-loop control mechanisms raise significant security issues
>    which must be addressed in their detailed technical description.
>
> which I thought should be reflected in this framework,
> but that has changed in the post-last-call version to:
>
>    This document analyzes the problem of micro-loops and summarizes a
>    number of potential solutions that have been proposed.  These
>    solutions require only minor modifications to existing routing
>    protocols and therefore do not add additional security risks.
>    However a full security analysis would need to be provided within the
>    specification of a particular solution proposed for deployment.
>
> I'm curious as to how "significant security issues" changed to
> "do not add additional security risks", but I don't have the time
> to track down the last call comments that created that change.
The original statement was just a place-holder held over from the first 
draft of the document.
>
> (I'd say that adding any additional information to a routing protocol
> may not change the underlying vulnerabilities of the routing protocol
> but certainly provides new means to cause damage when exploiting the
> known vulenrabilities.)
>
> Non-security related comments:
>
> The following comment would have been useful to see before section 6:
>
> 6.  Scope and applicability
>
>    The initial scope of this work is in the context of link state IGPs.
>    Link state protocols provide ubiquitous topology information, which
>    facilitates the computation of repairs paths.
We have moved this after the introduction.
>
> The following comment would have been useful to see before section
> 4.2.5:
>
>    Complete protection against multiple unrelated failures is out of
>    scope of this work.
>
We have copied this to the scope and applicability section.

> Some terms in this document are never defined and/or used ambiguously.
>
> The following terms are not in the terminology list:
> repair path
We have added a definition:-
"The path used by a repairing node to send traffic that it is unable to 
send via the normal path owing to a failure."
>
> Shared Risk Link Groups (SRLG) - perhaps so common in the teleco world
>     and in optical networks that definition was judged unnecessary.
We think this is well known
>
> "link(node) protecting" "being protected" "fully protected 
> (link/node)" "unprotectable" - it would seem to refer to a link or node
>   failure for which a repair path is being computed, but may also mean
>   mechanisms to avoid micro-loops.
In the context of this document they all refer to path protection. This 
doesn't seem to need any further clarification.
>
> a path being "affected" by a reconvergence - which I think means that
>   reconvergence to a new forwarding tree does not change any link
>   in the repair path
Yes.  A path not being affected means that there is no change to the 
path as a result of re-convergence of routers along the path.
>
> a repair path being "valid for a node" or "valid for destinations"
Valid means that it is a functioning repair path. A repair path may be 
valid for a link failure, but not for a node failure.
>
> Some text I found confusing:
>
> Page 7:
>
>    2.  In topologies that are susceptible to micro-loops, a mechanism to
>        prevent the effects of any micro-loops during subsequent re-
>        convergence.
>
> Because the loop free convergence draft distinguishes micro-loop 
> prevention
> from micro-loop suppression, which attempts to avoid the impact on other
> traffic from micro-loops, I thought "the effects of any micro-loops"
> referred to this collateral damage.  But later in that page it talks
> about micro-loop avoidance, which sounds like the loop free convergence
> draft's term "micro-loop prevention".  So I'm not sure what is meant 
> here.
We have revised this read:-

"In topologies that are susceptible to micro-loops, a micro-loop control 
mechanism may be required" and inserted a reference to the loop free 
convergence framework.
>
> Page 10:
>
>   1.  The percentage of links (or nodes) which can be fully protected
>        for all destinations.  This is appropriate where the requirement
>        is to protect all traffic, but some percentage of the possible
>        failures may be identified as being un-protectable.
>
>
> What does it mean to be "fully protected for all destinations"?  Is that
> redundant?  And what about "unprotectable"?  Is it possible to have
>   fully protected for all destinations
>   fully protected for some destinations
>   partially protected for all destinations
>   partially protected for some destinations
>   unprotectable for all destination
>   unprotectable for some destinations
> etc.?
Yes. We have revised the text to read :-

1. The percentage of links (or nodes) which can be fully protected (i.e. 
for all destinations). This is appropriate where the requirement is to 
protect all traffic, but some percentage of the possible failures may be 
identified as being un-protectable.

2. The percentage of destinations which can be protected for all link 
(or node) failures. This is appropriate where the requirement is to 
protect against all possible failures, but some percentage of 
destinations may be identified as being un-protectable.


>
> The outline in section 4 has me a bit confused:
>    4.  Mechanisms for IP Fast-reroute . . . . . . . . . . . . . . . .  7
>      4.1.  Mechanisms for fast failure detection  . . . . . . . . . .  7
>      4.2.  Mechanisms for repair paths  . . . . . . . . . . . . . . .  8
>        4.2.1.  Scope of repair paths  . . . . . . . . . . . . . . . .  9
>        4.2.2.  Analysis of repair coverage  . . . . . . . . . . . . .  9
>        4.2.3.  Link or node repair  . . . . . . . . . . . . . . . . . 10
>        4.2.4.  Maintenance of Repair paths  . . . . . . . . . . . . . 11
>        4.2.5.  Multiple failures and Shared Risk Link Groups  . . . . 11
>      4.3.  Local Area Networks  . . . . . . . . . . . . . . . . . . . 12
>      4.4.  Mechanisms for micro-loop prevention . . . . . . . . . . . 12
>
> Section 4.2.5 covers SRLG's as an example of multiple related failures,
> which it says are out of scope.  Then section 4.3 covers LANs - which
> would seem to me to satisfy the definition of a SRLG.  Is 4.3 supposed
> to be a subtopic under 4.2.5?  It seems out of keeping with the
> mechanism focus of sections 4.1, 4.2 and 4.4.
>
> Also, 4.3 says:
>
>    Protection against partial or complete failure of LANs is more
>    complex than the point to point case.  In general there is a trade-
>    off between the simplicity of the repair and the ability to provide
>    complete and optimal repair coverage.
>
> (That's a complete quote of that section, which is another reason for
> asking if it is really supposed to be a separate section)
>
> Does this imply that all previous discussion was about point to point
> links only?

We have moved section 4.3 to become 4.2.5 leaving the SRLG section as 4.2.6
>
>
>
> RFC 5286 has an extended discussion of computing backup paths for
> broadcast and NBMA links, so I was surprised to see this draft seem
> to indicate that LANs were out of scope.

They are not out of scope, but they do require special consdieration in 
the context of each repair mechanism.



    Mike & Stewart
>
>
>
>
>
> --Sandy Murphy
>