netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Clock-independent TCP ISN generation
@ 2019-09-03  5:06 Cyrus Sh
  2019-09-03  7:41 ` Eric Dumazet
  2019-09-03  7:45 ` kbuild test robot
  0 siblings, 2 replies; 14+ messages in thread
From: Cyrus Sh @ 2019-09-03  5:06 UTC (permalink / raw)
  To: davem; +Cc: shiraz.saleem, jgg, arnd, arnd, netdev, sirus

This patch addresses the privacy issue of TCP ISN generation in Linux
kernel. Currently an adversary can deanonymize a user behind an anonymity
network by inducing a load pattern on the target machine and correlating
its clock skew with the pattern. Since the kernel adds a clock-based
counter to generated ISNs, the adversary can observe SYN packets with
similar IP and port numbers to find out the clock skew of the target
machine and this can help them identify the user.  To resolve this problem
I have changed the related function to generate the initial sequence
numbers randomly and independent from the cpu clock. This feature is
controlled by a new sysctl option called "tcp_random_isn" which I've added
to the kernel. Once enabled the initial sequence numbers are guaranteed to
be generated independently from each other and from the hardware clock of
the machine. If the option is off, ISNs are generated as before.  To get
more information about this patch and its effectiveness you can refer to my
post here:
https://bitguard.wordpress.com/?p=982
and to see a discussion about the issue you can read this:
https://trac.torproject.org/projects/tor/ticket/16659

Signed-off-by: Sirus Shahini <sirus.shahini@gmail.com>
---
 include/net/tcp.h           |  1 +
 include/uapi/linux/sysctl.h |  1 +
 kernel/sysctl_binary.c      |  1 +
 net/core/secure_seq.c       | 24 +++++++++++++++++++++++-
 net/ipv4/sysctl_net_ipv4.c  |  7 +++++++
 net/ipv4/tcp_input.c        |  1 +
 6 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/include/net/tcp.h b/include/net/tcp.h
index 81e8ade..4ad1bbf 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -241,6 +241,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
 
 /* sysctl variables for tcp */
 extern int sysctl_tcp_max_orphans;
+extern int sysctl_tcp_random_isn;
 extern long sysctl_tcp_mem[3];
 
 #define TCP_RACK_LOSS_DETECTION  0x1 /* Use RACK to detect losses */
diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
index 87aa2a6..ba8927e 100644
--- a/include/uapi/linux/sysctl.h
+++ b/include/uapi/linux/sysctl.h
@@ -426,6 +426,7 @@ enum
 	NET_TCP_ALLOWED_CONG_CONTROL=123,
 	NET_TCP_MAX_SSTHRESH=124,
 	NET_TCP_FRTO_RESPONSE=125,
+	NET_IPV4_TCP_RANDOM_ISN=126,
 };
 
 enum {
diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
index 73c1320..0faf7d4 100644
--- a/kernel/sysctl_binary.c
+++ b/kernel/sysctl_binary.c
@@ -332,6 +332,7 @@ static const struct bin_table bin_net_ipv4_netfilter_table[] = {
 };
 
 static const struct bin_table bin_net_ipv4_table[] = {
+	{CTL_INT,   NET_IPV4_TCP_RANDOM_ISN     "tcp_random_isn"}
 	{CTL_INT,	NET_IPV4_FORWARD,			"ip_forward" },
 
 	{ CTL_DIR,	NET_IPV4_CONF,		"conf",		bin_net_ipv4_conf_table },
diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
index 7b6b1d2..b644bbe 100644
--- a/net/core/secure_seq.c
+++ b/net/core/secure_seq.c
@@ -22,6 +22,7 @@
 
 static siphash_key_t net_secret __read_mostly;
 static siphash_key_t ts_secret __read_mostly;
+static siphash_key_t last_secret = {{0,0}} ;
 
 static __always_inline void net_secret_init(void)
 {
@@ -134,8 +135,29 @@ u32 secure_tcp_seq(__be32 saddr, __be32 daddr,
 		   __be16 sport, __be16 dport)
 {
 	u32 hash;
-
+	u32 temp;
+	
 	net_secret_init();
+	
+	if (sysctl_tcp_random_isn){
+		if (!last_secret.key[0] && !last_secret.key[1]){
+			memcpy(&last_secret,&net_secret,sizeof(last_secret));	
+					
+		}else{
+			temp = *((u32*)&(net_secret.key[0]));
+			temp >>= 8;
+			last_secret.key[0]+=temp;
+			temp = *((u32*)&(net_secret.key[1]));
+			temp >>= 8;
+			last_secret.key[1]+=temp;
+		}
+		hash = siphash_3u32((__force u32)saddr, (__force u32)daddr,
+			        (__force u32)sport << 16 | (__force u32)dport,
+			        &last_secret);
+		return hash;
+	}
+	
+	
 	hash = siphash_3u32((__force u32)saddr, (__force u32)daddr,
 			    (__force u32)sport << 16 | (__force u32)dport,
 			    &net_secret);
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 0b980e8..74b2b6a 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -479,6 +479,13 @@ static int proc_fib_multipath_hash_policy(struct ctl_table *table, int write,
 
 static struct ctl_table ipv4_table[] = {
 	{
+    	.procname	= "tcp_random_isn",
+		.data		= &sysctl_tcp_random_isn,
+		.maxlen		= sizeof(int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec  
+	},
+	{
 		.procname	= "tcp_max_orphans",
 		.data		= &sysctl_tcp_max_orphans,
 		.maxlen		= sizeof(int),
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index c21e8a2..c6b4ebf 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -80,6 +80,7 @@
 #include <linux/jump_label_ratelimit.h>
 #include <net/busy_poll.h>
 
+int sysctl_tcp_random_isn __read_mostly = 0;
 int sysctl_tcp_max_orphans __read_mostly = NR_FILE;
 
 #define FLAG_DATA		0x01 /* Incoming frame contained data.		*/
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03  5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh
@ 2019-09-03  7:41 ` Eric Dumazet
  2019-09-03 15:39   ` Cyrus Sh
  2019-09-03  7:45 ` kbuild test robot
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2019-09-03  7:41 UTC (permalink / raw)
  To: Cyrus Sh, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 7:06 AM, Cyrus Sh wrote:
> This patch addresses the privacy issue of TCP ISN generation in Linux
> kernel. Currently an adversary can deanonymize a user behind an anonymity
> network by inducing a load pattern on the target machine and correlating
> its clock skew with the pattern. Since the kernel adds a clock-based
> counter to generated ISNs, the adversary can observe SYN packets with
> similar IP and port numbers to find out the clock skew of the target
> machine and this can help them identify the user.  To resolve this problem
> I have changed the related function to generate the initial sequence
> numbers randomly and independent from the cpu clock. This feature is
> controlled by a new sysctl option called "tcp_random_isn" which I've added
> to the kernel. Once enabled the initial sequence numbers are guaranteed to
> be generated independently from each other and from the hardware clock of
> the machine. If the option is off, ISNs are generated as before.  To get
> more information about this patch and its effectiveness you can refer to my
> post here:
> https://bitguard.wordpress.com/?p=982


<quote>
Firstly it’s unlikely that this happens at all,
</quote>

Sorry this happens all the time.
Some people use very disturbing setups really, and they are not trying to be malicious.

Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ?

> and to see a discussion about the issue you can read this:
> https://trac.torproject.org/projects/tor/ticket/16659

Four years old discussion. Does not seem urgent matter :/

> 
> Signed-off-by: Sirus Shahini <sirus.shahini@gmail.com>
> ---
>  include/net/tcp.h           |  1 +
>  include/uapi/linux/sysctl.h |  1 +
>  kernel/sysctl_binary.c      |  1 +
>  net/core/secure_seq.c       | 24 +++++++++++++++++++++++-
>  net/ipv4/sysctl_net_ipv4.c  |  7 +++++++
>  net/ipv4/tcp_input.c        |  1 +
>  6 files changed, 34 insertions(+), 1 deletion(-)
> 
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 81e8ade..4ad1bbf 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -241,6 +241,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
>  
>  /* sysctl variables for tcp */
>  extern int sysctl_tcp_max_orphans;
> +extern int sysctl_tcp_random_isn;

All TCP sysctls are per netns these days. (Look in include/net/netns/ipv4.h )

>  extern long sysctl_tcp_mem[3];
>  
>  #define TCP_RACK_LOSS_DETECTION  0x1 /* Use RACK to detect losses */
> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
> index 87aa2a6..ba8927e 100644
> --- a/include/uapi/linux/sysctl.h
> +++ b/include/uapi/linux/sysctl.h
> @@ -426,6 +426,7 @@ enum
>  	NET_TCP_ALLOWED_CONG_CONTROL=123,
>  	NET_TCP_MAX_SSTHRESH=124,
>  	NET_TCP_FRTO_RESPONSE=125,
> +	NET_IPV4_TCP_RANDOM_ISN=126,

Nope, we do not add new sysctls there anymore.

Everybody should now have /proc files to tune the values.

>  };
>  
>  enum {
> diff --git a/kernel/sysctl_binary.c b/kernel/sysctl_binary.c
> index 73c1320..0faf7d4 100644
> --- a/kernel/sysctl_binary.c
> +++ b/kernel/sysctl_binary.c
> @@ -332,6 +332,7 @@ static const struct bin_table bin_net_ipv4_netfilter_table[] = {
>  };
>  
>  static const struct bin_table bin_net_ipv4_table[] = {
> +	{CTL_INT,   NET_IPV4_TCP_RANDOM_ISN     "tcp_random_isn"}

Same remark. We no longer add stuff there.

>  	{CTL_INT,	NET_IPV4_FORWARD,			"ip_forward" },
>  
>  	{ CTL_DIR,	NET_IPV4_CONF,		"conf",		bin_net_ipv4_conf_table },
> diff --git a/net/core/secure_seq.c b/net/core/secure_seq.c
> index 7b6b1d2..b644bbe 100644
> --- a/net/core/secure_seq.c
> +++ b/net/core/secure_seq.c
> @@ -22,6 +22,7 @@
>  
>  static siphash_key_t net_secret __read_mostly;
>  static siphash_key_t ts_secret __read_mostly;
> +static siphash_key_t last_secret = {{0,0}} ;
>  
>  static __always_inline void net_secret_init(void)
>  {
> @@ -134,8 +135,29 @@ u32 secure_tcp_seq(__be32 saddr, __be32 daddr,
>  		   __be16 sport, __be16 dport)
>  {
>  	u32 hash;
> -
> +	u32 temp;
> +	
>  	net_secret_init();
> +	
> +	if (sysctl_tcp_random_isn){
> +		if (!last_secret.key[0] && !last_secret.key[1]){
> +			memcpy(&last_secret,&net_secret,sizeof(last_secret));	
> +					
> +		}else{

Check your patch using scripts/checkpatch.pl

All these missing spaces should be spotted.

> +			temp = *((u32*)&(net_secret.key[0]));
> +			temp >>= 8;
> +			last_secret.key[0]+=temp;
> +			temp = *((u32*)&(net_secret.key[1]));
> +			temp >>= 8;
> +			last_secret.key[1]+=temp;

Why not simply use an official random generator, instead of these convoluted
and not SMP safe attempts ?

Check drivers/char/random.c for officially maintained generators.

> +		}
> +		hash = siphash_3u32((__force u32)saddr, (__force u32)daddr,
> +			        (__force u32)sport << 16 | (__force u32)dport,
> +			        &last_secret);
> +		return hash;
> +	}
> +	
> +	
>  	hash = siphash_3u32((__force u32)saddr, (__force u32)daddr,
>  			    (__force u32)sport << 16 | (__force u32)dport,
>  			    &net_secret);

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03  5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh
  2019-09-03  7:41 ` Eric Dumazet
@ 2019-09-03  7:45 ` kbuild test robot
  1 sibling, 0 replies; 14+ messages in thread
From: kbuild test robot @ 2019-09-03  7:45 UTC (permalink / raw)
  To: Cyrus Sh; +Cc: kbuild-all, davem, shiraz.saleem, jgg, arnd, netdev, sirus

[-- Attachment #1: Type: text/plain, Size: 7349 bytes --]

Hi Cyrus,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc7 next-20190902]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Cyrus-Sh/Clock-independent-TCP-ISN-generation/20190903-131719
config: x86_64-randconfig-e003-201935 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> kernel/sysctl_binary.c:335:42: error: expected '}' before string constant
     {CTL_INT,   NET_IPV4_TCP_RANDOM_ISN     "tcp_random_isn"}
                                             ^~~~~~~~~~~~~~~~
>> kernel/sysctl_binary.c:336:2: error: expected '}' before '{' token
     {CTL_INT, NET_IPV4_FORWARD,   "ip_forward" },
     ^

vim +335 kernel/sysctl_binary.c

   333	
   334	static const struct bin_table bin_net_ipv4_table[] = {
 > 335		{CTL_INT,   NET_IPV4_TCP_RANDOM_ISN     "tcp_random_isn"}
 > 336		{CTL_INT,	NET_IPV4_FORWARD,			"ip_forward" },
   337	
   338		{ CTL_DIR,	NET_IPV4_CONF,		"conf",		bin_net_ipv4_conf_table },
   339		{ CTL_DIR,	NET_IPV4_NEIGH,		"neigh",	bin_net_neigh_table },
   340		{ CTL_DIR,	NET_IPV4_ROUTE,		"route",	bin_net_ipv4_route_table },
   341		/* NET_IPV4_FIB_HASH unused */
   342		{ CTL_DIR,	NET_IPV4_NETFILTER,	"netfilter",	bin_net_ipv4_netfilter_table },
   343	
   344		{ CTL_INT,	NET_IPV4_TCP_TIMESTAMPS,		"tcp_timestamps" },
   345		{ CTL_INT,	NET_IPV4_TCP_WINDOW_SCALING,		"tcp_window_scaling" },
   346		{ CTL_INT,	NET_IPV4_TCP_SACK,			"tcp_sack" },
   347		{ CTL_INT,	NET_IPV4_TCP_RETRANS_COLLAPSE,		"tcp_retrans_collapse" },
   348		{ CTL_INT,	NET_IPV4_DEFAULT_TTL,			"ip_default_ttl" },
   349		/* NET_IPV4_AUTOCONFIG unused */
   350		{ CTL_INT,	NET_IPV4_NO_PMTU_DISC,			"ip_no_pmtu_disc" },
   351		{ CTL_INT,	NET_IPV4_NONLOCAL_BIND,			"ip_nonlocal_bind" },
   352		{ CTL_INT,	NET_IPV4_TCP_SYN_RETRIES,		"tcp_syn_retries" },
   353		{ CTL_INT,	NET_TCP_SYNACK_RETRIES,			"tcp_synack_retries" },
   354		{ CTL_INT,	NET_TCP_MAX_ORPHANS,			"tcp_max_orphans" },
   355		{ CTL_INT,	NET_TCP_MAX_TW_BUCKETS,			"tcp_max_tw_buckets" },
   356		{ CTL_INT,	NET_IPV4_DYNADDR,			"ip_dynaddr" },
   357		{ CTL_INT,	NET_IPV4_TCP_KEEPALIVE_TIME,		"tcp_keepalive_time" },
   358		{ CTL_INT,	NET_IPV4_TCP_KEEPALIVE_PROBES,		"tcp_keepalive_probes" },
   359		{ CTL_INT,	NET_IPV4_TCP_KEEPALIVE_INTVL,		"tcp_keepalive_intvl" },
   360		{ CTL_INT,	NET_IPV4_TCP_RETRIES1,			"tcp_retries1" },
   361		{ CTL_INT,	NET_IPV4_TCP_RETRIES2,			"tcp_retries2" },
   362		{ CTL_INT,	NET_IPV4_TCP_FIN_TIMEOUT,		"tcp_fin_timeout" },
   363		{ CTL_INT,	NET_TCP_SYNCOOKIES,			"tcp_syncookies" },
   364		{ CTL_INT,	NET_TCP_TW_RECYCLE,			"tcp_tw_recycle" },
   365		{ CTL_INT,	NET_TCP_ABORT_ON_OVERFLOW,		"tcp_abort_on_overflow" },
   366		{ CTL_INT,	NET_TCP_STDURG,				"tcp_stdurg" },
   367		{ CTL_INT,	NET_TCP_RFC1337,			"tcp_rfc1337" },
   368		{ CTL_INT,	NET_TCP_MAX_SYN_BACKLOG,		"tcp_max_syn_backlog" },
   369		{ CTL_INT,	NET_IPV4_LOCAL_PORT_RANGE,		"ip_local_port_range" },
   370		{ CTL_INT,	NET_IPV4_IGMP_MAX_MEMBERSHIPS,		"igmp_max_memberships" },
   371		{ CTL_INT,	NET_IPV4_IGMP_MAX_MSF,			"igmp_max_msf" },
   372		{ CTL_INT,	NET_IPV4_INET_PEER_THRESHOLD,		"inet_peer_threshold" },
   373		{ CTL_INT,	NET_IPV4_INET_PEER_MINTTL,		"inet_peer_minttl" },
   374		{ CTL_INT,	NET_IPV4_INET_PEER_MAXTTL,		"inet_peer_maxttl" },
   375		{ CTL_INT,	NET_IPV4_INET_PEER_GC_MINTIME,		"inet_peer_gc_mintime" },
   376		{ CTL_INT,	NET_IPV4_INET_PEER_GC_MAXTIME,		"inet_peer_gc_maxtime" },
   377		{ CTL_INT,	NET_TCP_ORPHAN_RETRIES,			"tcp_orphan_retries" },
   378		{ CTL_INT,	NET_TCP_FACK,				"tcp_fack" },
   379		{ CTL_INT,	NET_TCP_REORDERING,			"tcp_reordering" },
   380		{ CTL_INT,	NET_TCP_ECN,				"tcp_ecn" },
   381		{ CTL_INT,	NET_TCP_DSACK,				"tcp_dsack" },
   382		{ CTL_INT,	NET_TCP_MEM,				"tcp_mem" },
   383		{ CTL_INT,	NET_TCP_WMEM,				"tcp_wmem" },
   384		{ CTL_INT,	NET_TCP_RMEM,				"tcp_rmem" },
   385		{ CTL_INT,	NET_TCP_APP_WIN,			"tcp_app_win" },
   386		{ CTL_INT,	NET_TCP_ADV_WIN_SCALE,			"tcp_adv_win_scale" },
   387		{ CTL_INT,	NET_TCP_TW_REUSE,			"tcp_tw_reuse" },
   388		{ CTL_INT,	NET_TCP_FRTO,				"tcp_frto" },
   389		{ CTL_INT,	NET_TCP_FRTO_RESPONSE,			"tcp_frto_response" },
   390		{ CTL_INT,	NET_TCP_LOW_LATENCY,			"tcp_low_latency" },
   391		{ CTL_INT,	NET_TCP_NO_METRICS_SAVE,		"tcp_no_metrics_save" },
   392		{ CTL_INT,	NET_TCP_MODERATE_RCVBUF,		"tcp_moderate_rcvbuf" },
   393		{ CTL_INT,	NET_TCP_TSO_WIN_DIVISOR,		"tcp_tso_win_divisor" },
   394		{ CTL_STR,	NET_TCP_CONG_CONTROL,			"tcp_congestion_control" },
   395		{ CTL_INT,	NET_TCP_MTU_PROBING,			"tcp_mtu_probing" },
   396		{ CTL_INT,	NET_TCP_BASE_MSS,			"tcp_base_mss" },
   397		{ CTL_INT,	NET_IPV4_TCP_WORKAROUND_SIGNED_WINDOWS,	"tcp_workaround_signed_windows" },
   398		{ CTL_INT,	NET_TCP_SLOW_START_AFTER_IDLE,		"tcp_slow_start_after_idle" },
   399		{ CTL_INT,	NET_CIPSOV4_CACHE_ENABLE,		"cipso_cache_enable" },
   400		{ CTL_INT,	NET_CIPSOV4_CACHE_BUCKET_SIZE,		"cipso_cache_bucket_size" },
   401		{ CTL_INT,	NET_CIPSOV4_RBM_OPTFMT,			"cipso_rbm_optfmt" },
   402		{ CTL_INT,	NET_CIPSOV4_RBM_STRICTVALID,		"cipso_rbm_strictvalid" },
   403		/* NET_TCP_AVAIL_CONG_CONTROL "tcp_available_congestion_control" no longer used */
   404		{ CTL_STR,	NET_TCP_ALLOWED_CONG_CONTROL,		"tcp_allowed_congestion_control" },
   405		{ CTL_INT,	NET_TCP_MAX_SSTHRESH,			"tcp_max_ssthresh" },
   406	
   407		{ CTL_INT,	NET_IPV4_ICMP_ECHO_IGNORE_ALL,		"icmp_echo_ignore_all" },
   408		{ CTL_INT,	NET_IPV4_ICMP_ECHO_IGNORE_BROADCASTS,	"icmp_echo_ignore_broadcasts" },
   409		{ CTL_INT,	NET_IPV4_ICMP_IGNORE_BOGUS_ERROR_RESPONSES,	"icmp_ignore_bogus_error_responses" },
   410		{ CTL_INT,	NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR,	"icmp_errors_use_inbound_ifaddr" },
   411		{ CTL_INT,	NET_IPV4_ICMP_RATELIMIT,		"icmp_ratelimit" },
   412		{ CTL_INT,	NET_IPV4_ICMP_RATEMASK,			"icmp_ratemask" },
   413	
   414		{ CTL_INT,	NET_IPV4_IPFRAG_HIGH_THRESH,		"ipfrag_high_thresh" },
   415		{ CTL_INT,	NET_IPV4_IPFRAG_LOW_THRESH,		"ipfrag_low_thresh" },
   416		{ CTL_INT,	NET_IPV4_IPFRAG_TIME,			"ipfrag_time" },
   417	
   418		{ CTL_INT,	NET_IPV4_IPFRAG_SECRET_INTERVAL,	"ipfrag_secret_interval" },
   419		/* NET_IPV4_IPFRAG_MAX_DIST "ipfrag_max_dist" no longer used */
   420	
   421		{ CTL_INT,	2088 /* NET_IPQ_QMAX */,		"ip_queue_maxlen" },
   422	
   423		/* NET_TCP_DEFAULT_WIN_SCALE unused */
   424		/* NET_TCP_BIC_BETA unused */
   425		/* NET_IPV4_TCP_MAX_KA_PROBES unused */
   426		/* NET_IPV4_IP_MASQ_DEBUG unused */
   427		/* NET_TCP_SYN_TAILDROP unused */
   428		/* NET_IPV4_ICMP_SOURCEQUENCH_RATE unused */
   429		/* NET_IPV4_ICMP_DESTUNREACH_RATE unused */
   430		/* NET_IPV4_ICMP_TIMEEXCEED_RATE unused */
   431		/* NET_IPV4_ICMP_PARAMPROB_RATE unused */
   432		/* NET_IPV4_ICMP_ECHOREPLY_RATE unused */
   433		/* NET_IPV4_ALWAYS_DEFRAG unused */
   434		{}
   435	};
   436	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24350 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03  7:41 ` Eric Dumazet
@ 2019-09-03 15:39   ` Cyrus Sh
  2019-09-03 15:59     ` Eric Dumazet
  0 siblings, 1 reply; 14+ messages in thread
From: Cyrus Sh @ 2019-09-03 15:39 UTC (permalink / raw)
  To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 1:41 AM, Eric Dumazet wrote:
> Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ?

Can you provide any reference to somewhere that explains these firewall rules
and how to exactly use them to prevent this specific type of attack?

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 15:39   ` Cyrus Sh
@ 2019-09-03 15:59     ` Eric Dumazet
  2019-09-03 16:06       ` Cyrus Sh
  2019-09-03 16:12       ` Cyrus Sh
  0 siblings, 2 replies; 14+ messages in thread
From: Eric Dumazet @ 2019-09-03 15:59 UTC (permalink / raw)
  To: Cyrus Sh, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 5:39 PM, Cyrus Sh wrote:
> 
> 
> On 9/3/19 1:41 AM, Eric Dumazet wrote:
>> Clock skew seems quite secondary. Some firewall rules should prevent this kind of attacks ?
> 
> Can you provide any reference to somewhere that explains these firewall rules
> and how to exactly use them to prevent this specific type of attack?
> 

You could add a random delay to all SYN packets, if you believe your host has clock skews.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 15:59     ` Eric Dumazet
@ 2019-09-03 16:06       ` Cyrus Sh
  2019-09-03 16:17         ` Eric Dumazet
  2019-09-03 22:43         ` David Miller
  2019-09-03 16:12       ` Cyrus Sh
  1 sibling, 2 replies; 14+ messages in thread
From: Cyrus Sh @ 2019-09-03 16:06 UTC (permalink / raw)
  To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 9:59 AM, Eric Dumazet wrote:
> 
> You could add a random delay to all SYN packets, if you believe your host has clock skews.

In theory yes, but again do you know any practical example with tested
applications and the list of the rules? I'm interested to see an actual example
that somebody has carried out and observed its results.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 15:59     ` Eric Dumazet
  2019-09-03 16:06       ` Cyrus Sh
@ 2019-09-03 16:12       ` Cyrus Sh
  2019-09-03 16:16         ` Eric Dumazet
  1 sibling, 1 reply; 14+ messages in thread
From: Cyrus Sh @ 2019-09-03 16:12 UTC (permalink / raw)
  To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 9:59 AM, Eric Dumazet wrote:

> You could add a random delay to all SYN packets, if you believe your host has clock skews.

And by the way adding delays has its own performance penalties.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:12       ` Cyrus Sh
@ 2019-09-03 16:16         ` Eric Dumazet
  0 siblings, 0 replies; 14+ messages in thread
From: Eric Dumazet @ 2019-09-03 16:16 UTC (permalink / raw)
  To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 6:12 PM, Cyrus Sh wrote:
> 
> 
> On 9/3/19 9:59 AM, Eric Dumazet wrote:
> 
>> You could add a random delay to all SYN packets, if you believe your host has clock skews.
> 
> And by the way adding delays has its own performance penalties.
> 


You understand your patch has been rejected, right ?

You will have to convince people at IETF and get a proper RFC before
I even look at the idea.

BTW, sending a patch only dealing with IPv4 is also not a good thing.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:06       ` Cyrus Sh
@ 2019-09-03 16:17         ` Eric Dumazet
  2019-09-03 16:27           ` Cyrus Sh
  2019-09-03 22:43         ` David Miller
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2019-09-03 16:17 UTC (permalink / raw)
  To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 6:06 PM, Cyrus Sh wrote:
> 
> 
> On 9/3/19 9:59 AM, Eric Dumazet wrote:
>>
>> You could add a random delay to all SYN packets, if you believe your host has clock skews.
> 
> In theory yes, but again do you know any practical example with tested
> applications and the list of the rules? I'm interested to see an actual example
> that somebody has carried out and observed its results.
> 

Do you have a real program showing us how this clock skew can be used practically ?


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:17         ` Eric Dumazet
@ 2019-09-03 16:27           ` Cyrus Sh
  2019-09-03 16:42             ` Eric Dumazet
  2019-09-03 22:45             ` David Miller
  0 siblings, 2 replies; 14+ messages in thread
From: Cyrus Sh @ 2019-09-03 16:27 UTC (permalink / raw)
  To: Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 10:17 AM, Eric Dumazet wrote:

> Do you have a real program showing us how this clock skew can be used practically ?
This is a well studied issue. You can take a look at this presentation as an
example:
http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf

> You will have to convince people at IETF and get a proper RFC 
No I won't. A lot of these standards have been written at a time that anonymity
networks were not of big importance. Now that they are, we try to lessen the
negative impacts of some RFC deficiencies by improving the implementation. It's
up to you whether to want to keep using a problematic code that may endanger
users or want to do something about it since we won't insist on having a patch
accepted.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:27           ` Cyrus Sh
@ 2019-09-03 16:42             ` Eric Dumazet
  2019-09-03 22:45             ` David Miller
  1 sibling, 0 replies; 14+ messages in thread
From: Eric Dumazet @ 2019-09-03 16:42 UTC (permalink / raw)
  To: Cyrus Sh, Eric Dumazet, davem; +Cc: shiraz.saleem, jgg, arnd, netdev, sirus



On 9/3/19 6:27 PM, Cyrus Sh wrote:
> 
> 
> On 9/3/19 10:17 AM, Eric Dumazet wrote:
> 
>> Do you have a real program showing us how this clock skew can be used practically ?
> This is a well studied issue. You can take a look at this presentation as an
> example:
> http://caia.swin.edu.au/talks/CAIA-TALK-080728A.pdf

2008 ? Really ?

I do not want an example, I want a proof that current systems are
exhibiting all the needed behavior.

I do not have time to spend hours reading old stuff based
on old architectures.

> 
>> You will have to convince people at IETF and get a proper RFC 
> No I won't. A lot of these standards have been written at a time that anonymity
> networks were not of big importance. Now that they are, we try to lessen the
> negative impacts of some RFC deficiencies by improving the implementation. It's
> up to you whether to want to keep using a problematic code that may endanger
> users or want to do something about it since we won't insist on having a patch
> accepted.
> 

Then this is the end. linux wont change something as fundamental without
proper feedback from the community.


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:06       ` Cyrus Sh
  2019-09-03 16:17         ` Eric Dumazet
@ 2019-09-03 22:43         ` David Miller
  1 sibling, 0 replies; 14+ messages in thread
From: David Miller @ 2019-09-03 22:43 UTC (permalink / raw)
  To: sirus.shahini; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus

From: Cyrus Sh <sirus.shahini@gmail.com>
Date: Tue, 3 Sep 2019 10:06:03 -0600

> On 9/3/19 9:59 AM, Eric Dumazet wrote:
>> 
>> You could add a random delay to all SYN packets, if you believe your host has clock skews.
> 
> In theory yes, but again do you know any practical example with tested
> applications and the list of the rules? I'm interested to see an actual example
> that somebody has carried out and observed its results.

That's ironic that you're asking for specific and "practical" examples
when you submitted a kernel patch that doesn't even compile.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 16:27           ` Cyrus Sh
  2019-09-03 16:42             ` Eric Dumazet
@ 2019-09-03 22:45             ` David Miller
  2019-09-04  0:45               ` Cyrus Sh
  1 sibling, 1 reply; 14+ messages in thread
From: David Miller @ 2019-09-03 22:45 UTC (permalink / raw)
  To: sirus.shahini; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus

From: Cyrus Sh <sirus.shahini@gmail.com>
Date: Tue, 3 Sep 2019 10:27:41 -0600

> It's up to you whether to want to keep using a problematic code that
> may endanger users or want to do something about it since we won't
> insist on having a patch accepted.

At least our problematic code, unlike your patch, compiles.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] Clock-independent TCP ISN generation
  2019-09-03 22:45             ` David Miller
@ 2019-09-04  0:45               ` Cyrus Sh
  0 siblings, 0 replies; 14+ messages in thread
From: Cyrus Sh @ 2019-09-04  0:45 UTC (permalink / raw)
  To: David Miller; +Cc: eric.dumazet, shiraz.saleem, jgg, arnd, netdev, sirus

On 9/3/19 4:45 PM, David Miller wrote:

> At least our problematic code, unlike your patch, compiles.

I obviously compiled and tested the code before sending along and this should be
easy to understand. Even I published the results in the link that I mentioned in
the initial message. Now I'm not sure what you're doing that you're unable to
compile the code. What compilation error message do you get? This patch has
been written for kernel 5.3-rc7. 
Further the reason that I asked for a specific practical example was that I
wanted to actually test different techniques and see their effectiveness. (Again
should be easy to understand, I don't know why it's not for you and why it made
you upset)


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2019-09-04  0:45 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-03  5:06 [PATCH] Clock-independent TCP ISN generation Cyrus Sh
2019-09-03  7:41 ` Eric Dumazet
2019-09-03 15:39   ` Cyrus Sh
2019-09-03 15:59     ` Eric Dumazet
2019-09-03 16:06       ` Cyrus Sh
2019-09-03 16:17         ` Eric Dumazet
2019-09-03 16:27           ` Cyrus Sh
2019-09-03 16:42             ` Eric Dumazet
2019-09-03 22:45             ` David Miller
2019-09-04  0:45               ` Cyrus Sh
2019-09-03 22:43         ` David Miller
2019-09-03 16:12       ` Cyrus Sh
2019-09-03 16:16         ` Eric Dumazet
2019-09-03  7:45 ` kbuild test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).