Subject: Tiny fragments and IPv6

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 28 Nov 2005 05:49:11 -0800

Hi folks,

To summarize the discussion we have had on and off the list, I have put
in a short draft.

Do let me know if you have any comments or suggestions for the same?

Thanks,
Vishwas
========================================================================
==

Routing Working Group                                          V. Manral
Internet-Draft                                                 SiNett
Corp
Expires: May 28, 2006                                        

                           Issues with Tiny Fragments in IPv6
                        draft-manral-ipv6-tiny-fragments-issues-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   IPv6 fragmentation allows fragments to be sent only by the source of
a 
  packet. The Fragment  header is used by an IPv6 source to send a 
  packet larger than would fit in the path MTU to its   destination. 

  Firewalls generally use 5-tuples to filter out packets. However there 
  are cases where  fragmentation can be used to disguise TCP  packets 
  from IP filters used in routers and hosts. This document specifies
where 
  tiny fragments can be issues.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.  Problem Statement

  With many IP implementations it is possible to impose a fragment
small 
  enough to force some of a packet's Upper Layer e.g. TCP header fields
  into the second fragment. 

  This can cause application like firewall and NAT-PT which expect the
fields
  header information in the first fragment to not work properly.

2.  Issues with Firewalls

   There are different types of firewalls and state can be created in
   these firewalls through different methods.  Independent of the
   adopted method, firewalls typically look at five parameters of the
   traffic arriving at the firewalls:

   o  Source IP address

   o  Destination IP address

   o  Protocol type

   o  Source port number

   o  Destination port number

   Based on these parameters, firewalls usually decide whether to allow
   the traffic or to drop the packets.  

  However in cases where the first fragment does not have the upper
layer 
  header information, the firewall is not able to get the port
information and
  other upper layer information, thus allowing the packets to be sent to
the
  protected side.
  
  This can lead to attacks to the network and the firewall not being
able to 
  block such an attack.

3.  Issues with NAT-PT

   NAT-PT [RFC2766] assumes that for NAPT-PT operation the ports are
visible to
   the translator. However if the Upper Layer Header is not there in the
first 
   fragment. This causes the visibility ot the port to be lost. This can
cause the
   translation process to fail.

  When the translator gets a tiny IPv6 fragment which has to be
translated to an 
  IPv4 packet. The translator will have to reassemble the packets as the
IPv4 non
  last  fragment needs to have a datagram size of 68 octets atleast.
  
   STD 5, RFC 791 states:

      Every internet module must be able to forward a datagram of 68
      octets without further fragmentation.  This is because an internet
      header may be up to 60 octets, and the minimum fragment is 8
      octets.

4. Proposed solutions to the problem

  a. Impose a minimum packet size for the non-last fragment.
  
  b. Reassemble the packet, translate the header fields and, glean
relevent 
     information and then pass the original fragments ahead after
modifying the 
     relevent fields.
 
  c. If upper layer protocol present then the header must be there in
the first 
       fragment.

  The above is just a first summary and the proposal are expected to be
changed
  as the draft matures.

5. Issues with fragment size of Minimum MTU

   The minimum fragment size of the non last fragment is set to 1280
octets, the 
   minimum link MTU to be supported [RFC2460] could be specified.
However
   if the IPv6 packet has to be further tunnelled the packet may have to
be 
   fragmented. To prevent such a case a minimum packet size of the
non-last 
  fragment should be less then 1280.

6.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

7.  Security Considerations

   This draft outlines security issues arising if Tiny fragments are
sent.
   This draft raises no new security issues.

7.  Acknowledgements
     
    This draft borrows text heavily from
draft-ietf-mip6-firewalls-03.txt and RFC1858.
    Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, Fred Baker and

    Radhakrishnan.S for the helpful discussion.

9.  References

9.1  Normative References

  [RFC2460] Deering & Hinden, "Internet Protocol, Version 6 (IPv6)
Specification",
            RFC2460, December 1998

  [RFC2766] Tsirtsis & Srisuresh, "Network Address Translation -
Protocol 
            Translation (NAT-PT)", RFC2766, February 2000

9.2  Informative References

  [RFC1858] Ziemba, Reed & Traina ,  "Security Considerations - IP 
            Fragment Filtering", RFC1858, October 1995

Authors' Addresses

   Vishwas Manral
   SiNett Corp
   Bangalore
   India

   Phone: +91-80-5137-7023
   Fax:   +91-80-5137-7001
   Email: [email-masked]

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 28 Nov 2005 11:23:44 -0800

Vishwas,

> Do let me know if you have any comments or suggestions for the same?

The chairs discussed this draft and conclude that it is more of an  
operational issue than a protocol issue.  Due to this, we think the  
discussion should be moved to the V6OPS list.  See:

   http://www.ietf.org/html.charters/v6ops-charter.html

Regards,
Bob Hinden & Brian Haberman
IPv6 w.g. chairs

> Vishwas
.......