Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

On Fri, Jan 5, 2024, 4:35 PM Ron Bonica <rbonica@juniper.net> wrote:

> Hi Tom,
>
> I believe that we have discussed this topic before, but it may have been
> off-list. So, I will repeat my argument on list.
>
> When considering your objection, we must consider:
>
> - its scope
> - the cost / benefit trade-off
>
> Regarding scope, you comment applies to many routing header compression
> scheme's not only the CRH. So, we should search for a solution that
> addresses all routing header compression schemes, not just the CRH.
>

Hi Ron,

Agreed.

> Regarding the cost / benefit trade-off, some operators may be concerned
> about the issue that you raise. They would be willing to sacrifice a few
> bytes of overhead for the additional functionality that you propose. Other
> operators, not so much.
>

Yes, this trade-off could be one of the questions answered in the
experiment.

>
> So, it seems that we should look for a solution that a) is applicable to
> many routing header compression scheme's and b) is optional. Clause a)
> precludes a solution that is embedded in the CRH.

> What do you think of a HBH Option that displays the ultimate destination.
> This can apply to any routing header compression scheme. It is also
> optional. If you like the idea, I would support a draft.
>

No, I suspect a new HBH option for this would be overkill.

Since this is experiment, how about defining two routing header types for
CRH where last SID is compressed, and one where it's not. The additional
processing and implementation complexity for the handling two variants
shouldn't be very significant, and both could be deployed side-by-side. It
would allow us to get feedback from real use cases, particularly on rather
a FIB containing all possible final destinations is scalable.

Tom

>                                                                         Ron
>
>
>
> Juniper Business Use Only
> -----Original Message-----
> From: Tom Herbert <tom@herbertland.com>
> Sent: Friday, January 5, 2024 5:56 PM
> To: Jen Linkova <furry13@gmail.com>
> Cc: 6man <ipv6@ietf.org>; draft-ietf-6man-comp-rtg-hdr@ietf.org
> Subject: Re: [IPv6] Working Group Last Call for
> draft-ietf-6man-comp-rtg-hdr
>
> [External Email. Be cautious of content]
>
>
> Hi,
>
> I have a concern with this proposal. As I understand it, the addresses of
> all intermediate destinations and the final destination can only be
> correctly deduced with access to the external state (the CRH-FIB). In
> particular, the final destination address can no longer be deduced by
> simple inspection of the packet contents. I think it may have ramifications
> on debugging and security. I suspect this also would be a concern for SR
> CRH.
>
> This will make much hardware to track and diagnose flows in the network.
> Also, if the destination is obfuscated the TCP and UDP checksum cannot be
> validated in the network (strictly not needed, however it is done when
> debugging corrupted checksums. Even if the diagnostic tools do have access
> to the FIB, it has to be the correct FIB in time. So to do post mortem
> analysis on a flow could only be done if the correct state is accessed for
> when the packet was accessed.
>
> Security may be a problem due to the potential of misdelivery. Correct
> delivery depends on FIB state being correct and synchronized between nodes.
> Presumably, misdelivery would be detected by transport layer checksum with
> pseudo header, however not all protocols have a checksum, and RFC6936
> allows UDPv6 to be sent with a zero checksum in the case of tunnels.
>
> To avoid ambiguity and misinterpretation, I suggest that the final address
> in the SIDs should be sent uncompressed as a plain address or compressed
> using some stateless method. I think this also could reduce the size of the
> FIB table since final destinations are likely to be hosts and there may be
> an order of magnitude more hosts than routers in the network.
>
> Tom
>
> On Thu, Jan 4, 2024 at 1:09 PM Jen Linkova <furry13@gmail.com> wrote:
> >
> > This message starts a new two week 6MAN Working Group Last Call on
> > advancing "The IPv6 Compact Routing Header (CRH)" document
> > (https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
> >
> tf-6man-comp-rtg-hdr/__;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0bndmOe3UuwngN0gXiuPTOerJkI$
> ) as an Experimental document.
> >
> > Substantive comments and statements of support for publishing this
> > document should be directed to the ipv6@ietf.org mailing list.
> > Editorial suggestions can be sent to the authors.  This last call will
> > end on Jan 21 2024, 23:59:59 UTC.
> >
> > --
> > Cheers, Jen Linkova on behalf of 6MAN chairs
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests:
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6
> > __;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0
> > bndmOe3UuwngN0gXiuPTMIkwPI$
> > --------------------------------------------------------------------
>