Last Call Review of draft-ietf-rtgwg-mrt-frr-architecture-09
review-ietf-rtgwg-mrt-frr-architecture-09-secdir-lc-huitema-2016-02-04-00

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.5.53.6558 - 

http://www.gpg4o.com/


Charset: utf-8

iQEcBAEBAgAGBQJWqv0vAAoJELba05IUOHVQMUUH/jtChUOM9wZkBgDKATsufdpH
do1g66lk8ZNfIufVRe8UVNm+668GJIbII4GDj6GUJHfbYMtVktSe3LPP0DG7hMl6
IFODITiycjgUmp0bA+ya63PA4Q4HgIqv4+ES2GZjoe2c0Kx1/qN2lNz2oIraqAJL
PYB2IrUBrRvMADseXipcq3nDQs6qbGsWWG/QsdXW9vX54AbI0UdV1MbkqlquGdgu
0CCbcH1IbQKsTWv1kewW5S4gwW+9/ksCJZSMlPCN4/L4F8kazJLBTxp2ecZJJo5V
/kS3aO/13l87mzpeBZsD5stCOVMZmW1g4V4MBlvpezol8JBXvdVyGXB82mrUE4w=
=1a4k
-----END PGP SIGNATURE-----


Attachment:


934309B255C80D72_huitema@huitema.net.asc




Description:

 Binary data