Telechat Review of draft-ietf-pce-global-concurrent-optimization-
review-ietf-pce-global-concurrent-optimization-secdir-telechat-kaufman-2009-04-09-00

I am
reviewing 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. Feel free to forward to any appropriate forum.




 




This I-D defines some extensions to the protocol defined in
RFC 5440, and since those extensions do not affect the security sensitivity of
the protocol in any significant way, the document appropriately refers to that
one for Security Considerations.




 




That said, the Security Considerations section of RFC 5440
is somewhat dubious. It requires that implementations of this protocol MUST
support TCP-MD5 (RFC 2385) as a security mechanism, with recommendations that
they implement TCP-AUTH when it becomes available. It notes that TLS and IPsec might
be preferable at some point in the future if key management issues can be
resolved. TCP-MD5 (and its successor TCP-AUTH/TCP-AO) were developed to solve
some specialized problems associated with BGP – in particular, the
ability to maintain a TCP connection for an indefinite period (often counted in
years) surviving reboots of the endpoints. Its keying is manual, which quickly
becomes unworkable as the number of endpoints rises. In response, it is common
to use group keys (where the same key is used to protect all of the connections
within a realm). TCP-MD5 also provides no confidentiality of data, in spite of
the fact that this I-D says the data carried by this protocol may be somewhat
sensitive.




 




This reviewer believes that TLS or IPsec would have been a
better choice (and given the current state of the world, TLS would be the
better of the two), and that the developers of this protocol should consider
supporting one of those in the future. Manual keying could still be used with
those protocols, though it would be better to issue certificates to the various
endnodes. These certificates need not (and perhaps should not) chain to a
commercial root; they could be issued by the same administrators who today
configure the shared keys.




 




But… there is no reason to hold up approval of the
updates in this document. Protecting the protocol by authenticating the
endpoints and protecting the integrity of the data seems both necessary and
sufficient; I don’t see any need to include any other forms of security
analysis.




 




=====




I found the following minor (typo-level) issues:




 




p4 para 4 line 8: distributed -> distributing




p4 para 5 line 6: promote -> promotes




p5 para 2 line 10: preemption -> ??? (**I suspect you
didn’t mean preemption, but I can’t guess what word you meant)




p9 para 3 line 1: regards -> regard




p10 para 1 line 7: LSP -> LSPs (**though perhaps some
different wording change would be better)




p15 section 5.2 line 3: computation -> computations




p18 defn MU line 2: all link -> all links




p18 defn mU line 2: all link -> all links




 




There are several places (beginning with section 5.4 defn
Type) which read “To be defined by IANA (suggested value = 5)”.
Unless there are multiple revisions to this protocol going on in parallel (such
that the values assigned might depend on the order in which the documents are
advanced), I believe the normal protocol is for an I-D to just specify the new
value and repeat it in the IANA considerations section (which this document
does). That will minimize work for the RFC editor.