NetBSD Problem Report #55654

From  Fri Sep 11 09:48:22 2020
Return-Path: <>
Received: from ( [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id 09A161A9239
	for <>; Fri, 11 Sep 2020 09:48:22 +0000 (UTC)
Message-Id: <>
Date: Fri, 11 Sep 2020 09:48:18 +0000 (UTC)
Subject: NPF defaults break IP fragment reassembly 
X-Send-Pr-Version: 3.95

>Number:         55654
>Category:       kern
>Synopsis:       NPF defaults break IP fragment reassembly
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    rmind
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 11 09:50:00 +0000 2020
>Last-Modified:  Fri Sep 11 13:54:17 +0000 2020
>Originator:     Frank Kardel
>Release:        NetBSD 9.99.72


System: NetBSD gateway 9.99.72 NetBSD 9.99.72 (GENERIC) #0: Thu Sep 10 06:02:30 UTC 2020 amd64
Architecture: x86_64
Machine: amd64
	On newer -current kernels IP fragment reassembly fails. IP packets with sizes larger
	then the path MTU never reach the application (e. g. x509 IKEv1 ident packets)

	Statistics indication (netstat -s):
	20673 total packets received
	0 bad header checksums
	0 with size smaller than minimum
	0 with data size < data length
	0 with length > max ip packet size
	0 with header length < data size
	0 with data length < header length
	0 with bad options
	0 with incorrect version number
>>>	142 fragments received
	0 fragments dropped (dup or out of space)
	0 fragments dropped (out of ipqent)
	0 malformed fragments dropped
>>>!	136 fragments dropped after timeout
	0 packets reassembled ok
	18759 packets for this host
	0 packets for unknown/unsupported protocol
	806 packets forwarded (0 packets fast forwarded)
	28 packets not forwardable
	0 redirects sent
	0 packets no matching gif found
	0 packets no matching ipsecif found
	20750 packets sent from this host
	7 packets sent with fabricated ip header
	0 output packets dropped due to no bufs, etc.
	0 output packets discarded due to no route
	1 output datagram fragmented
	1 fragment created
	4 datagrams that can't be fragmented
	0 datagrams with bad address in header
	938 input packets dropped by pfil
	482 output packets dropped by pfil
	0 input packets dropped by IPsec
	0 output packets dropped by IPsec
	0 input packets dropped due to interface state
	0 packets dropped due to TTL exceeded
	0 output packets dropped (no IP address)
	36 output packets discarded due to reject route
	0 output packets dropped (broadcast prohibited)
	run a new -current kernel an try to receive fragmented IP packets
	find the commit that broke it...


From: Frank Kardel <>
Subject: Re: kern/55654: IP fragment reassembly broken
Date: Fri, 11 Sep 2020 15:44:04 +0200

 This is a multi-part message in MIME format.
 Content-Type: text/plain; charset=utf-8; format=flowed
 Content-Transfer-Encoding: 7bit

 Analysis shows that NPF disables IP reassembly by default. That is 
 documented in
 npf-params. The IP stack without NPF does do IP reassembly, Once NPF is 
 IP reassembly is disabled unless "set ip4.reassembly on" is in 

 The man page for npf.conf states:

       Fragments are not selectable since NPF always reassembles packets 
       further processing.

 So here the documentation does not agree.

 This change of behavior is surprising to say the least. Furthermore 
 IP reassembly directly violates RFC1122 - Requirements for Internet 
 Hosts -- Communication Layers.

 RFC1122 states:

   Fragmentation and Reassembly:RFC-791 Section 3.2 <>

              The Internet model requires that every host support
              reassembly.  See Sections3.3.2 <>  and3.3.3 <>  for the
              requirements on fragmentation and reassembly.

        3.3.2  Reassembly

           The IP layer MUST implement reassembly of IP datagrams.

 Given that RFC1122 mandates IP reassembly and I did not overlook a relaxation of
 this requirement the option if disabling it is not there.

 So the current NPF behavior/documentation needs to be revisited for following reasons:
 	- Conformance with "Requirements for Internet Hosts"
        - at minimum for the default configuration.
        - inconsistent documentation
        - Violation of POLA on upgrades
        - upgrades simply break existing installations in unexpected 
          ways (see "Requirements for Internet Hosts")

Responsible-Changed-From-To: kern-bug-people->rmind
Responsible-Changed-When: Fri, 11 Sep 2020 13:51:48 +0000
over to committer

State-Changed-From-To: open->analyzed
State-Changed-When: Fri, 11 Sep 2020 13:54:17 +0000
comment contains analysis


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD:,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.