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

[Gorry Fairhurst <[e-mail]>]

On 23/04/2024 20:32, Ron Bonica wrote:
> Hi Gorry,
>
> Thanks for the thoughtful review. Responses inline [RB]....
>
>                 Ron
>
>
Ron, these comments were written primarily for the transport area 
directors, so this thread is not about the appropriateness of the spec., 
only about whether there are topics that might touch on transport 
operation. See below [GF].


Best wishes,

Gorry

> 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.
>
[GF] Fine, if this is sent for logging.
>
> 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.

[GF] I think your answer indicates you expect this is only for logging 
information that a problem exists.

--

>
> 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.
>
[GF] I don't if this is only logged, then this is fine.
--
>
> 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.
>
[GF] I'd suggest good practice is that it SHOULD be rate-limited. Others 
will know current IETF recommended practice.


---

> 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.
>
[GF] Then, in that case, I do think the ID ought to say this in a 
sentence - this isn't about whether the is acceptable or not, it's about 
noting the implication so that people know this is how it works.

--

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

[GF] Then, I think the ID ought to say this in a sentence - this isn't 
about whether the is acceptable or not, it's about noting the 
implication so that people know this is how the transport needs to work.

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

[GF] This could have been helpfully noted in 13 as something to explore.

---

>
> 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 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.
>
[GF] I didn't see an answer as to why this is an EXP spec is to be 
published.

---

>
> 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?
>
[GF] I agree the topic is generic - but so also is the list of 
network-related topics in 13. Including some transport-related 
experience in that list could prove useful.

---

> * 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.
[GF] That would be helpful.
>
> 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.

[GF]  So, that seems like an unsupported statement, if there had been an 
IETF talk, github URL, or something else, at least someone can find ourt 
what the state of implemenetation and deployment was at the time of 
publicatinon.


It looks to me that the state of implemenetation and deployment and 
could be near zero.

---

>
> * 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.
[GF] Thanks.
>
> - 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.
>
>
[GF] Thanks.
---
>
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art