Re: I-D Action: draft-ietf-6man-predictable-fragment-id-01.txt

[Fernando Gont <[e-mail]>]

Hi, Ray,

Thanks so much for your feedback! -- Please find my comments in-line...

On 05/06/2014 03:52 AM, Ray Hunter wrote:
> I have read this draft and think thatit is very well written and that it
> is important work. 

Thanks!



> 
>> Finally,
>>    the attacker send forged IPv6 fragments to the Host B, with their
>>    IPv6 Source Address set to that of Host A, and Identification values
>>    that would result in collisions with the Identification values
>>    employed for the legitimate traffic sent by Host A to Host B. If Host
>>    B discards fragments that result in collisions of Identification
>>    values (e.g., such fragments overlap, and the host implements
>>    [RFC5722]), the attacker could simply trash the Identification space
>>    by sending multiple forged fragments with different Identification
>>    values, such that any subsequent packets from Host A to Host B are
>>    discarded at Host B as a result of the malicious fragments sent by
>>    the attacker.
> Comment 1.
> Would this attack also be applicable to any middleware boxes that track
> session progress at the fragmentation level?

It certainly would. Question: do these voxes just "monitor" the traffic
(i.e., just snoop it), or do they actually receive-inspect-filter-if
appropriate)?   -- If the former, the attack could result in "evasion".
If the later, the attack would result in DoS.



> DoS attacker Host C could create a race condition by sending spoofed
> packets from A to B with forged fragment ident values, and the
> middelware box would potentially forward (or attempt to re-assemble)
> these packets in preference to the real next fragments arriving from A.

Agreed. That's, for instance, the DNS data-injection attack referenced
in the I-D.



> s/If Host B discards fragments /If Host B, or any intermediate
> middleware box tracking the session, discards fragments/ ?

I'd personally have the middleware stuff as a separate section or
paragraph.. what do you think?



> Comment 2.
> /The Identification value of the Fragment Header MUST NOT be predictable
> by an off-path attacker./
> 
> I think there should be more of a constraint on what is "good enough"
> 
> Is this not a s/MUST NOT/SHOULD NOT/?
> 
> Nothing actually breaks immediately if the advice is ignored.

I agree with the "nothing breaks" (and could certainly live with a
"SHOULD NOT")... although I'd note that it's pretty common to use
"MUST"s for security reasons... --- as in "the secret key MUST NOT be
known to possible attackers" or the like..

Another view is that if you include a "SHOULD NOT" (rather than MUST),
you should include cases where an implementer might decide to go against
the advice... but I don't see any reasons for that...



> Comment 3.
> I have a concern with the ability of implementations to be able to
> comply with this requirement.
> 
> The effective field length is apparently only 16 bits when used in
> combination with IPv6/IPv4 translation (according to Section 5).
> 
> Sending 2^16 attack packets is not a big ask.

I'd call that "brute forcing" rather than "predicting the ID".


> And it will be far fewer if the attacker relies on birthday type
> collisions to only disrupt 1 in n packets. e.g. if there are many
> packets in the stream and the aim of the attacker is to occasionally
> disrupt the stream they only need to send a fraction of the number of
> attack packets needed to disrupt every single packet.
> 
> So I think I also have to ask "is the fragment ident itself sufficiently
> long/ protected to be resistant to birthday type attacks, especially in
> combination with RFC6415 IPv6/IPv4 translation?"

It's certainly long enough. In this case, the problem is really in IPv4,
that has a far shorter Frag ID. I'd also say that I don't quite
understand why the translators expect to learn a sensible IPv4 Frag ID
from the IPv6 frag ID.  For instance, if the NAT64 box shares the same
IPv4 address among many IPv6 nodes, then, it may even lead to
collissions.  -- e.g.:


Host A   -----------
2001:db8::1         \+--------+
                     |        | 100.0.0.1
                     | NAT 64 +------------------ Host C
Host B   ------------|        |                   8.8.8.8
2001:db8::2          +--------+


Host A sends a packet "to 8.8.8.8" with frag ID 0xaaaa11111. Host B
sends a packet "to 8.8.8.8" with Frag ID 0xbbbb1111. Now both packets
employ the tuple (src 100.0.0.1, dst 8.8.8.8, frag id 0x1111) thus
resulting in a colision of Frag IDs.



> Comment 4.
> Do we also need to mandate /Nodes SHOULD also implement ICMP specific
> attack countermeasures as described in [RFC 5927] / in section 4, to
> prevent an off-path attacker being able force use of fragmentation in
> the first place?

I think they should -- also referencing RFC5927 in such a way would be a
down ref 8bcp/std track mandating an informational document). The only
caveat is: If the header chain is long enough (>1280 bytes), then the
transport protocol header will not be available in the ICMPv6 error.

(Unfortunately, mmany implementations don't even validate it when it's
available)

Thoughts?

Thanks!
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1