Subject: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jan 2018 01:23:40 +0000

Greetings. This document is still listed as in WG Last Call, although I haven't seen anything in the archive about that Last Call closing.

The document seems mostly fine, and it certainly seems like a useful IPsec extension. I have only two concerns:

- Section 5 says:
   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.
There is no way that an implementation can easily follow what is in the IANA registry for Special Use Domain names. Further, given that that the names are going to be internal, there isn't a good reason to prevent them from being used beyond the normal "don't make up names that someone else might be using" argument. The second sentence (fragment) doesn't give enough detail to help an implementer. I think that this whole paragraph can be safely removed.

- Section 6 says:
   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  The content MUST be
   verified and sanitized before passing it to other software.  For
   example, domain names are limited to alphanumeric characters and the
   minus ("-") and underscore ("_") symbol and if other other characters
   are present, the entire payload could be ignored and not passed to
   DNS software, or the malicious characters could be filtered out
   before passing the payload to DNS software.
That is not correct. *Host* names are limited, but domain names are not. Domain names can have any octet in them. This is a common misunderstanding in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this paragraph be changed to:
   The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
   passed to another (DNS) program for processing.  Some DNS programs
   only handle domain names in host name format, although many are
   inconsistent about this. 

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 21 Jan 2018 22:20:56 -0500 (EST)

> Greetings. This document is still listed as in WG Last Call, although I haven't seen anything in the archive about that Last Call closing.

Yeah, the WGLC ended Nov 9. I have pinged the chairs a few times
already, and requested an early code point for INTERNAL_DNSSEC_TA.
(we already have one for INTERNAL_DNS_DOMAIN)

> The document seems mostly fine, and it certainly seems like a useful IPsec extension. I have only two concerns:

Thanks for the review!

> There is no way that an implementation can easily follow what is in the IANA registry for Special Use Domain names. Further, given that that the names are going to be internal, there isn't a good r…

I think that's fair. Especially if there will be a .internal or
something, the advise could at best be "clients should be very
careful accepting certain special domains". I will removed the
paragraph.

> That is not correct. *Host* names are limited, but domain names are not. Domain names can have any octet in them. This is a common misunderstanding in the DNS; see RFC 7719 for definitions of DNS t…

That somewhat contradicts 7719 in which document you state:

 	Note that any label in a
 	domain name can contain any octet value; hostnames are generally
 	considered to be domain names where every label follows the rules
 	in the "preferred name syntax"

So a hostname - if FQDN - could have a leftmost label with other stuff
in it, but everything to the right of the zone cut would have to be
compliant to the restrive set. And we were talking about domain names,
and not hostnames.

>   only handle domain names in host name format, although many are

I would prefer to keep the focus on the security part. If there are
weird characters, don't blindly pass those along. Whether something
is a legit hostname or domainname is not very relevant to the IKE
or IPsec layer. Whoever _receives_ the information can determine
that part. We are mostly concerned about passing foo`cat /etc/passswd`.com

So how about:

 	The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be
 	passed to another (DNS) program for processing.  The content MUST be
 	verified to not contain any malicious characters, before it is
 	passed to other programs for DNS processing. If it contains malicious
 	characters, the payload should be ignored or sanitized. Whether a
 	specific combination of non-malicious characters constitute a valid
 	DNS domain name is best left to be decided by the DNS software that
 	receives the contents of these payloads.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jan 2018 03:29:02 +0000

> 	in the "preferred name syntax"

There is no contradiction between what I say above and that.

> compliant to the restrive set. And we were talking about domain names,

Nonono. Nothing in the definition of domain name or hostname has anything to do with label position.

> weird characters, don't blindly pass those along.

If you're talking about domain names, there are no "weird characters": they are just blobs of octets.

> Whether something

...which is a valid domain name (assuming an ASCII or UTF-8 encoding for the octets).

> 	receives the contents of these payloads.

Unless you can define "malicious", I would disagree. In fact, unless you can define "character", you will also have a problem (some encodings of characters take up multiple octets).

If you really want to go down this path, you must say something like "domain names where each label consist only of octets which map to the ASCII encoding of the following values: A to Z, a to z, 0 to 9, "-", and "_". 

--Paul Hoffman

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Mon, 22 Jan 2018 15:31:03 +0000

Paul and Paul,

Thanks for the additional review and dialog. I am currently reviewing this document as the shepherd. It would be good to resolve these issues before moving the draft forward.

I will watch this thread for a resolution before submitting the shepherd writeup.

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Sunday, January 21, 2018 10:29 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [IPsec] [Ext] Re: WG Last Call comments on draft-ietf-ipsecme-split-
> dns
> 
> >> That is not correct. *Host* names are limited, but domain names are not.
> Domain names can have any octet in them. This is a common misunderstanding
> in the DNS; see RFC 7719 for definitions of DNS terms. I suggest that this
> paragraph be changed to:
> >
> > is a legit hostname or domainname is not very relevant to the IKE or
> > IPsec layer. Whoever _receives_ the information can determine that
> > part. We are mostly concerned about passing foo`cat /etc/passswd`.com
> 
> Unless you can define "malicious", I would disagree. In fact, unless you can
> define "character", you will also have a problem (some encodings of characters
> take up multiple octets).
> 
> If you really want to go down this path, you must say something like "domain
> names where each label consist only of octets which map to the ASCII encoding
> of the following values: A to Z, a to z, 0 to 9, "-", and "_".
> 
> --Paul Hoffman
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iet
> f.org%2Fmailman%2Flistinfo%2Fipsec&data=02%7C01%7Cdavid.waltermire%4
> 0nist.gov%7Ccb3cb4d514f64ba8e4d908d561484fb5%7C2ab5d82fd8fa4797a
> 93e054655c61dec%7C1%7C0%7C636521885562888149&sdata=rZ0CDHHaez
> tWhdhrNHtkvtMC0X%2F7EZonxF52J0vlLUM%3D&reserved=0

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jan 2018 17:35:13 +0200

> (we already have one for INTERNAL_DNS_DOMAIN)

I have not seen any request come from IANA to me as an expert. WG
chairs do not assign code points, IANA does that, and they will only
start the process when such request is submitted to them. This will
automatically happen during the RFC publication process. You can also
submit the request to the IANA at any time, as this is Expert review
registry...

So make the request through the IANA and then it will come to me (and
got tickets assigned which will send me reminders if I do not act on
it quickly enough) and then you can get the number allocated.

I though I had already explained this year ago when we assigned
INTERNAL_DNS_DOMAIN, i.e., for expert registries, there is no need to
go through IESG or WG chairs, you can fill in the form in IANA page,
and then it will come to the expert for review...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Jan 2018 11:35:33 -0500 (EST)

On Mon, 22 Jan 2018, Tero Kivinen wrote:

[ added [email-masked] to get a general discussion on this, as it seems
  this is a procedural issue not specific to the WG ]

execsum: I followed RFC 7120 to get an Early Code Point, and there is
confusion about the process between me, the chairs and the epxert.

> it quickly enough) and then you can get the number allocated.

I followed https://tools.ietf.org/html/rfc7120#section-3

    The process for requesting and obtaining early allocation of code
    points is as follows:

    1.  The authors (editors) of the document submit a request for early
        allocation to the Working Group chairs, specifying which code
        points require early allocation and to which document they should
        be assigned.

    2. [wg chairs do stuff]

Nowhere does it link to or mention a page at IANA where to do this.
Nowhere does it state I should not contact the WG chairs.

Now, there is a strangeness in section 2:

The following conditions must hold before a request for early
    allocation of code points will be considered by IANA:

    a.  The code points must be from a space designated as "RFC
        Required", "IETF Review", or "Standards Action".  Additionally,
        requests for early assignment of code points from a
        "Specification Required" registry are allowed if the
        specification will be published as an RFC.

I don't understand why "Expert review" is not listed here. Is it by
design or an error in RFC 7120 ?

Additionally, the document does not point to any other instructions
for the process in the case of Expert Review. Who to contact where?

Paul

> Date: Mon, 22 Jan 2018 10:35:13
> From: Tero Kivinen <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Paul Hoffman <[email-masked]>
> To: Paul Wouters <[email-masked]>
> Subject: Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns
> 
> Paul Wouters writes:
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 22 Jan 2018 11:45:37 -0500 (EST)

>> of the following values: A to Z, a to z, 0 to 9, "-", and "_".

I'm trying not to define any DNS terms in this document and stay out of
any character/domain/hostname discussion. How about:

 	The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed
 	to another (DNS) program for processing. As with any network input, the
 	content should be considered untrusted and handled accordingly.

Paul

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 22 Jan 2018 16:47:18 +0000

Hi Paul,

Expert review requests don’t generally need early assignment because the expert can review a request immediately and codepoints can be assigned.

The working group chairs normally send the requests to [email-masked] for early allocation.  See point 5 in section 3.1:

   5.  If the Area Directors approve step 4), the WG chairs request IANA
       to make an early allocation.

Looks like some improvements are needed to RFC7120 and as I’m the author, I’ll add that to my list of to-do’s.

Let me know if you have any further questions.

Best regards,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager – IANA Services

-----Original Message-----
From: ietf <[email-masked]> on behalf of Paul Wouters <[email-masked]>
Date: Monday, January 22, 2018 at 8:36 AM
To: Tero Kivinen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Ext] Re: [IPsec] WG Last Call comments on draft-ietf-ipsecme-split-dns

    
    
    > it quickly enough) and then you can get the number allocated.
    
    I followed https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7120-23section-2D3&d=DwIBAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DtXLhb_G8hD85GLUyK8Z_tHchz8XPohfWYCwPbpStcU&m=VPvwZ58pXTamTD0lOqjz84Jkf5QVaIlhL2YiYAKqoVg&s=Lwg0SR9f74E08PQbAyw6awTf6d5NAzlLz4ylvxQXZ10&e=

    
        2. [wg chairs do stuff]

    

    
    
    Paul
    
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwIBAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DtXLhb_G8hD85GLUyK8Z_tHchz8XPohfWYCwPbpStcU&m=VPvwZ58pXTamTD0lOqjz84Jkf5QVaIlhL2YiYAKqoVg&s=alAy_YYi5GXoFXZxPAR6fdo_nMCLOH6SBRm7H0U5Odk&e=
    >

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jan 2018 16:50:02 +0000

> 	content should be considered untrusted and handled accordingly.

Yep, that works for me. With that and the other change you said was fine, I think this is quite ready for IETF Last Call.

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Jan 2018 20:28:52 +0200

>   this is a procedural issue not specific to the WG ]

You are trying to follow wrong procedure. There is NO early
allocations for expert review registries. There are only normal
allocations for expert review registries, and those can be done at any
time. The expert (and registry) might then have other requirements
before doing allocation, but as such all allocations are normal
allocations.

> confusion about the process between me, the chairs and the epxert.

RFC7120 does not apply here. From introduction:

   This memo addresses the early allocation of code points so that
   reservations are made in the IANA registries before the publication
   of an RFC. The early allocation mechanisms are applied only to
   spaces whose allocation policy is "Specification Required" (where
   an RFC is used as the stable reference), "RFC Required", "IETF
   Review", or "Standards Action". For an explanation of these
   allocation policies, see [RFC5226].

> I followed https://tools.ietf.org/html/rfc7120#section-3
<wrong procedure removed> 
> Nowhere does it state I should not contact the WG chairs.

That would be true for procedure following RFC7120, but as your
request is not for registries specified in RFC7120 you should not even
try to follow those rules.

> design or an error in RFC 7120 ?

By design.

Expert review assignments can be done at any time and expert will
decide whether those are done or not (but might need to follow rules
set when registry was created too).

It would be possible to get expert to assign you number even before
there is internet draft, so there is no need for "Early allocations".
When you are trying to allocate things earlier than you normally
could, i.e., before the RFC is published for "RFC required" etc, then
you need to get approval for that "Early allocation", but not for
registries where you can do allocations at any time.

> for the process in the case of Expert Review. Who to contact where?

Go to the iana.org web page and click "Apply for assignment" in the
protocol assignments part, and then select "all other protocol
registries" from there and fill in the form.

This will mean that there will be IANA ticket created for that, and
they will then contact the expert to check the request and depending
on expert's answer they will do the allocaton or not.
-- 
[email-masked]