On Thu, Jan 31, 2019 at 7:59 AM Joe Touch <to...@strayalpha.com> wrote: > > 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.
Joe, The term "Stateless firewalls" is unambiguous in this context. In a stateless firewall, each packet is inspected and judge based solely on it's content. So when packets are fragmented, any data the firewall inspects that is beyond the networking layer is not available in the fragment so that presents a problem to them. It's straight forward to quantify the problems and suggested solutions. The term "Stateful firewalls" on the other hand is quite ambiguous. Without any further context, all we can deduce is that the device maintains some state-- we don't know what state the firewall maintains or how it's using it. It's incorrect to say that stateful firewalls solve any problem just by virtue of being "stateful". I believe Ron actually provided the missing, maybe implied, context when he mentioned "Some stateful firewalls perform virtual reassemble". That might be true, but then that gets us back to the unspecified protocol for "virtual reassembly". Note, that the term itself implies that it's a different process than what hosts do which is just "reassembly". Without a specification, I don't still see how virtual reassembly can be a normative requirement. Tom > > 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
