Subject: [DNSOP] Fwd: [IANA #989438] ipv4only.arpa's delegation should be insecure.

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Jun 2018 11:29:31 +1000

The Domain Name Reservation Considerations in RFC 7050 do not cover whether
a delegation should be signed or not.  Due to that omission in constructing the set
of questions to be asked RFC 7050 fails when the client is behind a validating resolver
that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA.

There are 2 pieces of work that are required.
1) update the list of questions that need to be asked needs to include whether a delegation
    needs to be signed or not.
2) update RFC 7050 to include explicit instructions to say DO NOT sign IPV4ONLY.ARPA.

Item 1 is dnsop work as far as I can see.  Item 2, I think, should be v6ops work.

HOME.ARPA is a example of a unsigned delegation.
10.IN-ADDR.ARPA is a example of a unsigned delegation.

There is zero benefit in IPV4ONLY.ARPA being signed.  Its contents on the Internet
are well known.  The contents with NAT64 in using are well known except for the
AAAA query.  The answer to that query is *expected to change*.  That answer cannot
be validated.

Mark

> Begin forwarded message:
> 
> From: "Michelle Cotton via RT" <[email-masked]>
> Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure.
> Date: 6 January 2018 at 8:45:10 am AEDT
> To: [email-masked]
> Reply-To: [email-masked]
> 
> Hello,
> 
> Following up on a thread from the end of the year.  Who will bring this to the DNSOps working group?  Will someone notify us if there is an consensus on a conclusion of what needs to be done?
> 
> Thanks in advance.
> 
> --Michelle Cotton
> 
> 
> On Sun Dec 10 22:40:29 2017, [email-masked] wrote:
>> I had replied to the errata. I agree it warrants additional
>> discussion, and had also suggested same. Dnsops seems appropriate.
>> 
>> 
>> 
>> The question is not to much where the attacker is, but what DNSSEC
>> guarantee is provided. DNS64 imagines the client could do its own
>> validation — if it wanted.  To date, effectively zero clients seem to
>> want to do their own DNSSEC validation.
>> 
>> -d
>> 
>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere)
>>> <[email-masked]> wrote:
>>> 
>>> Hi,
>>> 
>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an
>>> email address I found from an I-D..
>>> 
>>> I'm not really following IETF nowadays, so I don't know if this has
>>> been discussed.
>>> 
>>> Also I'm not sure why ISPs couldn’t first verify the A response's
>>> validity and then generate AAAA response to the client as document...
>>> but I suppose it could be considered to be more proper action to
>>> modify insecure responses than secure responses. I'm just worried
>>> what happens if there's attacker between ISP and root, in which case
>>> the IPv4 address part of the response could be modified by attacker
>>> and then delivered to client in the ISP's synthetic AAAA record..
>>> 
>>> So I cannot accept the errata straight away, but it should be
>>> discussed with people who are more experts on this than I am.
>>> 
>>> Best regards,
>>> 
>>> Teemu
>>> 
>>> 
>>> -----Original Message-----
>>> From: Michelle Cotton via RT [mailto:iana-questions-
>>> [email-masked]]
>>> Sent: 9. joulukuuta 2017 1:22
>>> Cc: [email-masked]; [email-masked];
>>> [email-masked]; Savolainen, Teemu (Nokia-TECH/Tampere)
>>> <[email-masked]>
>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be
>>> insecure.
>>> 
>>> Hello,
>>> 
>>> Just checking to see if anyone had a chance to look at this.
>>> Dan Wing's email addressed bounced ([email-masked]).
>>> 
>>> Thanks,
>>> Michelle
>>> 
>>> 
>>> 
>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote:
>>>> Hello Authors and Area Directors,
>>>> 
>>>> We have received a message pointing out an errata report that would
>>>> modify the actions that were performed for RFC7050.
>>>> 
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-
>>>> 2Deditor.org_errata_eid5152&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=hjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=uCKCSggUUCCU7iPuRs-
>>>> usGcL3T69Fia9gTOy4UQwhLk&e=
>>>> 
>>>> Has this report been discussed?  Will the result be an approved
>>>> errata
>>>> report or a new RFC?
>>>> 
>>>> Thanks in advance.
>>>> 
>>>> Michelle Cotton
>>>> Protocol Parameters Engagement Sr. Manager
>>> 
>>> 
>>> 
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Tue, 12 Jun 2018 19:28:16 -0700

Hi everyone,

Stuart and I have a draft that attempts to address these issues, please let us know if you think it does or doesn't.

https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa <https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa>

Thanks,
David Schinazi

> On Jun 12, 2018, at 18:29, Mark Andrews <[email-masked]> wrote:
> 
>> From: "Michelle Cotton via RT" <[email-masked] <mailto:[email-masked]>>
>> To: [email-masked] <mailto:[email-masked]>
>> Reply-To: [email-masked] <mailto:[email-masked]>
>> 
>> Hello,
>> 
>> On Sun Dec 10 22:40:29 2017, [email-masked] <mailto:[email-masked]> wrote:
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> [email-masked] <mailto:[email-masked]>]
>>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>>>> [email-masked] <mailto:[email-masked]>; Savolainen, Teemu (Nokia-TECH/Tampere)
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> Dan Wing's email addressed bounced ([email-masked] <mailto:[email-masked]>).
>>>> 
>>>> Thanks,
>>>> Michelle
>>>> 
>>>> 
>>>> 
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc->
> PHONE: +61 2 9871 4742              INTERNET: [email-masked] <mailto:[email-masked]>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Jun 2018 19:35:34 -0700

LGTM.   It sounds like Mark is arguing that RFC6761 also needs updated.
Possibly this document could do that, but it would need to be reframed a
bit.

On Tue, Jun 12, 2018 at 7:28 PM, David Schinazi <[email-masked]> wrote:

> Hi everyone,
>
> Stuart and I have a draft that attempts to address these issues, please
> let us know if you think it does or doesn't.
>
> https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa
>
> Thanks,
> David Schinazi
>
>
> *From: *"Michelle Cotton via RT" <[email-masked]>
> *Subject: **[IANA #989438] ipv4only.arpa's delegation should be insecure.*
> *Date: *6 January 2018 at 8:45:10 am AEDT
> *To: [email-masked]
> *Reply-To: [email-masked]
>
> Hello,
>
> Following up on a thread from the end of the year.  Who will bring this to
> the DNSOps working group?  Will someone notify us if there is an consensus
> on a conclusion of what needs to be done?
>
> Thanks in advance.
>
> --Michelle Cotton
>
>
> 2Deditor.org_errata_eid5152&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=
> IMDU0f3LtPMQf5XkZ06fNg&m=hjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=
> uCKCSggUUCCU7iPuRs-
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Jun 2018 13:15:58 +1000

> On 13 Jun 2018, at 12:28 pm, David Schinazi <[email-masked]> wrote:
> 
> Hi everyone,
> 

This does not meet my requirements.  There is zero need for any part of the normal DNS resolution
process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zone.  That would
allow getaddrinfo() to be able to lookup up the AAAA records without any intermediate software
having to special case IPV4ONLY.ARPA.  IPV4ONLY.ARPA would then validate as insecure rather
than as secure as it currently does.

The document needs to explicitly state that the delegation for IPV4ONLY.ARPA in ARPA MUST
be insecure (no DS record).

You then have other issues to deal with like not sending queries for IPV4ONLY.ARPA to servers
which have DNS64 configured or have a local IPV4ONLY.ARPA zone.  These are similar to the issues
for HOME.ARPA but are at the ISP rather than the CPE.

One way to handle that would be for CPE to always use the DHCP/RA DNS servers for IPV4ONLY.ARPA
and require a explicit override just for IPV4ONLY.ARPA.

Another way would be for middle boxes to intercept queries but then you have to account for
anti spoofing technology TSIG, DNS COOKIE etc.  DNS COOKIE just needs the delegated servers
for IPV4ONLY.ARPA to not serve any other zones.  That way any DNS COOKIE state learnt for the
IP addresses of the servers for IPV4ONLY.ARPA does not impact on IPV4ONLY.ARPA lookups.

I mention TSIG because that could be used with a well known TSIG key to defeat fragmentation
attacks and because TSIG can be used between clients and recursive servers that are not
operated by the ISP.  This would be one case where DNS resolution software may want to be
altered by default.  This scenario is even rarer than DNSSEC.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jun 2018 12:12:28 +0200

><https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa>

>From Section 6.2:
3.  Name resolution APIs and libraries MUST recognize 'ipv4only.arpa'
       as special and MUST give it special treatment.  Regardless of any
       manual client DNS configuration, DNS overrides configured by VPN
       client software, or any other mechanisms that influence the
       choice of the client's recursive resolver address(es) (including
       client devices that run their own local recursive resolver and
       use the loopback address as their configured recursive resolver
       address) all queries for 'ipv4only.arpa' and any subdomains of
       that name MUST be sent to the recursive resolver learned from the
       network via IPv6 Router Advertisement Options for DNS
       Configuration [RFC6106] or via DNS Configuration options for
       DHCPv6 [RFC3646].

First we introduce ipv4only.arpa as a hack to avoid creating/deploying a
suitable mechanism to communicate the NAT64 translation prefix. That's fine
with me.

But when that hack then requires changes to every possible DNS stub resolver
implementation in the world, there is something seriously wrong.

So if this in indeeed required to make RFC7050 work then it is better to
formally deprecate RFC7050 and focus on other ways to discover the
translation prefix.

It seems that at least one already exists (RFC7225) so not much is lost.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 12:45:38 +0200

Hi Philip,

Agree, ideally, should be a DHCPv6 bases mechanism as we already proposed long time ago, because PCP is not present in many networks (unfortunately), while DHCP is quite common.

We are happy to resurrect and review this work if needed:

https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01

Regards,

Jordi

-----Mensaje original-----

De: DNSOP <[email-masked]> en nombre de Philip Homburg <[email-masked]>

Fecha: miércoles, 13 de junio de 2018, 12:42

Para: <[email-masked]>

CC: Stuart Cheshire <[email-masked]>, Michelle Cotton via RT <[email-masked]>, dnsop <[email-masked]>, David Schinazi <[email-masked]>

Asunto: Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.

           DHCPv6 [RFC3646].

    with me.

    translation prefix.

    

    DNSOP mailing list

    [email-masked]

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Jun 2018 22:19:17 -0400

On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews <[email-masked]> wrote:

> ​

I'm not sure that I agree with you on that (let's ignore DNSSEC for now) --
there is little *technical* reason for the normal DNS resolution process to
know that ipv4only.arpa is special, but administrators sometimes install
ipv4only.arpa resolution locally (for disconnected networks, to improve
reliability (e.g when .arpa is slow), or when users are using non-local DNS
resolvers (like 8.8.8.8). This is not a technical thing, but rather a
blessing that NAT64 / DNS64 admins can do that -- personally this sounds
more like an argument for adding it to locally served zones not SUDN. What
am I missing here?

​
> be insecure (no DS record).
RFC7050 Section 7 says:
"A signed "ipv4only.arpa." allows validating
   DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to
   detect malicious AAAA resource records.  Therefore, the zone serving
   the well-known name has to be protected with DNSSEC."

I read that a few times, and even when squinting I cannot figure out how
that is supposed to work. Can someone enlighten me? I can see how a signed
ipv4only.arpa allows a validating DNS64 server to validate the (well
known!) v4 addresses, but the malicious AAAA RR detection bit confuses me...

> altered by default.  This scenario is even rarer than DNSSEC.

​W
​

> >>> Following up on a thread from the end of the year.  Who will bring
> this to the DNSOps working group?  Will someone notify us if there is an
> consensus on a conclusion of what needs to be done?
> >>>
> >>> Thanks in advance.
> >>>
> >>> --Michelle Cotton
> >>>
> >>>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: David Schinazi <[email-masked]>
Date: Mon, 18 Jun 2018 18:30:17 -0700

Hi, responses inline.

> On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews <[email-masked] <mailto:[email-masked]>> wrote:
> 
> process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zone.

Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? It explains why some parts of the DNS resolution process do need to treat ipv4only.arpa as special, regardless of DNSSEC.

> On Jun 13, 2018, at 19:19, Warren Kumari <[email-masked]> wrote:
> 
> I read that a few times, and even when squinting I cannot figure out how that is supposed to work. Can someone enlighten me? I can see how a signed ipv4only.arpa allows a validating DNS64 server to validate the (well known!) v4 addresses, but the malicious AAAA RR detection bit confuses me...

I agree, there is no point in signing the A records for ipv4only.arpa since they are well-known, and for the same reason there is no point in checking it. So having A records signed or unsigned is irrelevant since no one should be querying for these A records anyway. Similarly, since the whole purpose of the AAAA records for ipv4only.arpa is to be overridden by a DNS64 recursive resolver which is not owned by .arpa, checking signatures will not validate anything useful.

I agree with Mark's point that queries will fail when the client is behind a validating resolver that has no special knowledge of ipv4only.arpa.

To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to mention that ipv4only.arpa MUST NOT be signed.

Thanks,
David

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Jun 2018 21:35:51 -0400

You should steal the text from the dot home RFC.

On Mon, Jun 18, 2018 at 9:30 PM David Schinazi <[email-masked]> wrote:

> Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? It
> explains why some parts of the DNS resolution process do need to treat
> ipv4only.arpa as special, regardless of DNSSEC.
>
> I agree, there is no point in signing the A records for ipv4only.arpa
> since they are well-known, and for the same reason there is no point in
> checking it. So having A records signed or unsigned is irrelevant since no
> one should be querying for these A records anyway. Similarly, since the
> whole purpose of the AAAA records for ipv4only.arpa is to be overridden by
> a DNS64 recursive resolver which is not owned by .arpa, checking signatures
> will not validate anything useful.
>
> I agree with Mark's point that queries will fail when the client is behind
> a validating resolver that has no special knowledge of ipv4only.arpa.
>
> To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to
> mention that ipv4only.arpa MUST NOT be signed.
>
> Thanks,
> David

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2018 12:16:01 +1000

> On 19 Jun 2018, at 11:35 am, Ted Lemon <[email-masked]> wrote:
> 

No.  You expect DNS64 recursive server to query for them as part of the synthesis process when they get a request from a device that is attempting to configuring the CLAT service by asking for the AAAA records for ipv4only.arpa.  And to be pedantic one is overriding the NODATA response as there are no AAAA records for ipv4only.arpa.