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

[Fernando Gont <[e-mail]>]

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.”