Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Tom Herbert <[e-mail]>]

On Wed, Aug 29, 2018 at 5:32 PM, Joe Touch <[e-mail]> wrote:
>
>
>
>
> On 2018-08-29 10:38, Tom Herbert wrote:
>
>
> I don't think you need the part about acting as a host, that would
> have other implications.
>
>
> It does, and that's exactly why you do. In particular, this includes ICMP
> processing.
>
>
> Also, the reassembly requirement might be
> specific to NAT and not other middlebox functionality. For instance,
> it would be sufficient for a firewall that is dropping UDP packets to
> some port to only drop the first fragment that has UDP port numbers
> and let the other fragments pass. Without the first fragment
> reassembly at the destination will simply timeout and the whole packet
> is dropped.
>
>
> And that's a great example of why not reassembling (or equivalent) isn't the
> appropriate behavior.
>
> Yes, the packet will still not be delivered, but the receiver will end up
> doing a lot of work that isn't necessary. I.e., the middlebox has ignored
> work it was responsible for and caused work elsewhere.

Joe,

End hosts are already quite capable of dealing with reassembly, I
think you'll find the average middlebox is not prepared to handle it.
In truth, for this case it really doesn't save the hosts much at all.
A DOS attack on fragmentation is still possible by the attacker
sending all but the last fragment to a port that is allowed by the
firewall. Also, a destination host will receive all the fragments for
reassembly by virtue of it being the having destination address in the
packets. As discussed previously, there's no guarantee that a firewall
will see all the packets in a fragment train in a mulithomed
environment-- routing may take packets along different paths so they
hit hit different firewalls for a site. The answer to that seems to be
to somehow coordinate across all the firewalls for a site to act as
single host-- I suppose that's possible, but it would be nice to see
the interoperable protocol that makes that generally feasible at any
scale.

>
> Further, acting as a host is always the right thing for any node that
> sources packets with its own IP address -- that includes NATs and regular
> proxies. The behavior of transparent proxies is more complex, but can be
> similarly reasoned from the appropriate equivalence model.

Proxies aren't quite the same though. An explicit proxy at least is
both receiving and sourcing packet based on it's own address. NAT only
sources or receive packets with their own address half the time.
Firewalls, never do and don't even need a host address.

Tom