Subject: [secdir] secdir review of draft-ietf-mif-mpvd-arch

From: Sean Turner <[email-masked]>
Date: Wed, 18 Feb 2015 09:17:01 -0500

Fear not as this is just the secdir review!

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 with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Ready with nits.

Nits:

0. s1.1: This section can be removed because there’s no 2119-language in the draft, but that can be done by the RFC editor later.

1. s3.5: Somebody once suggested adding an IKEv2 payload for configuration data and got their head handed to them.  I guess it’s fine to leave the paragraph in the draft because this is just a possible solution, but I’d not count on it as a viable option.

2. s4.2: Makes me think of Fernado’s VPN leaks RFC: http://datatracker.ietf.org/doc/rfc7359/.

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.

spt

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Feb 2015 13:00:26 -0500

> 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 l…

I think you may have used the wrong preposition here, and consequently I'm having trouble parsing this.   Can you restate?

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Feb 2015 09:53:26 -0500

Sean & Ted,

Sean, thank you for your review of the draft!

On Wed, Feb 18, 2015 at 1:00 PM, Ted Lemon <[email-masked]> 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