RE: Suspect short first fragment?

["Boyan Krosnov" <bkrosnov () lirex bg>]

I'll quote the Host Requirements RFC on fragmentation without any
comments. Maybe I was wrong about it.


====================================
> From RFC1122 = STD0003
-----
MMS_S, the maximum transport-layer message size that
         may be sent for a given {source, destination, TOS} triplet (see
         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
         is performed, the value of MMS_S will be:

            MMS_S = EMTU_S - <IP header size>
-----
We designate by EMTU_S ("Effective MTU for sending") the
         maximum IP datagram size that may be sent, for a particular
         combination of IP source and destination addresses and perhaps
         TOS.
-----
EMTU_R ("Effective MTU to receive"); this is sometimes
         called the "reassembly buffer size".  EMTU_R MUST be greater
         than or equal to 576, SHOULD be either configurable or
         indefinite, and SHOULD be greater than or equal to the MTU of
         the connected network(s).
-----
MMS_R, the maximum message size that can be received and
         reassembled in an IP datagram (see GET_MAXSIZES calls in
         Section 3.4).
-----
3.3.3  Fragmentation

         Optionally, the IP layer MAY implement a mechanism to fragment
         outgoing datagrams intentionally.

         We designate by EMTU_S ("Effective MTU for sending") the
         maximum IP datagram size that may be sent, for a particular
         combination of IP source and destination addresses and perhaps
         TOS.

         A host MUST implement a mechanism to allow the transport layer
         to learn MMS_S, the maximum transport-layer message size that
         may be sent for a given {source, destination, TOS} triplet (see
         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
         is performed, the value of MMS_S will be:

            MMS_S = EMTU_S - <IP header size>

         and EMTU_S must be less than or equal to the MTU of the network
         interface corresponding to the source address of the datagram.
         Note that <IP header size> in this equation will be 20, unless
         the IP reserves space to insert IP options for its own purposes
         in addition to any options inserted by the transport layer.

         A host that does not implement local fragmentation MUST ensure
         that the transport layer (for TCP) or the application layer
         (for UDP) obtains MMS_S from the IP layer and does not send a
         datagram exceeding MMS_S in size.

         It is generally desirable to avoid local fragmentation and to
         choose EMTU_S low enough to avoid fragmentation in any gateway
         along the path.  In the absence of actual knowledge of the
         minimum MTU along the path, the IP layer SHOULD use
         EMTU_S <= 576 whenever the destination address is not on a
         connected network, and otherwise use the connected network's



Internet Engineering Task Force                                [Page 58]
------------------------------------------------------------------------
--------



RFC1122                      INTERNET LAYER                 October 1989


         MTU.

         The MTU of each physical interface MUST be configurable.

         A host IP layer implementation MAY have a configuration flag
         "All-Subnets-MTU", indicating that the MTU of the connected
         network is to be used for destinations on different subnets
         within the same network, but not for other networks.  Thus,
         this flag causes the network class mask, rather than the subnet
         address mask, to be used to choose an EMTU_S.  For a multihomed
         host, an "All-Subnets-MTU" flag is needed for each network
         interface.

         DISCUSSION:
              Picking the correct datagram size to use when sending data
              is a complex topic [IP:9].

              (a)  In general, no host is required to accept an IP
                   datagram larger than 576 bytes (including header and
                   data), so a host must not send a larger datagram
                   without explicit knowledge or prior arrangement with
                   the destination host.  Thus, MMS_S is only an upper
                   bound on the datagram size that a transport protocol
                   may send; even when MMS_S exceeds 556, the transport
                   layer must limit its messages to 556 bytes in the
                   absence of other knowledge about the destination
                   host.

              (b)  Some transport protocols (e.g., TCP) provide a way to
                   explicitly inform the sender about the largest
                   datagram the other end can receive and reassemble
                   [IP:7].  There is no corresponding mechanism in the
                   IP layer.

                   A transport protocol that assumes an EMTU_R larger
                   than 576 (see Section 3.3.2), can send a datagram of
                   this larger size to another host that implements the
                   same protocol.

              (c)  Hosts should ideally limit their EMTU_S for a given
                   destination to the minimum MTU of all the networks
                   along the path, to avoid any fragmentation.  IP
                   fragmentation, while formally correct, can create a
                   serious transport protocol performance problem,
                   because loss of a single fragment means all the
                   fragments in the segment must be retransmitted
                   [IP:9].




Internet Engineering Task Force                                [Page 59]
------------------------------------------------------------------------
--------



RFC1122                      INTERNET LAYER                 October 1989


              Since nearly all networks in the Internet currently
              support an MTU of 576 or greater, we strongly recommend
              the use of 576 for datagrams sent to non-local networks.

              It has been suggested that a host could determine the MTU
              over a given path by sending a zero-offset datagram
              fragment and waiting for the receiver to time out the
              reassembly (which cannot complete!) and return an ICMP
              Time Exceeded message.  This message would include the
              largest remaining fragment header in its body.  More
              direct mechanisms are being experimented with, but have
              not yet been adopted (see e.g., RFC-1063).
> -----Original Message-----
> From: Frank Knobbe [mailto:fknobbe () knobbeits com]
> Sent: Friday, March 01, 2002 7:00 AM
> To: Boyan Krosnov
> Cc: jamie () jamie-sue org; incidents () securityfocus com
> Subject: RE: Suspect short first fragment?
>
>
> On Thu, 2002-02-28 at 14:29, Boyan Krosnov wrote:
> > [...]
> > The minimum really used MTU in the internet is about 550 bytes.
> > [...]
>
>
> Boyan,
>
> could you (or someone else) please explain what this number (550) is
> based on?
>
> Thanks,
> Frank

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com