Skip to main content

Last Call Review of draft-ietf-pwe3-iccp-13
review-ietf-pwe3-iccp-13-secdir-lc-kelly-2014-02-19-00

Request Review of draft-ietf-pwe3-iccp
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-02-18
Requested 2014-01-30
Authors Matthew Bocci , Thomas Nadeau , Luca Martini , Samer Salam , Ali Sajassi , Satoru Matsushima
I-D last updated 2014-02-19
Completed reviews Genart Last Call review of -13 by Dan Romascanu (diff)
Genart Telechat review of -13 by Dan Romascanu (diff)
Genart Telechat review of -15 by Dan Romascanu (diff)
Secdir Last Call review of -13 by Scott G. Kelly (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-pwe3-iccp by Security Area Directorate Assigned
Reviewed revision 13 (document currently at 16)
Completed 2014-02-19
review-ietf-pwe3-iccp-13-secdir-lc-kelly-2014-02-19-00
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