|
Hi Gorry,
Thanks for the thoughtful review. Responses inline [RB]....
Ron
Juniper Business Use Only
From: Gorry Fairhurst via Datatracker <noreply@xxxxxxxx>
Sent: Monday, April 22, 2024 3:16 PM To: tsv-art@xxxxxxxx <tsv-art@xxxxxxxx> Cc: draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx <draft-ietf-6man-comp-rtg-hdr.all@xxxxxxxx>; ipv6@xxxxxxxx <ipv6@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx> 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 tsv-art@xxxxxxxx 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.
|
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
