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

[Paolo Volpato <[e-mail]>]

Hi Fernando,
Thanks for your comments.
Definitely, you are not late. We have just started to review the draft, it shouldn't be so difficult to accommodate them.
Please find some comments inline marked as [PV].

Best regards
Paolo

-----Original Message-----
From: v6ops <[e-mail]> On Behalf Of Fernando Gont
Sent: Friday, April 22, 2022 1:48 PM
To: V6 Ops List <[e-mail]>
Cc: [e-mail]
Subject: [v6ops] Some comments on draft-ietf-v6ops-ipv6-deployment

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?

[PV] We'll review the sentence

* 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)

[PV] Right, but here we meant the end-to-end relationship at the network layer, not at the layers above it. This is why we focused on NATs.
We will better specify this concept in the next version.

* 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."

[PV] Well, this sentence intended to highlight the extensibility of IPv6 in comparison to IPv4.
Later in the document (sec. 7.5.2) we also highlighted the issues related with EHs. Anyway we'll review this sentence to make it "less optimistic" (more realistic :-)

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

[PV] Brian also had similar comments to this point. We plan to delete these sentences

* 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?

[PV] Agree that re-reading the sentence you may have this doubt. We'll review it

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

[PV] Ok, we will add more details in this section, in particular on ICMPv6 and ND threats (which was our intended target)

* Section 7.5.2, page 33:

A reference to RFC8990 is probably warranted here.

[PV] Guess it is RFC 9098 as below, right? If so, ok

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

[PV] Ok

* Section 7.5.2, page 33:

"   Additionally, packets with IPv6 Extension Headers may be dropped in
    the public Internet."

Ditto for RFC7872.

[PV] Good suggestion

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

[PV] Right, we will revise the sentence to also update the references. 2 of them now have been adopted

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

[PV] Ok

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

[PV] Ok

* 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."

[PV] Ok, we will review the sentence by highlighting the current trend in the IETF and the different proposals about the use and limits of the EHs 

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

[PV] Right, we'll fix this sentence

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