IETF Logo Mail Archive

Re: [tram] STUNBIS: Happy STUNballs

"Olle E. Johansson" <oej@edvina.net> Fri, 31 March 2017 10:12 UTC

Return-Path: <oej@edvina.net>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635221286AB for <tram@ietfa.amsl.com>; Fri, 31 Mar 2017 03:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 QOVGzy1y6xet for <tram@ietfa.amsl.com>; Fri, 31 Mar 2017 03:12:27 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435771293D8 for <tram@ietf.org>; Fri, 31 Mar 2017 03:12:26 -0700 (PDT)
Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1FA513000; Fri, 31 Mar 2017 12:12:18 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_B82D812B-4EE7-457A-9949-DB9FD32B92A4"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <bf70be24-2cda-3aa1-8ee4-ec8733df87a2@acm.org>
Date: Fri, 31 Mar 2017 12:12:17 +0200
Cc: Olle E Johansson <oej@edvina.net>, tram@ietf.org
Message-Id: <23A576F1-A8B1-4520-96FC-D26955A0DDA2@edvina.net>
References: <B528E069-3830-421F-A37E-A28A7BE40271@edvina.net> <bf70be24-2cda-3aa1-8ee4-ec8733df87a2@acm.org>
To: Marc Petit-Huguenin <petithug@acm.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/aYV3wAWGFeus2dnZJAfFgzS8Puc>
Subject: Re: [tram] STUNBIS: Happy STUNballs
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 31 Mar 2017 10:12:30 -0000

> On 31 Mar 2017, at 11:58, Marc Petit-Huguenin <petithug@acm.org> wrote:
> 
> Hi Olle,
> 
> On 07/26/2016 02:11 AM, Olle E. Johansson wrote:
>> Hi!
>> 
>> STUN now supports IPv6 too (because of the ICE usage) which is a
>> significant change. The text in the intro needs to reflect this STUN
>> usage and change too. From a previous NAT discovery role it’s about
>> network path discovery now.
> 
> STUN is supporting IPv6 since RFC 5389, so we do not think that much changed there and we left the text in the introduction as it was.
> 
>> 
>> A STUN usage use DNS SRV to discover STUN servers. What happens if
>> the server name resolves into both A and AAAA addresses? In this
>> case, STUNbis needs to have some advice on how to connect. RFC 2782
>> just says all IP addresses needs to be tried before moving to the
>> next SRV priority, but nothing about order or if we’re connecting in
>> parallell or in serial mode. Serial mode would be bad in STUN due to
>> the timeouts.
>> 
>> This needs to be handled in StunBis.
>> 
> 
> We updated the text to follow the advices in RFC 6555.  That was done in 3 places:
> 
> - Section 8, to explain what to do after processing according to RFC 2782 and on a domain name.
> - Section 12, to explain what to do with the NAT Discovery Usage.
> - Section 13, updating the list of things that other STUN Usage should do, in that case explain what to do with IPv6 and IPv4 addresses.
> 
> We'll leave it to icebis and turnbis to do the same for their respective STUN Usages.

Elegant. You are not solving the problem but tell the authors of STUN usages to solve the problem :-)

Note that RFC 6555 has a focus on connection-oriented transports and pretty much leaves old UDP in the cold.
"The mechanism described in this document is directly applicable to
   connection-oriented transports (e.g., TCP, SCTP), which is the scope
   of this document. “

It continues with: "For connectionless transport protocols (e.g.,
   UDP), a similar mechanism can be used if the application has request/
   response semantics (e.g., as done by Interactive Connectivity
   Establishment (ICE) to select a working IPv6 or IPv4 media path
   [RFC6157])."

Which may mean that STUN/UDP is covered.

/O

v2.23.0 | Report a Bug | By Email