Re: [spring] [IPv6] Subject: Mandating SRH when using C-SIDs (draft-ietf-spring-srv6-srh-compression)

[Tom Herbert <[e-mail]>]

On Thu, Apr 4, 2024, 4:59 PM Robert Raszuk <[e-mail]> wrote:

>
> Well software could know that but not NICs nor ASICs ...
>

Robert,

Sure they do. If a NIC or an ASIC wants to look at the transport layer then
they'd have to parse over the Routing Header. So they *know* it's there,
and the processing of routing headers is well specified. If they ignore the
RH and try to verify checksum based an intermediate address then it won't
work-- that's expected behavior. So when RH is present, everyone knows how
L4 checksum works.

Tom


> On Thu, Apr 4, 2024 at 10:57 PM Tom Herbert <[e-mail]> wrote:
>
>>
>>
>> On Thu, Apr 4, 2024, 4:00 PM Robert Raszuk <[e-mail]> wrote:
>>
>>> Tom,
>>>
>>> I have full sympathy for your points.
>>>
>>> But I can not understand how suddenly SR uSID is the issue and normal
>>> IPv6 vanilla Routing Headers are ok as defined checksum wise in RFC8200.
>>>
>>> Maybe someone could elaborate a bit on that ?
>>>
>>
>> Robert,
>>
>> Because, when a routing header is present we know that the final address
>> in the list is the one to used as the destination address in the pseudo
>> header. If the last address is uncompressed or can be decompressed without
>> additional state then we can calculate the checksum based on that (also,
>> that allows us to track flows in the network which is another useful thing
>> in a data center).
>>
>> Tom
>>
>>
>>> Thx,
>>> R.
>>>
>>> PS. And of course in spite of all effort from Alvaro to sort the topics
>>> the threads again got completely mangled and everyone is describing their
>>> perceived issue in random thread. My gently hint for the chairs would be to
>>> log issues in github and have more structured processing them there.
>>>
>>>
>>>
>>> On Thu, Apr 4, 2024 at 9:50 PM Tom Herbert <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 4, 2024, 3:37 PM Ole Trøan <otroan=
>>>> [e-mail]> wrote:
>>>>
>>>>> Tom,
>>>>>
>>>>> Can you point to any IETF specification requiring that middle boxes
>>>>> should be able to validate a l4 checksum? IPsec be damn.  It just seems
>>>>> like a path we should not go down.
>>>>>
>>>>
>>>> Ole,
>>>>
>>>> No, but neither can I point to an RFC that says firewalls have to parse
>>>> deep into packets. The point is that we know people can and do such things
>>>> (packet traces and checksum offload are deployed use cases for this).
>>>>
>>>> The transport checksum has been maintained to be correct on the wire in
>>>> plain UDP,TCP/IPv6 for thirty years even in NAT. Breaking that convention
>>>> without considering the ramifications could very well lead to some
>>>> unhappiness. And my concern is that problems would not just be confined to
>>>> SR packets, but could affect non-SR (like how we debug checksum problems in
>>>> non-SR traffic).
>>>>
>>>> Tom
>>>>
>>>>
>>>>> O.
>>>>>
>>>>>
>>>>>
>>>>> On 4 Apr 2024, at 21:22, Tom Herbert <tom=
>>>>> [e-mail]> wrote:
>>>>>
>>>>> 
>>>>>
>>>>>
>>>>> On Thu, Apr 4, 2024, 3:12 PM Robert Raszuk <[e-mail]> wrote:
>>>>>
>>>>>> Tom,
>>>>>>
>>>>>> >  SR aware routers to update L4 checksum
>>>>>>
>>>>>> That is completely unrealistic.
>>>>>>
>>>>>> Show me the box which can forward all interfaces at 800 Gb/s and read
>>>>>> entire each packet and compute upper layer checksum on it.
>>>>>>
>>>>>
>>>>> Robert,
>>>>>
>>>>> It's not necessary to calculate the whole checksum, only the L4
>>>>> checksum needs to be updated by adding in the delta checksum. With IPv6 we
>>>>> can also do a checksum neutral mapping. Basically, this uses the low order
>>>>> 16 bits in the DA address as the checksum adjustment value. For instance,
>>>>> if we can use the low order bits in a SID block then that would be simplest
>>>>> to implement.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>> If anything just do encap and move on.
>>>>>>
>>>>>> Thx,
>>>>>> R.
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 4, 2024 at 7:06 PM Tom Herbert <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Apr 4, 2024, 12:30 PM Robert Raszuk <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> Yes I am with you here.
>>>>>>>>
>>>>>>>> However let's observe that this is pretty common best practice to
>>>>>>>> disable any hardware offload on the box when running tcpdump or wireshark.
>>>>>>>>
>>>>>>>> In fact some implementations (F5) do it for you automagically :)
>>>>>>>>
>>>>>>>> And as it has been said based on the fact that hardware offload
>>>>>>>> does not understand any Routing Headers it really does not matter if it is
>>>>>>>> there or not :)
>>>>>>>>
>>>>>>>
>>>>>>> Robert,
>>>>>>>
>>>>>>> tcpdump is independent of hardware offload. If the checksum is
>>>>>>> incorrect per the packet contents we'll see bad checksums reported if we
>>>>>>> snoop packets, but like I said, we can't differentiate the bad from the
>>>>>>> good.
>>>>>>>
>>>>>>> Offload becomes an issue for NICs that do protocol specific checksum
>>>>>>> offload. We lose the capability on RX which is an inconvenience, on TX we'd
>>>>>>> need to change the implementation to ensure the checksum is not computed by
>>>>>>> HW.
>>>>>>>
>>>>>>> If SR without SRH is needed, then I believe the best answer is for
>>>>>>> SR aware routers to update L4 checksum when they change DA per NAT
>>>>>>> requirements. This solves tcpdump as well as offloads.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> R.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Apr 4, 2024 at 6:11 PM Tom Herbert <tom=
>>>>>>>> [e-mail]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Apr 4, 2024, 11:48 AM Francois Clad <[e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Tom,
>>>>>>>>>>
>>>>>>>>>> Tcpdump can determine that this packet is steered onto an SRv6
>>>>>>>>>> path by checking if the DA matches the SRv6 SID block.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Francois,
>>>>>>>>>
>>>>>>>>> That would require introducing external state to tcpdump for
>>>>>>>>> correct operation. This would be a major divergence in both implementation
>>>>>>>>> and ops compared to how things work today.
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Francois
>>>>>>>>>>
>>>>>>>>>> On 4 Apr 2024 at 16:59:59, Tom Herbert <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Apr 4, 2024, 9:39 AM Francois Clad <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi Mark,
>>>>>>>>>>>>
>>>>>>>>>>>> Tcpdump/wireshark decodes the IPv6 header just fine. I do not
>>>>>>>>>>>> see any issue here.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Francois,
>>>>>>>>>>>
>>>>>>>>>>> The problem is that tcpdump can't tell that a packet is an SR
>>>>>>>>>>> packet if there's no SRH. For instance, if the checksum is not maintained
>>>>>>>>>>> to be correct in the wire then tcpdump will show that the packet has a bad
>>>>>>>>>>> L4 checksum, but there's no way to tell if that is an SR packet or if the
>>>>>>>>>>> checksum is actually bad. This will make debugging checksum failures in the
>>>>>>>>>>> network much more difficult, and this affects our ability to debug all
>>>>>>>>>>> traffic not just SR packets.
>>>>>>>>>>>
>>>>>>>>>>> Tom
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Francois
>>>>>>>>>>>>
>>>>>>>>>>>> On 4 Apr 2024 at 14:09:43, Mark Smith <[e-mail]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 4 Apr 2024, 22:50 Francois Clad, <[e-mail]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Alvaro, all,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> RFC 8754 allows the SR source node to omit the SRH when it
>>>>>>>>>>>>>> contains redundant information with what is already carried in the base
>>>>>>>>>>>>>> IPv6 header. Mandating its presence for C-SID does not resolve any problem
>>>>>>>>>>>>>> because it will not provide any extra information to the nodes along the
>>>>>>>>>>>>>> packet path.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> How are troubleshooting tools like 'tcpdump' going to know how
>>>>>>>>>>>>> to automatically decode these packets as SRv6 packets if there is no SRH?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Specifically for the case of middleboxes attempting to verify
>>>>>>>>>>>>>> the upper-layer checksum,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>    - An SRv6-unaware middlebox will not be able to verify
>>>>>>>>>>>>>>    the upper-layer checksum of SRv6 packets in flight, regardless of whether
>>>>>>>>>>>>>>    an SRH is present or not.
>>>>>>>>>>>>>>    - An SRv6 and C-SID aware middlebox will be able to find
>>>>>>>>>>>>>>    the ultimate DA and verify the upper-layer checksum in flight, regardless
>>>>>>>>>>>>>>    of whether an SRH is present or not.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Furthermore, transit nodes (e.g., middleboxes) should not
>>>>>>>>>>>>>> attempt to identify SRv6 traffic based on the presence of the SRH, because
>>>>>>>>>>>>>> they will miss a significant portion of it: all the best-effort or
>>>>>>>>>>>>>> Flex-Algo traffic steered with a single segment may not include an SRH,
>>>>>>>>>>>>>> even without C-SID. Instead, RFC 8402, 8754, and 8986 define identification
>>>>>>>>>>>>>> rules based on the SRv6 SID block.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Francois
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 2 Apr 2024 at 19:44:51, Alvaro Retana <
>>>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [Moving this conversation up on your mailbox. :-) ]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [Thanks, Robert and Tom for your input!]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We want to hear from more of you, including the authors.
>>>>>>>>>>>>>>> Even if you already expressed your opinion in a different thread, please
>>>>>>>>>>>>>>> chime in here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We will collect feedback until the end of this week.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alvaro.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On March 28, 2024 at 8:06:18 AM, Alvaro Retana (
>>>>>>>>>>>>>>> [e-mail]) wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Focusing on the C-SID draft, some have suggested requiring
>>>>>>>>>>>>>>> the presence of the SRH whenever C-SIDs are used. Please discuss whether
>>>>>>>>>>>>>>> that is the desired behavior (or not) -- please be specific when debating
>>>>>>>>>>>>>>> the benefits or consequences of either behavior.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please keep the related (but independent) discussion of
>>>>>>>>>>>>>>> requiring the SRH whenever SRv6 is used separate. This larger topic may
>>>>>>>>>>>>>>> impact several documents and is better handled in a different thread (with
>>>>>>>>>>>>>>> 6man and spring included).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Alvaro
>>>>>>>>>>>>>>> -- for spring-chairs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>>> Administrative Requests:
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>>>> Administrative Requests:
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> Administrative Requests:
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>>>>
>>>>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>> IETF IPv6 working group mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> Administrative Requests:
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>>
>>>>>>>>> --------------------------------------------------------------------
>>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>>>