Subject: [Int-area] Review> SOCKS 6 Draft

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 5 Jul 2017 21:21:18 +0200

Hello,

I quickly reviewed Socks6 document as I was waiting for any initiation
to improve socks 5. I found it a good document, however, unfortunately
the security is still weak and this document also did not address that
but made it worse. I am looking for new methods of authentication as
what is available in socks5 is just plain text and cannot protect
against active attacker and also passive attacker if and if there is a
fixed value used as a username and password.

Further, DDoS attack mentioned also in the draft cannot be addressed as
easily as explained, IMHO. since the proxy server supposed to receive
higher size messages and the attacker client can only overwhelm the
socks server easier by less messages from different IP address that
sounds to be a new client.  Further, for constrained devices, there is a
limitation in size of the message, therefore, dissimilar to socks5 that
could be used also for such devices, socks 6 cannot be used otherwise
there will be limit in the information supposed to be sent in one message.

https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html

But in general, that is a good effort, keep going on!

Best,

Hosnieh

---

From: <[email-masked]>
Date: Thu, 6 Jul 2017 13:08:05 +0000

Hi Hosnieh,

Just out of curiosity, is there any particular reason you want to use SOCKS? Did you consider other protocols such as:

·         https://tools.ietf.org/html/rfc6887

·         https://tools.ietf.org/html/rfc7652

Thank you.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : [email-masked]
Objet : [Int-area] Review> SOCKS 6 Draft

Hello,

I quickly reviewed Socks6 document as I was waiting for any initiation to improve socks 5. I found it a good document, however, unfortunately the security is still weak and this document also did not address that but made it worse. I am looking for new methods of authentication as what is available in socks5 is just plain text and cannot protect against active attacker and also passive attacker if and if there is a fixed value used as a username and password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily as explained, IMHO. since the proxy server supposed to receive higher size messages and the attacker client can only overwhelm the socks server easier by less messages from different IP address that sounds to be a new client.  Further, for constrained devices, there is a limitation in size of the message, therefore, dissimilar to socks5 that could be used also for such devices, socks 6 cannot be used otherwise there will be limit in the information supposed to be sent in one message.

Best,

Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Jul 2017 20:08:44 +0200

Hi Mohamed,

Thanks for your email. I had two reasons:

1- I was not aware of these two documents.. I guess two less activities
at IETF. right?!

2- I just skimmed the documents you have referred to . They talk about
mechanisms for IP translation   and authentication and making the NAT
easier. But what I do not know exactly or at least with very quick
review could not find,  is that socks proxy also works closely with
firewall and open the ports if the client socks wants to communicate to
any service outside of the network and in general cases the firewall has
all its port close unless otherwise the client ask to open a port. I
know that NAT has a settings to also work closely with firewall but do
not know which one has a better performance. Further the default
assumption in those document is that the NAT service is there. that
means I do not only need to consider the implementation of NAT but also
these documents. While for Socks, only socks standard is enough which
works closely with Selinux for firewalling.

Now the question is which process is heavier from computation
perspective, NAT + this approach or a socks proxy alone that do the
replacement of IP? I haven't done any experiment or comparison yet..

One more important point is that, how NAT will handle TCP connections
when we have non reliable internet connection that breaks frequently but
we cannot establish the TLS every single time where the connection
breaks?   What I liked about Socks 6 that was not in socks5 is that they
handled the unreliable connection, either by purpose or accidentally,
very well since they referred to a document such as TCP FAST OPEN.

Further, Socks proxy is  layer 5 protocol and can handle TLS
communication better than NAT. I am of course not talking about the case
to use socks as a MITM for my TLS connection. That is not the purpose at
all here. But NAT is layer 3 or maximum with some configuration layer 4
which has no flexibility to session layer.

Best,

Hosnieh

this is of course what I also need or expect to use from Socks as a kind
of NATing but at the same time the most important thing is its
interaction with firewall
On 07/06/2017 03:08 PM, [email-masked] wrote:
>
> Hi Hosnieh,
>
>  
>
> Just out of curiosity, is there any particular reason you want to use
> SOCKS? Did you consider other protocols such as:
>
> *De :*Int-area [mailto:[email-masked]] *De la part de*
> Hosnieh Rafiee
> *Envoyé :* mercredi 5 juillet 2017 21:21
> *À :* [email-masked]
> *Objet :* [Int-area] Review> SOCKS 6 Draft
>
>  
>
> Hello,
>
>
> Further, DDoS attack mentioned also in the draft cannot be addressed
> as easily as explained, IMHO. since the proxy server supposed to
> receive higher size messages and the attacker client can only
> overwhelm the socks server easier by less messages from different IP
> address that sounds to be a new client.  Further, for constrained
> devices, there is a limitation in size of the message, therefore,
> dissimilar to socks5 that could be used also for such devices, socks 6
> cannot be used otherwise there will be limit in the information
> supposed to be sent in one message.
>

---

From: <[email-masked]>
Date: Fri, 7 Jul 2017 08:27:56 +0000

Hi Hosnieh,

Please see inline.

Cheers,
Med

De : Hosnieh Rafiee [mailto:[email-masked]]
Envoyé : jeudi 6 juillet 2017 20:09
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Objet : Re: [Int-area] Review> SOCKS 6 Draft

Hi Mohamed,

1- I was not aware of these two documents.. I guess two less activities at IETF. right?!

2- I just skimmed the documents you have referred to . They talk about mechanisms for IP translation   and authentication and making the NAT easier.

[Med] Actually, both NAT and firewall are addressed by PCP. There is no assumption that a NAT must be out there.
   The Port Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as Network
   Address Translator IPv6/IPv4 (NAT64), Network Address Translator
   IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices, and a
   mechanism to reduce application keepalive traffic.

But what I do not know exactly or at least with very quick review could not find,  is that socks proxy also works closely with firewall and open the ports if the client socks wants to communicate to any service outside of the network and in general cases the firewall has all its port close unless otherwise the client ask to open a port.

[Med] Can be done using PCP, as well.

 I know that NAT has a settings to also work closely with firewall but do not know which one has a better performance. Further the default assumption in those document is that the NAT service is there.

[Med] No. RFC6887 defines PCP-controlled device as follows:

===

   PCP-Controlled Device:

      A NAT or firewall that controls or rewrites packet flows between

      internal hosts and remote peer hosts.  PCP manages the mappings on

      this device.

===

that means I do not only need to consider the implementation of NAT but also these documents. While for Socks, only socks standard is enough which works closely with Selinux for firewalling.

Now the question is which process is heavier from computation perspective, NAT + this approach or a socks proxy alone that do the replacement of IP? I haven't done any experiment or comparison yet..

[Med] Please see above. The NAT part is not required. Actually, RFC7652 provides the following:

==

   The mechanism described in this document meets the security

   requirements to address the Advanced Threat Model described in the

   base PCP specification [RFC6887<https://tools.ietf.org/html/rfc6887>].  This mechanism can be used to

   secure PCP in the following situations:

   o  On security infrastructure equipment, such as corporate firewalls,

      that does not create implicit mappings for specific traffic.

==

One more important point is that, how NAT will handle TCP connections when we have non reliable internet connection that breaks frequently but we cannot establish the TLS every single time where the connection breaks?   What I liked about Socks 6 that was not in socks5 is that they handled the unreliable connection, either by purpose or accidentally, very well since they referred to a document such as TCP FAST OPEN.

Further, Socks proxy is  layer 5 protocol and can handle TLS communication better than NAT. I am of course not talking about the case to use socks as a MITM for my TLS connection. That is not the purpose at all here. But NAT is layer 3 or maximum with some configuration layer 4 which has no flexibility to session layer.

[Med] I’m not sure to get your last two points.

Best,

Hosnieh

this is of course what I also need or expect to use from Socks as a kind of NATing but at the same time the most important thing is its interaction with firewall
On 07/06/2017 03:08 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi Hosnieh,

Thank you.

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : [email-masked]<mailto:[email-masked]>
Objet : [Int-area] Review> SOCKS 6 Draft

Hello,

Best,

Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 11 Jul 2017 20:35:34 +0200

Hi Mohamed,

Thanks for your response. That is interesting!

just the last question is that, whether or not similar to TCP FAST OPEN,
can we also have it together with this solution so that we can handle
any unreliable internet connection by avoiding the break in TCP layer.

Thanks,

Best,

Hosnieh

==
> when we have non reliable internet connection that breaks frequently
> but we cannot establish the TLS every single time where the connection
> breaks?   What I liked about Socks 6 that was not in socks5 is that
> they handled the unreliable connection, either by purpose or
> accidentally, very well since they referred to a document such as TCP
> FAST OPEN.
>
> communication better than NAT. I am of course not talking about the
> case to use socks as a MITM for my TLS connection. That is not the
> purpose at all here. But NAT is layer 3 or maximum with some
> configuration layer 4 which has no flexibility to session layer.
>
> this is of course what I also need or expect to use from Socks as a
> kind of NATing but at the same time the most important thing is its
> On 07/06/2017 03:08 PM, [email-masked]
> <mailto:[email-masked]> wrote:
>
>     Hi Hosnieh,
>
>      
>
>     Just out of curiosity, is there any particular reason you want to
>     use SOCKS? Did you consider other protocols such as:
>
>     <https://tools.ietf.org/html/rfc7652>
>
>      
>
>     Thank you.
>
>      
>
>     Cheers,
>
>     Med
>
>      
>
>     *De :* Int-area [mailto:[email-masked]] *De la part de*
>     Hosnieh Rafiee
>     *À :* [email-masked] <mailto:[email-masked]>
>     I quickly reviewed Socks6 document as I was waiting for any
>     initiation to improve socks 5. I found it a good document,
>     however, unfortunately the security is still weak and this
>     document also did not address that but made it worse. I am looking
>     for new methods of authentication as what is available in socks5
>     is just plain text and cannot protect against active attacker and
>     also passive attacker if and if there is a fixed value used as a
>     username and password.
>
>     Further, DDoS attack mentioned also in the draft cannot be
>     addressed as easily as explained, IMHO. since the proxy server
>     supposed to receive higher size messages and the attacker client
>     can only overwhelm the socks server easier by less messages from
>     different IP address that sounds to be a new client.  Further, for
>     constrained devices, there is a limitation in size of the message,
>     therefore, dissimilar to socks5 that could be used also for such
>     devices, socks 6 cannot be used otherwise there will be limit in
>     the information supposed to be sent in one message.
>