Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
On 16/1/19 16:26, Tom Herbert wrote: > 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. 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: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
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 > Sent: Wednesday, January 16, 2019 3:03 PM > To: Ron Bonica > Cc: int-area > 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 wrote: > > > > Inline….. > > > > > > > > From: Tom Herbert > > Sent: Wednesday, January 16, 2019 2:27 PM > > To: Ron Bonica > > Cc: int-area > > Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 > > (Tom Herbert) > > > > > > > > > > > > On Tue, Jan 15, 2019, 6:17 PM Ron Bonica > > > 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
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
On Wed, Jan 16, 2019 at 11:40 AM Ron Bonica wrote: > > Inline….. > > > > From: Tom Herbert > Sent: Wednesday, January 16, 2019 2:27 PM > To: Ron Bonica > Cc: int-area > Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom > Herbert) > > > > > > On Tue, Jan 15, 2019, 6:17 PM Ron Bonica > 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 > > > 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 ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
Inline….. From: Tom Herbert Sent: Wednesday, January 16, 2019 2:27 PM To: Ron Bonica Cc: int-area Subject: Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert) On Tue, Jan 15, 2019, 6:17 PM Ron Bonica mailto: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. 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 > 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<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_int-2Darea=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8=Zhs6QMg9BE9hwkV1BxbTY67UZveI3xhyoA3WWx75vXQ=FE4QaQJPaMuOBKxvbfjmmEvaKWEcC9Dg0eN5xHQFjxA=> ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
Re: [Int-area] WGLC on draft-ietf-intarea-frag-fragile-05 (Tom Herbert)
On Tue, Jan 15, 2019, 6:17 PM Ron Bonica 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. > 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 > > 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 > ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
