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

[Mark Smith <[e-mail]>]

Hi,

On Thu, 30 May 2024 at 10:20, Tom Herbert
<tom=[e-mail]> wrote:
>
> On Wed, May 29, 2024 at 4:23 PM Ron Bonica
> <rbonica=[e-mail]> wrote:
> >

<snip>

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

As this issue only occurs for TCP, UDP and ICMPv6, and only occurs
because those protocols' pseudoheader checksum is covering the CRH
IPv6 header, I think the solution is to insert another IPv6 header
between the outer CRH IPv6 header and the TCP, UDP or ICMPv6 payload,
with the packet's originating SA and final DA.

The TCP, UDP or ICMPv6 pseudoheader checksums would then only cover
the new IPv6 header, and that IPv6 header would not be changed during
transport over CRH.

Middle boxes shouldn't be validating the TCP, UDP or ICMPv6
pseudoheaders in that case, as the new IPv6 header should hide those
payloads from the middlebox. However, even if a middlebox did validate
the pseudheader checksums, they would pass because the new IPv6 header
isn't changed in flight over the CRH substrate.

(An alternative perspective. CRH (and SRv6) are replacements for MPLS.
TCP, UDP or ICMP were never "bare" or directly in MPLS, there was
always an IP header in between the MPLS and TCP, UDP or ICMP headers,
so there also should be for CRH and SRv6. MPLS is a data link layer
protocol from the perspective of the network layer, and therefore so
are CRH and SRv6.)

Regards,
Mark.








> 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:
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------