RE: Problem about reassembly and fragmentation

[Stephen Kent <kent@bbn.com>]

At 8:02 AM -0800 3/11/02, Scott Fluhrer wrote:
>At 06:11 AM 3/11/02 , Stephen Kent wrote:
>>
>>  [I]n transport mode, the packets received by an IPsec implementation for
>>  outbound processing ought not be fragments, otherwise the implementation has
>>  to assemble them before applying IPsec. In tunnel mode, the IPsec
>>  implementation may receive fragments for outbound processing.  In either
>>  case, the addition of the IPsec headers may require exceed the MTU for the
>>  outbound interface, so the "outer" header (the only header for transport
>>  mode) may exhibit fragmentation. I'd like to push for mandatory use of PMTU
>>  and thus an ability to avoid the need to fragment, and perhaps 
>>avoid the need
>>  to perform reassembly at the receiver, to remove this means of DoS attacks
>>  against receivers.
>
>
>While I appreciate your trying to allow a security gateway to avoid
>fragmentation, I doubt that it will always be practical in IPv4.  I have seen
>networks where either:
>
>- The end application is too stupid to understand PMTU
>- There's a firewall between the security gateway and the end system which
>drops all ICMP messages
>
>In either of these cases, PMTU doesn't work.  And hence, we're either going to
>stop supporting those legacy networks, or we're just going to allow security
>gateways to fragment anyways.
>
>--
>scott

Scott,

I'm surprised that there are many OS instances today (it's not an 
application issue, right?) that still don't respond to PMTU.

As for the firewall problem, there is a complementary issue, 
firewalls and NAT devices that drop fragments, because they can't 
look at port fields.  We had a report at the last meeting of 
experience with NAT devices dropping fragments, which was causing 
problems for the UDP encapsulation strategy. Thus we may have 
problems in both cases and I'd argue for an approach that emphasizes 
MTU-based solutions to these problems, and a minimization of 
fragmentation on both sides of an IPsec implementation.

Steve