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

["Moriarty, Kathleen" <[e-mail]>]

Hello Dan,

Thank you for the update to the draft and response to my comments.  I'll have to read through the draft again to see why I thought labels changed.  If I find a specific point, I'll let you know so it could be clarified for other readers, but it may not be an issue.

I have a couple of responses below that start with KM>.

Thank you!
Kathleen

-----Original Message-----
From: Daniel King [mailto:[e-mail]] 
Sent: Thursday, February 20, 2014 5:21 PM
To: Moriarty, Kathleen
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Sec Dir review of draft-ietf-mpls-ldp-multi-topology-09.txt

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.  

KM> I agree there is no additional risk, the 'risk' is more the perception a reader may have if they see something is segregated and assumes that means it is secure.  The reader just needs to understand the points noted above so they are clear that the traffic may not remain segregated.

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. 

KM> Thank you!

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.

KM> OK, This was my first time through the draft and I'll go back to see why I came to that assumption.
 
> 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.