Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr

[Tom Herbert <[e-mail]>]

On Fri, Nov 3, 2023 at 12:56 PM Ron Bonica <[e-mail]> wrote:
>
> Hi Tom,
>
> Thanks for the review. Response inline[RB].
>
>                              Ron
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Wednesday, November 1, 2023 11:41 PM
> To: Ron Bonica <rbonica=[e-mail]>
> Cc: Tony Przygienda <[e-mail]>; Joel Halpern <[e-mail]>; 6man <[e-mail]>; [e-mail]
> Subject: Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg-hdr
>
> [External Email. Be cautious of content]
>
>
> On Wed, Nov 1, 2023 at 5:06 PM Ron Bonica <rbonica=[e-mail]> wrote:
> >
> > Tony,
> >
> >
> >
> > Please do not confuse the CRH with SRv6 or SR. The CRH can be used on any IPv6 packet that doesn’t include another Routing Header type. It can be used in the absence of the SR control plane.
>
> Hi Ron,
>
> Just to clarify: Is it true that CRH is only an IPv6 routing header and doesn't require any modifications or considerations to IPv6 or any other protocols,
>
> [RB] True. The CRH is just another Routing Header and it is fully compliant with RFCs 4291 and 8200.
>
>  and that CRH will not need its own EtherType (i.e.
> CRH is IPv6 and conformant with RFC8200)?
>
> [RB] CRH does not required its own Ethertype.
>
> Also, at any given point in a packet's lifetime, can the final destination address of the packet be unambiguously determined just by inspecting the packet with CRH without needing any external context?
>
> [RB] No. The CRH contains a list of 2 or 4 byte Segment Identifiers. These are not to be confused with SRv6 SIDS. They are different. The only reason they are called SIDs is because all Routing Headers contain a field called "Segments Left".
>
> [RB] The final SID references a CRH-FIB entry that needs to exist only on the node that processes that SID. The CRH-FIB entry maps the SID to a real, RFC 4291, IPv6 address.
>
> And if any intermediate node were to try to validate a transport layer checksum with a pseudo header in flight for packets with a CRH, would it yield the same result (valid/invalid csum) as the final destination will get (I assume if the final destination can be derived from the packet the answer should be yes).
>
> [RB] No, it would not. The transport layer always uses the ultimate destination address to calculate the pseudo-header checksum. Intermediate nodes would have no way to determine the ultimate destination address because a) they probably do not recognize the CRH and b) even if they do recognize the CRH, they probably wouldn’t have the CRH-FIB entry required to determine the ultimate destination address.
>
> [RB] This issue isn’t unique to the CRH. Think about any other unrecognized Routing Header type, or even the SRv6 uSID.

Hi Ron,

>From RFC8200: "If the IPv6 packet contains a Routing header, the
Destination Address used in the pseudo-header is that of the final
destination."

I believe for all the currently defined routing headers, including
SRv6, the final destination can be derived from the routing header
without requiring any external state. If someone captures a pcap file
we should be able to parse the routing header to get the final
destination address and use that for checksum verification. The real
final destination is also needed to identify what flows packets belong
to. These are useful at least for diagnostics and debugging, but could
be used operationally in some scenarios.

If the last segment is a compressed SID that requires an external
state like CRH-FIB to decompress then we can no longer deduce the
final destination by just inspecting the packet. To me this is a loss
of useful functionality. It would be nice if we could retain this.
Maybe the last entry could be compressed in such a way that it doesn't
require an external state to decompress? (like RPL maybe?).

While the loss of the ability to determine the final address creates
some problems, it is at least manageable since we can identify packets
where the final destination cannot be deduced based on the presence of
Routing Headers in the packet with certain types.  The case that a
compressed SID is used in the Destination Address without a Routing
Header (like in draft-ietf-spring-srv6-srh-compression) is more
problematic. If this is deployed in a network then there will start to
be many packets with bad checksums detected when packets are traced at
routers. Since there's no routing header, there is no way to tell
without external information if these are truly bad checksums or not,
so debugging bad checksums in the network would be next to impossible.
A solution to that would be to update the transport layer checksum
updated each time the Destination Address changes following standard
procedures for NAT. That would at least address the inflight checksum
verification problem, but still the final destination is obfuscated
for flow identification.

>
> [RB] We also have to ask why an intermediate node might check the transport-layer checksum. A garden-variety router would not. However, some middleboxes might. Those middleboxes would break on any unrecognized Routing Header Type.

Yes, some middleboxes will try to validate transport layer checksums.
This is also needed for debugging and diagnostics. For instance, if a
host is receiving packets from some destination the operator will want
to identify where in the path the bad checksums are being introduced.
If we get a packet trace from some router and all the packets are
reported to have a bad checksum then that's not very useful.

>
> [RB] We have observed some middleboxes that, having detected an incorrect checksum, correct it. In my opinion, this behavior is hideous. It assumes that an incorrect checksum is *never* caused by packet corruption. This is a pretty dangerous assumption.

Yes, that is bad, non-standard behavior.

Tom

>
>                                                                    Ron
>
>
> Tom
>
> >
> >
> >
> >
> > Ron
> >
> >
> >
> >
> > Juniper Business Use Only
> >
> > From: Tony Przygienda <[e-mail]>
> > Sent: Tuesday, October 31, 2023 3:54 PM
> > To: Tom Herbert <tom=[e-mail]>
> > Cc: Joel Halpern <[e-mail]>; 6man <[e-mail]>;
> > [e-mail]
> > Subject: Re: [IPv6] Routing Headers and limited domains (Was Re:
> > Adoption call for draft-bonica-6man-comp-rtg-hdr
> >
> >
> >
> > [External Email. Be cautious of content]
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Oct 31, 2023 at 5:47 PM Tom Herbert <tom=[e-mail]> wrote:
> >
> > On Mon, Oct 30, 2023 at 6:33 PM Joel Halpern <[e-mail]> wrote:
> > >
> > > Maybe I am dense, but I have trouble seeing how a node could have enough information to compose a useful CRH source route, and not have enough information to know where the relevant decapsulator is.  The most obvious candidate would be simply to decapsulate at the last entry in the source route.  it doesn't matter if that is (as is likely) not actually the egress.
> >
> > Hi Joel,
> >
> > Yes, that would probably be the most obvious candidate, and it's also
> > a candidate for removing the RH. Once segments left is zero, the
> > routing header is not operationally relevant to any downstream nodes.
> >
> > But even if that were the obvious choice for an encapsulation, I still
> > don't see how the source could know when to encapsulate and when not
> > to. A possible solution might be to tunnel all packets, but then
> > that's a lot of per packet overhead especially if most packets never
> > actually leave the limited domain.
> >
> > More generally, constraining protocols like routing header to a
> > limited domain is required and it's clear that *something* needs to
> > happen at edge routers of the limited domain.
> > draft-raviolli-intarea-trusted-domain-srv6 has a good description of
> > the problem. That's focused on SR, but other routing headers like CRH,
> > and other use cases of extension headers also have similar
> > requirements-- I would hope that there might be a general solution to
> > limiting protocol to limited domains (IMO, a new Ethertype like
> > described in that draft isn't the best solution and is likely to
> > create a set of new problems)
> >
> >
> >
> > can you be more specific here? seemed to have worked for mpls like a charm, for a very long time, at a very large scale ... and to differentiate v4 from v6 and many, many other use cases where it was necessary to quickly deploy a domain boundary ...
> >
> >
> >
> > Unless we have a clear, simple demarcation on the packet we end up building basically a stateful firewall by deep inspection or state-tying-together magic. one can afford that at L4 throughputs (at high cost) but the game is very different with the L3 or L2.5 economics as they are today.  As long CRH is mandatory on _every_ SRv6 packet, ok, it's bit deep to parse into but maybe somewhat workable, without, it eludes me how to build a simple, economical, non-stateful solution to delineate a possible SRv6 injection attack surface distinguishable from normal v6 forwarding unless a new ethertype is required.
> >
> >
> >
> > -- tony
> >
> >
> >
> > --------------------------------------------------------------------