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. 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. 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? 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? 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? 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? 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. 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. 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? 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. * 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? 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. * 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. - RFC8704 is a useful reference: It was not clear why RFC8704 was normative - it does not appear to rely upon this. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
