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

[Brian E Carpenter <[e-mail]>]

Fernando's points are all correct.

Some people may remember that we killed draft-ietf-iab-case-for-ipv6 20 years ago because it made too many dubious public relations claims for IPv6. The current draft still has similar problems.

On one point, I believe that there are measured scenarios where IPv6 performance is better than IPv4, and the opposite, but a general claim without data definitely does more harm than good.

(The authors of https://www.researchgate.net/publication/335865993_IPv6_in_production_its_deployment_and_usage_in_WLCG may have current data, for example.)

Regards
    Brian Carpenter

On 22-Apr-22 23:48, Fernando Gont wrote:
> 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 [e-mail] about the unintended receipt of this electronic message and delete it.”
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>