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
- [v6ops] Some comments on draft-ietf-v6ops-ipv6-de… Fernando Gont
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Paolo Volpato
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Fred Baker
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Brian E Carpenter
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Brian E Carpenter
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Fernando Gont
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Brian E Carpenter
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Fred Baker
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Fernando Gont
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Alexandre Petrescu
- Re: [v6ops] Some comments on draft-ietf-v6ops-ipv… Paolo Volpato