Re: [v6ops] Supporting IPv6-only Networks with NAT64 and DNS64 section of draft-ietf-v6ops-rfc6555bis-01

Perhaps, have section 7 for IPv6-only network with 2 sub-sections -

7.1 pointing out transition technologies such as 464XLAT based on DNS64/NAT64 that breaks DNSSEC for v4 destinations.

7.2 pointing out that MAP-T/E not breaking DNSSEC since there is no DNS64 involved.

I still think it should be outside the scope of this draft to tackle DNSSEC related issues when using DNS64.

Agreed.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Jun 28, 2017, at 9:53 PM, "stephan.lagerholm@yahoo.com<mailto:stephan.lagerholm@yahoo.com>" <stephan.lagerholm@yahoo.com<mailto:stephan.lagerholm@yahoo.com>> wrote:

Hi Mark,
>        Mark Andrews <marka@isc.org<mailto:marka@isc.org>>
>
>> On 29 Jun 2017, at 1:01 pm, stephan.lagerholm@yahoo.com<mailto:stephan.lagerholm@yahoo.com> wrote:
>>
>> Hi Mark,
>>
>> >From: Mark Andrews <marka@isc.org<mailto:marka@isc.org>>
>> >> In message <738488839.469942.1498664001646@mail.yahoo.com<mailto:738488839.469942.1498664001646@mail.yahoo.com>>, "stephan.lagerholm@yahoo.com<mailto:stephan.lagerholm@yahoo.com>" writes:
>> >> Hi David,
>> >> Thanks for adding the Supporting IPv6-only Networks with NAT64 and DNS64
>> >> section, I find it useful. However I don't think the below sentence from
>> >> this section is accurate. I can't think of any changes that are needed on
>> >> a client device to run NAT64/DNS64.
>> >
>> >Well you obviously don't have any devices doing DNSSEC validation.
>> >DNS64 breaks DNSSEC as it changes the DNS responses from NOERROR
>> >NODATA to NOERROR DATA by synthesizing a AAAA RRset.  This from the
>> >client's perspective is not different than forging a fake AAAA RRset
>> >that is trying to hijack the traffic stream.
>>
>> This case and the remedy is already covered in RFC 6147 section 3. I don't think it makes sense to bring it up in this draft.
>
>RFC 6147 states that end devices need to be upgraded.  Yes
>this is in contradiction to itself where it states that they don't need
>to be upgraded.
>
>Section 5.5.
>
>      The disadvantage to this approach is that an end point that is
>      translation-oblivious but security-aware and validating will not
>      be able to use the DNS64 functionality.  In this case, the end
>      point will not have the desired benefit of NAT64.  In effect,
>      this strategy means that any end point that wishes to do
>      validation in a NAT64 context must be upgraded to be
>      translation-aware as well.
>
>Then you have 5.5.3, turn a DNSSEC MUST NOT into a MAY
>and in doing so completely defeating the purpose of the "MUST NOT"
>on CD=1 which is to get answers which are incorrectly being rejected
>by the upstream validating resolver.
>
>      "then vDNS64 MAY perform validation,"
>
>Then you have changes to the purpose of CD which don't work
>with TTL=0 answers.
>
>The whole IETF seems to think that DNS64/NAT64 works well.  It
>doesn't when you need to use the protections that DNSSEC
>provides.  It works ok if everything else is correctly configured and
>there are no active attacks on the recursive DNS servers happening.

I agree that it does not work well if you validate on the stub resolver side. I can imagine that you could do an RFC7050 query within your validator, strip the pref64 and then validate the A record. I still think it should be outside the scope of this draft to tackle DNSSEC related issues when using DNS64. It is not going to add any clarity to Happy Eyeballs to have text around DNSSEC related issues that remains unchanged with or without this draft being implemented. I'm happy to work on an rfc6174bis with you.

/Stephan
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops