Re: [secdir] Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt

["Daniel King" <[e-mail]>]

Dear Kathleen,

Thank you for your review of draft-ietf-mpls-ldp-multi-topology-09. We have
updated the document to address a number of comments, including your Sec Dir
review:

http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-11

Please see our specific responses and/or how addressed your comments inline
("Authors:") below:

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Moriarty, Kathleen
> Sent: 03 November 2013 23:27
> To: [e-mail]; [e-mail]; draft-ietf-mpls-ldp-multi- 
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt
> 
> 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.
> 
> Review:
> It is unclear to me how there could not be any security 
> considerations.  The
draft
> introduces the ability to segregate traffic, allowing for the MT 
> capability to
be
> supported and then transitioned to equipment where the capability is 
> not supported.  See section 3.2:
> 
> If an LSR is changed from IGP-MT capable to non-MT capable, it may
>       wait until the routes update to withdraw FEC and release the label
>       mapping for existing LSPs of specific MT.
> 
> The introduction states this feature may be used to segregate traffic 
> for
different
> purposes, including the use of management traffic.  Typically, 
> management
traffic
> requires security protections such as session encryption.  The 
> labeling also appears to allow for labels to change in addition to the 
> feature support disappearing.  The security considerations should at 
> least mention that no additional protections are offered through this 
> mechanism of segregating
traffic,
> so that the reader is informed of this risk.  The advantages may be 
> limited to
QoS
> and other possible benefits.  Users should be aware that the 
> segregation
offers
> no security advantage over MPLS without MT.

Authors: Thanks for your comments and as you suggest we have updated the
Security section to state that MPLS MT does not offer any additional
security over MPLS. Although we do not believe that the reader needs to be
informed of any "risk" because we do not believe there is any additional
risk.  

MPLS security, as discussed in RFC5920, is split into two items: control
plane security and data plane security: 

- For the control plane (and our document is chiefly about the control
plane) the security relies on the security provided for LDP; LDP runs over
TCP so it can leverage TLS and TCP/AO.  

- The MPLS data plane is not secure and it is the responsibility of the
application to secure its traffic as necessary (e.g., running management
traffic over IPsec tunnels).  We believe that the document makes no change
to those basic concepts. However, we have clarified the Security section and
included a reference to RFC5920 to assist/remind the reader. 

Also, we would like to underline that when MT support is withdrawn, there is
no change in labeling. We have documented that when an LSR stops supporting
MT, the LSPs that exist for non-default topologies must be torn down
(because they are no longer supported) and this should be done by
withdrawing the labels that were advertised for the other topologies.

 
> Editorial nits:
> 
> In Introduction, change from isolated to isolate:
> Separate routing and MPLS domains may be used to isolated
>       multicast and IPv6 islands within the backbone network.
> 
> To: Separate routing and MPLS domains may be used to isolate
>       multicast and IPv6 islands within the backbone network.

Authors: Thanks, updated. 
 
> Change Carries to carry:
>  Management traffic could be separated from customer traffic using
>       multiple MTs, where the management traffic MT does not use links
>       that carries customer traffic.
> To:  Management traffic could be separated from customer traffic using
>       multiple MTs, where the management traffic MT does not use links
>       that carry customer traffic.
> 
> Section 3.6: Change "imply" to "simply":
> Since using different label spaces for different topologies would
>    imply significant changes to the data plane, a single global label
>    space is supported in this solution.

Authors: Thanks, but this was intended so left. 

> Change "peer" to "peers":
> There will be one session
>    supported for each pair of peer, even there are multiple topologies
>    supported between these two peers.
> 
> Section 4.3.4:
> Change from:
> For the case that the LSP ping with return path not specified , the
>    reply packet must go through the default topology instead of the
>    topology where the Echo Request goes through.
> To: For the case that the LSP ping with return path is not specified, the
>    reply packet must go through the default topology instead of the
>    topology where the Echo Request goes through.

Authors: Thanks, updated.
 
> Section 5.1:
> Recommend breaking this text into multiple sentences.

Authors: Thanks, updated.
 
> Section 6:
> Change from:
> In case the bad things does happen, according
>    to [RFC5036], processing of such message should be aborted.
> To: In case the bad things happen, according
>    to [RFC5036], processing of such messages should be aborted.

Authors: Thanks, updated.

> Section 7: I recommend breaking the second paragraph into multiple
sentences.

Authors: Thanks, updated.

> Best regards,
> Kathleen

Again, thank you for your valuable comments and suggestions. 

Br, Dan & Authors.