Hi Vlad,
Thanks a lot for your clarification, maybe I am unclear. I am
attaching a document I have attached, just have a look.
First, this only happens when the IPv4 host does not support path mtu
discovery (DF bit is 0). In this case, inserting a fragment header
at the translator in essence performs the fragmentation that was
requested by the sender. I just so happens that in this case the
fragment might have offset and M flag set to 0.
There are 2 sides of the problem. The first is that different
protocols use different definition of a fragment, which needs to be
clarified, because some assumption by a protocol may not work in many
cases due to the specification clarity. The second part is the use of
different policies for fragments.
The idea I am stating is that one spec uses the Fragment header to
just signal its ability to perform fragmentation, while others
specs(AH & ESP for one) clearly lay down a differnet way for
identifying an IPv6 fragment and its subsequent treatment. As there
are different policies for fragments, the signaling may not work in
many cases(no I am not talking about policies but the clarification of
the term Fragment - example a Fragment with M = 0 and Offset = 0
should be treated as a non fragmented packet). I do not see any
problem in clarifying exactly what an IPv6 fragment is so that we can
have a consistent set of specs as well as implementations.
Now you are getting in policies outside of the definition. The definition
does not have to encompass all eventual uses. Otherwise we'll be updating
a lot more specs.
No, I am talking about specs too besides practical network scenarios.
If we see a problem in a spec I do not see a reason we should hesitate
in fixing the problems (and its not unprecedented either).
Thanks,
Vishwas
On 6/25/07, Vlad Yasevich <[EMAIL PROTECTED]> wrote:
Vishwas Manral wrote:
> Hi Suresh/ Vlad,
>
> For SIIT the fragment header is used to signal the ability to
> fragment, it does not state it is a fragment itself.
First, this only happens when the IPv4 host does not support path mtu
discovery (DF bit is 0). In this case, inserting a fragment header
at the translator in essence performs the fragmentation that was
requested by the sender. I just so happens that in this case the
fragment might have offset and M flag set to 0.
>
>> A fragment with offset 0 and M flag 0 is just treated as the ONLY
>> fragment. No harm don
> But there are different policies for fragments, including some that
> drop fragments. It is not the correct behavior, I feel the definition
> of a fragment should be clarified.
Now you are getting in policies outside of the definition. The definition
does not have to encompass all eventual uses. Otherwise we'll be updating
a lot more specs.
-vlad
Network Working Group V. Manral
Internet-Draft IP Infusion
Expires: December 25, 2007
June 26, 2007
IPv6 Fragments and treatment of Tiny fragments
draft-manral-ipv6-fragments-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 December 25, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
[RFC2460] defines an IPv6 header called "Fragment Header", which is
identified by a Next Header value of 44 in the immediately preceding
header. This document clarifies the definition of an IPv6 fragment
Manral, et al. Expires December 25, 2007 [Page 1]
Internet-Draft IPv6 Fragments June 2007
as well as defines the treatment of what consititues a tiny IPv6
Fragment.
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].
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Fragment . . . . . . . . . . . . . . . . . . . . . . . 3
3. Tiny Fragments and issues . . . . . . . . . . . . . . . . . 4
4. Additional checks required . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . 10
Manral, et al. Expires December 25, 2007 [Page 2]
Internet-Draft IPv6 Fragments June 2007
1. Problem Statement
The definition of Fragments is slightly vague in the IPv6 specification.
This has resulted in different specification using different ways for
identifying fragments. The SIIT [RFC2765] specification uses a fragment
header to signal the ability of a node to fragment an IPv6 packet, the
ESP [RFC4303] and AH [RFC4302] assume the existence of an IPV6 Fragment
header identifies an IPv6 Fragment. As different policies are applied for
fragments and non-fragments in middle boxes, such ambiguity in the
specification can lead to issues.
Middleboxes generally use 5-tuples to filter out packets. However there
are cases where fragmentation can be used to disguise TCP packets
from IP filters and other middleboxes [Tiny-Fragment] used in routers and
hosts. This document also specifies ways to identify tiny fragments and
the subsequent action that needs to be taken, once such a fragment is
identified.
2. IPv6 Fragment
The IPv6 specification [RFC2460] defines a fragment header as:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Reserved | Fragment Offset |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header 8-bit selector. Identifies the initial header
type of the Fragmentable Part of the original
packet (defined below). Uses the same values as
the IPv4 Protocol field [RFC-1700 et seq.].
Reserved 8-bit reserved field. Initialized to zero for
transmission; ignored on reception.
Fragment Offset 13-bit unsigned integer. The offset, in 8-octet
units, of the data following this header,
relative to the start of the Fragmentable Part
of the original packet.
Res 2-bit reserved field. Initialized to zero for
transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits is used for facilitating each fragment is
correctly reassembled at the receiver.
An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6
Fragment header as described above, having either the More flag or the
Fragment Offset set to have a non 0 value.
Manral, et al. Expires December 25, 2007 [Page 3]
Internet-Draft IPv6 Fragments June 2007
In turn if an IPv6 packet contains a fragment header, with both the More
flag as well as the Fragment Offset fields set to, it is treated exactly
like an IPv6 packet without the Fragment header.
3. Tiny Fragments and issues
An IPv6 Tiny Fragment is defined as a non-last fragment which has a payload
length of less than 1200 octets.
A lot of middleboxes (firewalls/ IDS and IPS devices) idenfity sessions based
on a 5-tuple of Source IP address, Destination IP Address, Upper Layer
protocol, and the souce and destination ports of the protocol. Such
information is available in the first Fragment (Fragment Offset 0 and M flag
as 1). However in order to bypass checks in middleboxes, smaller first
fragments can be sent.
This document specifies the behavior of any router on encountering a Tiny
Fragment. A Tiny Fragment should be treated to have malicious intent and
SHOULD
be silently dropped.
Manral, et al. Expires December 25, 2007 [Page 4]
Internet-Draft IPv6 Fragments June 2007
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Manral, et al. Expires December 25, 2007 [Page 5]
Internet-Draft IPv6 Fragments June 2007
5. Security Considerations
This draft outlines security issues arising from the use of tiny fragments.
It further clarifies the definition of a Fragment Header. This draft enhances
the security of IPv6 network and helps prevent attacks caused by tiny
fragments or spec ambiguity.
No new security requirements result from such proposals.
Manral, et al. Expires December 25, 2007 [Page 6]
Internet-Draft IPv6 Fragments June 2007
6. Acknowledgements
The subject of this draft has been discussed in detail in the IPv6 mailing
list.
Elwyn Davies, Suresh Krishnan specially contributed ideas to this draft.
Manral, et al. Expires December 25, 2007 [Page 7]
Internet-Draft IPv6 Fragments June 2007
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC1700] Reynolds J. and J. Postel, "Assigned Numbers", RFC1700,
October 1994
7.2 Informative References
[I-D.manral-v6ops-tiny-fragments-issues-02]
Manral V., "Operational issues with Tiny Fragments in IPv6",
(work in progress), July 2006.
[RFC2765] Nordmark E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
February 2000
[RFC4302] Kent S., "IP Authentication Header (AH)", RFC4302,
December 2005
[RFC4303] Kent S., "IP Encapsulating Security Payload (ESP)", RFC4303,
December 2005
Manral, et al. Expires December 25, 2007 [Page 8]
Internet-Draft IPv6 Fragments June 2007
Contributors Address
Authors' Addresses
Vishwas Manral
IP Infusion
Almora, Uttarakhand
India
Phone:
Fax:
Email: [EMAIL PROTECTED]
Manral, et al. Expires December 25, 2007 [Page 9]
Internet-Draft IPv6 Fragments June 2007
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 PROTECTED]
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.
Manral, et al. Expires December 25, 2007 [Page 10]
Internet-Draft IPv6 Fragments June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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-
[EMAIL PROTECTED]
Manral, et al. Expires December 25, 2007 [Page 11]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
