Skip to main content

Last Call Review of draft-ietf-pce-stateful-hpce-11
review-ietf-pce-stateful-hpce-11-secdir-lc-farrell-2019-08-27-00

Request Review of draft-ietf-pce-stateful-hpce
Requested revision No specific revision (document currently at 15)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-08-28
Requested 2019-08-14
Authors Dhruv Dhody , Young Lee , Daniele Ceccarelli , Jongyoon Shin , Daniel King
I-D last updated 2019-08-27
Completed reviews Rtgdir Last Call review of -10 by Tal Mizrahi (diff)
Secdir Last Call review of -11 by Stephen Farrell (diff)
Genart Last Call review of -11 by Paul Kyzivat (diff)
Assignment Reviewer Stephen Farrell
State Completed
Request Last Call review on draft-ietf-pce-stateful-hpce by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/J56ngChyqmcSAg51Ve9hWRoU7wc
Reviewed revision 11 (document currently at 15)
Result Has nits
Completed 2019-08-27
review-ietf-pce-stateful-hpce-11-secdir-lc-farrell-2019-08-27-00
Hiya,

This draft doesn't define new protocol but rather describes a way to use existing 
PCE stuff in what I guess is a new way. 

The nit I see is the usual, presumably fictional, reference to TCP-AO.  I mean, if
nobody actually does that, why bother? Esp. if you have a TLS option that's (I
hope) less fictional. (Is TLS less fictional for PCEP btw?) OTOH, I guess that
nearly everyone now knows that referring to TCP-AO is just a figleaf to try keep
security nerds happy, so maybe it's ok that we all suspend disbelief;-( 

Other than that, I did have two questions that occurred to me, but that are by 
no means a reason to hold up this draft - if answers required some action, it'd
almost certainly not be something that'd be fixed here. But I'm still curious:-)

1. Has anyone spent any significant amount of time/effort attempting to 
attack an H-PCE network  as a PCEP speaker? (And written that up:-) It 
looks to me like there're enough moving parts here that any real stateful 
hierarchical PCE  network could be fairly likely to have interestingly
exploitable problems in the face of such an attacker.

2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the 
ability to e.g. use different SubjectAltNames in x.509 certificates
might create the potential for some kind of deliberate or accidental
loops to be created somewhere. 

Again, there's no reason to hold this up to try answer (or even to
understand) those questions. I'd be happy to chat over a beer with 
someone  at IETF106 about 'em as that might be easier than a bunch 
of mail. 

Cheers,
S.