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

From: Daniel Migault <[email-masked]>
Date: Tue, 13 Dec 2016 19:46:58 +0100

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 <[email-masked]> 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 <[email-masked]> 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: [email-masked]
> *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 <[email-masked]>, Paul Wouters <[email-masked]>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 15 Dec 2016 14:03:04 -0800

Hi Daniel,

Thanks for the review comments! Responses inline.

Tommy

> On Dec 13, 2016, at 10:46 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi, 
> 
> 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.
> 
Sure, we can add more discussion around this to explain it.

>    responder.  This attribute lists the corresponding DSSNEC

=) Good catch!

> 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.  
> 

Okay, we can also add more discussion around this in the next update.

>    requesting only "example.com <http://example.com/>" and "other.com <http://other.com/>".  The responder replies
>    domains, "example.com <http://example.com/>" and "city.other.com <http://city.other.com/>".  Note that one of the
>    domains in the CFG_REPLY, "city.other.com <http://city.other.com/>", is a subset of the
>    requested domain, "other.com <http://other.com/>".  This indicates that hosts within
>    "other.com <http://other.com/>" that are not within "city.other.com <http://city.other.com/>" should be resolved
> MGLT: I migth be wrong but can *.other.com <http://other.com/> stands for example.other.com <http://example.other.com/> as well as example.city.other.com <http://example.city.other.com/>. If so how wildcard is handled. Maybe the wildcard use case should be explained.  
>    

We have some text in section 5 around how the segments in the domain are complete segments. This covers part of the behavior.

For example, if the
   INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
   "example.com", "www.example.com" and "mail.eng.example.com" MUST be
   resolved using the internal DNS resolver(s), but "anotherexample.com"
   and "ample.com" MUST be resolved using the system's external DNS
   resolver(s).

I don't want people to be using an actual * wildcard in the protocol, though. I'll probably add a mention in the text that * does not imply a wildcard and should not be used.

>  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. 

That's a better wording, yes. Will change.

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

Quite right. Again, thanks for catching!
> 
>  
> 
> On Mon, Oct 17, 2016 at 6:33 PM, Tommy Pauly <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> 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 <https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02>).
>> 
>> 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: [email-masked] <mailto:[email-masked]>
>>> 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 <[email-masked] <mailto:[email-masked]>>, Paul Wouters <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>> URL:            https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt <https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt>
>>> Status:         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ <https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/>
>>> Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 <https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02>
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02 <https://www.ietf.org/rfcdiff?url2=draft-pauly-ipsecme-split-dns-02>
>>> 
>>> Abstract:
>>> 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 <http://tools.ietf.org/>.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>
> 
>