Re: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment
Paolo Volpato <paolo.volpato@huawei.com> Fri, 29 April 2022 07:13 UTC
Return-Path: <paolo.volpato@huawei.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 2DE14C15948A; Fri, 29 Apr 2022 00:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 csCoFDOzmhVB; Fri, 29 Apr 2022 00:13:24 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA57C157B5E; Fri, 29 Apr 2022 00:13:24 -0700 (PDT)
Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KqNrl45gkz67PcQ; Fri, 29 Apr 2022 15:09:11 +0800 (CST)
Received: from fraeml740-chm.china.huawei.com (10.206.15.221) by fraeml738-chm.china.huawei.com (10.206.15.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 29 Apr 2022 09:13:20 +0200
Received: from fraeml740-chm.china.huawei.com ([10.206.15.221]) by fraeml740-chm.china.huawei.com ([10.206.15.221]) with mapi id 15.01.2375.024; Fri, 29 Apr 2022 09:13:19 +0200
From: Paolo Volpato <paolo.volpato@huawei.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ietf-v6ops-ipv6-deployment@ietf.org" <draft-ietf-v6ops-ipv6-deployment@ietf.org>
Thread-Topic: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment
Thread-Index: AQHYWtzHBu2fmQjMfkCz5GO0FYbR1a0GdRGQ
Date: Fri, 29 Apr 2022 07:13:19 +0000
Message-ID: <c2c177294ece43ef97f009a170caa652@huawei.com>
References: <3008655b-2af6-7df0-1302-63cf81bad8b4@edgeuno.com> <69d7d9a5-f597-897f-d1ca-5d0395834a6d@gmail.com>
In-Reply-To: <69d7d9a5-f597-897f-d1ca-5d0395834a6d@gmail.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.204.160]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xLnF5kaMGj3HEX-UO42nDLWMVIA>
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: Fri, 29 Apr 2022 07:13:28 -0000
Hi Alexandre, Thank you for your comment. The idea was to provide an example of assignment of multiple prefixes to a user equipment, but I agree that referring it to a mobile device is probably not the good choice (it should be more general, like multiple assignments to a CPE). We will address your comment in the current revision of the draft. Best regards Paolo -----Original Message----- From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Alexandre Petrescu Sent: Thursday, April 28, 2022 10:49 AM To: v6ops@ietf.org Subject: Re: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment 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 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