Skip to main content

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