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

[Ray Hunter <[e-mail]>]

Fernando Gont wrote:
> Hi, Hannes,
>
> Thanks so much for the review! Please find my comments in-line...
>
> On 09/16/2014 06:04 AM, Hannes Frederic Sowa wrote:
>>>     o  Only the IPv6 addresses of the IPv6 packet embedded in the ICMPv6
>>>        payload need to be forged.  While one could envision filtering
>>>        devices enforcing BCP38-style filters on the ICMPv6 payload, the
>>>        use of extension (by the attacker) could make this difficult, if
>>>        at all possible.
>> On FreeBSD and Linux you must hit an open socket to get the ICMP PtB
>> error to be accepted. E.g. FreeBSD does not deal with ICMP PtB messages
>> at all on UDP and on both, FreeBSD and Linux, the payload of the ICMP
>> message will also be checked to the TCP-window.
>
> What if the TCP header is not there? Is the ICMPv6 dropped?
>
> (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?

I think the basic question is "what do the Linux kernel developers 
consider as a 'flow'?"

RFC 1192 and RFC 4821 are deliberately vague.

You are correct, Fernando: if the flow is simply cached based on 
<destination address> then you could use UDP to attack TCP.

But even if a "flow" is identified as the duple <destination address, 
transport protocol> then you could also potentially target an attack 
against NFS or FCIP over TCP by targeting an HTTP or other seemingly 
innocuous loopback process listening on another interface on the device, 
that may connected to a completely different network.

if a "flow" was identified as the triple <destination address, transport 
protocol, outbound interface> or<destination address, transport 
protocol, sourceaddress> that attack would be tougher.

However, if the "flow" was <destination address, sourceaddress, 
transport protocol, source port, destination port> you'd be far less 
likely to be able to cache the learned MTU to be used on other sessions, 
meaning PMTUD effectively becomes PLPMTUD.

Unless the developers used something like <destination address, 
sourceaddress, transport protocol, "passive open port"> and remembered 
which party initiated the flow via a passive open (server) and which an 
active open (client).


>
> [....]
>>>     In such a scenario, if each translator were to select the IPv4
>>>     Fragment Identification on its own (rather than selecting the IPv4
>>>     Fragment ID from the low-order 16-bits of the Fragment Identification
>>>     of atomic fragments), this could possibly lead to IPv4 Fragment ID
>>>     collisions.  However, since a number of implementations set IPv6
>>>     Fragment ID according to the output of a Pseudo-Random Number
>>>     Generator (PRNG) (see Appendix B of
>>>     [I-D.ietf-6man-predictable-fragment-id]) and the translator only
>>>     employs the low-order 16-bits of such value, it is very unlikely that
>>>     relying on the Fragment ID of the IPv6 atomic fragment will result in
>>>     a reduced Fragment ID collision rate (when compared to the case where
>>>     the translator selects each IPv4 Fragment ID on its own).
>> 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).
>
>
>> Also multiple
>> IP addresses now share one IP-state "bucket".
>
> That's so that the per-destination counter is less deterministic, or what?
>
>
>
>> 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...
>
>
>>> 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....
>
>
>> So in an operating system we just don't update the "destination cache"
>> anymore but we don't treat it as an illegal ICMP error?
>
> Exactly.
>
>
>
>>> Appendix A.  Small Survey of OSes that Fail to Produce IPv6 Atomic
>>>               Fragments
>>>
>>>     [This section will probably be removed from this document before it
>>>     is published as an RFC].
>>>
>>>     This section includes a non-exhaustive list of operating systems that
>>>     *fail* to produce IPv6 atomic fragments.  It is based on the results
>>>     published in [RFC6946] and [Morbitzer].
>>>
>>>     The following Operating Systems fail to generate IPv6 atomic
>>>     fragments in response to ICMPv6 PTB messages that report an MTU
>>>     smaller than 1280 bytes:
>>>
>>>     o  FreeBSD 8.0
>>>
>>>     o  Linux kernel 2.6.32
>>>
>>>     o  Linux kernel 3.2
>>>
>> 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.
>
> Thanks!
>
> Best regards,

-- 
Regards,
RayH