[ipv6hackers] funny FreeBSD bug

[Marc Heuse]

I found a funny bug in freebsd (9.0 with all updates):
if you send an ICMP toobig message to it with a too low MTU size,
FreeBSD will prepend any packet data with an one-shot fragment (or
atomic fragment as Fernando calls it).

IPv6Hdr
Frag Hdr Offset 0, No more Frags Bit set
ICMP6/TCP/UDP

to test with the thc-ipv6 package (v1.9):
toobig6 eth1 freebsd-ipv6-addr your-ipv6-addr 68

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A
_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

[Simon Perreault]

Le 2012-07-26 08:35, Marc Heuse a écrit :
> I found a funny bug in freebsd (9.0 with all updates):
> if you send an ICMP toobig message to it with a too low MTU size,
> FreeBSD will prepend any packet data with an one-shot fragment (or
> atomic fragment as Fernando calls it).

Why do you think it's a bug? Seems like normal IPv6 behaviour to me.
It's in the RFC...

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca

[Marc Heuse]

Hi Simon,

Am 26.07.2012 17:47, schrieb Simon Perreault:
> Le 2012-07-26 08:35, Marc Heuse a écrit :
>> I found a funny bug in freebsd (9.0 with all updates):
>> if you send an ICMP toobig message to it with a too low MTU size,
>> FreeBSD will prepend any packet data with an one-shot fragment (or
>> atomic fragment as Fernando calls it).
>
> Why do you think it's a bug?

first it servs no use to add the fragmentation header if the packet is
not fragmented. second I have not seen this behaviour in other OS,
however I havent looked for it though.

> Seems like normal IPv6 behaviour to me. It's in the RFC...

I cant remember having seen this in any rfc - do you have a pointer?

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Simon Perreault]

Le 2012-07-26 10:26, Marc Heuse a écrit :
>> Why do you think it's a bug?
>
> first it servs no use to add the fragmentation header if the packet is
> not fragmented. second I have not seen this behaviour in other OS,
> however I havent looked for it though.
>
>> Seems like normal IPv6 behaviour to me. It's in the RFC...
> I cant remember having seen this in any rfc - do you have a pointer?

RFC 2460 section 5:

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.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca

[Fernando Gont]

Hi, Marc,

On 07/26/2012 12:35 PM, Marc Heuse wrote:
> I found a funny bug in freebsd (9.0 with all updates):
> if you send an ICMP toobig message to it with a too low MTU size,
> FreeBSD will prepend any packet data with an one-shot fragment (or
> atomic fragment as Fernando calls it).
>
> IPv6Hdr
> Frag Hdr Offset 0, No more Frags Bit set
> ICMP6/TCP/UDP

This is not a bug, but intended behaviour. It is meant to handle the
case of v6/v4 translators. A translator may receive an IPv6 packet that
needs to be fragmented before sending it to the IPv4 world. In that
case, it may send an ICMPv6 PTB with a MTU<1280. This will cause the
IPv6 sending host to include a Fragment Header in each packet, thus
selecting an appropriate Fragment ID. When the translator receives such
fragments, it will use the received Fragment ID for the IPv4 fragments.

The aforementioned behavior is required by stateless translators.

See slide 35 of
<http://www.si6networks.com/presentations/just4meeting2012/fgont-just4meeting2012-recent-advances-in-ipv6-security.pdf>
for a list of systems that support this behavior.

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Marc Heuse]

Thank you Simon, even after that many years there is something new to
learn in ipv6 :-)
Current Windows 7 now behaves the same as well, my Linux does not
(Fernado documented that it is in the 3.x kernel though)

Greets,
Marc

Am 26.07.2012 19:36, schrieb Simon Perreault:
> Le 2012-07-26 10:26, Marc Heuse a écrit :
>>> Why do you think it's a bug?
>>
>> first it servs no use to add the fragmentation header if the packet is
>> not fragmented. second I have not seen this behaviour in other OS,
>> however I havent looked for it though.
>>
>>> Seems like normal IPv6 behaviour to me. It's in the RFC...
>> I cant remember having seen this in any rfc - do you have a pointer?
>
> RFC 2460 section 5:
>
> 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.
>
> Simon

--

--
Marc Heuse
Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A