[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4F52B08E.1090109@si6networks.com>
Date: Sat, 03 Mar 2012 21:00:14 -0300
From: Fernando Gont <fgont@...networks.com>
To: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
CC: Full Disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Security Implications of Predictable IPv6 Fragment Identification
values (rev'ed IETF I-D)
Folks,
We have published a revision of the aforementioned IETF Internet-Draft.
The revised document is available at:
<http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-01.txt>.
A diff from the previous version is available at:
<http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-00.txt&url2=http://tools.ietf.org/id/draft-gont-6man-predictable-fragment-id-01.txt>.
This version incorporates lots of detailed feedback sent by Ivan Arce
(Thanks Ivan!).
Any comments will be welcome.
P.S.: Other IETF I-Ds on the subject are available at:
<http://www.si6networks.com/presentations/ietf.html>. And yes, you can
follow us on twitter: @SI6Networks
Best regards,
Fernando
-------- Original Message --------
Subject: New Version Notification for
draft-gont-6man-predictable-fragment-id-01.txt
Date: Sat, 03 Mar 2012 15:02:10 -0800
From: internet-drafts@...f.org
To: fgont@...networks.com
A new version of I-D, draft-gont-6man-predictable-fragment-id-01.txt has
been successfully submitted by Fernando Gont and posted to the IETF
repository.
Filename: draft-gont-6man-predictable-fragment-id
Revision: 01
Title: Security Implications of Predictable Fragment Identification Values
Creation date: 2012-03-03
WG ID: Individual Submission
Number of pages: 21
Abstract:
IPv6 specifies the Fragment Header, which is employed for the
fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the
IPv6
Source Address and the IPv6 Destination Address of the packet,
identifies fragments that correspond to the same original datagram,
such that they can be reassembled together at the receiving host.
The only requirement for setting the "Identification" value
is that
it must be different than that of any other fragmented packet sent
recently with the same Source Address and Destination Address. Some
implementations simply use a global counter for setting the Fragment
Identification field, thus leading to predictable values. This
document analyzes the security implications of predictable
Identification values, and updates RFC 2460 specifying additional
requirements for setting the Fragment Identification, such that the
aforementioned security implications are mitigated.
The IETF Secretariat
Powered by blists - more mailing lists