Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05

[Joe Touch <[e-mail]>]

Hi Tom,

> On Jan 17, 2019, at 6:55 AM, Tom Herbert <[e-mail]> wrote:
> 
>> On Wed, Jan 16, 2019 at 10:20 PM Joe Touch <[e-mail]> 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