Fragments for a single connection (a combination of proto,src,dst,af)

may easily reuse the fragment id as it is only 16 bit for IPv4.  To
avoid that pf reassembles them into the wrong packet, throw away
stale fragments.  With the default timeout this happens after 12,000
newer fragements have been seen.
from markus@; OK sashan@

1 files changed, 9 insertions, 1 deletions

diff --git a/sys/net/pfvar.h b/sys/net/pfvar.h
index dd75c72044d..d19f6f769ac 100644
--- a/sys/net/pfvar.h
+++ b/sys/net/pfvar.h
@@ -1,4 +1,4 @@
-/*	$OpenBSD: pfvar.h,v 1.457 2017/05/30 19:40:54 henning Exp $ */
+/*	$OpenBSD: pfvar.h,v 1.458 2017/06/26 18:33:24 bluhm Exp $ */
 
 /*
  * Copyright (c) 2001 Daniel Hartmeier
@@ -109,6 +109,14 @@ enum	{ PFTM_TCP_FIRST_PACKET, PFTM_TCP_OPENING, PFTM_TCP_ESTABLISHED,
 #define PFTM_SRC_NODE_VAL		0	/* Source tracking */
 #define PFTM_TS_DIFF_VAL		30	/* Allowed TS diff */
 
+/*
+ * For each connection (combination of proto,src,dst,af) the number
+ * of fragments is limited.  Over the PFTM_FRAG interval the average
+ * rate must be less than PF_FRAG_STALE fragments per second.
+ * Otherwise older fragments are considered stale and are dropped.
+ */
+#define PF_FRAG_STALE			200
+
 enum	{ PF_NOPFROUTE, PF_ROUTETO, PF_DUPTO, PF_REPLYTO };
 enum	{ PF_LIMIT_STATES, PF_LIMIT_SRC_NODES, PF_LIMIT_FRAGS,
 	  PF_LIMIT_TABLES, PF_LIMIT_TABLE_ENTRIES, PF_LIMIT_MAX };