Re: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 28 April 2022 08:48 UTC

Return-Path: <alexandre.petrescu@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 A58B8C14F74B for <v6ops@ietfa.amsl.com>; Thu, 28 Apr 2022 01:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.188
X-Spam-Level:
X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.857, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gziPGlCP2-GB for <v6ops@ietfa.amsl.com>; Thu, 28 Apr 2022 01:48:52 -0700 (PDT)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D92C1595E6 for <v6ops@ietf.org>; Thu, 28 Apr 2022 01:48:51 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 23S8mnlh019498 for <v6ops@ietf.org>; Thu, 28 Apr 2022 10:48:49 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F45B2029D5 for <v6ops@ietf.org>; Thu, 28 Apr 2022 10:48:49 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 357DB202D2C for <v6ops@ietf.org>; Thu, 28 Apr 2022 10:48:49 +0200 (CEST)
Received: from [10.8.32.130] (is245935.intra.cea.fr [10.8.32.130]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 23S8mnk6025685 for <v6ops@ietf.org>; Thu, 28 Apr 2022 10:48:49 +0200
Message-ID: <69d7d9a5-f597-897f-d1ca-5d0395834a6d@gmail.com>
Date: Thu, 28 Apr 2022 10:48:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1
Content-Language: fr
To: v6ops@ietf.org
References: <3008655b-2af6-7df0-1302-63cf81bad8b4@edgeuno.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
In-Reply-To: <3008655b-2af6-7df0-1302-63cf81bad8b4@edgeuno.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/dYHxN-hHsqk7txYknTLJsrdQq7w>
Subject: Re: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.34
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: Thu, 28 Apr 2022 08:48:55 -0000

One additional comment:

> For example, a mobile carrier will assign one or several /64 prefixes
> to the User Equipment (UE).

'will'?  But when?

I am asking because all I could see is allocating a single /64 prefix to
the UE, to a connection of single SIM card that is.

(I know there are some UEs that have multiple SIM cards, and hence
multiple modems, and hence might get multiple /64s; but that is very
expensive and is not practiced to a wide scale.  If we talk about
multiple SIM cards when talking multiple /64s per unique UE, then we
should say so, because the costs vary from simple to double - cant be
ignored).

(or maybe one thinks that in the future, multiple /64s might be
allocated to an UE, by some standard, which is a different thing than
the implementation, and this draft is about deployment which presumable
means implementation).

Alex

Le 22/04/2022 à 13:48, Fernando Gont a écrit :
> HI, All,
> 
> Apologies for the bad timing (I guess it could still be worse...
> i.e., past IETF-LC ;-)  ).
> 
> I've read through the I-D, and it seems that there are a number of 
> claims that seem to be technically inaccurate.
> 
> These are my comments:
> 
> 
> * Section 6, page 24:
> 
> "   4.  Future Proof: IPv6 was designed from scratch to be
> future-proof, despite some incompatibilities with IPv4. "
> 
> Isn't IPv6 *fully* incompatible with IPv4?
> 
> 
> * Section 6, page 24: "     A side effect to that, this approach
> brings the connectivity model back to the end-to-end client/server 
> paradigm."
> 
> It's not just NATs, but firewalls and other middle-boxes. So no, I
> think that ship has sailed already. (see e.g.: 
> https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-considerations#section-4.3)
> 
> 
> 
> 
> * Section 6, page 24: "The introduction of new functionality is one
> of the technical benefit of IPv6 due to the flexible structure of the
> packet header.  The IETF is currently active in defining operational
> recommendations for the usage of Extension Headers and Options left
> open by the base standards."
> 
> But then Geoff Huston argues in 
> https://blog.apnic.net/2022/03/25/notes-from-the-iepg-meeting-at-ietf-113/
>
> 
that:
> 
> "....all IPv6 extension headers are unusable in the public IPv6
> Internet and proposals to carry information in such headers are
> completely unrealistic in this context. The conclusion is simple: If
> you want to deploy a robust service on the IPv6 public Internet then
> you should avoid any use of extension headers."
> 
> 
> 
> * Section 7.5, page 31:
> 
> "  There are some concerns in terms of the security but, on the
> other hand, IPv6 offers increased efficiency.  There are measurable 
> benefits to IPv6 to notice, like more transparency, improved 
> mobility, and also end to end security (if implemented)."
> 
> This is wrong, or misleading at best.
> 
> First of all, you're discussing security, and you;re kind of saying 
> "IPv6 security is bad... but well, the protocol is fast" -- in the 
> context of a discussion of security, who cares about the later? :-)
> 
> The statement that IPv6 offers increased efficiency is also
> misleading. If you;re going to make that claim, please provide a
> reference. (Note: measurements tend to argue the other way around).
> 
> "Improved mobility" probably refers to mobile-IP. But, what's the
> level of mobile-ip deployment/usage?  Do folks still have any hopes
> on mobile ip?
> 
> "End to end security" might also be misleading. You can deliver "end
> to end security" with IPv4 as well.
> 
> 
> * Section 7.5, page 31:
> 
> "  However, this is turning also in the other way around, as with
> more IPv6 deployment there may be older IPv4 flaws not discovered or
> even not resolved anymore by vendors."
> 
> Are you really expecting that vendors will stop patching IPv4 
> vulnerabilities anytime soon?
> 
> 
> * Section 7.5.1, page 31:
> 
> "Since it is used in many IPv6 related protocols, ICMPv6 packet with
> multicast address should be filtered carefully to avoid attacks."
> 
> Multicast packets don;t generally represent an issue, since in most 
> networks you won't have multicast routing, anyway.
> 
> 
> * Section 7.5.2, page 33:
> 
> A reference to RFC8990 is probably warranted here.
> 
> 
> 
> * Section 7.5.2, page 33:
> 
> "   IPv6 Extension Headers imply some issues, in particular their 
> flexibility also means an increased complexity, indeed security 
> devices and software must process the full chain of headers while 
> firewalls must be able to filter based on Extension Headers."
> 
> At the risk of sounding our own horn, a reference RFC9098 is
> probably warranted here.
> 
> 
> 
> * Section 7.5.2, page 33:
> 
> "   Additionally, packets with IPv6 Extension Headers may be dropped
> in the public Internet."
> 
> Ditto for RFC7872.
> 
> 
> * Section 7.5.2, page 33:
> 
> "Some documents, e.g. [I-D.hinden-6man-hbh-processing],
> [I-D.bonica-6man-ext-hdr-update], [I-D.peng-v6ops-hbh] analyze and
> provide guidance regarding the processing procedures of IPv6
> Extension Headers."
> 
> They don't really provide guidance, but rather aim at changing the 
> standard. Please also note that all of them seem to be individual 
> submissions, and not wg documents.
> 
> 
> * Section 7.5.2, page 33:
> 
> "   There are some possible attacks through EHs, for example RH0 can
> be used for traffic amplification over a remote path and it is 
> deprecated. "
> 
> One should not that probably most IPv6-related vulnerabilities have
> been associted with implementation flaws in the processing of IPv6
> extension headers.
> 
> 
> * Section 7.5.2, page 33: "There are some possible attacks through
> EHs, for example RH0 can be used for traffic amplification over a
> remote path and it is deprecated.  Other attacks based on Extension
> Headers are based on IPv6 Header Chains and Fragmentation that could
> be used to bypass filtering, but to mitigate this effect, Header
> chain should go only in the first fragment and the use of the IPv6
> Fragmentation Header is forbidden in all Neighbor Discovery
> messages.
> 
> Fragment Header is used by IPv6 source node to send a packet bigger 
> than path MTU and the Destination host processes fragment headers. 
> There are several threats related to fragmentation to pay attention 
> to e.g. overlapping fragments (not allowed) resource consumption 
> while waiting for last fragment (to discard), atomic fragments (to
> be isolated)."
> 
> A reference to RFC8200 is probably warranted here. Also one to
> RFC6980.
> 
> 
> 
> 
> * Section 7.5.2, page 33: " A lot of additional functionality has
> been added to IPv6 primarily by adding Extension Headers and/or using
> overlay encapsulation."
> 
> But then Geoff Huston argues in 
> https://blog.apnic.net/2022/03/25/notes-from-the-iepg-meeting-at-ietf-113/
>
> 
that:
> 
> "The high order takeaway from both of these measurements is that all 
> IPv6 extension headers are unusable in the public IPv6 Internet and 
> proposals to carry information in such headers are completely 
> unrealistic in this context. The conclusion is simple: If you want
> to deploy a robust service on the IPv6 public Internet then you
> should avoid any use of extension headers."
> 
> 
> 
> * Section 7.5.2, page 33: "All of the these expand the packet size
> and this could lead to oversized packets that would be dropped on
> some links.  It is important to investigate the potential problems
> with oversized packets in the first place. "
> 
> In many (most?) cases, it's the presence of IPv6 EHs or the length
> of the EH chain that leads to drops, rather than the overall packet
> size itself.
> 
> Thanks!
> 
> Cheers, -- Fernando Gont Director of Information Security EdgeUno PGP
> Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
> 
> 
> 
> 
> “This communication is the property of EdgeUno or one of its group 
> companies and/or affiliates. 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 if you are not the intended recipient be aware that any 
> non-explicitly 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. Please notify legal@edgeuno.com about the
> unintended receipt of this electronic message and delete it.”
> 
> _______________________________________________ v6ops mailing list 
> v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops