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.

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
> <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
>