[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 7:05 PM Mark Smith <[e-mail]> wrote:
>
> 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.)

Mark,

Mark,

I'm not sure we need a solution, I just think we need to document the
change so people are aware of the potential impact.

Also, I believe that with CRH there is no way to determine the final
destination of a packet without external information that may be
temporal. This could also affect ops (like if we're doing a post
mortem on traces from the network we'd need the routing table from the
time the logs were taken. It might be hard to do connection tracking
as well. I think this should be documented as well.

Tom



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