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

Phillip Hallam-Baker <> Tue, 26 April 2016 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7135B12D14C; Tue, 26 Apr 2016 07:51:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IWo85FY5kLpF; Tue, 26 Apr 2016 07:51:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17DBF12B00C; Tue, 26 Apr 2016 07:51:27 -0700 (PDT)
Received: by with SMTP id u64so18884935lff.3; Tue, 26 Apr 2016 07:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=35cZv8VtD4qXvf8d7Rqc7crbMkA5W93dmhGCoBFcG/Y=; b=wuBDv3w75aMb5gVAeqCxU3Daf3MiWTI/+ja9aG2TIGm/FJi8SJRUYMc7BN7k/Fn2Td KaNssfHH46ithnbTNM3F4LI+QzWVzcsDspU5lYr72htX06O9m9pqeLjlPwdtCiDmfRQg 2+7a3jmWavSTvEIKKqlLun6qGwARq41ZQ7SWr/sMQS+QPq0pyLp21HKzRJxZZ+ayZXcV izC/nGzxXJazSdp+6FJg4ks+q1ix/+I3d/8ETqN/rsrjZ6/pwIgDY4qr+y9SIqSGsetj Nrf9cMVp1YDvt2EWO9jrEdKZAKeW2ut4yxVcsxnAPvsOpmlNN8hJob1N/PXLoC61b5sO yUVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=35cZv8VtD4qXvf8d7Rqc7crbMkA5W93dmhGCoBFcG/Y=; b=QW8m9quwWZy81lHFswLMq/Qmz57BPYLxFp1dqgJqK7Xi4Xq3+LwGV+jGihJJH4qTdt Piq0fDOjxJwHJUh8JJ6MhHwUtXb0eHhYBv3y4veBVYe75+xIQGS065t+A+fRomtNlVhV pyeQVkWi/C8f5Z3j6r+Nl92EWkHORBUD3++xOGzv4EJg8CBoRO2SD7bjgAOSFGyDTc/9 kRm+icNiOx2SzUqdOBZbUF9DPKrG7QBo2W5+52x5cMX76Z58V9KaYboopHkTNWd2mlIK AgLDaKDzZmBn0JfkGfblVl3KPXyEEzDn3JneOZoNhgcGvCXP+0aFtUZU3uY8Nu97rBEB qFGA==
X-Gm-Message-State: AOPr4FVWYxeM9zNWFeWywXU8+P44W3g/fQHmLDqdNdbevf0XG2+gLKbXITKLtmdwWWTodjO2DyGbLhhy2t6ZSg==
MIME-Version: 1.0
X-Received: by with SMTP id xp9mr1467674lbb.133.1461682285051; Tue, 26 Apr 2016 07:51:25 -0700 (PDT)
Received: by with HTTP; Tue, 26 Apr 2016 07:51:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 26 Apr 2016 10:51:24 -0400
X-Google-Sender-Auth: vKER1EHGJWeJ596HYUR0pihMPGM
Message-ID: <>
From: Phillip Hallam-Baker <>
To: "Andrew G. Malis" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:, "" <>, "" <>
Subject: Re: [secdir] SECDIR review of draft-ietf-pals-seamless-vccv-02
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 26 Apr 2016 14:51:29 -0000

Yes, I think that what is needed is IAB review of what is going on
rather than action on this particular draft.

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.

The security approach outlined in 5085 is mix and match with a large
dose of handwaving. It desperately needs to be reconsidered and a
security architecture written up. I don't think that you can expect
interoperability on the basis of that description.

The Snowden documents demonstrate that 'well managed enterprise
networks' are attacked on a daily basis and that this is the basis for
mass surveillance.

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.

That is the only way I could be confident that PRISM class attack
against the network had not been performed.

On Tue, Apr 26, 2016 at 10:18 AM, Andrew G. Malis <> wrote:
> Phillip,
> On behalf of the PALS WG, thanks for your review.
> To be clear, this sounds like more a comment on RFC 5085 than it does a
> comment on the draft in question. So is there any action requested regarding
> the draft?
> Also, you many not be aware that pseudowires are almost exclusively used in
> well-managed private enterprise services networks, usually either physically
> or logically separated from the public Internet for reasons of both traffic
> management and assurance to enterprise customers that their private traffic
> is well separated from the Internet. Thus interception is less a threat than
> it may be for protocols that are used in the public Internet.
> Thanks,
> Andy
> On Tue, Apr 26, 2016 at 8:48 AM, Phillip Hallam-Baker
> <> 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.
>> This document is an incremental change to a layer 2 virtualization
>> layer (Software Defined Networking). As such it properly references
>> RFC5085 for security considerations.
>> That said, I am a bit surprised at the security considerations in
>> RFC5085 which points out that denial of service is an issue but not
>> the introduction of a new set of opportunities for interception. This
>> is surprising given that BGP interception had already been used in
>> international hostilities when the RFC was published.
>> Further the proposed solution is to sprinkle on some magic IPSEC dust
>> or equivalent. While that might be an appropriate approach in an
>> experimental protocol, it is hardly adequate for a production protocol
>> with implications for Internet security as a whole.
>> Given the critical function of this layer and the date of its
>> inception, I would expect to see a comprehensive security architecture
>> developed as part of the overall scheme.