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

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 20 Apr 2018 15:34:47 -0600

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

---

From: Harish Sitaraman <[email-masked]>
Date: Thu, 26 Apr 2018 13:42:05 +0000

Hi Hilarie,

Thanks for the review. We've posted a -03 version of the draft. Let us know if it helps with your comments. See inline [HS]...

On 4/20/18, 2:35 PM, "Hilarie Orman" <[email-masked]> wrote:

    			  Security review of

    

[HS] Expanded on the Security considerations section.

[HS] Changed to the recommended text.
    
Harish

---

From: Hilarie Orman <[email-masked]>
Date: Thu, 26 Apr 2018 15:45:02 -0600 (MDT)

You have addressed each protocol separately, not the
combination.  However, the issues of denial-of-service and 
covert channels on shared infrastructure do not seem to be 
part of any previous security considerations, so I suppose 
it is unreasonable  to expect this draft to do so.  The 
situation is lamentable, but the draft is READY from my 
point of view.

Hilarie

----- Original Message -----
From: "Harish Sitaraman" <[email-masked]>
To: "Hilarie Orman" <[email-masked]>, "The IESG" <[email-masked]>, "secdir" <[email-masked]>
Cc: "draft-ietf-teas-sr-rsvp-coexistence-rec all" <[email-masked]>
Sent: Thursday, April 26, 2018 7:42:05 AM
Subject: Re: Security review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

Hi Hilarie,

    			  Security review of

    

    

Harish