The problem with dropping the entire paragraph is the section title - talking about stateless firewalls begs the question of stateful ones. This is reinforced later in the recommendations. The sentences you remove were the only thing that tied the two together, which IMO is important.
Also note that draft-tunnels points out significant issues in some of the RFCs cited here, e.g., 4459. Part of the reason why fragmentation doesn’t work well is the errors in those prior docs. Joe > On Jan 30, 2019, at 6:20 PM, Ron Bonica <rbon...@juniper.net> wrote: > > Done > >> -----Original Message----- >> From: Tom Herbert <t...@herbertland.com> >> Sent: Wednesday, January 30, 2019 7:56 PM >> To: Ron Bonica <rbon...@juniper.net> >> Cc: int-area@ietf.org; Brian E Carpenter <brian.e.carpen...@gmail.com> >> Subject: Re: I-D Action: draft-ietf-intarea-frag-fragile-06.txt >> >> On Wed, Jan 30, 2019 at 12:57 PM Ron Bonica <rbon...@juniper.net> wrote: >>> >>> Inline...... >>> >>>> Message: 3 >>>> Date: Tue, 29 Jan 2019 11:45:45 -0800 >>>> From: Tom Herbert <t...@herbertland.com> >>>> To: int-area <int-area@ietf.org> >>>> Subject: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06 >>>> Message-ID: >>>> <CALx6S35kwvHL5iE4Ci10LQbPzun3k1C- >>>> t4m5b55yayl+np4...@mail.gmail.com> >>>> Content-Type: text/plain; charset="UTF-8" >>>> >>>> Hello, >>>> >>>> I have suggested text for the draft to address some previous >>>> comments made on the list. >>>> >>>> Last paragraph in section 4.3: >>>> >>>> "This problem does not occur in stateful firewalls or Network >>>> Address Translation (NAT) devices. Such devices maintain state so >>>> that they can afford identical treatment to each fragment that >>>> belongs to a packet. Note, however, that stateful firewalls and NAT >>>> devices impose the external requirement that all packets of a flow >>>> and fragments of a packets for a flow must traverse the same stateful >> device; stateless devices do not force this requirement." >>>> >>> >>> The first two sentence that you suggest already appear in version 06 of the >> document. >>> >>> I would prefer to omit the final sentence for the following reasons: >>> >>> - It isn't absolutely necessary >>> - It opens another can of worms that I don't want to address. Specifically, >> some stateful firewalls perform virtual reassembly but don't maintain TCP >> session state. Some stateful firewalls perform virtual reassemble and >> maintain >> TCP state. You third sentence is true for one firewall type and false for the >> other. >>> >> Yes, but as Fred mentioned, the current text is a blanket statement that >> stateful firewalls don't have this problem. Some firewalls may have >> implemented virtual reassembly, but others may not and might not do >> anything we'd consider reasonable for handling fragments. So similarly the >> statement in the draft may be "true for one firewall type and false for the >> other". Also, any implication that people should swap out their stateless >> devices for stateful ones because they solve one problem without mentioning >> that they introduce other problems would be a disservice IMO. >> >> To avoid the can of worms, I suggest the whole paragraph and any discussion >> about stateful devices could be removed from the draft without loss of >> content. >> >> Tom >> >>>> Section 4.5: >>>> "IP fragmentation causes problems for some routers that support >>>> Equal Cost Multipath (ECMP). Many routers that support ECMP execute >>>> the algorithm described in Section 4.4 in order to perform flow >>>> based forwarding; therefore, the exhibit they same problematic >>>> behaviors described in Section 4.4. In IPv6, the flow label may >>>> alternatively used as input to the algorithm as opposed to parsing >>>> the transport layer of packets to discern port numbers. The flow >>>> label should be consistently set for a packets of flow including >>>> fragments, such that a device does not need to parse packets beyond the >> IP header for the purposes of ECMP." >>> >>> This comment is almost identical to one made by Brian Carpenter. I have >> addressed his comment in Section 4.4. Rather than repeating the same text in >> Section 4.5, I have merged the two sections. >>> >>>> >>>> Add to section 7.3: >>>> >>>> "Routers SHOULD use IPv6 flow label for ECMP routing as described in >>>> [RFC6438]." >>> >>> Brian suggested similar text, but in a new section. Look for the new >>> section in version 07 >>> >>> > _______________________________________________ > 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
