Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02

Stewart Bryant <stewart.bryant@gmail.com> Fri, 29 April 2016 09:19 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012D812B055; Fri, 29 Apr 2016 02:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NyTbUlOvseJK; Fri, 29 Apr 2016 02:19:55 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF6912D5D9; Fri, 29 Apr 2016 02:19:54 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id e201so19607047wme.0; Fri, 29 Apr 2016 02:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=lXhI8Pv+cs2vajkVBIBOa23xUsNuxmqx8hniiu9YRD8=; b=nbNmdrkg0hyBwarKKypZVes6kB0EGXEax4TOWc21JtyWtPMGFyGuz9bhbJ8LSLZaE3 KSmdRp/V6nKxdotiiIZpfm7tSVJIk012NE0OJhaDs4JpbQnOZYGKIVUDpZFVh+Cgm7ei f089ub6xfQMdafIh6TIUAGHsXw7E90OI5z2euGqM6Gi9l/MCUXz3J6NSKzPU35FOpGU/ nz0fr8aKy4pwxoiPhiRoPOf6Y8PJT298YM+OmetUt/mEneH9+C8j2fAWNI30Wj5CaF/D C+FV70Uj86MoK/Ox5M7Fgcm1viNZ3xO8zNX3HhDWZc5BdYLNeQkr5lGudr75pZV4LiWH 8irg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=lXhI8Pv+cs2vajkVBIBOa23xUsNuxmqx8hniiu9YRD8=; b=F/gxnWWl2Pz/js+kRklH2OiKFMY4zTh76rNwP6YT66eddYZLJ/YqkG8ZvRklaKWitb bOxP8Uk7+r0f/wEnXWjxFehIR4uQhv6iCbLtYElqsexNpAHRGAeJmoMMavygdcKsDfvM 5rLBsvLbdYI5k43JV2nG1ssn73FItWzjchw3Qyfss3+KT2Nj07cPXWDeTybRF+s0GGH1 pjDL51aVGZHycR9ZWI8er1UyNJBomS9mGiqJUwoI0zhy6I5FsOx7vhAQxAqmTAaTY8IB atuP/kjey1sfnENoGmG/JkQfAmkLkJOVNV3Oowp6523Oy2SHMybjBHSv9QkxjJG/VJjk he6Q==
X-Gm-Message-State: AOPr4FWnvCvNClQKPoGe2E2z1apxX06VIM/yUJ0ZJmOWxq2DhkzKEDEGKVV78oWzHGWv2A==
X-Received: by 10.194.205.167 with SMTP id lh7mr20475185wjc.30.1461921593526; Fri, 29 Apr 2016 02:19:53 -0700 (PDT)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id c194sm2347698wme.9.2016.04.29.02.19.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Apr 2016 02:19:52 -0700 (PDT)
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <CAMm+Lwho5C8JzQ92Nk4mQjjhwKG0gvus=xH5G0e6s9smEg=DNg@mail.gmail.com> <CAA=duU3uvJ+HOMvmgkCdn4dVQRHQus5XHSQd+RhDJTVpF1O5nw@mail.gmail.com> <CAMm+Lwi18cg66Yy_XY7QAOr0fBfC8oRY_2WTM_+NKu0xj08_Dw@mail.gmail.com> <57208701.2010209@gmail.com> <CAMm+LwiiBK4ZdT+CcF1nm240kAS4rgK71Pn9fmKG-53ssibBXg@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <57232736.60305@gmail.com>
Date: Fri, 29 Apr 2016 10:19:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAMm+LwiiBK4ZdT+CcF1nm240kAS4rgK71Pn9fmKG-53ssibBXg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010707070706070806050503"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/pZnI_dwUcnC7csXJIJ6DBHKXUCw>
Cc: draft-ietf-pals-seamless-vccv.all@ietf.org, "Andrew G. Malis" <agmalis@gmail.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 29 Apr 2016 09:19:58 -0000

I think we need to wind this discussion way back.

MPLS and PW (which can run over IP and well as a MPLS) are widely deployed
technologies. When running over MPLS PW inherits the MPLS security model.

If you think that MPLS needs to extend RFC5920, then that is a much bigger
discussion and one that you need take to the MPLS WG.

When using an IP transport, the security model belongs to the L2TPext WG
and that is a discussion you need to take to that WG.

This draft is a tiny extension to RFC5085, and I cannot see that it 
degrades the
security of RFC5085. As such we should note your points and move on.

The right way forward here is to take your concerns about the security
of pseudowires to the PALS, MPLS and L2TPext WGs as a wider concern and
not to hang them on this text.

Stewart


On 28/04/2016 20:37, Phillip Hallam-Baker wrote:
> On Wed, Apr 27, 2016 at 5:31 AM, Stewart Bryant 
> <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:
>
>
>
>     On 26/04/2016 15:51, Phillip Hallam-Baker wrote:
>>     Yes, I think that what is needed is IAB review of what is going on
>>     rather than action on this particular draft.
>     Sorry - what is the scope of your proposed IAB review?
>>     In particular, I don't consider a protocol suitable to be considered
>>     an IETF standard unless people can buy devices from multiple vendors
>>     and configure them to work together securely.
>
>     Sure, but I would like to see an evidence based assessment of the
>     specific
>     problem you are seeing in the field. So far none has been brought
>     to PALS (ne PWE3)
>     or MPLS as far as I am aware. Carlos can talk to L2TP, but again I
>     have not
>     heard of a specific problem ever being raised.
>
>
> The point of security considerations is that the onus is on the 
> developers to show that the system is secure.
>
> The documents I have read don't describe a coherent security 
> architecture. It seems to me that the security of the MPLS/SDN etc 
> world is something that hasn't really received the consideration it needs.
>
> A few years back we suddenly realized that BGP had no security model 
> and desperately needed one. The whole point of security considerations 
> was to try to avoid situations like that occurring. It seems we have 
> done the same thing in this space.
>
> The other issue is that security people probably should be looking at 
> layer 2 security because that is the only way to achieve protection 
> against certain mass surveillance attacks. It is a potential tool that 
> has been overlooked.
>
>
>     Right, but I cannot see why anyone would want to mass surveil the OAM
>     protocol, and we inherit the security enhancements to the underlying
>
>     data and control planes.
>
>
> The type of attack that would be of concern would be injecting 
> messages into the control plane to affect movement of packets. There 
> are games that can be played just by manipulating quality of service.
>
>>     I do not consider IPSEC to be a suitable security mechanism for this
>>     type of system. If I was given the design brief, I would insist that
>>     every message be authenticated by digital signature rather than a MAC
>>     and the control messages logged. I might use a MAC for
>>     pre-authentication to prevent DoS attack on the control plane. But the
>>     control messages should be fixed in non repudiable fashion.
>
>     We need to examine this statement in more detail to understand
>     which element
>     of the system you are concerned about. However please remember
>     that some
>     elements of the dataplane and OAM are cost and time sensitive.
>
>
> I am mostly interested in security of the control plane messages. 
> Though it might well be useful to consider the possibility of using 
> these infrastructures as a possible platform for building traffic 
> analysis resistant networks.
>
>
>     I am aware that this is not BGP which is a layer 3 switching protocol.
>
> I don't think anyone would describe BGP as a layer 3 switching protocol!
>
> It exchanges reachability information, it does not switch packets.
>
> I just did and I am right. The layer at which BGP data moves is pretty 
> much irrelevant to me. It could move out of band on carrier pigeon for 
> all I care. BGP is supplying the information that directs packets at 
> layer 3. Hence it is best viewed as a support protocol for layer 3.
>
> The ISO layered model isn't very helpful because it directs attention 
> to how packets move. Once you start on virtual links and quality of 
> service, you end up with nested stacks if you try to maintain 'layering'.
>
> This document has the title 'psuedowire' in the title. The protocol it 
> is describing creates a capability that has link-like nature. 
> Therefore from a security perspective we are talking layer 2 even if 
> you build this on layer 3.
>
> At that layer I am interested in service and traffic analysis attacks.