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

[Tom Herbert <[e-mail]>]

On Thu, Jan 17, 2019 at 7:06 AM Joe Touch <[e-mail]> wrote:
>
> 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.
>
Joe,

Conversley, if a packet arrives on your interface that isn't destined
to your IP address, you ARE NOT 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.
>
If NAT is a host, then it is only a host in the return path. Packets
sent from the client behind a NAT have destinations addresses that are
not those of the the NAT device. If a device is performing host
procedures on such packets, like reassembly, then it is being done
outside the auspices of the standard.

In any case, this isn't a NAT specific issue. Stateful firewalls
regularly process packets for which they aren't the destination.

Tom

> >
> >> 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