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