Hi Tom, > On Jan 17, 2019, at 6:55 AM, Tom Herbert <t...@herbertland.com> wrote: > >> On Wed, Jan 16, 2019 at 10:20 PM Joe Touch <to...@strayalpha.com> wrote: >> >> Tom, >> >> On 1/14/2019 2:04 PM, Tom Herbert wrote: >> >> Hello. I have a couple of comments: >> >>> From the draft: >> "Middle boxes SHOULD process IP fragments in a manner that is >> compliant with RFC 791 and RFC 8200. In many cases, middle boxes must >> maintain state in order to achieve this goal." >> >> This requirement is confusing to me on several accounts. First of all, >> there are a lot of requirements about fragmentation in both RFC791 and >> RFC8200, including some MUSTs. This requirement seems to be updating >> and possibly relaxing some of those requirements, but is not specific. >> >> I disagree; being compliant with existing RFCs neither updates nor relaxes >> those RFCs. >> >> This seems ambiguous as a normative requirement. >> >> Perhaps vague, agreed. >> >> Secondly, the only specified interaction between fragmentation and >> intermediate nodes is that routers can fragment packets in IPv4. >> >> Agreed. However, nodes that *create* packets with their own IP addresses act >> as hosts; in that regard, middleboxes act both as intermediate (from the >> private side to public) and hosts (from the public side). As hosts, packets >> entering them, destined to *their* IP addresses, need to be reassembled, >> just as with any other host. >> >> This is addressed in detail here: >> >> Touch, J,. "Middlebox Models Compatible with the Internet," Technical >> Report, USC/ISI (ISI-TR-711), 2016. >> >> https://www.strayalpha.com/pubs/isi-tr-711.pdf >> >> Other >> than that, a middlebox that complies with RFC791 and RFC8200 does not >> process or consider fragmentation of packets. Given that, it's unclear >> to me why middle boxes would need to maintain state to be protocol >> compliant. >> >> If they process only IP headers, they don't. If they further consume the >> packet's contents - as would a *host*, they need to reassemble that content >> (even if virtually) to be able to interpret it. That includes associating >> transport headers with all the content as well as inspecting that content. >> > Joe, > > As I mentioned, in-network reassembly has not been specified, only > reassembly at end destinations has been.
Hint - if a packet arrives on your interface with your IP address, you ARE a host. > I suspects that > implementations of in-network reassembly commonly make two incorrect > assumptions: The first one is above... > > 1) All fragments of a packet traverse the network device performing reassembly > 2) The first fragment is always received first > > Neither of these assumptions are valid for IP. Agreed, but again, there are three incorrect assumptions. The first is that a NAT isn’t a host, and too often that’s the one that causes the above two to actually cause pain. > >> It's possible that the implicit exception of the >> requirement is that middleboxes might perform "in-network reassembly" >> or "virtual reassemlby" which would require state. If that is indeed >> the case then the requirements for the mechanisms should be spelled >> out. >> >> As with Ron, I agree that seems out of scope for this doc. >> >> For stateless load balancing (described in section 4.4), the IPv6 flow >> label obviates the need for DPI. >> >> Only for flow-based routing; not for DPI processing involving content beyond >> the transport header, e.g., content-based routing. I.e., it depends on how >> far into the packet the DPI is going... >> > TLS and payload encryption have largely eliminated the ability for > intermediate devices to perform DPI into content. Transport layer > header encryption, like done in QUIC, will further reduce the value of > doing DPI. Yes and no; there are still devices that do DPI on content - especially devices that spoof the initial splash page for Internet access when at hotspots. Some of them won’t even open a splash page unless customers first access a non-TLS website. Joe _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
