Re: [IPv6] Tsvart last call review of draft-ietf-6man-comp-rtg-hdr-05

[Ron Bonica <[e-mail]>]

Hi Gorry,

Thanks for the thoughtful review. Responses inline [RB]....

                Ron



Juniper Business Use Only

________________________________
From: Gorry Fairhurst via Datatracker <[e-mail]>
Sent: Monday, April 22, 2024 3:16 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Tsvart last call review of draft-ietf-6man-comp-rtg-hdr-05

[External Email. Be cautious of content]


Reviewer: Gorry Fairhurst
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

* Summary

This is a simple, and well-written draft that is intended to be published with
EXP status. It adds a new header to IPv6 carried as a routing EH. Although this
is at the network layer, there are some subtle implications on transport that
deserve consideration.

[RB] Thanks!

Review Comments:

In each case of sending an ICMPv6 Parameter Problem, the resulting error
message might or might not reach the source node - as usual, it could be wise
to note this.

[RB] Does this need to be mentioned in every RFC that originates ICMP messages? Or can we assume that readers know what ICMP is and know that ICMP delivery is not reliable.

[RB] In the interest of maintaining this document's signal to noise ratio, I lean towards the second option.


Source Node Processing: What is expected to happen if this ICMPv6 Parameter
Problem is received? Is the source node expected to log it, to react to it?

I am not aware of any IPv6 stack that processes ICMP Parameter Problem messages differently, depending on which parameter was problematic.

[RB] Neither am I! And I think that there is a very good reason for this. The pointer field in the ICMP Parameter Problem Message is unreliable.

[RB] Assume that an IPv6 packet contains three extension headers. All three have a have a type and a length attribute. However, the length attribute in the first header is off by one.  While the packet cannot be parsed, it is difficult, if not impossible, to determine that the first extension header was the one that had a problem. The pointer will probably point further into the packet.

[RB] For that reason, most implementations process all incoming ICMP Parameter Problems identically. This probably should have been mentioned in RFC 4443. But it is beyond the scope of this document.

Transport Security Consideration:  To allow closing a DoS opportunity to create
work at an endpoint, how can the source node verify that ICMPv6 messages
originate from a router on the path - can it check the packets content somehow?

[RB] It can't. But isn't this a generic ICMP problem? While it is an interesting problem, it should be addressed in a generic analysis of ICMP, not in the CRH draft.


Transport Security Consideration:  A note in the ID says: "In the description
above, ICMPv6 messages are subject to rate limits.", which appears valuable
advise. It does not motivate why ICMPv6 messages SHOULD be rate limited, which
I think it ought to be, although such rate-limiting is likely re-using existing
procedures?

[RB] Again, this is a generic ICMP problem. While it is an interesting problem, it should be addressed in a generic analysis of ICMP, not in the CRH draft.

[RB] This might be a good topic for a graduate student thesis. If you have a student looking for a topic, I would be glad to work it with them.

Transport Middlebox: Because the dest address is not the final destination as
the packet is processed on-path, this prevents intermediate nodes from
verifying transport layer checksums. - This sounds like it could raise a
potential issues in some types of middle box. Since the actual destination is
carried in the EH, ought this to be used in a checksum computation by any
middlebox before it consults any of the transport data? What are the thoughts?
Ought this to be separately identified in a section?

[RB] Section 7 of the CRH draft addresses this topic. If this solution is unacceptable, it should also be raised with regard to draft-ietf-spring-srv6-srh-compression-15. It has the exact same problem and the exact same solution.

Transport Integrity Consideration:  It would seem the final destination needs
to verify the transport checksum, while this is a general requirement for IPv6,
this perhaps ought to be explicitly noted here, because label-swapping methods
that move addresses around could potentially introduce errors that would
otherwise go undetected.

[RB] The source node calculates the transport layer checksum using the packet's ultimate destination address. That address MUST be in the packets IPv6 Destination Address field when it arrives at the ultimate destination. If it is not, the packet should not pass checksum validation. Again, draft-ietf-spring-srv6-srh-compression-15 is in the exact same situation. If this is really a problem, it should be raised with regard to both drafts.


Transport Interface Consideration:  Any EH can take away from space available
from the configured MTU or discovered PMTU at the source. It seems that many
on-path routers in addition have limits on fast-path/hardware-based/etc routing
that could result in a constraint to the total size available for an EH. These
have implications on the maximum size of segment that a transport can send, but
they are the same as any other EH.

[RB] Again, this is a generic problem, and is not specific to the CRH. Does it need to be mentioned in ever draft that specifies an extension header. Or maybe in a separate document?

Status: Section 13 does provide some useful insight into what might be learned
from the experiments, this just seems to stop short of saying why the EXP
status is being used. This could perhaps be related to the dropping (and in
some cases black-holing of packets that have this header added). So, why is
this ID is EXP and what is the potential risk of this being used and what
experience is needed to allow it to be PS?

[RB] The decision to publish as EXP was made entirely in the political layer. It had to do with competition between this draft and draft-ietf-spring-srv6-srh-compression-15.

[RB] However, I do believe that every experimental draft should include something like Section 13.


Transport Consideration: It would be helpful to note that the probability of
successful transmission depends on support by specific routers in the path so
that transport protocols that need to race packets with and without the EH
could understand the likely outcomes.

[RB] Is this not true of all routing types? If so, does this detail belong in every document that specifies a routing type, or does it belong in its own document?

* Comments on external references:

The ID states TCPDUMP and Wireshark have been extended to support the CRH.
- There is no reference provided, it's hard to understand further. Is this in
mainstream?

[RB] I will look for a reference.

Section 12 describes "Implementation and Deployment Status", this is welcome
but provides no details or supporting links to material, so it so hard to
assess what this means.

[RB] The experimenters did not publish anything.

* Comments on Normative References:

- RFC8201 is a useful reference: It was not clear why RFC8201 was normative -
it does not appear to rely upon this, but would benefit from this.

[RB] True. This reference could have been informative.

- RFC8704 is a useful reference: It was not clear why RFC8704 was normative -
it does not appear to rely upon this.

[RB] True. This reference could have been informative.