Re: [IPsec] New Version of Split DNS for IKEv2

Daniel Migault <daniel.migault@ericsson.com> Tue, 13 December 2016 18:47 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46149129472 for <ipsec@ietfa.amsl.com>; Tue, 13 Dec 2016 10:47:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sAe313Zvy570 for <ipsec@ietfa.amsl.com>; Tue, 13 Dec 2016 10:47:00 -0800 (PST)
Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 20BD7129492 for <ipsec@ietf.org>; Tue, 13 Dec 2016 10:47:00 -0800 (PST)
Received: by mail-io0-x241.google.com with SMTP id y124so30557538iof.1 for <ipsec@ietf.org>; Tue, 13 Dec 2016 10:47:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PrhXMpEbNY9NmxwC/BLl9HZ19ZtVIWY80tCPtypXmtU=; b=Ta5f1oFwRLJel+5iybDRinSrgnGCrmCJJKSwvo3RbSIuDLYbGeKt/8xFz3K2RYBgBH rgwbkXb3E6fzgxZ61a3lQidEfBldzN00SNfpxEejNim2keitqdTGPry+dDbbeAxfCu+Z gDBhcBuEG67WqYGjZ6jWqonVMKZEzTdH9vYocNJZJa53Ip0Adf35MNaP/1QFsZlf7yaq p70KC4oJaCrYYuzRuIDJm9sDa/8BOZd/u++O+SemxazwGB9q9UGAnMYpTNPeL7eqNT4C TiZ0gmSM4TrjmfZ4gq/umCUeivmVEqlwZw77n0kwd0ViVJV3hinwcdJuLDHcEGRmA4Fm yr2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PrhXMpEbNY9NmxwC/BLl9HZ19ZtVIWY80tCPtypXmtU=; b=QZDN/p8BKtV7pa3YERYDxK7T+ZfnTDufDMO0zwhkaM23+q/2y11EhSs5qY/kJ77arv Z2CvyAXewVu1NVyXnwpJbwKoj+nNc66UbKUJVH0bSLDixCk8PQp8+ObUlVUCUQhUNfne JF6u2bJoUgmyvmBOZBx7/3+J0Pmaqqj3LziSw1qBm6waLIl1aqyZsP20vNmtEhZEpezk Ygjebnki0OGlOBEC+k2sVqX6mZY3bmbOZJnj00GwN5V5ERrfosUPMOvfGLc10RoV/MZD rRtaJUBpEzZy7dEKEyy/hb8kWYVa8dWP3r8v+6GtGwAsFgMvuCFbNksrzke4CkgB9OXP 1Xhg==
X-Gm-Message-State: AKaTC01k6RLMSPILk2eils+/CWK/TZO5N3VAhVQ34mT5LgxWFnvBAGYwZ4PPFnILemqNpdIRGiqBqzmlS0pI7A==
X-Received: by 10.107.44.5 with SMTP id s5mr88816547ios.10.1481654819317; Tue, 13 Dec 2016 10:46:59 -0800 (PST)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.107.59.214 with HTTP; Tue, 13 Dec 2016 10:46:58 -0800 (PST)
In-Reply-To: <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com>
References: <147448964321.14590.5635818993002735779.idtracker@ietfa.amsl.com> <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Tue, 13 Dec 2016 19:46:58 +0100
X-Google-Sender-Auth: a_VkIUG4-H2v3kDx15XtmtqsykM
Message-ID: <CADZyTkk4HChhm=WDSZxRdU5fpXoY6st8EZBXKgVAYga8KWf=6g@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Content-Type: multipart/alternative; boundary="001a113944902f6c0205438ea545"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/5x2y4FZQ-k6K38EDArhljQIAsnE>
Cc: IPsecME WG <ipsec@ietf.org>, Paul Wouters <paul@nohats.ca>, Paul Hoffman <paul.hoffman@vpnc.org>, Tero Kivinen <kivinen@iki.fi>
Subject: Re: [IPsec] New Version of Split DNS for IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 18:47:03 -0000

Hi,

Please find my comments on draft-pauly-ipsecme-split-dns-02.

Yours,
Daniel


3.  Protocol Exchange

3.1.  Configuration Request

   An initiator MAY convey its current DNSSEC trust anchors for the
   domain specified in the INTERNAL_DNS_DOMAIN attribute.  If it does
   not wish to convey this information, it MUST use a length of 0.

MGLT: I think a high level explanation may be needed for the reader to
understand why the initiator provides the trust anchor but maybe that is
the responder and not the initiator.


3.2.  Configuration Reply

   For each DNS domain specified in an INTERNAL_DNS_DOMAIN attribute,
   one or more INTERNAL_DNSSEC_TA attributes MAY be included by the
   responder.  This attribute lists the corresponding DSSNEC

MGLT: DNSSEC

   trust
   anchor in the DNS wire format of a DS record as specified in
   [RFC4034].

MGLT: I think that is te first time in the draft that mentions the TA is in
fact the hash of it. That is fine, but maybe that could be mentioned
earlier in the introduction for example. In case that storing TA as DS is
defined somewhere a reference to that document might be useful. Otherwise,
maybe we should mention that is a common practice. What I would like to
point is that we may have to re-read the draft with that in mind.


3.4.  Example Exchanges

3.4.2.  Requesting Limited Domains

   In this example exchange, the initiator requests INTERNAL_IP4_DNS and
   INTERNAL_DNS_DOMAIN attributes in its CFG_REQUEST, specifically
   requesting only "example.com" and "other.com".  The responder replies
   with two DNS server addresses, 198.51.100.2 and 198.51.100.4, and two
   domains, "example.com" and "city.other.com".  Note that one of the
   domains in the CFG_REPLY, "city.other.com", is a subset of the
   requested domain, "other.com".  This indicates that hosts within
   "other.com" that are not within "city.other.com" should be resolved
   using an external DNS server.

MGLT: I migth be wrong but can *.other.com stands for example.other.com as
well as example.city.other.com. If so how wildcard is handled. Maybe the
wildcard use case should be explained.


5.  Split DNS Usage Guidelines

    An initiator SHOULD ignore INTERNAL_DNS_DOMAIN attributes containing
   domains that are designated Special Use Domain Names in [RFC6761],
   such as "local", "localhost", "invalid", etc.  Although it may
   explicitly wish to support some Special Use Domain Names.

 MGLT: It sounds to me that deciding how to handle the .local is part of
the initiator policy. I would propose something around.

 Handling domains that are designated Special Use Domain Names in
[RFC6761], such as "local", "localhost", "invalid", etc. with the
INTERNAL_DNS_DOMAIN is part of the initiator's policy. Unless the initiator
explicitly wish to support some Special Use Domain Names, it SHOULD ignore
INTERNAL_DNS_DOMAIN attributes containing Special Use Domain Names.

 I think there is a "dommain" somewhere in the text....



On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly <tpauly@apple.com> wrote:

> Hello,
>
> I’d like to see if there were any further comments on this draft. We
> incorporated the feedback we got from Paul H, Tero, and Daniel—can you
> review the recent version and see if the changes look good?
>
> Thanks,
> Tommy
>
>
> On Sep 21, 2016, at 2:23 PM, Tommy Pauly <tpauly@apple.com> wrote:
>
> Hello all,
>
> We've posted a new version of draft-pauly-ipsecme-split-dns (
> https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).
>
> The changes in this version include:
>
> - Textual clarification based on input from Daniel and Tero
> - Clarification of DNSSEC payload types
> - Update on the content and structure of the INTERNAL_DNSSEC_TA attribute
> - How to associate DNSSEC values with specific domains
> - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)
>
> We believe this should be ready for adoption and moving forward, to follow
> the charter. Please review and provide your input!
>
> Thanks,
> Tommy
>
>
> Begin forwarded message:
>
> *From: *internet-drafts@ietf.org
> *Subject: **New Version Notification for
> draft-pauly-ipsecme-split-dns-02.txt*
> *Date: *September 21, 2016 at 1:27:23 PM PDT
> *To: *Tommy Pauly <tpauly@apple.com>, Paul Wouters <pwouters@redhat.com>
>
>
> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
>
> Name: draft-pauly-ipsecme-split-dns
> Revision: 02
> Title: Split DNS Configuration for IKEv2
> Document date: 2016-09-21
> Group: Individual Submission
> Pages: 12
> URL:            https://www.ietf.org/internet-drafts/draft-
> pauly-ipsecme-split-dns-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-
> ipsecme-split-dns/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-
> split-dns-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-
> ipsecme-split-dns-02
>
> Abstract:
>   This document defines two Configuration Payload Attribute Types for
>   the IKEv2 protocol that add support for private DNS domains.  These
>   domains should be resolved using DNS servers reachable through an
>   IPsec connection, while leaving all other DNS resolution unchanged.
>   This approach of resolving a subset of domains using non-public DNS
>   servers is referred to as "Split DNS".
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>