Re: [secdir] secdir review of draft-ietf-mif-mpvd-arch
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 19 February 2015 14:53 UTC
Return-Path: <kathleen.moriarty.ietf@gmail.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 345CA1A1AC6; Thu, 19 Feb 2015 06:53:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] 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 Dck1Tdd5YTbL; Thu, 19 Feb 2015 06:53:32 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 CD5461A001C; Thu, 19 Feb 2015 06:53:27 -0800 (PST)
Received: by lbvp9 with SMTP id p9so265146lbv.3; Thu, 19 Feb 2015 06:53:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/m9o1pS0NhhEgqKeVjDOU5tMYQ2ypYrv01vvTaGuIKM=; b=01zl2kaYJzk8xv79PqtuRGTjWQh0OX4OJJFweF4/apM43SrrcN30mGXs8MuaiClv98 LGxyLqT22yR1ynf+YS0VmUHxJwaFWWX0sPVtgEn0Jjsa9GK2Z9CXAaOB4Af/3oqQynkb 1+h9HA+rfxS8EGRa9EydEna+eHnuYIgvTZshBEnMGS91grFarGu/lYbHYC6wc6qMpp8s dUmyTreZEx5GCF/4IiCmCY0ykLu/mZuCPRgva5eqL0vNUQPjnd0RdCAHB5Fekg8qzDs7 AH5yf5d7yLkLeGCYYlzRAL7iKGqtCnjJFWYjtjAllPZua8Tya29BNmR5KhorNbvlPA8T zJHg==
MIME-Version: 1.0
X-Received: by 10.152.183.165 with SMTP id en5mr4534608lac.0.1424357606306; Thu, 19 Feb 2015 06:53:26 -0800 (PST)
Received: by 10.112.167.101 with HTTP; Thu, 19 Feb 2015 06:53:26 -0800 (PST)
In-Reply-To: <008B9168-0AF1-4AE5-A316-4EEBD97C63FD@nominum.com>
References: <79A24849-274F-4E45-BDED-1EE103D484B8@ieca.com> <008B9168-0AF1-4AE5-A316-4EEBD97C63FD@nominum.com>
Date: Thu, 19 Feb 2015 09:53:26 -0500
Message-ID: <CAHbuEH4Y1tzM2=n=s-VTv-XG8euY867ngysgbSf_3okjFyLDeg@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Content-Type: multipart/alternative; boundary="001a1134573c283945050f721976"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Na-wTxissq15Fu8I73eLJe_lAiw>
Cc: draft-ietf-mif-mpvd-arch.all@tools.ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-mif-mpvd-arch
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Thu, 19 Feb 2015 14:53:34 -0000
Sean & Ted, Sean, thank you for your review of the draft! On Wed, Feb 18, 2015 at 1:00 PM, Ted Lemon <Ted.Lemon@nominum.com> wrote: > On Feb 18, 2015, at 9:17 AM, Sean Turner <turners@ieca.com> wrote: > > 3. s5.2.1: Makes me hope that the if there’s two connections and one is > a VPN that lookups meant for that connection is only done over that > connection and not leaked out. I think this is covered later in the > section though. > > I think you may have used the wrong preposition here, and consequently I'm > having trouble parsing this. Can you restate? > I'm reading the text in 4.2 as addressing the concern in 5.2.1 that Sean raises. Yes, I agree on the comparison to the VPN leak RFC, but having this statement prevents the need for a similar on on this topic. The routing to IP addresses reachable within this PvD will be set up via the VPN connection, and the routing of packets to addresses outside the scope of this PvD will remain unaffected. But in 5.1, you may need a clause at the end of this sentence to make sure the same PvD is used to prevent such issues (it is implied, but may be better stated explicitly). From: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to. Such creation / augmentation of PvD(s) could be static or dynamic. To: As an example, a node administrator could inject a DNS server which is not ISP-specific into PvDs for use on any of the networks that the node could attach to via the same PvD. Such creation / augmentation of PvD(s) could be static or dynamic. For Sean's comment on 5.2.1, I think the above modified text in combination with this text in 5.2.1 (plus what's in 4.2) is sufficient to address the concern. In either case, by default a node uses information obtained via a name service lookup to establish connections only within the same PvD as the lookup results were obtained. For clarification, when it is written that the name service lookup results were obtained "from a PvD", it should be understood to mean that the name service query was issued against a name service which is configured for use in a particular PvD. In that sense, the results are "from" that particular PvD. -- Best regards, Kathleen
- [secdir] secdir review of draft-ietf-mif-mpvd-arch Sean Turner
- Re: [secdir] secdir review of draft-ietf-mif-mpvd… Ted Lemon
- Re: [secdir] secdir review of draft-ietf-mif-mpvd… Kathleen Moriarty