Last Call Review of draft-shiomoto-ccamp-switch-programming-
review-shiomoto-ccamp-switch-programming-secdir-lc-austein-2011-08-14-00

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.

This draft is a bit of Talmudic commentary on the RSVP-TE scripture.
The draft at hand defines no new protocol, nor does it define any new
operational procedure.  Rather, it attempts to summarize and clarify
guidance from the existing specifications on the subject of when it is
"safe" to assume that Label Switched Paths (LSPs) have been set up on
the data plane and may be used for sending traffic.

The kicker here is the definition of "safe".  As the subject is
traffic engineering, loss of money and data are of course issues, but
the more disturbing issue is that (according to the authors -- I have
no reason to disbelieve them but have not independently verified this)
there is a risk of bodily harm to "service personnel", because, for
some of the technologies that use this protocol, deciding to start
sending data equates to turning on lasers.

As this draft defines nothing new, it would be hard to claim that the
risk factor here is this draft's fault.  The Security Considerations
section does call out the human safety issue, albeit briefly.

The discussion of the ResvConf message in section 3.3 is a bit odd.
It seems to be saying that waiting for the ResvConf message would be
an excellent way of being sure it's "safe" to start transmitting, but
that implementations should nevertheless not use this mechanism,
because it would be wasteful (ie, this is traffic engineering) and
unreliable (because many GMPLS implementations don't bother with this
message).  Given the human safety concerns raised in this draft I was
a bit surprised by this approach, I would have expected instead a
discussion of the merits of requiring implementations to support this
behavior so that it could be made mandatory.   But I could easily be
missing something here, as I'm not an MPLS expert.