Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-split-dns-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-05-22
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-05-06
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-04-19
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-03-26
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-03-25
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2019-03-25
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-03-21
|
17 | (System) | RFC Editor state changed to EDIT |
2019-03-21
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-03-21
|
17 | (System) | Announcement was received by RFC Editor |
2019-03-21
|
17 | (System) | IANA Action state changed to In Progress |
2019-03-21
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-03-21
|
17 | Amy Vezza | IESG has approved the document |
2019-03-21
|
17 | Amy Vezza | Closed "Approve" ballot |
2019-03-21
|
17 | Amy Vezza | Ballot approval text was generated |
2019-03-20
|
17 | Eric Rescorla | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-03-14
|
17 | Tero Kivinen | Added to session: IETF-104: ipsecme Thu-1050 |
2019-03-11
|
17 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-17.txt |
2019-03-11
|
17 | (System) | New version approved |
2019-03-11
|
17 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2019-03-11
|
17 | Tommy Pauly | Uploaded new revision |
2019-02-03
|
16 | Tim Chown | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list. |
2018-12-24
|
16 | Eric Rescorla | DISCUSSes cleared. Awaiting comment followup (or confirmation that none is needed). |
2018-12-04
|
16 | Warren Kumari | [Ballot comment] Thank you for addressing my DISCUSS. I still don't love this idea / solution, but after asking the DNSOP list for review ( … [Ballot comment] Thank you for addressing my DISCUSS. I still don't love this idea / solution, but after asking the DNSOP list for review (https://www.ietf.org/mail-archive/web/dnsop/current/msg24835.html) and getting feedback (https://www.ietf.org/mail-archive/web/dnsop/current/msg24881.html) I've been persuaded that the benefits (with the mitigations) outweigh the risks. ---- Original DISCUSS position ---- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. -------------- This section: " 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." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? |
2018-12-04
|
16 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss |
2018-11-26
|
16 | Alexey Melnikov | [Ballot comment] Thank you for addressing my DISCUSS. |
2018-11-26
|
16 | Alexey Melnikov | [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss |
2018-11-25
|
16 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-16.txt |
2018-11-25
|
16 | (System) | New version approved |
2018-11-25
|
16 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-11-25
|
16 | Paul Wouters | Uploaded new revision |
2018-11-21
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-21
|
15 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-11-21
|
15 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-15.txt |
2018-11-21
|
15 | (System) | New version approved |
2018-11-21
|
15 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-11-21
|
15 | Paul Wouters | Uploaded new revision |
2018-11-21
|
14 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-11-21
|
14 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-11-21
|
14 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-11-20
|
14 | Terry Manderson | [Ballot comment] Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns … [Ballot comment] Thanks for the time and effort invested in this document. I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. Perhaps specifying that the DOMAIN and TA sent to the client MUST be in the administrative control of the VPN provider (I'm not sure I read that in the draft) might be one way out, yet I wonder if this is a case of simply having to trust that the VPN provider does the right thing (as cold as that leaves me) regardless of the words in the document. |
2018-11-20
|
14 | Terry Manderson | Ballot comment text updated for Terry Manderson |
2018-11-20
|
14 | Terry Manderson | [Ballot comment] I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections … [Ballot comment] I'm also very interested to see the resolution to Warren's DISCUSS regarding ipsecme-split-dns being used as an easy tool to over-claim entire sections of the DNS hierarchy. |
2018-11-20
|
14 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-11-20
|
14 | Ben Campbell | [Ballot comment] - General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved … [Ballot comment] - General: Once my client signals support for split DNS, what prevents a server from over claiming the domains that should be resolved via the private DNS servers? Perhaps for purposes of employee monitoring or censoring NTFW domains? (I've known some IT managers who would think that was a fine idea.) §6: "the IKE connection SHOULD only process the DNS information if the two connections are part of the same logical entity" How does a client determine the connections are part of the same logical entity? I can think of some ways, but I think the draft should be give some explicit guidance. |
2018-11-20
|
14 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-11-20
|
14 | Warren Kumari | [Ballot discuss] I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users … [Ballot discuss] I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. |
2018-11-20
|
14 | Warren Kumari | [Ballot comment] This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network … [Ballot comment] This section: " 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." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? |
2018-11-20
|
14 | Warren Kumari | Ballot comment and discuss text updated for Warren Kumari |
2018-11-20
|
14 | Suresh Krishnan | [Ballot comment] * Sections 3.1 and 7 I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute would ever be zero. Do … [Ballot comment] * Sections 3.1 and 7 I have a hard time seeing why the length of the INTERNAL_DNS_DOMAIN attribute would ever be zero. Do you expect someone to send an empty attribute? If not, the attribute definition should be updated in Section 7. * Meta comment Since the draft needs and uses a lot of example domain names, I would suggest using a reserved TLD (e.g. ".example") from BCP32 to build up the examples instead of using registered domain names. |
2018-11-20
|
14 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-11-20
|
14 | Warren Kumari | [Ballot discuss] I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users … [Ballot discuss] I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding what the INTERNAL_DNSSEC_TA bit does - please help allay my fears... |
2018-11-20
|
14 | Warren Kumari | [Ballot comment] This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network … [Ballot comment] This section: " 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." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? |
2018-11-20
|
14 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2018-11-20
|
14 | Spencer Dawkins | [Ballot comment] Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request … [Ballot comment] Perhaps it would be helpful to give an example of why A client using these configuration payloads will be able to request and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA configuration attributes. The client device can use the internal DNS server(s) for any DNS queries within the assigned domains. DNS queries for other domains SHOULD be sent to the regular external DNS server. DNS queries for other domains might not be sent to the regular external DNS server? I'm thinking of one, but I'm flat-out guessing. |
2018-11-20
|
14 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-11-19
|
14 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this document. It seems a very useful extension to IKEv2. I have a handful of minor and … [Ballot comment] Thanks to everyone who worked on this document. It seems a very useful extension to IKEv2. I have a handful of minor and editorial comments that you may want to consider addressing. --------------------------------------------------------------------------- Please expand "IKEv2" in the title and abstract. See https://www.rfc-editor.org/materials/abbrev.expansion.txt for details. --------------------------------------------------------------------------- §2.1: > To indicate support for Split DNS, an initiator includes one more > INTERNAL_DNS_DOMAIN attributes as defined in Section 3 as part of the > CFG_REQUEST payload. I can't parse this. Is it mean to say "...one or more..."? Or is "attributes" supposed to be "attribute"? --------------------------------------------------------------------------- §2.1: > includes an INTERNAL_DNSSEC_TA attribute, but does not inclue an Nit: "include" --------------------------------------------------------------------------- §2.1: > 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. As an implementor, I would have no idea whether this was something I wanted to include. If it is configurable, then I would have no idea as an operator whether how to set such configuration. Could we add some guidance here about when implementations and/or operators might want to send this, and when they might not? --------------------------------------------------------------------------- §2.4.1: > The responder replies with two DNS server addresses, and two internal > domains, "example.com" and "city.other.com". The domain "other.com" appears to be in active use by an organization known as "Other Entertainment." Please consider using an example domain as described in RFC 2606 section 2 or 3. --------------------------------------------------------------------------- §2.4.2: > In this example, the initiator has no existing DNSSEC trust anchors > would the requested domain. the "example.com" dommain has DNSSEC Nit: "...domain. The..." --------------------------------------------------------------------------- §4: > 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" SHOULD NOT be > resolved using the internal resolver and SHOULD use the system's > external DNS resolver(s). The domain "anotherexample.com" is in use by a personal web site. The domain "ample.com" is registered anonymously through Amazon.com. For this example that needs to show a domain whose name is a subset of the indicated domain, please consider using an example domain as described in RFC 2602 section 2. --------------------------------------------------------------------------- §5: > DNS records can be used to publish specific records containing trust > anchors for applications. The most common record type is the TLSA > record specified in [RFC6698]. This DNS record type publishes which > CA certificate or EE certificate to expect for a certain host name. Please expand "CA" and "EE". --------------------------------------------------------------------------- §5: > In most deployment scenario's, the IKE client has an expectation that Nit: "scenarios" |
2018-11-19
|
14 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-11-19
|
14 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-11-19
|
14 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-11-19
|
14 | Alissa Cooper | [Ballot comment] Section 5: "Enterprise Certificate Agency" --> I would have expected this to say Enterprise Certificate Authority. "Other generic or public domains, such as … [Ballot comment] Section 5: "Enterprise Certificate Agency" --> I would have expected this to say Enterprise Certificate Authority. "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." Under what exceptional circumstances would it make sense to whitelist a TLD? Is this like if I run Example Corp and I own .example? |
2018-11-19
|
14 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-11-19
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tim Chown |
2018-11-19
|
14 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tim Chown |
2018-11-17
|
14 | Alexey Melnikov | [Ballot discuss] This is a well written document, so thank you for that. I've noticed that Benjamin already found typos that I found and raised … [Ballot discuss] This is a well written document, so thank you for that. I've noticed that Benjamin already found typos that I found and raised one of the same questions, but I think this is important enough to be addressed before I recommend approval of this document. Specifically: In Section 3.1: o Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", in DNS presentation format and optionally using IDNA [RFC5890] for Internationalized Domain Names. Do you mean A-label or U-label form here? Implementors need to be careful that this value is not null-terminated. |
2018-11-17
|
14 | Alexey Melnikov | [Ballot Position Update] New position, Discuss, has been recorded for Alexey Melnikov |
2018-11-15
|
14 | Benjamin Kaduk | [Ballot comment] I am balloting YES because I think this mechanism has significant value, but I do also have some substantial comments that will likely … [Ballot comment] I am balloting YES because I think this mechanism has significant value, but I do also have some substantial comments that will likely result in changes to the draft. (I also have a number of nit-level comments.) Section 1 nit: the Abstract and Introduction are supposed to stand on their own, so starting off with "Split DNS is a common configuration" before defining it makes the reader work a bit harder than perhaps they need to. Section 2 When Split DNS has been negotiated, the existing DNS server configuration attributes will be interpreted as internal DNS servers that can resolve hostnames within the internal domains. nit: maybe add a word or two to emphasize that the existing attributes are also IKEv2 Configuration Payload Attributes? Section 2.1 If an INTERNAL_DNS_DOMAIN attribute is included in the CFG_REQUEST, the initiator MUST also include one or more INTERNAL_IP4_DNS and INTERNAL_IP6_DNS attributes in the CFG_REQUEST. nit: I think I could parse this as saying that I need one or more IP4 and also one or more IP6 attributes (i.e., precluding v4- or v6-only configurations), which I assume is not the intent. Maybe "or" or "and/or" would be better than "and"? To indicate support for DNSSEC, an initiator includes one or more INTERNAL_DNSSEC_TA attributes as defined in Section 3 as part of the CFG_REQUEST payload. [...] nit: There are perhaps philosophical arguments to have about whether this indicates support for DNSSEC as a whole, or just for receiving trust anchors for DNSSEC from the responder [for the split-DNS domain(s)]. Section 2.2 supported by the server, unless the initiator has been configured with local polict to define a set of Split DNS domains to use by default. typo: "policy" We have to use DNS presentation format for the DS records and not wire format? Section 2.4 Please consider using IPv6 examples, per https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ . Section 3.1 o Domain Name (0 or more octets) - A Fully Qualified Domain Name used for Split DNS rules, such as "example.com", in DNS presentation format and optionally using IDNA [RFC5890] for Internationalized Domain Names. Implementors need to be careful that this value is not null-terminated. W.r.t. IDNA, is this an A-label or a U-label? W.r.t NUL-termination, do they need to not send the zero byte or not expect to receive one? Section 3.2 Any INTERNAL_DNSSEC_TA attribute that is not immediately preceded by an INTERNAL_DNS_DOMAIN or another INTERNAL_DNSSEC_TA attribute applying to the same domain name MUST be ignored and treated as a protocol error. Isn't "ignored" incompatible with "treated as a protocol error"? Section 4 If a client is configured by local policy to only accept a limited number of INTERNAL_DNS_DOMAIN values, the client MUST ignore any other INTERNAL_DNS_DOMAIN values. Is this a limited *number* or a limited *set*? (If the former, exposition about which ones are the "other" ones is probably in order.) private remote network using the IPsec connection. If all traffic is routed over the IPsec connection, the existing global INTERNAL_IP4_DNS and INTERNAL_IP6_DNS can be used without creating specific DNS exemptions. DNS or DNSSEC exemptions (i.e., both)? Section 5 DNS records can be used to publish specific records containing trust anchors for applications. The most common record type is the TLSA record specified in [RFC6698]. This DNS record type publishes which CA certificate or EE certificate to expect for a certain host name. These records are protected by DNSSEC and thus can be trusted by the application. [...] I'm probably thinking too much about "trust" as a concept (due to the RATS BoF), but especially given that this goes on to say that this is a local policy decision, I'd suggest replacing "can be trusted" with something like "has a trust path in" or "are trustable by". Merely being in DNS with valid DNSSEC signatures does not make the client trust it; that's still a local policy decision. It allows the remote IKE/IPsec server to modify DNS answers including its DNSSEC cryptographic signatures by overriding existing DNS information with trust anchor conveyed via IKE and (temporarilly) installed on the IKE client. [...] nits: "including DNSSEC cryptographic signatures" (no "its"); "trust anchor(s)" IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use a whitelist of one or more domains that can be updated out of band. IKE clients with an empty whitelist MUST NOT use any INTERNAL_DNSSEC_TA attributes received over IKE. Such clients MAY interpret receiving an INTERNAL_DNSSEC_TA attribute for a non- whitelisted domain as an indication that their local configuration may need to be updated out of band. [...] IKE clients MAY interpret an INTERNAL_DNSSEC_TA for domain that was not preconfigured as an indication that it needs to update its IKE configuration (out of band). The client MUST NOT use such a INTERNAL_DNSSEC_TA to reconfigure its local DNS settings. These two paragraphs seem essentially redundant (the first seems better to me). IKE clients MUST ignore any received INTERNAL_DNSSEC_TA requests for a FDQN for which it did not receive and accept an INTERNAL_DNS_DOMAIN Configuration Payload. nit: are these really "requests"? Section 6 It's probably appropriate to reiterate here that "As discussed in Section 5, the INTERNAL_DNSSEC_TA mechanism allows the credential used to authenticate an IKEv2 association to be leveraged into authenticating credentials for TLS and other connections. This reflects something of a privilege escalation, and initiators should ensure that they have sufficient trust in the communications peer to responsibly use (or not use) that elevated privilege." If the initiator is using DNSSEC validation for a domain in its public DNS view, and it requests and receives an INTERNAL_DNS_DOMAIN attribute without an INTERNAL_DNSSEC_TA, it will need to reconfigure its DNS resolver to allow for an insecure delegation. It SHOULD NOT accept insecure delegations for domains that are DNSSEC signed in the public DNS view, for which it has not explicitely requested such deletation by specifying the domain specifically using a INTERNAL_DNS_DOMAIN(domain) request. It seems like heeding this SHOULD NOT would potentially require the initiator to make extra DNS requests from the external view that it would not otherwise need to make. I agree that this is the behavior we want to encourage with respect to not downgrading away from DNSSEC, but it's less clear to me that we want to encourage the initiator to go out of its way to check, as opposed to just using information it may happen to have already. |
2018-11-15
|
14 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-11-09
|
14 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-11-05
|
14 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-11-04
|
14 | Tero Kivinen | Added to session: IETF-103: ipsecme Wed-1350 |
2018-11-04
|
14 | Eric Rescorla | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-11-03
|
14 | Cindy Morgan | New version available: draft-ietf-ipsecme-split-dns-14.txt |
2018-11-03
|
14 | (System) | Secretariat manually posting. Approvals already received |
2018-11-03
|
14 | Cindy Morgan | Uploaded new revision |
2018-11-03
|
13 | Cindy Morgan | Placed on agenda for telechat - 2018-11-21 |
2018-11-03
|
13 | Eric Rescorla | Ballot has been issued |
2018-11-03
|
13 | Eric Rescorla | [Ballot Position Update] New position, Yes, has been recorded for Eric Rescorla |
2018-11-03
|
13 | Eric Rescorla | Created "Approve" ballot |
2018-11-03
|
13 | Eric Rescorla | Ballot writeup was changed |
2018-10-22
|
13 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-10-22
|
13 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-13.txt |
2018-10-22
|
13 | (System) | New version approved |
2018-10-22
|
13 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-10-22
|
13 | Tommy Pauly | Uploaded new revision |
2018-08-30
|
12 | Tim Chown | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. Sent review to list. |
2018-08-24
|
12 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-08-22
|
12 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2018-08-22
|
12 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ipsecme-split-dns-12. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-ipsecme-split-dns-12. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the IKEv2 Configuration Payload Attribute Types registry on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at: https://www.iana.org/assignments/ikev2-parameters/ the existing registrations Multi- Value Attribute Type Valued Length Reference ------ ------------------- ------ ---------- --------------- 25 INTERNAL_DNS_DOMAIN YES 0 or more [current draft] 26 INTERNAL_DNSSEC_TA YES 0 or more [current draft] will have their references changed to [ RFC-to-be ]. The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-08-20
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-08-20
|
12 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2018-08-19
|
12 | Stefan Santesson | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Stefan Santesson. Sent review to list. |
2018-08-16
|
12 | Christer Holmberg | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Christer Holmberg. Sent review to list. |
2018-08-16
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2018-08-16
|
12 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2018-08-16
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-08-16
|
12 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stefan Santesson |
2018-08-10
|
12 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-08-10
|
12 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-08-24): From: The IESG To: IETF-Announce CC: David Waltermire , ipsecme-chairs@ietf.org, ekr@rtfm.com, ipsec@ietf.org, … The following Last Call announcement was sent out (ends 2018-08-24): From: The IESG To: IETF-Announce CC: David Waltermire , ipsecme-chairs@ietf.org, ekr@rtfm.com, ipsec@ietf.org, david.waltermire@nist.gov, draft-ietf-ipsecme-split-dns@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Split DNS Configuration for IKEv2) to Proposed Standard The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Split DNS Configuration for IKEv2' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to 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". The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-08-10
|
12 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-08-10
|
12 | Eric Rescorla | Last call was requested |
2018-08-10
|
12 | Eric Rescorla | Last call announcement was generated |
2018-08-10
|
12 | Eric Rescorla | Ballot approval text was generated |
2018-08-10
|
12 | Eric Rescorla | Ballot writeup was generated |
2018-08-10
|
12 | Eric Rescorla | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-08-06
|
12 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-12.txt |
2018-08-06
|
12 | (System) | New version approved |
2018-08-06
|
12 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-08-06
|
12 | Tommy Pauly | Uploaded new revision |
2018-07-19
|
11 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-11.txt |
2018-07-19
|
11 | (System) | New version approved |
2018-07-19
|
11 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-07-19
|
11 | Tommy Pauly | Uploaded new revision |
2018-07-18
|
10 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-10.txt |
2018-07-18
|
10 | (System) | New version approved |
2018-07-18
|
10 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-07-18
|
10 | Tommy Pauly | Uploaded new revision |
2018-07-18
|
09 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-09.txt |
2018-07-18
|
09 | (System) | New version approved |
2018-07-18
|
09 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-07-18
|
09 | Paul Wouters | Uploaded new revision |
2018-07-16
|
08 | Tero Kivinen | Added to session: IETF-102: ipsecme Wed-1520 |
2018-06-18
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-06-18
|
08 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-08.txt |
2018-06-18
|
08 | (System) | New version approved |
2018-06-18
|
08 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-06-18
|
08 | Paul Wouters | Uploaded new revision |
2018-04-13
|
07 | Eric Rescorla | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2018-03-01
|
07 | David Waltermire | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The type of this RFC is Proposed Standard, which is listed in the title page header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The IPsecME working group has obsoleted the IKEv1 protocol in favor of the IKEv2 protocol many years ago. However, IKEv2 never had an option to send one or more DNS domains from a Remote Access VPN server to the VPN clients. IKEv1 did have that option via XAUTH/ModeCFG. This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to 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". Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the last 3 IETF (98, 99, 100) meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The document is supported by implementors, and authors also represent a subset of implementors. Interoperability of the DNS domain has been confirmed by at least three independent implementations. DNSSEC TA support has not seen an implementation or interoperability test, but the format is sufficiently simple that no one is worried. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The Document Shepherd is David Waltermire. The responsible Area Director is Eric Rescorla. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has completely reviewed this draft to include review of idnits, the references, and IANA considerations sections. No issues have been found. The document is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document had a significant number of reviews/comments during the multiple draft iterations. The document Shepherd believes the document has been carefully reviewed. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document Shepherd has no issue with the document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. The authors confirm there is no IPR disclosure needed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is no related IPR disclosures for this document, or the prior document, RFC4307. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The document has been heavily discussed and reviewed by the WG, and has been presented during the IETF meetings. There has been a significant number of comments on the draft, which have been sufficiently addressed by the authors. The document represents the strong consensus of the WG. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No error is raised. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). This is caused by the use of RFC8174 boilerplate and should be ignored. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not need external formal reviews. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA section adds two new attribute types to the IANA "IKEv2 Configuration Payload Attribute Types" registry. Both of these entries have been requested for early assignment, have passed expert review, and already appear in the registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There is no need to proceed to further checks. |
2018-03-01
|
07 | David Waltermire | Responsible AD changed to Eric Rescorla |
2018-03-01
|
07 | David Waltermire | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-03-01
|
07 | David Waltermire | IESG state changed to Publication Requested |
2018-03-01
|
07 | David Waltermire | IESG process started in state Publication Requested |
2018-03-01
|
07 | David Waltermire | Waiting to confirm IPR before submitting to the IESG. |
2018-03-01
|
07 | David Waltermire | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2018-03-01
|
07 | David Waltermire | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-03-01
|
07 | David Waltermire | Changed consensus to Yes from Unknown |
2018-03-01
|
07 | David Waltermire | Intended Status changed to Proposed Standard from None |
2018-03-01
|
07 | David Waltermire | Changed document writeup |
2018-02-28
|
07 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-07.txt |
2018-02-28
|
07 | (System) | New version approved |
2018-02-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-02-28
|
07 | Tommy Pauly | Uploaded new revision |
2018-02-09
|
06 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-06.txt |
2018-02-09
|
06 | (System) | New version approved |
2018-02-09
|
06 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-02-09
|
06 | Paul Wouters | Uploaded new revision |
2018-02-06
|
05 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-05.txt |
2018-02-06
|
05 | (System) | New version approved |
2018-02-06
|
05 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-02-06
|
05 | Paul Wouters | Uploaded new revision |
2018-01-22
|
04 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-04.txt |
2018-01-22
|
04 | (System) | New version approved |
2018-01-22
|
04 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2018-01-22
|
04 | Paul Wouters | Uploaded new revision |
2017-11-11
|
03 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-03.txt |
2017-11-11
|
03 | (System) | New version approved |
2017-11-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2017-11-11
|
03 | Paul Wouters | Uploaded new revision |
2017-11-11
|
02 | David Waltermire | Added to session: IETF-100: ipsecme Mon-0930 |
2017-11-11
|
02 | David Waltermire | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-11-11
|
02 | David Waltermire | IETF WG state changed to In WG Last Call from WG Document |
2017-07-29
|
02 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-02.txt |
2017-07-29
|
02 | (System) | New version approved |
2017-07-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2017-07-29
|
02 | Paul Wouters | Uploaded new revision |
2017-07-19
|
01 | Paul Wouters | New version available: draft-ietf-ipsecme-split-dns-01.txt |
2017-07-19
|
01 | (System) | New version approved |
2017-07-19
|
01 | (System) | Request for posting confirmation emailed to previous authors: Paul Wouters , Tommy Pauly |
2017-07-19
|
01 | Paul Wouters | Uploaded new revision |
2017-07-18
|
00 | Tero Kivinen | Added to session: IETF-99: ipsecme Fri-1150 |
2017-03-29
|
00 | David Waltermire | Notification list changed to David Waltermire <david.waltermire@nist.gov> |
2017-03-29
|
00 | David Waltermire | Document shepherd changed to David Waltermire |
2017-03-26
|
00 | David Waltermire | Added to session: IETF-98: ipsecme Wed-1300 |
2017-03-13
|
00 | David Waltermire | This document now replaces draft-pauly-ipsecme-split-dns instead of None |
2017-03-13
|
00 | Tommy Pauly | New version available: draft-ietf-ipsecme-split-dns-00.txt |
2017-03-13
|
00 | (System) | WG -00 approved |
2017-03-13
|
00 | Tommy Pauly | Set submitter to "Tommy Pauly ", replaces to draft-pauly-ipsecme-split-dns and sent approval email to group chairs: ipsecme-chairs@ietf.org |
2017-03-13
|
00 | Tommy Pauly | Uploaded new revision |