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

"Andrew G. Malis" <> Tue, 26 April 2016 14:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF6F812D1C9; Tue, 26 Apr 2016 07:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d14Rm2IoDtDX; Tue, 26 Apr 2016 07:18:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D17D12B065; Tue, 26 Apr 2016 07:18:48 -0700 (PDT)
Received: by with SMTP id tz8so7505743obc.0; Tue, 26 Apr 2016 07:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JJwP4aFdI8K46PV4rUt7WwGAlxbZL8Mt9edV54Ugc7c=; b=sKYQ/6zO0h+neJTt0rErd7gCc8P32dJVwXAUri360/6g+7F/UU5FqHAJPL/GpXtBpH 0+9ZI6XCfg49y+j48cLtPIlzQWxhHTZTSq5/WcmD6FDD3RrqOI3TUmaQaaobWCFXeYWD h1ekuj+HD5Km0yvTEBz5myEUKgn2lcroZ5Z20mJpXohFLcfoDC6tsUOSB86jCgQiZoU0 gA4AphoO0f6h9rdhUUiPlgGJ/1ZVrfSQEhtIRvIX2yGJdIcH5VQKqL5Yyl64BmD/QEEk 3aeYho3ZiMBi1+n+1rmBeYtnDnyMkug4vStWx31e0SgnUZhltUk1BtI4A2pLdZ+rOWBY ouFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JJwP4aFdI8K46PV4rUt7WwGAlxbZL8Mt9edV54Ugc7c=; b=ADuF9mH7lkJTyYCIgEZN9W79Iw8nm8bsb48pLi8DISTOcH0lTNi80tUY/vf/I3V2Mk WI40su9Ynppvzezcuqt7fBU22Bccexc1RT9sKHRIfMpQmAlHOUxdkIhxFBQRfGSKgTAX WMbyUvnKMVJZo3o6ykg725sbPfN71Y9Iiuw4DsrJMHdIZ6lQV9IsUWy5r8On9E29zVKc s/jCeel8/SBzg/vLNAEAEEGH8F9SvRjb8mt0i30WD+qgLvUOjIokLkm+OAirdwpPa8OC wTMsnkvKXYzTnc14MJtvhL7W58W61pQfUUkWEUjIUQla2tun1yX4kHxRfjeY2zy0Rho1 3UBQ==
X-Gm-Message-State: AOPr4FUw54NIL/Ky5rhu5kiXa8D6p471RADirHCNYYRjQAM+OF1I4cy/M9h6xsFwB/svQfSioCiEyFPaORNJ1w==
X-Received: by with SMTP id d9mr1190793obf.83.1461680327752; Tue, 26 Apr 2016 07:18:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Apr 2016 07:18:28 -0700 (PDT)
In-Reply-To: <>
References: <>
From: "Andrew G. Malis" <>
Date: Tue, 26 Apr 2016 10:18:28 -0400
Message-ID: <>
To: Phillip Hallam-Baker <>
Content-Type: multipart/alternative; boundary=001a11c2e558b60424053163f8ad
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:18:50 -0000


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


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.