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

[Harish Sitaraman <[e-mail]>]

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" <[e-mail]> wrote:

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

[HS] Expanded on the Security considerations section.
    
    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 ...".

[HS] Changed to the recommended text.
    
Harish