Re: [tram] Transport of ICMP errors in TURN

> On 27 Aug 2015, at 13:35, Marc Petit-Huguenin <petithug@acm.org> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 08/27/2015 04:29 AM, Pal Martinsen (palmarti) wrote:
>> 
>> On 26 Aug 2015, at 14:29, Simon Perreault
>> <sperreault@jive.com<mailto: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.
>> 
> 
> Can you elaborate on this? The proposed extension is to have the server send to the client an indication message that wraps the information for ICMP packets received by the server with only type 3, and perhaps type 12 for ICMPv4 and 1, 2 and 3 for ICMPv6, and that match a permission and contain an UDP header.
> 
> This indication message will contain a XOR-MAPPED-ADDRESS attribute that contains the same IP address/port that was in the CreatePermission/Send messages sent by the client (or in the CHANNEL-BIND request if channels are used).  There is no additional information leaked here.
> 
> Then the indication message should also contain a new attribute that contains the ICMP error.  That also does not reveal anything about the identity of the sender of the packet that triggered this ICMP packet.
> 

If we limit this to deal with host unreachable and related problems I am fine with this. Having the argumentation you just did in the spec is useful. 

My main concern was if we wanted to turn the TURN server into some sort of ICMP gateway and allow the client to trigger all sort of network weirdness on the public side. 

Sorry about wearing the paranoia hat, just wanted to make sure this was understood and discussed.

.-.
Pål-Erik

> - -- 
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJV3vYaAAoJECnERZXWan7E+3MQAJiJa8dF1LLFw9edwiGE6jX6
> EIDiXOcTQIc6UBB9t+JTJcKPaSFD28khEenOY6fMCG9b3VDKuFWxEKi6d8yWTUp5
> Ijhr50sugfmLiS53+jAQEM5RiffJD+3pCcktRJn2Hjy2TNOu1ouPOhXtq/+EQXlX
> PC3j+qFoIYK1OM0cJiRH3DkGPgjNjgy0mQzOfoaSVC2AbCz8swbgj2rwuywyRy42
> cfIuqmUhD5lfp52Gt7pRI8aKlKeN3CKGQOf4LViO0JT+pi9Z50QKI/0hwOmF0Pz1
> I79iT1wt6V4JP7lCatdUk0r5zteXJIO/sUJXWvgmUtv/ginI1i9sV3GwcSBrYBP9
> O0NhEhRho/RIK+v4HvbHoUWn9Wr606rh44gVgDyoIYv04Yvte0i/wt/6UPSh5XeZ
> pMhBKcs8vsdhT6Q4fFE45IFtRDCVrhCT/hC6CRDvSCGkw0VW+98eZdsOJGuLTKan
> e6DWcHFV7tB1/aOr8jDsIyDjNnY4FGN1BfYtF7LqGdE+jNkSkCiDDV7Hd9QeG9vu
> VUlm5D9z6LBuHGbmuNHOmrZP8zi858XQa9Ta/3UKbotO8XErgEGv+dzRKXp/KpaI
> pTf2xry4tWNBdpiar3L9uG1qaUQRW47lk22N/XQvQJAGIPAuPxoAWSiGIMNp2jPu
> 803fI2FWofeSyGmPpUN9
> =OkNS
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram