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 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".
> * 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?
> * 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).
> * 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.
> * 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?
That said, it's simple: Since atomic-fragments are... atomic :-), you
don't really need to wait for anything else to process them. This means
that you do not need to mix atomic fragments with any other queued
fragments, you do not need to queue the atomic fragments waiting for
anything else, etc. This simplifies the processing, isolates
atomic-fragment processing from any other packets, etc. I cannot really
see how this could introduce a new attack vector.
> Is this an acceptable risk?
> Obviously, packets protected by IPsec would be immune to this attack. At
> a minimum, the Security Considerations should spend some time discussing
> the potential new attacks based on these rules.
I fail to see the attack vector you're describing. i.e., this behaviour
doesn't allow an attacker to do anything he couldn't do already...
Am I missing something? And, if so, could you please elaborate?
> - Introduction
> * s/[RFC2460] allowed/[RFC2460] allows/
> * s/[RFC5722] forbid/[RFC5722] forbids/
> * Provide a forward pointer to Appendix A in paragraph 4
Will do.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: [email protected]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
