Subject: [secdir] draft-shiomoto-ccamp-switch-programming-05

From: Rob Austein <[email-masked]>
Date: Thu, 11 Aug 2011 01:40:42 -0400

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.

---

From: Tom Yu <[email-masked]>
Date: Mon, 22 Aug 2011 14:46:17 -0400

> sending data equates to turning on lasers.

I am not inclined to believe that this physical safety issue is
severe.  Having worked with lasers, though not network equipment that
uses them, I can say that good general laser safety practices should
substantially reduce the risk of injury to personnel.  (e.g., safety
eyewear; treating any aperture, fiber, etc. that is capable of
emitting a laser beam as if it could do so at any moment; putting beam
stops in place to protect against accidental exposure; etc.)

IMHO, if the physical safety of your personnel relies substantially on
the good behavior of some person or equipment located possibly
thousands of miles away, your industrial hygiene program could use
some improvement.

It may be that prevailing practices in the industry are not as
conservative, such that the advice about physical safety due to
unexpected laser activation is warranted.  (Are there operators here
who could comment?)  From a risk management perspective, I think it
would be better for an operator to institute better laser safety
practices locally.  I believe optical patch panels with integral beam
stops are available, for example.