Re: [tram] Transport of ICMP errors in TURN

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 08/27/2015 07:01 AM, Pal Martinsen (palmarti) wrote:
> 
>> On 27 Aug 2015, at 13:35, Marc Petit-Huguenin <[e-mail]> wrote:
>>
> 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.
> 
> 
>> 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. 

OK, I'll propose text for the security consideration section

> 
>> 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. 

No.  Only error ICMP are to be translated.  See the patch I just sent.

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

- -- 
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

iQIcBAEBCAAGBQJV3yJtAAoJECnERZXWan7EkecP/3g04DXkXoaYX13uEa670buf
MidwaB6M3ZtfSVLUg8Ogga96ceAPbeJqhmTc9IS7yaYZ1aKwwdJxfvNb4kkVaN9T
K/8GN+gT9qgtRldTOBkuiah1c6CcduKQqY/0NZVlL5Uv8csQE5rDBA+d1MyKYyEc
oIvSHhapnKfHDMJwlRtWMl50HECtAKNrtvbL+jpsi4zErXSYJPTS40GAnBKAyGSn
QhWNaqhcqmAkEWvTrhSkkRVOZFS/VUGsHaIpSSm3MrR/HcgH9V2jIgXy9M4RZwmk
YHHJJ7+oqAKBm/ftij1ZJiJkHRrO+fA+56p3G4wRBtL90jddCgRFv4kv6YNpXmGK
kzAj3jzbvKOwnogAKv+LI3HPyk6fVBQEhF0O3fU8Vy8bJHpB0LaX3ZrsnMZFB5FW
HYPk+DgtlZHg4M4X5smxk6vp7MFQaDTBMmHMxqtPAiiVwypze9OHaAPG6B7EX5oY
BeF0SXedQmZshCSSGvDgYdrmNl1s2Dte+wBiHlA/iXbKkRR3pBLHGWAf+MpbHbAQ
cokI8VdcQZqQ3pPZgrk5FBpMyJHImJT4EM2ozwHo9uiU09ZxbUAm5ebKHrlv/JxH
fmCCdwZkaATvXi64bIwkXEvf3ZLZzE6NIr5jSgsXnoO/Nc7ja6lZkvDOq2Y/mVpd
pHjog+8vP58T1Wa9oE+9
=CbBc
-----END PGP SIGNATURE-----