Skip to main content

Last Call Review of draft-ietf-rtgwg-mrt-frr-architecture-09

Request Review of draft-ietf-rtgwg-mrt-frr-architecture
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-01-29
Requested 2016-01-21
Authors Alia Atlas , Chris Bowers , Gabor Sandor Envedi
I-D last updated 2016-02-04
Completed reviews Secdir Last Call review of -09 by Christian Huitema (diff)
Opsdir Last Call review of -09 by Fred Baker (diff)
Opsdir Last Call review of -09 by Nevil Brownlee (diff)
Rtgdir Early review of -09 by Bruno Decraene (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-rtgwg-mrt-frr-architecture by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 10)
Result Has nits
Completed 2016-02-04
Hash: SHA1

I have reviewed this document 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.

The draft presents an architecture for quickly repairing routes after a link 
break or a node failure, in a network managed using OSPF or IS-IS.
Classic solutions repair the routing after routing updates propagate across 
the network, but in the interim the routing can be imperfect, with the 
possibility of micro loops causing local bouts of congestion. The proposed 
solution is to precompute two sets of "backup routes," to activate one of 
them immediately after failure, and to revert to shortest
path routing when the routing protocol has converged again. The architecture
draft provide justification and guidelines for implementing that solution.

The main focus of my review was the security aspects of the solution. From
that point of view, the document is ready for publication. 

On the other hand, I struggled with the prolific use of acronyms, some of which 
are not spelled out in the text. I wish this could be fixed.

This is an architecture document, and the security considerations are thus 
somewhat abstract. They point two potential issues: an attacker crafting
packet headers to send packets on the longer backup routes and thus 
creating extra load on the network; and an attacker injecting false 
"backup" information in the routing network to send some traffic through
an unexpected route where it could be inspected by a third party. I tried
to come up with different attacks, but the worse I can think off is an
attackers taking control of a router through a virus or a phishing attack.
Such attackers could certainly use the backup routing information in
creative ways, but then they could also do lots of damage by manipulating
the regular OSPF or IS-IS data. In short, I don't think that the addition
of backup routes opens big new risks, apart from the two listed in the
security considerations.

The document is generally well written but the authors have an annoying 
fondness for acronyms. Some of these acronyms, like the LDP in the title,
must be completely obvious for the WG members, but I had to actually
do a lookup to understand that this was about the Label Distribution 
Protocol used by MPLS. A bit later, I was really wondering what Forward
Error Correction had to do with the problem, until I realized that FEC
actually stood for Forward Equivalence Class. Most of the acronyms used
are spelled out the first time they are used in the text, which is good, 
but given the wide usage it would be even better if there was some kind
of lexicon. 

Also, it would be nice if there was some kind of "expected reading" at or
near the introduction, so the average reader could become familiar with 
the problem and the vocabulary before studying this document.

- -- Christian Huitema
Version: GnuPG v1
Comment: Using gpg4o v3.5.53.6558 -

Charset: utf-8




 Binary data