On 12/17/12 10:54 AM, Fernando Gont wrote:
Hi, Brian,
Thanks so much for your feedback! -- Please find my comments inline...
On 12/13/2012 03:57 PM, Brian Haberman wrote:
Substantive
----------------
* It would be quite useful to explicitly define "atomic fragment" prior
to using it in the document. This could be done in the Introduction in
a formal manner and the use of "atomic fragments" in the Abstract can be
re-worded.
How about this:
* Change the first sentence of the Abstract to:
"The IPv6 specification allows packets to contain a Fragment Header
without the packet being actually fragmented into multiple pieces
(we refer to these packets as "atomic fragments")."
* Change the last sentence of the third para of "1. Introduction" to:
"The resulting packets
will thus *not* be actually fragmented into several pieces, but just
include a Fragment Header with both the "Fragment Offset" and the "M"
bit set to 0 (we refer to these packets as "atomic fragments")."
* Have a new new section right after "Introduction", with the following
contents:
---- cut here ----
2. Terminology
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].
IPv6 atomic fragments
IPv6 packets that contain a Fragment Header with the Fragment
Offset set to 0 and the M bit set to 0.
---- cut here ----
The above sounds reasonable.
* The Introduction needs to provide more motivation as to why we should
allow these atomic fragments to exist. Please provide the rationale
discussed on the mailing list about how v4/v6 translators use the
fragmentation information.
How about incorporating this text as a parenthetical note (indented
text) right after the third para of Section 1:
"IPv6/IPv4 translators employ the Fragment Identification information
found in the Fragment Header to select an appropriate Fragment
Identification value for the resulting IPv4 fragments".
I am fine with adding the above text. Not sure that it needs to be
indented though.
* The core source of this attack is that some implementations have
predictable algorithms for generating the Fragmentation ID, allowing
attackers to launch these types of attacks. It would be good to
reference that work in this draft as well.
draft-gont-6man-predictable-fragment-id is referenced as
"[PREDICTABLE-ID]" throughout this document. Is there anything I'm missing?
After re-reading the portions containing the above reference, I don't
think there are any needed changes for this point.
* What is the purpose of the indented paragraph within the first bullet
of the list in section 2? Is it a quote from one of the two referenced
RFCs?
The bullet notes that some implementations fail to validate the ICMPv6
error messages. The indented text notes that it may be virtually
impossible to do so (i.e., a clarification).
I would suggest just making that text a part of the bulleted text.
Typically, indented text is a quotation.
* It is not clear to me why the document spends much time on discussing
ICMP-based attacks on the source of traffic, especially ones that ignore
existing RFCs, when the issue is really with devices that don't do the
right thing on the receiving end.
Because by means of ICMPv6-based attacks an attacker can *trigger* the
use of IPv6 atomic fragments. Without such ability, an attacker could
only leverage atomic fragments for communication flows that legitimately
employ them.
The point of this draft is to fix the re-assembly behavior at the
receiver. There are a variety of ways for an attack to be launched that
do not involve anything being sent to the sender, ICMP or not.
* I am rather disappointed with the Security Considerations section
given that this draft is addressing a perceived security vulnerability.
Well, the Sec Cons section is "as simple as it can be". I could
certainly make it longer, if deemed appropriate... But I personally
think that it says what it needs to say: this document eliminates the
aforementioned attack vector.
In fact, I would like to ask the WG if the solution actually creates an
attack vector on receiving hosts. An on-device path could modify
packets with Fragmentation headers by setting Offset=0 and M=0. This
would cause the receiver to blindly treat the packet as an atomic and
pass it up to the upper-layer protocol.
If the attacker is on path -- and essentially a man in the middle -- why
would he bother to do this if he can simply blackhole the legtimate
atomic-fragment, and create/send a new one?
No, these are not legitimate atomic fragments. Let's say that a source
fragments a packet into three packets. The attacker sees one of these
packets and changes the offset and/or M to 0 in order to make that one
fragment look like an atomic.
The receiver processes the modified fragment as atomic and passes it up
to the upper-layer protocol. My question to the WG is whether or not
people see that as an issue.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
