Re: [tram] Transport of ICMP errors in TURN

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Thu, 27 August 2015 10:29 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1B1ACE4C for <tram@ietfa.amsl.com>; Thu, 27 Aug 2015 03:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYiAKuaOpFy2 for <tram@ietfa.amsl.com>; Thu, 27 Aug 2015 03:29:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A47F1A8991 for <tram@ietf.org>; Thu, 27 Aug 2015 03:29:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7765; q=dns/txt; s=iport; t=1440671378; x=1441880978; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+rnBEfe+oq6Q6qWvZJss4I7ub1WjlbqvE5VyEJBIHCA=; b=OreAdGsJ++W2wzrZ4h449kQYi1lLrz4S5yudSeQtDDiJDUzgTqO8XUCL 3mrWZ9wvbLKKaM9VEjfe+GcpXchwe8iVWvRih3vpYciKS855KjnS3oR2X a5NK6e2E0bmYX0DPUJYCi2Jn3syhp1CoX6hcQLXvpCNzgW6c9iQwFG8qK 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CmAgCP5d5V/4UNJK1dgxtUaQa9cQEJgW4BC4V5AoEwOBQBAQEBAQEBgQqEJAEBBAEBAWsLEAIBCA4xBycLFBECBA4FiC4NA8gWAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSIeIJphEBHBAeDGIEUBZU9AYUFh22BSoQylGQmg39xAYFHgQUBAQE
X-IronPort-AV: E=Sophos; i="5.17,422,1437436800"; d="scan'208,217"; a="23987862"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2015 10:29:37 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7RATaCU007313 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 10:29:36 GMT
Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 05:29:35 -0500
Received: from xhc-rcd-x11.cisco.com (173.37.183.85) by xch-rcd-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 05:29:35 -0500
Received: from xmb-rcd-x06.cisco.com ([169.254.6.133]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 05:29:35 -0500
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: Simon Perreault <sperreault@jive.com>
Thread-Topic: [tram] Transport of ICMP errors in TURN
Thread-Index: AQHQ3+oWUq4elx0VKUWmZ9u5ZuMizJ4eib2AgAFwzIA=
Date: Thu, 27 Aug 2015 10:29:35 +0000
Message-ID: <A8F8D0A4-C847-4F3E-B5A3-45DA47CB95D9@cisco.com>
References: <55DD94FF.7080400@acm.org> <55DDB133.6090608@jive.com>
In-Reply-To: <55DDB133.6090608@jive.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.18]
Content-Type: multipart/alternative; boundary="_000_A8F8D0A4C8474F3EB5A345DA47CB95D9ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tram/W_OQnNiwdS854-GRV8z_PQkWd0A>
Cc: Marc Petit-Huguenin <petithug@acm.org>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Transport of ICMP errors in TURN
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 10:29:39 -0000

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.

.-.
Pål-Erik

Simon

_______________________________________________
tram mailing list
tram@ietf.org<mailto:tram@ietf.org>
https://www.ietf.org/mailman/listinfo/tram