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