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

Stewart Bryant <stewart.bryant@gmail.com> Wed, 27 April 2016 09:45 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 AAC6E12D5E9; Wed, 27 Apr 2016 02:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 lyEjAdAI8Wnu; Wed, 27 Apr 2016 02:44:59 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 D969312D695; Wed, 27 Apr 2016 02:44:58 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id a17so8255180wme.0; Wed, 27 Apr 2016 02:44:58 -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:content-transfer-encoding; bh=xOBckTupv3g7Cw/gM9lNfl5IzMFXROvIu61WMBze7Cs=; b=upQo7qteVydMsanii2QrQDWOV+Ycy226AF0At5CfnWzEOqL0iayOWOUfGyYoGg3ULW 0VloJTRkkjaZeAx8p7mL+hsniFldUVtxKgEnzEvCXvrkLc99uF8O+0Qxpdads1Rdf/di /lQuM6Jxvb8Ru0OE/SNynH+5byfpXSJul03/Qs47mHn0ZsVd3I490mrXEmEXT7vvwkp0 HZEojKT2z/oUNAocR+hfHNfN+S2Q6rCfV73y4T58qvSmPtZcL7tu/G7uqyVuCKRxclHL UfpqdsiBMlFaVqYTLIZknbtUhrtRLAHAbLSWNpl99omJkOXYpPRha37iuvY3Dd37M4gv JMVw==
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:content-transfer-encoding; bh=xOBckTupv3g7Cw/gM9lNfl5IzMFXROvIu61WMBze7Cs=; b=f5XLe+gTHmOTp1HZ3xMK6kvrMPeoTw7y9sjVZQpw+5clh9KTpKF69YBGx1pUE18c6U UybrtPAzXGoP3YRxvLpDqbYJz9dDSqeUHTnEqLjE4i1n/UWOXk5WaoQS3w4r/x5B42rX z4lXSn5tsuxIvAtiBnO4+87Qft5ZLN6o8JpoWTVtAS44nJhAPJvV9k79FPiA/zKxCjO0 amkxScocx+nv5Mdpk66tPJZh41zA9WmDk0ZONhoSeuKP0pmNbFDWmg7KHaKLN66rCSw7 lnVC6MEf2+EGjq3lTToMo5eHJAw9Vaq050g3OTH7EeO73dGGu/EPSJ2rHJl/zI211F8R MRQg==
X-Gm-Message-State: AOPr4FXpdpJecQjIgFRuqh97UGt8V4/9dPzknkMHWHTRwTdOtf2awGP6Cx2drDFAneDJNg==
X-Received: by 10.194.111.199 with SMTP id ik7mr8969075wjb.150.1461750297352; Wed, 27 Apr 2016 02:44:57 -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 f11sm23059285wmf.22.2016.04.27.02.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Apr 2016 02:44:56 -0700 (PDT)
To: Phillip Hallam-Baker <phill@hallambaker.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
References: <CAMm+Lwho5C8JzQ92Nk4mQjjhwKG0gvus=xH5G0e6s9smEg=DNg@mail.gmail.com> <01160F37-0C73-42CE-AA8C-A09F876080A8@cisco.com> <CAMm+Lwhtuopf_yhhyWPfY0mDoU8bwt4HMb0OywD_9c7g5W+K0Q@mail.gmail.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <57208A16.5050602@gmail.com>
Date: Wed, 27 Apr 2016 10:44:54 +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+Lwhtuopf_yhhyWPfY0mDoU8bwt4HMb0OywD_9c7g5W+K0Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/EiwVHcLDHIl1tlkjIfKYEFzmVq8>
Cc: "draft-ietf-pals-seamless-vccv.all@ietf.org" <draft-ietf-pals-seamless-vccv.all@ietf.org>, "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: Wed, 27 Apr 2016 09:45:00 -0000


On 26/04/2016 15:57, Phillip Hallam-Baker wrote:
> On Tue, Apr 26, 2016 at 10:26 AM, Carlos Pignataro (cpignata)
> <cpignata@cisco.com> wrote:
>> Phillip,
>>
>> Many thanks for your review.
>>
>> As you rightly call out, this is indeed an incremental addition — I might add for emphasis a very incremental change.
>>
>> One point of clarification, however, is that this solution as defined does _not_ use BGP. The relevant control protocols’ security considerations are addressed in RFC 5085. This is not 'IPsec pixy-dust' — if you follow the pointers, you will get to the control connection (endpoint and message) security as well as protection for data plane spoofing.
>
> With respect, I disagree.
>
> A collection of pointers to a dozen other documents is not a security
> architecture.
>
> 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.

> This is layer 2 but the same security concerns apply. The fact that we
> have seen nation state actors use BGP injection attacks as tools of
> war demonstrate that this is a real concern.

I think you need to explain the attack scenario you have in mind.
>> In re-reading the Security Considerations section (thanks again for the review), I do believe there is an area of improvement: from RFC 5885, since these PWs specify single-hop adjacencies, the document ought to specify the use of GTSM for the IP/UDP encapsulations.
>>
>> I’ll be happy to add that in. Please let me know if you have any concerns with it.
> For an infrastructure of this scale, the security architecture should
> really be described in a separate document and at length.

Let's start with the MPLS variant. What do you think needs to be added 
to RFC5920, and what of that is explicit to PALS?

- Stewart