Hi, Brian, On 12/18/2012 01:32 PM, Brian Haberman wrote:
>> 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: [....] > > The above sounds reasonable. I will apply these changes to the next rev. >>> * 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 way I use indented text is to include info that is essentially a "clarification" of something, but that you don't need to read to understand the document. >>> * 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. OK, will do. >>> * 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. That note is meant to be a warning along the lines of "look, the trouble here s not just attacks against existing atomic-fragment traffic, since an attacker can actually trigger the generation of such atomic-fragments for any communication flow.". i.e., it notes that, at the end of the day, this change benefits not only communication flows already employing atomic fragments, but rather *all* communication flows, since it is trivial to trigger generation of atomic fragments. I guess one might argue that part of this could be moved to the Sec Cons section... but I thought it was too important/central to comment on it only at the Sec Cons section. >>> 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. What would be the difference between this, and simply removing the fragments from the net, and re-send the packets as e.g., non-fragmented traffic? i.e., the bottom-line is that once the attacker becomes on-path (not to mention "man in the middle"), this is kind of "game over". Things become pretty much "IPsec or death". > 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. Me, I don't see any issues here. For instance, it is very likely that, as a result of this, some upper layer checksum will fail, and end the packet will be drooped by the destination system. Also, as noted above, if I was an attacker and for some reason wanted a legitimate fragment to be "passed up" without any further processing/reassembly, I'd simply re-encapsulate such contents in a non-fragmented packet (e.g., rather than clearing the M and FO bits, I'd simply remove the Frag header). In any case, I wonder what the "goal" that you think the attacker would have in mind... because if the attacker is a MITM or is simply on-path, and the goal is DoS, he can simply drop packet or corrupt them, rather than playing with this particular issue. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
