Tom,
We seem to be talking past one another.
Would you objection be satisfied if I deleted the sentence?
Ron
> -----Original Message-----
> From: Tom Herbert <t...@herbertland.com>
> Sent: Wednesday, January 16, 2019 3:03 PM
> To: Ron Bonica <rbon...@juniper.net>
> Cc: int-area <int-area@ietf.org>
> Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom
> Herbert)
>
> On Wed, Jan 16, 2019 at 11:40 AM Ron Bonica <rbon...@juniper.net> wrote:
> >
> > Inline…..
> >
> >
> >
> > From: Tom Herbert <t...@herbertland.com>
> > Sent: Wednesday, January 16, 2019 2:27 PM
> > To: Ron Bonica <rbon...@juniper.net>
> > Cc: int-area <int-area@ietf.org>
> > Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
> > (Tom Herbert)
> >
> >
> >
> >
> >
> > On Tue, Jan 15, 2019, 6:17 PM Ron Bonica <rbon...@juniper.net wrote:
> >
> > Tom,
> >
> > Please take a look at Section 4.3 (Stateless Firewalls). How can the
> > stateless
> firewall behave optimally without maintaining state?
> >
> >
> >
> > Ron,
> >
> >
> >
> > A stateless firewall that maintains state is no longer a stateless firewall.
> Introducing state requires memory and additional logic that are at odds with
> the goal of cheap low end devices.
> >
> >
> >
> > True, but orthogonal to the issue at hand. You asked why a middle box might
> need to maintain state to perform properly. I offered the example of a
> firewall. In the presence of fragments, only a stateful firewall can perform
> its
> intended task.
> >
> Ron,
>
> I don't follow. If the intended task is to drop packets based on some filter
> then
> dropping the first fragment meets the requirement. If the intent is something
> else then the requirements should be enumerated.
> Neither do I understand why a stateful firewall uniquely satisfies the
> requirements without breaking others. All we know from the description is
> that they're stateful, but we don't know how they should manage and using
> state nor the requirements they have followed. Think of it this way, if I
> were a
> manufacturer of a stateless device and I read the draft I might be convinced
> of
> the recommedation that I need to add state to my devices. But then what does
> that mean? Where is the specification and requirements that tells me how to
> do that?
>
> Tom
>
> >
> >
> >
> >
> > A stateless firewall could just drop the first fragment that contains the
> transport layer header and allow non first fragments to past. This achieves
> the
> filtering goal to prevent delivery of the reassmbled packet. It does mean
> fragments that can't possibly be reassembled make it to the destination.
> Whether or not that is a mere nuisance or causes real problems that creates a
> DOS vector depends on other factors in deployment.
> >
> >
> >
> > It is at least a nuisance and at worst a DOS vector.
> >
> >
> >
> > Also, if state is required then what is the algorithm that uses that state?
> > in
> section 4.6 virtual reassembly is mentioned in passing, but they goes on to
> say
> that has problems. It's also true that stateful firewalls inevitably break
> multi-
> path but stateless firewalls don't which is a big advantage. It's not clear
> to me
> that making stateless firewalls stateful is an improvement.
> >
> >
> >
> > This is beyond the scope of this document.
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> > Tom
> >
> >
> >
> >
> >
> >
> > While flow labels may help in the case of load balancers, the don't help at
> > all
> in the case of stateless firewalls.
> >
> >
> > Ron
> >
> > > Secondly, the only specified interaction between fragmentation and
> > > intermediate nodes is that routers can fragment packets in IPv4.
> > > 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. 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.
> > >
> > > For stateless load balancing (described in section 4.4), the IPv6
> > > flow label obviates the need for DPI. 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
> >
> > _______________________________________________
> > Int-area mailing list
> > Int-area@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> > man_listinfo_int-2Darea&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voD
> > TXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=9zVoUdr9_Qfuu
> > va6rZQ-CZAiv-
> hwpTgbMYOwTZQk5CY&s=cVqZEBCUgpPByE1PsvHyK7FzO1NuJmVuPdOCv
> > bfWfGs&e=
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
