Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt

Jen Linkova <furry13@gmail.com> Tue, 11 August 2020 11:16 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204993A0FB1 for <v6ops@ietfa.amsl.com>; Tue, 11 Aug 2020 04:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzX_4pt-LP5i for <v6ops@ietfa.amsl.com>; Tue, 11 Aug 2020 04:16:03 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C844F3A0FAF for <v6ops@ietf.org>; Tue, 11 Aug 2020 04:16:03 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id g26so11268093qka.3 for <v6ops@ietf.org>; Tue, 11 Aug 2020 04:16:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4TJA6gLxLQI6xCLwMQg0mwHVSLMKWK4fsSpEQ9sWtmU=; b=Pk/eJ076vkvx6lT5g6q/q6SWE63dxdouHshCF5R0KpmlcCMTv2vcbQEBa8vRMyudsK kFNskcNkgQX96N7oWtfYzAXF1gDXjBz98cWjH0k8OXHyVZftEpSx11u838KtT4wNaKlg 6oZNr+HxphOxiiyKI4n4F6hLWxg8HIWNC+jHL8sVv/NVbWSQRyKguIbpOw0bwNWEe5MO +UljtLcjsUpRwOzClb9sdlwz3w7Iei4LHHmINzBwZ6yQ8KQNiFhQ1H/5Ra+uoufdCwW2 sVHjtJkf8uoQqXb1bENxJi/2WbE3hgrZ/1hRJ0pkzv4tti9cRXvD4PV7JF8FXVnpsDuB gdwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4TJA6gLxLQI6xCLwMQg0mwHVSLMKWK4fsSpEQ9sWtmU=; b=OJRRRIy3tJROmqtg5j5fpOAtwWNtEfr1ZiCjcFY+XNLWG+vL6zBkDLpFe81+xQdhzm xlT8N/782CfOuNBEDcOaP5+QAS3Og4RZo3v9oQodbpS8B1YRRW7s3/AjQFoGxXMbrdvx d0SKi1Kl/1zxCyUgSQLW9ITwz/qu8bps8Y60+ZDLAY3sbdbnrkOpP3Nzs0El1+Jg5+Yk /mahUtx+ats0EemD7K6LRmq3z2DKKtmE3s8uetp2yZikH1OyL0nwRyKkPMqWrYpVeLyJ 3uiTOOka6Nor3cylyjcL1Yo4triNrtqQUH7W/NBi+AZkmHLk51rG6XKqpZ6McJNBsRfA 7LfA==
X-Gm-Message-State: AOAM533x55EWYt/r0vyZNgE8FyjVcwGxueJI6vPe2Kj/WG4r2/l5u9ms PnHI+zeQoJf8FX0nwn+qzmJBFnNKuCDj6Nf7mrA=
X-Google-Smtp-Source: ABdhPJy+owpfTfx+F/fAcy3j2RdvVoJkRhATOS9RPreiF9F9B8gnXGgNa09yRbgyJUCWWEyu8cvNjqMu9JkLpxIwMjA=
X-Received: by 2002:a37:9c4b:: with SMTP id f72mr632794qke.332.1597144562506; Tue, 11 Aug 2020 04:16:02 -0700 (PDT)
MIME-Version: 1.0
References: <159594573523.13152.3914768057480139064@ietfa.amsl.com> <7975506A-9D32-490B-96C6-E4A1CF7EBFE1@consulintel.es> <CAKC-DJid6F0RcTAL6p_eTUOq+2WMcbJkcxSjh+pw73Fvah=hVQ@mail.gmail.com>
In-Reply-To: <CAKC-DJid6F0RcTAL6p_eTUOq+2WMcbJkcxSjh+pw73Fvah=hVQ@mail.gmail.com>
From: Jen Linkova <furry13@gmail.com>
Date: Tue, 11 Aug 2020 21:15:50 +1000
Message-ID: <CAFU7BAT8O4wuxYZEz-oPMC-tLOJ=sNk7LgO5-O6ifP+1KuE5Ag@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Cc: "v6ops@ietf.org list" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TReNYAU1qyG9zYYlx6Ad2ZvH-hE>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-03.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2020 11:16:06 -0000

Sorry, I've missed -03 being posted.
Jordi, thanks for improving the document!
First of all, I agree with all comments Erik made (see my AUD0.02 inline ;)

On Fri, Jul 31, 2020 at 4:41 AM Erik Nygren <erik+ietf@nygren.org> wrote:
> This version improves, but still seems to be missing some important items.
> I'm also still worried that it may not be safe enough and may still cause
> more problems than it solves, especially if implementations are buggy.
> (Buggy implementations in CPEs will be really hard to debug or trace back
> for people outside the network, will be hard/impossible to get fixed,  and will
> result in dual-stack content getting switched to IPv4-only to work around issues.

+1. We have a very long history of broken IPv6 deployments in
residential networks caused by buggy CPEs.

> Some specific thoughts:
>
> * Would it make sense to change away from the "MUST" implement
>   and instead require all modes to be used only with configuration by
>   the network operator?  (Having that configuration include an allowlist
>   of IP(v4) prefixes which are candidates for the optimization may further help.)
>   This at least allows this to get disabled in cases where it causing problems
>   while still letting network operators use it for content they want to optimize
>   in coordination with CDN partners.  Using this with off-the-shelf CPEs seems
>   dangerous as bugs there can have high damage risk to IPv6 content deployment
>   without a good path to fix.

I second that.
I believe it 'MUST BE disabled by default'
Taking into account the following:
- not every operator would need this;
- it's very likely that potential issues on CPEs would affect some
IPv6-enabled destinations only so it would not even look like a CPE or
the ISP network issue but more like the destination problem.
- the issues would mostly affect devices like SmartTVs etc with very
limited troubleshooting capacity (while on a laptop I can run a packet
capture or traceroute, such steps would be more difficult on a TV
box);
- troubleshooting issues with this technology is rather tricky and
might be impossible if the operator is not aware of the functionality
being quietly enabled on *some* CPEs in the network;

I believe that the operator needs to explicitly enable the feature and
make sure it's enabled on well-tested CPEs only.

> * We should add the security risk discussed previously to Security Considerations.
>   (ie, clients/apps ignoring DNS TTL can still be hijacked to other IPs even without
>   DNS spoofing if an app with the same MAC (same device or behind a NAT/router)
>   does a DNS lookup to an attacker-controlled hostname.)

The Security Section still states 'This document does not have any new
specific security considerations, besides the ones already known for
DNS64.'.
I'm not sure that this statement is correct - we have discussed
various attacks vectors).
Also it looks to me that if the CPE does not support DNSSEC, the
attacker can perform the DNS spoofing even if the host itself does
DNSSEC validation.

A few more things:
1) did I miss it or the STUN case is not addressed in -03?

2) https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03#section-5.2.3
"Note that the NAT46/CLAT MUST already know the WKP or NSP being used
in that network. "
Shall the text say that if the CPE can not discover the NAT64 prefix
the optimization MUST be disabled?

3) https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03#section-5.2.5

"The EAMT entry MUST only be created if all the following conditions are met:"
Shall it be another condition 'there is no entry for the given MAC and
the destination IPv4 address'?

Actually it would be great to describe a state machine a bit more
clearly. I found it a bit hard to follow the algorithm..(maybe it's
just me, quite possible ;)

"An EAMT entry marked as "Stale" or "Invalid", only affects the
relevant host. " - does it mean that Active EAMT entry would affect
other hosts?

4) https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03#section-5.2.11
"Because the EAMT entries are only created when the NAT46/CLAT/CE
proxy/stub DNS is being used, any hosts or applications that don't
   use DNS, will not create the relevant entries. They will not be
optimized unless EAMT entries are statically configured."

I might be missing smth but if we have two applications on the same
IPv4-only host, one has asked for A RR for a name, so an EAMT entry
got created - if the second application is trying to use the same IPv4
address (3rd-party DNS or IPv4-literals), the traffic from the second
application would be optimized as well, right?
The similar concern is for
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03#section-5.2.12
-
what happenes if one application is using the system resolver (== the
CPE) while another application is using other resolvers? It looks to
me that this scenario makes entries collisions very possible as the
CPE would not be able to invalidate the entry (by detecting 'the same
IPv4, different IPv6' case).
Am I missing smth?
>
> On Tue, Jul 28, 2020 at 10:24 AM JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
>>
>> Hi all,
>>
>> Sorry, was a bit congested with other work last week to finish this version..
>>
>> I'm still working in some of the previous emails, to make sure that this version has addressed them. I will be responding ASAP.
>>
>> Regards,
>> Jordi
>> @jordipalet
>>
>>
>>
>> El 28/7/20 16:16, "v6ops-bounces@ietf.org en nombre de internet-drafts@ietf.org" <v6ops-bounces@ietf.org en nombre de internet-drafts@ietf.org> escribió:
>>
>>
>>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>     This draft is a work item of the IPv6 Operations WG of the IETF.
>>
>>             Title           : 464XLAT/MAT-T Optimization
>>             Authors         : Jordi Palet Martinez
>>                               Alejandro D'Egidio
>>         Filename        : draft-ietf-v6ops-464xlat-optimization-03.txt
>>         Pages           : 24
>>         Date            : 2020-07-28
>>
>>     Abstract:
>>        IP/ICMP Translation Algorithm (SIIT) can be used to provide access
>>        for IPv4-only hosts or applications to IPv4-only or dual-stack
>>        destinations over IPv6-only infrastructure.  In that case, the
>>        traffic flows are translated twice: first from IPv4 to IPv6
>>        (stateless NAT46 at the ingress point to the IPv6-only
>>        infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
>>        the egress point).  When the destination is IPv6-enabled, the second
>>        translation might be avoided.  This document describes a possible
>>        optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
>>        back to IPv4 if the destination is reachable over IPv6.  The proposed
>>        solution would significantly reduce the NAT64 utilization in the
>>        operator's network, increasing the performance.
>>
>>
>>     The IETF datatracker status page for this draft is:
>>     https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/
>>
>>     There are also htmlized versions available at:
>>     https://tools.ietf..org/html/draft-ietf-v6ops-464xlat-optimization-03
>>     https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-03
>>
>>     A diff from the previous version is available at:
>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-03
>>
>>
>>     Please note that it may take a couple of minutes from the time of submission
>>     until the htmlized version and diff are available at tools.ietf.org.
>>
>>     Internet-Drafts are also available by anonymous FTP at:
>>     ftp://ftp.ietf.org/internet-drafts/
>>
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     v6ops@ietf.org
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> 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.
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops



--
SY, Jen Linkova aka Furry