On Fri, Mar 22, 2024 at 7:40 AM Robinson, Herbie <[email protected]> wrote: > > Legitimate reasons for a middle box to look at transport headers: >
Herbie, Whether something is "legitimate" is a matter of opinion, protocol conformance typically is not. > > > Firewalls need to look at port numbers to perform their quite necessary job. For applications and hosts firewalls are not all necessary to do their job and have created way more problems for developers than they solve. In fact, in the 6man meeting the other day someone pointed out that the effect of NAT has been to move the problems and complexity out of the network into the host and application-- as a host developer I can say that this statement is spot on. > > Anything forwarding packets (including NICs) needs to make sure TCP packets > for a given IP/port/IP/port go through the same path to avoid re-ordering. That would be great if TCP was the only transport protocol. But it's not. What about UDP, DCCP, SCTP, GRE, IPsec, IPIP, IP fragments, and others? There is a simple answer for this, use the IPv6 flow label instead of port number to get the proper effect regardless of the encapsulated IP protocol and routers don't need to parse deep into the packet to find the port numbers. IPv4 doesn't have a flow label, but this draft proposes using IPID for that with non-fragmented packets. > > Note that firewalls usually have a hardware assisted fast path and a software > based slow path. Any new protocol features will kick packets into the slow > path until the hardware gets updated (and that’s if the hardware gets > updated). Right, and this is exactly what drives use to limit packets on the Internet to perpetually use the least common denominator of support in the network. The result is an ossified Internet that we can no longer evolve-- IMO that's not a good thing! Tom > > > > > > ________________________________ > > Hello, > > > > Interestingly, there is a similar discussion going on in Spring around the > C-SID draft, about whether people think it is legitimate for intermediate > nodes to be able to parse / process / check information that are supposed to > be used by end nodes or not. This goes with checksum, port numbers, segment > IDs, etc. > > > > I think that acknowledging the possibility for middleboxes to look at and > modify fields that are supposed to be looked at and checked by end nodes is > an issue, and breaks fundamental end to end assumptions that are foundational > in the Internet design. Thus, I think we should allow shim headers (you can > name them IPv4 extension headers if you want) to be deployed between IPv4 > header and Transport layer protocol, provided they get a proper protocol > number. Of course, this will break the operation of middleboxes that try to > look at information in transport headers, but they should not look at those > information in the first place, or at least do it in a robust way. > > > > Best regards, > > > > Antoine > > > > From: Int-area <[email protected]> On Behalf Of Tom Herbert > Sent: vendredi 22 mars 2024 04:49 > To: Joe Touch <[email protected]> > Cc: Toerless Eckert <[email protected]>; int-area <[email protected]> > Subject: Re: [Int-area] New Version Notification for > draft-herbert-ipv4-eh-03.txt > > > > > > On Thu, Mar 21, 2024, 8:28 PM [email protected] <[email protected]> > 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. If you say TCP as in > modifying port numbers for NAT, I'll point out it that the TCP was never > designed for this, it breaks TCP Auth option, and QUIC closed this > architectural aberration by encrypting the transport layer so that > intermediate nodes can't muck with it :-) > > > > IMO, network nodes have no business participating in transport layer, doing > so has led to a lot of protocol ossification. > > > > Tom > > > > > > > > IPv6 can call them extensions because all IPv6 nodes already know what to do > with them, even for codepoints they’ve never seen. IPv4 implementations have > no knowledge of this new transport protocol - only those who have been > upgraded. > > > > No different in principle - or implementation - than DCCP or SCTP. > > No easier to deploy. > > No more unique utility, IMO. > > > > Joe > > > > *All protocol layers are relative, so you COULD do the following: > > > > IPa IPb UDPc UDPd > > > > To IPa, its view of itself is layer 3, IPb is layer 4, not an extension to > layer 3. > > > > To IPb, its view of itself is layer 3, IPa is layer 2 and UDPc is layer 4. > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
