[secdir] Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

["Hilarie Orman" <[e-mail]>]

			  Security review of
   Recommendations for RSVP-TE and Segment Routing LSP co-existence
	      draft-ietf-teas-sr-rsvp-coexistence-rec-02

Do not be alarmed.  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.

When two independent protocols are used to manage bandwidth on one
shared link, the problem of efficient use of the total bandwidth
will depend on how much information the traffic engineering database
has about the utilization and reservations handled by the two
protocols.  This situation occurs when RSVP-TE and Segment Routing
LSP are used simultaneously.

The draft rules out centralized controllers for RSVP-TE as an option.
It also notes that the co-existence of two protocols might be a
temporary situation arising during a transition from RSVP-TE to SR
LSP.  This seems to imply that the recommendations are a stopgap
measure.

Although there is a claim of "no new security considerations", I think
that the proposed solution, of giving SR traffic demands the best
preemption priority in the network, could be a problem in terms of
covert channels and denial of service.  If the adjustments in the TED
result in any observable change in traffic patterns, then a malicious
party might be able to infer usage on an SR channel or even disrupt
the RSVP-TE channels by driving up demand on the SR channel.
Moreover, it might be possible to send the traffic management
algorithms into some kind of resonance crisis by increasing and
diminishing demand rapidly.  Although the proposed solution has
a damping factor, I would be concerned about systems operating
in parallel that might exhibit second order effects.

Could the draft address the security and stability concerns in
some reassuring way?  Like, "don't let this happen"?

In section 3.5, this sentence threw me for a loop:
   However, changing the maximum bandwidth for the TE link will
   prevent any compute engine for SR or RSVP to decipher the real
   static bandwidth of the TE link
After rereading it several times, I think that "decipher" has no
cryptographic significance and should be replaced by "determine"
or "measure", and rewritten in the form "will prevent any compute
engine ... from determining ...".

Hilarie