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

Stewart Bryant <stbryant@cisco.com> Tue, 18 February 2014 17:08 UTC

Return-Path: <stbryant@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CFE1A04DE; Tue, 18 Feb 2014 09:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level:
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lguFPIb8iQW3; Tue, 18 Feb 2014 09:08:08 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF891A03F9; Tue, 18 Feb 2014 09:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3877; q=dns/txt; s=iport; t=1392743285; x=1393952885; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=VP+b1ucCdTBAHNFebpfyvJIOznoSJWl58hZ3Tv11eE4=; b=G5oryWSfK51vusaDGlCicneeFvF9uQDVgRQKqG5vU8CEoa9MBM1rW56S pORC4Px8UZnW22mY5vsWWmsedbhGj5Z8JahdXuB9KBDItcUGPun4O59PH vex+YLm1KpqVFiUhz4mMxxxglY7DVypg1uvKBjUbSXOEtZ6lV1iO3lQfv w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFAMaSA1OQ/khR/2dsb2JhbABZgwaEEblEgwqBGxZ0giUBAQEEIxVAEQsYAgIFFgsCAgkDAgECAUUGAQwIAQGIAaoWoggXgSmNAF+Cb4FJAQOYLJIjgy2BaA
X-IronPort-AV: E=Sophos;i="4.97,502,1389744000"; d="scan'208";a="5408427"
Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 18 Feb 2014 17:08:03 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IH820Y016748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 17:08:02 GMT
Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IH80U6022729; Tue, 18 Feb 2014 17:08:00 GMT
Message-ID: <53039370.4070707@cisco.com>
Date: Tue, 18 Feb 2014 17:08:00 +0000
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Scott G. Kelly" <scott@hyperthought.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-pwe3-iccp.all@tools.ietf.org
References: <1392310413.011331048@apps.rackspace.com>
In-Reply-To: <1392310413.011331048@apps.rackspace.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/HPyPiXEnPfLCSaziRs7q6QaPR9k
Subject: Re: [secdir] secdir review of draft-ietf-pwe3-iccp-13
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 17:08:13 -0000

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