[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [IPv6] Router vs. host processing of EH (in response to chairs review of eh-limits)
From:       Tom Herbert <tom=40herbertland.com () dmarc ! ietf ! org>
Date:       2023-11-13 16:43:11
Message-ID: CALx6S35wfxf4=G1jn8zBSAWn63Oj4tqWUbOE8yw_P0mHAxwStQ () mail ! gmail ! com
[Download RAW message or body]

On Mon, Nov 13, 2023 at 8:30 AM Havard Eidnes <he@uninett.no> wrote:
>
> > 1) Routers only have to process Hop-by-Hop Options, but a receiving
> > host has to process *all* extension headers in a packet. The review
> > states 'As noted in the draft "hosts typically have more processing
> > capabilities" ' seemingly implying that hosts should be able to handle
> > load while routers can't. While it's true that hosts have more general
> > processing capabilities, hosts have to do *a lot* more work to process
> > packets. Also, hosts have to do everything in software in a CPU, they
> > don't typically leverage hardware accelerations like CAMs that might
> > speed up TLV processing.
>
> Well, some NICs implement what's referred to as "TSO" (TCP
> segmentation off-load, causing parts of TCP packet stream
> processing to be off-loaded to the NIC) and other similar
> functionality (IPv<x> checksumming etc.).  However, who's going
> to take a bet whether hop-by-hop options processing is included
> in what a typical NIC can do?  My bet is on "slim to none",
> without having investigated this in any way, and if true, HBH
> options becomes a way to force the host CPU to do the processing.

Hi Havard,

Both TSO and checksum can be made to work with HBH options. If
protocol agnostic checksum offload is properly implemented then
there's no problem with extension headers on a host (protocol specific
checksum offload doesn't work with EH and hence why we're deprecating
it). Similarly, TSO works as long as the same EH can be used for each
segment.

>
> ...
> wm0 at pci3 dev 0 function 0, 64-bit DMA: Intel PRO/1000 PT Quad Port Server Adapter (rev. 0x06)
> ...
> $ ifconfig wm0
> wm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         capabilities=0x7ff80<TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx>
>         capabilities=0x7ff80<TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx>
>         capabilities=0x7ff80<TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6>
> ...
>
> Not that this changes any of the concerns you raised, perhaps it
> even bolsters the argument.

Unfortunately, this device implements protocol specific checksum
offload would likely be broken with any extension header. Broken means
that the checksum computation would be done on the CPU and not
offloaded. For such a device, EH could be used to force higher CPU
utilization as part of a DOS attack. I believe newer Nvidia and Intel
support protocol agnostic checksum offload that could offload checksum
processing for packets with extension headers.

Tom

>
> Best regards,
>
> - Håvard

--------------------------------------------------------------------
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]