Subject: Fwd: Tiny fragments and IPv6

From: Fred Baker <[email-masked]>
Date: Tue, 29 Nov 2005 08:23:12 -0500

This has been moved to v6ops, as it is more operational in nature  
than a protocol discussion.

Begin forwarded message:

> From: "Vishwas Manral" <[email-masked]>
> Date: November 28, 2005 8:49:11 AM EST
> To: "IPv6" <[email-masked]>
> Subject: Tiny fragments and IPv6
>
> 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: "Margaret Wasserman" <[email-masked]>
Date: Tue, 29 Nov 2005 13:13:12 -0500

Why is this an IPv6-specific problem?  Is there a reason why the same type
of attack does not work in IPv4?

Margaret 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Tuesday, November 29, 2005 8:23 AM
> To: [email-masked]
> Cc: Vishwas Manral
> Subject: Fwd: Tiny fragments and IPv6
> 
> This has been moved to v6ops, as it is more operational in 
> nature than a protocol discussion.
> 
> Begin forwarded message:
> 
> > put in a short draft.
> > Internet-Draft                                              
>    SiNett
> >    IPv6 fragmentation allows fragments to be sent only by 
> the source 
> > of a
> >   other upper layer information, thus allowing the packets 
> to be sent 
> > to the
> >   protected side.
> >
> >    the translator. However if the Upper Layer Header is not 
> there in 
> > the first
> >   IPv4 packet. The translator will have to reassemble the 
> packets as 
> > the
> > IPv4 non
> >   The above is just a first summary and the proposal are 
> expected to 
> > be changed
> >   as the draft matures.
> >
> >
> >    if the IPv6 packet has to be further tunnelled the 
> packet may have 
> > to be
> >    Note to RFC Editor: this section may be removed on 
> publication as 
> > an
> >    RFC.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >     Thanks to Brian Carpenter, Pekka Savola, Stig Venaas, 
> Fred Baker 
> > and
> >
> >    Intellectual Property Rights or other rights that might 
> be claimed 
> > to
> >    attempt made to obtain a general license or permission 
> for the use 
> > of
> repository 
> > at
> >    This document and the information contained herein are 
> provided on 
> > an

---

From: Fred Baker <[email-masked]>
Date: Tue, 29 Nov 2005 14:17:34 -0500

It does happen in IPv4. Vishwas' concern is that the attack that  
happens in IPv4 might happen in IPv6, and is wondering whether there  
are best practices that we can discuss to minimize the impact.