From nobody Fri May 27 05:15:42 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D8412B05C; Fri, 27 May 2016 05:15:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 05:15:38 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stunbis-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:15:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-07.txt Pages : 62 Date : 2016-05-27 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 27 05:46:24 2016 Return-Path: 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 372BE12D9B4 for ; Fri, 27 May 2016 05:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Nz_ifYSvbGHw for ; Fri, 27 May 2016 05:46:20 -0700 (PDT) Received: from implementers.org (implementers.org [173.246.102.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E67312D66F for ; Fri, 27 May 2016 05:46:20 -0700 (PDT) Received: from [IPv6:2001:0:53aa:64c:1485:9c85:2fc9:fa50] (unknown [IPv6:2001:0:53aa:64c:1485:9c85:2fc9:fa50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4E7E9201D3 for ; Fri, 27 May 2016 14:46:18 +0200 (CEST) References: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> To: tram@ietf.org From: Marc Petit-Huguenin Message-ID: <57484196.1040006@petit-huguenin.org> Date: Fri, 27 May 2016 05:46:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vNLQKfsgIRA6U8QbcGvuANdAqpuDFACph" Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:46:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vNLQKfsgIRA6U8QbcGvuANdAqpuDFACph Content-Type: multipart/mixed; boundary="piP8IS9BDnc2G3j6AG99ef9W2SmIvRBok" From: Marc Petit-Huguenin To: tram@ietf.org Message-ID: <57484196.1040006@petit-huguenin.org> Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-07.txt References: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> In-Reply-To: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> --piP8IS9BDnc2G3j6AG99ef9W2SmIvRBok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The changelog for this new version is: o Add USERHASH attribute to carry the hashed version of the username. o Add IANA registry and nonce encoding for Security Features that need to be protected from bid down attacks. o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support truncation limits (pending cryptographic review). We have now completed our list of updates for STUN. One of the open issues is the need for a cryptographic review of the new = HMAC truncation proposal. We welcome comments and reviews in advance of a WGLC. On 05/27/2016 05:15 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the TURN Revised and Modernized of the IET= F. >=20 > Title : Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Jonathan Rosenberg > Dan Wing > Rohan Mahy > Philip Matthews > Filename : draft-ietf-tram-stunbis-07.txt > Pages : 62 > Date : 2016-05-27 >=20 > Abstract: > Session Traversal Utilities for NAT (STUN) is a protocol that serves= > as a tool for other protocols in dealing with Network Address > Translator (NAT) traversal. It can be used by an endpoint to > determine the IP address and port allocated to it by a NAT. It can > also be used to check connectivity between two endpoints, and as a > keep-alive protocol to maintain NAT bindings. STUN works with many > existing NATs, and does not require any special behavior from them. >=20 > STUN is not a NAT traversal solution by itself. Rather, it is a too= l > to be used in the context of a NAT traversal solution. >=20 > This document obsoletes RFC 5389. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tram-stunbis-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-stunbis-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 --piP8IS9BDnc2G3j6AG99ef9W2SmIvRBok-- --vNLQKfsgIRA6U8QbcGvuANdAqpuDFACph Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXSEGWAAoJECnERZXWan7EF88P/RG3R8y1jV9PEJDiC3ap9Uap 92SbBb8RD0NnRMXokEZwvPJNJ9JY6bq0fFON+qqFKLxbgRkMtOGhvbvIf5BN7ZJq yH+Ez/ZHJPp9sq+c67FbmTsVizkv4yHBzGFfJdQaEaEqIS8Bq+YH4Qquvd4GTqCt XvL0222W/cuQfmJz3aOBTXAenq87CGypXkBBtl3rc7/26DrGFV/FXXOd1JxcXPAk vvzEaJ/2a8aqZ0t7ra2zBAf4rhhXwusAjl3ziduUVk8Y7UFj8QJIjm7f7RMoDNxz /NNgNksTP7iNgPs76kkHZheJLmSK0DavJAMYeoNhAO2Eseu5AiLWdUuX30KUrwj1 58fz1ohyWPmRw0I5hDs/R43J6clFJjtTiv8Z6imS116D6VFLcODsfLEx8qWvvhK5 PYaF16tsn5NjNB3FntttZw4AL59LSN6Kuwqq8PghHMNctxpTUrnrPJwKIL+2+EE8 LBqbPhYaSB4fJ9QUeUxbaERi4F7ogpHUCMV1cjGm/Pjus5eBkWMqiFvBl1Mz77Yn Mx002PFwO/K/UK513F14xP1VnKafYgLt6xrZKiYzeD99Bem/m4dAIcfYZ/6FBhbB 4XiGVZYPlY1mPx3T6Af1FXbXzZ+cr6ab+X0cFji13MlJJReT+s9iY4VjaM4aLfSA vLQlao9Lo0TtDARXYitd =jel2 -----END PGP SIGNATURE----- --vNLQKfsgIRA6U8QbcGvuANdAqpuDFACph-- From nobody Fri May 27 12:46:16 2016 Return-Path: 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 C748812D889 for ; Fri, 27 May 2016 12:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com 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 jnn5oIMbxPkt for ; Fri, 27 May 2016 12:46:13 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC12912D848 for ; Fri, 27 May 2016 12:46:12 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id h185so52887180qke.2 for ; Fri, 27 May 2016 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=lh5UnidedG4dLq/uX4CGoaxQJSfgcF1gndF7pM6SBCk=; b=l7AtGDusU5HhWRwzYcXU5hg4YCZ5/9mBntx98qEGFWvR3dzJEMo2PlwfOiDP4FbFMk R8P5itzcZCF9tMEqBFb/Tsb9XliAq3NuMbBBpEKvb7EPUiuzoQzvfrlf+5ZWZY5sY2vG GSLfwP0k0AZevuENiit6GBWwp67126LnXOU4fZ7mkiGbqRJsK3GKAct+sflkLGNxCanx JNDaxmy0C9lrGXkjw3JMFSUDci6kv0sGibNMuuI4OTOgXFMZv7T0vz7YSDJTdiuF93kb iVyOia1LXSEPBeNRJPKIeqeU1vHdBdZ07Nmicuu5oyP2pvraiMCmeOWD6YIYNzHtoVu+ +Xhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=lh5UnidedG4dLq/uX4CGoaxQJSfgcF1gndF7pM6SBCk=; b=drTW3z2z0QfDGX5PSNYtK1iMfNBevx/WuGfiwEPdEYfw+HYtAzqf9oh25mQoc+Kf85 eIk678uybu2EXEPoRUEtor3pjt4HJ/LV8bS8Hy66JywcIZrE2ydDhJ3bMPYmR8sz+qNJ R1Rz5r5yIgi8KPugvCQI6pvxSkg2sz8X9h/PntxusOeEoMvwctP2nJeM4UBQ57NBXzQQ 2TwpFmb+tKA0nwRXPAMu/2megVMLNGIX1R+q8MNoPsLJ4/wMMCjCehcftSINDLZACKEC CPa+4miM1Hj/yXGaXi3CIrN7q7KgF/TLd66c7uV20tSodQdKvuospxe82ZVAcimFJSWT uOPA== X-Gm-Message-State: ALyK8tLyFf94ozGCv2mpkRWdy04qhxXntcnajjfCAhMRar7l0qT6fwutzYZFe1BdTyHr3J/K23m50YKVPjye/c5UtIuRf9jVjtMYuhxWNx6kiq6DNjpqq6eq9ks9KjscSp9DPJF8zqnRBQeC1so/u/1VLf4Bbmioenc4zxhYzgw= X-Received: by 10.237.44.162 with SMTP id g31mr14879552qtd.67.1464378371936; Fri, 27 May 2016 12:46:11 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:a98e:3e8e:b1b2:a0cc]) by smtp.gmail.com with ESMTPSA id d193sm4045800qke.4.2016.05.27.12.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 27 May 2016 12:46:11 -0700 (PDT) To: Brandon Williams , Marc Petit-Huguenin , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A90B27.9080502@akamai.com> <5703C986.2070006@akamai.com> From: Simon Perreault Message-ID: <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> Date: Fri, 27 May 2016 15:46:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <5703C986.2070006@akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 19:46:15 -0000 All, The WG has not yet expressed a clear consensus for or against Brandon's proposal. If you have an opinion either way, please speak up now. Brandon, no need to restate your position. :) Thanks, Simon Le 2016-04-05 à 10:19, Brandon Williams a écrit : > Hi all, > > I haven't seen any responses to this question so I'm going to convert it > into a proposal. > > My sense is that the group sees little enough problem with > fragmentation, and particularly little enough risk the the PMTU is 576 > bytes, that the MUST language about MTU limitations can be removed. I > propose that we completely remove the following statement from stunbis. > > The MTU limitation is a SHOULD, and not a MUST, to account for cases > where STUN itself is being used to probe for MTU characteristics > [RFC5780]. Outside of this or similar applications, the MTU > constraint MUST be followed. > > I think this reflects the outcome of a previous discussion. Are there > any objections to this change? > > --Brandon > > On 01/27/2016 01:23 PM, Brandon Williams wrote: >> On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>>> s 6.1 This section still says "MTU constraint MUST be followed" >>>> language. I'm pretty sure that we decided to relax this constraint in >>>> Dallas, but I don't see it in the minutes. It seems to be implied by >>>> the decision about removing the SCTP requirement. >>> >>> My recollection was that the relaxation was linked to the introduction >>> of the SCTP transport in STUN (which permitted safe fragmentation). >>> Now that SCTP is gone, I am not sure that this decision stands alone. >>> >> >> IIRC, in Dallas we discussed MTU constraints in the context of both the >> SCTP requirement and the ORIGIN draft. The point was made that both >> small MTUs and fragment delivery failure are rare and that the existing >> requirements language is unnecessary. This was the foundation for >> removing the SCTP language and for removing some size constraint >> language from the ORIGIN draft. My understanding of the discussion was >> also that the group agreed to relax the existing RFC5389 constraint, at >> least for request/response message types. >> >> This really just applies to the following text: >> >> If the path MTU is unknown for UDP, messages SHOULD be the smaller of >> 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for >> IPv6 [RFC2460]. >> >> The MTU limitation is a SHOULD, and not a MUST, to account for cases >> where STUN itself is being used to probe for MTU characteristics >> [RFC5780]. Outside of this or similar applications, the MTU >> constraint MUST be followed. >> >> IOW, if you don't know the PMTU, an allocation request MUST be smaller >> than 576 bytes for IPv4. My sense of the room in Dallas was that we >> agreed this is an unnecessary restriction, at least for the >> request/response message types. >> >> So, what do others think/remember? Should we keep the existing >> requirement (in which case I think it will be important to consider this >> limitation whenever new attribute types are created)? Am I remembering >> correctly that we already decided to loosen the requirement and it just >> didn't make it into the notes for the meeting? >> >> --Brandon >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > From nobody Sun May 29 07:51:36 2016 Return-Path: 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 7070112D0A4 for ; Sun, 29 May 2016 07:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 r5tJbWRqBbml for ; Sun, 29 May 2016 07:51:32 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7B012D09D for ; Sun, 29 May 2016 07:51:32 -0700 (PDT) Received: from [IPv6:2602:61:7532:f600:1c94:ed30:c9c0:b73a] (unknown [IPv6:2602:61:7532:f600:1c94:ed30:c9c0:b73a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5BB54201F5; Sun, 29 May 2016 16:51:30 +0200 (CEST) To: Simon Perreault , Brandon Williams , "tram@ietf.org" References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A90B27.9080502@akamai.com> <5703C986.2070006@akamai.com> <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> From: Marc Petit-Huguenin Message-ID: Date: Sun, 29 May 2016 08:51:27 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="66Wu6phaRhm82JHW0xhi4b3x3Krjf68kJ" Archived-At: Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 May 2016 14:51:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --66Wu6phaRhm82JHW0xhi4b3x3Krjf68kJ Content-Type: multipart/mixed; boundary="I2txWP93747jfDtnRkhjba3NsiOUqXWBm" From: Marc Petit-Huguenin To: Simon Perreault , Brandon Williams , "tram@ietf.org" Message-ID: Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04) References: <55E8644F.8090506@akamai.com> <56A83C5B.6010702@acm.org> <56A90B27.9080502@akamai.com> <5703C986.2070006@akamai.com> <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> In-Reply-To: <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> --I2txWP93747jfDtnRkhjba3NsiOUqXWBm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Note that the following opinion is expressed as individual, not as co-edi= tor of the draft. I am opposed to this proposal, and we should keep things as they are.=20 After reading everything I could get my hands on about fragmentation ([1]= and [2]), I think that most of the concerns expressed in these documents= are still true today. If not be able to fragment is a problem, then STUN over SCTP over UDP, as= described in a previous iteration of this document, was the way to go. = draft-ietf-tram-stun-pmtud describes a solution to measure the PMTUD for = STUN Usages that have the possibility of choosing the packet size (like v= ideo packets carried in TURN DATA messages or in a TURN channel). In fact the text should be even more strict and use a conditional MUST. = I am opposed to any use of SHOULD/SHOULD NOT in any kind of document, bec= ause this is a well-known backdoor used by sloppy developers that count o= n the fact that most people never read RFC 2119 and so are not aware of t= he difference of meaning between SHOULD and "should". Conditional MUST i= s the way to go in all cases, but that would represent far too many edits= to do it everywhere in this document. [1] http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf [2] https://tools.ietf.org/html/rfc4963 On 05/27/2016 01:46 PM, Simon Perreault wrote: > All, >=20 > The WG has not yet expressed a clear consensus for or against Brandon's= > proposal. If you have an opinion either way, please speak up now. >=20 > Brandon, no need to restate your position. :) >=20 > Thanks, > Simon >=20 > Le 2016-04-05 =C3=A0 10:19, Brandon Williams a =C3=A9crit : >> Hi all, >> >> I haven't seen any responses to this question so I'm going to convert = it >> into a proposal. >> >> My sense is that the group sees little enough problem with >> fragmentation, and particularly little enough risk the the PMTU is 576= >> bytes, that the MUST language about MTU limitations can be removed. I >> propose that we completely remove the following statement from stunbis= =2E >> >> The MTU limitation is a SHOULD, and not a MUST, to account for case= s >> where STUN itself is being used to probe for MTU characteristics >> [RFC5780]. Outside of this or similar applications, the MTU >> constraint MUST be followed. >> >> I think this reflects the outcome of a previous discussion. Are there >> any objections to this change? >> >> --Brandon >> >> On 01/27/2016 01:23 PM, Brandon Williams wrote: >>> On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>>> s 6.1 This section still says "MTU constraint MUST be followed" >>>>> language. I'm pretty sure that we decided to relax this constraint = in >>>>> Dallas, but I don't see it in the minutes. It seems to be implied b= y >>>>> the decision about removing the SCTP requirement. >>>> >>>> My recollection was that the relaxation was linked to the introducti= on >>>> of the SCTP transport in STUN (which permitted safe fragmentation). >>>> Now that SCTP is gone, I am not sure that this decision stands alone= =2E >>>> >>> >>> IIRC, in Dallas we discussed MTU constraints in the context of both t= he >>> SCTP requirement and the ORIGIN draft. The point was made that both >>> small MTUs and fragment delivery failure are rare and that the existi= ng >>> requirements language is unnecessary. This was the foundation for >>> removing the SCTP language and for removing some size constraint >>> language from the ORIGIN draft. My understanding of the discussion wa= s >>> also that the group agreed to relax the existing RFC5389 constraint, = at >>> least for request/response message types. >>> >>> This really just applies to the following text: >>> >>> If the path MTU is unknown for UDP, messages SHOULD be the smalle= r of >>> 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes= for >>> IPv6 [RFC2460]. >>> >>> The MTU limitation is a SHOULD, and not a MUST, to account for ca= ses >>> where STUN itself is being used to probe for MTU characteristics >>> [RFC5780]. Outside of this or similar applications, the MTU >>> constraint MUST be followed. >>> >>> IOW, if you don't know the PMTU, an allocation request MUST be smalle= r >>> than 576 bytes for IPv4. My sense of the room in Dallas was that we >>> agreed this is an unnecessary restriction, at least for the >>> request/response message types. >>> >>> So, what do others think/remember? Should we keep the existing >>> requirement (in which case I think it will be important to consider t= his >>> limitation whenever new attribute types are created)? Am I rememberin= g >>> correctly that we already decided to loosen the requirement and it ju= st >>> didn't make it into the notes for the meeting? >>> >>> --Brandon >>> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --I2txWP93747jfDtnRkhjba3NsiOUqXWBm-- --66Wu6phaRhm82JHW0xhi4b3x3Krjf68kJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXSwHvAAoJECnERZXWan7EAXcP/jC5IiggsUK0WYM9mNl3fgGX MTjE7K6JHI+TBi4wedvuNst5n1zaDrt0JBjTh3cNBzJqvFSAEEC4TfWR1ZH2+l1O vd+xOlWLgrM7HLPld5NfguJgMegUVS02xcZ+tPVInK6jJYAGElO5vnEJfv2aK1no kEQ7wa3gfwfieMgCbqMbo9TD+wj8RRl3wUwfe/k87BZmhXse8X5UnE0YL2NtLuHs lcE6OH4P+h8zIm+/BIkA9BKl4i03zlc+fXhvtESspyV59NI3Wfb32XDfCQ51EL6G FS2hkOQCZC3KWAFxyXuMvdgzTVuqHz5ptGFmW6wdOhJs4rBnRe9ZxUPC7dadVezw 5XdL3MnyRjoukQIQkqjGfjR5DrMgY9ea4nvTZfezSCQ4Z5xxeg9Z/mZfnfJbei0J jha0xqAJEW0Eux451o2zXMEVVlN2QHaj55Uaqrf+knQ3B4cv/jmp8LnaylKcBBLs r8Gxhw1hObSI6/X6+pv8NnPE/Ys5RIcNfs8FCIKWRemMxy5C/V1pOj5aGfy0vIlb xlHjQ+r1MecbFdaxiENGAUWzEj1YLTjyBhYFcnl9+P5qOTG7HH8wtoqx3mFzNH20 wvB8ENw1XI5bY8iG8VVUE619MTUphYpJWudgLNck4fsOsAipbWKYaafNLrftX1SY U07QzVp8GQK1YphtDmHC =r3Ad -----END PGP SIGNATURE----- --66Wu6phaRhm82JHW0xhi4b3x3Krjf68kJ-- From nobody Mon May 30 06:01:35 2016 Return-Path: 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 EF57512D527 for ; Mon, 30 May 2016 06:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jive-com.20150623.gappssmtp.com 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 fYMl7DJ5Uz91 for ; Mon, 30 May 2016 06:01:30 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67FFC12D52E for ; Mon, 30 May 2016 06:01:30 -0700 (PDT) Received: by mail-qg0-x22b.google.com with SMTP id q32so77713755qgq.3 for ; Mon, 30 May 2016 06:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=mBqKc6FEev8+yn9YkYEJRTEYRh0wpg7tYmDsKQgewe0=; b=Shkd8InmEgGV4dn1Nq5WO+EPGaNj9MGztEVU35IwB1xljUwsfMF7JZ/pgbeSDeTBx1 8fA7upQTrcYjyRQ84XPPpKkj9RTCS3cBt6DFHZXe9m9Seuz2pn03Msny/tFk7Ticnd0r KDWrkoYWxcaM5cbSOJdqhzMfuyJ9YTISsnIbElk2oEbE2zzwVDWGPwRaYRVBE8Wcw/Nn 6vLrVHVrbkdWLNtcL3xiYSNDCQapcqQClUkjnXW2SvI1+2keRdLThqdxBJ9lQJNvOS/v L4R4h3snE2sEBR1wB8cS9tXx4FhCa4N6/8BxuWBGflI7bh1aufhjEjGxBzgKrA0HRtGv 0aog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mBqKc6FEev8+yn9YkYEJRTEYRh0wpg7tYmDsKQgewe0=; b=S/PgfyPhskC4apSM55pZ9wqMs07NblQLEs1UDz0UlAJCZsmt16hpLrTO+yL5Wbk0UK 6tOLVdYfAHqP1c3Lbp44IpopRLgXoPtG4B+hD8f/+0S/Twvahl7BZ+6MZXQmy33Or8G+ MYDwdVYuLp0cIXZitg3IXJ1MYQ90vEPPFUKQczyGnXWdxoAM3VTH/5519DhD+wws/vzR vQpXsTyOB3Vbx7yGRbHooXWktUKgm3GIRg4VVOoOeEn7NBLSFkyH39SEfuzgBFQ2pJ// X4BIhx5emKBqm/mWqnIaZaa/r4jj9k9B33+uARG3LZ7v9dg+xjf0DHg6xqAlXqBxagiC 8mIw== X-Gm-Message-State: ALyK8tJj8EXw7XnqwHloiPt7sfrs1c3AClCYM2vhTfRlOll+eWf+ZQooV1gl44twL8CEgGhlcyiGBsCGtXz0gDnsGasv3iRE75kjjAl8RAZ+WavstCFYedXcOQZ2CPFD2hd3rOyaLiaKNXPOWAXGOszwl7+BYGvyk/Qd7q6aOeY= X-Received: by 10.141.0.3 with SMTP id b3mr26789970qhd.13.1464613289172; Mon, 30 May 2016 06:01:29 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:d31:7032:5956:ccc5]) by smtp.gmail.com with ESMTPSA id 188sm9324281qhf.44.2016.05.30.06.01.28 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 May 2016 06:01:28 -0700 (PDT) To: Marc Petit-Huguenin , tram@ietf.org References: <20160527121538.3109.78797.idtracker@ietfa.amsl.com> <57484196.1040006@petit-huguenin.org> From: Simon Perreault Message-ID: <4e5afec8-dc53-dcdd-361f-3814543d051c@jive.com> Date: Mon, 30 May 2016 09:01:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <57484196.1040006@petit-huguenin.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-07.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 13:01:33 -0000 TRAMsters, Please review this new revision carefully. This is important work and this WG's main deliverable. We'd like to close on this by Berlin. Thanks, Simon Le 2016-05-27 à 08:46, Marc Petit-Huguenin a écrit : > The changelog for this new version is: > > > o Add USERHASH attribute to carry the hashed version of the > username. > o Add IANA registry and nonce encoding for Security Features that > need to be protected from bid down attacks. > o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support > truncation limits (pending cryptographic review). > > We have now completed our list of updates for STUN. > > One of the open issues is the need for a cryptographic review of the new HMAC truncation proposal. > > We welcome comments and reviews in advance of a WGLC. > > On 05/27/2016 05:15 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the TURN Revised and Modernized of the IETF. >> >> Title : Session Traversal Utilities for NAT (STUN) >> Authors : Marc Petit-Huguenin >> Gonzalo Salgueiro >> Jonathan Rosenberg >> Dan Wing >> Rohan Mahy >> Philip Matthews >> Filename : draft-ietf-tram-stunbis-07.txt >> Pages : 62 >> Date : 2016-05-27 >> >> Abstract: >> Session Traversal Utilities for NAT (STUN) is a protocol that serves >> as a tool for other protocols in dealing with Network Address >> Translator (NAT) traversal. It can be used by an endpoint to >> determine the IP address and port allocated to it by a NAT. It can >> also be used to check connectivity between two endpoints, and as a >> keep-alive protocol to maintain NAT bindings. STUN works with many >> existing NATs, and does not require any special behavior from them. >> >> STUN is not a NAT traversal solution by itself. Rather, it is a tool >> to be used in the context of a NAT traversal solution. >> >> This document obsoletes RFC 5389. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-tram-stunbis-07 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-07 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Mon May 30 06:22:58 2016 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EA412D540; Mon, 30 May 2016 06:22:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160530132257.29139.22211.idtracker@ietfa.amsl.com> Date: Mon, 30 May 2016 06:22:57 -0700 Archived-At: Cc: sperreault@jive.com, spencerdawkins.ietf@gmail.com, tram@ietf.org, tram-chairs@ietf.org Subject: [tram] tram - New Meeting Session Request for IETF 96 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 13:22:57 -0000 A new meeting session request has just been submitted by Simon Perreault, a Chair of the tram working group. --------------------------------------------------------- Working Group Name: TURN Revised and Modernized Area Name: Transport Area Session Requester: Simon Perreault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 30 Conflicts to Avoid: First Priority: payload rtcweb avtext avtcore ice mmusic dispatch sipcore perc Second Priority: rmcat httpbis clue xrblock tls Special Requests: ---------------------------------------------------------