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

[Tom Herbert <[e-mail]>]

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. I suspects that
implementations of in-network reassembly commonly make two incorrect
assumptions:

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.

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

Tom

> It is sufficient to hash over the
> three tuple <saddr, daddr, flow label> to get good load balancing. All
> major OSes have been updated to set flow labels, and there are devices
> that already support this. IMO, the draft should make using flow label
> for stateless load balancing a SHOULD.
>
> Tom
>
> On Mon, Jan 14, 2019 at 11:55 AM Joel M. Halpern <[e-mail]> wrote:
>
> I have re-read this document.  I think it is a useful document that
> captures that state of a complex tradeoff and makes effective
> recommendations. I support publishing it as a BCP.
>
> If the authors make further additions, adding a mention of ECMP as a
> particular case of stateless load balancers might further improve the
> document.
>
> Yours,
> Joel
>
> On 1/14/19 1:13 PM, Wassim Haddad wrote:
>
> Dear all,
>
> This email starts an Int-Area WG Last Call on the latest version of "IP Fragmentation Considered Fragile” draft:
>
> https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-05
>
> Please respond to this email to support the document and/or send comments by 2019-01-28.
>
> Please indicate if you are personally aware of any IPR that applies to draft-ietf-intarea-frag-fragile-xx?
> If so, has this IPR been disclosed in compliance with IETF IPR rules?
>
>
> Regards,
>
> Juan & Wassim
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area