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