[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tiny fragments and IPv6
Hi folks,
To summarize the discussion we had on/off the ipv6 list, I have put in a
short draft. The chairs of the groups (ipv6 and v6ops) wanted the
discussion to move to the v6ops list; hence I am forwarding the
discussion here.
Do let me know if you have any comments or suggestions on the same?
Thanks,
Vishwas
========================================================================
==
Routing Working Group V. Manral
Internet-Draft SiNett
Corp
Expires: May 29, 2006
Operational issues with Tiny Fragments in IPv6
draft-manral-v6ops-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 all middlebox's like firewall and NAT-PT which expect
the
fields header information in the first fragment to not work properly.
Though the NAT Behave draft, states that NAT box should reassemble
the packets, a lot of new issues can result. Keeping state could
result
in easy DoS attacks. Besides the jury is still out about how many NAT
boxes do reassembly.
All policy based devices where packets are forwarded or sent on a
tunnel
based on some policy are also affected.
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. Issues with Policy Boxes
Tiny Fragments could cause issues to Policy boxes which look further
inside the packet, to make decisions.
For IPsec Security Policy Database (SPD) specifies what services are
to be offered to IP datagrams and in what fashion.
The draft [RFC2401bis] states:
"Non-initial" vs "Initial" Fragments
Throughout this document, the phrase "non-initial" fragments is
used to mean fragments that do not contain all of the selector
values that may be needed for access control
And the phrase "initial" fragment is used to mean a fragment that
contains all the selector values needed for access control.
However,
it should be noted that for IPv6, which fragment contains the Next
Layer Protocol and ports (or ICMP message type/code or Mobility
Header
type) will depend on the kind and number of extension headers
present.
Having tiny fragments could mean that none of the fragments would
be
the Initial Fragment. So any access control/ tunneling based on
that
may not work unless reassembly is done, or extra state like next
Header
and previous header length remaining are kept across fragments.
5. 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.
6. Issues with fragment size of Minimum MTU
The minimum fragment size of the non last fragment could be
specified
to be 1280 octets, the minimum link MTU [RFC2460].
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.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
This draft outlines security issues arising if "Tiny Fragments" are
sent. This draft raises no new security issues.
9. 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, Pyda Srisuresh and Radhakrishnan.S for the helpful
discussion.
10. References
10.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
[RFC2401bis] Kent & Seo, "Security Architecture for the Internet
Protocol", Work in Progress, September, 2005
10.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.