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

[Tommy Pauly]

Hi Daniel,

Thanks for the review comments! Responses inline.

Tommy

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

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

=) Good catch!

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

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

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

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.

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

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  > 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 > > wrote:
>> 
>> Hello all,
>> 
>> We've posted a new version of 

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

[Daniel Migault]

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  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  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-dra...@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 , Paul Wouters 
>
>
> 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