[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Tiny fragments and IPv6
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: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker
> Sent: Tuesday, November 29, 2005 8:23 AM
> To: v6ops@ops.ietf.org
> 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:
>
> > From: "Vishwas Manral" <Vishwas@sinett.com>
> > Date: November 28, 2005 8:49:11 AM EST
> > To: "IPv6" <ipv6@ietf.org>
> > 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: vishwas@sinett.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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
> > ietf-ipr@ietf.org.
> >
> >
> > 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
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
>