[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Evaluation: draft-ietf-mpls-lsp-query - Multi Protocol Label Switching Label Distribution Protocol Query Message Description to Proposed Standard

Alex:


> I do not like the Abstract.  I propose:

>      This document describes the encoding and procedures for three
>      new Label Distribution Protocol (LDP) messages: Query Message,
>      Query-Reply Message and Partial Query-Reply Message. A Label
>      Edge Router (LER) sends a Query message when it needs information
>      about an established Label Switched Path (LSP). The Query message
>      can be used to request information about LDP LSPs as well as
>      Constraint-Based Label Switched Paths (CR-LSPs). The response to
>      the query is encoded into the Query-Reply and Partial Query-Reply
>      messages.

> The Introduction should be rewritten so that is does not depend on the
> Abstract to define terms.

OK, will work with the authors.

> In the security considerations, the document says:

>      The Query mechanism inherits the same security mechanism
>      described in Section 4.0 of [4].

> Section 4.0 of RFC 3036 is the IANA Considerations!  I assume that Section
> 5 should have been referenced.

Ditto

>   Further, section 5.1 of RFC 3036 discussed
> the TCP MD5 Signature Option.  This appear to be the only integrity
> mechanism available.  Since this protocol runs on top of TCP, why not
> discuss IPsec ESP and/or TLS?

Two data points here:

 1. It would probably be not correct for us to bring up the question
    of LDP security in general wrt this particular document that
    documents an extension to the protocol.

 2. See the discussion we had on BGP security, and the document Steve
    is working on to explain why TCP-MD5 is OK for BGP. LDP is
    basically in the same situation or even better, as LDP sessions
    are normally single-hop.
However, we agreed that if BGP was ever updated, then a more robust integrity mechanism ought to inserted. The same ought to apply here.

> Section 5 of RFC 3036 also said that the peers need to be trusted to label
> properly.  What are the impacts on these new protocol messages if this
> trust is misplaced?  This topic should be discussed in the security
> considerations section.

What do you mean by "trust is misplaced"? That we mistakenly trust a
compromised peer?
If a peer does mislabel, what are the consequences? Can an inappropriately labeled message cause a bad state? And, if so, will this bad state be passed on to other peers.

Russ