From nobody Fri Jul 1 05:32:26 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 DCF8912D5AB; Fri, 1 Jul 2016 05:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 1qjtuQx_aTAj; Fri, 1 Jul 2016 05:32:16 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 185BA12D593; Fri, 1 Jul 2016 05:32:16 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id t127so198588740qkf.1; Fri, 01 Jul 2016 05:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sopJkiB4zHI8sI+7YgK8PYwg2Z6aRO2mmKT1DHale7M=; b=KKFZlNBK8b3QFXR66Cn88/JntFUick4qnr/BHTenWfCHeevI1imx2rAwWNcg4mmhx9 qHLg36/XsdWcyhl1bZuASVh5x6Hf43mu+VrLqkM1TD+/kSUUQj0ptrSP1ClzR16V6cy5 ACfUevH+7PmXYziwDmLpMKUk8rUF331N7KuCPUyG2My/HqVBmGXtsg4W7azPlUJ2UWj8 f0rnwTzWgTWc8jLwGH1Khbm0t5dmdJWXmf+ejAjTqbOM99PJpP6VP87azB3NkkpWFKfD VRUz96GueQ/LZ4PRIuFIUvJ5zsR9dRqgtUzuOan6y7LOzalqniXoQ41tAI2J/++hSDng GyUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sopJkiB4zHI8sI+7YgK8PYwg2Z6aRO2mmKT1DHale7M=; b=SFJaxy6xzUz65yuxOLDWrhFvHLoDtrpVUUbxH1SETMrdCuIKBWkDP02oVpkuggohFr 7czghbmx1UBUKnkNckiSEGH0KxBwpZdZSdmQAco/aG7T/N560FmI4jdLXEa1I8GfHhHO gKE43ivJbCM7BmwOUtAtS3Oq5YJBwREtLG5jtsbv+BwpoogMrIEzU3+Yrp/sUGRy/Xvu 5tK5H+JLNJL2u9apPbtjV9G3hKg7cS4cRsKnSgXlfrAO3aw/axm3P9gBhMY0Shw2bl2P YmYdQpHjfaq/FEKkCHVnDT6F9H0VIJR5dEuR7ZoxDoh1L6pG4uz3RT/Pp6W+3ixNEwmx /yUA== X-Gm-Message-State: ALyK8tJkKOrLX9oUF+3KMyfZhtPh2Jvvyzv/GjqhuxSxGvEaSrm0Qsk+ByjfQd9+GRqPalbELwhMyZZwwxlD3w== X-Received: by 10.129.41.205 with SMTP id p196mr9188780ywp.64.1467376335166; Fri, 01 Jul 2016 05:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.125.134 with HTTP; Fri, 1 Jul 2016 05:32:14 -0700 (PDT) In-Reply-To: <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> References: <20160420225843.780.83631.idtracker@ietfa.amsl.com> <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> From: Spencer Dawkins at IETF Date: Fri, 1 Jul 2016 07:32:14 -0500 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1141461235a0420536922dca Archived-At: Cc: "tram-chairs@ietf.org" , "Pal Martinsen \(palmarti\)" , tram mailing list , Simon Perreault , The IESG , "draft-ietf-tram-stun-path-data@ietf.org" Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) 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, 01 Jul 2016 12:32:19 -0000 --001a1141461235a0420536922dca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Suresh, On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > > On 21 Apr 2016, at 00:58, Suresh Krishnan > wrote: > > > > Suresh Krishnan has entered the following ballot position for > > draft-ietf-tram-stun-path-data-03: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-path-data/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The RespTransCnt mechanism seems to be a bit fragile and error prone > > possibly leading to wrong conclusions on the client (please see my > > example below). If you agree with my assessment, it is probably useful = to > > evaluate whether the added complexity of this RespTransCnt mechanism is > > worth it for the potentially unreliable results it produces. > > > > Consider the following two cases (copy paste with a monospace font for > > better readability) > > > > Case 1: Upstream loss of first "re"transmission > > > > | Upstream loss | > > | Client Server | > > +-+-+-+-+-+-+-+-+-+ > > | 1 x | > > | | > > | 2 2,1 | > > | 2,1 | > > > > Case 2: Downstream loss of response to first "re"transmission with > > re-ordering > > > > | Downstream loss | > > | Client Server | > > +-+-+-+-+-+-+-+-+-+ > > | 1 1,2 | > > | x | > > | 2 2,1 | > > | 2,1 | > > > > How does the client differentiate between these two cases? > > > So the problem is that the first retransmit (second transmit) of the STUN > request arrives before the initial transmit and the response to the initi= al > request is lost downstream. > > This means not able to distinguish between upstream reordering and > downstream loss. I do not think adding complexity to solve this is worth > it. If ICE is using this, it is still valuable information. And once (s)R= TP > starts flowing the reordering will quickly be discovered by out of orer > packets. > > The draft needs to clearly spell out this limitation. > > My main worry now is the RTT calculation. Am I right if I assume that the > packets usually are delayed when reorder, and not magically put in front = of > the queue? If that is the case the RTT measurement should still be ok Could you take a look at -04, and let us know if the authors have successfully addressed this Discuss? Thanks! Spencer > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Section 5: IANA Considerations > > > > Shouldn't the range for this option be in the 0x8000-0xBFFF range inste= ad > > of the 0x8000-0xFFFF range as currently stated by the draft? > > Yes. We want it to be part of the IETF Review comprehension-optional rang= e. > > > > > Section 6: > > > > I think this requirement is backwards and needs to be reworded. > > > > "Unauthenticated STUN message MUST NOT include the PATH-CHARACTERISTIC > > attribute in order to prevent on-path attacker from influencing > > decision-making." > > > > Suggest rewording to. > > > > "The PATH-CHARACTERISTIC attribute MUST NOT be included in > > unauthenticated STUN messages in order to prevent an on-path attacker > > from influencing decision-making.=E2=80=9D > > > > +1 > > I also agree with Alissa about the vagueness of the attribute name. > > > > > +1 > > .-. > P=C3=A5l-Erik > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a1141461235a0420536922dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Suresh,

On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) <pal= marti@cisco.com> wrote:

> On 21 Apr 2016, at 00:58, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote:
>
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-tram-stun-path-data-03: Discuss
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-tram-stun-path-data/
>
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> The RespTransCnt mechanism seems to be a bit fragile and error prone > possibly leading to wrong conclusions on the client (please see my
> example below). If you agree with my assessment, it is probably useful= to
> evaluate whether the added complexity of this RespTransCnt mechanism i= s
> worth it for the potentially unreliable results it produces.
>
> Consider the following two cases (copy paste with a monospace font for=
> better readability)
>
> Case 1: Upstream loss of first "re"transmission
>
> |=C2=A0 Upstream loss=C2=A0 |
> |=C2=A0 Client=C2=A0 Server |
> +-+-+-+-+-+-+-+-+-+
> |=C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x=C2=A0 =C2=A0 |
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> |=C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02,1=C2=A0 |
> |=C2=A0 =C2=A0 2,1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>
> Case 2: Downstream loss of response to first "re"transmissio= n with
> re-ordering
>
> | Downstream loss |
> |=C2=A0 Client=C2=A0 Server |
> +-+-+-+-+-+-+-+-+-+
> |=C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01,2=C2=A0 |
> |=C2=A0 =C2=A0 x=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> |=C2=A0 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02,1=C2=A0 |
> |=C2=A0 =C2=A0 2,1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>
> How does the client differentiate between these two cases?
>
So the problem is that the first retransmit (second transmit) o= f the STUN request arrives before the initial transmit and the response to = the initial request is lost downstream.

This means not able to distinguish between upstream reordering and downstre= am loss. I do not think adding complexity to solve this is worth it. If ICE= is using this, it is still valuable information. And once (s)RTP starts fl= owing the reordering will quickly be discovered by out of orer packets.

The draft needs to clearly spell out this limitation.

My main worry now is the RTT calculation. Am I right if I assume that the p= ackets usually are delayed when reorder, and not magically put in front of = the queue? If that is the case the RTT measurement should still be ok

Could you take a look at -04, and let us know if= the authors have successfully addressed this Discuss?

=
Thanks!

Spencer
=C2=A0
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Section 5: IANA Considerations
>
> Shouldn't the range for this option be in the 0x8000-0xBFFF range = instead
> of the 0x8000-0xFFFF range as currently stated by the draft?

Yes. We want it to be part of the IETF Review comprehension-optional= range.

>
> Section 6:
>
> I think this requirement is backwards and needs to be reworded.
>
> "Unauthenticated STUN message MUST NOT include the PATH-CHARACTER= ISTIC
> attribute in order to prevent on-path attacker from influencing
> decision-making."
>
> Suggest rewording to.
>
> "The PATH-CHARACTERISTIC attribute MUST NOT be included in
> unauthenticated STUN messages in order to prevent an on-path attacker<= br> > from influencing decision-making.=E2=80=9D
>

+1
> I also agree with Alissa about the vagueness of the a= ttribute name.
>
>
+1

.-.
P=C3=A5l-Erik
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

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

--001a1141461235a0420536922dca-- From nobody Tue Jul 5 09:28:27 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 EB96F12D635; Tue, 5 Jul 2016 09:27:57 -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 SXP8wdB6a9VF; Tue, 5 Jul 2016 09:27:56 -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 AC31C12D640; Tue, 5 Jul 2016 09:27:49 -0700 (PDT) Received: from [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3] (unknown [IPv6:2601:648:8380:d0:b000:c523:5e3:37d3]) (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 57672207C7; Tue, 5 Jul 2016 18:27:47 +0200 (CEST) To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> From: Marc Petit-Huguenin Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Date: Tue, 5 Jul 2016 09:27:38 -0700 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: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd" Archived-At: Subject: Re: [tram] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 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: Tue, 05 Jul 2016 16:27:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd Content-Type: multipart/mixed; boundary="kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i" From: Marc Petit-Huguenin To: Magnus Westerlund , IETF AVTCore WG , "tram@ietf.org" , ice@ietf.org, "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" Message-ID: <4da07aaf-6340-e866-801e-1c6bd78d0d2e@petit-huguenin.org> Subject: Re: [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 References: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> In-Reply-To: <10a73efe-2e50-77ed-e78f-298d388efb47@ericsson.com> --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Magnus, We just published version -10. See below for some comments. On 06/28/2016 07:35 AM, Magnus Westerlund wrote: > Authors and WGs, >=20 > In my review for the publication writeup I did spot some issues in the = draft. Please consider the following issues: >=20 > 1. Abstract: With the addition of the ZRTP the abstract should benefit = from being updated. The ZRTP protocol being possible to multiplex is miss= ing as well as that there are now 4 issues. Fixed. >=20 > 2. Abstract contains [ref] to RFC 5764. This is an ID nit. Fixed. >=20 > 3. Section 1. The introduction is not explicitly saying that it updates= RFC 5764. I think that can be put as a sentence after: >=20 > This is achieved by > modifying the IANA registries with instructions for coordination > between the protocols at risk. We incorporated this in that sentence and also added it into the abstract= =2E >=20 > 4. Reference ID-nits: >=20 > =3D=3D Outdated reference: A later version (-31) exists of > draft-ietf-mmusic-sdp-bundle-negotiation-23 Fixed. >=20 > 5. Section 2: >=20 > ID-nits complains about the modified boilerplate for the RFC2119 text. = First of all one usually don't cut down the list to only the used ones. T= he requirement on all caps ones I am very divided about. I do have a pref= erence for unmodified boilerplate, this as I otherwise have to explain in= the write-up the ID-nit. Fixed. >=20 > 6. Section 6: >=20 > In order to prevent future documents from assigning values from the > unused range to a new protocol, this document modifies the RFC 5764 > demultiplexing algorithm to properly account for TURN channels by > allocating the values from 64 to 79 for this purpose. >=20 > I think this text fails to be explicit about that this restricts the TU= RN Channel space to a more limited set of possible channels when the TURN= client does the channel binding request. Thus affecting the TURN channel= allocation algorithm in the client implementations, at least when used i= n combination of muxing. Fixed. >=20 > Based on this and the fact that this specification changes the IANA reg= istrations performed by RFC5766, I think this document to have "Updates" = for RFC5766 also. So please add that in header, abstract and introduction= =2E Based on our understanding and looking at other RFCs, just updating an IA= NA registry does not imply a update to the core specification, so we did = not made that change. >=20 > 7. Updates RFC5389: >=20 > Looking at the impact also on the STUN protocol I would also think that= this requires and "Updates" also for RFC 5389. >=20 Based on the argument above, we do not think that this warrants an "Updat= es" status. >=20 > 8. Section 10.3: >=20 > The IANA registry name is not the correct one. The IANA page says that = the registry name is: >=20 > Traversal Using Relays around NAT (TURN) Channel Numbers > http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#t= urn-channel >=20 > Please update. Fixed. >=20 > 9. Section 12.2: >=20 > The reference to ZRTP [RFC6189] is likely in the wrong category, at the= same time moving this to a normative one creates a downref. I guess it o= ne that has to be accepted in this case. I suggest that you move it to th= e normative references. We are keeping it informative for now, but we will forward the discussion= with the AD to the mailing-list as requested. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --kQwxn8JHF4Q5da5XcDALrpaBMEiMIHS9i-- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd 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 iQIcBAEBCAAGBQJXe9/6AAoJECnERZXWan7E8JwQAMkUHV3c2Q1MK8TWsMTs/q5q r4eb5gLyaoxSV6x9ufYs42lJ3j6hr7t3GabA5ANFFI1tOx+eN3iMwTgH/2ylugoE fnyGgbal/vZ6pEj01goPALATYSk0m6KtFwS7+QPVvNoEan6oHbLA5iH5oc73FY8x B5cBFq89Do1ATeTKEX0a0FeSZmE5r4N4xrsjZpnMBXt1Unm+1SG0Ku24PJHCbEWN Tx68bmLODh+65pTVUzewDOo3urSlwjxStVqf/jQHh4fx/tDnxGH8c8cGMSW18jl/ PuanYrAv7pg0rMdhQMkeEs5Y6UaInE3B3zADdXEET0QSw6U4oiXVvzP8GH/QC8Ml z4zNDEcDn+wlPMWcmwOhrVtqbuUAcdHlMB4oynOzcVZpKciXvIpDlKKWJXdo9ERU l4/GCog8yq0HgQ2Mv5mGLHO3x5CIs+zgKFvAz6uWK3Qq4i12Wgxga+aJt3OFgwAn qvaMVuAr4ajUkYzF8iHJpXqUD15E48MvYHm4ps6ExtHhXcWqBUv8FxxGixTDZWAX lj5K6jpYdSddwY6nMc3BMS1XZrCX2TBmTaCm9MZWQjqRao0IEdVehfAh4+D1eeUb nUgIzFjjyQ73kZ2FHkyXBm6FYxAuXSI5MU9H1kjh78KDvUlGTStjb0azCrBNWG0c 0hmVb/kE0WTHDCIYklcY =qxAO -----END PGP SIGNATURE----- --OEdkAEJ0HRTBEXDrfGK5H20FvaBIE4dwd-- From nobody Tue Jul 5 19:46:14 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 0947112D52C; Tue, 5 Jul 2016 19:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 gZ2BDeFkkA9Y; Tue, 5 Jul 2016 19:46:05 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4870112D182; Tue, 5 Jul 2016 19:46:05 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-6b-577c70aae387 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5B.88.03614.BA07C775; Wed, 6 Jul 2016 04:44:59 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0294.000; Tue, 5 Jul 2016 22:46:04 -0400 From: Suresh Krishnan To: Spencer Dawkins at IETF Thread-Topic: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) Thread-Index: AQHRm1g0d9UWRAAejUmRj5PiQ0LRKQ== Date: Wed, 6 Jul 2016 02:46:03 +0000 Message-ID: References: <20160420225843.780.83631.idtracker@ietfa.amsl.com> <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyuXRPoO7qgppwg+tnBC269/1kspjxZyKz xfvrK1kslk3Zw2xx/UqoxfKfK9ksPqy9wObA7jHl90ZWj52z7rJ7LFnyk8nj35ynzAEsUVw2 Kak5mWWpRfp2CVwZ6+dPYCloYKnYtvYUawPjHOYuRk4OCQETiTv3nrFB2GISF+6tB7OFBI4y Stx8k9nFyAVkL2OU6Ht9HyzBBtSwYednJhBbRMBaYktfJxtIEbPAUiaJTdv7gRIcHMICBRId J6Ihagol5jedZIGw9STeXFjHCmKzCKhIXDnSB3YEr4CvxL+Wn6wQy3YySsy8+B1sGSPQRd9P rQFbxiwgLnHryXwmiEsFJJbsOQ/1gajEy8f/WCFsJYmPv+ezQ9TrSCzY/YkNwtaWWLbwNdQy QYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVI0dpcUFObrqR4SZGYEwdk2Bz3MG4t9fzEKMA B6MSD++Cr9XhQqyJZcWVuYcYJTiYlUR4i3JrwoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz6r9U DBcSSE8sSc1OTS1ILYLJMnFwSjUwFnGLPF73M7Dz2tX8165Ld6lmrJkg/zb2U0Rkvs5dXsGX rQq2ehpdk/Z/6Q3wcP9Ynep2RXzhlv3bu+98rI67mGyvsy/+f27N6ZL7Jbnv48vCbZZuFDhc mypqsd7kq8Xbzm4nw4/C4bum7hRIynkUZSOncSD6snxJ6owFLlNlQhOuJck5dVkrsRRnJBpq MRcVJwIAfQmDSKUCAAA= Archived-At: Cc: "tram-chairs@ietf.org" , "Pal Martinsen \(palmarti\)" , tram mailing list , Simon Perreault , The IESG , "draft-ietf-tram-stun-path-data@ietf.org" Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) 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: Wed, 06 Jul 2016 02:46:07 -0000 Hi Spencer,=0A= =0A= Spencer Dawkins at IETF wrote:=0A= > Hi, Suresh,=0A= >=0A= > On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) > wrote:=0A= > ...=0A= >=0A= > Could you take a look at -04, and let us know if the authors have=0A= > successfully addressed this Discuss?=0A= =0A= I looked over the new version of the draft and it nicely addresses the issu= es =0A= I raised. I have cleared.=0A= =0A= Regards=0A= Suresh=0A= =0A= From nobody Tue Jul 5 19:53:13 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 4518712D182; Tue, 5 Jul 2016 19:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 BVT-0wiPbiMR; Tue, 5 Jul 2016 19:53:09 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 855F512D155; Tue, 5 Jul 2016 19:53:09 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so77384353ywb.2; Tue, 05 Jul 2016 19:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ErSQIt/ZbKZZrwO6sltroc82CTIgE+Smd4S7J8rEb8I=; b=WbxNx7VV4eAXYuRZLNS+9En44H0w9gCXaiyFkrUKtxO4LcI4BNZPLcDvvTCaQoFW9J ylaEwNrlFKQEZnTGrqyMFpu+nKUz6IcQkFuj+0ZSlYR3wowY06j9Y/k2pAo4nRGO2WZw Ay2E0Apg0Ze1s+IRxmzWWmXBVrysUSyGHeBj7S4MeGRgFahZ3cY0aSbX1CL6eiVxOsba 3FVtcKRCbalJ7iE9K8d9XAimt8zCrvnbZEtlJSNHdk9Aw3gmCdQ01iUfu2U64yTB8HxX Y4cO+u+9Pm49i07w5HHS/UVTOj7A5iWIRe9c/bhz6DVHwjbJOSvEQPfs9aTI2x4qsv6K 9sqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ErSQIt/ZbKZZrwO6sltroc82CTIgE+Smd4S7J8rEb8I=; b=hLpBa6GLOwJD9YUVgNIggCVr50hvKIJ+VFkI9A5Bn2zKfdjlGqzAqgaImXYVKnoTsE dm1LDu5z+oCddsDmJnshlmnIOM7MGJwbGYz8rwq+9Ah6xGksHGIe+GbRv7gN6JgAlHqQ W1ISVp+B5z0gODVHLD1/+yY325tY68yiJAQeFQQFjm5vKCIdxS/lLnDsz5xiPlSLh6Nx hS/0nTS9aq9HmRBbM0XOPvaZXqR8QXCZ+JhmFJ3LTP5nCuMEVQdiG58NYccKMo2QWhOl FNW+YYs6WmKJDkim4DvI7D8AoDLqWiQWzHJAWljxelSnY/XUO5unsR03voy3/Rg0ewiK aulA== X-Gm-Message-State: ALyK8tIxbFnjW6SBU4bCc+be29ixSGe+/DGUMMcrFrEAOu6M+ubZ/MOwiBOURFPntEgocRXjtLrfRy26okYc5g== X-Received: by 10.37.34.197 with SMTP id i188mr12282926ybi.5.1467773588792; Tue, 05 Jul 2016 19:53:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.125.134 with HTTP; Tue, 5 Jul 2016 19:53:08 -0700 (PDT) In-Reply-To: References: <20160420225843.780.83631.idtracker@ietfa.amsl.com> <86EAFAE4-CB79-4E4B-8117-B7ED21B55048@cisco.com> From: Spencer Dawkins at IETF Date: Tue, 5 Jul 2016 21:53:08 -0500 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a114327f25eea800536eeabb8 Archived-At: Cc: "tram-chairs@ietf.org" , "Pal Martinsen \(palmarti\)" , tram mailing list , Simon Perreault , The IESG , "draft-ietf-tram-stun-path-data@ietf.org" Subject: Re: [tram] Suresh Krishnan's Discuss on draft-ietf-tram-stun-path-data-03: (with DISCUSS and COMMENT) 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: Wed, 06 Jul 2016 02:53:11 -0000 --001a114327f25eea800536eeabb8 Content-Type: text/plain; charset=UTF-8 Hi, Suresh, On Tue, Jul 5, 2016 at 9:46 PM, Suresh Krishnan < suresh.krishnan@ericsson.com> wrote: > Hi Spencer, > > Spencer Dawkins at IETF wrote: > > Hi, Suresh, > > > > On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com > > > wrote: > > ... > > > > Could you take a look at -04, and let us know if the authors have > > successfully addressed this Discuss? > > I looked over the new version of the draft and it nicely addresses the > issues > I raised. I have cleared. Thanks! I'll read carefully through the revised draft before sending the Approved: e-mail, of course. Spencer --001a114327f25eea800536eeabb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Suresh,

On Tue, Jul 5, 2016 at 9:46 PM, Suresh Krishnan <sur= esh.krishnan@ericsson.com> wrote:
Hi Spencer,

Spencer Dawkins at IETF wrote:
> Hi, Suresh,
>
> On Thu, Apr 21, 2016 at 2:16 AM, Pal Martinsen (palmarti) <palmarti@cisco.com
> <mailto:palmarti@cisco= .com>> wrote:
> ...
>
> Could you take a look at -04, and let us know if the authors have
> successfully addressed this Discuss?

I looked over the new version of the draft and it nicely addresses t= he issues
I raised. I have cleared.

Thanks! I'll = read carefully through the revised draft before sending the Approved: e-mai= l, of course.

Spencer=C2=A0
--001a114327f25eea800536eeabb8-- From nobody Wed Jul 6 01:47:41 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 657FD12D0FB; Wed, 6 Jul 2016 01:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qFpXJPbtanj1; Wed, 6 Jul 2016 01:47:27 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F54C12D0A4; Wed, 6 Jul 2016 01:47:26 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ea-577cc59ce276 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E9.00.18043.C95CC775; Wed, 6 Jul 2016 10:47:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.294.0; Wed, 6 Jul 2016 10:47:23 +0200 To: IETF AVTCore WG , "tram@ietf.org" , , "tls@ietf.org" , "mmusic (E-mail)" , "draft-ietf-avtcore-rfc5764-mux-fixes@ietf.org" References: From: Magnus Westerlund Message-ID: Date: Wed, 6 Jul 2016 10:47:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM2K7lu6cozXhBu86tCxe9qxktzjwcSqz xbcLtRZTlz9msfh0vovR4sPaC2wObB5LlvxkCmCM4rJJSc3JLEst0rdL4Mp4vWQLa8Fa4Yq5 X7uZGxhv83cxcnJICJhIPFvxgR3CFpO4cG89WxcjF4eQwBFGibcL1kA5yxglbvX9Aari4BAW CJE4vj8JJC4i8I9R4uPGmywg3UIC9hK/djYyg9hsAhYSN380soHYvEDxnZMmgNksAioSE1cf AbNFBWIkGm8fZoeoEZQ4OfMJ2BxOAQeJ4z83sIDsYgbqfbC1DCTMLCAv0bx1NjPEKm2JhqYO 1gmMArOQdM9C6JiFpGMBI/MqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMCAPbjlt9UOxoPP HQ8xCnAwKvHwLvhaHS7EmlhWXJl7iFGCg1lJhFfwUE24EG9KYmVValF+fFFpTmrxIUZpDhYl cV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsbk35xzJsUsUmXvqnhYwLbwa8nSCSl/ebr+cWSG nXkre/3qfvc7sQlOm4/pzJLdtszO+Lzdttccrg7LFn6NZTb/MDcwtXun2uyIsBlsLHHra8JV f5iaZlY+iGZ4sYsnBhhnirbz9BsbefaqOGhfYmVl6/h0Lu7c7SNxN344TA5++HvZJ/uV35VY ijMSDbWYi4oTAU6aP69UAgAA Archived-At: Subject: Re: [tram] [MMUSIC] Confirmation call on draft-ietf-avtcore-rfc5764-mux-fixes-09 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: Wed, 06 Jul 2016 08:47:29 -0000 Hi, The call has now ended. The authors have updated the document to address the issues I raised. The writeup has been uploaded and I have requested publication. If anyone has late feedback, please provide it. We will address it at the latest at the end of the IETF last call, most likely earlier. Cheers Magnus Westerlund Chair AVTCORE WG and Document Shepherd. Den 2016-06-28 kl. 15:04, skrev Magnus Westerlund: > WGs, > > I as WG chair earlier made a mistake in failing to include the relevant > WGs in our previous WG last call. Thus I would like to make a one week > confirmation call on the content of > draft-ietf-avtcore-rfc5764-mux-fixes-09 prior to publication request. > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > > TRAM WG: Please check that you are okay with the restrictions and > updates to the TURN channel allocations as well as STUN Method > restrictions. > > TLS WG: I believe you are satisfied with the impact on the TLS IANA > registry after previous discussions, but you are welcome to confirm this. > > ICE: For your information as this impacts protocol mechanism your are > dependent on. > > MMUSIC: For your information due to some notes in regards to BUNDLE and > RFC7345. > > Please provide any feedback by 5th of July. > > cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jul 6 08:10:48 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 D296112D5BD for ; Wed, 6 Jul 2016 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.201 X-Spam-Level: X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 aDJkMV__X-GY for ; Wed, 6 Jul 2016 08:10:24 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7726812D578 for ; Wed, 6 Jul 2016 08:09:58 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-8a-577d1f44ffe2 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5E.FD.18043.44F1D775; Wed, 6 Jul 2016 17:09:56 +0200 (CEST) Received: from [131.160.126.209] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Wed, 6 Jul 2016 17:09:39 +0200 To: "tram@ietf.org" From: Gonzalo Camarillo Message-ID: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> Date: Wed, 6 Jul 2016 18:09:39 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM2K7nK6LfG24wecVOhazH79jtfiw9gKb A5PHkiU/mTymtlxlCWCK4rJJSc3JLEst0rdL4Mo4vP4hc0FNRX/XVvYGxtguRk4OCQETiccN n1kgbDGJC/fWs3UxcnEICRxhlNhxcyYrhLOGUeLj3z52kCoRAWWJiSeeM4PYzALqEg9+9LGC 2GwCFhJbbt0HmyQMVLP6+32mLkYODl4Be4n/9wVAwiwCKhJn59xjArFFBWIkGm8fBhvJKyAo cXLmExaQcmYBTYn1u/QhpstLbH87B2yTkIC2xPJnLSwTGPlnIemYhdAxC0nHAkbmVYyixanF xbnpRkZ6qUWZycXF+Xl6eaklmxiBYXdwy2+rHYwHnzseYhTgYFTi4V3wtTpciDWxrLgy9xCj BAezkgjvFOnacCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTByc Ug2Mc9PPr7q8clXi0t18eqfWLd+99y5z/7XgPTK/lFwOO083fbhbI0H9q6F81G9Gwar0SRzb A4TXHNTc2vhw1abMvdMnmaYd0Jl52cP5kvhC3ccm6RNWvDvZPqOmZedthomNTarfHpqohgc9 OuwQqP7vXKWPi7yIT/SnzLmvs3cXnGu1FRbataXTVYmlOCPRUIu5qDgRAAF8mG43AgAA Archived-At: Cc: Simon Perreault Subject: [tram] Agenda requests for Berlin 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: Wed, 06 Jul 2016 15:10:38 -0000 Folks, if you have an agenda request for our session in Berlin, please let us (the chairs) know. Thanks, Gonzalo From nobody Wed Jul 6 08:14:07 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 37EA712D0CB for ; Wed, 6 Jul 2016 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9RooFsu5mmQS for ; Wed, 6 Jul 2016 08:14:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6044712D0EF for ; Wed, 6 Jul 2016 08:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=509; q=dns/txt; s=iport; t=1467818036; x=1469027636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FPebmrkbBhYddq4H9VANKGmKvSKufe8YWB+0dHf3S28=; b=dY+akrjHcnVxSWy5ngP+mZlek2csMFoGWLVKoJF/nu84DBWdxOdaMvvH SOg3s4ir0c/zm37hzGLh5MKgUSCry4EXrPo27UjaajlRzkjmfh6ZlbX7w SQuo22YOabkc3Oek1umDigFK7Xxs6626t8xhtO/D+Yea1blvhHG8xzqd8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgAZH31X/5hdJa1dgz5WfAa5EYF3I?= =?us-ascii?q?oV2AoEpOBQBAQEBAQEBZSeETAEBBAEBATg0CwULAgEIGB4QJwslAgQOBYgoCA6?= =?us-ascii?q?8IQEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhieBeIJVhECFWwEEmRMBjkaBVAEVh?= =?us-ascii?q?FaIapAJAR42g3Buh3N/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,319,1464652800"; d="scan'208";a="126422725" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2016 15:13:55 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u66FDtFj029475 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jul 2016 15:13:55 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 6 Jul 2016 10:13:54 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 6 Jul 2016 10:13:54 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Gonzalo Camarillo Thread-Topic: [tram] Agenda requests for Berlin Thread-Index: AQHR15iciqJYMBN5AEm0QsRzXoMH26AL1qUA Date: Wed, 6 Jul 2016 15:13:54 +0000 Message-ID: <274BBBF9-2A68-4DF3-ACE9-26523151472D@cisco.com> References: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> In-Reply-To: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.217.68] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Agenda requests for Berlin 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: Wed, 06 Jul 2016 15:14:06 -0000 We would like 30 minutes to present the changes made over the past few revi= sions of STUNbis. Thanks, Gonzalo > On Jul 6, 2016, at 11:09 AM, Gonzalo Camarillo wrote: >=20 > Folks, >=20 > if you have an agenda request for our session in Berlin, please let us > (the chairs) know. >=20 > Thanks, >=20 > Gonzalo >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Jul 6 12:12:07 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 9D4AF12B040 for ; Wed, 6 Jul 2016 12:12:05 -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 UwUVyl23jPL1 for ; Wed, 6 Jul 2016 12:12:01 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 DD43B12D1B8 for ; Wed, 6 Jul 2016 12:12:00 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id m2so121615216qtd.1 for ; Wed, 06 Jul 2016 12:12:00 -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=2PQLsN4EkUtfTINU+4a50p5WLYAE7rEZWg4HK1k02N0=; b=FLPvII2TtGFb6HbgstuJ0rVaukIpJ1gO7OIuo7s2E8V3/ru2EjYJT7Cvk5pstZ/c1x 6uHyfnDv/V0/RIY0lrY2H3MK7auQO6gBrvFwviuoFb/BNGuvGkO3qRIPuJ27aMpkHdJ2 Z4xKTAQ/MD02sJsDf45D4MG2QvzrDVLUv8F8cJ5AU0P8DnomiDneskfzHFcYp3t5U3xC jJzKXaYptG8z53F7yNbYHOsh31wphVJFgHclIYmHzgQ66cfTqFOBBB5/K9oBbErBf/SB dFaSx/836p/DC2e07DeX4oF2pncBYoEhyTC1ZpWWpEFMctnewH4QSPbLGqHUM29vGfCa g34g== 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=2PQLsN4EkUtfTINU+4a50p5WLYAE7rEZWg4HK1k02N0=; b=Kk9PM/HMWz7t93M2o8CY0Tv3IcPmyljn37FE3X8CTo0O4ISHW/3gQvkqBcKKfzTyfI T6+Bnlk1h/+yHGLAPzTH9T400RrrxURrihJQBeNV8Mlk77qv0BAHm+08Io0Bc+Ft/v5f 7dR2/eItH8RbyvMUevQw74aSf04jOUwR6Rfz88ZTZ+2b/E5iPr4RYLghs/yYzvwba/rb D4ak/a9msKNKNZD4SrrkOHpGI6UOYykJVNBTqh145u+3uRIAdXBnH0X46pAOq1xa7JrU u4SoWKe59QForsb1dIOyEm6DVTThR0UUreULyMqO7cj7y2uzpVEscm6z/+pCx7qotqxb 7lMg== X-Gm-Message-State: ALyK8tIOb/MrVMydUbf963BjCG9RTeWSoFOlWWFuwqGPZUOjnfNOS+fIZp6wq19FCwL4D6t+DOXZydw1x1G0/Oeigc1ZbHClksvHK69+nHrbSufR3d0DPyhetgunNMQM3nxHS0uY2jr0ioFEp0N3TskiT8a/Ar1Qj7qLIYbTjDQ= X-Received: by 10.200.48.147 with SMTP id v19mr38917399qta.68.1467832319912; Wed, 06 Jul 2016 12:11:59 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:30d5:7618:5aec:49e1]) by smtp.gmail.com with ESMTPSA id g10sm37392qtb.15.2016.07.06.12.11.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Jul 2016 12:11:58 -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> <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.com> From: Simon Perreault Message-ID: <4c10b1c5-f0bc-197f-6fa9-cd3e4f212914@jive.com> Date: Wed, 6 Jul 2016 15:12:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <404cc88c-0dc6-3cbf-f6bb-3cde6cb012a3@jive.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: Wed, 06 Jul 2016 19:12:05 -0000 Editors of stunbis, The result of this consensus call is that there is no consensus to change the current MTU rules, therefore they shall remain unchanged. Thanks, Simon Le 2016-05-27 ą 15:46, Simon Perreault a écrit : > 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 Wed Jul 6 23:06:52 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 365F712D0E0 for ; Wed, 6 Jul 2016 23:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 3dOnat1YBAQU for ; Wed, 6 Jul 2016 23:06:49 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8EE12D0B5 for ; Wed, 6 Jul 2016 23:06:49 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-e3-577df17641b4 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.06.12516.671FD775; Thu, 7 Jul 2016 08:06:47 +0200 (CEST) Received: from [131.160.50.156] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.294.0; Thu, 7 Jul 2016 08:06:45 +0200 To: From: Gonzalo Camarillo Message-ID: <3d8524a8-95bb-d63e-0c97-9e56140fde9b@ericsson.com> Date: Thu, 7 Jul 2016 09:06:45 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM2K7gW75x9pwg4nHRSyuXwm1+LD2ApsD k8eSJT+ZPP7NecocwBTFZZOSmpNZllqkb5fAlfG79zxjwUSWik275jE1MK5k7mLk4JAQMJE4 Pzmyi5ETyBSTuHBvPVsXIxeHkMARRomZ7YcZQRJCAqsZJb4v8wSxRQSEJeYevMsCYjMLaEqc PPUYrIZNwEJiy637YHFhASeJTfPeMIHYvAL2EpOO3mQDsVkEVCTuz13CDGKLCsRINN4+zA5R IyhxcuYTFpB7QGau36UPMV5eYvvbOcwQJ2hLLH/WwjKBkX8Wko5ZCB2zkHQsYGRexShanFpc nJtuZKyXWpSZXFycn6eXl1qyiREYdge3/Nbdwbj6teMhRgEORiUe3oT62nAh1sSy4srcQ4wS HMxKIrxNH4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUa GK1eLb1l/+1qaPu8ewsZszYtb7VefrhPdq7am5j6hjgGTrNtB2tWW3z43f3oNM9h5c0VUXa7 elnu3VlZ57rsavrvCbf5FeovCy1Zwub/ec2BTV/yUl+78/Q8ThQ7GlrBnnG7caOKzF+pYgGL Mjct3g5e8bv/4ryy70mKbH7HEScRMV9E/72UthJLcUaioRZzUXEiAGoYDng3AgAA Archived-At: Cc: Simon Perreault Subject: [tram] Dedicated reviewers needed for draft-ietf-tram-stun-pmtud 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: Thu, 07 Jul 2016 06:06:51 -0000 Folks, we would like to get the following draft in a good-enough shape so that we can start its WGLC in the near future. For that, we need at least two dedicated reviewers: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ If you would like to volunteer to review this draft, please let the chairs know. We are after a general review of the draft. In addition, we would like the dedicated reviewers to provide input on the two proposed Probing Mechanisms (Simple and Complete). Thanks, Gonzalo From nobody Wed Jul 6 23:13:32 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 CAB2112D50E for ; Wed, 6 Jul 2016 23:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 l4XW0v4gc7rd for ; Wed, 6 Jul 2016 23:13:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD54812D0E0 for ; Wed, 6 Jul 2016 23:13:28 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-89-577df3067756 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C7.D8.18043.603FD775; Thu, 7 Jul 2016 08:13:26 +0200 (CEST) Received: from [131.160.50.156] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.294.0; Thu, 7 Jul 2016 08:13:25 +0200 To: "Gonzalo Salgueiro (gsalguei)" References: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> <274BBBF9-2A68-4DF3-ACE9-26523151472D@cisco.com> From: Gonzalo Camarillo Message-ID: Date: Thu, 7 Jul 2016 09:13:26 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <274BBBF9-2A68-4DF3-ACE9-26523151472D@cisco.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM2K7ri7b59pwg7W3lS3mTvGzmP34HavF h7UX2ByYPab83sjqsWTJTyaPqS1XWQKYo7hsUlJzMstSi/TtErgyfnxcxlLwiKViZ2NhA+NT 5i5GTg4JAROJR1MXsELYYhIX7q1n62Lk4hASOMIocenYZlYIZzWjxMubX4EyHBzCAnoSp79U gjSICJhL7PndwgZiCwkUSdx+P4sdxGYW8JBYOfcKE4jNJmAhseXWfRYQm1fAXuLFkk4WkDEs AioSn/vFQMKiAjESjbcPs0OUCEqcnPkErJxTwFbi0LXXzBAjDSSOLJrDCmHLS2x/O4cZYq22 xPJnLSwTGAVnIWmfhaRlFpKWBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECg/fglt9W OxgPPnc8xCjAwajEw5tQXxsuxJpYVlyZe4hRgoNZSYT3zUegEG9KYmVValF+fFFpTmrxIUZp DhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBkbjWXfvp7dzLj9b8u41W4fauu/u/UkSZiEx +0surBXR2H3lsuTNnd9EJ0fFr9X7+/53PetDdmOGK4cEsrMPF0WffWJy6mz0hc9n7LtyHBTC nGatr+1ad2jm7Pnan/rTOI6rJIboXbJyfWqbe/z3s4x9RQsbRY1+6ixreXjun81Zi9er84v2 1c1UYinOSDTUYi4qTgQACI8b2VoCAAA= Archived-At: Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Agenda requests for Berlin 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: Thu, 07 Jul 2016 06:13:31 -0000 Noted. Thanks. Gonzalo On 06/07/2016 6:13 PM, Gonzalo Salgueiro (gsalguei) wrote: > We would like 30 minutes to present the changes made over the past few revisions of STUNbis. > > Thanks, > > Gonzalo > > >> On Jul 6, 2016, at 11:09 AM, Gonzalo Camarillo wrote: >> >> Folks, >> >> if you have an agenda request for our session in Berlin, please let us >> (the chairs) know. >> >> Thanks, >> >> Gonzalo >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > From nobody Wed Jul 6 23:48:10 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 84FD412D0B3 for ; Wed, 6 Jul 2016 23:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 42w0xYPc-qDT for ; Wed, 6 Jul 2016 23:48:07 -0700 (PDT) Received: from tsinghua.org.cn (mail.tsinghua.org.cn [211.151.65.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3269E12D08F for ; Wed, 6 Jul 2016 23:48:05 -0700 (PDT) Received: from wangaj (unknown [219.142.69.75]) by app1 (Coremail) with SMTP id Z0GX06Cbzwf3831XkoxZBg==.45219S2; Thu, 07 Jul 2016 14:17:41 +0800 (CST) From: "Aijun Wang" To: "'Gonzalo Camarillo'" , References: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> In-Reply-To: Date: Thu, 7 Jul 2016 14:47:33 +0800 Message-ID: <016501d1d81b$78d64540$6a82cfc0$@org.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdHXmJqlHVURYSinSnm939euM4U4TQAYlGfwAAgT8/A= Content-Language: zh-cn X-CM-TRANSID: Z0GX06Cbzwf3831XkoxZBg==.45219S2 X-Coremail-Antispam: 1U3129KBjvJXoW7Gry3GFyDKFy8Zw15XFyxZrb_yoW8Jr18pF W8G3yFkFW5Jr18G3y8Xr1xXa1Fv3sYkrZrXFn8tF18WFyDAFyvgr18KrW5Ar9rZr98JryU X3Wj9r13W3W5ZrJanT9S1TB71UUUUUUv73VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjBvb7 Iv0xC_Jr1l5I8CrVACY4xI64kE6c02F40Ex7xfM7kC6x804xWl14x267AKxVWUJVW8JwAF xVCF77xC6IxKo4kEV4yl1I0EscIYIxCEI4klw4CSwwAv7VCjz48v1sIEY20_GF1lx4CE17 CEb7AF67AKxVWUXVWUAjIFyTuYvjfUojjgDUUUU Archived-At: Cc: 'Simon Perreault' Subject: Re: [tram] Agenda requests for Berlin 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: Thu, 07 Jul 2016 06:48:09 -0000 Hi, Gonzalo and Simon: I would like to apply one time slot to present our solution to = host-to-host communication, which is named as OARS(Operator-Assisted-Relay-Service), = one alternative/additional solution that compared with TURN. The corresponding draft has been submitted to the IETF repository, = please refer to it according to the following links: https://datatracker.ietf.org/doc/draft-wang-tram-oars/ The information for the presentation is as the following: Title: OARS(Operator-Assisted-Relay-Service) Presenter: Aijun Wang(China Telecom) Duration: 5-10minutes Thanks in advance. Best Regards. Aijun Wang China Telecom Beijing Research Institute Network R&D and Operation = Support Department -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: tram [mailto:tram-bounces@ietf.org] =B4=FA=B1=ED = Gonzalo Camarillo =B7=A2=CB=CD=CA=B1=BC=E4: 2016=C4=EA7=D4=C26=C8=D5 23:10 =CA=D5=BC=FE=C8=CB: tram@ietf.org =B3=AD=CB=CD: Simon Perreault =D6=F7=CC=E2: [tram] Agenda requests for Berlin Folks, if you have an agenda request for our session in Berlin, please let us = (the chairs) know. Thanks, Gonzalo _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Fri Jul 8 05:29:09 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 D545E12B062 for ; Fri, 8 Jul 2016 05:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 XEdZ3jt-HzsR for ; Fri, 8 Jul 2016 05:29:06 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DEB12B031 for ; Fri, 8 Jul 2016 05:29:05 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-29-577f9c8f057b Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.06.12926.F8C9F775; Fri, 8 Jul 2016 14:29:03 +0200 (CEST) Received: from [131.160.50.156] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.294.0; Fri, 8 Jul 2016 14:29:03 +0200 To: Aijun Wang , References: <162341d1-08e0-3426-b536-b308977707b2@ericsson.com> <016501d1d81b$78d64540$6a82cfc0$@org.cn> From: Gonzalo Camarillo Message-ID: <84db660c-4930-cb39-e8e6-e1ef79bea3a8@ericsson.com> Date: Fri, 8 Jul 2016 15:29:03 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <016501d1d81b$78d64540$6a82cfc0$@org.cn> Content-Type: text/plain; charset="gbk" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM2K7gW7/nPpwg9vPjC1mP37HavFh7QU2 iy2df9gdmD2WLPnJ5DG15SqLx5rmuWwBzFFcNimpOZllqUX6dglcGY+W72Ep2M1dcWHFRaYG xoWcXYycHBICJhKL/q9jhLDFJC7cW8/WxcjFISRwhFFiwupbzBDOakaJQ/dvs3cxcnAIC+hJ nP5SCdIgImAtseTSebCwkECWxPz57CBhZgFNibW777OB2GwCFhJbbt1nAbF5Bewltu2dCBZn EVCR+HlhI5gtKhAj0Xj7MDtEjaDEyZlPwOo5BUwlNh79xwIxU13i+5nfTBC2vETz1tnMILaQ gLbE8mctLBMYBWchaZ+FpGUWkpYFjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQID+OCW 36o7GC+/cTzEKMDBqMTDm+BYHy7EmlhWXJl7iFGCg1lJhLdiOlCINyWxsiq1KD++qDQntfgQ ozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QDY0pQMsPmnct9M3sKcqQWaQb3nfb4pj9h IcN3LsUN2wp4vnm9MhB2Ct1x6MzNgnkFiQcV1YSZjb1m7NyR2bdu1nTxQPZp3Z05U5hdy165 /dmbGPDjlqXYP+2JkS9VErfuZHWtLI2342BlKLwvsfn8Ng9WJeb2mr1vpnWeeXBD4HnNiaCQ k0LOSizFGYmGWsxFxYkALIP8jFwCAAA= Archived-At: Cc: 'Simon Perreault' Subject: Re: [tram] Agenda requests for Berlin 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, 08 Jul 2016 12:29:08 -0000 OK. You can find the draft agenda here: https://www.ietf.org/proceedings/96/agenda/agenda-96-tram Cheers, Gonzalo On 07/07/2016 9:47 AM, Aijun Wang wrote: > Hi, Gonzalo and Simon: > > I would like to apply one time slot to present our solution to host-to-host > communication, which is named as OARS(Operator-Assisted-Relay-Service), one > alternative/additional solution that compared with TURN. > The corresponding draft has been submitted to the IETF repository, please > refer to it according to the following links: > https://datatracker.ietf.org/doc/draft-wang-tram-oars/ > > The information for the presentation is as the following: > > Title: OARS(Operator-Assisted-Relay-Service) > Presenter: Aijun Wang(China Telecom) > Duration: 5-10minutes > > Thanks in advance. > > Best Regards. > > Aijun Wang > China Telecom Beijing Research Institute Network R&D and Operation Support > Department > > > -----ÓŹ¼žŌ­¼ž----- > ·¢¼žČĖ: tram [mailto:tram-bounces@ietf.org] ´ś±ķ Gonzalo Camarillo > ·¢ĖĶŹ±¼ä: 2016Äź7ŌĀ6ČÕ 23:10 > ŹÕ¼žČĖ: tram@ietf.org > ³­ĖĶ: Simon Perreault > Ö÷Ģā: [tram] Agenda requests for Berlin > > Folks, > > if you have an agenda request for our session in Berlin, please let us (the > chairs) know. > > Thanks, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > From nobody Tue Jul 12 08:47:14 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 63D7F12D972 for ; Tue, 12 Jul 2016 08:47:13 -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 gzdTxEjNqXyn for ; Tue, 12 Jul 2016 08:47:11 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 5CF9112D99C for ; Tue, 12 Jul 2016 08:43:01 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id i123so8031703pfg.0 for ; Tue, 12 Jul 2016 08:43:01 -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=h3XCyfFFVIt3AefP3tMggWkvFqnLH5RuT9jeLNhn6TY=; b=DQohZN5fDJ38KSw3kuqR7coZO2fkwDEKqoiO3AF7dbUftImV3o+YRYiYzTOHKHODM9 /WIepkY0QLnwqi5MJkLt1HH1nnBiHSj+6miN1+rl/EGT5w73vuLXZAwqn6E+Y6bftkLE f3xzsSgSUkkQg+ssI16xGwN6vRmKEV4qGMNBdNU99ZxZnSVcViYoZQhOQBLk13NBcQPO t6PS7STlpAqy5e+PvshYmEToySCD6k7aIi/qQGdFb6nJ9xPetDK04zk2Fk2flaAP6BO+ Miv4T82ffbJVffdukx9gl58y1Uc0VEv+r0SY2OlyevBzoPLTsr4xJuVZH0RMRS9paBYh kTgg== 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=h3XCyfFFVIt3AefP3tMggWkvFqnLH5RuT9jeLNhn6TY=; b=kRXraEqnx7NLjS7D0hqNiGlI4+RaiKHtZ32+ELIjSIMlFVfflzAonnymU+ov7BC/eu TlTVp/K08ySDgvCyldR+Ud14eFQ2aNckflkk6Lc0RZADlYvb2aIEo1gQalDX5bwT3gOR hvazGIXXWlpntV8mIDfcc28MjxQp5U5Mb6qN9KLrgsbU9kSvH/vNtAu6FtrZPW6wryTY BoxfDW4EmFO9IOnOhco++h7affuyK/Fc6HArTeP6LweXqd/i3kWK0SIBcm2kiVF6WuKa dfLRpqAKrfLtmTSLS94KXZp0A3r+cL6JZMoEORWBYh/aMBBD6fV0IS//0HKEJjBbrnYS 2PMA== X-Gm-Message-State: ALyK8tIAlv8CNnL+lwmAROxoW1utQ5yWzejTKVxannNFgn6zUzO3RuPSuoFpjAQ3aa6AVW3dVVBuv8wDrQvymHM3xPERx3atuktXzTY3cTJzDObPBJaagtHrsBuVo1zGjJQIWQqmlhjyaivdpWOzZPdOJulOftcY/GGzwSvWHVA= X-Received: by 10.98.39.68 with SMTP id n65mr45860385pfn.153.1468338180556; Tue, 12 Jul 2016 08:43:00 -0700 (PDT) Received: from balaise.nomis80.org ([2607:fa48:6e34:f170:76d4:35ff:fe1d:9ba2]) by smtp.gmail.com with ESMTPSA id s3sm5491717pfb.87.2016.07.12.08.42.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jul 2016 08:42:59 -0700 (PDT) To: Marc Petit-Huguenin , tram@ietf.org References: <20160615193229.26225.84457.idtracker@ietfa.amsl.com> From: Simon Perreault Message-ID: <87bbd02b-3f77-9e7e-00c6-8ae1800dd74e@jive.com> Date: Tue, 12 Jul 2016 11:42:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-08.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: Tue, 12 Jul 2016 15:47:13 -0000 Le 2016-06-15 ą 15:39, Marc Petit-Huguenin a écrit : > Changelog: > > * Updated list of changes since RFC 5389. > * More examples are automatically generated. > * Message integrity truncation is fixed at a multiple of 4 bytes, because the padding will not decrease by more than this. > * USERHASH contains the 32 bytes of the hash, not a character string. > * Updated the example to use the USERHASH attribute and the modified NONCE attribute. > * Updated ICEbis reference. Just reviewed -07 and -08. Changes look good to me. Thanks! > We still need a cryptographic review of the new HMAC truncation proposal. Indeed we do. We'll ask for a volunteer during the meeting in Berlin if we find nobody before then. As a last resort we can ask the security area ADs to twist someone's arm... Simon From nobody Tue Jul 12 09:12:26 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 26A1512D1C8 for ; Tue, 12 Jul 2016 09:12:25 -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 DL9Beb3ZBt8q for ; Tue, 12 Jul 2016 09:12:23 -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 8E22112B076 for ; Tue, 12 Jul 2016 09:12:23 -0700 (PDT) Received: from [IPv6:2a01:e34:ee66:4490:de53:60ff:feda:8cf2] (unknown [IPv6:2a01:e34:ee66:4490:de53:60ff:feda:8cf2]) (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 8C59E2012F; Tue, 12 Jul 2016 18:12:21 +0200 (CEST) To: Simon Perreault , tram@ietf.org References: <20160615193229.26225.84457.idtracker@ietfa.amsl.com> <87bbd02b-3f77-9e7e-00c6-8ae1800dd74e@jive.com> From: Marc Petit-Huguenin Message-ID: Date: Tue, 12 Jul 2016 18:12:28 +0200 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: <87bbd02b-3f77-9e7e-00c6-8ae1800dd74e@jive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stunbis-08.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: Tue, 12 Jul 2016 16:12:25 -0000 Thanks Simon. On 07/12/2016 05:42 PM, Simon Perreault wrote: > Le 2016-06-15 Ć  15:39, Marc Petit-Huguenin a Ć©crit : >> Changelog: >> >> * Updated list of changes since RFC 5389. >> * More examples are automatically generated. >> * Message integrity truncation is fixed at a multiple of 4 bytes, because the padding will not decrease by more than this. >> * USERHASH contains the 32 bytes of the hash, not a character string. >> * Updated the example to use the USERHASH attribute and the modified NONCE attribute. >> * Updated ICEbis reference. > > Just reviewed -07 and -08. Changes look good to me. Thanks! > >> We still need a cryptographic review of the new HMAC truncation proposal. > > Indeed we do. We'll ask for a volunteer during the meeting in Berlin if > we find nobody before then. As a last resort we can ask the security > area ADs to twist someone's arm... > > Simon > From nobody Sun Jul 17 04:07:47 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 1A98012D567 for ; Sun, 17 Jul 2016 04:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 0oaalSjH3bpF for ; Sun, 17 Jul 2016 04:07:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0370412B058 for ; Sun, 17 Jul 2016 04:07:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-f7-578b66fd6d20 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2F.C4.18043.DF66B875; Sun, 17 Jul 2016 13:07:41 +0200 (CEST) Received: from [131.160.126.84] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.68) with Microsoft SMTP Server id 14.3.294.0; Sun, 17 Jul 2016 13:07:41 +0200 To: From: Gonzalo Camarillo Message-ID: Date: Sun, 17 Jul 2016 13:07:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGbHdSfdvWne4wf2zZhYf1l5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxratH5gKuhgrVi5/wNTAmNfFyMkhIWAi0TnvARuELSZx4d56 IJuLQ0jgCKPEkVsTmSCcNYwSZz/vYgGpEhEQlph78C6YzSZgIbHl1n0wW1hAUGLC1E1A3Rwc vAL2Es9uuYKEWQRUJV79escMEhYViJFY35cAEuYFqj458wkLSJhZQFNi/S59kDCzgLzE9rdz mEFsIQFtieXPWlgmMPLNQtIxC6FjFpKOBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC Q+nglt9WOxgPPnc8xCjAwajEw5uwritciDWxrLgy9xCjBAezkghvUmJ3uBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQbGjVyPnQtOpzX3sjam1O5SeXz7 2TELw7rE7bWSTS155eulvszny/63535nwBazlbz2jnJhJh5u2ikpvfP5fhtezv+qHrf81Hrm T4aSpoK+uo+WuFQcjk5w6XSPdmSYamsunV7YNqVc9PKJ4tfz2fYdO/9r0pHVN5hlw93/Jhw9 vsF/zZmCdWJKLMUZiYZazEXFiQBkczHCIQIAAA== Archived-At: Subject: [tram] PLUS BoF 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, 17 Jul 2016 11:07:46 -0000 Hi, FYI: some of you may be interested in the PLUS BoF: https://datatracker.ietf.org/meeting/96/agenda/plus/ Cheers, Gonzalo From nobody Mon Jul 18 07:11:18 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 6C8B512DC73 for ; Mon, 18 Jul 2016 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.788 X-Spam-Level: X-Spam-Status: No, score=-15.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 h-D_ty1X1o6E for ; Mon, 18 Jul 2016 07:11:10 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C4712D9F0 for ; Mon, 18 Jul 2016 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=848; q=dns/txt; s=iport; t=1468849311; x=1470058911; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VRz+pyFr6h2YDWEl4PGymY4fRG9Wwpr+p8G+clsQPOE=; b=e9baME+t3j4VsjvVvOmwRFmM8lBqeGr6gSVBwWUMI7mKdrXX0HVRPqY+ 4Fw1imx6C1oTuLOeGti2yr2EmJGw0qvDv8q+2vIOHiPkvWMx+gIMSHH9j ImcgcWYAcqDdQ8qqhdv98r2jNpLxd7vM9L2s0DmveHLmoy/G1a/x9kmlw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AxBgAE3IxX/4cNJK1bgz+BWLZmhAiHU?= =?us-ascii?q?DsRAQEBAQEBAWUcC4RjOlEBPkInBIhDoFadUQEBCAIBJI8hhXEFmSQBjl6PN5A?= =?us-ascii?q?dATQgg3OHLX8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,384,1464652800"; d="scan'208";a="297638897" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 13:41:50 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u6IDfonB027585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Jul 2016 13:41:50 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 09:41:49 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 09:41:49 -0400 From: "Ram Mohan R (rmohanr)" To: "tram@ietf.org" Thread-Topic: Carrying Session identifier in TURN messages Thread-Index: AQHR4PoiwJbpWfStpEyVLBlOxIr8wQ== Date: Mon, 18 Jul 2016 13:41:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.82.111] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tram] Carrying Session identifier in TURN messages 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, 18 Jul 2016 14:11:15 -0000 Hi all, When deploying TURN server in the cloud we saw the following problem: There is a no proper identifier to troubleshoot and co-relate TURN messages with rest of call control messages. For example, if we have a cloud rendering IP telephony services having SIP elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media elements (like TURN servers) we would need a way to co-relate the SIP messages with TURN control messages for a given session. SIP messages could be co-related by using an identifier like SIP session ID mostly. It would be good to have a new STUN attribute that can carry the session identifier (which can be SIP sessionID in case of TURN session was allocated by SIP element). Would like to hear any thoughts the WG have on having such a attribute in TURN messages ?=20 Regards, Ram From nobody Mon Jul 18 09:53:22 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 D768312D0DC for ; Mon, 18 Jul 2016 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.807 X-Spam-Level: X-Spam-Status: No, score=-15.807 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 AHfCgnoiJZbJ for ; Mon, 18 Jul 2016 09:53:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56BA1288B8 for ; Mon, 18 Jul 2016 09:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1468860797; x=1470070397; h=from:to:subject:date:message-id:mime-version; bh=QUXN1fGoqaj1u6jUUE+0/XAH+Z0enaje0LU7RRnL9yM=; b=kVDHd8ucZ56EjiZdE3b9kDPhLwMtqIy/F+J0A2I15Sdz3wsxD4YQVGMn edDnz9MSG5YShYcp1074WA7psHLWawitrMID7PS4tsKOmLUDuN8TH4FQi HFqdYWMtiyR4i0zMOLO+qRwHRbVyLiX83fv7zox2XmH3c7BLLiCrwx3c7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAgAnCY1X/4YNJK1bgnFOVnwGs16Cd?= =?us-ascii?q?YIPgXkihy44FAEBAQEBAQFlHAuEYy1eAQx0JgEEG4goDqBRnV4BAQEBAQUBAQE?= =?us-ascii?q?BAQEcBYYqjmgFmSQBhhKIRY8+kB0BHjaDc24BAQEBhl9/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,384,1464652800"; d="scan'208,217";a="125037210" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jul 2016 16:53:16 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u6IGrG5S001343 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 18 Jul 2016 16:53:16 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 11:53:16 -0500 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 11:53:16 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: HMAC and SHA2 Truncation for STUNbis Thread-Index: AdHhFNY75HaMV0bnSky7hgHYxErRMw== Date: Mon, 18 Jul 2016 16:53:16 +0000 Message-ID: <915dc6fa3e8f42b6a10fae8c6d0ac832@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.71.148] Content-Type: multipart/alternative; boundary="_000_915dc6fa3e8f42b6a10fae8c6d0ac832XCHRCD017ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [tram] HMAC and SHA2 Truncation for STUNbis 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, 18 Jul 2016 16:53:20 -0000 --_000_915dc6fa3e8f42b6a10fae8c6d0ac832XCHRCD017ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://tools.ietf.org/html/rfc7518#section-5.2.3 and https://tools.ietf.or= g/html/rfc7252#section-9.1.3.2.1 -Tiru --_000_915dc6fa3e8f42b6a10fae8c6d0ac832XCHRCD017ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://tools.ietf.org/html/rfc7518#section-5.2.3 and https://t= ools.ietf.org/html/rfc7252#section-9.1.3.2.1

 

-Tiru

 

--_000_915dc6fa3e8f42b6a10fae8c6d0ac832XCHRCD017ciscocom_-- From nobody Mon Jul 18 14:16:31 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 8258612B05A for ; Mon, 18 Jul 2016 14:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MISSING_SUBJECT=1.799, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 Fq-FktyLizFs for ; Mon, 18 Jul 2016 14:16:29 -0700 (PDT) Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B09E12B00D for ; Mon, 18 Jul 2016 14:16:29 -0700 (PDT) Received: from [166.182.81.245] by msvc-mesg-gmxus004.server.lan (via HTTP); Mon, 18 Jul 2016 23:16:26 +0200 MIME-Version: 1.0 Message-ID: From: "Dwayne Hans" To: tram@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 18 Jul 2016 23:16:26 +0200 X-Provags-ID: V03:K0:byT25WojwWTeDQKv6Y2Vlok28MjkOzyKOkwh7MCe+7y C8vSnS337j3BH6A1T/06PYBG9QKWvHXGRFkIFf7HAXc5WjgOWE 45oZZmPtzutRTTdfvag7K5ocXwObw2mp5mXfrtbJm1FlQyX84g kLjL48CPLBLfKBOCIqsXJqbc5Kd0C8EdsYagxPGG+18JsSgmQY XGpjblEepuJjEBENG7W33Xb8HgaNSX+MPZZEEOt3d8GSP+XTP0 jB65NDrkMGrvkORhblfXfvCK1TZ6iHm6YOZcqZPw4Play+Gvom gyIo3pZXKn0wJxemRJLSfCJvFtI X-UI-Out-Filterresults: notjunk:1;V01:K0:VhBytIe7b2w=:K9CxRki96Acw7UzLWC9Kfo uhrxk/LrxVEjf+qg6gos0LC0nAtXEv+b09W7htmZx5rUqK+rfZAa9l0qAc/37tjpsyJvqWH5m /Fw6BjGGTCEOzhj8uqXTVLZ58VnOXzX2YFQLT454F8RbRRKZn7tz+od1cQ0SAjngVm4yzSmbL 4BxXLyZJTk985px4Deia7MIaKW3iNLYHuI4zfWNnOxlU0zKE0dMMzdbXHmyMhiKUtp4mpF0d6 Bii8AM4x/uHyow28jM4TQOkrnWnfoNHIksmL+W3OTrGJxJlwSMLkb1Mw8k8D+NxvzBVzF5ZY0 MrcJ2WgT8ZxW5YmCs0HTVyXasUcM54Hz+wMAxoTt7QieOsATJAve9kVXuj4T5oM8tOL2LpVLg c2QcgvgEhO9ByMCvi7tu+jNpOwGDwzImIEhK8dl26Nbv42MUGjH11T2mL/TCIeyPta/bI+ZaO Wqh6ckFseDNXtmwYzakME0ePA/lXu0EUL9dz1Nqrwa7DcJTTtcDcCGt58WZ85s9lp30mcMAh0 DgZ3pcQWur5iX+NmsDYpauRvwzLNYOKziC2vSlbIYOt33dpYPdilJAPgiqYibT1HAWRxWQByu hbhOB0548z0IQSCQOaxjS6xVJm3S2KeCEQA91rv2MM2fmFX09Azg8ChM9jtzx8k7jMVRL6S0O 54f0= Archived-At: Cc: Dwayne Hans Subject: [tram] (no subject) 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, 18 Jul 2016 21:16:30 -0000 https://blockchain.info/Resources/wallet-legacy/pay-now-button.js Sent using the mail.com mail app From nobody Tue Jul 19 04:36:43 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 4CF3F12D0BF for ; Tue, 19 Jul 2016 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 16KFE0Ck-wKg for ; Tue, 19 Jul 2016 04:36:40 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 721D812D12E for ; Tue, 19 Jul 2016 04:36:39 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id w18so21025510oiw.3 for ; Tue, 19 Jul 2016 04:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BQ3OfoV3nzGPVMH+bD6L02N5uRt8Q2uGt9a2hnJbmXU=; b=AocPT8syAkXSB3R4woXeUNB8FR5aKhfMWpilbkfPikN48SAJQGW+HOB9pBtiGX+IVT KFSZV1XGwnBksUj1jCS6Drrk8jKAenq6A9vxenwi0KdmeKpFuzlbqoqy77m74CYBkdwv lbVcMQENfNr0GCaZJcERz91Rf/PR3nY2TOxj4MM/TiwlnIukKJp8iyrPGSYEAYcx8NTC EwwHal0XXiJu4duoGyu1Uk8la33g3PSo/TzRm4yQYFT+zzLzK6V+h75AQp+63CkbWU0+ NHeq2R+cjly1yxBqR911GxPmXXLVsH5REKcMF+yyEO98keB1fMlIVawHUG7chJWN0KTK t/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BQ3OfoV3nzGPVMH+bD6L02N5uRt8Q2uGt9a2hnJbmXU=; b=Nab0EyJUXLCl1EGgNuIcNsqoJ4PtUppSP3nOAE9lU9lDWwev9NUW+AmPOWENulRlhe VUrIS4l96nun+8tav8E6MhPw7F9tKDmKtbjn7p+Nte68M9D438l1b6iypoTHrsb7Ge8K /XMcaGvOX4fSKfo1xa+9E9+HqoFl+XDzCKLXOchPib2jKeEfE7UwO+o0G+LDy12zu75l 07CPQKVEjzuPU1oso6iwOICRNKQ7mxpRSL/+ROxvKg8pENgibzWDpz62PoyDZDM/mviq /JcVHHFy970YeR2tH4m5q23xtuuC/UxtE+fBJTua9/66Lzh903LypvDijrG23BxNq9wO OTnQ== X-Gm-Message-State: ALyK8tKvOW9T51YUEGxkyzp4NmRyO/+MiHBhZ5IlpQueW4D7CVtfpDtYL8N2XHWK1cNYSAHHXvebf1nKuVicfg== X-Received: by 10.202.217.67 with SMTP id q64mr17801665oig.12.1468928198768; Tue, 19 Jul 2016 04:36:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.52 with HTTP; Tue, 19 Jul 2016 04:36:38 -0700 (PDT) In-Reply-To: References: From: Muthu Arul Mozhi Perumal Date: Tue, 19 Jul 2016 13:36:38 +0200 Message-ID: To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=001a113cf48c7d00960537fb7ff8 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Carrying Session identifier in TURN messages 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: Tue, 19 Jul 2016 11:36:42 -0000 --001a113cf48c7d00960537fb7ff8 Content-Type: text/plain; charset=UTF-8 This looks would certainly help in troubleshooting. What we probably need is an identifier that the application can pass on to the TURN client to be included in the TURN control messages associated with an allocation and for the server to echo it back in the response. How this identifier gets mapped to the SIP session ID or some other session ID could be just implementation details. This identifier can then be used to correlate the TURN messages pertaining to a set of allocations, possibly from different TURN servers, with session signaling, for troubleshooting purpose.. Muthu On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) wrote: > Hi all, > > When deploying TURN server in the cloud we saw the following problem: > There is a no proper identifier to troubleshoot and > co-relate TURN messages with rest of call control messages. > For example, if we have a cloud rendering IP telephony services having SIP > elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media > elements (like TURN servers) we would need a way to co-relate the SIP > messages with TURN control messages for a given session. SIP messages > could be co-related by using an identifier like SIP session ID mostly. > > It would be good to have a new STUN attribute that can carry the session > identifier (which can be SIP sessionID in case of TURN session was > allocated by SIP element). > > Would like to hear any thoughts the WG have on having such a attribute in > TURN messages ? > > Regards, > Ram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113cf48c7d00960537fb7ff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This looks would certainly help in trou= bleshooting.=C2=A0 What we probably need is an identifier that the applicat= ion can pass on to the TURN client to be included in the TURN control messa= ges associated with an allocation and for the server to echo it back in the= response. How this identifier gets mapped to the SIP session ID or some ot= her session ID could be just implementation details. This identifier can th= en be used to correlate the TURN messages pertaining to a set of allocation= s, possibly from different TURN servers, with session signaling, for troubl= eshooting purpose..=C2=A0

Muthu

On= Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) <= rmohanr@cisco.com> wrote:
Hi all,

When deploying TURN server in the cloud we saw the following problem:
=C2=A0There is a=C2=A0 no proper identifier to troubleshoot and
co-relate TURN messages with rest of call control messages.
For example, if we have a cloud rendering IP telephony services having SIP<= br> elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media elements (like TURN servers) we would need a way to co-relate the SIP
messages with TURN control messages for a given session. SIP messages
could be co-related by using an identifier like SIP session ID mostly.

It would be good to have a new STUN attribute that can carry the session identifier (which can be SIP sessionID in case of TURN session was
allocated by SIP element).

Would like to hear any thoughts the WG have on having such a attribute in TURN messages ?

Regards,
Ram

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

--001a113cf48c7d00960537fb7ff8-- From nobody Tue Jul 19 05:29:05 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 98B9012D641 for ; Tue, 19 Jul 2016 05:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 WTAQuwvDyYFD for ; Tue, 19 Jul 2016 05:29:01 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 3600512D65E for ; Tue, 19 Jul 2016 05:28:57 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j185so22875778oih.0 for ; Tue, 19 Jul 2016 05:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bgrUPk9vIDio09+WBVcfd3DI1OYa/ELDgouVMvdlZsA=; b=xNWH9AFjt1mN7ocHpKBMkTHNso4cReuRz2pBEqM4qcZbVJLXzMi9PMxYojaRTHXOhk aJ6vQ8cFS/uWG50rvX2yc/pKAf/JEIzLEaEXegEHTixWYKhq8OyN9Y9HN2sJUcp2L00T XIloIQTv+ncvppd+xseL4hOkzGOI3Eret9UaT6GCvpdephxlCs6jqBK7HOOllBmDLt/A x8adecK/pHCj2JpcAgy/XJYOVOIB/lgyle9CDQqI/wuz6BLY8pSIaNn3jNbSJHJxtoaW cQ8b///cPPGOkg9Bd1woECObTEo8Ff3ay9fGMkCpjJrbaomK6Am6AyoX82VPF+OWEkeJ WYvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bgrUPk9vIDio09+WBVcfd3DI1OYa/ELDgouVMvdlZsA=; b=eaKiz1tyOD5Z1NaRQdB4dkgzkh3O/plR4lON+/k6kA6CCxeRLKNIvsDW0FJxKZOQcm fFYjSBWII62grrM/PMhL/fxNHhJonvWLhyHAvV+0z+36iQQJ2kvsePXat0F6XNPY6xD8 bD+RPWAYFHAYt9jySErsdWjzquPPwEde5SlXElnUWgTk1LBMny0hiGz3mRgmO5jP1tQe K6fX2JHabwz2xQVh13IKFqH4OywUtOfh9IeR/zvhrVHO9dS03TyLqdOvScxXswHkkdA0 /ebACgMJKpjJgL1zODJCOkc1wXjkh4WE1eqbZIU4hUc1P0pfh2R0c/YPttsspK/Vo2+n 3hsg== X-Gm-Message-State: ALyK8tL7L8AZNy5fLsouSdj3CY9+5auMQGzwTeR5ohhanR+Qq+MO+MebchYf4oejNqIx4z+C+CjNglL0ksqGnw== X-Received: by 10.202.234.5 with SMTP id i5mr19172603oih.98.1468931337136; Tue, 19 Jul 2016 05:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.52 with HTTP; Tue, 19 Jul 2016 05:28:56 -0700 (PDT) In-Reply-To: References: From: Muthu Arul Mozhi Perumal Date: Tue, 19 Jul 2016 14:28:56 +0200 Message-ID: To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=001a113d38068cb1620537fc3a88 Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Carrying Session identifier in TURN messages 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: Tue, 19 Jul 2016 12:29:03 -0000 --001a113d38068cb1620537fc3a88 Content-Type: text/plain; charset=UTF-8 Giving it another thought, if we also want 3pp tools (say, Wireshark) to be able to correlate a set of TURN messages with a set to SIP messages, we may also need to specify how to obtain one ID from the other. But, that requirement could probably be discussed separately? Muthu On Tue, Jul 19, 2016 at 1:36 PM, Muthu Arul Mozhi Perumal < muthu.arul@gmail.com> wrote: > This looks would certainly help in troubleshooting. What we probably need > is an identifier that the application can pass on to the TURN client to be > included in the TURN control messages associated with an allocation and for > the server to echo it back in the response. How this identifier gets mapped > to the SIP session ID or some other session ID could be just implementation > details. This identifier can then be used to correlate the TURN messages > pertaining to a set of allocations, possibly from different TURN servers, > with session signaling, for troubleshooting purpose.. > > Muthu > > On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) > wrote: > >> Hi all, >> >> When deploying TURN server in the cloud we saw the following problem: >> There is a no proper identifier to troubleshoot and >> co-relate TURN messages with rest of call control messages. >> For example, if we have a cloud rendering IP telephony services having SIP >> elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media >> elements (like TURN servers) we would need a way to co-relate the SIP >> messages with TURN control messages for a given session. SIP messages >> could be co-related by using an identifier like SIP session ID mostly. >> >> It would be good to have a new STUN attribute that can carry the session >> identifier (which can be SIP sessionID in case of TURN session was >> allocated by SIP element). >> >> Would like to hear any thoughts the WG have on having such a attribute in >> TURN messages ? >> >> Regards, >> Ram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > --001a113d38068cb1620537fc3a88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Giving it another thought, if we also w= ant 3pp tools (say, Wireshark) to =C2=A0be able to correlate a set of TURN = messages with a set to SIP messages, we may also need to specify how to obt= ain one ID from the other. But, that requirement could probably be discusse= d separately?

Muthu

On Tue, Jul 19= , 2016 at 1:36 PM, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com= > wrote:
This looks= would certainly help in troubleshooting.=C2=A0 What we probably need is an= identifier that the application can pass on to the TURN client to be inclu= ded in the TURN control messages associated with an allocation and for the = server to echo it back in the response. How this identifier gets mapped to = the SIP session ID or some other session ID could be just implementation de= tails. This identifier can then be used to correlate the TURN messages pert= aining to a set of allocations, possibly from different TURN servers, with = session signaling, for troubleshooting purpose..=C2=A0

Muthu

On Mon, Jul = 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) <rmohanr@cisco.com> wrote:
Hi all,

When deploying TURN server in the cloud we saw the following problem:
=C2=A0There is a=C2=A0 no proper identifier to troubleshoot and
co-relate TURN messages with rest of call control messages.
For example, if we have a cloud rendering IP telephony services having SIP<= br> elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media elements (like TURN servers) we would need a way to co-relate the SIP
messages with TURN control messages for a given session. SIP messages
could be co-related by using an identifier like SIP session ID mostly.

It would be good to have a new STUN attribute that can carry the session identifier (which can be SIP sessionID in case of TURN session was
allocated by SIP element).

Would like to hear any thoughts the WG have on having such a attribute in TURN messages ?

Regards,
Ram

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


--001a113d38068cb1620537fc3a88-- From nobody Tue Jul 19 05:57:54 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 34B4B12D7A1 for ; Tue, 19 Jul 2016 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 U4Z0F9ZfqXHw for ; Tue, 19 Jul 2016 05:57:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AD412D7A2 for ; Tue, 19 Jul 2016 05:54:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2108; q=dns/txt; s=iport; t=1468932882; x=1470142482; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=C98eZK2clHTugB0/99YqoJGgP3Vr/ZqR0byzxrK1HNw=; b=FyZNCJnbFVzrSbcvR0KcOsVJx3hkAlhI4PuFpTul9W1indoHX4irUObu Wm9wdYyDfi7rZo1qxjcadaHXhFaRd54v7rvF6e2tBvVrwuVUAa19J7CnH MWnKbwZev14KDb3RMtqYjnZJZodh95mf9+DDaKxTJEnZ0QjLrQtP7/ENb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgDRIo5X/4QNJK1cgz9WfAasR4wag?= =?us-ascii?q?XoihXgCgS84FAEBAQEBAQFlHAuEXAEBBAEBAWwQCwIBCBEDAQIBLiEGCx0IAgQ?= =?us-ascii?q?TiBYDDwgOuBsNhB4BAQEBAQEBAQIBAQEBAQEBARoFineCQ4FnhXEFjkSKLDQBj?= =?us-ascii?q?EOCHo83iCWHeAEeNoNzbocRfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="130326265" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 12:54:30 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u6JCsUB9024590 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jul 2016 12:54:30 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 08:54:29 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 08:54:29 -0400 From: "Ram Mohan R (rmohanr)" To: "tram@ietf.org" Thread-Topic: [tram] Carrying Session identifier in TURN messages Thread-Index: AQHR4bufrON1QLG4SkCzW9iRBgv8dqAgGnkA Date: Tue, 19 Jul 2016 12:54:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.37.117] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5A53B73702C2164BB73BBF55B46CEF5A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Carrying Session identifier in TURN messages 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: Tue, 19 Jul 2016 12:57:52 -0000 Hi Muthu, > > >From: Muthu Arul Mozhi Perumal >Date: Tuesday, 19 July 2016 at 1:36 PM >To: Ram Mohan Ravindranath >Cc: "tram@ietf.org" >Subject: Re: [tram] Carrying Session identifier in TURN messages > > >This looks would certainly help in troubleshooting. What we probably need >is an identifier that the application can pass on to the TURN client to be >included in the TURN control messages associated with an allocation and >for the server to echo it back in the > response. Yes that=B9s the idea. > How this identifier gets mapped to the SIP session ID or some >other session ID could be just implementation details. Agree.=20 > This identifier can >then be used to correlate the TURN messages pertaining to a set of >allocations, possibly from different TURN > servers, with session signaling, for troubleshooting purpose.. Yes. that=B9s the main use-case I have. Regards, Ram > >Muthu > >On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) > wrote: > >Hi all, > >When deploying TURN server in the cloud we saw the following problem: > There is a no proper identifier to troubleshoot and >co-relate TURN messages with rest of call control messages. >For example, if we have a cloud rendering IP telephony services having SIP >elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media >elements (like TURN servers) we would need a way to co-relate the SIP >messages with TURN control messages for a given session. SIP messages >could be co-related by using an identifier like SIP session ID mostly. > >It would be good to have a new STUN attribute that can carry the session >identifier (which can be SIP sessionID in case of TURN session was >allocated by SIP element). > >Would like to hear any thoughts the WG have on having such a attribute in >TURN messages ? > >Regards, >Ram > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram > > > > > From nobody Tue Jul 19 06:00:53 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 9FABA12D866 for ; Tue, 19 Jul 2016 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 t7-4_dv58Ip9 for ; Tue, 19 Jul 2016 06:00:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A7C12D781 for ; Tue, 19 Jul 2016 05:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2595; q=dns/txt; s=iport; t=1468933086; x=1470142686; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=nM4ewNR0gmvwca3jE1lX8VBuQs8mHmc+rSCNQ7IBr9E=; b=mIDeQwC6P0jX/BOdunczsfT4pJCKgf9h3LmlOm69zyM6lC+wrd5472qv RFJKAMegTb6kTIMnXLZo7LBMSVkIAWX1P55S4CNI+mQOGMUipzNKIAnw8 +WBiw9V35uJgiMw21W+KOQz2iYdT7BG+Z3o0Rw3Kq0KYX3XnE8vV+iYnS I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAgD4Io5X/4ENJK1cgz9WfAasR4wag?= =?us-ascii?q?XoihXgCgS84FAEBAQEBAQFlJ4RcAQEFAQE4NBsCAQgRAwECAR4QIQYLHQgCBAE?= =?us-ascii?q?SiBYDFw64Fg2EHgEBAQEBAQEBAQEBAQEBAQEBAQEZBYp3gkOBZ4VxBZhwNAGMQ?= =?us-ascii?q?4IejzeIJYd4AR42g3NuhxF/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,389,1464652800"; d="scan'208";a="125701766" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jul 2016 12:58:05 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u6JCw5VT005028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Jul 2016 12:58:05 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 19 Jul 2016 08:58:04 -0400 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Tue, 19 Jul 2016 08:58:04 -0400 From: "Ram Mohan R (rmohanr)" To: "tram@ietf.org" , Muthu Arul Mozhi Perumal Thread-Topic: [tram] Carrying Session identifier in TURN messages Thread-Index: AQHR4bzbrON1QLG4SkCzW9iRBgv8dqAgG3CA Date: Tue, 19 Jul 2016 12:58:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.6.160626 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.37.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tram] Carrying Session identifier in TURN messages 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: Tue, 19 Jul 2016 13:00:53 -0000 Inline > > >From: Muthu Arul Mozhi Perumal >Date: Tuesday, 19 July 2016 at 2:28 PM >To: Ram Mohan Ravindranath >Cc: "tram@ietf.org" >Subject: Re: [tram] Carrying Session identifier in TURN messages > > >Giving it another thought, if we also want 3pp tools (say, Wireshark) to >be able to correlate a set of TURN messages with a set to SIP messages, we >may also need to specify how to obtain one ID from the other. But, that >requirement could probably be discussed > separately? I am not sure if that needs to be standardised. How tools/application that correlates these information obtains the ID could be purely an implementation detail. Regards, Ram > >Muthu > >On Tue, Jul 19, 2016 at 1:36 PM, Muthu Arul Mozhi Perumal > wrote: > >This looks would certainly help in troubleshooting. What we probably need >is an identifier that the application can pass on to the TURN client to be >included in the TURN control messages associated > with an allocation and for the server to echo it back in the response. >How this identifier gets mapped to the SIP session ID or some other >session ID could be just implementation details. This identifier can then >be used to correlate the TURN messages pertaining > to a set of allocations, possibly from different TURN servers, with >session signaling, for troubleshooting purpose.. > >Muthu > >On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) > wrote: > >Hi all, > >When deploying TURN server in the cloud we saw the following problem: > There is a no proper identifier to troubleshoot and >co-relate TURN messages with rest of call control messages. >For example, if we have a cloud rendering IP telephony services having SIP >elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media >elements (like TURN servers) we would need a way to co-relate the SIP >messages with TURN control messages for a given session. SIP messages >could be co-related by using an identifier like SIP session ID mostly. > >It would be good to have a new STUN attribute that can carry the session >identifier (which can be SIP sessionID in case of TURN session was >allocated by SIP element). > >Would like to hear any thoughts the WG have on having such a attribute in >TURN messages ? > >Regards, >Ram > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > > > > From nobody Tue Jul 19 07:27:04 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 1FB3612D87D for ; Tue, 19 Jul 2016 07:27:03 -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 UAtzJPjRBoNo for ; Tue, 19 Jul 2016 07:27:01 -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 D446E12D988 for ; Tue, 19 Jul 2016 06:48:29 -0700 (PDT) Received: from [IPv6:2001:67c:370:160:de53:60ff:feda:8cf2] (unknown [IPv6:2001:67c:370:160:de53:60ff:feda:8cf2]) (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 D0FEB20822; Tue, 19 Jul 2016 15:48:27 +0200 (CEST) To: "Tirumaleswar Reddy (tireddy)" , "tram@ietf.org" References: <915dc6fa3e8f42b6a10fae8c6d0ac832@XCH-RCD-017.cisco.com> From: Marc Petit-Huguenin Message-ID: <256a69bd-691c-20fa-dfe5-ed4f93ca4f6b@acm.org> Date: Tue, 19 Jul 2016 15:48:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: <915dc6fa3e8f42b6a10fae8c6d0ac832@XCH-RCD-017.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tram] HMAC and SHA2 Truncation for STUNbis 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: Tue, 19 Jul 2016 14:27:03 -0000 Hi Tiru, On 07/18/2016 06:53 PM, Tirumaleswar Reddy (tireddy) wrote: > https://tools.ietf.org/html/rfc7518#section-5.2.3 and > https://tools.ietf.org/html/rfc7252#section-9.1.3.2.1 > > -Tiru > Thank you for the pointers. We choose to use 128 bits as the minimum because of the 4 bytes padding in attribute, and we aligned the direction of truncation to what is used in the RFC. This is for MESSAGE-INTEGRITY-256, but I completely forgot in my slides that we are also proposing to do the same for MESSAGE-INTEGRITY. Would you have some guidance also for SHA-1, or do you (and the WG) think that we should restrict truncation only to the new MESSAGE-INTEGRITY-286 attribute? Thanks. From nobody Tue Jul 19 08:17:43 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 2EAE512D766 for ; Tue, 19 Jul 2016 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 DfuxyDeqO4wN for ; Tue, 19 Jul 2016 08:17:39 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 01B3E12DFF0 for ; Tue, 19 Jul 2016 07:56:10 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id j185so29063054oih.0 for ; Tue, 19 Jul 2016 07:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q8aoELudBQeD99TxsCmb0atei4Yyd14G25QMmYh+m0M=; b=RJmZm4USwCy4jWg7kmhsLLLeFrAOAfUkeLjiUjXaHyVSme2TOeEonvCh95q3y3ZVQ2 EoCfwRYHCWUeO/A5hLXU032asCM2xUi6njM5gqsvwceLDcrXcjXfpOy3HiEQ75ZLqKdj fvfvVxVwtBIGLCE3QApC7VdVDTF03kaXtLm5WeEgraaasIUdfydR+dpNYpTXkwXe4+eG Ihr88oJ8jovqNVBuTaDyJSS7dPb+wYOCQfPKoxwvuVcoNhRh6LaV47K0xbckMGv688S6 AuFuGgjNY8OwEndUhRFh+bCOKKsQmWMQTjgu04IBfCOhvaNU3ILkH66YpRR8mo7lKvqv LuIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q8aoELudBQeD99TxsCmb0atei4Yyd14G25QMmYh+m0M=; b=IAxpEI0WjO1gldkS7GW2eqOHM0KAzD+tuTkFCZLSUrmXm8StKAkKxsN7W33aJlabvB 30ig2kYAZCyIyWD3Aezm88sPWf1VHXY1AXi3hZUeezw+fOspm/8fSyfj1Dh80usi3GTF 90dTJjwW8lPknVlAZ7wHs6zh2RewJfYYS9NJ4cv4fB2onOa2WhE/qAf6kOegkHbrmLW3 yxW7+Y2jRaVsai+fLf4gBj+j+voj+EBD5gM6CWGfFCGj+kvNDcD23C0RVQkCX0hZ8ubv cR64E8OsEhLH84eSsVgd4gAP8hnCFbRLBJOczaxpRr8qLTKpv9y886kGpfAdbnNypia/ PEeA== X-Gm-Message-State: ALyK8tL3sLFEljhHtCoKsOCWjMrCrIe2TiAOYp4aSbEJoTzoI/IehJo2lrS3izTs/jaOufmml83lrEr0hjZRMQ== X-Received: by 10.157.1.214 with SMTP id e80mr24884674ote.141.1468940170274; Tue, 19 Jul 2016 07:56:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.52 with HTTP; Tue, 19 Jul 2016 07:56:09 -0700 (PDT) In-Reply-To: References: From: Muthu Arul Mozhi Perumal Date: Tue, 19 Jul 2016 16:56:09 +0200 Message-ID: To: "Ram Mohan R (rmohanr)" Content-Type: multipart/alternative; boundary=94eb2c03ba040bafd80537fe499e Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] Carrying Session identifier in TURN messages 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: Tue, 19 Jul 2016 15:17:42 -0000 --94eb2c03ba040bafd80537fe499e Content-Type: text/plain; charset=UTF-8 The mapping function probably needs to be standardized for tool implementors. However, I agree it is a separate requirement and needs to be discussed whether it should be in scope or out of scope.. Regards, Muthu On Tue, Jul 19, 2016 at 2:58 PM, Ram Mohan R (rmohanr) wrote: > Inline > > > > > > >From: Muthu Arul Mozhi Perumal > >Date: Tuesday, 19 July 2016 at 2:28 PM > >To: Ram Mohan Ravindranath > >Cc: "tram@ietf.org" > >Subject: Re: [tram] Carrying Session identifier in TURN messages > > > > > >Giving it another thought, if we also want 3pp tools (say, Wireshark) to > >be able to correlate a set of TURN messages with a set to SIP messages, we > >may also need to specify how to obtain one ID from the other. But, that > >requirement could probably be discussed > > separately? > > I am not sure if that needs to be standardised. How tools/application > that correlates these information obtains the ID could be purely an > implementation detail. > > Regards, > Ram > > > > >Muthu > > > >On Tue, Jul 19, 2016 at 1:36 PM, Muthu Arul Mozhi Perumal > > wrote: > > > >This looks would certainly help in troubleshooting. What we probably need > >is an identifier that the application can pass on to the TURN client to be > >included in the TURN control messages associated > > with an allocation and for the server to echo it back in the response. > >How this identifier gets mapped to the SIP session ID or some other > >session ID could be just implementation details. This identifier can then > >be used to correlate the TURN messages pertaining > > to a set of allocations, possibly from different TURN servers, with > >session signaling, for troubleshooting purpose.. > > > >Muthu > > > >On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) > > wrote: > > > >Hi all, > > > >When deploying TURN server in the cloud we saw the following problem: > > There is a no proper identifier to troubleshoot and > >co-relate TURN messages with rest of call control messages. > >For example, if we have a cloud rendering IP telephony services having SIP > >elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media > >elements (like TURN servers) we would need a way to co-relate the SIP > >messages with TURN control messages for a given session. SIP messages > >could be co-related by using an identifier like SIP session ID mostly. > > > >It would be good to have a new STUN attribute that can carry the session > >identifier (which can be SIP sessionID in case of TURN session was > >allocated by SIP element). > > > >Would like to hear any thoughts the WG have on having such a attribute in > >TURN messages ? > > > >Regards, > >Ram > > > >_______________________________________________ > >tram mailing list > >tram@ietf.org > >https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > > > > > > > > > > > > > > > > > > > --94eb2c03ba040bafd80537fe499e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The mapping function probably needs to = be standardized for tool implementors. However, I agree it is a separate re= quirement and needs to be discussed whether it should be in scope or out of= scope..

Regards,
Muthu =C2=A0=C2=A0

=
On Tue, Jul 19, 2016 at 2:58 PM, Ram Mohan R (rm= ohanr) <rmohanr@cisco.com> wrote:
Inline

>
>
>From:=C2=A0 Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
>Date:=C2=A0 Tuesday, 19 July 2016 at 2:28 PM
>To:=C2=A0 Ram Mohan Ravindranath <rmohanr@cisco.com>
>Cc:=C2=A0 "tram@ietf.org"= ; <tram@ietf.org>
>Subject:=C2=A0 Re: [tram] Carrying Session identifier in TURN messages<= br> >
>
>Giving it another thought, if we also want 3pp = tools (say, Wireshark) to
>be able to correlate a set of TURN messages with a set to SIP messages,= we
>may also need to specify how to obtain one ID from the other. But, that=
>requirement could probably be discussed
> separately?

I am not sure if that needs to be standardised. How tools/applicatio= n
that correlates these information obtains the ID could be purely an
implementation detail.

Regards,
Ram

>
>Muthu
>
>On Tue, Jul 19, 2016 at 1:36 PM, Muthu Arul Mozhi Perumal
><muthu.arul@gmail.com>= ; wrote:
>
>This looks would certainly help in troubleshooting.=C2=A0 What we proba= bly need
>is an identifier that the application can pass on to the TURN client to= be
>included in the TURN control messages associated
> with an allocation and for the server to echo it back in the response.=
>How this identifier gets mapped to the SIP session ID or some other
>session ID could be just implementation details. This identifier can th= en
>be used to correlate the TURN messages pertaining
> to a set of allocations, possibly from different TURN servers, with >session signaling, for troubleshooting purpose..
>
>Muthu
>
>On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr)
><rmohanr@cisco.com> wrot= e:
>
>Hi all,
>
>When deploying TURN server in the cloud we saw the following problem: > There is a=C2=A0 no proper identifier to troubleshoot and
>co-relate TURN messages with rest of call control messages.
>For example, if we have a cloud rendering IP telephony services having = SIP
>elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and medi= a
>elements (like TURN servers) we would need a way to co-relate the SIP >messages with TURN control messages for a given session. SIP messages >could be co-related by using an identifier like SIP session ID mostly.<= br> >
>It would be good to have a new STUN attribute that can carry the sessio= n
>identifier (which can be SIP sessionID in case of TURN session was
>allocated by SIP element).
>
>Would like to hear any thoughts the WG have on having such a attribute = in
>TURN messages ?
>
>Regards,
>Ram
>
>_______________________________________________
>tram mailing list
>tram@ietf.org
>https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
>
>
>
>
>
>
>
>
>


--94eb2c03ba040bafd80537fe499e-- From nobody Wed Jul 20 01:36:19 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 D883912D9C1 for ; Wed, 20 Jul 2016 01:36:17 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 cbnUu35xzFvT for ; Wed, 20 Jul 2016 01:36:16 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D90B12B037 for ; Wed, 20 Jul 2016 01:36:16 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u6K8aETH003186; Wed, 20 Jul 2016 04:36:14 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 241uh6gqph-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jul 2016 04:36:13 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 20 Jul 2016 03:36:13 -0500 From: Jonathan Lennox To: Marc Petit-Huguenin Thread-Topic: [tram] HMAC and SHA2 Truncation for STUNbis Thread-Index: AQHR4mEKjL1m78DcmUOzINNcTGis3KAhUpoA Date: Wed, 20 Jul 2016 08:36:12 +0000 Message-ID: <81BF6B3C-7B66-4834-83E0-6AC445308419@vidyo.com> References: <915dc6fa3e8f42b6a10fae8c6d0ac832@XCH-RCD-017.cisco.com> <256a69bd-691c-20fa-dfe5-ed4f93ca4f6b@acm.org> In-Reply-To: <256a69bd-691c-20fa-dfe5-ed4f93ca4f6b@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.177.193] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-07-20_06:2016-07-20,2016-07-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1607200101 Archived-At: Cc: "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] HMAC and SHA2 Truncation for STUNbis 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: Wed, 20 Jul 2016 08:36:18 -0000 > On Jul 19, 2016, at 3:48 PM, Marc Petit-Huguenin wrote= : >=20 > Hi Tiru, >=20 > On 07/18/2016 06:53 PM, Tirumaleswar Reddy (tireddy) wrote: >> https://tools.ietf.org/html/rfc7518#section-5.2.3 and >> https://tools.ietf.org/html/rfc7252#section-9.1.3.2.1 >>=20 >> -Tiru >>=20 >=20 > Thank you for the pointers. We choose to use 128 bits as the minimum bec= ause of the 4 bytes padding in attribute, and we aligned the direction of t= runcation to what is used in the RFC. >=20 > This is for MESSAGE-INTEGRITY-256, but I completely forgot in my slides t= hat we are also proposing to do the same for MESSAGE-INTEGRITY. Would you = have some guidance also for SHA-1, or do you (and the WG) think that we sho= uld restrict truncation only to the new MESSAGE-INTEGRITY-286 attribute? >=20 > Thanks. I think we should consider MESSAGE-INTEGRITY a legacy feature, and base any= protocol enhancements only on MESSAGE-INTEGRITY-SHA256. = From nobody Wed Jul 20 02:23:13 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 0F90612D096 for ; Wed, 20 Jul 2016 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 WhMUQapzyVEC for ; Wed, 20 Jul 2016 02:22:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88AB712B004 for ; Wed, 20 Jul 2016 02:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1469006578; x=1470216178; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UNEDJEcvZ+5QUsCSlS1XAuHPsFtPUidjx/GAi1DFpmE=; b=ScLCra4llVumjX/VoIB62JOZ1k/Bo87zMRWVuujcIeo3TOgakzOGwQXF sEeQn6AQJUBXmIYdSJH6EI2IKP1E+QTwbZYl4Lyk1KBwMQGz0Jaeta9bM IBcM+Pmpvxqy1r04AWLTZSMtA52RNLln6qtVmTwFERr8yNqDdfgU9R3e8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgBQQo9X/5xdJa1dgz9WfLhwgXoih?= =?us-ascii?q?XgCgTU4FAEBAQEBAQFlJ4RcAQEEAQEBODQLBQsCAQgYHhAnCyUCBA4FiCgIDr1?= =?us-ascii?q?EAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGKoF4glWEQIMsgi8FmSYBhhKIT485k?= =?us-ascii?q?B8BHjaCCB+BTG4BAQEBh2wBAQE?= X-IronPort-AV: E=Sophos;i="5.28,393,1464652800"; d="scan'208";a="125719986" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2016 09:22:57 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u6K9Mvpl017360 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jul 2016 09:22:57 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 20 Jul 2016 04:22:57 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Wed, 20 Jul 2016 04:22:57 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Jonathan Lennox Thread-Topic: [tram] HMAC and SHA2 Truncation for STUNbis Thread-Index: AQHR4mEKjL1m78DcmUOzINNcTGis3KAhUpoA//+5Pig= Date: Wed, 20 Jul 2016 09:22:56 +0000 Message-ID: <591C86BE-7E9A-4C4F-9A39-7B573A4258A2@cisco.com> References: <915dc6fa3e8f42b6a10fae8c6d0ac832@XCH-RCD-017.cisco.com> <256a69bd-691c-20fa-dfe5-ed4f93ca4f6b@acm.org>, <81BF6B3C-7B66-4834-83E0-6AC445308419@vidyo.com> In-Reply-To: <81BF6B3C-7B66-4834-83E0-6AC445308419@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Marc Petit-Huguenin , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] HMAC and SHA2 Truncation for STUNbis 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: Wed, 20 Jul 2016 09:23:05 -0000 +1 -G > On Jul 20, 2016, at 10:36 AM, Jonathan Lennox wrote: >=20 >=20 >> On Jul 19, 2016, at 3:48 PM, Marc Petit-Huguenin wrot= e: >>=20 >> Hi Tiru, >>=20 >>> On 07/18/2016 06:53 PM, Tirumaleswar Reddy (tireddy) wrote: >>> https://tools.ietf.org/html/rfc7518#section-5.2.3 and >>> https://tools.ietf.org/html/rfc7252#section-9.1.3.2.1 >>>=20 >>> -Tiru >>=20 >> Thank you for the pointers. We choose to use 128 bits as the minimum be= cause of the 4 bytes padding in attribute, and we aligned the direction of = truncation to what is used in the RFC. >>=20 >> This is for MESSAGE-INTEGRITY-256, but I completely forgot in my slides = that we are also proposing to do the same for MESSAGE-INTEGRITY. Would you= have some guidance also for SHA-1, or do you (and the WG) think that we sh= ould restrict truncation only to the new MESSAGE-INTEGRITY-286 attribute? >>=20 >> Thanks. >=20 > I think we should consider MESSAGE-INTEGRITY a legacy feature, and base a= ny protocol enhancements only on MESSAGE-INTEGRITY-SHA256.=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Mon Jul 25 14:29:17 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 1075012D0CA; Mon, 25 Jul 2016 14:29:11 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725212911.11445.1865.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 14:29:11 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-pmtud-02.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: Mon, 25 Jul 2016 21:29:11 -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 : Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : draft-ietf-tram-stun-pmtud-02.txt Pages : 11 Date : 2016-07-25 Abstract: This document describes a Session Traversal Utilities for NAT (STUN) usage for Path MTU Discovery (PMTUD) between a client and a server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-02 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 Tue Jul 26 00:02:26 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 3BD2C12B05B for ; Tue, 26 Jul 2016 00:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 AqJ-bjVbBS6i for ; Tue, 26 Jul 2016 00:02:23 -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 314D812B014 for ; Tue, 26 Jul 2016 00:02:22 -0700 (PDT) Received: from [192.168.40.18] (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 2E8B34281; Tue, 26 Jul 2016 09:02:19 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2016 09:02:18 +0200 Message-Id: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> To: tram@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [tram] STUNBIS: TLS verification 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: Tue, 26 Jul 2016 07:02:25 -0000 Hi! The part about TLS verification is not clearly written in the draft. Consider the following examples: 1) Configured STUN server name: =E2=80=9Csollentuna.example.com=E2=80=9D=20= Server redirects to =E2=80=9Cstockholm.example.com=E2=80=9D - which = name needs to be in the cert? 2) Configured STUN server name: =E2=80=9Corust.example.com=E2=80=9D DNS SRV leads to =E2=80=9Carlanda.example.net=E2=80=9D as first = selection - which name needs to be in the cert? 3) Configured STUN server name: =E2=80=9Cbromma.example.com=E2=80=9D Certficate has =E2=80=9C*.example.com=E2=80=9D - are wildcards = approved? (SIP doesn=E2=80=99t approve) 4) Configured STUN server name: =E2=80=9Csigtuna.example.com=E2=80=9D Cert has =E2=80=9Csigtuna.example.com=E2=80=9D in subject - but = =E2=80=9Csigtuna.example.net=E2=80=9D in SAN Is this approved? (In SIP it would not be) We need to be clear on verification procedures, especially in the case = of DNS SRV and STUN redirects. RFC 6125 is a better reference here than the old HTTP rfc. /O= From nobody Tue Jul 26 00:11:48 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 D6F5C12B024 for ; Tue, 26 Jul 2016 00:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 iiJmK8_IvEfo for ; Tue, 26 Jul 2016 00:11:46 -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 E956F12B014 for ; Tue, 26 Jul 2016 00:11:45 -0700 (PDT) Received: from [192.168.40.18] (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 0B0A94281; Tue, 26 Jul 2016 09:11:41 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2016 09:11:40 +0200 Message-Id: To: tram@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [tram] STUNBIS: Happy STUNballs 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: Tue, 26 Jul 2016 07:11:47 -0000 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. =46rom a previous NAT discovery role it=E2=80=99s = about network path discovery now. 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=E2=80=99re = 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. /O= From nobody Tue Jul 26 01:22:37 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 71D4612D69B for ; Tue, 26 Jul 2016 01:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 3we41kRR8dvv for ; Tue, 26 Jul 2016 01:22:33 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 6691912D69A for ; Tue, 26 Jul 2016 01:22:33 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id o67so185605774qke.1 for ; Tue, 26 Jul 2016 01:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vD8yI6C/54WUY+Gq6n9l5kgOxSp+9HuaZ9n96sMw9No=; b=VJsuPpbgsbOCtoM8WeY+1C9crUM9T+eW7Zt4ceszp3l3MQQ4MyyqYoD4J60lm2+2WY k6qFlhjhh46iI27w3biwsgl5dz5X4IXH8MnwaVh7OBQv29xZ+2vkbq7SU7u667EIqrRr YQpZ+tAHpdpDJxOYcDlICeycaZqNMsgKBFLmnvo3Q5icU2130FTcn6VIHCE2S85kiESm WGbp4a/bTFrqEsmO0yqn73PQKReRqyE0VF72c3+m1QhimVrn6kT+2NIsMukio7E+onJO 0w3ZyJxjTl98Zh7IdIRp5ScZHf3EsF31SM5Pqr3FjFTLUdvvJx0OXm9aXCuWBOHBTXlv B2rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vD8yI6C/54WUY+Gq6n9l5kgOxSp+9HuaZ9n96sMw9No=; b=LqdKq+E6K70ErVu7Dy2OXQN3rqZ3jKQJpkTXzJwtK4WnKrykY5nWOUrdjvI2D2sCIm rE2bMwiATjl8wqQI0iwgS+9U/oiecyGqMONn1L2UqrKUjGDRjCsfJ/FZEYYs6F/8eV9F 3G91si9R6YcNkWt7uTmtzKYXhDtOS1oEbBiyA3XvzYcDIpjsDaJc53/QRlETBb51Ledk quXK0gBhYJrs5ShqwHf1kwt7IUWKSYEdlS/5n2LpEE0DGw7N/GHU23TsuWRoTDX6YIHW my1VoDY86fz5MaOCTjp81m/08TWsMepyX4moMXqeFJrgtNoDrldvavVjdsITnj/1I7sC NJng== X-Gm-Message-State: AEkooutHqo/fNVwkyLAJKtVV5g5T8+/npSCgeyrr03jxaz/S+MuyQpJ6JQcVuD2SXWHeErCxbxHIUZYlVMSc8g== X-Received: by 10.55.78.146 with SMTP id c140mr28997456qkb.48.1469521352590; Tue, 26 Jul 2016 01:22:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 26 Jul 2016 01:22:32 -0700 (PDT) In-Reply-To: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> References: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> From: Martin Thomson Date: Tue, 26 Jul 2016 10:22:32 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] STUNBIS: TLS verification 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: Tue, 26 Jul 2016 08:22:35 -0000 I agree that 6125 is best here. Simple answers: On 26 July 2016 at 09:02, Olle E. Johansson wrote: > 1) Configured STUN server name: =E2=80=9Csollentuna.example.com=E2=80=9D > Server redirects to =E2=80=9Cstockholm.example.com=E2=80=9D - which = name needs to be in the cert? If the redirect is authenticated, then it can be stockholm > 2) Configured STUN server name: =E2=80=9Corust.example.com=E2=80=9D > DNS SRV leads to =E2=80=9Carlanda.example.net=E2=80=9D as first selec= tion > - which name needs to be in the cert? orust - we don't trust the DNS > 3) Configured STUN server name: =E2=80=9Cbromma.example.com=E2=80=9D > Certficate has =E2=80=9C*.example.com=E2=80=9D - are wildcards appro= ved? (SIP doesn=E2=80=99t approve) *.example.com should be OK > 4) Configured STUN server name: =E2=80=9Csigtuna.example.com=E2=80=9D > Cert has =E2=80=9Csigtuna.example.com=E2=80=9D in subject - but =E2= =80=9Csigtuna.example.net=E2=80=9D in SAN > Is this approved? (In SIP it would not be) no - I don't see how a complete name mismatch could ever be acceptable From nobody Tue Jul 26 01:33:15 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 8025612D85D for ; Tue, 26 Jul 2016 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zPSVRQaDsFmF for ; Tue, 26 Jul 2016 01:33:13 -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 54F6112D72A for ; Tue, 26 Jul 2016 01:33:12 -0700 (PDT) Received: from [192.168.40.18] (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 280694281; Tue, 26 Jul 2016 10:33:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 26 Jul 2016 10:33:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5540FAAA-4C4E-47AB-9F7B-16AB4B39360E@edvina.net> References: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson , "tram@ietf.org" Subject: Re: [tram] STUNBIS: TLS verification 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: Tue, 26 Jul 2016 08:33:15 -0000 > On 26 Jul 2016, at 10:22, Martin Thomson = wrote: >=20 > I agree that 6125 is best here. Simple answers: >=20 > On 26 July 2016 at 09:02, Olle E. Johansson wrote: >> 1) Configured STUN server name: =E2=80=9Csollentuna.example.com=E2=80=9D= >> Server redirects to =E2=80=9Cstockholm.example.com=E2=80=9D - = which name needs to be in the cert? >=20 > If the redirect is authenticated, then it can be stockholm =E2=80=9Ccan be=E2=80=9D :-) In SIP we always compare with the original URI and avoid redirections. In that case it=E2=80=99s =E2=80=9Csollentuna=E2=80=9D. This is clearly = something that needs to be documented. In 6125 lingo, the server name =E2=80=9Csollentuna.example.com=E2=80=9D = is the reference identifier. What you propose is that a STUN redirect change the reference identifier which I=E2=80=99m fine with. The first STUN server needs a cert for = sollentuna.example.com so we clearly trust that server. The redirect goes to stockholm and the cert in that server needs to verify for Stockholm. I think that case needs to be clear in stunbis. >=20 >> 2) Configured STUN server name: =E2=80=9Corust.example.com=E2=80=9D >> DNS SRV leads to =E2=80=9Carlanda.example.net=E2=80=9D as first = selection >> - which name needs to be in the cert? >=20 > orust - we don't trust the DNS Ok, let=E2=80=99s take the DNSsec case later. Marc and I had a draft on = that earlier that we need to revive after this is done. >=20 >> 3) Configured STUN server name: =E2=80=9Cbromma.example.com=E2=80=9D >> Certficate has =E2=80=9C*.example.com=E2=80=9D - are wildcards = approved? (SIP doesn=E2=80=99t approve) >=20 > *.example.com should be OK Following 6.4.3 in 6125 then >=20 >> 4) Configured STUN server name: =E2=80=9Csigtuna.example.com=E2=80=9D >> Cert has =E2=80=9Csigtuna.example.com=E2=80=9D in subject - but = =E2=80=9Csigtuna.example.net=E2=80=9D in SAN >> Is this approved? (In SIP it would not be) >=20 > no - I don't see how a complete name mismatch could ever be acceptable Right, if there are SAN, the Subject CNAMe must be ignored.=20 /O >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jul 26 02:06:59 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 D63681288B8 for ; Tue, 26 Jul 2016 02:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 XDHQLAEvomSn for ; Tue, 26 Jul 2016 02:06:57 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 AD198127058 for ; Tue, 26 Jul 2016 02:06:57 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id x1so460793qkb.3 for ; Tue, 26 Jul 2016 02:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=u10PEKGTDWmJbvvqHE9BDpmypKaH9PowTsgUlVarTKU=; b=lcATIF2QGLjriYi3Jzs/mAE+AoRpuOevM92qzKJFiOYwOA2DaSpohoDrMm7JOfjKSS Ea25UnnUZhSvLLdIx9e/FD2Ww4kDTAuWsUJqDVhjGn7Fv6Uq7ExgDJo8sCJcMfNBofgX GIJ00mzOWRPwSoqd6NQll2EPsooybVAU49aU9LcIU5WhiL7dIsEuZQIqmNF+JTANitag LjFwFgxPk33ta63KqGghVhk6G72r2EiIJyKx96mZj7FzWKD+IkgLE+W5cuFBqlhtZ/R5 ffh/zgAMSHq64MzReLaJBhWLQLEisEWDG/Bj/44HA+UOaz7o+UHn6tirakTenc689zkl RFpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=u10PEKGTDWmJbvvqHE9BDpmypKaH9PowTsgUlVarTKU=; b=MKR6DnIVuSbLAvr9vU+HCRd92zzVAOqcT3Gi6kuEFwfLExzBNxi9mUIYgtni0NHDnv EbLCFkYr3rRLcUqK/B7d0nIczZpuEskFkzg3z5gutwKd2dDEEDtZtgiEC7tVuTWim7JJ p1KcVD/7fvEJhzCfU/MByDciqinYLmvH86Zyad3D2+tqrJL8zF7t7hUX4BR3ctMtKbDr 6KpA4tzFzJsOjQAUdh8AH90INUwy6rPYqGiDZXpmQlQBnJIWB47P8+DbhtVR4ffp5S3e U0J7R94F0LtiNSetU2JmCKe7Bt295cA0RYpG5+mITgc8nAwHyOYkdhbwAb0Bf6WXKuF1 H4ug== X-Gm-Message-State: AEkoouvu0JIZ2q+BW7RRHeW7jIANhSuL9XiWr4xdwbipDdnYLLxuVcl7qiqvPVlan6l1tRA0SmRbqwUQaK7BwA== X-Received: by 10.233.239.149 with SMTP id d143mr28898793qkg.68.1469524016760; Tue, 26 Jul 2016 02:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 26 Jul 2016 02:06:56 -0700 (PDT) In-Reply-To: <5540FAAA-4C4E-47AB-9F7B-16AB4B39360E@edvina.net> References: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> <5540FAAA-4C4E-47AB-9F7B-16AB4B39360E@edvina.net> From: Martin Thomson Date: Tue, 26 Jul 2016 11:06:56 +0200 Message-ID: To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tram@ietf.org" Subject: Re: [tram] STUNBIS: TLS verification 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: Tue, 26 Jul 2016 09:06:59 -0000 On 26 July 2016 at 10:33, Olle E. Johansson wrote: >> If the redirect is authenticated, then it can be stockholm > =E2=80=9Ccan be=E2=80=9D :-) > In SIP we always compare with the original URI and avoid redirections. Redirects are a form of delegation that - if authenticated - can mean that you change the reference identity. That's the way that 3xx works in HTTP for example. But you could - as with SIP - decide that the reference identity does not change (see Alt-Svc in HTTP for an analogy). Thus, you need to pick one. But you do need to pick one. From nobody Tue Jul 26 02:24:07 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 3644612D0B0 for ; Tue, 26 Jul 2016 02:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8-70RaBUSKwR for ; Tue, 26 Jul 2016 02:24:04 -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 5146A12D09C for ; Tue, 26 Jul 2016 02:24:00 -0700 (PDT) Received: from [192.168.40.18] (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 7F7D8426A; Tue, 26 Jul 2016 11:23:57 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2016 11:23:57 +0200 Message-Id: To: tram@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [tram] STUNBIS: Retransmissions over TCP 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: Tue, 26 Jul 2016 09:24:05 -0000 Section 6.2.2: "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP itself, and there are no retransmissions at the STUN protocol = level.=E2=80=9D When using STUN over mobile networks, I think this is a bad assumption. We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and they = don=E2=80=99t follow the original intention of TCP. The SIP message fails, even though TCP = confirmed delivery. I=E2=80=99ve got confirmation from a few developers that they = started to send UDP-style retransmits over TCP to get around this. As a discovery protocol, I think we need STUN to discover situations = like this. I know it=E2=80=99s not religiously correct, but retransmits over TCP = unfortunately makes sense=20 in today=E2=80=99s broken network, especially for a protocol designed to = discover middle boxes. With sadness, /O= From nobody Tue Jul 26 02:24:47 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 7999B12B04B for ; Tue, 26 Jul 2016 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 3sz87DeDLPKT for ; Tue, 26 Jul 2016 02:24:43 -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 8476E12B03D for ; Tue, 26 Jul 2016 02:24:43 -0700 (PDT) Received: from [192.168.40.18] (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 EBB90426A; Tue, 26 Jul 2016 11:24:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 26 Jul 2016 11:24:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B69F8CE-4094-44A9-9D33-6879A089A859@edvina.net> <5540FAAA-4C4E-47AB-9F7B-16AB4B39360E@edvina.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson , "tram@ietf.org" Subject: Re: [tram] STUNBIS: TLS verification 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: Tue, 26 Jul 2016 09:24:45 -0000 > On 26 Jul 2016, at 11:06, Martin Thomson = wrote: >=20 > On 26 July 2016 at 10:33, Olle E. Johansson wrote: >>> If the redirect is authenticated, then it can be stockholm >> =E2=80=9Ccan be=E2=80=9D :-) >> In SIP we always compare with the original URI and avoid = redirections. >=20 > Redirects are a form of delegation that - if authenticated - can mean > that you change the reference identity. That's the way that 3xx works > in HTTP for example. But you could - as with SIP - decide that the > reference identity does not change (see Alt-Svc in HTTP for an > analogy). >=20 > Thus, you need to pick one. But you do need to pick one. Exactly - and it needs to be documented. /O From nobody Tue Jul 26 05:09:38 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 39BAF12D745 for ; Tue, 26 Jul 2016 05:09:37 -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 AtuqwwbBz050 for ; Tue, 26 Jul 2016 05:09:36 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 DCC9512D73D for ; Tue, 26 Jul 2016 05:09:35 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id x1so3663149qkb.3 for ; Tue, 26 Jul 2016 05:09:35 -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=yCpxSRpawFlUDdP3bFIb3xKRdPhLGUBncsTgiHGkO00=; b=P8VsG9XGftYGmpZejzxJuIgmAsHX4XPcPgIG7sToY7wKv+9GGD+X4A3AI8+E+QSGV0 vseMbUcNF6HbhBA3tl6di2foJqvO93pS/D38HedloDlQdFjhbcb9s/DkQTg2Zvd3FwD4 Zvu2SRr2sKYO5/0cA7/C/u9uR7g6z7YHnPjlXn1jTOcZc197GbeuYJOVLryWi2a4BGd1 KbcbQp7lX8WTsVRV6fqCiMmsUbzdQoyuWXeZIUVz/fVTqGZzn9hV3L8rhY9g5tnziXfm q37Qsb0wfBGt62LAaXqzV3XpxYUOAutH/tMlmLlIxxS8kE0+Idk226GoyhzXtWwG35v3 96+Q== 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=yCpxSRpawFlUDdP3bFIb3xKRdPhLGUBncsTgiHGkO00=; b=eCbpz0/lmDBBKyTP7oahMd/OKQnuLC/K7BY1nbd5OJ99JpgPeTr7lbLgpDsi6L48dF jn9y2rw/qpfSAiHQusd/FDYigAjub5k4qAPyH954a53iW48jdTrzt/t7AaNb09Ud0Xlz yBGcrYuf/51Ax0j2SLsiFMtzm41zkxSCZIyfYnbaE6l36/+nC5r50Ja9k3ceyZ50CyYE DJKiLJwq4LXTcDAQ9uIdVZ91HVA62yG/jOyPOMeWzaGbXjXDZ4VKmvAp0PvkqSTDj8DV MUcjRWBzAFNtxyEIZqR84ZJ42wTlFiEgVmwqoVy7P2t5ZHRYqTZuPoyO5MQWu5j8+foP qk5w== X-Gm-Message-State: AEkooutG7VieSm42GN+CDnRrTZs5bfdWOuKBSdLBfCdRHXB3O2eFx0pdCJFnwIS4Wvtoe9yqCUWkMld4zNpF8SIKZ6/P0j4dJ/xvSzcUgsr8xzGc6s6P+cYDWd3XSdwFj1lbmhSWhkGoOsP7Xw9AaAsuAjMEVCmJlTUPYBtkob8= X-Received: by 10.55.200.27 with SMTP id c27mr29710220qkj.46.1469534974758; Tue, 26 Jul 2016 05:09:34 -0700 (PDT) Received: from MacBook-Pro-de-Simon.local ([2001:470:b161:0:9de0:e13e:dc69:bdb7]) by smtp.gmail.com with ESMTPSA id a66sm356690qkg.2.2016.07.26.05.09.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 05:09:34 -0700 (PDT) To: "Olle E. Johansson" , tram@ietf.org References: From: Simon Perreault Message-ID: Date: Tue, 26 Jul 2016 08:09:30 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tram] STUNBIS: Retransmissions over TCP 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: Tue, 26 Jul 2016 12:09:37 -0000 Le 2016-07-26 Ć  05:23, Olle E. Johansson a Ć©crit : > Section 6.2.2: > > "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP > itself, and there are no retransmissions at the STUN protocol level.ā€¯ > > When using STUN over mobile networks, I think this is a bad assumption. > Weā€™ve seen many times that TCP proxys cause TCP to fail and they donā€™t follow > the original intention of TCP. The SIP message fails, even though TCP confirmed > delivery. Iā€™ve got confirmation from a few developers that they started to send UDP-style > retransmits over TCP to get around this. I think this will be met with incredulity and responses along the lines of "pcap or GTFO". :) I admit I'd like to see a more detailed description of the problem before we mandate such a profound change in the protocol. Would you be able to get one of those developers to come talk to us? > As a discovery protocol, I think we need STUN to discover situations like this. > I know itā€™s not religiously correct, but retransmits over TCP unfortunately makes sense > in todayā€™s broken network, especially for a protocol designed to discover middle boxes. To be clear: you actually mean sending a second Binding request on the *same* TCP connection, right? Not opening a new one? Simon From nobody Tue Jul 26 05:25:02 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 63A3B12D775 for ; Tue, 26 Jul 2016 05:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lKOJHVjgW7uF for ; Tue, 26 Jul 2016 05:24:58 -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 346AB12D770 for ; Tue, 26 Jul 2016 05:24:57 -0700 (PDT) Received: from [192.168.40.18] (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 8AE1F426A; Tue, 26 Jul 2016 14:24:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 26 Jul 2016 14:24:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6F618695-A2C3-4224-8392-A69C2EAE2D5D@edvina.net> References: To: Simon Perreault X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson , tram@ietf.org Subject: Re: [tram] STUNBIS: Retransmissions over TCP 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: Tue, 26 Jul 2016 12:25:01 -0000 > On 26 Jul 2016, at 14:09, Simon Perreault wrote: >=20 > Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit : >> Section 6.2.2: >>=20 >> "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP >> itself, and there are no retransmissions at the STUN protocol = level.=E2=80=9D >>=20 >> When using STUN over mobile networks, I think this is a bad = assumption. >> We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and = they don=E2=80=99t follow >> the original intention of TCP. The SIP message fails, even though TCP = confirmed >> delivery. I=E2=80=99ve got confirmation from a few developers that = they started to send UDP-style >> retransmits over TCP to get around this. >=20 > I think this will be met with incredulity and responses along the = lines > of "pcap or GTFO". :) >=20 It has been documented: https://www.cs.montana.edu/mwittie/publications/Goel16Detecting.pdf > I admit I'd like to see a more detailed description of the problem > before we mandate such a profound change in the protocol. Would you be > able to get one of those developers to come talk to us? He is doing some research for me, but I hope to get him out of the = closet. The research paper is a good start though. Clearly shows that the TCP is confirmed by a middle box in the path, not by the other end point. >=20 >> As a discovery protocol, I think we need STUN to discover situations = like this. >> I know it=E2=80=99s not religiously correct, but retransmits over TCP = unfortunately makes sense=20 >> in today=E2=80=99s broken network, especially for a protocol designed = to discover middle boxes. >=20 > To be clear: you actually mean sending a second Binding request on the > *same* TCP connection, right? Not opening a new one? I think so, yes.=20 Maybe these needs to go in another revision, but I wanted to open this can of worms for discussion.=20 /O= From nobody Tue Jul 26 05:50: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 0F3A112D8EF for ; Tue, 26 Jul 2016 05:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 EfQ9LANAxRc3 for ; Tue, 26 Jul 2016 05:50:21 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 2C43D12D927 for ; Tue, 26 Jul 2016 05:50:19 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 38so17998780iol.0 for ; Tue, 26 Jul 2016 05:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tvY0dqfy+7XTtPuzss4QtWOl4fBJn1xzp9Ip/mYqiV0=; b=mtdKIwKIyTxSnwBtfTdBSG3w6NTAzqNjPDS6CRuQ1iJjr6Nfof/wL2l+HiMuRC2mlq Ta75yteB4yYL+yff2eMXJVCElEK+3N2r7XrL5W9Is/oKy73wXG7vQ96StTtL4CtTg0zk 2j/YkSJOd//yYGyZu44l99cehnYuqvlLf+KQ36bwfNWP7h2LojDT2OxdoGe99VomRPmw ziylE7p4/wCgOlghCfzVqtUYoBJBHIrHsOwXw/TUQPwMoBDkRtYn7nxqFsOYYizB0XAL nKro3fNNy/sCqgP9peFh6+i663lzpYsyYv9h8HXy2oOxWOUUGHf7bx1jjLtBJ3MZibkp YSEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tvY0dqfy+7XTtPuzss4QtWOl4fBJn1xzp9Ip/mYqiV0=; b=RwOa2ukM7ZFyu2zJrxRJuF/4ZA2qpjhgN1v3eFecBO/AJjGSrY0zflNubjK1vyPLz/ vzvcvuKFjQaFlBqudW/Sejoj2jdEXEmZz/Yvvf+l+kBgkBbvIoAVTcRr5TGBC4482cgX 8bH4wbGga+geapne9Hb2gDKt+n+AO3V79h16nOKhx7PBsXBBpCXXx6t5VwPKNsUwmQbs xJ9kFlAAmc3bkajTCj7OCYEPCrFDYiJPBmwvdGlC2MpFgFykFoxrQm7NMXwo1wR+vyuO PwEPicGduksGyVXqiAcuin5z+MRKE5K/5uDgRgbzbLuyzSk3IZ9VUmX7og+HaNvyYDsf Z1IQ== X-Gm-Message-State: AEkooutm6ACOR7AHodydgFeY0f3L5FUbWUB4XTg707Eq1Apwhg2BPN8O6pqC/MVJqRGGsSnnoTm3+hjzHANJlg== X-Received: by 10.157.24.118 with SMTP id t51mr13432594ott.65.1469537417164; Tue, 26 Jul 2016 05:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.13.52 with HTTP; Tue, 26 Jul 2016 05:50:16 -0700 (PDT) In-Reply-To: References: From: Muthu Arul Mozhi Perumal Date: Tue, 26 Jul 2016 18:20:16 +0530 Message-ID: To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113db3e2bbfdba053889578d Archived-At: Cc: "Olle E. Johansson" , "tram@ietf.org" Subject: Re: [tram] STUNBIS: Retransmissions over TCP 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: Tue, 26 Jul 2016 12:50:23 -0000 --001a113db3e2bbfdba053889578d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The use cases I've heard are: 1. A (broken) middle box doing TCP<->UDP inter-working: If the message get lost on the UDP side and the transmissions are handled by the TCP stack (in the kernel), the middle box may not retransmit the message over UDP causing problem for endpoints. 2. Mobility: If the IP address changes, TCP may not know whether the message was sent or not. These are what I've overheard, though I haven't come across the problem myself.. Muthu On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault wrote: > Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit : > > Section 6.2.2: > > > > "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP > > itself, and there are no retransmissions at the STUN protocol level.= =E2=80=9D > > > > When using STUN over mobile networks, I think this is a bad assumption. > > We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and the= y don=E2=80=99t > follow > > the original intention of TCP. The SIP message fails, even though TCP > confirmed > > delivery. I=E2=80=99ve got confirmation from a few developers that they= started > to send UDP-style > > retransmits over TCP to get around this. > > I think this will be met with incredulity and responses along the lines > of "pcap or GTFO". :) > > I admit I'd like to see a more detailed description of the problem > before we mandate such a profound change in the protocol. Would you be > able to get one of those developers to come talk to us? > > > As a discovery protocol, I think we need STUN to discover situations > like this. > > I know it=E2=80=99s not religiously correct, but retransmits over TCP > unfortunately makes sense > > in today=E2=80=99s broken network, especially for a protocol designed t= o > discover middle boxes. > > To be clear: you actually mean sending a second Binding request on the > *same* TCP connection, right? Not opening a new one? > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113db3e2bbfdba053889578d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The use cases I've heard are:
=
1. A (broken) middle box doing TCP<->UDP inter-wor= king: If the message get lost on the UDP side and the transmissions are han= dled by the TCP stack (in the kernel), the middle box may not retransmit th= e message over UDP causing problem for endpoints.
2= . Mobility: If the IP address changes, TCP may not know whether the message= was sent or not.

Thes= e are what I've overheard, though I haven't come across the problem= myself..

Muthu
<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">
On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault &= lt;sperreault@jive= .com> wrote:
Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit :
> Section 6.2.2:
>
> "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP<= br> >=C2=A0 =C2=A0 itself, and there are no retransmissions at the STUN prot= ocol level.=E2=80=9D
>
> When using STUN over mobile networks, I think this is a bad assumption= .
> We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and th= ey don=E2=80=99t follow
> the original intention of TCP. The SIP message fails, even though TCP = confirmed
> delivery. I=E2=80=99ve got confirmation from a few developers that the= y started to send UDP-style
> retransmits over TCP to get around this.

I think this will be met with incredulity and responses along the li= nes
of "pcap or GTFO". :)

I admit I'd like to see a more detailed description of the problem
before we mandate such a profound change in the protocol. Would you be
able to get one of those developers to come talk to us?

> As a discovery protocol, I think we need STUN to discover situations l= ike this.
> I know it=E2=80=99s not religiously correct, but retransmits over TCP = unfortunately makes sense
> in today=E2=80=99s broken network, especially for a protocol designed = to discover middle boxes.

To be clear: you actually mean sending a second Binding request on t= he
*same* TCP connection, right? Not opening a new one?

Simon

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

--001a113db3e2bbfdba053889578d-- From nobody Tue Jul 26 09:59:01 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 B88DB12D15E for ; Tue, 26 Jul 2016 09:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 lp3ueMzFvlmS for ; Tue, 26 Jul 2016 09:58:58 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 2B9DE12D10F for ; Tue, 26 Jul 2016 09:58:58 -0700 (PDT) X-AuditID: c1b4fb30-57fff7000000103c-aa-579796cdf2c0 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id A0.7D.04156.DC697975; Tue, 26 Jul 2016 18:58:56 +0200 (CEST) Received: from [131.160.126.84] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.301.0; Tue, 26 Jul 2016 18:58:52 +0200 To: References: <3d8524a8-95bb-d63e-0c97-9e56140fde9b@ericsson.com> From: Gonzalo Camarillo Message-ID: <9338c4b8-3664-83a2-8e8f-d72f0ecac034@ericsson.com> Date: Tue, 26 Jul 2016 19:58:52 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3d8524a8-95bb-d63e-0c97-9e56140fde9b@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7n+6FadPDDda9lbS4fiXU4sPaC2wO TB5Llvxk8vg35ylzAFMUl01Kak5mWWqRvl0CV8a1xq+MBcvYK05Om8DawPictYuRk0NCwETi 9bs1QDYXh5DAekaJb0cns0E4axglNly4xAhSJSzgK3G67TIbiC0iICwx9+BdFhBbSMBe4tKB uWCTmAU0JU6eegxWzyZgIbHl1n2wGl6gmjPfJ4D1sgioSqz8eAKohoNDVCBGYn1fAkSJoMTJ mU/AyjkFHCTuHd8KNdJA4siiOVC2vMT2t3OYIdZqSyx/1sIygVFgFpL2WUhaZiFpWcDIvIpR tDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMCgPbvltsIPx5XPHQ4wCHIxKPLwLgqeFC7EmlhVX 5h5ilOBgVhLh/Tt1ergQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUw WSYOTqkGRgePCS37HZ7kfCsVEuHuTZzXZL3gwOPyj/u8Np3PENE39osuKQ4Uu93/ZnmRxYIn J99Yziv/fFz331Wnjo5midsmG0uYmj9eEfb19192y+/Ws/xfnYsm1i3e47mTa8FGoS8yDz6n lUdKH5c2THsYseHAjGXJzJGWWR9sO3Zs/9FuVL+XJUg2QomlOCPRUIu5qDgRAC9q34hGAgAA Archived-At: Cc: Simon Perreault Subject: Re: [tram] Dedicated reviewers needed for draft-ietf-tram-stun-pmtud 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: Tue, 26 Jul 2016 16:59:00 -0000 Hi, per our session in Berlin, we are still looking for volunteers to review this draft. Please, contact the chairs if you would like to volunteer. Thanks, Gonzalo On 07/07/2016 9:06 AM, Gonzalo Camarillo wrote: > Folks, > > we would like to get the following draft in a good-enough shape so that > we can start its WGLC in the near future. For that, we need at least two > dedicated reviewers: > > https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ > > If you would like to volunteer to review this draft, please let the > chairs know. > > We are after a general review of the draft. In addition, we would like > the dedicated reviewers to provide input on the two proposed Probing > Mechanisms (Simple and Complete). > > Thanks, > > Gonzalo > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Tue Jul 26 13:01: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 DC75212D51F; Tue, 26 Jul 2016 13:01:40 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160726200140.30953.72420.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2016 13:01:40 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-server-discovery-08.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: Tue, 26 Jul 2016 20:01:41 -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 : TURN Server Auto Discovery Authors : Prashanth Patil Tirumaleswar Reddy Dan Wing Filename : draft-ietf-tram-turn-server-discovery-08.txt Pages : 15 Date : 2016-07-26 Abstract: Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-server-discovery-08 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 Tue Jul 26 13:03:32 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 A7CDF12D5A5; Tue, 26 Jul 2016 13:03:30 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160726200330.30840.29025.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2016 13:03:30 -0700 Archived-At: Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-mobility-03.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: Tue, 26 Jul 2016 20:03:30 -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 : Mobility with TURN Authors : Dan Wing Prashanth Patil Tirumaleswar Reddy Paal-Erik Martinsen Filename : draft-ietf-tram-turn-mobility-03.txt Pages : 13 Date : 2016-07-26 Abstract: It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tram-turn-mobility-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-mobility-03 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 Wed Jul 27 00:23:25 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 BE43E12D5C2 for ; Wed, 27 Jul 2016 00:23:23 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 j2-FV1-Z6gTH for ; Wed, 27 Jul 2016 00:23:21 -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 BAA5912D1DA for ; Wed, 27 Jul 2016 00:23:20 -0700 (PDT) Received: from [192.168.40.18] (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 146D8426A; Wed, 27 Jul 2016 09:23:17 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F7624833-D2AF-4CC7-9101-A2A5484E42F6" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 27 Jul 2016 09:23:16 +0200 Message-Id: References: To: Muthu Arul Mozhi Perumal X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Simon Perreault , Olle E Johansson , "tram@ietf.org" Subject: Re: [tram] STUNBIS: Retransmissions over TCP 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: Wed, 27 Jul 2016 07:23:24 -0000 --Apple-Mail=_F7624833-D2AF-4CC7-9101-A2A5484E42F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal = wrote: >=20 > The use cases I've heard are: > 1. A (broken) middle box doing TCP<->UDP inter-working: If the message = get lost on the UDP side and the transmissions are handled by the TCP = stack (in the kernel), the middle box may not retransmit the message = over UDP causing problem for endpoints. > 2. Mobility: If the IP address changes, TCP may not know whether the = message was sent or not. >=20 > These are what I've overheard, though I haven't come across the = problem myself.. THank you for your feedback! I think there is something here to explore for STUN and the various = usages, but we may not be ready to open up StunBIS for it. It is a middlebox problem we need to = handle, and I think that STUN is a tool developed to discover middleboxes - NAT was the = first one. The STUN RTT measurement come in handy here, as the report I referred to clearly sees = different latencies depending on direction indicating that a TCP proxy was in the path. = Maybe the RTT draft needs to consider one-way too in order to assist detection? /O >=20 > Muthu >=20 > On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault > wrote: > Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit : > > Section 6.2.2: > > > > "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP > > itself, and there are no retransmissions at the STUN protocol = level.=E2=80=9D > > > > When using STUN over mobile networks, I think this is a bad = assumption. > > We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and = they don=E2=80=99t follow > > the original intention of TCP. The SIP message fails, even though = TCP confirmed > > delivery. I=E2=80=99ve got confirmation from a few developers that = they started to send UDP-style > > retransmits over TCP to get around this. >=20 > I think this will be met with incredulity and responses along the = lines > of "pcap or GTFO". :) >=20 > I admit I'd like to see a more detailed description of the problem > before we mandate such a profound change in the protocol. Would you be > able to get one of those developers to come talk to us? >=20 > > As a discovery protocol, I think we need STUN to discover situations = like this. > > I know it=E2=80=99s not religiously correct, but retransmits over = TCP unfortunately makes sense > > in today=E2=80=99s broken network, especially for a protocol = designed to discover middle boxes. >=20 > To be clear: you actually mean sending a second Binding request on the > *same* TCP connection, right? Not opening a new one? >=20 > Simon >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram = >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail=_F7624833-D2AF-4CC7-9101-A2A5484E42F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:

The use = cases I've heard are:
1. A = (broken) middle box doing TCP<->UDP inter-working: If the message = get lost on the UDP side and the transmissions are handled by the TCP = stack (in the kernel), the middle box may not retransmit the message = over UDP causing problem for endpoints.
2. = Mobility: If the IP address changes, TCP may not know whether the = message was sent or not.

These = are what I've overheard, though I haven't come across the problem = myself..
THank you for your = feedback!

I think there is something = here to explore for STUN and the various usages, but we may = not
be ready to open up StunBIS for it. It is a middlebox = problem we need to handle, and I think
that STUN is a tool = developed to discover middleboxes - NAT was the first one. The STUN = RTT
measurement come in handy here, as the report I referred = to clearly sees different latencies
depending on direction = indicating that a TCP proxy was in the path. Maybe the RTT draft = needs
to consider one-way too in order to assist = detection?

/O

Muthu

On = Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault <sperreault@jive.com> wrote:
Le = 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit :
> Section 6.2.2:
>
> "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
>    itself, and there are no retransmissions at the STUN = protocol level.=E2=80=9D
>
> When using STUN over mobile networks, I think this is a bad = assumption.
> We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and = they don=E2=80=99t follow
> the original intention of TCP. The SIP message fails, even though = TCP confirmed
> delivery. I=E2=80=99ve got confirmation from a few developers that = they started to send UDP-style
> retransmits over TCP to get around this.

I think this will be met with incredulity and responses along the = lines
of "pcap or GTFO". :)

I admit I'd like to see a more detailed description of the problem
before we mandate such a profound change in the protocol. Would you = be
able to get one of those developers to come talk to us?

> As a discovery protocol, I think we need STUN to discover = situations like this.
> I know it=E2=80=99s not religiously correct, but retransmits over = TCP unfortunately makes sense
> in today=E2=80=99s broken network, especially for a protocol = designed to discover middle boxes.

To be clear: you actually mean sending a second Binding request = on the
*same* TCP connection, right? Not opening a new one?

Simon

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

_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

= --Apple-Mail=_F7624833-D2AF-4CC7-9101-A2A5484E42F6-- From nobody Wed Jul 27 01:15:53 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 5F4E412D0AD for ; Wed, 27 Jul 2016 01:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 S6NqrZysbKTG for ; Wed, 27 Jul 2016 01:15:50 -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 8CBCD12D0A7 for ; Wed, 27 Jul 2016 01:15:50 -0700 (PDT) Received: from [192.168.40.18] (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 C5DFF426A; Wed, 27 Jul 2016 10:15:46 +0200 (CEST) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2016 10:15:46 +0200 Message-Id: To: tram@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Olle E Johansson Subject: [tram] TURN server auto-discovery 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: Wed, 27 Jul 2016 08:15:52 -0000 Sorry for being late into reviewing this document. If I am too late, my = apologies, but nevertheless here=E2=80=99s a few nits and comments: https://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-08 Section 1: - =E2=80=9CWeb Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, which are mostly based on web applications, need this immediately.=E2=80=9D When I read this in ten years time, it is no longer immediately. Please = rephrase. - =E2=80=9CThis document describes three discovery mechanisms, so as to = maximize opportunity for discovery, based on the network in which the TURN client finds itself. =E2=80=9C=20 A very complicated sentence. Can it be simplified to make reading = easier? - =E2=80=9CFor example, in case of Web Real-Time Communication (WebRTC) [I-D.ietf-rtcweb-overview] usages and related extensions, which are based on web applications, a Java Script specified TURN server MUST be considered as local configuration. =E2=80=9C I think =E2=80=9Clocal=E2=80=9D is a bad choice here - maybe = =E2=80=9Capplication-provided configuration=E2=80=9D could be an improvement? - =E2=80=9CA client can choose auto-discovery in the absence of local configuration, if local configuration doesn't work or on top of local configuration. =E2=80=9C I think local security policy may affect choice and maybe also need to = override =E2=80=9Clocal configuration=E2=80=9D=20 - =E2=80=9CAn implementation MAY give the user an opportunity (e.g., by means of configuration file options or menu items) to specify a TURN server for each address family.=E2=80=9D How do you define the implementation? The browser, the javascript = application or another TURN user, like a SIP phone? In the case of WebRTC you need to clarify your terminology - there=E2=80=99s one application running in = javascript and then you have the browser. Also remember that TURN is not only about browsers :-) - =E2=80=9CA TURN client that implements the auto discovery algorithm, = to discover TURN servers in the attached network, uses the following mechanisms for discovery:=E2=80=9D Change the list that follows to use bullets, as you later write that you = do not prescribe a strict order. Section 4.1: This section is a bit open. If I want to write a SIP specific document specifying a way to use the outbound proxy URI or a service route URI to use for TURN service discovery - will that be a standalone document or an update to this document. Maybe some requirements on other ways to select a domain name would be appropriate. Section 4.1.2: - =E2=80=9CJID : 'alice@example.com=E2=80=99=E2=80=9D You have a SIP URI and a bare JID. Maybe consider making it an XMPP URI=20= by prefixing the JID with =E2=80=9CXMPP:=E2=80=9D for clarity. Section 5: - =E2=80=9CFor example, TURN server advertises the following DNS records = :=E2=80=9D s/TURN/a TURN/ Section 9: - =E2=80=9CUse of STUN authentication is OPTIONAL for TURN servers = provided by the local network or by the access network. A network provided TURN server MAY be configured to accept Allocation requests without STUN authentication, and a TURN client MAY be configured to accept Allocation success responses without STUN authentication from a network provided TURN server. =E2=80=9C Is this text normative? If so it=E2=80=99s clearly out of scope for a = draft on auto-discovery. You also need to add text on DNSsec here. A lot of this text is good, but I have issues with it being in this = draft. Does this text normatively update another document? It covers how to set up connections more than how to discover services. Maybe how to trust the TURN server should be another draft or, if it needs to be in this = draft,=20 should be made in a separate section. If that is the case, the abstract and introduction section needs to be modified to cover this scope too. /O From nobody Wed Jul 27 05:21:59 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 0418412E0F8 for ; Wed, 27 Jul 2016 05:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 ifcKFzm7YX4z for ; Wed, 27 Jul 2016 05:21:43 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 674EA12E11A for ; Wed, 27 Jul 2016 05:21:43 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id z8so55025912ywa.1 for ; Wed, 27 Jul 2016 05:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CvzuBp5Dm63cHyeXlB0x+oJRtUKJQUuXcZMDwjcCdq0=; b=MWSLyy1gIh26L2jjTDnVFms9ors9g9WqmhZBrBqy5Y1cC1o1Ces1naREHY6j6iLg/5 bm9DnsShfWF8G6lYfDsLwCW7g2MXMNSDIKzsaXFccOpxpufw0lbVyRwMwTwTtd2p2U3s RG1SQSQE/tKqIVrt5qSeiy6md+f1Q1VXS4VZqzcrt1VGvlgHHw67ASgJNPzNLJ8y3LZj DR/CVpSYUiEDgCnEHU7nq4dVU8nB5Rqde4Dxs3Z/GHV8VnT1e/4M3CpAU8MPWdDWoWeQ qGxmsxxEeM8fUnoAamm/z+23ZqXMJbVnhkRkcNle39Y3wlIUkyhaaQvbQD1C7ESiGKlA bkCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CvzuBp5Dm63cHyeXlB0x+oJRtUKJQUuXcZMDwjcCdq0=; b=MdB+TF/1vz339mzxBsYt7M74Qx78qoMa+Ls1DWLNy91Gws3KE2/o9abvz8tX3EcB2R 0NKCr+B6QRu58H5dnBv5YjSpPxLWH6tBq9O05PU5XLWJxJnMsMyHjlPEl4Yu9kezMX/n X8c6wWRVCRKqSa8XBNJ8hLdz7yGqHfLL2Mp0DpmYtBTHLMtNEB7Dces3sjKW5pYleojg gvNv9pr+0MmB71WQlXBceDiaTn4zkCM0/65TyrrADlIMr8/D2a5eyvI/IF8PZfP3jOO2 UEM7DsEB3jzt/5rVN63+ESEVHXw/QrbwZGGuNl0egnw8CJN8ywophGy2+YaeQ/+0xqF9 GNtg== X-Gm-Message-State: AEkoout+UlbQ3Sz36GkrE/8X1B/GLcsZpAirGSsthqrY6NrgI0yySE4aOIv0WtjyOjKt2A3soAmUqgLsHWcrWQ== MIME-Version: 1.0 X-Received: by 10.37.73.195 with SMTP id w186mr24414905yba.90.1469622102545; Wed, 27 Jul 2016 05:21:42 -0700 (PDT) Received: by 10.37.231.20 with HTTP; Wed, 27 Jul 2016 05:21:42 -0700 (PDT) Received: by 10.37.231.20 with HTTP; Wed, 27 Jul 2016 05:21:42 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2016 07:21:42 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=94eb2c095566606cdd05389d0f6f Archived-At: Cc: Simon Perreault , muthu.arul@gmail.com, tram@ietf.org Subject: Re: [tram] STUNBIS: Retransmissions over TCP 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: Wed, 27 Jul 2016 12:21:48 -0000 --94eb2c095566606cdd05389d0f6f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, This conversation is starting out in the right place (thank you, Olle), and what TRAM needs to do with STUNbis NOW should stay in TRAM, but I would appreciate someone summarizing what folks are seeing, with appropriate references, to TSVAREA. The larger conversation is something TSV needs to know about. Thank you all. Spencer, as TRAM AD On Jul 27, 2016 02:23, "Olle E. Johansson" wrote: > > >> On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal wrote: >> >> The use cases I've heard are: >> 1. A (broken) middle box doing TCP<->UDP inter-working: If the message get lost on the UDP side and the transmissions are handled by the TCP stack (in the kernel), the middle box may not retransmit the message over UDP causing problem for endpoints. >> 2. Mobility: If the IP address changes, TCP may not know whether the message was sent or not. >> >> These are what I've overheard, though I haven't come across the problem myself.. > > THank you for your feedback! > > I think there is something here to explore for STUN and the various usages, but we may not > be ready to open up StunBIS for it. It is a middlebox problem we need to handle, and I think > that STUN is a tool developed to discover middleboxes - NAT was the first one. The STUN RTT > measurement come in handy here, as the report I referred to clearly sees different latencies > depending on direction indicating that a TCP proxy was in the path. Maybe the RTT draft needs > to consider one-way too in order to assist detection? > > /O >> >> >> Muthu >> >> On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault wrote: >>> >>> Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit : >>> > Section 6.2.2: >>> > >>> > "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP >>> > itself, and there are no retransmissions at the STUN protocol level.=E2=80=9D >>> > >>> > When using STUN over mobile networks, I think this is a bad assumption. >>> > We=E2=80=99ve seen many times that TCP proxys cause TCP to fail and t= hey don=E2=80=99t follow >>> > the original intention of TCP. The SIP message fails, even though TCP confirmed >>> > delivery. I=E2=80=99ve got confirmation from a few developers that th= ey started to send UDP-style >>> > retransmits over TCP to get around this. >>> >>> I think this will be met with incredulity and responses along the lines >>> of "pcap or GTFO". :) >>> >>> I admit I'd like to see a more detailed description of the problem >>> before we mandate such a profound change in the protocol. Would you be >>> able to get one of those developers to come talk to us? >>> >>> > As a discovery protocol, I think we need STUN to discover situations like this. >>> > I know it=E2=80=99s not religiously correct, but retransmits over TCP unfortunately makes sense >>> > in today=E2=80=99s broken network, especially for a protocol designed= to discover middle boxes. >>> >>> To be clear: you actually mean sending a second Binding request on the >>> *same* TCP connection, right? Not opening a new one? >>> >>> Simon >>> >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --94eb2c095566606cdd05389d0f6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear All,

This conversation is starting out in the right place (thank = you, Olle), and what TRAM needs to do with STUNbis NOW should stay in TRAM,= but I would appreciate someone summarizing what folks are seeing, with app= ropriate references, to TSVAREA.

The larger conversation is something TSV needs to know about= .

Thank you all.

Spencer, as TRAM AD

On Jul 27, 2016 02:23, "Olle E. Johansson" <oej@edvina.net> wrote:
>
>
>> On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> wrote:
>>
>> The use cases I've heard are:
>> 1. A (broken) middle box doing TCP<->UDP inter-working: If t= he message get lost on the UDP side and the transmissions are handled by th= e TCP stack (in the kernel), the middle box may not retransmit the message = over UDP causing problem for endpoints.
>> 2. Mobility: If the IP address changes, TCP may not know whether t= he message was sent or not.
>>
>> These are what I've overheard, though I haven't come acros= s the problem myself..
>
> THank you for your feedback!
>
> I think there is something here to explore for STUN and the various us= ages, but we may not
> be ready to open up StunBIS for it. It is a middlebox problem we need = to handle, and I think
> that STUN is a tool developed to discover middleboxes - NAT was the fi= rst one. The STUN RTT
> measurement come in handy here, as the report I referred to clearly se= es different latencies
> depending on direction indicating that a TCP proxy was in the path. Ma= ybe the RTT draft needs
> to consider one-way too in order to assist detection?
>
> /O
>>
>>
>> Muthu
>>
>> On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault <sperreault@jive.com> wrote:
>>>
>>> Le 2016-07-26 =C3=A0 05:23, Olle E. Johansson a =C3=A9crit : >>> > Section 6.2.2:
>>> >
>>> > "Reliability of STUN over TCP and TLS-over-TCP is ha= ndled by TCP
>>> >=C2=A0 =C2=A0 itself, and there are no retransmissions at = the STUN protocol level.=E2=80=9D
>>> >
>>> > When using STUN over mobile networks, I think this is a b= ad assumption.
>>> > We=E2=80=99ve seen many times that TCP proxys cause TCP t= o fail and they don=E2=80=99t follow
>>> > the original intention of TCP. The SIP message fails, eve= n though TCP confirmed
>>> > delivery. I=E2=80=99ve got confirmation from a few develo= pers that they started to send UDP-style
>>> > retransmits over TCP to get around this.
>>>
>>> I think this will be met with incredulity and responses along = the lines
>>> of "pcap or GTFO". :)
>>>
>>> I admit I'd like to see a more detailed description of the= problem
>>> before we mandate such a profound change in the protocol. Woul= d you be
>>> able to get one of those developers to come talk to us?
>>>
>>> > As a discovery protocol, I think we need STUN to discover= situations like this.
>>> > I know it=E2=80=99s not religiously correct, but retransm= its over TCP unfortunately makes sense
>>> > in today=E2=80=99s broken network, especially for a proto= col designed to discover middle boxes.
>>>
>>> To be clear: you actually mean sending a second Binding reques= t on the
>>> *same* TCP connection, right? Not opening a new one?
>>>
>>> Simon
>>>
>>> _______________________________________________
>>> tram mailing list
>>> tram@ietf.org
>>> https:/= /www.ietf.org/mailman/listinfo/tram
>>
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www= .ietf.org/mailman/listinfo/tram
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.iet= f.org/mailman/listinfo/tram
>

--94eb2c095566606cdd05389d0f6f-- From nobody Thu Jul 28 07:36:07 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 66E8512D776; Thu, 28 Jul 2016 07:36:02 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160728143602.12869.46019.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 07:36:02 -0700 Archived-At: Cc: draft-ietf-tram-turn-mobility@ietf.org, tram-chairs@ietf.org, tram@ietf.org, spencerdawkins.ietf@gmail.com, sperreault@jive.com Subject: [tram] Last Call: (Mobility with TURN) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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: Thu, 28 Jul 2016 14:36:02 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Mobility with TURN' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract It is desirable to minimize traffic disruption caused by changing IP address during a mobility event. One mechanism to minimize disruption is to expose a shorter network path to the mobility event so only the local network elements are aware of the changed IP address but the remote peer is unaware of the changed IP address. This draft provides such an IP address mobility solution using Traversal Using Relays around NAT (TURN). This is achieved by allowing a client to retain an allocation on the TURN server when the IP address of the client changes. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-turn-mobility/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Jul 28 07:36:48 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 2CDF512D7AD; Thu, 28 Jul 2016 07:36:36 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160728143636.12974.24934.idtracker@ietfa.amsl.com> Date: Thu, 28 Jul 2016 07:36:36 -0700 Archived-At: Cc: tram@ietf.org, tram-chairs@ietf.org, draft-ietf-tram-turn-server-discovery@ietf.org, spencerdawkins.ietf@gmail.com, sperreault@jive.com Subject: [tram] Last Call: (TURN Server Auto Discovery) to Proposed Standard X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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: Thu, 28 Jul 2016 14:36:36 -0000 The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'TURN Server Auto Discovery' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Current Traversal Using Relays around NAT (TURN) server discovery mechanisms are relatively static and limited to explicit configuration. These are usually under the administrative control of the application or TURN service provider, and not the enterprise, ISP, or the network in which the client is located. Enterprises and ISPs wishing to provide their own TURN servers need auto discovery mechanisms that a TURN client could use with no or minimal configuration. This document describes three such mechanisms for TURN server discovery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/ballot/ No IPR declarations have been submitted directly on this I-D.