Re: Review of draft-gont-6man-deprecate-atomfrag-generation-01

[Hosnieh Rafiee <[e-mail]>]

Hi Fernando,
Thanks a lot for your review and comments. Sure i will review your draft and send commens to you first and then if you like to the mailinglist.
Best,
Hosnieh


___________________________
“sorry for tpyos from my chubby fingers typing on my phone“

-------- Original message --------
Subject: Re: Review of draft-gont-6man-deprecate-atomfrag-generation-01 
From: Fernando Gont <[e-mail]> 
To: Hannes Frederic Sowa <[e-mail]> 
CC: [e-mail] 

Hi, Hannes,

On 09/16/2014 05:56 PM, Hannes Frederic Sowa wrote:
>> (Actually, I'll try to check that with a current Linux kernel..)
>>
>>
>>> So the unkown variables
>>> for an attacker would be the connection quadruple and the sequence
>>> numbers. Hitting non-connected UDP on Linux sockets seems pretty easy,
>>> but TCP might not be as easy.
>>
>> Does an ICMPv6 PTB targetted at a UDP socket span all sockets with that
>> Destination Address? i.e., could I use UDP (which enforces fewer checks)
>> to attack TCP flows?
> 
> Yes, you can.

So... if there's a socket with the same remote address, the TCP SEQ
check can be bypassed by performing the attack with ICMPv6 messages
embedding UDP packets. (just double-checking)



> So next outgoing packet will already use new mtu information.
> 
> Kernel before 3.14 also used this MTU value for the forwarding path but
> did not look at dst_allfrag attribute (which is the function which
> checks if atomic fragments should be generated).

"Forwarding path" meaning "if the box is operating as a router for this
packet"?


[...]
>>> OT:
>>> This is very well true! On Linux still we use per-host increasing
>>> randomized IDs, but at least since the paper "Counting Packets Sent
>>> Between Arbitrary Internet Hosts" by Jeffrey Knockel and Jedidiah
>>> Crandall showed up, we also seed in a bit of randomness.
>>
>> We had sent a report to some Linux folks regarding issues with
>> predictable Frag IDs arounf 2010 or 2011. At the time, it was changed
>> from a global counter to a per-dest counter (initialized to a random
>> value, IIRC).
>>
>> Has anything changed since then? e.g., what do you mean by "seed in a
>> bit of randomness).
> 
> The above paper showed that it is possible to infer from the
> fragmentation ids if two independent machines on the internet are
> communicating with each other:
> 
> https://www.cs.unm.edu/~crandall/foci2014.pdf

I'll check the paper.



>>> Also multiple
>>> IP addresses now share one IP-state "bucket".
>>
>> That's so that the per-destination counter is less deterministic, or what?
> 
> The tree we kept the per-destination in became a bottleneck: The new
> method uses less memory and does faster lookup. A side effect is also
> that the per-destination counter are less deterministic.
> 
> The new hash to store the counters also keeps a timestamps to later
> check when the last fragmentation id was used.
> 
> In case we didn't communicate with a host for some time we add a random
> value clamped to (current time - last timestamp).

Cool. Thanks for the clarification.


> 
> 
>>> I still think that for generating fragmentation ids using just an
>>> increasing counter and encrypting it with a very small block cipher
>>> (e.g. RC5) is the way to go, but very slow.
>>
>> Take a look at the hash-based approach in
>> [I-D.ietf-6man-predictable-fragment-id]. You probably get the same
>> thing... but faster...
> 
> I think you're referring to 6.3? I'll study that, thanks!

Section 5.3. -- As far as I recall, Linux uses/used the same sort of
algorithm for TCP port randomization -- with the exception that you
employ a global counter rather than counter[G(src IP, Dst Pref, secret2)]




>>>> 5.  Updating RFC2460
>>>>
>>>>    The following text from Section 5 of [RFC2460]:
>>>>
>>>>       "In response to an IPv6 packet that is sent to an IPv4 destination
>>>>       (i.e., a packet that undergoes translation from IPv6 to IPv4), the
>>>>       originating IPv6 node may receive an ICMP Packet Too Big message
>>>>       reporting a Next-Hop MTU less than 1280.  In that case, the IPv6
>>>>       node is not required to reduce the size of subsequent packets to
>>>>       less than 1280, but must include a Fragment header in those
>>>>       packets so that the IPv6-to-IPv4 translating router can obtain a
>>>>       suitable Identification value to use in resulting IPv4 fragments.
>>>>       Note that this means the payload may have to be reduced to 1232
>>>>       octets (1280 minus 40 for the IPv6 header and 8 for the Fragment
>>>>       header), and smaller still if additional extension headers are
>>>>       used."
>>>>
>>>>    is formally replaced with:
>>>>
>>>>       "An IPv6 node that receives an ICMPv6 Packet Too Big error message
>>>>       that reports a Next-Hop MTU smaller than 1280 bytes (the minimum
>>>>       IPv6 MTU) MUST NOT include a Fragment header in subsequent packets
>>>>       sent to the corresponding destination.  That is, IPv6 nodes MUST
>>>>       NOT generate IPv6 atomic fragments."
>>>
>>> This is the same as ignoring the packet? Should we still notify any
>>> errors without updating path MTUs?
>>
>> The original advice was to just drop the ICMPv6 PTB. However, it was
>> later noted that still notifying the errors (without updating the Path
>> MTU) would be better. -- And I'd say I'd agree. e.g., ythat could result
>> in a more specific error message if eventually e.g. the TCP connection
>> times out.
>>
>>
>>> I am not sure because user space might have cared about IPv6 < 1280
>>> errors before and they very well might be listening for them.
>>
>> Any ideas what they might be using those ICMPv6 PTB for? -- The only
>> consumer for ICMPv6 PTBs<1280 is SIIT... so one would expect that any
>> other app would just drop those PTBs if received....
> 
> I also only think those would be SIIT applications sitting on top of
> Linux. I am unsure if they can make use of those notifications any more,

Why?


> but I don't think they will upgrade right away. If we push the changes
> to linux stable, all currently supported kernel will ignore PTB<1280
> right away, that's why I ask.

Certainly the idea is that the kernel ignores PTB<1280. If it's also
possible to still notify the errors to the upper layer, that'd be
perfect. Thus e.g. TCP can report a more specific error message other
than "timeout" and, if there's any upper-layer app that has not yet been
patched to *not* rely on ICMPv6 PTBs, it can still do its job.

Thoughts?



>>> I am a bit unsure but hadn't yet time to test this. We definitely have
>>> the logic to generate atomic fragments in those mentioned linux
>>> versions.
>>
>> Since there are tools to do that
>> (<http://www.si6networks.com/tools/ipv6toolkit>), I'll try to check that
>> for TCP, UDP, and ICMPv6.
> 
> Merci! I also attached a packetdrill snippet in the other mail, which
> you could use in FreeBSD (IIRC) and Linux to check the stacks behavior.

I'll report back asap.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492




--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------