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

On Wed, Jan 16, 2019 at 11:40 AM Ron Bonica <rbonica@juniper.net> wrote:
>
> Inline…..
>
>
>
> From: Tom Herbert <tom@herbertland.com>
> Sent: Wednesday, January 16, 2019 2:27 PM
> To: Ron Bonica <rbonica@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 <rbonica@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://www.ietf.org/mailman/listinfo/int-area