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

[Ron Bonica <[e-mail]>]

Fair enough.

                      Ron




Juniper Business Use Only
From: Tom Herbert <[e-mail]>
Sent: Saturday, January 6, 2024 4:22 PM
To: Ron Bonica <[e-mail]>
Cc: Jen Linkova <[e-mail]>; 6man <[e-mail]>; [e-mail]
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]


On Sat, Jan 6, 2024, 12:57 PM Ron Bonica <[e-mail]<mailto:[e-mail]>> wrote:
Tom,

Revealing the ultimate destination address to intermediate nodes has never been an explicitly stated requirement of the IPv6 Routing header. Therefore, it is beyond the scope of the current experiment.
Ron,

It may not be an explicit protocol requirement, but as I pointed out it may be an implicit operational requirement at least in some networks. Even if there's not a solution in this draft, I think it's worth mentioning in the draft the loss of visibility of the final destination and potential ramifications.

Tom


However, that doesn’t close the door to subsequent experiments. Please feel free to post a follow up draft.

                                                                                               Ron




Juniper Business Use Only
From: Tom Herbert <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, January 6, 2024 11:19 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>
Cc: Jen Linkova <[e-mail]<mailto:[e-mail]>>; 6man <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [IPv6] Working Group Last Call for draft-ietf-6man-comp-rtg-hdr

[External Email. Be cautious of content]


On Fri, Jan 5, 2024, 4:35 PM Ron Bonica <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 5, 2024 5:56 PM
To: Jen Linkova <[e-mail]<mailto:[e-mail]>>
Cc: 6man <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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<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 [e-mail]<mailto:[e-mail]> 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
> [e-mail]<mailto:[e-mail]>
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6>
> __;!!NEt6yMaO-gk!CWvVGIuSGSWauTRliWk7FJg8VvZNfVPLMcMeOdaUrfqmrfb7flEI0
> bndmOe3UuwngN0gXiuPTMIkwPI$
> --------------------------------------------------------------------