[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: [IPv6] Routing Headers and limited domains (Was Re: Adoption call for draft-bonica-6man-comp-rtg
From: Ron Bonica <rbonica=40juniper.net () dmarc ! ietf ! org>
Date: 2023-11-15 21:58:09
Message-ID: BL0PR05MB53169A0B356C9B09106529D3AEB1A () BL0PR05MB5316 ! namprd05 ! prod ! outlook ! com
[Download RAW message or body]
Tom,
You say, " 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."
Is this true of the SRH when the final element of the SRH is a uSID/CSID/GSID?
\
Ron
Juniper Business Use Only
-----Original Message-----
From: Tom Herbert <tom@herbertland.com>
Sent: Tuesday, November 14, 2023 2:45 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>; Tony Przygienda \
<tonysietf@gmail.com>; Joel Halpern <jmh@joelhalpern.com>; 6man <ipv6@ietf.org>; \
draft-bonica-6man-comp-rtg-hdr.authors@ietf.org
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 Fri, Nov 3, 2023 at 12:56+IC8-PM Ron Bonica <rbonica@juniper.net> wrote:
>
> Hi Tom,
>
> Thanks for the review. Response inline[RB].
>
> Ron
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Wednesday, November 1, 2023 11:41 PM
> To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> Cc: Tony Przygienda <tonysietf@gmail.com>; Joel Halpern
> <jmh@joelhalpern.com>; 6man <ipv6@ietf.org>;
> draft-bonica-6man-comp-rtg-hdr.authors@ietf.org
> 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+IC8-PM Ron Bonica \
> <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> >
> > Tony,
> >
> >
> >
> > Please do not confuse the CRH with SRv6 or SR. The CRH can be used on any IPv6 \
> > packet that doesn+IBk-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+IBk-t have the CRH-FIB entry required to determine the ultimate destination \
> address.
> [RB] This issue isn+IBk-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 <tonysietf@gmail.com>
> > Sent: Tuesday, October 31, 2023 3:54 PM
> > To: Tom Herbert <tom=40herbertland.com@dmarc.ietf.org>
> > Cc: Joel Halpern <jmh@joelhalpern.com>; 6man <ipv6@ietf.org>;
> > draft-bonica-6man-comp-rtg-hdr.authors@ietf.org
> > 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+IC8-PM Tom Herbert \
> > <tom=40herbertland.com@dmarc.ietf.org> wrote:
> > On Mon, Oct 30, 2023 at 6:33+IC8-PM Joel Halpern <jmh@joelhalpern.com> 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
> >
> >
> >
> > --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic