Subject: [v6ops] TCP related attacks/RFC3128

From: Hemant Singh <[email-masked]>
Date: Wed, 11 Jan 2017 11:51:33 -0500

I was looking at RFC3128.  It's not specific to v6ops, but being a RFC that
covers TCP small fragment attacks, I thought I'd send the email.  I also
think, the IETF WG that sponsored this RFC may be closed now.

I wonder who approved this document because it has basic mistakes.

(a) In section 2.1, the document uses "Fragment A" and also "B" for the
first time and does not define them anywhere.
(b) In section 2, in relation to Fragment 3, the document says "Fragment
offset >=2".  In the IP header, the fragment offset is a multiple of 8
octets, and thus == 2 is incorrect.

Please let me know if there is a current IETF WG covering such issues.

Thanks,

Hemant

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jan 2017 09:10:31 +1300

Hi Hemant,

The tracker shows that it was an individual draft directly submitted
to the IESG, so no WG was involved.

Why don't you submit errata at https://www.rfc-editor.org/errata.php ?

Regards
   Brian

On 12/01/2017 05:51, Hemant Singh wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 11 Jan 2017 13:58:30 -0800

Hi, Hemant,

On 1/11/2017 8:51 AM, Hemant Singh wrote:
> I was looking at RFC3128.  It's not specific to v6ops, but being a RFC
> that covers TCP small fragment attacks, I thought I'd send the email. 
> I also think, the IETF WG that sponsored this RFC may be closed now. 
>
> (a) In section 2.1, the document uses "Fragment A" and also "B" for
> the first time and does not define them anywhere.
Presumably these refer to Fragment 1 and 2 as defined just above in the
same section (end of the previous page).

> (b) In section 2, in relation to Fragment 3, the document says
> "Fragment offset >=2".  In the IP header, the fragment offset is a
> multiple of 8 octets, and thus == 2 is incorrect.
The fragment offset field is indicated as a number of 8 octet units,
e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's
why the fragment field is only 13 bits long (vs. 16 bits to indicate the
length of an IP datagram).

> Please let me know if there is a current IETF WG covering such issues.
INTAREA would be the relevant WG, but AFAICT you're pointing out
something we'd probably classify as an Errata, which wouldn't need to be
addressed by a WG. You can submit those here:

https://www.rfc-editor.org/errata.php

Joe

---

From: Hemant Singh <[email-masked]>
Date: Thu, 12 Jan 2017 11:34:17 -0500

Joe,

Thanks much for your reply and also thanks to Brian.  Sure, even I surmised
Fragment A and B as 1 and 2 but I thought an RFC editor should have caught
this minor issue.  Having seen Brian's reply related to individual
submission, I see the edition issue.

 I forgot to mention another issue with RFC3128 in section 2.1.  Fragment 2
says target is telnet (port 23) but then uses FTP in the sentence.  FTP
should be "telnet".  Sure, I will file an Errata.

Thanks for the clarification on the number of 8 octet units.  Indeed, the
total length in the IP header is 2 bytes and thus the maximum packet is
65536 but 13 bits only support 8192 bytes.

I found that a cable modem is using 1480 in the fragment offset instead of
185.   We should check what do router vendors do.

On a different note, see that RFC3128 references RFC1858 which lists the
minimum size of an IPv4 datagram as 68 bytes.  Such small packets are used
to attack ACLs on firewalls for TCP packets using an IP header which is 60
bytes in length.  Wonder what the minimum size of an IPv6 packet is
specified in any IPv6 RFC?  I checked the IPv6 Node requirements RFC and
don't find any minimum.

Thanks,

Hemant

On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch <[email-masked]> wrote:

> that covers TCP small fragment attacks, I thought I'd send the email.  I
> also think, the IETF WG that sponsored this RFC may be closed now.
>
> The fragment offset field is indicated as a number of 8 octet units, e.g.,
> 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why the
> fragment field is only 13 bits long (vs. 16 bits to indicate the length of
> an IP datagram).
>
> INTAREA would be the relevant WG, but AFAICT you're pointing out something
> we'd probably classify as an Errata, which wouldn't need to be addressed by
> a WG. You can submit those here:
>
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jan 2017 10:48:39 -0800

Hi, Hemant,

On 1/12/2017 8:34 AM, Hemant Singh wrote:
> Joe,
>
> Thanks much for your reply and also thanks to Brian.  Sure, even I
> surmised Fragment A and B as 1 and 2 but I thought an RFC editor
> should have caught this minor issue.  Having seen Brian's reply
> related to individual submission, I see the edition issue. 
>
>  I forgot to mention another issue with RFC3128 in section 2.1. 
> Fragment 2 says target is telnet (port 23) but then uses FTP in the
> sentence.  FTP should be "telnet".  Sure, I will file an Errata.
Makes sense.
>
> Thanks for the clarification on the number of 8 octet units.  Indeed,
> the total length in the IP header is 2 bytes and thus the maximum
> packet is 65536 but 13 bits only support 8192 bytes. 
>
> I found that a cable modem is using 1480 in the fragment offset
> instead of 185.   We should check what do router vendors do.

The fragments would never reassemble - there would be a gap. You might
check to see whether fragmented traffic fails as a result.

> On a different note, see that RFC3128 references RFC1858 which lists
> the minimum size of an IPv4 datagram as 68 bytes.

The minimum IPv4 datagram would be 20 bytes - just the IP header with no
data.

68 is the smallest IPv4 datagram that an IPv4 network MUST be able to
transit without fragmentation. I.e., it's the minimum IPv4 MTU.

> Such small packets are used to attack ACLs on firewalls for TCP
> packets using an IP header which is 60 bytes in length.

IMO, the only "attack" that exists for a firewall that can't handle 20
byte IPv4 packets at advertised line rate is on its consumers, i.e.,
they're lying about supporting IPv4 at the advertised line rate.

IMO, any ACL system or firewall that claims to check for information
that might not be in the initial fragment MUST perform reassembly.
Although routers aren't supposed to do reassembly, a device that needs
to inspect upper layer protocols is no longer just a router, and is
acting on behalf of an endpoint and doing part of the endpoint's job. It
thus is justified in reassembling before acting.

> Wonder what the minimum size of an IPv6 packet is specified in any
> IPv6 RFC?  I checked the IPv6 Node requirements RFC and don't find any
> minimum.

The minimum packet size would be 40 bytes, i.e., just the IPv6 header
with no data. That could be used to trigger a device or set off an
alarm; there need not be any data for a packet to be useful.

The minimum IPv6 packet that an IPv6 network MUST be able to transit
without fragmentation is 1280, as specified in RFC2460.

Joe

>
> Thanks,
>
> Hemant
>
>
>
>
> On Wed, Jan 11, 2017 at 4:58 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi, Hemant,
>
>>     I was looking at RFC3128.  It's not specific to v6ops, but being
>>     a RFC that covers TCP small fragment attacks, I thought I'd send
>>     the email.  I also think, the IETF WG that sponsored this RFC may
>>     be closed now. 
>>
>>     (a) In section 2.1, the document uses "Fragment A" and also "B"
>>     for the first time and does not define them anywhere.
>     Presumably these refer to Fragment 1 and 2 as defined just above
>     in the same section (end of the previous page).
>
>>     "Fragment offset >=2".  In the IP header, the fragment offset is
>>     a multiple of 8 octets, and thus == 2 is incorrect.
>     The fragment offset field is indicated as a number of 8 octet
>     units, e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is
>     valid. That's why the fragment field is only 13 bits long (vs. 16
>     bits to indicate the length of an IP datagram).
>
>     something we'd probably classify as an Errata, which wouldn't need
>     to be addressed by a WG. You can submit those here:
>
>     <https://www.rfc-editor.org/errata.php>
>
>     Joe
>
>>
>>     Thanks,
>>
>>     Hemant
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Hemant Singh <[email-masked]>
Date: Mon, 16 Jan 2017 20:11:02 -0500

Hi Joe,

Sorry for the delayed reply - I was out sick.  Please see in line below.

On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch <[email-masked]> wrote:

> <hs> As I said in the past one attack on firrwalls or router ACLs is to
craft an IPv4 header which is 60 bytes.  Then add 8 bytes at a portion of
the TCP header.  Thus receivers receiving such a packet  cannot get to the
SYNC TCP message type of the TCP header.  The hacker is also setting the MF
bit in the Flags of the IP header when such a 68 byte packet has business
to be fragmented on a 1500 Ethernet MTU link.

> IMO, any ACL system or firewall that claims to check for information that
> might not be in the initial fragment MUST perform reassembly. Although
> routers aren't supposed to do reassembly, a device that needs to inspect
> upper layer protocols is no longer just a router, and is acting on behalf
> of an endpoint and doing part of the endpoint's job. It thus is justified
> in reassembling before acting.
>
> <hs> Agree.  Some routers which a access concentrators such as a CMTS
(Cable Modem Termination System) or a DSL BNG terminate fragmented traffic
between the router and the broadband modem.  Thus, these routers can
certainly be made robust to fragmented packet attacks.

> Wonder what the minimum size of an IPv6 packet is specified in any IPv6
> RFC?  I checked the IPv6 Node requirements RFC and don't find any minimum.
>
>
> The minimum packet size would be 40 bytes, i.e., just the IPv6 header with
> no data. That could be used to trigger a device or set off an alarm; there
> need not be any data for a packet to be useful.
>
> <hs> Sorry, I wasn't clear.  I meant the minimum sized IPv6 packet that
won't be dropped by the network.   I would think 40 bytes plus at least 8
bytes of a TCP header would be valid?

> <hs> Yes, I am aware of the 1280 number.   Since IPv4 nodes are dropping
an IPv4 packet which is smaller than 68 bytes. I was wondering, does IPv6
have some smallest size below which packets are dropped?  Is the IPv6 size
in 48 bytes good or should we be smart to include the complete size of the
TCP header and add 40 bytes of the IPv6 header?  This is the smallest
packet an IPv6 network will accept.  Below this size the network drops
packets.

Thanks,

Hemant
>> e.g., 0=0 octets, 1=8 octets, and 2=16 octets, so that is valid. That's why
>> the fragment field is only 13 bits long (vs. 16 bits to indicate the length
>> of an IP datagram).
>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 17 Jan 2017 08:56:28 -0800

Hi, Hemant,

On 1/16/2017 5:11 PM, Hemant Singh wrote:
> On Thu, Jan 12, 2017 at 1:48 PM, Joe Touch <[email-masked]
>     IMO, the only "attack" that exists for a firewall that can't
>     handle 20 byte IPv4 packets at advertised line rate is on its
>     consumers, i.e., they're lying about supporting IPv4 at the
>     advertised line rate.
>
> <hs> As I said in the past one attack on firrwalls or router ACLs is
> to craft an IPv4 header which is 60 bytes.  Then add 8 bytes at a
> portion of the TCP header. 
If you are talking about a single IP packet, that should not be
considered an attack.

If you're talking about fragments, then  you need to describe the case
more clearly. IMO, a firewall always needs to reassemble fragments.

> Thus receivers receiving such a packet  cannot get to the SYNC TCP
> message type of the TCP header.  The hacker is also setting the MF bit
> in the Flags of the IP header when such a 68 byte packet has business

Remember that an IPv4 packet with DF=0 can be fragmented anywhere in the
network and both IPv4 and IPv6 can be fragmented at the source.

IPv4 requires that a 68 byte packet can traverse the net without
fragmentation but there are no rules that prohibit smaller packets or
fragments. E.g., if you are sending a 100-byte packet and it needs to be
fragmented down to 68 bytes, it's entirely valid to make the first
fragment as 32 bytes. Anything longer than the IP header ought is
defined as valid.

>  
>
>     IMO, any ACL system or firewall that claims to check for
>     information that might not be in the initial fragment MUST perform
>     reassembly. Although routers aren't supposed to do reassembly, a
>     device that needs to inspect upper layer protocols is no longer
>     just a router, and is acting on behalf of an endpoint and doing
>     part of the endpoint's job. It thus is justified in reassembling
>     before acting.
>
> (Cable Modem Termination System) or a DSL BNG terminate fragmented
> traffic between the router and the broadband modem.  Thus, these
> routers can certainly be made robust to fragmented packet attacks.  
>
>>     Wonder what the minimum size of an IPv6 packet is specified in
>>     any IPv6 RFC?  I checked the IPv6 Node requirements RFC and don't
>>     find any minimum.
>
>     The minimum packet size would be 40 bytes, i.e., just the IPv6
>     header with no data. That could be used to trigger a device or set
>     off an alarm; there need not be any data for a packet to be useful.
>
> <hs> Sorry, I wasn't clear.  I meant the minimum sized IPv6 packet
> that won't be dropped by the network.   I would think 40 bytes plus at
> least 8 bytes of a TCP header would be valid?

The *minimum* for traffic is 40 bytes, the size of the smallest IPv6
header. As to fragments, the same rule applies as for IPv6.

Note - if a fragment - initial or otherwise - contains 0 bytes of
payload, that might be considered invalid because it prevents reassembly
from "making forward progress"; strictly, it's allowed, but it doesn't
make sense to send such a message. However, both protocols allow it AFAICT.

>  
>
>     The minimum IPv6 packet that an IPv6 network MUST be able to
>     transit without fragmentation is 1280, as specified in RFC2460.
>
> <hs> Yes, I am aware of the 1280 number.   Since IPv4 nodes are
> dropping an IPv4 packet which is smaller than 68 bytes.
That is broken behavior. The smallest valid IPv4 packet is 20 bytes, and
the smallest that would still make progress in reassembly is 28; for
IPv6 it would be 56 (40 for the IP header, 8 for the fragmentation
extension, and 8 for the smallest fragment. There's absolutely no rule
that all IPv6 fragments must be larger than 68 except for the last fragment.

Remember as well that the fragments don't always "break" in even pieces
because a packet might traverse links with different MTUs.

E.g., consider traversing links with MTUs of 95 then 90:

200 (i.e., 180d + 20h) -> 92 (72d+20h), 92 (72d+20h), 36 (16d+20h) -> 84
(64d+20h), 28 (8d+20h), 84, 28, 36

I.e., small fragments can be generated by a succession of hops that have
decreasing MTUs.

> I was wondering, does IPv6 have some smallest size below which packets
> are dropped?

An IPv6 link can't drop anything that has at least an IPv6 header. If
you want to say "it's safe to drop fragments that don't make sense",
then anything with a fragment offset extension should be at least 56
bytes (48 would be just IP + FH, and that's not enough to make
progress). But you have to look at the header to figure that out -
otherwise, 40 bytes without a fragment header is still valid.

> Is the IPv6 size in 48 bytes good or should we be smart to include the
> complete size of the TCP header and add 40 bytes of the IPv6 header? 
> This is the smallest packet an IPv6 network will accept.  Below this
> size the network drops packets.

IPv4 with MF = 1 should be at least 28 bytes (header plus at least one
fragment chunk)
IPv4 with MF = 0 must be at least 20 bytes (just the header)

IPv6 without frag header must be at least 40 bytes (just the header)
IPv6 with frag header and M = 1 should be at least 56 bytes

That's all I can see as *required*.

Joe

---

From: Hemant Singh <[email-masked]>
Date: Wed, 18 Jan 2017 19:14:27 -0500

Hi Joe,

On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch <[email-masked]> wrote:

If you're talking about fragments, then  you need to describe the case more
> clearly. IMO, a firewall always needs to reassemble fragments.
>
> <hs> Yes, it's an attack using fragments.  An ACL is configured on the
router to allows telnet and ssh only from certain source IP addresses.  An
attacker uses a source IP port that does not match any source in the ACL.
However, the router has a incorrect implementation for ACLs (or ACL rules
is mis-configured) which processes fragmented packets first before matching
source IP.   Once the first fragment is allowed, the subsequent fragments
are let through.  The source IP is checked later in the implementation and
thus the hacker gets into the network.  An authentication server serving
the router is the last defense against such a hack because a login and
password is required.

> fragmented down to 68 bytes, it's entirely valid to make the first fragment
> as 32 bytes. Anything longer than the IP header ought is defined as valid.
>
> <hs> When I get the time, I will check the Linux code and see if it has
anything hard coded for minimum IPv4 packet size.  Thanks for your other
replies - make total sense.  I am all set.

Best Regards,

Hemant

---

From: Joe Touch <[email-masked]>
Date: Wed, 18 Jan 2017 16:44:41 -0800

Hi, Hemant,

It's useful to note that the attack isn't based solely on minimum packet
size; it depends on how duplicate and overlapping fragment are handled
as well.

The best approach for a firewall is to reassemble such packets. If it
implements an ACL, it's acting like an end host in peeking into the
payload; there's no meaningful or safe way to do so when fragmentation
occurs other than reassembly, IMO.

Joe

On 1/18/2017 4:14 PM, Hemant Singh wrote:
> Hi Joe,
>
>
> On Tue, Jan 17, 2017 at 11:56 AM, Joe Touch <[email-masked]
>     If you're talking about fragments, then  you need to describe the
>     case more clearly. IMO, a firewall always needs to reassemble
>     fragments.
>
> router to allows telnet and ssh only from certain source IP
> addresses.  An attacker uses a source IP port that does not match any
> source in the ACL.  However, the router has a incorrect implementation
> for ACLs (or ACL rules is mis-configured) which processes fragmented
> packets first before matching source IP.   Once the first fragment is
> allowed, the subsequent fragments are let through.  The source IP is
> checked later in the implementation and thus the hacker gets into the
> network.  An authentication server serving the router is the last
> defense against such a hack because a login and password is required. 
>
>
>     Remember that an IPv4 packet with DF=0 can be fragmented anywhere
>     in the network and both IPv4 and IPv6 can be fragmented at the
>     source.
>
>     fragmentation but there are no rules that prohibit smaller packets
>     or fragments. E.g., if you are sending a 100-byte packet and it
>     needs to be fragmented down to 68 bytes, it's entirely valid to
>     make the first fragment as 32 bytes. Anything longer than the IP
>     header ought is defined as valid.
>
> <hs> When I get the time, I will check the Linux code and see if it
> has anything hard coded for minimum IPv4 packet size.  Thanks for your
> other replies - make total sense.  I am all set.
>
> Best Regards,
>
> Hemant 
>
>
>

---

From: Hemant Singh <[email-masked]>
Date: Thu, 19 Jan 2017 19:31:52 -0500

Hi Joe,

Sounds reasonable to me.  I agree with your firewall comments as well.

Thanks,

Hemant

On Wed, Jan 18, 2017 at 7:44 PM, Joe Touch <[email-masked]> wrote:

> size; it depends on how duplicate and overlapping fragment are handled as
> well.
>