On Thu, Mar 21, 2024 at 9:01 PM to...@strayalpha.com <to...@strayalpha.com> wrote: > > On Mar 21, 2024, at 8:48 PM, Tom Herbert <t...@herbertland.com> wrote: > > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com <to...@strayalpha.com> > 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 > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
