Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)

[Ron Bonica <[e-mail]>]

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 <[e-mail]>
> Sent: Wednesday, January 16, 2019 3:03 PM
> To: Ron Bonica <[e-mail]>
> Cc: int-area <[e-mail]>
> 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 <[e-mail]> wrote:
> >
> > Inline…..
> >
> >
> >
> > From: Tom Herbert <[e-mail]>
> > Sent: Wednesday, January 16, 2019 2:27 PM
> > To: Ron Bonica <[e-mail]>
> > Cc: int-area <[e-mail]>
> > Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05
> > (Tom Herbert)
> >
> >
> >
> >
> >
> > On Tue, Jan 15, 2019, 6:17 PM Ron Bonica <[e-mail] 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
> > [e-mail]
> > 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=