NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/55654: IP fragment reassembly broken

The following reply was made to PR kern/55654; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
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.
 --------------271CAD44F21FF5B907E12585
 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 
 enabled
 IP reassembly is disabled unless "set ip4.reassembly on" is in 
 /etc/npf.conf.
 
 The man page for npf.conf states:
 
       Fragments are not selectable since NPF always reassembles packets 
 before
       further processing.
 
 So here the documentation does not agree.
 
 This change of behavior is surprising to say the least. Furthermore 
 disabling
 IP reassembly directly violates RFC1122 - Requirements for Internet 
 Hosts -- Communication Layers.
 
 RFC1122 states:
 
           3.2.1.4  Fragmentation and Reassembly:RFC-791 Section 3.2 <https://tools.ietf.org/html/rfc791#section-3.2>
 
              The Internet model requires that every host support
              reassembly.  See Sections3.3.2 <https://tools.ietf.org/html/rfc1122#section-3.3.2>  and3.3.3 <https://tools.ietf.org/html/rfc1122#section-3.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")
 
 
 --------------271CAD44F21FF5B907E12585
 Content-Type: text/html; charset=utf-8
 Content-Transfer-Encoding: 8bit
 
 <html>
   <head>
     <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   </head>
   <body text="#000000" bgcolor="#FFFFFF">
     Analysis shows that NPF disables IP reassembly by default. That is
     documented in<br>
     npf-params. The IP stack without NPF does do IP reassembly, Once NPF
     is enabled<br>
     IP reassembly is disabled unless "set ip4.reassembly on" is in
     /etc/npf.conf.<br>
     <br>
     The man page for npf.conf states:<br>
     <br>
          Fragments are not selectable since NPF always reassembles
     packets before<br>
          further processing.<br>
     <br>
     So here the documentation does not agree.<br>
     <br>
     This change of behavior is surprising to say the least. Furthermore
     disabling <br>
     IP reassembly directly violates RFC1122 -  <span class="h1">Requirements
       for Internet Hosts -- Communication Layers.<br>
       <br>
       RFC1122 states:<br>
     </span>
     <pre class="newpage">         3.2.1.4  Fragmentation and Reassembly: <a href="https://tools.ietf.org/html/rfc791#section-3.2";>RFC-791 Section 3.2</a>
 
             The Internet model requires that every host support
             reassembly.  See Sections <a href="https://tools.ietf.org/html/rfc1122#section-3.3.2";>3.3.2</a> and <a href="https://tools.ietf.org/html/rfc1122#section-3.3.3";>3.3.3</a> 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 "<span class="h1">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")
 
 </span><span class="grey"></span></pre>
   </body>
 </html>
 
 --------------271CAD44F21FF5B907E12585--
Home | Main Index | Thread Index | Old Index