Re: [tram] Transport of ICMP errors in TURN

[Marc Petit-Huguenin <[e-mail]>]

-----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
> <[e-mail]<mailto:[e-mail]>> 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.

- -- 
Marc Petit-Huguenin
Email: [e-mail]
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-----