Last Call Review of draft-ietf-pce-pcep-domain-sequence-09
review-ietf-pce-pcep-domain-sequence-09-secdir-lc-wierenga-2015-11-12-00
Request | Review of | draft-ietf-pce-pcep-domain-sequence |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-11-09 | |
Requested | 2015-10-29 | |
Authors | Dhruv Dhody , Udayasree Palle , Ramon Casellas | |
I-D last updated | 2015-11-12 | |
Completed reviews |
Genart Last Call review of -09
by Joel M. Halpern
(diff)
Opsdir Telechat review of -09 by Nevil Brownlee (diff) Secdir Last Call review of -09 by Klaas Wierenga (diff) |
|
Assignment | Reviewer | Klaas Wierenga |
State | Completed | |
Request | Last Call review on draft-ietf-pce-pcep-domain-sequence by Security Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 12) | |
Result | Has issues | |
Completed | 2015-11-12 |
review-ietf-pce-pcep-domain-sequence-09-secdir-lc-wierenga-2015-11-12-00
Hi, 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. I consider the document “ready with issues”, see below for detailed comments: * 4.1 Inter-Area Path Computation you write: "This could be represented in the IRO as:” and then a number of diagrams. It is unclear to me whether those different option are functionally equivalent. The text suggests so to me, but that doesn’t seem to make sense….. (or I completely misunderstand the text) To me it seems that the three sequences you give are all possible sequences for the given topology not equivalent, I think the text needs some clarification in that case. The same goes for 4.2, 4.3 etc. * 4.5 P2MP I am guessing that the tree you show is the result of the three paths you give before, but some explanation would be good. 7 security considerations I think these are a bit weak. Especially compared to what RFC5440 provides. I consider an attacker gaining fine grained control over the network path a very serious risk. The flippant comment about “routing around trouble” doesn’t really do it for me. I would encourage you to take a good look at the security considerations in 5440 and assess how those considerations change given the finer grained control you provide. Some or even most may remain the same, and it is fine to say so, but I can imagine that some risks are higher because of the fine-grained control, and you seem to suggest so too given the “the security techniques in rfc5440 are considered more important”. So I really think this draft would benefit from a better security considerations section. Hope this helps, Klaas -- Klaas Wierenga Identity Architect Cisco Cloud Services