On Fri, Mar 22, 2024 at 12:17 PM Brian E Carpenter <brian.e.carpen...@gmail.com> wrote: > > On 23-Mar-24 03:40, Robinson, Herbie wrote: > > Legitimate reasons for a middle box to look at transport headers: > > > > Firewalls need to look at port numbers to perform their quite necessary job. > > Steve Bellovin pointed out in 1999 that such firewalls should be in the > destination host**. That works very well, and in particular it scales > perfectly in proportion to the number of hosts in the Internet, so doesn't > need hardware assist. > > Firewall vendors don't agree and never have done.
Brian, That functionality is certainly in Android and iOS I would imagine. > > Unfortunately for Tom's argument, firewalls at enterprise network boundaries > are widespread and hosts without adequate self-protection are common. It's a > sad state of affairs. It will be interesting to see whether QUIC manages to > effect change. There might be some argument for enterprise firewalls for the purpose of protecting network resources. One example is the filtering packets that contain Hop-by-Hop Options _might_ be reasonable in some circumstances since they are directed towards routers and not just end hosts, so filtering them conceptually protects the enterprise's network resources from attack. Although, I'd prefer that they remove HBH at the edge instead of dropping like in draft-herbert-eh-inflight-removal (that's also in the ipv4eh draft). Also, it probably never makes sense to accept packets with Routing Headers from the Internet into a limited domain. Tom > > ** https://www.cs.columbia.edu/~smb/papers/distfw.pdf > > Brian > > > > > 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. > > > > 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). > > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > 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 <int-area-boun...@ietf.org > > <mailto:int-area-boun...@ietf.org>> *On Behalf Of *Tom Herbert > > *Sent:* vendredi 22 mars 2024 04:49 > > *To:* Joe Touch <to...@strayalpha.com <mailto:to...@strayalpha.com>> > > *Cc:* Toerless Eckert <t...@cs.fau.de <mailto:t...@cs.fau.de>>; int-area > > <int-area@ietf.org <mailto:int-area@ietf.org>> > > *Subject:* Re: [Int-area] New Version Notification for > > draft-herbert-ipv4-eh-03.txt > > > > On Thu, Mar 21, 2024, 8:28 PM to...@strayalpha.com > > <mailto:to...@strayalpha.com> <to...@strayalpha.com > > <mailto: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. 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 > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
