Hi,
Brian Haberman <br...@innovationslab.net> writes:
> This Last Call concluded with exactly one public comment. We
> cannot advance this document without support of the working
> group. Please review this draft and state whether you support or
> disagree with advancing it.
I support advancing the document. The content of section 4 should have
been the default in 2460, IMHO. Nonetheless, some minor comments on an
inline version of the document (version 02). Those may have already been
discussed, I did not look at the archives.
> 3. The attack
>
> This attack describes how a malicious node can bypass a firewall
> using overlapping fragments. Consider a sufficiently large IPv6
> packet that needs to be fragmented.
>
>
> +------------------+--------------------//-----------------------+
> | Unfragmentable | Fragmentable |
> | Part | Part |
> +------------------+--------------------//-----------------------+
>
> Figure 1: Large IPv6 packet
>
> This packet is split into several fragments by the sender so that the
> packet can fit inside the path MTU. Let's say the packet is split
> into two fragments.
>
> +------------------+--------+--------------------+
> | Unfragmentable |Fragment| first |
> | Part | Header | fragment |
> +------------------+--------+--------------------+
>
> +------------------+--------+--------------------+
> | Unfragmentable |Fragment| second |
> | Part | Header | fragment |
> +------------------+--------+--------------------+
>
> Figure 2: Fragmented IPv6 packet
>
> Consider the first fragment. Let's say it contains a destination
> options header (DOH) 80 octets long and is followed by a TCP header.
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
> |NextHdr=DOH(60)| Reserved | FragmentOffset = 0 |Res|1|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Identification=aaaabbbb |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==DOH
> |NextHdr=TCP(6) | HdrExtLen = 9 | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
> | |
> . .
> . Options .
> . .
> | |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
> | Source Port | Destination Port |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sequence Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Acknowledgment Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Offset| Reserved |U|A|P|R|S|F| Window |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 3: First Fragment
>
> The TCP header has the following values of the flags S(YN)=1 and
> A(CK)=1. This makes an inspecting stateful firewall think that it is
I would say "This may make". If the initial rule for the creation
of the state specifically require S=1 and A=0, that trick will not
work. It basically depends on the default behavior of the firewall
for the creation of the state and on the specific content of the
ruleset. Netfilter (Linux fw) allows to specify that.
> a response packet for a connection request initiated from the trusted
> side of the firewall. Hence it will allow the fragment to pass. It
> will also allow the following fragments with the same Fragment
> Identification value in the fragment header to pass through.
>
> A malicious node can form a second fragment with a TCP header that
> changes the flags and sets S(YN)=1 and A(CK)=0. This would change
This may change
Here, It depends on the behavior of the remote host: if it consider
prefers first data, this will not work.
> the packet on the receiving end to consider the packet as a
> connection request instead of a response. By doing this the
> malicious node has bypassed the firewall's access control to initiate
> a connection request to a node protected by a firewall.
I am not arguing on the fact this kind of attack may work depending
on the environment, devices and configuration.
>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==FH
> |NextHdr=DOH(60)| Reserved | FragmentOffset = 10 |Res|0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Identification=aaaabbbb |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<==TCP
> | Source Port | Destination Port |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sequence Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Acknowledgment Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Offset| Reserved |U|A|P|R|S|F| Window |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Figure 4: Second Fragment
>
> Note that this attack is much more serious in IPv6 than in IPv4. In
> IPv4 the overlapping part of the TCP header did not include the
> source and destination ports. In IPv6 the attack can easily work to
> replace the source or destination port with an overlapping fragment.
>
>
> 4. Recommendation
>
> IPv6 nodes transmitting datagrams that need to be fragmented MUST NOT
> create overlapping fragments. IPv6 nodes that receive a fragment
> that overlaps with a previously received fragment MUST cease the
> reassembly process and MUST discard the previously received fragments
> with the same IPv6 Source Address, IPv6 Destination Address and
> Fragment Identification.
Simple, efficient. Should have been the default in RFC 2460.
Cheers,
a+
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
