Re: [Int-area] New Version Notification for draft-herbert-ipv4-eh-03.txt

[Tom Herbert <[e-mail]>]

On Thu, Mar 21, 2024 at 9:01 PM [e-mail]
<[e-mail]> wrote:
>
> On Mar 21, 2024, at 8:48 PM, Tom Herbert <[e-mail]> wrote:
>
>
>
>
> On Thu, Mar 21, 2024, 8:28 PM [e-mail] <[e-mail]> wrote:
>>
>> <Joe>
>>
>>
>>> You’ve just described a transport protocol that the intermediate nodes know.
>>
>>
>> Joe,
>>
>> A transport protocol doesn't meet the requirements. They don't work with any transport protocol other than themselves,
>>
>>
>> They do when you define them that way, i.e., “here’s a transport protocol header A, after which you can use any transport protocol, as indicated in field X”.
>>
>> and intermediate nodes cannot robustly parse transport headers
>>
>>
>> They can’t parse these either. But, if upgraded to do so for headers “A”, as per above.
>>
>> This has to be L3 protocol.
>>
>>
>> It’s not. It’s L4, or at least that’s what it is* to IP.
>
>
> Joe,
>
> Please give one concrete example of a transport protocol explicitly designed to be processed and modified by intermediate nodes.
>
>
> The one in this draft.
>
> ...
> IMO, network nodes have no business participating in transport layer, doing so has led to a lot of protocol ossification.
>
>
> Nodes participate in the protocols that they know about.

Joe,

Sure. Before TLS spun up, intermediate nodes were commonly parsing
HTML into TCP to rewrite content to put in their own ads and doing
other nefarious things. Basically, anything in plaintext is often
considered fair game.  But, the fact that they can do something
non-conformant hardly justifies it or makes it robust. This is exactly
why there is a trend to encrypt as much of the packet as possible like
in QUIC.

>
> There are BITW stacks that process IPsec. As noted many times, NATs do this for TCP.  There have been BITW devices that coalesce or split TCP packets.
>
> No, this isn’t possible for protocols designed to NOT allow it (authentication, encryption, etc.).
>
> But the protocol defined in this draft IS designed to allow - and encourage - just that.
>
> It does’t make it “not a transport”. It makes it a “transport that intermediate nodes know they can modify”.
>
> Again, I’m not saying it’s not useful. I’m saying it’s just another transport - one with particular properties, but still just a transport.

Extension headers are not transport protocols per the standard,
RFC8200 clearly distinguishes extension headers from upper layer
protocols which can be transport layer protocols.

Tom

>
> Joe
>