[IPv6]Re: Éric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)

[Tom Herbert <[e-mail]>]

On Wed, May 29, 2024 at 4:23 PM Ron Bonica
<rbonica=[e-mail]> wrote:
>
> Eric,
>
> Please see responses, inline [RB].
>
> I have posted an updated version of the draft so that you can clear.
>
>                                                             Ron
>
>
>
> Juniper Business Use Only
>
> ________________________________
> From: Éric Vyncke via Datatracker <[e-mail]>
> Sent: Wednesday, May 29, 2024 3:16 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Subject: Éric Vyncke's Discuss on draft-ietf-6man-comp-rtg-hdr-08: (with DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-6man-comp-rtg-hdr-08: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcjnBaXmI$
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZZQBom0$
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-6man-comp-rtg-hdr-08
>
> Thank you for the work put into this document. I do like the idea of
> compressing SRH-like header, but the document has room for improvements.
>
> Please find below some blocking DISCUSS points (easy to address), some
> non-blocking COMMENT points (but replies would be appreciated even if only for
> my own education), and some nits.
>
> Special thanks to Bob Hinden for the shepherd's detailed write-up including the
> WG consensus *but* it lacks the justification of the intended status (and IMHO
> experimental is the right one).
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> # DISCUSS (blocking)
>
> As noted in https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmcZOFq8Vg$ , a
> DISCUSS ballot is a request to have a discussion on the following topics:
>
> ## Section 5
>
> `Decrement the IPv6 Hop Limit.` what do to when hop limit is 0 ? Is there a
> deviation from RFC 8200 section 3, else why repeating this step ?
>
> [RB] Agree. IPv6 has decremented the hop limit before the extension header is processed. So, decrementing it again would be a bad thing. I have deleted this step.
>
>
>
> ## Section 7
>
> It is not clear to me why this document needs to make an allowance for
> intermediate nodes (sic) that verify transport layer checksums. Transport layer
> checksums are expected to be verified by the Transport layer endpoints and not
> in the network. So since when the Internet architecture has changed to take
> care of `it prevents intermediate nodes from verifying transport layer
> checksums`? Actual references are required for such statement. And,
> explanations should be given whether this "sentence" helps RFC 7258 pervasive
> monitoring perhaps in the security considerations section.
>
> [RB] Agree. I have deleted section 7.

Ron, Eric,

While the expectation may be that only endpoints will verify the
checksum, since it's in plain text there is nothing that prevents
intermediate nodes from processing it and potentially filtering bad
packets with bad checksums (similar to other non-standard cases of
devices doing Deep Packet Inspection and looking at TCP options or
other parts of transport layer headers). Also, I believe that could
break NAT? On a more programmatic side, snooping tools will report bad
L4 checksums in their output; this has been very useful in  deployment
for debugging checksum failures (i.e. trying to figure out where the
error was introduced in the path).

I don't immediately know of any other cases where the checksum would
be incorrect on the wire, so this is potentially breaking a
longstanding convention that falls under the be conservative in what
you send philosophy. IMO, at least documenting it is prudent.

Tom

>
>
> ## Section 11
>
> While not a real DISCUSS criteria, I am really surprised to see an IPv4-like
> notation for CRH SID.
>
> [RB] Why not. IPv4-like is a convenient and familiar notation for 32-bit values.
>
> ## Section 12
>
> As AH is end-to-end, intermediate nodes do not have the shared secret, hence
> `The CRH is not compatibile with AH processing at intermediate nodes.` is
> useless and confusing. Please remove. Very similar to the DISCUSS about section
> 7.
>
> [RB] Agree. I have removed that sentence.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # COMMENTS (non-blocking)
>
> ## Abstract
>
> Can we really write `deployed` for an experimental I-D?
>
> [RB] The purpose of any IETF experiment is to demonstrate that something can be deployed. You nay want to deploy in a low-risk environment at first. But if you can't demonstrate deployability, why bother.
>
> ## Section 1
>
> s/to its destination/to its destination(s)/ (think multicast/anycast). Twice in
> the section ;)
>
> [RB] Done
>
>
>
> Suggest to move the motivation to its own section.
>
> ## Section 3
>
> Any recommendation on when to do `The first CRH SID in the path can be omitted
> from the list.`?
>
> What is the expected behavior of any CRH-aware router and final node(s) when
> `the Type- specific data field MUST be padded with zeros` is not respected ?
>
> ## Section 4
>
> Can the IPv6 address in the CRH-FIB be a link-local or multicast or can only be
> a unicast ? Section 5 gives some more explanations, but an early one would be
> better.
>
> ## Section 5
>
> The first bullet can probably be removed as it is the normal behavior of any
> IPv6 node per RFC 8200.
>
> `If Hdr Ext Len indicates that the CRH is larger than the implementation can
> process, ` suggest using code 6 per
> https://urldefense.com/v3/__https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml*icmpv6-parameters-codes-5__;Iw!!NEt6yMaO-gk!DVJoms2WoGvxmxqkffXENdtHNjV3fbIs-eqSaGApHrZ_QLRG6sy7korNjjBzml5sJ7eFURmc25Y-TxM$
>
> While wasting octets with too large CRH (i.e., larger than the minimum length)
> is a bad thing, does it deserve to discard the packet on transit ? Why not
> requesting the source to enforce this mimimum length?
>
> `If the search does not return a CRH-FIB entry` is the code 0 the most suitable
> code ? If not, why not creating one ? Or even using ICMPv6 code 1 'destination
> unreachable' ?
>
> `If Segments Left is greater than 0` this will always be the case per first
> bullet `If Segments Left equals 0` ;-)
>
> The reader will welcome a justification of `CRH-FIB entry contains a multicast
> address, discard the packet and`.
>
> ## Section 6
>
> I guess that this is linked to RFC 4302 (AH), so, please state this clearly.
>
> ## Section 7
>
> Is it about `Destination Address Transparency` or privacy ?
>
> ## Section 8
>
> `Each CRH SID is processed by exactly one node.` isn't it rather "Each CRH SID
> is processed by exactly one CRH-configured router whose one address matches the
> packet destination address" ?
>
> ## Section 9
>
> The title should rather be "operational considerations"
>
> What are the "representations described herein" in ` It is recommended that the
> experimental versions of PING use the text representations described herein` ?
> Is it about section 11 ? Then please add a forward reference.
>
> ## Section 10
>
> This is the usual considerations about ICMP, please consider to remove this
> section. Or refer for section 5 of RFC 4443.
>
> ## Section 11
>
> Beside the above semi-DISCUSS, please state that hexadecimal should be in lower
> case.
>
> ## Section 12
>
> `The Source Address does not identify an interface on a trusted node.` is there
> any hint how this can be done ? How will it scale if all CRH-enabled router
> must know all the specific address of all trusted nodes ? The same scalability
> issue for `The ACL discards packets whose source address identifies an
> interface on a trusted node.`
>
> ## Section 13
>
> If the Wireshark/tcpdump modifications (cited in section 9) are public, then
> references to code will be welcome.
>
> `Interoperability among these implementations has not yet been demonstrated.`
> should rather be in section 14 'experimental results'
>
> ## Section 14
>
> I am indeed very curious to see the experimental result of
> ```
> Mechanism used to populate the FIB
> Scale of deployment
> ```
> even if the text states in one year after publication as an RFC, this work
> started back in 2019 and was adopted in 2023, do we already have some results ?
>
> What are the possible next steps as seen by the authors / 6MAN WG is the
> experiment is assumed to be successful ? And what are the criteria to declare a
> successful experiment ?
>
> # NITS (non-blocking / cosmetic)
>
> ## Section 12
>
> s/This is becasue /This is because/
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------