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

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Jan 2019 02:16:44 +0000

Tom,

Please take a look at Section 4.3 (Stateless Firewalls). How can the stateless firewall behave optimally without maintaining state?

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

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Jan 2019 11:26:39 -0800

On Tue, Jan 15, 2019, 6:17 PM Ron Bonica <[email-masked] 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.

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.

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.

Tom

> While flow labels may help in the case of load balancers, the don't help
> at all in the case of stateless firewalls.

> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Jan 2019 19:40:49 +0000

Inline…..

From: Tom Herbert <[email-masked]>
Sent: Wednesday, January 16, 2019 2:27 PM
To: Ron Bonica <[email-masked]>
Cc: int-area <[email-masked]>
Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)

On Tue, Jan 15, 2019, 6:17 PM Ron Bonica <[email-masked]<mailto:[email-masked]> wrote:
Tom,

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.

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

                                                Ron

_______________________________________________
Int-area mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=Zhs6QMg9BE9hwkV1BxbTY67UZveI3xhyoA3WWx75vXQ&s=FE4QaQJPaMuOBKxvbfjmmEvaKWEcC9Dg0eN5xHQFjxA&e=>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 Jan 2019 12:02:37 -0800

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

---

From: Ron Bonica <[email-masked]>
Date: Wed, 16 Jan 2019 20:08:18 +0000

Tom,

We seem to be talking past one another. 

Would you objection be satisfied if I deleted the sentence?

                                          Ron

> -----Original Message-----
> Sent: Wednesday, January 16, 2019 3:03 PM
> > 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.
> 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
> 
> >
> >
> >
> >
> 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.
> >
> >
> >
> > 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.
> >
> >
> >
> > > 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
> >
> > 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=

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Jan 2019 22:22:42 -0800

FWIW...

On 1/16/2019 11:26 AM, Tom Herbert wrote:
> ...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.

That works only if the firewall drop rules are based on information
available in the first fragment. The D in DPI often goes much further.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Jan 2019 05:27:51 -0300

On 16/1/19 16:26, Tom Herbert wrote:
> firewall. Introducing state requires memory and additional logic that
> are at odds with the goal of cheap low end devices..
> 
> 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.

This assumes the node to be firewalled implements RFC8200/RFC5722 -- if
it doesn't, the filtering policy could be circumvented.

You may or may not be able to make such assumption. Where you can't, you
may have to do stateful firewalling.

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492