Re: [tram] Transport of ICMP errors in TURN

A key part of TURN design was that it was not usable for running general purpose server that accepted traffic from anyone without first identifying who it is that you want to get the traffic from. So the client has to tell the TURN server which external hosts can send it traffic. 

Receiving ICMP violates this because you would need to accept stuff from sources you had not given permission to send you stuff. That allows TURN to be used to build generic servers which allows it to circumvent firewall policy. One of the reasons we invented TURN instead of using one of the other tunnel protocols was to not have this problem. 

> On Aug 27, 2015, at 6:20 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
> 
> I don’t see a privacy problem with the proposal of Marc.
>  
> -Tiru
> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Pal Martinsen (palmarti)
> Sent: Thursday, August 27, 2015 4:00 PM
> To: Simon Perreault
> Cc: Marc Petit-Huguenin; tram@ietf.org
> Subject: Re: [tram] Transport of ICMP errors in TURN
>  
>  
> On 26 Aug 2015, at 14:29, Simon Perreault <sperreault@jive.com> wrote:
>  
> Le 2015-08-26 06:29, Marc Petit-Huguenin a écrit :
> 
> During the presentation of the Path MTU Discovery Using STUN draft in Prague, there was some discussion on how ICMP can be received by the client when the PMTUD probes are sent through a TURN server.  Which reminded me that I worked on that problem when I proposed PMTUD over STUN, back in 2008.  That was the case, according to my notes, but in fact the idea of tunneling the ICMP packets through the TURN server was proposed the year before, but for a different reason:
> 
> https://mailarchive.ietf.org/arch/msg/behave/76pAtymXlAtF5SoD0rgoFECf2Fg
> 
> So my proposal is to add this into turnbis.  I can provide text.
> 
> RFC 5766 section 2.6 <https://tools.ietf.org/html/rfc5766#section-2.6>
> explains that ICMP not being relayed was a design decision to make it
> possible to run a TURN server as an unprivileged user. That conclusion
> is wrong for two reasons:
> 
> - With the BSD sockets API, some ICMP errors are translated into recv()
> error codes. This means that it is always possible to relay at least
> some subset of ICMP errors. (Not sure for TCP or IPv6, I’d
> need to check.)
> 
>  
> It is possible by creating a new listen socket.
>  
> See: https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2
>  
> The code described in that ID works well and we have implemented it in most of our hard and soft clients.
> Not sure about any performance issues when doing this on the server side though.
>  
> The STUNTrace ID is not a TRAM draft anymore. We will ask for it to be AD sponsored, just need to have some more discussion in the security section regarding information leakage. This is particular hard in the intersection network troubleshooting and end user privacy. If you got any concerns or ideas please ping me. (Or maybe we can have chair approval to have the discussion on this list? If any that is..)
>  
>  
> - On Linux, which dominates the market of TURN server, one can receive
> all ICMP errors as an unprivileged user with the IP(V6)_RECVERR socket
> option.
> 
> So my conclusion is: yes, please. :)
> 
> +1
>  
> But we need to carefully describe the security pitfalls. Some people might already be using a TURN server as mean to hide their “true” IP address. Any changes in the TURN spec that introduces a change in the server behaviour that affects the privacy aspect might potentially be risk to some users.  
>  
> .-.
> Pål-Erik
> 
> 
> Simon
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>  
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram