Skip to main content

Last Call Review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

Request Review of draft-ietf-teas-sr-rsvp-coexistence-rec
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-04-20
Requested 2018-04-06
Authors Harish Sitaraman , Vishnu Pavan Beeram , Ina Minei , Siva Sivabalan
Draft last updated 2018-04-26
Completed reviews Rtgdir Last Call review of -01 by Manav Bhatia (diff)
Opsdir Last Call review of -02 by Al Morton (diff)
Genart Last Call review of -02 by Joel M. Halpern (diff)
Secdir Last Call review of -02 by Hilarie Orman (diff)
Genart Telechat review of -03 by Joel M. Halpern (diff)
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-teas-sr-rsvp-coexistence-rec-02-secdir-lc-orman-2018-04-26
Reviewed revision 02 (document currently at 04)
Result Has Issues
Completed 2018-04-26
			  Security review of
   Recommendations for RSVP-TE and Segment Routing LSP co-existence

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

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

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 ...".