Re: [secdir] secdir review of draft-ietf-pwe3-iccp-13

[Stewart Bryant <[e-mail]>]

On 13/02/2014 16:53, Scott G. Kelly wrote:
> 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.
>
> I'm sorry that this review is a few days late. From the abstract:
>
>     This document specifies an inter-chassis communication protocol
>     (ICCP) that enables Provider Edge (PE) device redundancy for Virtual
>     Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS)
>     applications. The protocol runs within a set of two or more PEs,
>     forming a redundancy group, for the purpose of synchronizing data
>     amongst the systems. It accommodates multi-chassis attachment circuit
>     as well as pseudowire redundancy mechanisms.
>   
> So, it's a redundancy protocol between provider edge devices. The document is long (81 pages), and not having been a participant in the wg, I encountered a lot of unfamiliar territory.
>
> The document presents 4 different interconnect scenarios for PEs (provider edge devices), as they are called. The security considerations section says that the security considerations in RFC5036 (LDP) and RFC4447 (Pseudowire Setup and Maintenance Using LDP) apply, and goes on to say that the ICCP protocol (which runs between the PEs) is intended to be restricted to a single administrative domain.
>
> The security considerations section goes on to talk about the need for policy configuration, and recommends that implementations provide control-plane policing to mitigate various attacks.
>
> I have to admit that I only have a limited understanding of this protocol, and this review should be taken accordingly. Zooming up to a 20000` level, I see that there is a group, and that this protocol allows a device to join and participate the group.
>
> The 4 different interconnect scenarios have different security properties/considerations. The first one (co-located dedicated interconnect) allows assumptions about physical security. The second and fourth have the PEs communicating via shared fabric ("Core Network"). The third has a dedicated interconnect which may allow assumptions about connection security.
>
> So, the questions I think of are these:
>
> - what are the potential consequences of an unauthorized join?
>
> - if any of these are a concern, then how do I prevent unauthorized joins?
>
> - assuming unauthorized joins are prevented, what are the potential consequences of interfering with traffic?
>
> - if any of these are a concern, then how do I detect/prevent these?
>
> In the case relying on physical security and/or a dedicated link (first/third), these can all be addressed by securing the physical link. In the other two cases, we either need protocol mechanisms, or we need assumptions/methods relating to the core network.
>
> Since the security considerations section points at RFCs 5036 and 4447, I went and looked at those. They talk about LDP and MPLS security, but the mechanisms they are using are ip address filtering and MD5 authentication. Under some assumptions for the core network, these may be fine, but under others (e.g. a potentially hostile core network), they are not.
>
> These are the things that occurred to me, as an outside observer who read the draft once.
>
> --Scott
>
>
> .
Scott

Thank you for the review.

MPLS signalling is only used in well managed and highly monitored networks
so an attempt by an attacker to join would be noticed. However to 
attempt the
join the attacker would first need to breach the physical and packet 
filtering
security measures.

This would not be deployed on or over the public Internet.

Stewart