Re: [tram] Transport of ICMP errors in TURN

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

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

On 08/27/2015 08:33 AM, Cullen Jennings (fluffy) wrote:
> 
>> On Aug 27, 2015, at 8:23 AM, Simon Perreault <[e-mail]> wrote:
>>
>> Le 2015-08-27 09:49, Cullen Jennings (fluffy) a écrit :
>>>
>>> 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.
>>
>> Good point.
>>
>> That is easily solved by having the TURN server enforce permissions on
>> the 5-tuple of the ICMP error's encapsulated original packet. Exactly
>> the same way stateful firewalls do it.
>>
>> Simon
> 
> Yep, with that change it would be OK.

I believe that the text in the patch I just sent does that.

> 
> I find that many networks block ICMP for one reason or another thus one can not count on it working most of the time so it has really limited value for applications as they end up using a method that works all the time. 

Yes, and that's OK - both ICE and PMTUD are designed to work without receiving ICMP, but work better if they do.

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

iQIcBAEBCAAGBQJV3yONAAoJECnERZXWan7E/MEP/iMhsPf2+UOtWxJbanHsqvs8
wstZUctFVtEyx2/dUnSP/zXfzGpDhnnGXZXdxqisqOrf+42/itP0CbCufvIzu9ZD
DuRdy6TEY7MTzYHTI3cGBByL6J6RbkZF8ytymND0h2EP2gk284PZkM6O3hKoZVYF
ZUCM3BB3vWOphrZVescHn2ulYkjZFfUgyEpnPShKi5xaYYlu+e56wVouZn8653n3
wUZA5e5QEZgV5vgzFpbOLt6ZW0EorWFqgoGOj2Qb0h925PwadNFqLnnOQF7Pf+yT
stect5QQtiNI1NdQSy0vp/IzEUn9EWTi2NXfTYqD9sA0GCGDQCiabVUjTx0DXgU4
I+WXqXFUesm9zi6SS+SB4f67zhUH37zMhwkngbyd6NTfaoHUVLVdaXNQU8MzZDHs
sQPStzn24GLSsUB5W/gsrSwq/c3s/60vFcZ/2mT8jDRErHpeTmz/ose8OYFfUGTL
QIFS28m2W2VrkPOegw04vIiGAroeo+MgFkLok99M+IHzJdM2O7BL4vAS7Qp8Lh4F
YaEkKQrlAFtff+asqwOdZr7pH9mif2eloBaghaoN0rEi51D88HnRgalY+ZguhwES
TiNwTlfJzGWGdozBDvPWcwGlB+oFmPGOoGXeNKvPrvE3UFDc69bM0/nAUTOSrx6m
3ExRElqHwELyyZ3dV1gu
=LI7w
-----END PGP SIGNATURE-----