From nobody Fri Aug 1 06:17:43 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6F01A0B06 for ; Fri, 1 Aug 2014 06:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csLa22VTXOeV for ; Fri, 1 Aug 2014 06:17:38 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id EE6431A0383 for ; Fri, 1 Aug 2014 06:17:37 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 29E262866A; Fri, 1 Aug 2014 13:17:37 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 17DAA2860B; Fri, 1 Aug 2014 13:17:37 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 12AFB8003C; Fri, 1 Aug 2014 13:17:37 +0000 (GMT) Message-ID: <53DB9371.4090406@akamai.com> Date: Fri, 01 Aug 2014 09:17:37 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Martin Thomson , Justin Uberti References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-M3pqGwSYIzUBkUWTulqsOViBa8 Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] ALPN identifiers for STUN and TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:17:42 -0000 I can see a potential benefit in allowing the server to avoid DTLS handshake overhead in the case where it doesn't consent to engage in TURN. I have a hard time seeing how this might come into play though. If it's not a TURN server, why was the client sent to that address in the first place? If it's illegitimate traffic, the bad actor can circumvent the advantage for the server by not sending ALPN at all, right? That leaves the case where it is a TURN server but it's already in a resource exhausted state. If it can't handle more allocations, knowing that the client will be asking for one could allow the server to minimize unnecessary DTLS overhead for a session that it can't support anyway. --Brandon On 07/31/2014 03:42 PM, Martin Thomson wrote: > On 31 July 2014 12:02, Justin Uberti wrote: >> It's not clear to me that a DTLS ALPN would be that useful for at the TURN >> server - it already knows it is getting TURN traffic. The primary advantage >> of a DTLS ALPN would seem to be for local DPI firewalls to understand that >> the DTLS flow is in fact carrying TURN traffic. > > > The only advantage I can think of, and it's probably only theoretical > at best, is to provide the client with a positive indication that the > server consents to engage in TURN. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Aug 1 06:38:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFB01ABB35 for ; Fri, 1 Aug 2014 06:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjUfNv_VCgJB for ; Fri, 1 Aug 2014 06:38:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 09A991A0024 for ; Fri, 1 Aug 2014 06:38:33 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 60C7D2866B; Fri, 1 Aug 2014 13:38:33 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 4ACA8285FC; Fri, 1 Aug 2014 13:38:33 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id E85578003C; Fri, 1 Aug 2014 13:38:32 +0000 (GMT) Message-ID: <53DB9858.9030206@akamai.com> Date: Fri, 01 Aug 2014 09:38:32 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Justin Uberti , Martin Thomson References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/cnjDU_t6IzhyjesRQ5-r5PwUdmU Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" Subject: Re: [tram] ALPN identifiers for STUN and TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 13:38:36 -0000 I've got a small concern about allowing STUN over DTLS, since it challenges some elements of the STUN security analysis from the RFC. In particular, there is the assumption that "STUN requests can be processed statelessly by a server, making such attacks hard to launch." If STUN is sent over DTLS, then the DTLS processing itself is stateful on the server side, and so STUN implementers probably need to take that into account when implementing STUN-over-DTLS. RFC5389 is a bit inconsistent in this regard, IMO, since it includes both the above statement about stateless processing and the suggestion that some attacks can be mitigated through the use of TLS. This concern isn't directly related to the ALPN discussion, though, since ALPN doesn't make it either better or worse. --Brandon On 07/31/2014 03:02 PM, Justin Uberti wrote: > Agreed. While one could certainly do STUN over DTLS, it's not clear why > one would want to do so. That said, it should work, and so I don't have > an issue with defining an ALPN for STUN. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Aug 1 08:02:39 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C591B27C6 for ; Fri, 1 Aug 2014 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDFi_c75wQoT for ; Fri, 1 Aug 2014 08:02:35 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABDEC1B27C3 for ; Fri, 1 Aug 2014 08:02:34 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so4443505wgh.8 for ; Fri, 01 Aug 2014 08:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nV+VqvnO8LP7ImpF/t0dEYlviGUu7V43ik0IeZ7A4Y0=; b=PcaTfCDpHseek6U5D468d4aspZm6FFkZct2UpOL+/iUgQYlms/evzMKSAhrevbJbIm 4LxA9xkmKefZDXQXfapvoeh+sS11Q+stlJKIIUc5TIYtmC+xPMZ0TcKWjYw4CSBjJkJM B/AVvx4uN6UfVxdVltj6CR071jPF/iazI2uEgSnziWq4xBso47DG2Ry+IkjQY0pEK113 0Ic6jNDNadmQOfD1+E1tulzgIfRrLfxZj0NJkbIUnximgaDFOWhkgd/2oJ5UfHQ/FdI8 6cpcuV5toO5dH0qHrom6NkKESMCy+nwUR1Nz9cNK3AcxmGlt+1dpPm2spXKLAgWNQRh5 Qpow== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr7458987wiv.65.1406905352938; Fri, 01 Aug 2014 08:02:32 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 1 Aug 2014 08:02:32 -0700 (PDT) Date: Fri, 1 Aug 2014 10:02:32 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d043c7f04cb785304ff92ada6 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/a2a2AP5BSjAo_kt5QPBPiwe2Uuo Subject: [tram] STUN Origin Open Issue: Size of Attribute X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:02:38 -0000 --f46d043c7f04cb785304ff92ada6 Content-Type: text/plain; charset=UTF-8 draft-ietf-tram-stun-origin-00 currently says this about the size of the Origin: It MUST contain a UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. The value of 268 is chosen to be larger than the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number. Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes. In Toronto, we discussed changing these guidelines. Here is some proposed text: It MUST contain a UTF-8 [RFC3629] encoded sequence of characters. Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes. The length and number of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation. HTTP origins are 266 characters or smaller (the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number). It is RECOMMENDED that ORIGIN attributes larger than this not be used, or be truncated. Comments and suggestions most welcome, especially about truncation. - Alan - --f46d043c7f04cb785304ff92ada6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
draft-ietf-tram-stun-origin-00 currently says this about t= he size of the Origin:

=C2=A0 =C2=A0It MUST contain= a
=C2=A0 =C2=A0UTF-8 [RFC3629] encoded sequence of characters le= ss than 268 bytes.
=C2=A0 =C2=A0The value of 268 is chosen to be larger than the maximum = 253
=C2=A0 =C2=A0character domain name plus 8 characters for the = URI scheme plus 5
=C2=A0 =C2=A0characters for the port number. = =C2=A0Senders MAY include multiple ORIGIN
=C2=A0 =C2=A0attributes in a request, and receivers MUST support parsi= ng and
=C2=A0 =C2=A0receiving multiple ORIGIN attributes.

In Toronto, we discussed changing these guidelines.= =C2=A0Here is some proposed text:

It MUST contain a UTF-8 [RFC3629] encoded sequence of c= haracters. =C2=A0Senders MAY include multiple ORIGIN attributes in a reques= t, and receivers MUST support parsing and receiving multiple ORIGIN attribu= tes. =C2=A0The length and number of ORIGINs included in a STUN message can = have a major impact on the size of a STUN packet, and could potentially cau= se UDP fragmentation. =C2=A0HTTP origins are 266 characters or smaller (the= maximum 253 character domain name plus 8 characters for the URI scheme plu= s 5 characters for the port number). =C2=A0It is RECOMMENDED that ORIGIN at= tributes larger than this not be used, or be truncated.

Comments and suggestions most welcome, especially about= truncation.

- Alan -

--f46d043c7f04cb785304ff92ada6-- From nobody Fri Aug 1 08:07:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26BB1B27E1 for ; Fri, 1 Aug 2014 08:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WP2HxGZw3Q_Z for ; Fri, 1 Aug 2014 08:07:25 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412061B27D9 for ; Fri, 1 Aug 2014 08:07:23 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so1508591wib.10 for ; Fri, 01 Aug 2014 08:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZlToEeDC/nhIZ6MiUhlYyBS6j9pqzLOOnXcQpJG7KrE=; b=m1dw239iP5u3FwcUw7zIXmPUJgii9Z+RM3CbX3h8C7NWPP79w/8ZvsSQ5UXBFq5eHU /PWxPvHybaPaQWKSyIzyLuNEP95F4gAfohHG/NMqTSKcMaNf0ADVI5NuaAUpt8z9x2qu 2jNYV0O5RwUyj0SdWMEZsyAmA2//KG52IrhY76iAIzFly0MMwIetTHPfDeFMCsfzv3v8 SswA4HEQUBT8l6s2FeM91k9xp1bwPxISVpYiLZxiOpmEO6Cf0aduGoEjYHa4SNb5Nm4Y NnH2dD7MHHWQzZD0sAr3/Tb7rs/NKCc/bq5qZp74l/5ZxpIPKyCzxZx2/15bEzyMLaoj Hrsg== MIME-Version: 1.0 X-Received: by 10.180.85.162 with SMTP id i2mr7733702wiz.53.1406905639573; Fri, 01 Aug 2014 08:07:19 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Fri, 1 Aug 2014 08:07:19 -0700 (PDT) Date: Fri, 1 Aug 2014 10:07:19 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444e9cbe11faf04ff92be0f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/g-7ulC4DLbo3GAWmnzoRYn0Mvp4 Subject: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:07:27 -0000 --f46d0444e9cbe11faf04ff92be0f Content-Type: text/plain; charset=UTF-8 In draft-ietf-tram-stun-origin-00, the Security Considerations says: The STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request. However, MESSAGE- INTEGRITY is not present in the initial STUN message sent, so the initial ORIGIN attribute will not have integrity protection and hence could be modified or removed from a STUN request without the server knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY attribute will provide integrity protection for the contents of the ORIGIN attribute. The strength of this protection is a function of the secret used to generate the MESSAGE-INTEGRITY value. Justin has proposed changing it to: The STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request. However, when using STUN's long-term credential mechanism, as is done in TURN, MESSAGE- INTEGRITY is not present in the initial STUN message sent, and so the initial ORIGIN attribute will not have integrity protection. Hence, it could be modified or removed from a STUN request without the server knowing, which could affect the server's choice of REALM. With the long-term credential mechanism, subsequent STUN requests will contain the MESSAGE-INTEGRITY attribute and will provide integrity protection for the contents of the ORIGIN attribute(s). To mitigate any potential concerns arising from the unprotected attribute in the initial message, servers SHOULD verify that the ORIGIN attribute(s) present in the authenticated STUN requests match those that were received in the initial, unauthenticated requests. The strength of the integrity protection is a function of the secret used to generate the MESSAGE-INTEGRITY value. Anyone object to this clarification? Any other suggested edits to the Security Considerations section? - Alan - --f46d0444e9cbe11faf04ff92be0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In draft-ietf-tram-stun-origin-00, the Security Consi= derations says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN= MESSAGE-INTEGRITY attribute can provide integrity protection
=C2= =A0 =C2=A0for all attributes present in a STUN request. =C2=A0However, MESS= AGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -
--f46d0444e9cbe11faf04ff92be0f-- From nobody Fri Aug 1 08:42:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A964D1A00F6 for ; Fri, 1 Aug 2014 08:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 djmwWPrqEm0R for ; Fri, 1 Aug 2014 08:42:56 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454E31A007A for ; Fri, 1 Aug 2014 08:42:56 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id o6so3237948oag.11 for ; Fri, 01 Aug 2014 08:42:55 -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:content-type; bh=LIKtp74sCMWyF+QfnMbXvpVOC5YWOvlBJsY7c7spnXE=; b=QQKzRNBxqADfqGKSu0B3jV8bU580GTa+zP5LWrtnZ7RRNjzVF0jMcTMBM3MDaJ2+bl MNVkuSDWFYilvMDYh0mDx7LVqWQmIpqY0V1gKvf/hdYjWaNcG0rwUhpQLHkZZD2ghk5C wp7jpWJinn5m1kaKE6+sBIIxgQ7l5nWHX9aF09s170fTWOCobD/BrmGc01L44yDm3aH3 UvvDsQcpNPNr+z6gjTKUVQjG8/FOQgX+nf7TaI6cN/e7xLCCmyfgGesp3mazuiC69m1p xizTtfJyyGhezko4EMyVINMPd/fjIWLEv1ZmPHRICUqRU3c/pdL8zRqF/Yv/T3Sa45YK jEDQ== MIME-Version: 1.0 X-Received: by 10.60.176.225 with SMTP id cl1mr9447193oec.36.1406907775217; Fri, 01 Aug 2014 08:42:55 -0700 (PDT) Received: by 10.60.134.232 with HTTP; Fri, 1 Aug 2014 08:42:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 1 Aug 2014 08:42:55 -0700 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7bd75e642c753b04ff933e71 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7z80JfAA_bSakYxHnj7wjCGFq4g Cc: "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 15:42:57 -0000 --047d7bd75e642c753b04ff933e71 Content-Type: text/plain; charset=UTF-8 I agree with the changes. Thanks Oleg On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston wrote: > In draft-ietf-tram-stun-origin-00, the Security Considerations says: > > The STUN MESSAGE-INTEGRITY attribute can provide integrity protection > for all attributes present in a STUN request. However, MESSAGE- > INTEGRITY is not present in the initial STUN message sent, so the > initial ORIGIN attribute will not have integrity protection and hence > could be modified or removed from a STUN request without the server > knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY > attribute will provide integrity protection for the contents of the > ORIGIN attribute. The strength of this protection is a function of > the secret used to generate the MESSAGE-INTEGRITY value. > > Justin has proposed changing it to: > > The STUN MESSAGE-INTEGRITY attribute can provide integrity protection > for all attributes present in a STUN request. However, when using > STUN's long-term credential mechanism, as is done in TURN, MESSAGE- > INTEGRITY is not present in the initial STUN message sent, and so the > initial ORIGIN attribute will not have integrity protection. Hence, > it could be modified or removed from a STUN request without the server > knowing, which could affect the server's choice of REALM. > > With the long-term credential mechanism, subsequent STUN requests will > > contain the MESSAGE-INTEGRITY attribute and will provide integrity > protection > for the contents of the ORIGIN attribute(s). To mitigate any potential > concerns > arising from the unprotected attribute in the initial message, servers > SHOULD > verify that the ORIGIN attribute(s) present in the authenticated STUN > requests > match those that were received in the initial, unauthenticated requests. > > The strength of the integrity protection is a function of > the secret used to generate the MESSAGE-INTEGRITY value. > > Anyone object to this clarification? Any other suggested edits to the > Security Considerations section? > > - Alan - > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7bd75e642c753b04ff933e71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with the changes.

Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <alan.b.= johnston@gmail.com> wrote:
In draft-ietf-tram-stu= n-origin-00, the Security Considerations says: =C2=A0=C2=A0

<= /div>
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide int= egrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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


--047d7bd75e642c753b04ff933e71-- From nobody Fri Aug 1 15:41:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81D1A0205 for ; Fri, 1 Aug 2014 15:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 gub0hif62AnI for ; Fri, 1 Aug 2014 15:41:06 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2148A1A0181 for ; Fri, 1 Aug 2014 15:41:05 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id le20so7768321vcb.28 for ; Fri, 01 Aug 2014 15:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rMzzCXlcW7O4OCniXgQxnMylgVbktKqKxfN0ufMRvzk=; b=VNCActLIW3kH6OXqNWc0GUoXbvxw/iLnNSqXBDDNxzQPeeTZX5COf2jPVHcx4C3Gpz F/I6vb5ya74fRH5KDWYZu4aqtpLpXH+S0XvwqpRODyK6FL8JJS0Fu47beEZ4xVoBIMMj tJ6GX+lUE1r7pvP2X+bhe5l+BDmc4NMVc8AmSUT7+e6ny0deq3cpSNGojBW8XsH8MXkp o3T+eYLHJXrREcpz+wHU3amWq5MfmQCOVAsXO4eRTArmOiSffxpVqu0Vz2d72pfqL5Hn s4VFLHguYSD0QwXEnAUg+1WhSciAzh+KaYlPGI/hSGJXaBFjc/rtEwPoEO3M+m6rp2J6 MQiA== 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-type; bh=rMzzCXlcW7O4OCniXgQxnMylgVbktKqKxfN0ufMRvzk=; b=kmc0KzC5k7kXYgMj7KfDvuNtcBjWbEO7ez5shWdftMPtqd1dUQBiXZAg6JOJOVbtdU 06XUNilSGoWeww9G4KVUaRvLED9CV9txpA9Nh+/ZiYVHGelVjG5/Svb0PYeiHxwdY09T 8Bjbr1KjmjbDd3gdZgacTWuHyIT8Xyp3rcAjtC248dONzv2ud6IJulwv6Q7tQ7MbZyMU 2A/gI9x8C7SlgKlc3CPKWSV9s/26hOlFq/g/lrjiiKZ4F0HRkmlxLtjwvBi5VVmuLeDP Uo/khnHJiN/QshAe/NIo4PMS5nYFZUaJTmFUwDGrWlX92mAJBGwxTPiFpjVQrD1N1AOE pc7w== X-Gm-Message-State: ALoCoQk6GHKnxaD9Y4J98h3F7G8smua7tXAdb72DGhkyI5GAvuf2IMiFheoL7xd7t9VR7Dpeb38h X-Received: by 10.52.61.99 with SMTP id o3mr8663022vdr.46.1406932865135; Fri, 01 Aug 2014 15:41:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 1 Aug 2014 15:40:44 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 1 Aug 2014 15:40:44 -0700 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a113403d0a64f5f04ff9915c7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iS5SO8JiqRsmJNduNUYkVFcaEXQ Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:41:08 -0000 --001a113403d0a64f5f04ff9915c7 Content-Type: text/plain; charset=UTF-8 I realized when looking at a code review for this that the stateless-stack approach makes it difficult to enforce this as written. Instead, I think the advice should be that the ORIGIN attributes in the authenticated request MUST be verified to be consistent with the REALM value that is supplied. On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko wrote: > I agree with the changes. > > Thanks > Oleg > > > On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston > wrote: > >> In draft-ietf-tram-stun-origin-00, the Security Considerations says: >> >> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >> for all attributes present in a STUN request. However, MESSAGE- >> INTEGRITY is not present in the initial STUN message sent, so the >> initial ORIGIN attribute will not have integrity protection and hence >> could be modified or removed from a STUN request without the server >> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY >> attribute will provide integrity protection for the contents of the >> ORIGIN attribute. The strength of this protection is a function of >> the secret used to generate the MESSAGE-INTEGRITY value. >> >> Justin has proposed changing it to: >> >> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >> for all attributes present in a STUN request. However, when using >> STUN's long-term credential mechanism, as is done in TURN, MESSAGE- >> INTEGRITY is not present in the initial STUN message sent, and so the >> initial ORIGIN attribute will not have integrity protection. Hence, >> it could be modified or removed from a STUN request without the server >> knowing, which could affect the server's choice of REALM. >> >> With the long-term credential mechanism, subsequent STUN requests will >> >> contain the MESSAGE-INTEGRITY attribute and will provide integrity >> protection >> for the contents of the ORIGIN attribute(s). To mitigate any >> potential concerns >> arising from the unprotected attribute in the initial message, servers >> SHOULD >> verify that the ORIGIN attribute(s) present in the authenticated STUN >> requests >> match those that were received in the initial, unauthenticated >> requests. >> >> The strength of the integrity protection is a function of >> the secret used to generate the MESSAGE-INTEGRITY value. >> >> Anyone object to this clarification? Any other suggested edits to the >> Security Considerations section? >> >> - Alan - >> >> _______________________________________________ >> 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 > > --001a113403d0a64f5f04ff9915c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I realized when looking at a code review for this that the= stateless-stack approach makes it difficult to enforce this as written. In= stead, I think the advice should be that the ORIGIN attributes in the authe= nticated request MUST be verified to be consistent with the REALM value tha= t is supplied.


On Fri, Aug 1= , 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
I agree with the = changes.

Thanks
Oleg


On Fri, Aug 1, 20= 14 at 8:07 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-tram-stun-origin-00, the Security Consideration= s says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can p= rovide integrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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



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


--001a113403d0a64f5f04ff9915c7-- From nobody Fri Aug 1 15:59:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3241A019A for ; Fri, 1 Aug 2014 15:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 JdG9hOAK_rdr for ; Fri, 1 Aug 2014 15:59:15 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4063F1A0191 for ; Fri, 1 Aug 2014 15:59:15 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so7715577vcb.5 for ; Fri, 01 Aug 2014 15:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ifdw2oFL/T1A8hnVBDJrJy0C+LU68cK9xwc5NW8sNuU=; b=XadQ6cvHq7+WJYbsxGnIvtwjttr1Mo5zd/dO9IPGfkka2cfcvy6ps5TzlHGzeHT+vu OvzXMaVWXLMfrReucQPrp2A2XjxFQZqTkmN4enHTAVl4UqDMkfYjHTnLsWbqLrz3oj3G Cm3SWVCf470R5RDLy1OnTVO8Ni8V70AYiYi40+P0dSpEBKYRsFz1LkmXwTv04w478UJK lPxaeQQSIRtKbvZ43MZkWVkuepJgbvOpVTroY4sqTNt4g3sA0dIlhnbFtPjokgXJEUz/ +jsNvxtnCjEiL+MXoOuOf8wnlIgDj48tUTvjUii2k14JMjyg9+P2tEIAAME7TyTrgKEY flKg== 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-type; bh=ifdw2oFL/T1A8hnVBDJrJy0C+LU68cK9xwc5NW8sNuU=; b=PeUlfwH9anBD4hjphU5No0/rW6hBxxd3Asl/FnjBOs7ZCkBTN+gUUGK8k2oGfsr1/f XAN/VsqATa/3j+N1uM+v1cmRa2W1bNzfJU3hL6watRgVMKubvcsMyfCDe4GIgx8Qdqz4 qWi7AVHUz0MTNTJ/d2AP86n2GZecfGuG2U3uNLtJ/XEKQqWh+IiJX868TrVlaRYlkku2 7dbpVcIKgCKQd+8/1xug9ZXaRnNv+ZlQkXv1h/tBcKFAYrE03YgMCDdiObHDtlAmbp+j Q6KpmCQrRKpw9t3abbNtCSYeTuNGLLlgQJ7R1y1AyQBM4AJW3tKC0/ub2Puecdwvd/b5 IJqA== X-Gm-Message-State: ALoCoQmOBSUQg92Ggo+ddzJFSMETlVmdtH4x5g4VxYkbdIgXtXV02ZHS3CVQ3F9LKLT+2S5uK6Oo X-Received: by 10.221.41.135 with SMTP id tu7mr6498230vcb.70.1406933954326; Fri, 01 Aug 2014 15:59:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 1 Aug 2014 15:58:54 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 1 Aug 2014 15:58:54 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=001a1133901c92223804ff9956cf Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ttodnihtMftp-jtx43EaXlStkrU Cc: "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Size of Attribute X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:59:17 -0000 --001a1133901c92223804ff9956cf Content-Type: text/plain; charset=UTF-8 On Fri, Aug 1, 2014 at 8:02 AM, Alan Johnston wrote: > draft-ietf-tram-stun-origin-00 currently says this about the size of the > Origin: > > It MUST contain a > UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. > The value of 268 is chosen to be larger than the maximum 253 > character domain name plus 8 characters for the URI scheme plus 5 > characters for the port number. Senders MAY include multiple ORIGIN > attributes in a request, and receivers MUST support parsing and > receiving multiple ORIGIN attributes. > > In Toronto, we discussed changing these guidelines. Here is some proposed > text: > > It MUST contain a UTF-8 [RFC3629] encoded sequence of characters. Senders > MAY include multiple ORIGIN attributes in a request, and receivers MUST > support parsing and receiving multiple ORIGIN attributes. The length and > number of ORIGINs included in a STUN message can have a major impact on the > size of a STUN packet, and could potentially cause UDP fragmentation. HTTP > origins are 266 characters or smaller (the maximum 253 character domain > name plus 8 characters for the URI scheme plus 5 characters for the port > number). It is RECOMMENDED that ORIGIN attributes larger than this not be > used, or be truncated. > 267 including the colon between domain and port. (272 with type and length and padding). > Comments and suggestions most welcome, especially about truncation. > Truncating origins seems like dangerous advice; I don't know what a server would do with a truncated origin. I would recommend that we say that the total size of ORIGIN attributes SHOULD not be more than 272 bytes, and implementations should drop ORIGINs as needed in order to stay under this limit, possibly sending none at all. The TURN server may fail the request as a result, but that's at least a deterministic failure. > > - Alan - > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a1133901c92223804ff9956cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Aug 1, 2014 at 8:02 AM, Alan Johnston <= ;alan.b.john= ston@gmail.com> wrote:
draft-ietf-tram-stun-origin-00 currently = says this about the size of the Origin:

=C2=A0 =C2=A0It MUST contain a
=C2=A0 =C2=A0U= TF-8 [RFC3629] encoded sequence of characters less than 268 bytes.
=C2=A0 =C2=A0The value of 268 is chosen to be larger than the maximum = 253
=C2=A0 =C2=A0character domain name plus 8 characters for the = URI scheme plus 5
=C2=A0 =C2=A0characters for the port number. = =C2=A0Senders MAY include multiple ORIGIN
=C2=A0 =C2=A0attributes in a request, and receivers MUST support parsi= ng and
=C2=A0 =C2=A0receiving multiple ORIGIN attributes.

In Toronto, we discussed changing these guidelines.= =C2=A0Here is some proposed text:

It MUST contain a UTF-8 [RFC3629] encoded sequence of c= haracters. =C2=A0Senders MAY include multiple ORIGIN attributes in a reques= t, and receivers MUST support parsing and receiving multiple ORIGIN attribu= tes. =C2=A0The length and number of ORIGINs included in a STUN message can = have a major impact on the size of a STUN packet, and could potentially cau= se UDP fragmentation. =C2=A0HTTP origins are 266 characters or smaller (the= maximum 253 character domain name plus 8 characters for the URI scheme plu= s 5 characters for the port number). =C2=A0It is RECOMMENDED that ORIGIN at= tributes larger than this not be used, or be truncated.

267 including the colon between doma= in and port. (272 with type and length and padding).



Comments and suggestions most welcome, especially about= truncation.

Truncating origins= seems like dangerous advice; I don't know what a server would do with = a truncated origin. I would recommend that we say that the total size of OR= IGIN attributes SHOULD not be more than 272 bytes, and implementations shou= ld drop ORIGINs as needed in order to stay under this limit, possibly sendi= ng none at all. The TURN server may fail the request as a result, but that&= #39;s at least a deterministic failure.=C2=A0
=

- Alan -



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


--001a1133901c92223804ff9956cf-- From nobody Mon Aug 4 05:43:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9AB1B2AA4 for ; Mon, 4 Aug 2014 05:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryOm9xasBZda for ; Mon, 4 Aug 2014 05:43:08 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43E21B2AA3 for ; Mon, 4 Aug 2014 05:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3551; q=dns/txt; s=iport; t=1407156188; x=1408365788; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CpWUlbzJl2cMQ/QMjz8r6rAzcdHkskVNBOYhmbxofv0=; b=BaQVYMrLDHNAvDNkt20vmOQBTN6xKVKa3/plceti0w2Ftkj6DQLQV58c mtffF7HOkj84c17ustJAGCJ6Tr7ch6aiXjOdd/t+iFVIfftFDf61McBZ6 zivUBceYmcg84WaahRx7qfLmoJwRgQM7Fi13jo811iiMBMH1wgoz6Dvu4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAMR+31OtJV2T/2dsb2JhbABQCoJHRoEpBNN1AYEQFneEAwEBAQR5EAIBCAQKAwMBAigHIREUCQgCBAENBYguAxG9bQ2HABeNH4FRSxEHhEsBBIR/ApR+ggeON4Yog01sgUY X-IronPort-AV: E=Sophos;i="5.01,798,1400025600"; d="scan'208,217";a="344935321" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 04 Aug 2014 12:43:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s74Ch7xs015754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 12:43:07 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.100]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 07:43:06 -0500 From: "Prashanth Patil (praspati)" To: Justin Uberti , Martin Thomson Thread-Topic: [tram] ALPN identifiers for STUN and TURN Thread-Index: AQHPrOz4Nz5dmIDv40+WJQ6MP8NI+Zu63f4AgAY7cQA= Date: Mon, 4 Aug 2014 12:43:06 +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.4.3.140616 x-originating-ip: [173.39.66.146] Content-Type: multipart/alternative; boundary="_000_D0057D7146041praspaticiscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Qm9Q_4pI-O2DOLJUMht_ftOFMdw Cc: "tram@ietf.org" Subject: Re: [tram] ALPN identifiers for STUN and TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 12:43:09 -0000 --_000_D0057D7146041praspaticiscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right, the intent was that it could be useful for a firewall to identify a = (D)TLS flow as TURN traffic, especially when sent over 443. -Prashanth From: Justin Uberti > Date: Friday, August 1, 2014 12:32 AM To: Martin Thomson > Cc: Prashanth Patil >, "tram@= ietf.org" > Subject: Re: [tram] ALPN identifiers for STUN and TURN It's not clear to me that a DTLS ALPN would be that useful for at the TURN = server - it already knows it is getting TURN traffic. The primary advantage= of a DTLS ALPN would seem to be for local DPI firewalls to understand that= the DTLS flow is in fact carrying TURN traffic. --_000_D0057D7146041praspaticiscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <83E7A570B8A54641AEA6288405A1B072@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Right, the intent was that it could be useful for a firewall to identi= fy a (D)TLS flow as TURN traffic, especially when sent over 443.

-Prashanth

From: Justin Uberti <juberti@google.com>
Date: Friday, August 1, 2014 12:32 = AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Prashanth Patil <praspati@cisco.com>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] ALPN identifier= s for STUN and TURN

It's not clear to me that a DTLS ALPN would be that useful for at the TURN serv= er - it already knows it is getting TURN traffic. The primary advantage of = a DTLS ALPN would seem to be for local DPI firewalls to understand that the= DTLS flow is in fact carrying TURN traffic. --_000_D0057D7146041praspaticiscocom_-- From nobody Mon Aug 4 11:36:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA311A00DF for ; Mon, 4 Aug 2014 11:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGzPc_LdxuL5 for ; Mon, 4 Aug 2014 11:36:03 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7101A00F1 for ; Mon, 4 Aug 2014 11:36:02 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so8152210wgh.8 for ; Mon, 04 Aug 2014 11:36:01 -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:content-type; bh=Wk3l86XsfWS7N0AC82ugsFTZW78/7Ddu01AZ73pfBpY=; b=VL/RZ+wYuxpVne7JowffyUaqPgERTBphF8/NWwCPOeTXPAGNG6nFDetDj1YcreXij5 p6lodzRhEHtHANa5r38wrd3hWRPiK2l5JQPbPvegyRaogh9gbjyapjJB1K8/TYSqPglY SO2ejAT+w904BnWOKuf9bVV+WtB2CdsY1oXql7pVldLPcdsWatlq4nXaorGjuUjdCE/P X+24tTuiOYqg5Ll+pGwyiCfaEBZupbVCqIKlXluwvn2qrxhhhKfK2ASofCRbanV/C+Gv OLxEXZ+cpBJM1xp7IvIEHKY/HrTAGoy16yQig9CSooveOQ0+y249pLRX/fXBhMnos/H+ eL6g== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr31829858wib.65.1407177361559; Mon, 04 Aug 2014 11:36:01 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Mon, 4 Aug 2014 11:36:01 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Aug 2014 11:36:01 -0700 Message-ID: From: Martin Thomson To: "Prashanth Patil (praspati)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RlVZd9CvjcXyEOqsiQJ3Q_FMxxU Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] ALPN identifiers for STUN and TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:36:04 -0000 On 4 August 2014 05:43, Prashanth Patil (praspati) wrote: > Right, the intent was that it could be useful for a firewall to identify a > (D)TLS flow as TURN traffic, especially when sent over 443. Note however that this is nearly information-free. A TURN binding can be used for literally anything. From nobody Wed Aug 6 07:57:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FC1B2802 for ; Wed, 6 Aug 2014 07:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB7KhkdhtgIl for ; Wed, 6 Aug 2014 07:57:21 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7AEC1A0312 for ; Wed, 6 Aug 2014 07:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1407337040; x=1408546640; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=59aCnPMRKSzzm4SbhmcwC+Aj12aqGoDvHa4l4NOOfjI=; b=NLOWtIwSZLxFQETy+GZVx6g4vUIxVxsLWtpTzFfI+bGP7bt1aw59EsEC LTuC6T+1t7/9ZQau2dJU1MZ5bjB8h9NvyD0lUTTSYKffDdjpOEIC4FJpw aIA++8x55R9cDDSR/P8SeFsKjoMtWFdh74az470DGiqr925d8lGmA1rCw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUFAJVB4lOtJA2H/2dsb2JhbABQCoMNUlcEzBsKh0gBgRMWd4QDAQEBBAEBATc0CwwGAQgRBAEBAQoUCS4LFAkJAQQBDQUIiDoNwx4TBI5wKzENgymBHAWwd4NUbIFG X-IronPort-AV: E=Sophos;i="5.01,812,1400025600"; d="scan'208";a="66997662" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 06 Aug 2014 14:57:20 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s76EvKPg013751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 14:57:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 09:57:20 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Martin Thomson , "Prashanth Patil (praspati)" Thread-Topic: [tram] ALPN identifiers for STUN and TURN Thread-Index: Ac+xhrUUUdLgOB58SMy9kDG/TDbbHg== Date: Wed, 6 Aug 2014 14:57:19 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28301E4E@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.67.151] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ttdnOQ35CSowOCK1wb75iXPDTgU Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] ALPN identifiers for STUN and TURN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 14:57:22 -0000 Protocols like peer to peer streaming protocol (PPSP) are also using TURN t= o upload/download content (or chunks) from remote peers. The TURN APLN ide= ntifier would be useful for coarse-grain policy enforcement on firewall to = ensure that only the Enterprise TURN server is selected by the clients for = various applications and the TURN servers provided by application server an= d access network are not used. If additional information is also conveyed l= ike WebRTC, PPSP etc. it could help firewalls to enforce granular policies.= =20 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Tuesday, August 05, 2014 12:06 AM > To: Prashanth Patil (praspati) > Cc: tram@ietf.org; Justin Uberti > Subject: Re: [tram] ALPN identifiers for STUN and TURN >=20 > On 4 August 2014 05:43, Prashanth Patil (praspati) > wrote: > > Right, the intent was that it could be useful for a firewall to > > identify a (D)TLS flow as TURN traffic, especially when sent over 443. >=20 >=20 > Note however that this is nearly information-free. A TURN binding can be > used for literally anything. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sun Aug 10 13:37:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EA51A0354 for ; Thu, 31 Jul 2014 03:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccsFXnu8FVGJ for ; Thu, 31 Jul 2014 03:58:21 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455AA1A0343 for ; Thu, 31 Jul 2014 03:58:21 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id h15so9144536igd.5 for ; Thu, 31 Jul 2014 03:58:20 -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-type:content-transfer-encoding; bh=US63IylXVA1NLllLx7YpWR27c0x+ha0dZVSYAXCIQeo=; b=RnR88nZuW92cbwdVDmsa7Ltnmm9aMUHVLgdeXr1zCtIPPmhieM80pdVmU8dYvs5Jvg WABS6smDV0htBjUq980XMHkgI/AG2uYYukn1uGGg2eQKYVKe4xjZ+bpxigJ9a7xiyxad KFgnhl/uQVljJ70P8AbquzCe7GqN2L1iwAS7OfMxFszQgzbcAeTxpCerYBoFx8XAE+WJ EyG97plFQ+qWt7lyOXinyLoArGf0xHmL63x74VYvEXpRSGCbxOLU6lm2f+R7DyDgSKom p+T9uGgD4LxrL7Sf4jIEdGy2U2lKRsAJpvjFq2froFAFJfHw+mINwqREdRWH1lyJxMii /oMw== X-Received: by 10.43.6.195 with SMTP id ol3mr14113336icb.86.1406804300660; Thu, 31 Jul 2014 03:58:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.251.175 with HTTP; Thu, 31 Jul 2014 03:58:00 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A282FC8D2@xmb-rcd-x10.cisco.com> References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <53D796E5.9040009@jive.com> <913383AAA69FF945B8F946018B75898A282FC8D2@xmb-rcd-x10.cisco.com> From: Varun Singh Date: Thu, 31 Jul 2014 13:58:00 +0300 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PJ07IfZej6MKMFZkDtrA7XLg_88 X-Mailman-Approved-At: Sun, 10 Aug 2014 13:37:01 -0700 Cc: Simon Perreault , "varun.singh@iki.fi" , "tram@ietf.org" , Jonathan Lennox , Justin Uberti Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 10:58:25 -0000 On Tue, Jul 29, 2014 at 7:24 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Tuesday, July 29, 2014 6:13 PM >> To: Justin Uberti; Jonathan Lennox >> Cc: tram@ietf.org >> Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it= not >> converge? >> >> Le 2014-07-28 20:56, Justin Uberti a =C3=A9crit : >> > I agree this is a real problem - while A' might be a better match for >> > B, A might be better for B', just due to internet routing oddities. So >> > you could end up switching ad nauseam. >> >> Agreed. >> >> > Also: >> > 2) Ted's point that "closer" doesn't always mean "better" - A often >> > won't have the information to know for sure that A' is better for B. >> >> I don't think that the problem is that it won't work: we know from Akama= i's >> example that it can work. What Ted asked, as I understand it, is for the= next >> draft revision to describe the knowledge that is required in order to be= able to >> perform the kind of server selection for which the draft defines signali= ng. >> >> > 3) The general mechanism is unlikely to produce the desired results, >> > because the ALTERNATE-SERVER will typically arrive after gathering has >> > completed - and thus you need to do an ICE restart to actually use the >> > new TURN server. Since the timing of ALTERNATE-SERVER will be >> > different for both a and b, it will be difficult to get this properly = synchronized. >> > >> > If we could do a synchronized restart though, one could treat the >> > ALTERNATE-SERVER from the original TURN server as a suggestion, and >> > then during the restart, allocate candidates from both. Then, using >> > the actual RTTs that are observed amongst the permutations (A->B, >> > A->B', A'->B, A'->B'), the CONTROLLING side can determine the best pat= h to >> use. >> >> Would be nice if we had an ICE-RTT draft that we could point to... ;) > > MPRTP already uses RTT and other path characteristics to load balance the= media stream across different interfaces, it may help to look into the wor= k they have already done. > As Jonathan pointed out, RTT can be calculated from the STUN transactions messages. but the endpoint may also want to prefer a less lossy path. This too may be calculated using STUN retransmissions or counting the numbe of RTOs. It may not matter when there is only one interface, but when choosing between multiple interfaces/paths (3G, WLAN, etc.) to a TURN server. Since this proposal is about redirecting the peer to a different TURN server, the redirecting server probably already knows the throughput or the capacity of the new TURN server and took that into consideration before redirecting the peers. MPRTP is slightly different because it does not know the throughputs of each path before hand and needs to send data on those paths to make appropriate load balancing decisions. (it may of course learn some metrics from processing connectivity checks). Cheers, Varun > -Tiru > >> >> 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 --=20 http://www.netlab.tkk.fi/~varun/ From nobody Sun Aug 10 13:37:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719BB1A0AAE for ; Thu, 31 Jul 2014 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmWicz5EWNIN for ; Thu, 31 Jul 2014 04:04:42 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4231A0AAD for ; Thu, 31 Jul 2014 04:04:26 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id lx4so3519725iec.3 for ; Thu, 31 Jul 2014 04:04:25 -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-type; bh=qy5kqG2lKz/HErmkWivgPsYnKq7/lJKLCUVZrJo1U5w=; b=qyJk6eASQ2bpI8vEdpmXqm+J+Ms6Kh3JaNdj2s6tlLrBbBfNcvAIEezd+vmsZaC48r qiv0hIYDDFeINq52gW7efP+eUGMM9BXOi2ZJOJ3v9GjZuYFbQWBkJ46dZxHikpa7QUs9 Ium0e2GdSsWC/MiaCRr66Tl8b/I5aDRKJ3qV5DRoySv/iRtA08o0D+lmRrurpMM4QaaY gTp8HX4ReuYSKJ3LYRKsSK6+Vf8M0RRIhJofq9ZgGDSzu+2ywHlYnra8U8femH9uFCLe SojkukNjRbWl0hXYvRe3LtaQTHz/im8gtDi8K/LN3gE06sm25q5LeL0O9yDDo8HuAlIG 8Crg== X-Received: by 10.50.107.7 with SMTP id gy7mr17600283igb.15.1406804664418; Thu, 31 Jul 2014 04:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.251.175 with HTTP; Thu, 31 Jul 2014 04:04:04 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A282FCF31@xmb-rcd-x10.cisco.com> From: Varun Singh Date: Thu, 31 Jul 2014 14:04:04 +0300 Message-ID: To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FxRuehjMcL6nASbGuFSCBdYbElc X-Mailman-Approved-At: Sun, 10 Aug 2014 13:37:01 -0700 Cc: Jonathan Lennox , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" , Simon Perreault Subject: Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 11:04:44 -0000 On Wed, Jul 30, 2014 at 10:10 AM, Justin Uberti wrote: > On Tue, Jul 29, 2014 at 11:40 PM, Tirumaleswar Reddy (tireddy) > wrote: >> >> > The one thing we need to do is update ICE to allow the CONTROLLING side >> > to make dynamic decisions about which pair to use, instead of being forced >> > to use PRIORITY (which is what 5245 says). >> >> The dynamic decision of changing priority in certain scenarios should be >> confined to an interface. For example when cost saving is taken into account >> in multi-interface scenario, candidates from an interface which offers least >> cost would have higher priority than candidates from other interfaces. > > > Least cost is one policy that the application could choose. I don't think it > should be the only one. > Assuming cost meant monetary cost, apart from dollar costs, it can be energy costs, latency vs throughput trade-off, or something else altogether. So agree the monetary cost shouldn't be the only policy. I suppose the application, user and/or the system knows these policies better. Cheers, Varun > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- http://www.netlab.tkk.fi/~varun/ From nobody Sun Aug 10 15:56:03 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52A61A0166 for ; Sun, 10 Aug 2014 15:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTypaoPDsg7A for ; Sun, 10 Aug 2014 15:55:58 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB1A1A015D for ; Sun, 10 Aug 2014 15:55:57 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so3380834wib.15 for ; Sun, 10 Aug 2014 15:55:56 -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 :content-type; bh=inH1My/JYNfB1n4dyPVURYpaABGg78xj1K6Tk/wowEw=; b=gb6T12SnY2HsuPAhtxEXzpL8xKsPNtlO2JzLopbKLj/qfqAY3z2fBYaxFrKBYZHMIQ tM/9HggLTngqbkCkAkF8XYcpfxrX8xLLFQ4pXYHDQRMdshgVzH/akrTNbAGaFH3Jk6XW uKgtGNXGrgSqy00R44QfIcSxWOLywy3Za5w4vyN+OrcL+Z73D7c06lzu0x7zd3AAG6yn 5i4pBnKQwwKse12NzUlkhPw+yQJzE63RB1fjn0dSAYBNyNepUw01zzCvXsB05AfhjpqB EKoSGjA2BNH4sbwqzn4qcYaUvTA8yv+v66KF4orn0NKzqO8pJ5Q3FBSAiNSjrx1PkUfT 2ChA== MIME-Version: 1.0 X-Received: by 10.180.101.65 with SMTP id fe1mr21100492wib.53.1407711356414; Sun, 10 Aug 2014 15:55:56 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Sun, 10 Aug 2014 15:55:56 -0700 (PDT) In-Reply-To: <20140810225035.24286.20595.idtracker@ietfa.amsl.com> References: <20140810225035.24286.20595.idtracker@ietfa.amsl.com> Date: Sun, 10 Aug 2014 17:55:56 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" , "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=f46d041826be58700405004e574e Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wruOVlIdNeVGOvWa6oXBByCVGUg Subject: [tram] Fwd: New Version Notification for draft-johnston-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 22:56:00 -0000 --f46d041826be58700405004e574e Content-Type: text/plain; charset=UTF-8 All, Tiru and I have made a start to the TURNbis draft. We have submitted it as an individual draft so the working group can decide if this is a reasonable starting point for our chartered work item. The -00 version is essentially unchanged from RFC 5766 to make it easy to track the changes. The -01 version represents our edits so far including a number of Editor's Notes. Feedback and comments are most welcome. - Alan - ---------- Forwarded message ---------- From: Date: Sun, Aug 10, 2014 at 5:50 PM Subject: New Version Notification for draft-johnston-tram-turnbis-01.txt To: Tirumaleswar Reddy , Alan Johnston < alan.b.johnston@gmail.com>, Rohan Mahy , Jonathan Rosenberg , Philip Matthews A new version of I-D, draft-johnston-tram-turnbis-01.txt has been successfully submitted by Alan Johnston and posted to the IETF repository. Name: draft-johnston-tram-turnbis Revision: 01 Title: Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Document date: 2014-08-10 Group: Individual Submission Pages: 69 URL: http://www.ietf.org/internet-drafts/draft-johnston-tram-turnbis-01.txt Status: https://datatracker.ietf.org/doc/draft-johnston-tram-turnbis/ Htmlized: http://tools.ietf.org/html/draft-johnston-tram-turnbis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-turnbis-01 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. 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. The IETF Secretariat --f46d041826be58700405004e574e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

Tiru and I have made a start to th= e TURNbis draft. =C2=A0We have submitted it as an individual draft so the w= orking group can decide if this is a reasonable starting point for our char= tered work item.

The -00 version is essentially unchanged from RFC 5766 = to make it easy to track the changes. =C2=A0The -01 version represents our = edits so far including a number of Editor's Notes.=C2=A0
=
Feedback and comments are most welcome. =C2=A0

- Alan -<= /div>

---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
Date: Sun, Aug 10, 2014 at 5:50 PM
Subject: New Version Notification for= draft-johnston-tram-turnbis-01.txt
To: Tirumaleswar Reddy <tireddy@cisco.com>, Alan Johnston <= alan.b.johnston@gmail.com&= gt;, Rohan Mahy <rohan@ekabal.com>, Jonathan Rosenberg <jdrose= n@jdrosen.net>, Philip Matthews <philip_matthews@magma.ca>



A new version of I-D, draft-johnston-tram-turnbis-01.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-johnston-tram-turnbis
Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Traversal Using Relays around NAT = (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
Document date: =C2=A02014-08-10
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A069
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0htt= p://www.ietf.org/internet-drafts/draft-johnston-tram-turnbis-01.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ie= tf.org/doc/draft-johnston-tram-turnbis/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/draf= t-johnston-tram-turnbis-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ie= tf.org/rfcdiff?url2=3Ddraft-johnston-tram-turnbis-01

Abstract:
=C2=A0 =C2=A0If a host is located behind a NAT, then in certain situations = it can
=C2=A0 =C2=A0be impossible for that host to communicate directly with other= hosts
=C2=A0 =C2=A0(peers). =C2=A0In these situations, it is necessary for the ho= st to use
=C2=A0 =C2=A0the services of an intermediate node that acts as a communicat= ion
=C2=A0 =C2=A0relay. =C2=A0This specification defines a protocol, called TUR= N (Traversal
=C2=A0 =C2=A0Using Relays around NAT), that allows the host to control the<= br> =C2=A0 =C2=A0operation of the relay and to exchange packets with its peers = using
=C2=A0 =C2=A0the relay. =C2=A0TURN differs from some other relay control pr= otocols in
=C2=A0 =C2=A0that it allows a client to communicate with multiple peers usi= ng a
=C2=A0 =C2=A0single relay address.

=C2=A0 =C2=A0The TURN protocol was designed to be used as part of the ICE =C2=A0 =C2=A0(Interactive Connectivity Establishment) approach to NAT trave= rsal,
=C2=A0 =C2=A0though it also can be used without ICE.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--f46d041826be58700405004e574e-- From nobody Mon Aug 11 08:54:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059B31A067A for ; Mon, 11 Aug 2014 08:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udePoEp9svWB for ; Mon, 11 Aug 2014 08:54:43 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15F21A0678 for ; Mon, 11 Aug 2014 08:54:42 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so4500348wiw.0 for ; Mon, 11 Aug 2014 08:54:41 -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:content-type; bh=mRIWq4iWAn/niOj5AlO3G33gbwSOWhc+SDdZj7HJdEU=; b=SxnbK8b/eWd8RD3y/fJ9UWO+t6Y7bK/CXOTxkkqo97Z/XaMKahg6ckFJudJdwXCKDV ocnLrzyhH3aFvn/y6ylUDO9hcRrfGgr6GVIzcd8EiohGRnj8a4JQiTL7/EN743MUmZNh BHTIXPgPsuoA2sQ5oVrww2krm2eK1S9yTnNw6oFAiDVXZeEvHTLq5uHy9aV5CvFQSTw0 Asp/BoER7iZlhQzPguwotq8kn2aGVL/H9mgadxMc6g5ivsYIbJ0Lzyu5Fl51ELZsDxFX cxfTg+THXMZOhNepf2jdsbk9eE96nrJw5EZOgncioM2fO8ZEgtfU6sifPFpSYDzmVCso aDsw== MIME-Version: 1.0 X-Received: by 10.180.95.68 with SMTP id di4mr26807527wib.60.1407772481351; Mon, 11 Aug 2014 08:54:41 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Mon, 11 Aug 2014 08:54:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Aug 2014 10:54:41 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04138dbfacfa8d05005c9222 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8QK4uFKeqHzE8L-8efiBluXzEPU Cc: "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Size of Attribute X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:54:45 -0000 --f46d04138dbfacfa8d05005c9222 Content-Type: text/plain; charset=UTF-8 Justin, Thanks for the feedback. I'll fix the 272 and replace the truncation text with your suggested text. - Alan - On Fri, Aug 1, 2014 at 5:58 PM, Justin Uberti wrote: > > > > On Fri, Aug 1, 2014 at 8:02 AM, Alan Johnston > wrote: > >> draft-ietf-tram-stun-origin-00 currently says this about the size of the >> Origin: >> >> It MUST contain a >> UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. >> The value of 268 is chosen to be larger than the maximum 253 >> character domain name plus 8 characters for the URI scheme plus 5 >> characters for the port number. Senders MAY include multiple ORIGIN >> attributes in a request, and receivers MUST support parsing and >> receiving multiple ORIGIN attributes. >> >> In Toronto, we discussed changing these guidelines. Here is some >> proposed text: >> >> It MUST contain a UTF-8 [RFC3629] encoded sequence of characters. >> Senders MAY include multiple ORIGIN attributes in a request, and receivers >> MUST support parsing and receiving multiple ORIGIN attributes. The length >> and number of ORIGINs included in a STUN message can have a major impact on >> the size of a STUN packet, and could potentially cause UDP fragmentation. >> HTTP origins are 266 characters or smaller (the maximum 253 character >> domain name plus 8 characters for the URI scheme plus 5 characters for the >> port number). It is RECOMMENDED that ORIGIN attributes larger than this >> not be used, or be truncated. >> > > 267 including the colon between domain and port. (272 with type and length > and padding). > > > >> Comments and suggestions most welcome, especially about truncation. >> > > Truncating origins seems like dangerous advice; I don't know what a server > would do with a truncated origin. I would recommend that we say that the > total size of ORIGIN attributes SHOULD not be more than 272 bytes, and > implementations should drop ORIGINs as needed in order to stay under this > limit, possibly sending none at all. The TURN server may fail the request > as a result, but that's at least a deterministic failure. > >> >> - Alan - >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --f46d04138dbfacfa8d05005c9222 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin,

Thanks for the feedback. =C2=A0= I'll fix the 272 and replace the truncation text with your suggested te= xt.

- Alan -


On Fri, Aug 1, 2014 at 5:58 PM, Justin Uberti <juberti@google.com> wrote:



On Fri, Aug 1, 2014 at 8:02 AM, Alan Johnston <= ;alan.b.john= ston@gmail.com> wrote:
draft-ietf-tram-stun-origin-00 currently = says this about the size of the Origin:

=C2=A0 =C2=A0It MUST contain a
=C2=A0 =C2=A0U= TF-8 [RFC3629] encoded sequence of characters less than 268 bytes.
=C2=A0 =C2=A0The value of 268 is chosen to be larger than the maximum = 253
=C2=A0 =C2=A0character domain name plus 8 characters for the = URI scheme plus 5
=C2=A0 =C2=A0characters for the port number. = =C2=A0Senders MAY include multiple ORIGIN
=C2=A0 =C2=A0attributes in a request, and receivers MUST support parsi= ng and
=C2=A0 =C2=A0receiving multiple ORIGIN attributes.

In Toronto, we discussed changing these guidelines.= =C2=A0Here is some proposed text:

It MUST contain a UTF-8 [RFC3629] encoded sequence of c= haracters. =C2=A0Senders MAY include multiple ORIGIN attributes in a reques= t, and receivers MUST support parsing and receiving multiple ORIGIN attribu= tes. =C2=A0The length and number of ORIGINs included in a STUN message can = have a major impact on the size of a STUN packet, and could potentially cau= se UDP fragmentation. =C2=A0HTTP origins are 266 characters or smaller (the= maximum 253 character domain name plus 8 characters for the URI scheme plu= s 5 characters for the port number). =C2=A0It is RECOMMENDED that ORIGIN at= tributes larger than this not be used, or be truncated.

267 including the colon between doma= in and port. (272 with type and length and padding).



Comments and suggestions most welcome, especially about= truncation.

Truncating origins= seems like dangerous advice; I don't know what a server would do with = a truncated origin. I would recommend that we say that the total size of OR= IGIN attributes SHOULD not be more than 272 bytes, and implementations shou= ld drop ORIGINs as needed in order to stay under this limit, possibly sendi= ng none at all. The TURN server may fail the request as a result, but that&= #39;s at least a deterministic failure.=C2=A0

- Alan -



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



--f46d04138dbfacfa8d05005c9222-- From nobody Mon Aug 11 09:22:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41721A06CE for ; Mon, 11 Aug 2014 09:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad9aavkoHKXY for ; Mon, 11 Aug 2014 09:22:27 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937C21A06C9 for ; Mon, 11 Aug 2014 09:22:26 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so4479914wib.10 for ; Mon, 11 Aug 2014 09:22:25 -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:content-type; bh=kHLa5VaVaap5j2C1Kas1WUMBAUMZZooxcvyVrbkTBA4=; b=vQ6SZ9SRiRcMmGj+SJzQ8sue62JdBa3BZFTn/zkHbEHNDOdCP/ur1N7PEAWLiVhOX9 pukb9GxJ0MrwvnyzuoVsJkHy+JlcCKzJMD5N71vWcKFFnoRK1l4q2Itrs0Ooh9yP2N5a 0bwjytjd75YZ060woBBu22GdL6eJk0QbjbwX4muEdnHV1M2qtsslif2uwqg+wA0wErVh 3aKVZQ3ovEJFFpWgMFIeUXvPxJHyEF6ihp+0XL+5qKuHRKbl4IJaBFjZWEqu4MZwgTnq bwhbXWFIAFCg5TthAaspw00av64+rhmLZMGu0+GpGv64kfoaRUtmwznbvp64Ab8Wzau0 cArQ== MIME-Version: 1.0 X-Received: by 10.180.95.68 with SMTP id di4mr26968756wib.60.1407774145249; Mon, 11 Aug 2014 09:22:25 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Mon, 11 Aug 2014 09:22:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Aug 2014 11:22:25 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: multipart/alternative; boundary=f46d04138dbfda094205005cf575 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/J5ejM7h47INwNj3LdjAgYf30NTw Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:22:28 -0000 --f46d04138dbfda094205005cf575 Content-Type: text/plain; charset=UTF-8 Justin & Oleg, Thanks for the feedback. I will change the one requirement to a MUST: To mitigate any potential concerns arising from the unprotected attribute in the initial message, servers MUST verify that the ORIGIN attribute(s) present in the authenticated STUN requests match those that were received in the initial, unauthenticated requests. Having running code is a good thing! - Alan - On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti wrote: > I realized when looking at a code review for this that the stateless-stack > approach makes it difficult to enforce this as written. Instead, I think > the advice should be that the ORIGIN attributes in the authenticated > request MUST be verified to be consistent with the REALM value that is > supplied. > > > On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko > wrote: > >> I agree with the changes. >> >> Thanks >> Oleg >> >> >> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston >> wrote: >> >>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: >>> >>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >>> for all attributes present in a STUN request. However, MESSAGE- >>> INTEGRITY is not present in the initial STUN message sent, so the >>> initial ORIGIN attribute will not have integrity protection and hence >>> could be modified or removed from a STUN request without the server >>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY >>> attribute will provide integrity protection for the contents of the >>> ORIGIN attribute. The strength of this protection is a function of >>> the secret used to generate the MESSAGE-INTEGRITY value. >>> >>> Justin has proposed changing it to: >>> >>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >>> for all attributes present in a STUN request. However, when using >>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE- >>> INTEGRITY is not present in the initial STUN message sent, and so the >>> initial ORIGIN attribute will not have integrity protection. Hence, >>> it could be modified or removed from a STUN request without the server >>> knowing, which could affect the server's choice of REALM. >>> >>> With the long-term credential mechanism, subsequent STUN requests >>> will >>> contain the MESSAGE-INTEGRITY attribute and will provide integrity >>> protection >>> for the contents of the ORIGIN attribute(s). To mitigate any >>> potential concerns >>> arising from the unprotected attribute in the initial message, >>> servers SHOULD >>> verify that the ORIGIN attribute(s) present in the authenticated STUN >>> requests >>> match those that were received in the initial, unauthenticated >>> requests. >>> >>> The strength of the integrity protection is a function of >>> the secret used to generate the MESSAGE-INTEGRITY value. >>> >>> Anyone object to this clarification? Any other suggested edits to the >>> Security Considerations section? >>> >>> - Alan - >>> >>> _______________________________________________ >>> 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 >> >> > --f46d04138dbfda094205005cf575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin & Oleg,

Thanks for the feedb= ack. =C2=A0I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected = attribute in the initial message, servers MUST verify that the ORIGIN attri= bute(s) present in the authenticated STUN requests match those that were re= ceived in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti <jubert= i@google.com> wrote:
I realized when looking at a code review = for this that the stateless-stack approach makes it difficult to enforce th= is as written. Instead, I think the advice should be that the ORIGIN attrib= utes in the authenticated request MUST be verified to be consistent with th= e REALM value that is supplied.


On Fri, Aug 1= , 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
I agree with the changes.
Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM= , Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-= tram-stun-origin-00, the Security Considerations says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can p= rovide integrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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



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



--f46d04138dbfda094205005cf575-- From nobody Mon Aug 11 09:53:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E57E1A06C9 for ; Mon, 11 Aug 2014 09:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX2Tur8_3fFL for ; Mon, 11 Aug 2014 09:53:49 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06161A06AB for ; Mon, 11 Aug 2014 09:53:48 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so11808203vcb.20 for ; Mon, 11 Aug 2014 09:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=N6ZXcJPeKiWtMO6Lq5ZmHau/tQJ8urOsf2cbi1xnekg=; b=gnzDIjb0fryOJp44qFsHyoRlOZ9gsLl588niuP5u1Zw4PFeXYbexX0yN1YvqWZckfG Vo1GdskyaCV41eEt9HPnBw/B2B7D/V8W4OL5MeA2ciD0b5Vp/9UNriNUpO4IC/bpJB6A 32EC6zeb0n0XTExPZ8BccOmDI1WUqOFqzZUDOSaONBdTZVP2GLRS7TpEzNyTDi/FBRPf pXGy6HOX8ml054YLX0OtteaIVM+6g52+sz7TVzCN4BbyM/xLLfn/k7uh+JHcZBilVxZh qjrPs31OLCYfwxLyI9yF12rw8GEQYLI/V6P/qDYdGYbqp1+mB6MIZS9yu6nSNTkVRzBL yung== 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-type; bh=N6ZXcJPeKiWtMO6Lq5ZmHau/tQJ8urOsf2cbi1xnekg=; b=AX9gzBTG7PGdlq80THiTWoUQrSzCGGF6kMSZXTnDYFCFJheTEKAMD/jcAQ6IFRqyYJ uW3c6YlnrLJGbwRS/ipJLA/YpfOpnurFxDR8RjjyI+8cugO+a/1vV9kUX8CTQkbDTyCz 3KrXmU4q7YeXuzV39wsZzBur7iL+bRhLlGUhVG8yLR3MeGuq/sSqLwkuAUmb8SnF5Cr3 z7mLZbxfoHL2C+U7KA+S8RdXmZG8/Xqm5RWwlvNyx+EJGbJhbzSVBytD2BVVmQISgnMR TWwnX4j3vl60fVRk/NvtGrgloqP+WINAHG8Dwk1DgB3LYyuIlyjAm2Tu+1g+wP0HG2Z2 p6Vw== X-Gm-Message-State: ALoCoQnH3F/dg7PGdcRbh8w0CVfdu60zzEy2h9jDW0T3ZjrFT2g/ggIRkppSPQbAoNtvLpYLH75+ X-Received: by 10.220.252.198 with SMTP id mx6mr37100877vcb.15.1407776027904; Mon, 11 Aug 2014 09:53:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Mon, 11 Aug 2014 09:53:26 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Mon, 11 Aug 2014 09:53:26 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=089e013a044a11327605005d6681 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FzhHE-9WtBMq-lec957fOOE_144 Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 16:53:51 -0000 --089e013a044a11327605005d6681 Content-Type: text/plain; charset=UTF-8 As mentioned I think what you describe is hard to do when using stateless stack - see my email on Aug 1 for a suggestion on how to resolve this. On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston wrote: > Justin & Oleg, > > Thanks for the feedback. I will change the one requirement to a MUST: > > To mitigate any potential concerns arising from the unprotected attribute > in the initial message, servers MUST verify that the ORIGIN attribute(s) > present in the authenticated STUN requests match those that were received > in the initial, unauthenticated requests. > > Having running code is a good thing! > > - Alan - > > > On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti wrote: > >> I realized when looking at a code review for this that the >> stateless-stack approach makes it difficult to enforce this as written. >> Instead, I think the advice should be that the ORIGIN attributes in the >> authenticated request MUST be verified to be consistent with the REALM >> value that is supplied. >> >> >> On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko >> wrote: >> >>> I agree with the changes. >>> >>> Thanks >>> Oleg >>> >>> >>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston >> > wrote: >>> >>>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: >>>> >>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >>>> for all attributes present in a STUN request. However, MESSAGE- >>>> INTEGRITY is not present in the initial STUN message sent, so the >>>> initial ORIGIN attribute will not have integrity protection and hence >>>> could be modified or removed from a STUN request without the server >>>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY >>>> attribute will provide integrity protection for the contents of the >>>> ORIGIN attribute. The strength of this protection is a function of >>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>> >>>> Justin has proposed changing it to: >>>> >>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protection >>>> for all attributes present in a STUN request. However, when using >>>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE- >>>> INTEGRITY is not present in the initial STUN message sent, and so the >>>> initial ORIGIN attribute will not have integrity protection. Hence, >>>> it could be modified or removed from a STUN request without the >>>> server >>>> knowing, which could affect the server's choice of REALM. >>>> >>>> With the long-term credential mechanism, subsequent STUN requests >>>> will >>>> contain the MESSAGE-INTEGRITY attribute and will provide integrity >>>> protection >>>> for the contents of the ORIGIN attribute(s). To mitigate any >>>> potential concerns >>>> arising from the unprotected attribute in the initial message, >>>> servers SHOULD >>>> verify that the ORIGIN attribute(s) present in the authenticated >>>> STUN requests >>>> match those that were received in the initial, unauthenticated >>>> requests. >>>> >>>> The strength of the integrity protection is a function of >>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>> >>>> Anyone object to this clarification? Any other suggested edits to the >>>> Security Considerations section? >>>> >>>> - Alan - >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > --089e013a044a11327605005d6681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As mentioned I think what you describe is hard to do when = using stateless stack - see my email on Aug 1 for a suggestion on how to re= solve this.


On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <alan.b.johnston@gm= ail.com> wrote:
Justin & Oleg,

Thanks for the feedb= ack. =C2=A0I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected = attribute in the initial message, servers MUST verify that the ORIGIN attri= bute(s) present in the authenticated STUN requests match those that were re= ceived in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti <juberti@google.com> wrote:
I realized when looking at a code review = for this that the stateless-stack approach makes it difficult to enforce th= is as written. Instead, I think the advice should be that the ORIGIN attrib= utes in the authenticated request MUST be verified to be consistent with th= e REALM value that is supplied.


On Fri, Aug 1= , 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
I agree with the changes.
Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM= , Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-= tram-stun-origin-00, the Security Considerations says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can p= rovide integrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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



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




--089e013a044a11327605005d6681-- From nobody Tue Aug 12 08:33:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78AB1A0976 for ; Tue, 12 Aug 2014 08:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRWUFLKx4hnS for ; Tue, 12 Aug 2014 08:33:38 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC451A095C for ; Tue, 12 Aug 2014 08:33:37 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so10102333wes.39 for ; Tue, 12 Aug 2014 08:33:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=9EXBul3Rxd9otOggEMHFzKdEOTcLVhqXrNe7XAXaVNk=; b=RbYjZktmXWP+lGvgoQ76z8BmED3hLUAgBHNusU6Qz9O0E7Sl41X4BeM1c7NA4V7nM9 gvxF8HKPwd9OEqc8iNq2Q3UQfiNic7yc8VxWUFzsJv/aoP3oAwvruuqbBGWgXkVaSjsS EeBqXfe3khHwCfy6HInYBOa1dtbXD+GR1Iug4Pbak9/ECaAPHlNhNWKtsUoTezo8TtM+ IHsoxWGQnYU/hsc6UH9B5h5A4O6512kr+V+iZOZPZWnuze51B2gyoK9ZLVe/yyansR/q Okjqe7uxnNJviRqBS1B0nfNG/M4TU5luwjUc/bSw6A2jZOr91DeFMEfijI5KMj/M1/JW UWzw== X-Gm-Message-State: ALoCoQn66kogpdt7LKXgmO+HIV1NaMIzyZMleFKAEOXwgkSQ/S4A8k02JMXrd38dwoW1uonXwOUU MIME-Version: 1.0 X-Received: by 10.180.107.65 with SMTP id ha1mr32802224wib.59.1407857616508; Tue, 12 Aug 2014 08:33:36 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Tue, 12 Aug 2014 08:33:36 -0700 (PDT) Date: Tue, 12 Aug 2014 11:33:36 -0400 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZhBW7uKIw_F6Vxuioo7G-5Od6y4 Subject: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:33:40 -0000 TRAMsters, This email initiates a two-week adoption call for draft-johnston-tram-turnbis-01, which targets the TURN-bis milestone we have for January 2015. Two questions for discussion: - What do we want to achieve with TURN-bis? That is, beyond the errata and tracker issues, when will we consider the draft to be "done" and ready to be sent to IESG? - Given what we want to achieve, is this draft a good start? "Good" meaning it is going in the right direction, not that it is close to the end goal. Thanks, Simon & Gonzalo From nobody Tue Aug 12 08:43:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8832D1A0989 for ; Tue, 12 Aug 2014 08:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIJo5SnNkjWu for ; Tue, 12 Aug 2014 08:43:54 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4861A098A for ; Tue, 12 Aug 2014 08:43:54 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so10072465wes.25 for ; Tue, 12 Aug 2014 08:43:52 -0700 (PDT) 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:content-type; bh=zhy9LnddqlSlWQtGLWZ5fS6wh4g0i0kjMvLTQyogUS8=; b=R5dWDI6TN6Y+TCV2XKq1kIR6eICksrNtgro5LEujlRIR8zIb7bsFXdlfVXJezsClDM x6O+ORK17GSP3W5apvP9/50zXfyNtASakfp/DiaEck8/z1SX9JHA1IMFndkjKbzJV+G8 tsosmnCxfIHLBShR91EAugO7t5R+v7lu69Nrna2+OeawJ2GZdUWyKY8QtRpC7GG6hHVn gzo6JhUqjYgMEgSRqE5+bVNnsJGICzLM1JDy6e5WOECIe9HMH2tiDmqJfs7V78kg5j1X m4o/+JcHJTEuN5AY1xtL3j1FCzw1VSmsFVYr56c7Ro1DNOW9JkIcybcOQi2DtHVs3RHB PguA== X-Gm-Message-State: ALoCoQnpHtD558HoOu21t60DpIjkAfF4IXrnjImGSwQ6y5++cZ0T0khH4+iGb6RZe4Zqarb/4/Go MIME-Version: 1.0 X-Received: by 10.194.59.18 with SMTP id v18mr6145672wjq.64.1407858232903; Tue, 12 Aug 2014 08:43:52 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Tue, 12 Aug 2014 08:43:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Aug 2014 11:43:52 -0400 Message-ID: From: Simon Perreault To: "tram@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/t_WTVnP_0LTrQtZuBsMnG6FJKJk Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 15:43:57 -0000 With WG chair hat off, I will provide my own personal views... On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault wrote: > - What do we want to achieve with TURN-bis? That is, beyond the errata > and tracker issues, when will we consider the draft to be "done" and > ready to be sent to IESG? I think we need to merge TURN-IPv6 into the base spec. IPv4-only protocols are a thing of the past. I don't think we need to merge TURN-TCP. The base spec could remain compatible with the TURN-TCP RFC so that we don't need to update it too. I think that it would make sense to merge the SSODA draft into the base spec. > - Given what we want to achieve, is this draft a good start? "Good" > meaning it is going in the right direction, not that it is close to > the end goal. Since the draft is so close to the starting line, it's hard to go in the wrong direction... Simon From nobody Tue Aug 12 09:25:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7091A0266 for ; Tue, 12 Aug 2014 09:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Dby42VsXbwKa for ; Tue, 12 Aug 2014 09:25:36 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F3C1A02DF for ; Tue, 12 Aug 2014 09:25:35 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so6138295wiv.7 for ; Tue, 12 Aug 2014 09:25:34 -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:content-type; bh=H6WQAxQSa0r1cQ8m84EXvw4XJBpS0iSvShHTCGdiObA=; b=wQRPPIgk5jVnPNrmwAUrP0YRN2lIJ//jyfH+W0F0zDDYNvLeF1TWwwAPwpbjbP8x9R ksHKXmaYN+5CjKAY1RoxC7thJbNCb5Bk4HniJhv+tWVjZN0L7tI2dhniPQHuZoqEwBJy FVa7uhilEvHpMrIM41b8xZuRSrtTyCMZyOuiw8phIuv3lHQoMxE+lbKmYa9KwGx+jwQa nxuQjyPWAImEmLREGtPxODp+M0qXNXZovt64qdkAP9N6CDgrONnYIK+mp2ZgZ2iqmBld wSEc9J/U9DrXCgniss6zbJyU1VtEGoO6B0ey0R7D/CdrE6Q1hGnWSVmxL8b1JD0XoeUb SDzw== MIME-Version: 1.0 X-Received: by 10.194.236.132 with SMTP id uu4mr1130350wjc.108.1407860734299; Tue, 12 Aug 2014 09:25:34 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Tue, 12 Aug 2014 09:25:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Aug 2014 09:25:34 -0700 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=089e01494186f6139f0500711e68 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5lX-rCavK79kIEuOiTCaxjxkWpw Cc: "tram@ietf.org" Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:25:39 -0000 --089e01494186f6139f0500711e68 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault wrote: > With WG chair hat off, I will provide my own personal views... > > On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault > wrote: > > - What do we want to achieve with TURN-bis? That is, beyond the errata > > and tracker issues, when will we consider the draft to be "done" and > > ready to be sent to IESG? > > I think we need to merge TURN-IPv6 into the base spec. IPv4-only > protocols are a thing of the past. > > I don't think we need to merge TURN-TCP. The base spec could remain > compatible with the TURN-TCP RFC so that we don't need to update it > too. > > I think that it would make sense to merge the SSODA draft into the base > spec. > I agree, and I'd merge the ORIGIN draft, too. That is a very important change for a large enterprise. > > > - Given what we want to achieve, is this draft a good start? "Good" > > meaning it is going in the right direction, not that it is close to > > the end goal. > > Since the draft is so close to the starting line, it's hard to go in > the wrong direction... > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --089e01494186f6139f0500711e68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault = <sperreault@jiv= e.com> wrote:
With WG chair hat off, I will provide my own= personal views...

On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault <sperreault@jive.com> wrote:
> - What do we want to achieve with TURN-bis? That is, beyond the errata=
> and tracker issues, when will we consider the draft to be "done&q= uot; and
> ready to be sent to IESG?

I think we need to merge TURN-IPv6 into the base spec. IPv4-only
protocols are a thing of the past.

I don't think we need to merge TURN-TCP. The base spec could remain
compatible with the TURN-TCP RFC so that we don't need to update it
too.

I think that it would make sense to merge the SSODA draft into the base spe= c.


I agree, and I'd = merge the ORIGIN draft, too. That is a very important change for a large en= terprise.
=C2=A0

> - Given what we want to achieve, is this draft a good start? "Goo= d"
> meaning it is going in the right direction, not that it is close to > the end goal.

Since the draft is so close to the starting line, it's hard to go= in
the wrong direction...

Simon

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

--089e01494186f6139f0500711e68-- From nobody Tue Aug 12 09:42:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D71A0317 for ; Tue, 12 Aug 2014 09:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ3A4PkCj3y1 for ; Tue, 12 Aug 2014 09:42:35 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA671A0328 for ; Tue, 12 Aug 2014 09:42:33 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so10251522wes.10 for ; Tue, 12 Aug 2014 09:42:32 -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:content-type; bh=cSIUwzeQ1jdrDNyFsVK8VYHLhebA/CjzApiOsWn2HpA=; b=Pb+09xUwF+hJaZVfAp4cCNrr0ndYrQvjhOYM2SPhGlj2eqE+5tHpyMfGPyWNonhJdk WSPFlSF6Vf++zcpcYt1CutsL0aPe8CwAVxfwSPeU5S/+y5/Aym7atkaHfPg++cOXalbN 8qnijN7nXsW6iT+KYBC1qHOZ7woxjQbmIXpd4DLxDKToXEtiLTk3hTZgNbezrZUebOtE 2B5TaSo7jnT5fvLY2/eGlP8X7xrFe6xC8fHTsT6PBfuX+iTw6rOKif7ZRYpF2PKUP3r6 fD0R1jPoy06wMpkzHDsc7Kkx2phQ4iNx2dGEZamdaUd24P8udQ9qQmgjYjDWUIrfHlya /Xpg== MIME-Version: 1.0 X-Received: by 10.180.95.68 with SMTP id di4mr34206043wib.60.1407861752078; Tue, 12 Aug 2014 09:42:32 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Tue, 12 Aug 2014 09:42:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Aug 2014 11:42:32 -0500 Message-ID: From: Alan Johnston To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=f46d04138dbfa02a800500715b57 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dApgLqWZ4YQAzXQfIYciTAWP8T4 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:42:37 -0000 --f46d04138dbfa02a800500715b57 Content-Type: text/plain; charset=UTF-8 Hi Oleg, The ORIGIN attribute applies to both STUN and TURN, so if it were to be merged, it would be into STUN-bis. I'm not so sure about merging as the ORIGIN draft is almost ready for last call. The ORIGIN RFC could be normatively referenced by both STUN-bis and TURN-bis when they are published next year, if needed. - Alan - On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko wrote: > > > > On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault > wrote: > >> With WG chair hat off, I will provide my own personal views... >> >> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault >> wrote: >> > - What do we want to achieve with TURN-bis? That is, beyond the errata >> > and tracker issues, when will we consider the draft to be "done" and >> > ready to be sent to IESG? >> >> I think we need to merge TURN-IPv6 into the base spec. IPv4-only >> protocols are a thing of the past. >> >> I don't think we need to merge TURN-TCP. The base spec could remain >> compatible with the TURN-TCP RFC so that we don't need to update it >> too. >> >> I think that it would make sense to merge the SSODA draft into the base >> spec. >> > > > I agree, and I'd merge the ORIGIN draft, too. That is a very important > change for a large enterprise. > > >> >> > - Given what we want to achieve, is this draft a good start? "Good" >> > meaning it is going in the right direction, not that it is close to >> > the end goal. >> >> Since the draft is so close to the starting line, it's hard to go in >> the wrong direction... >> >> 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 > > --f46d04138dbfa02a800500715b57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Oleg,

The ORIGIN attribute applies to both STUN and TURN, so if it were to be mer= ged, it would be into STUN-bis. =C2=A0I'm not so sure about merging as = the ORIGIN draft is almost ready for last call. =C2=A0The ORIGIN RFC could = be normatively referenced by both STUN-bis and TURN-bis when they are publi= shed next year, if needed.

- Alan -=


O= n Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:



On Tue, Aug 12, 2014 at 8:43 AM, Sim= on Perreault <sperreault@jive.com> wrote:
With WG chair hat off, I will provide my own= personal views...

On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault <sperreault@jive.com> wrote:
> - What do we want to achieve with TURN-bis? That is, beyond the errata=
> and tracker issues, when will we consider the draft to be "done&q= uot; and
> ready to be sent to IESG?

I think we need to merge TURN-IPv6 into the base spec. IPv4-only
protocols are a thing of the past.

I don't think we need to merge TURN-TCP. The base spec could remain
compatible with the TURN-TCP RFC so that we don't need to update it
too.

I think that it would make sense to merge the SSODA draft into the base spe= c.


I agree, and I'd = merge the ORIGIN draft, too. That is a very important change for a large en= terprise.
=C2=A0

> - Given what we want to achieve, is this draft a good start? "Goo= d"
> meaning it is going in the right direction, not that it is close to > the end goal.

Since the draft is so close to the starting line, it's hard to go= in
the wrong direction...

Simon

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


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


--f46d04138dbfa02a800500715b57-- From nobody Tue Aug 12 13:53:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C0B1A01E6 for ; Tue, 12 Aug 2014 13:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc_x4EI8sORO for ; Tue, 12 Aug 2014 13:53:44 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE3E1A01E1 for ; Tue, 12 Aug 2014 13:53:43 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so13772235vcb.24 for ; Tue, 12 Aug 2014 13:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Rx3E4UwXhGmcpGxydLLqxk1MR82HXoh0PwujCFjv67Q=; b=YXN3vI8hCw9UaL96rmQTh/wmS/lkJI2oUvhl1l1l0kZsKc/ORWE7Fdvlky8RZWBCUM 5yPg7RiGcriEis3yjLTCJnUMFg/FVhlLbr2ZdiL2Dv/WEMP4ZNOowK+Gn0EQNxqms3S1 VpE0m0IkXrGe3/eh4rYNLDz92CC8BzRxL7KHsg8QNFmyjcWKlSoJuqjmsttBxaNLJN8F niFeKOatjyp5FvQVxvgAHRlvMZ5BW/fimNEITBAvZbRSouEwJUuE+bcX9lxEEfLdJLtx aL3++oln1b/eX7HN2d+/17gbkH8ZNh3oqMGJzWFxTFIrhQ6f21l6dIG6NzTIQpq4rwTf m/IQ== 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-type; bh=Rx3E4UwXhGmcpGxydLLqxk1MR82HXoh0PwujCFjv67Q=; b=dz+M5Hn6HrUyoKqjReCIxXDcQsPOP0qNw4gWR802DEQPmceT8gYgezObMEhZ7RgTX2 NWLmz55oXR8nwkRc5xXo4h+5ezn240txe3GJcZX+jCqRC7YM/Y6nkQ+EXVQlqBmtZEEc K/VvG9rv//OI6PmsbMW9WlwQfQH8FhSdd5ZB90ROKk/ToHs9eL7C97OYY4Ax6sgAgdC2 R7fgbU1g/t/c8C5u1Jk/hU5AMnKwVI12mt821OGmZhSCng7NSAbI2YbLKwNY0VZCH697 xW6ooWQXPWLqGX9UXN+LWHNI6oM8UymhZNtUuEHNnAMUCA/58EAcnnMdZgnB53D6EWmc RImg== X-Gm-Message-State: ALoCoQk93BbeshHRZORI3ZCtP301tvxy10N7GI0D7VNIdshrQmI7j7vzmsbZpdCuU/DkItpm81Gv X-Received: by 10.220.49.10 with SMTP id t10mr150183vcf.34.1407876823068; Tue, 12 Aug 2014 13:53:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Tue, 12 Aug 2014 13:53:22 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Tue, 12 Aug 2014 13:53:22 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=089e0163412ced4c7a050074dd47 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2z4hxGPVAzNKaXUSNIIl_DF_CNo Cc: Simon Perreault , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 20:53:46 -0000 --089e0163412ced4c7a050074dd47 Content-Type: text/plain; charset=UTF-8 I agree that simply referencing ORIGIN makes more sense. Also agree that we should try to incorporate SSODA. On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston wrote: > Hi Oleg, > > The ORIGIN attribute applies to both STUN and TURN, so if it were to be > merged, it would be into STUN-bis. I'm not so sure about merging as the > ORIGIN draft is almost ready for last call. The ORIGIN RFC could be > normatively referenced by both STUN-bis and TURN-bis when they are > published next year, if needed. > > - Alan - > > > On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko > wrote: > >> >> >> >> On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault >> wrote: >> >>> With WG chair hat off, I will provide my own personal views... >>> >>> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault >>> wrote: >>> > - What do we want to achieve with TURN-bis? That is, beyond the errata >>> > and tracker issues, when will we consider the draft to be "done" and >>> > ready to be sent to IESG? >>> >>> I think we need to merge TURN-IPv6 into the base spec. IPv4-only >>> protocols are a thing of the past. >>> >>> I don't think we need to merge TURN-TCP. The base spec could remain >>> compatible with the TURN-TCP RFC so that we don't need to update it >>> too. >>> >>> I think that it would make sense to merge the SSODA draft into the base >>> spec. >>> >> >> >> I agree, and I'd merge the ORIGIN draft, too. That is a very important >> change for a large enterprise. >> >> >>> >>> > - Given what we want to achieve, is this draft a good start? "Good" >>> > meaning it is going in the right direction, not that it is close to >>> > the end goal. >>> >>> Since the draft is so close to the starting line, it's hard to go in >>> the wrong direction... >>> >>> 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 > > --089e0163412ced4c7a050074dd47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that simply referencing ORIGIN makes more sense. A= lso agree that we should try to incorporate SSODA.

On Tue, Aug 12, 2014 at 9:42 AM, Alan John= ston <alan.b.johnston@gmail.com> wrote:
Hi Oleg,

The ORIGIN attribute applies to both STUN and TURN, so if it were to be mer= ged, it would be into STUN-bis. =C2=A0I'm not so sure about merging as = the ORIGIN draft is almost ready for last call. =C2=A0The ORIGIN RFC could = be normatively referenced by both STUN-bis and TURN-bis when they are publi= shed next year, if needed.

- Alan -=


On Tue, Aug 12, 2014 at 11:25 AM, Oleg M= oskalenko <mom040267@gmail.com> wrote:



On Tue, Aug 12, 2014 at 8:43 AM, Sim= on Perreault <sperreault@jive.com> wrote:
With WG chair hat off, I will provide my own= personal views...

On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault <sperreault@jive.com> wrote:
> - What do we want to achieve with TURN-bis? That is, beyond the errata=
> and tracker issues, when will we consider the draft to be "done&q= uot; and
> ready to be sent to IESG?

I think we need to merge TURN-IPv6 into the base spec. IPv4-only
protocols are a thing of the past.

I don't think we need to merge TURN-TCP. The base spec could remain
compatible with the TURN-TCP RFC so that we don't need to update it
too.

I think that it would make sense to merge the SSODA draft into the base spe= c.


I agree, and I'd = merge the ORIGIN draft, too. That is a very important change for a large en= terprise.
=C2=A0

> - Given what we want to achieve, is this draft a good start? "Goo= d"
> meaning it is going in the right direction, not that it is close to > the end goal.

Since the draft is so close to the starting line, it's hard to go= in
the wrong direction...

Simon

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


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



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


--089e0163412ced4c7a050074dd47-- From nobody Wed Aug 13 00:42:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7A51A7026 for ; Wed, 13 Aug 2014 00:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKP6338V0G_e for ; Wed, 13 Aug 2014 00:42:09 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45BC1A7029 for ; Wed, 13 Aug 2014 00:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9400; q=dns/txt; s=iport; t=1407915728; x=1409125328; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qKv2axgXNRjFKdahzJe/kXveUEinINtf+oCoaz+zIo8=; b=et36NMKvVT5Cqr4adJmVVO2XsG0X+Y7DiAoFjWzo0/d54/JloBXITE+k G3wpvvXM0sPToIjMjA1fpacA5u/UwBFVYLCWb0lGk8vyUolouxKonXe4L 3n1Zo0+ET9mNnXdQ5gIUcX5qOYA0sYn09BfiDG/O/FQm1qFI015JknM/Q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIEV61OtJA2I/2dsb2JhbABagkdGUlcEzRsBCYdIAYERFneEBAEBBAEBARpRCxACAQgYJwchBgsUEQIEDgWILgMRDcASDYVDEwSNH4IpBAeDL4EdBYUDAoVehjqEJoRogg6OS4Yzg1xsAYFH X-IronPort-AV: E=Sophos;i="5.01,855,1400025600"; d="scan'208,217";a="346939072" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 13 Aug 2014 07:42:08 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7D7g7xo016344 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 07:42:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.218]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 02:42:07 -0500 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] Call for adoption: draft-johnston-tram-turnbis-01 Thread-Index: AQHPtkLNSGApSr1LvU+GJMn+tUQex5vNb7oAgAALpwCAAAS9AIAARhUAgAC1QQA= Date: Wed, 13 Aug 2014 07:42:07 +0000 Message-ID: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.71] Content-Type: multipart/alternative; boundary="_000_951FFC8D3C5547E69D7B281CDF9EC5CAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FR4Zfi4yhVz4zFM2iC2Fe6LALmY Cc: Simon Perreault , Oleg Moskalenko , Alan Johnston , Justin Uberti Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 07:42:14 -0000 --_000_951FFC8D3C5547E69D7B281CDF9EC5CAciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 to referencing ORIGIN. +1 to incorporating SSODA into TURNbis SSODA now have two implementations (Both OpenSource). Coturn (https://code.= google.com/p/coturn/) and NATtools (https://github.com/cisco/NATTools) I think the SSODA draft is ready to be merged into TURNbis and continue the= discussion there. There probably still issues to be discussed, but better = to have them in a WG document than an I-D? Or? .-. P=E5l-Erik On 12 Aug 2014, at 22:53, Justin Uberti > wrote: I agree that simply referencing ORIGIN makes more sense. Also agree that we= should try to incorporate SSODA. On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston > wrote: Hi Oleg, The ORIGIN attribute applies to both STUN and TURN, so if it were to be mer= ged, it would be into STUN-bis. I'm not so sure about merging as the ORIGI= N draft is almost ready for last call. The ORIGIN RFC could be normatively= referenced by both STUN-bis and TURN-bis when they are published next year= , if needed. - Alan - On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko > wrote: On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault > wrote: With WG chair hat off, I will provide my own personal views... On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault > wrote: > - What do we want to achieve with TURN-bis? That is, beyond the errata > and tracker issues, when will we consider the draft to be "done" and > ready to be sent to IESG? I think we need to merge TURN-IPv6 into the base spec. IPv4-only protocols are a thing of the past. I don't think we need to merge TURN-TCP. The base spec could remain compatible with the TURN-TCP RFC so that we don't need to update it too. I think that it would make sense to merge the SSODA draft into the base spe= c. I agree, and I'd merge the ORIGIN draft, too. That is a very important chan= ge for a large enterprise. > - Given what we want to achieve, is this draft a good start? "Good" > meaning it is going in the right direction, not that it is close to > the end goal. Since the draft is so close to the starting line, it's hard to go in the wrong direction... 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 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_951FFC8D3C5547E69D7B281CDF9EC5CAciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3849E7A63DB26247B5BCF325C56FED7A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

+1 to referencing ORIGIN.

+1 to incorporating SSODA into TURNbis

SSODA now have two implementations (Both OpenSource). Coturn (https://code.google.com/p/coturn/) and NATtools (https://gith= ub.com/cisco/NATTools)

I think the SSODA draft is ready to be merged into TURNbis and continu= e the discussion there. There probably still issues to be discussed, but be= tter to have them in a WG document than an I-D? Or?

.-.
P=E5l-Erik


On 12 Aug 2014, at 22:53, Justin Uberti <juberti@google.com> wrote:

I agree that simply referencing ORIGIN makes more sense. A= lso agree that we should try to incorporate SSODA.

On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston <= span dir=3D"ltr"> <alan.b.j= ohnston@gmail.com> wrote:
Hi O= leg,

The ORIGIN attribute a= pplies to both STUN and TURN, so if it were to be merged, it would be into = STUN-bis.  I'm not so sure about merging as the ORIGIN draft is almost= ready for last call.  The ORIGIN RFC could be normatively referenced by both STUN-bis and TURN-bis when they are publ= ished next year, if needed.

- Alan -


On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenk= o <mom040267@gmai= l.com> wrote:



On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault= <sperreault@jiv= e.com> wrote:
With WG chair hat off, I will provide my own personal views...

On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault <sperreault@jive.com> wrote:
> - What do we want to achieve with TURN-bis? That is, beyond the errata=
> and tracker issues, when will we consider the draft to be "done&q= uot; and
> ready to be sent to IESG?

I think we need to merge TURN-IPv6 into the base spec. IPv4-only
protocols are a thing of the past.

I don't think we need to merge TURN-TCP. The base spec could remain
compatible with the TURN-TCP RFC so that we don't need to update it
too.

I think that it would make sense to merge the SSODA draft into the base spe= c.


I agree, and I'd merge the ORIGIN draft, too. That is a very important= change for a large enterprise.
 

> - Given what we want to achieve, is this draft a good start? "Goo= d"
> meaning it is going in the right direction, not that it is close to > the end goal.

Since the draft is so close to the starting line, it's hard to go in
the wrong direction...

Simon

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


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



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


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

--_000_951FFC8D3C5547E69D7B281CDF9EC5CAciscocom_-- From nobody Wed Aug 13 04:28:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5F51A86FB for ; Wed, 13 Aug 2014 04:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69yktFqDbXrr for ; Wed, 13 Aug 2014 04:28:21 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF231A085C for ; Wed, 13 Aug 2014 04:28:20 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so7242208wiv.1 for ; Wed, 13 Aug 2014 04:28:19 -0700 (PDT) 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:content-type; bh=dRTktq9iz+X318BaDGnSLKLFTidwaUMZ2S7xfHkDXRk=; b=SzcEERn0x1JU4NNVKZ9+GW1OmNQbnqkAD0cLUpFd6WaRx5QnbBvz6b87S7NQ9UM9uW xu4BTYx/hzJwvkNu3ezX0VaLHH6W/r+2r2ocK4LZk4xIkTK9bZBRmaUkgdtTI6qzqNaW FyYnoqkEiOgtCdZY/oKOUhTWxcCkLuyvjVQNlX+DphwSVrr3sqiN6X5/Fx9DKBxJ9JAi BppUujAR7y1X0pv39Lj/etA7BFLOeEVPMngzsij1Fr1ffxLJUUbbhidJXXp70uZOGZZY +BSDO9tcUpwcUnXN8A/gtjq5bb2sL+3WkrXCkEX7f7hvPvtLO0RtEQa4Wz+JVgegtFs+ +w/g== X-Gm-Message-State: ALoCoQnQqgkP2eFwubbY+eVoRmntAcaVOiTPc1SjWO+5s/LThO/6Ethx7u2bLEt2wMqSlelL+ZaX MIME-Version: 1.0 X-Received: by 10.180.188.203 with SMTP id gc11mr37735557wic.59.1407929299124; Wed, 13 Aug 2014 04:28:19 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Wed, 13 Aug 2014 04:28:19 -0700 (PDT) In-Reply-To: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> References: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> Date: Wed, 13 Aug 2014 07:28:19 -0400 Message-ID: From: Simon Perreault To: "Pal Martinsen (palmarti)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XenaqqP2ba-Uz2RI593D4XqSPHQ Cc: Oleg Moskalenko , Alan Johnston , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 11:28:22 -0000 On Wed, Aug 13, 2014 at 3:42 AM, Pal Martinsen (palmarti) wrote: > SSODA now have two implementations (Both OpenSource). Coturn > (https://code.google.com/p/coturn/) and NATtools > (https://github.com/cisco/NATTools) Cool! Please add this in an Implementation Status [RFC6982] section! Discussion about SSODA issues can continue. Whether SSODA is merged or not is irrelevant. Simon From nobody Wed Aug 13 07:59:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0621A0788 for ; Wed, 13 Aug 2014 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rr7URp2a8Q3m for ; Wed, 13 Aug 2014 07:59:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7521A0750 for ; Wed, 13 Aug 2014 07:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3511; q=dns/txt; s=iport; t=1407941953; x=1409151553; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U3U+Mgh/DD4+HVRp2iU6hgROBmDvCGk7wMm6INblzcs=; b=FOUlChJvMwEJjEUW4xWezDVuawJNXx7d0wAcjjhoiWjLApuV7fOJPaSH 5QTRbJypQick48rMdEaOUUCwWxbfzPn7FPdDWn/EfixAnDQ3V1tL90702 L9pG98WqFlTRJY8+Gt3EzJcf7tb8s+5bKePfDLwl5dCCWc6OY0Fvl2L3n U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAI9861OtJA2I/2dsb2JhbABagw1SVwTNHQqHSAGBFBZ3hAQBAQQBAQEaURsCAQgYLiEGCyUCBBOILgMRDcB+DYVEEwSNH4F6OoMvgR0FhQMChV6GOoQmhGiCDo5LhjODXGwBgUc X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="347246846" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP; 13 Aug 2014 14:59:12 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7DExCvI026817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Aug 2014 14:59:12 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.173]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 09:59:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: [tram] Call for adoption: draft-johnston-tram-turnbis-01 Thread-Index: AQHPtkLNU99tQfoIfEKiNQ54ZwLeA5vNb7oAgAALpwCAAAS9AIAARhUAgAC1Q4CAAHoYgA== Date: Wed, 13 Aug 2014 14:59:11 +0000 Message-ID: <9689EC6A-20AC-4117-AA48-39ECDD7BDFF5@cisco.com> References: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> In-Reply-To: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.237.174] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0AD0E8D39A5D9D40AA5AB798C7F32793@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zuLJs6HA9juhWyM-9TgCbRROaVk Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 14:59:15 -0000 +1 to referencing ORIGIN. +1 to incorporating SSODA into TURNbis +1 to adoption of draft-johnston-tram-turnbis-01 as WG doc [so that's a +3 by my count] -G On Aug 13, 2014, at 3:42 AM, Pal Martinsen (palmarti) = wrote: >=20 > +1 to referencing ORIGIN. >=20 > +1 to incorporating SSODA into TURNbis >=20 > SSODA now have two implementations (Both OpenSource). Coturn (https://cod= e.google.com/p/coturn/) and NATtools (https://github.com/cisco/NATTools) >=20 > I think the SSODA draft is ready to be merged into TURNbis and continue t= he discussion there. There probably still issues to be discussed, but bette= r to have them in a WG document than an I-D? Or? >=20 > .-. > P=E5l-Erik >=20 >=20 > On 12 Aug 2014, at 22:53, Justin Uberti wrote: >=20 >> I agree that simply referencing ORIGIN makes more sense. Also agree that= we should try to incorporate SSODA. >>=20 >> On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston wrote: >> Hi Oleg, >>=20 >> The ORIGIN attribute applies to both STUN and TURN, so if it were to be = merged, it would be into STUN-bis. I'm not so sure about merging as the OR= IGIN draft is almost ready for last call. The ORIGIN RFC could be normativ= ely referenced by both STUN-bis and TURN-bis when they are published next y= ear, if needed. >>=20 >> - Alan - >>=20 >>=20 >> On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko = wrote: >>=20 >>=20 >>=20 >> On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault w= rote: >> With WG chair hat off, I will provide my own personal views... >>=20 >> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault = wrote: >> > - What do we want to achieve with TURN-bis? That is, beyond the errata >> > and tracker issues, when will we consider the draft to be "done" and >> > ready to be sent to IESG? >>=20 >> I think we need to merge TURN-IPv6 into the base spec. IPv4-only >> protocols are a thing of the past. >>=20 >> I don't think we need to merge TURN-TCP. The base spec could remain >> compatible with the TURN-TCP RFC so that we don't need to update it >> too. >>=20 >> I think that it would make sense to merge the SSODA draft into the base = spec. >>=20 >>=20 >> I agree, and I'd merge the ORIGIN draft, too. That is a very important c= hange for a large enterprise. >> =20 >>=20 >> > - Given what we want to achieve, is this draft a good start? "Good" >> > meaning it is going in the right direction, not that it is close to >> > the end goal. >>=20 >> Since the draft is so close to the starting line, it's hard to go in >> the wrong direction... >>=20 >> Simon >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >>=20 >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >>=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 From nobody Wed Aug 13 21:24:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501461A00C9 for ; Wed, 13 Aug 2014 21:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MroqvWdWfx63 for ; Wed, 13 Aug 2014 21:24:44 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7751A00C2 for ; Wed, 13 Aug 2014 21:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4077; q=dns/txt; s=iport; t=1407990284; x=1409199884; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=12Tme40djbe1+zcnbnXH/H2JC095DOrymzn6EoqeQB0=; b=W+2raYolDGVoJizapq/P0Nh8vAReMVE5uLjUeSbd7QKdWXEE1JAPbacO 4PsX5Ag5yLBR6xCdKg0LLXoLJzBbvVONNNvNo/G14iRgeaaMKB1QPY3fZ MvuRFjkStWyzWiZ8OHN2E3tqMMPoZt6yeiBYpt6mYJRBaUg3ozw8LqV5k w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAK057FOtJV2P/2dsb2JhbABagw1SVwTNOgqHSAGBEhZ3hAMBAQEEAQEBGlEXBAIBCBEEAQEBCh0HIQYLFAkIAgQBEgiIJgMRDcEtDYVIEwSNH4F8OAaDKYEdBYUDAoVehjqEJoRokFmGM4NcbAGBRw X-IronPort-AV: E=Sophos;i="5.01,860,1400025600"; d="scan'208";a="347405358" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2014 04:24:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7E4OhMb020004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Aug 2014 04:24:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 23:24:43 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Gonzalo Salgueiro (gsalguei)" , "tram@ietf.org" Thread-Topic: [tram] Call for adoption: draft-johnston-tram-turnbis-01 Thread-Index: AQHPtkLNpUFgbIrVnUWQilcWp40uSZvNb7oAgAALpwCAAAS9AIAARhUAgAC1Q4CAAHodgIAAjIhQ Date: Thu, 14 Aug 2014 04:24:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831582E@xmb-rcd-x10.cisco.com> References: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> <9689EC6A-20AC-4117-AA48-39ECDD7BDFF5@cisco.com> In-Reply-To: <9689EC6A-20AC-4117-AA48-39ECDD7BDFF5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.34] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jm5NyhfFbqZ381NgnYjOR9EIZtk Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 04:24:48 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro > (gsalguei) > Sent: Wednesday, August 13, 2014 8:29 PM > To: tram@ietf.org > Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 >=20 > +1 to referencing ORIGIN. >=20 > +1 to incorporating SSODA into TURNbis >=20 > +1 to adoption of draft-johnston-tram-turnbis-01 as WG doc +1 to all above. -Tiru >=20 > [so that's a +3 by my count] >=20 > -G >=20 >=20 > On Aug 13, 2014, at 3:42 AM, Pal Martinsen (palmarti) > wrote: >=20 > > > > +1 to referencing ORIGIN. > > > > +1 to incorporating SSODA into TURNbis > > > > SSODA now have two implementations (Both OpenSource). Coturn > > (https://code.google.com/p/coturn/) and NATtools > > (https://github.com/cisco/NATTools) > > > > I think the SSODA draft is ready to be merged into TURNbis and continue > the discussion there. There probably still issues to be discussed, but be= tter to > have them in a WG document than an I-D? Or? > > > > .-. > > P=E5l-Erik > > > > > > On 12 Aug 2014, at 22:53, Justin Uberti wrote: > > > >> I agree that simply referencing ORIGIN makes more sense. Also agree th= at > we should try to incorporate SSODA. > >> > >> On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston > wrote: > >> Hi Oleg, > >> > >> The ORIGIN attribute applies to both STUN and TURN, so if it were to b= e > merged, it would be into STUN-bis. I'm not so sure about merging as the > ORIGIN draft is almost ready for last call. The ORIGIN RFC could be > normatively referenced by both STUN-bis and TURN-bis when they are > published next year, if needed. > >> > >> - Alan - > >> > >> > >> On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko > wrote: > >> > >> > >> > >> On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault > wrote: > >> With WG chair hat off, I will provide my own personal views... > >> > >> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault > wrote: > >> > - What do we want to achieve with TURN-bis? That is, beyond the > >> > errata and tracker issues, when will we consider the draft to be > >> > "done" and ready to be sent to IESG? > >> > >> I think we need to merge TURN-IPv6 into the base spec. IPv4-only > >> protocols are a thing of the past. > >> > >> I don't think we need to merge TURN-TCP. The base spec could remain > >> compatible with the TURN-TCP RFC so that we don't need to update it > >> too. > >> > >> I think that it would make sense to merge the SSODA draft into the bas= e > spec. > >> > >> > >> I agree, and I'd merge the ORIGIN draft, too. That is a very important > change for a large enterprise. > >> > >> > >> > - Given what we want to achieve, is this draft a good start? "Good" > >> > meaning it is going in the right direction, not that it is close to > >> > the end goal. > >> > >> Since the draft is so close to the starting line, it's hard to go in > >> the wrong direction... > >> > >> 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 > >> > >> > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Fri Aug 15 08:01:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19C91A082E for ; Fri, 15 Aug 2014 08:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBkxfkDm1waa for ; Fri, 15 Aug 2014 08:01:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4509C1A065D for ; Fri, 15 Aug 2014 08:01:48 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C8EBC28555 for ; Fri, 15 Aug 2014 15:01:47 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9B365285F0 for ; Fri, 15 Aug 2014 15:01:47 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 98A998005C for ; Fri, 15 Aug 2014 15:01:47 +0000 (GMT) Message-ID: <53EE20DB.40800@akamai.com> Date: Fri, 15 Aug 2014 11:01:47 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: tram@ietf.org References: <951FFC8D-3C55-47E6-9D7B-281CDF9EC5CA@cisco.com> <9689EC6A-20AC-4117-AA48-39ECDD7BDFF5@cisco.com> <913383AAA69FF945B8F946018B75898A2831582E@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831582E@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XHAyNrAocB9wuqBN4cOe55NX5M8 Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 15:01:50 -0000 +1 to WG I think that both TURNbis and STUNbis should cover things that the WG considers to be problems with the core protocols that apply broadly to virtually any STUN/TURN deployment. For that reason ... +1 to incorporating SSODA (I think IPv4/6 dual stack support should be considered a core TURN requirement) I'm uncertain what I think about the ORIGIN draft here. It mostly applies to 3rd party TURN service deployments I think, so I agree with not folding it into TURNbis. I'm just not sure whether an extension for improved 3rd party support even needs to be referenced. Are we intending to reference all such 3rd party support extensions? To be clear, I don't object to it being referenced. I'm just not sure it needs to be in order for TURNbis to be complete. --Brandon On 08/14/2014 12:24 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo Salgueiro >> (gsalguei) >> Sent: Wednesday, August 13, 2014 8:29 PM >> To: tram@ietf.org >> Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 >> >> +1 to referencing ORIGIN. >> >> +1 to incorporating SSODA into TURNbis >> >> +1 to adoption of draft-johnston-tram-turnbis-01 as WG doc > > +1 to all above. > > -Tiru > >> >> [so that's a +3 by my count] >> >> -G >> >> >> On Aug 13, 2014, at 3:42 AM, Pal Martinsen (palmarti) >> wrote: >> >>> >>> +1 to referencing ORIGIN. >>> >>> +1 to incorporating SSODA into TURNbis >>> >>> SSODA now have two implementations (Both OpenSource). Coturn >>> (https://code.google.com/p/coturn/) and NATtools >>> (https://github.com/cisco/NATTools) >>> >>> I think the SSODA draft is ready to be merged into TURNbis and continue >> the discussion there. There probably still issues to be discussed, but better to >> have them in a WG document than an I-D? Or? >>> >>> .-. >>> Pål-Erik >>> >>> >>> On 12 Aug 2014, at 22:53, Justin Uberti wrote: >>> >>>> I agree that simply referencing ORIGIN makes more sense. Also agree that >> we should try to incorporate SSODA. >>>> >>>> On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston >> wrote: >>>> Hi Oleg, >>>> >>>> The ORIGIN attribute applies to both STUN and TURN, so if it were to be >> merged, it would be into STUN-bis. I'm not so sure about merging as the >> ORIGIN draft is almost ready for last call. The ORIGIN RFC could be >> normatively referenced by both STUN-bis and TURN-bis when they are >> published next year, if needed. >>>> >>>> - Alan - >>>> >>>> >>>> On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko >> wrote: >>>> >>>> >>>> >>>> On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault >> wrote: >>>> With WG chair hat off, I will provide my own personal views... >>>> >>>> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault >> wrote: >>>>> - What do we want to achieve with TURN-bis? That is, beyond the >>>>> errata and tracker issues, when will we consider the draft to be >>>>> "done" and ready to be sent to IESG? >>>> >>>> I think we need to merge TURN-IPv6 into the base spec. IPv4-only >>>> protocols are a thing of the past. >>>> >>>> I don't think we need to merge TURN-TCP. The base spec could remain >>>> compatible with the TURN-TCP RFC so that we don't need to update it >>>> too. >>>> >>>> I think that it would make sense to merge the SSODA draft into the base >> spec. >>>> >>>> >>>> I agree, and I'd merge the ORIGIN draft, too. That is a very important >> change for a large enterprise. >>>> >>>> >>>>> - Given what we want to achieve, is this draft a good start? "Good" >>>>> meaning it is going in the right direction, not that it is close to >>>>> the end goal. >>>> >>>> Since the draft is so close to the starting line, it's hard to go in >>>> the wrong direction... >>>> >>>> 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 >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Aug 15 09:57:31 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10E91A0087 for ; Fri, 15 Aug 2014 09:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEjErVIy5eYO for ; Fri, 15 Aug 2014 09:57:17 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id B72581A0084 for ; Fri, 15 Aug 2014 09:57:17 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3A508285FD; Fri, 15 Aug 2014 16:57:17 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 1C1E4285F7; Fri, 15 Aug 2014 16:57:17 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 185CE2036; Fri, 15 Aug 2014 16:57:17 +0000 (GMT) Message-ID: <53EE3BED.8020006@akamai.com> Date: Fri, 15 Aug 2014 12:57:17 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Alan Johnston , "tram@ietf.org" , "Tirumaleswar Reddy (tireddy)" References: <20140810225035.24286.20595.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pnQ_u_MWeXS2XTLSfT1ah_IzXw0 Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:57:23 -0000 Thanks to both of you for taking on this task. Regarding questions that you ask in editor's notes: * I think it would nice to have a unified document for IPv4, IPv6, UDP, and TCP, and so merging RFC6062 and RFC6156 text into TURNbis would be good. In particular, the IPv6 is probably necessary to include if SSODA is to be included. That said, I don't feel strongly enough about it to put up any resistance if anyone else disagrees. * I don't think a specific algorithm from RFC6056 needs to be recommended. The RFC itself provides a good discussion of the tradeoffs, but itself falls short of providing any recommendations. It might be worthwhile to note that some of the RFC6056 discussion re: NAPT applies to TURN allocations as well. --Brandon On 08/10/2014 06:55 PM, Alan Johnston wrote: > All, > > Tiru and I have made a start to the TURNbis draft. We have submitted it > as an individual draft so the working group can decide if this is a > reasonable starting point for our chartered work item. > > The -00 version is essentially unchanged from RFC 5766 to make it easy > to track the changes. The -01 version represents our edits so far > including a number of Editor's Notes. > > Feedback and comments are most welcome. > > - Alan - > > ---------- Forwarded message ---------- > From: ** > > Date: Sun, Aug 10, 2014 at 5:50 PM > Subject: New Version Notification for draft-johnston-tram-turnbis-01.txt > To: Tirumaleswar Reddy >, > Alan Johnston >, Rohan Mahy >, Jonathan Rosenberg >, Philip Matthews > > > > > A new version of I-D, draft-johnston-tram-turnbis-01.txt > has been successfully submitted by Alan Johnston and posted to the > IETF repository. > > Name: draft-johnston-tram-turnbis > Revision: 01 > Title: Traversal Using Relays around NAT (TURN): Relay > Extensions to Session Traversal Utilities for NAT (STUN) > Document date: 2014-08-10 > Group: Individual Submission > Pages: 69 > URL: http://www.ietf.org/internet-drafts/draft-johnston-tram-turnbis-01.txt > Status: https://datatracker.ietf.org/doc/draft-johnston-tram-turnbis/ > Htmlized: http://tools.ietf.org/html/draft-johnston-tram-turnbis-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-turnbis-01 > > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. > > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. > > > > > 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 > . > > The IETF Secretariat > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Sun Aug 17 11:42:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B091A6EF7 for ; Sun, 17 Aug 2014 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7vz8B9aR8Vu for ; Sun, 17 Aug 2014 11:42:33 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1261C1A6EEC for ; Sun, 17 Aug 2014 11:42:32 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so4100832wgh.18 for ; Sun, 17 Aug 2014 11:42:31 -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:content-type; bh=V7SB17SiI+OSGTf/MZx7wE54h2zRBkpWouHlxaq5Tzg=; b=XW2Xtr/aKygjbPbxMPWDpoj9t89b3J789lrk4SMQJjLrjA18PGWpxb1mtYZj8ehW6B XCLdO+KDei+hgYKnskRAtF7j2jAexyedvHDBDlHXCYP5slNtJ02VNVEl53I9xYk9c/nJ f95n5YYtsdca5RHoWWfAMzHJdP7hYh2gAGgPj4oY4pi6zZX4HsLOC62QOmE3YYp6/T51 eUwtkCWaWCJ6fnZcQOZVN/Lv3E/+97JKE7arxvOSmNYp7I0gkXqc6AX+kr9fGc5GXbFf zWTl52aoz537TnEzaXVp6h/WioMzGzsyTVA9lDi2TRFNj2Xnlpfu8Svk5QbvWGvqMXGY Mmtg== MIME-Version: 1.0 X-Received: by 10.194.78.4 with SMTP id x4mr36712430wjw.44.1408300951664; Sun, 17 Aug 2014 11:42:31 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Sun, 17 Aug 2014 11:42:31 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Aug 2014 13:42:31 -0500 Message-ID: From: Alan Johnston To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7bfcf914f629ae0500d79d26 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Hx4cFnE-8ywWK2R_7uyyHmDgJLg Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 18:42:35 -0000 --047d7bfcf914f629ae0500d79d26 Content-Type: text/plain; charset=UTF-8 Justin, I now understand your issue. There is no real way for a client or server to enforce that the ORIGIN attribute be the same across requests. The existing text about MESSAGE-INTEGRITY isn't all that useful, either. Instead, I suggest we include text saying that only DTLS or TLS transport provides integrity protection in all cases for ORIGIN attributes. I'll send the suggested text in another list mail. - Alan - On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti wrote: > As mentioned I think what you describe is hard to do when using stateless > stack - see my email on Aug 1 for a suggestion on how to resolve this. > > > On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston > wrote: > >> Justin & Oleg, >> >> Thanks for the feedback. I will change the one requirement to a MUST: >> >> To mitigate any potential concerns arising from the unprotected attribute >> in the initial message, servers MUST verify that the ORIGIN attribute(s) >> present in the authenticated STUN requests match those that were received >> in the initial, unauthenticated requests. >> >> Having running code is a good thing! >> >> - Alan - >> >> >> On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti wrote: >> >>> I realized when looking at a code review for this that the >>> stateless-stack approach makes it difficult to enforce this as written. >>> Instead, I think the advice should be that the ORIGIN attributes in the >>> authenticated request MUST be verified to be consistent with the REALM >>> value that is supplied. >>> >>> >>> On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko >>> wrote: >>> >>>> I agree with the changes. >>>> >>>> Thanks >>>> Oleg >>>> >>>> >>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston < >>>> alan.b.johnston@gmail.com> wrote: >>>> >>>>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: >>>>> >>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity >>>>> protection >>>>> for all attributes present in a STUN request. However, MESSAGE- >>>>> INTEGRITY is not present in the initial STUN message sent, so the >>>>> initial ORIGIN attribute will not have integrity protection and >>>>> hence >>>>> could be modified or removed from a STUN request without the server >>>>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY >>>>> attribute will provide integrity protection for the contents of the >>>>> ORIGIN attribute. The strength of this protection is a function of >>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>> >>>>> Justin has proposed changing it to: >>>>> >>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity >>>>> protection >>>>> for all attributes present in a STUN request. However, when using >>>>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE- >>>>> INTEGRITY is not present in the initial STUN message sent, and so >>>>> the >>>>> initial ORIGIN attribute will not have integrity protection. Hence, >>>>> it could be modified or removed from a STUN request without the >>>>> server >>>>> knowing, which could affect the server's choice of REALM. >>>>> >>>>> With the long-term credential mechanism, subsequent STUN requests >>>>> will >>>>> contain the MESSAGE-INTEGRITY attribute and will provide integrity >>>>> protection >>>>> for the contents of the ORIGIN attribute(s). To mitigate any >>>>> potential concerns >>>>> arising from the unprotected attribute in the initial message, >>>>> servers SHOULD >>>>> verify that the ORIGIN attribute(s) present in the authenticated >>>>> STUN requests >>>>> match those that were received in the initial, unauthenticated >>>>> requests. >>>>> >>>>> The strength of the integrity protection is a function of >>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>> >>>>> Anyone object to this clarification? Any other suggested edits to the >>>>> Security Considerations section? >>>>> >>>>> - Alan - >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> > --047d7bfcf914f629ae0500d79d26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin,

I now understand your issue. = =C2=A0There is no real way for a client or server to enforce that the ORIGI= N attribute be the same across requests. =C2=A0The existing text about MESS= AGE-INTEGRITY isn't all that useful, either. =C2=A0Instead, =C2=A0I sug= gest we include text saying that only DTLS or TLS transport provides integr= ity protection in all cases for ORIGIN attributes. =C2=A0

I'll send the suggested text in another list mail.<= /div>

- Alan -



On Mon, Aug 11, 2014 at 11:53 AM, Justin Ube= rti <juberti@google.com> wrote:
As mentioned I think what you describe is hard to do when = using stateless stack - see my email on Aug 1 for a suggestion on how to re= solve this.


On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <alan.b.johnston@gm= ail.com> wrote:
Justin & Oleg,

Thanks for the feedb= ack. =C2=A0I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected = attribute in the initial message, servers MUST verify that the ORIGIN attri= bute(s) present in the authenticated STUN requests match those that were re= ceived in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, = Aug 1, 2014 at 5:40 PM, Justin Uberti <juberti@google.com> = wrote:
I realized when looking at a code review = for this that the stateless-stack approach makes it difficult to enforce th= is as written. Instead, I think the advice should be that the ORIGIN attrib= utes in the authenticated request MUST be verified to be consistent with th= e REALM value that is supplied.


On Fri, Aug 1= , 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
I agree with the changes.
Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM= , Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-= tram-stun-origin-00, the Security Considerations says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can p= rovide integrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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



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





--047d7bfcf914f629ae0500d79d26-- From nobody Sun Aug 17 11:45:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93D1A009C for ; Sun, 17 Aug 2014 11:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W6s9m4sP_iO for ; Sun, 17 Aug 2014 11:45:21 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32CC1A0095 for ; Sun, 17 Aug 2014 11:45:20 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so4059744wgh.3 for ; Sun, 17 Aug 2014 11:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IUGccpueh1n4Icmlfj4iYrio9rEqDF8WQInO0WEOBB8=; b=o+a3FjI1VPfpJ1V7PJZfNalS6/IJnaBro0DntEuxNvHSm+smujTReVvA6jzRXyK5An 9YpYG5cLdpXcwQ2SqAvz6pRXhiF3eShorcj95G5dsO9Vk0bPzwc5exrN8DcDIiChTGa5 oBtEbxpIJdx4RvgndaRLTtTtHBTsWJ2FhmMAOKyLDjtVHfHBEf34unHQTJua+hga/V3o s3g09lmWukfN54ULpAjXzVC9BL7hnuNO46dRdy4VpAhqV9Q5SV5qvCgSUKKVXB72UGPd CmX+RGwlR2dZ952NQEP1lSCgCP1Cr7tsHZ3msYOX+L/UbvNMHEvd2QbjUFSACYd/Xa0N AOzg== MIME-Version: 1.0 X-Received: by 10.194.78.4 with SMTP id x4mr36721336wjw.44.1408301119298; Sun, 17 Aug 2014 11:45:19 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Sun, 17 Aug 2014 11:45:19 -0700 (PDT) Date: Sun, 17 Aug 2014 13:45:19 -0500 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=047d7bfcf914f3e2da0500d7a755 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mWew1HK7FOvq2Bu6UPD6iZ__0No Subject: [tram] STUN Origin Open Issue Resolution Proposal X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 18:45:23 -0000 --047d7bfcf914f3e2da0500d7a755 Content-Type: text/plain; charset=UTF-8 Based on the discussion on the two Open Issues (Integrity Protection and Size of Attribute) discussed on this list, and the XMPP Origin issue discussed on the XMPP list (thanks to Peter Saint-Andre for his text), here is my proposed changes to the draft. Let me know if you have concerns about this new text. I plan to revise the draft in the next few days with these changes. - Alan - Proposed changes to draft-ietf-tram-stun-origin-00: OLD: For a Jabber client [RFC6120] using STUN and TURN, the ORIGIN attribute is the Jabber ID (JID) [RFC6122] of the Jabber Server that the client is using. NEW: For an XMPP client [RFC6120] using STUN and TURN, the ORIGIN attribute is an XMPP URI [RFC5122] representing the domainpart of the client's Jabber ID (JID) [RFC6122]; for example, if the client's JID is "juliet@im.example.com/balcony" then the ORIGIN attribute would be "xmpp:im.example.com". Add to TURN Usage section: Including the ORIGIN attribute in the Send method is NOT RECOMMENDED. OLD: It MUST contain a UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes. The value of 268 is chosen to be larger than the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number. Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes. NEW: It MUST contain a UTF-8 [RFC3629] encoded sequence of characters. Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes. The size and number of ORIGINs included in a STUN message can have a major impact on the size of a STUN packet, and could potentially cause UDP fragmentation. HTTP origins are less than 267 characters (the maximum 253 character domain name plus 8 characters for the URI scheme plus 5 characters for the port number). It is NOT RECOMMENDED that an ORIGIN attribute be included if the total size (including type, length, and padding) is larger than 272 octets. Multiple ORIGIN attributes SHOULD NOT be included if the total size of these attributes exceeds 272 octets. OLD: The STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request. However, MESSAGE-INTEGRITY is not present in the initial STUN message sent, so the initial ORIGIN attribute will not have integrity protection and hence could be modified or removed from a STUN request without the server knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY attribute will provide integrity protection for the contents of the ORIGIN attribute. The strength of this protection is a function of the secret used to generate the MESSAGE-INTEGRITY value. NEW: While the STUN MESSAGE-INTEGRITY attribute can provide integrity protection for all attributes present in a STUN request, MESSAGE-INTEGRITY is not present in the initial STUN message sent. As a result, an ORIGIN attribute could be modified or removed from a STUN request without the server knowing. DTLS or TLS transport SHOULD be used when integrity protection for the ORIGIN attribute is important. --047d7bfcf914f3e2da0500d7a755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Based on the discussion on the two Open Issues (Integrity = Protection and Size of Attribute) discussed on this list, and the XMPP Orig= in issue discussed on the XMPP list (thanks to=C2=A0Peter Saint-Andre=C2=A0for his = text), here is my proposed changes to the draft.

Let me know if you have concerns about this new text. =C2=A0= I plan to revise the draft in the next few days with these changes.

- Alan -

Proposed changes to dra= ft-ietf-tram-stun-origin-00:

OLD:

For a Jabber client [RFC6= 120] using STUN and TURN, the ORIGIN attribute is the Jabber ID (JID) [RFC6= 122] of the Jabber Server that the client is using.

NEW:

=C2=A0 =C2=A0For an=C2=A0XMPP= =C2=A0client [RFC6120] using STUN and TURN, the ORIGIN
=C2=A0 =C2=A0at= tribute is an=C2=A0XMPP=C2=A0URI [RFC5122] represent= ing the domainpart
=C2=A0 =C2=A0of= the client's Jabber ID (JID) [RFC6122]; for example, if the
=C2=A0 =C2=A0client's JID is &qu= ot;juliet@im.example.c= om/balcony= " then the= ORIGIN
=C2=A0 =C2=A0at= tribute would be "xmpp:im.example.com".


Add to TURN Usage section:

=C2=A0 =C2=A0Including the ORIGIN attribute in the S= end method is NOT RECOMMENDED.

OLD:

=
=C2=A0 =C2=A0It MUST contain a
=C2=A0 =C2=A0UTF-8 [RFC3629] = encoded sequence of characters less than 268 bytes.
=C2=A0 =C2=A0= The value of 268 is chosen to be larger than the maximum 253
=C2= =A0 =C2=A0character domain name plus 8 characters for the URI scheme plus 5=
=C2=A0 =C2=A0characters for the port number. =C2=A0Senders MAY include= multiple ORIGIN
=C2=A0 =C2=A0attributes in a request, and receiv= ers MUST support parsing and
=C2=A0 =C2=A0receiving multiple ORIG= IN attributes.

NEW:

It MUST contain a UTF-8 [RFC3629] encode= d sequence of characters. =C2=A0Senders MAY include multiple ORIGIN attribu= tes in a request, and receivers MUST support parsing and receiving multiple= ORIGIN attributes. =C2=A0The size and number of ORIGINs included in a STUN= message can have a major impact on the size of a STUN packet, and could po= tentially cause UDP fragmentation. =C2=A0HTTP origins are less than 267 cha= racters (the maximum 253 character domain name plus 8 characters for the UR= I scheme plus 5 characters for the port number). =C2=A0It is NOT RECOMMENDE= D that an ORIGIN attribute be included if the total size (including type, l= ength, and padding) is larger than 272 octets. =C2=A0Multiple ORIGIN attrib= utes SHOULD NOT be included if the total size of these attributes exceeds 2= 72 octets.=C2=A0

OLD:

The STUN MESSAGE-INTEGRIT= Y attribute can provide integrity protection for all attributes present in = a STUN request. =C2=A0However, MESSAGE-INTEGRITY is not present in the init= ial STUN message sent, so the initial ORIGIN attribute will not have integr= ity protection and hence could be modified or removed from a STUN request w= ithout the server knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY attribute will provide integrity protection for the content= s of the ORIGIN attribute. =C2=A0The strength of this protection is a funct= ion of the secret used to generate the MESSAGE-INTEGRITY value.=C2=A0

NEW:

While the STUN MESSAGE-IN= TEGRITY attribute can provide integrity protection for all attributes prese= nt in a STUN request, MESSAGE-INTEGRITY is not present in the initial STUN = message sent. As a result, an ORIGIN attribute could be modified or removed= from a STUN request without the server knowing. DTLS or TLS transport SHOU= LD be used when integrity protection for the ORIGIN attribute is important.=


--047d7bfcf914f3e2da0500d7a755-- From nobody Sun Aug 17 14:20:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805491A0025 for ; Sun, 17 Aug 2014 14:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 W1rdjDD131ZT for ; Sun, 17 Aug 2014 14:20:51 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBA31A0026 for ; Sun, 17 Aug 2014 14:20:50 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so6091622pdj.26 for ; Sun, 17 Aug 2014 14:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=d9buLd00kIGNHK6GzmWG1r9nM1KTFdb2geMG0mZo1Pk=; b=IS5pf/Y12bFFsN6MNT2QQTptNwcdeFdkDaRXWhwpwgjh+Ujf9amj0z+jHib5wqA3C/ 9H5ZvLDco5CAkH9hxsE1EzdajVRhcCx22HeTqlhHcDithhgj9llgleU4LQGsXC3dwlNH K4N0r3iyVlal0AlrKwpQ2YNp17V/kwUdOtLtzddBoxUzPDCvCTZ072iUL3/CP1SS8e9u TrnlLqmfdTa84MkwoFeNYNvWz58S2HHn5bHSIeGjRWpabggkAu3gCJcGbHVCkl6bae3J zoFAt9abHuGWP1iqR81UmLqOvhkmWPK/UKua1fkaGriDGDXlozA2DXt+VjxHOUexR0+W pcNg== X-Received: by 10.66.124.168 with SMTP id mj8mr30082485pab.78.1408310450646; Sun, 17 Aug 2014 14:20:50 -0700 (PDT) Received: from [10.172.106.186] (113.sub-70-197-12.myvzw.com. [70.197.12.113]) by mx.google.com with ESMTPSA id pz1sm14188275pbc.49.2014.08.17.14.20.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 14:20:48 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-CE4B82CB-F0A6-40DF-A342-5D7841B84BAF Content-Transfer-Encoding: 7bit Message-Id: <8499EB1C-A2F7-4F57-BF03-D5E5226B2B6D@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Sun, 17 Aug 2014 14:20:46 -0700 To: Alan Johnston Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ujDQxCUA-5v8rdGyQxqjYNntdD8 Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 21:20:53 -0000 --Apple-Mail-CE4B82CB-F0A6-40DF-A342-5D7841B84BAF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alan, that's not exactly true. Coturn 4.1.2.1 enforces the origin policy. Bu= t the problem is the reason why we enforce that. Let me read the document an= d i ll provide my thoughts. Thanks Oleg Sent from my iPhone > On Aug 17, 2014, at 11:42 AM, Alan Johnston wr= ote: >=20 > Justin, >=20 > I now understand your issue. There is no real way for a client or server t= o enforce that the ORIGIN attribute be the same across requests. The existi= ng text about MESSAGE-INTEGRITY isn't all that useful, either. Instead, I s= uggest we include text saying that only DTLS or TLS transport provides integ= rity protection in all cases for ORIGIN attributes. =20 >=20 > I'll send the suggested text in another list mail. >=20 > - Alan - >=20 >=20 >=20 >> On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti wrot= e: >> As mentioned I think what you describe is hard to do when using stateless= stack - see my email on Aug 1 for a suggestion on how to resolve this. >>=20 >>=20 >>> On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston wrote: >>> Justin & Oleg, >>>=20 >>> Thanks for the feedback. I will change the one requirement to a MUST: >>>=20 >>> To mitigate any potential concerns arising from the unprotected attribut= e in the initial message, servers MUST verify that the ORIGIN attribute(s) p= resent in the authenticated STUN requests match those that were received in t= he initial, unauthenticated requests. >>>=20 >>> Having running code is a good thing! >>>=20 >>> - Alan - >>>=20 >>>=20 >>>> On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti wrot= e: >>>> I realized when looking at a code review for this that the stateless-st= ack approach makes it difficult to enforce this as written. Instead, I think= the advice should be that the ORIGIN attributes in the authenticated reques= t MUST be verified to be consistent with the REALM value that is supplied. >>>>=20 >>>>=20 >>>>> On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko w= rote: >>>>> I agree with the changes. >>>>>=20 >>>>> Thanks >>>>> Oleg >>>>>=20 >>>>>=20 >>>>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston wrote: >>>>>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: = =20 >>>>>>=20 >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protect= ion >>>>>> for all attributes present in a STUN request. However, MESSAGE- >>>>>> INTEGRITY is not present in the initial STUN message sent, so the >>>>>> initial ORIGIN attribute will not have integrity protection and he= nce >>>>>> could be modified or removed from a STUN request without the serve= r >>>>>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRIT= Y >>>>>> attribute will provide integrity protection for the contents of th= e >>>>>> ORIGIN attribute. The strength of this protection is a function o= f >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>>=20 >>>>>> Justin has proposed changing it to: >>>>>>=20 >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protect= ion >>>>>> for all attributes present in a STUN request. However, when using= =20 >>>>>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE= - >>>>>> INTEGRITY is not present in the initial STUN message sent, and so t= he >>>>>> initial ORIGIN attribute will not have integrity protection. Hence= , >>>>>> it could be modified or removed from a STUN request without the se= rver >>>>>> knowing, which could affect the server's choice of REALM. >>>>>> =20 >>>>>> With the long-term credential mechanism, subsequent STUN requests w= ill =20 >>>>>> contain the MESSAGE-INTEGRITY attribute and will provide integrity= protection=20 >>>>>> for the contents of the ORIGIN attribute(s). To mitigate any pote= ntial concerns=20 >>>>>> arising from the unprotected attribute in the initial message, ser= vers SHOULD=20 >>>>>> verify that the ORIGIN attribute(s) present in the authenticated S= TUN requests >>>>>> match those that were received in the initial, unauthenticated req= uests. >>>>>>=20 >>>>>> The strength of the integrity protection is a function of >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>>=20 >>>>>> Anyone object to this clarification? Any other suggested edits to th= e Security Considerations section? >>>>>>=20 >>>>>> - Alan - >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tram mailing list >>>>>> tram@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tram >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> tram mailing list >>>>> tram@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tram >=20 --Apple-Mail-CE4B82CB-F0A6-40DF-A342-5D7841B84BAF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Alan, that's not exactly true. Coturn 4.1.2.1 enforces the origin policy. But the problem is the reason why we enforce that. Let me read the document and i ll provide my thoughts.

Thanks
Oleg

Sent from my iPhone

On Aug 17, 2014, at 11:42 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:

Justin,

I now understand your issue.  There is no real way for a client or server to enforce that the ORIGIN attribute be the same across requests.  The existing text about MESSAGE-INTEGRITY isn't all that useful, either.  Instead,  I suggest we include text saying that only DTLS or TLS transport provides integrity protection in all cases for ORIGIN attributes.  

I'll send the suggested text in another list mail.

- Alan -



On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti <juberti@google.com> wrote:
As mentioned I think what you describe is hard to do when using stateless stack - see my email on Aug 1 for a suggestion on how to resolve this.


On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
Justin & Oleg,

Thanks for the feedback.  I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected attribute in the initial message, servers MUST verify that the ORIGIN attribute(s) present in the authenticated STUN requests match those that were received in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti <juberti@google.com> wrote:
I realized when looking at a code review for this that the stateless-stack approach makes it difficult to enforce this as written. Instead, I think the advice should be that the ORIGIN attributes in the authenticated request MUST be verified to be consistent with the REALM value that is supplied.


On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
I agree with the changes.

Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-tram-stun-origin-00, the Security Considerations says:   

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, so the
   initial ORIGIN attribute will not have integrity protection and hence
   could be modified or removed from a STUN request without the server
   knowing.  Subsequent STUN requests containing the MESSAGE-INTEGRITY
   attribute will provide integrity protection for the contents of the
   ORIGIN attribute.  The strength of this protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Justin has proposed changing it to:

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, when using 
   STUN's long-term credential mechanism, as is done in TURN, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, and so the
   initial ORIGIN attribute will not have integrity protection. Hence,
   it could be modified or removed from a STUN request without the server
   knowing, which could affect the server's choice of REALM.
   
   With the long-term credential mechanism, subsequent STUN requests will     
   contain the MESSAGE-INTEGRITY attribute and will provide integrity protection 
   for the contents of the ORIGIN attribute(s).  To mitigate any potential concerns 
   arising from the unprotected attribute in the initial message, servers SHOULD 
   verify that the ORIGIN attribute(s) present in the authenticated STUN requests
   match those that were received in the initial, unauthenticated requests.

   The strength of the integrity protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Anyone object to this clarification?  Any other suggested edits to the Security Considerations section?

- Alan -

_______________________________________________
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-CE4B82CB-F0A6-40DF-A342-5D7841B84BAF-- From nobody Sun Aug 17 15:40:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC191A007A for ; Sun, 17 Aug 2014 15:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ObA5NKwLMhUh for ; Sun, 17 Aug 2014 15:40:52 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1631A0068 for ; Sun, 17 Aug 2014 15:40:52 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so6387442pad.24 for ; Sun, 17 Aug 2014 15:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HqSuNrGk9G8PS14FZvIWVoMItcw6hE4IrLgVjv0QLtI=; b=EKKFSfkr2CndtyeC3Vi6q4Od+cavGYYF3Ai7ehYgylt//TfI13ZWNzcdNCYic8P0Yi AMHkse+L6pHc6y53+eFeC3Qhre1PTYTx0XzveIzFdPbTJyHF3TF+XRMdmzQGxN//lZxf mV2MWKlIDcIXj1whW1NcuT7XZSN5wox8xtBhvSxhhfJ7BrjU42OJ6gvjgG5J8hPbZekG mIXyN08uSXOoOr9CrKoC0iKEBhX3svzj8d8biyUOJdagmNzCu5cWEXaBFc17do4+GYZ3 weu7WtMq3vNkkHQJ89pPRZnZw9++hcEKmHPN78MtKvgmSkIC7cV0ON7Ro6Le03vHhDsD tccg== X-Received: by 10.70.103.8 with SMTP id fs8mr34438159pdb.81.1408315251819; Sun, 17 Aug 2014 15:40:51 -0700 (PDT) Received: from ?IPv6:2600:1010:b017:6cce:5970:d12:5976:81c5? ([2600:1010:b017:6cce:5970:d12:5976:81c5]) by mx.google.com with ESMTPSA id qb2sm14299095pbb.0.2014.08.17.15.40.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 15:40:49 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-ED6A3A08-35DE-4328-B822-FA70761D838B Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Sun, 17 Aug 2014 15:40:47 -0700 To: Alan Johnston Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uOZFJDH5t6yo0cHYkK0ueneH11Y Cc: "tram@ietf.org" , Justin Uberti Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 22:40:53 -0000 --Apple-Mail-ED6A3A08-35DE-4328-B822-FA70761D838B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alan, I checked the new edition. The message-integrity wording is accurate a= nd it is similar to how i understand this issue. So i agree with the new edi= tion. Thanks! Oleg Sent from my iPhone > On Aug 17, 2014, at 11:42 AM, Alan Johnston wr= ote: >=20 > Justin, >=20 > I now understand your issue. There is no real way for a client or server t= o enforce that the ORIGIN attribute be the same across requests. The existi= ng text about MESSAGE-INTEGRITY isn't all that useful, either. Instead, I s= uggest we include text saying that only DTLS or TLS transport provides integ= rity protection in all cases for ORIGIN attributes. =20 >=20 > I'll send the suggested text in another list mail. >=20 > - Alan - >=20 >=20 >=20 >> On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti wrot= e: >> As mentioned I think what you describe is hard to do when using stateless= stack - see my email on Aug 1 for a suggestion on how to resolve this. >>=20 >>=20 >>> On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston wrote: >>> Justin & Oleg, >>>=20 >>> Thanks for the feedback. I will change the one requirement to a MUST: >>>=20 >>> To mitigate any potential concerns arising from the unprotected attribut= e in the initial message, servers MUST verify that the ORIGIN attribute(s) p= resent in the authenticated STUN requests match those that were received in t= he initial, unauthenticated requests. >>>=20 >>> Having running code is a good thing! >>>=20 >>> - Alan - >>>=20 >>>=20 >>>> On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti wrot= e: >>>> I realized when looking at a code review for this that the stateless-st= ack approach makes it difficult to enforce this as written. Instead, I think= the advice should be that the ORIGIN attributes in the authenticated reques= t MUST be verified to be consistent with the REALM value that is supplied. >>>>=20 >>>>=20 >>>>> On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko w= rote: >>>>> I agree with the changes. >>>>>=20 >>>>> Thanks >>>>> Oleg >>>>>=20 >>>>>=20 >>>>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston wrote: >>>>>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: = =20 >>>>>>=20 >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protect= ion >>>>>> for all attributes present in a STUN request. However, MESSAGE- >>>>>> INTEGRITY is not present in the initial STUN message sent, so the >>>>>> initial ORIGIN attribute will not have integrity protection and he= nce >>>>>> could be modified or removed from a STUN request without the serve= r >>>>>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRIT= Y >>>>>> attribute will provide integrity protection for the contents of th= e >>>>>> ORIGIN attribute. The strength of this protection is a function o= f >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>>=20 >>>>>> Justin has proposed changing it to: >>>>>>=20 >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity protect= ion >>>>>> for all attributes present in a STUN request. However, when using= =20 >>>>>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE= - >>>>>> INTEGRITY is not present in the initial STUN message sent, and so t= he >>>>>> initial ORIGIN attribute will not have integrity protection. Hence= , >>>>>> it could be modified or removed from a STUN request without the se= rver >>>>>> knowing, which could affect the server's choice of REALM. >>>>>> =20 >>>>>> With the long-term credential mechanism, subsequent STUN requests w= ill =20 >>>>>> contain the MESSAGE-INTEGRITY attribute and will provide integrity= protection=20 >>>>>> for the contents of the ORIGIN attribute(s). To mitigate any pote= ntial concerns=20 >>>>>> arising from the unprotected attribute in the initial message, ser= vers SHOULD=20 >>>>>> verify that the ORIGIN attribute(s) present in the authenticated S= TUN requests >>>>>> match those that were received in the initial, unauthenticated req= uests. >>>>>>=20 >>>>>> The strength of the integrity protection is a function of >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>>=20 >>>>>> Anyone object to this clarification? Any other suggested edits to th= e Security Considerations section? >>>>>>=20 >>>>>> - Alan - >>>>>>=20 >>>>>> _______________________________________________ >>>>>> tram mailing list >>>>>> tram@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tram >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> tram mailing list >>>>> tram@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tram >=20 --Apple-Mail-ED6A3A08-35DE-4328-B822-FA70761D838B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Alan, I checked the new edition. The message-integrity wording is accurate and it is similar to how i understand this issue. So i agree with the new edition.

Thanks!
Oleg

Sent from my iPhone

On Aug 17, 2014, at 11:42 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:

Justin,

I now understand your issue.  There is no real way for a client or server to enforce that the ORIGIN attribute be the same across requests.  The existing text about MESSAGE-INTEGRITY isn't all that useful, either.  Instead,  I suggest we include text saying that only DTLS or TLS transport provides integrity protection in all cases for ORIGIN attributes.  

I'll send the suggested text in another list mail.

- Alan -



On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti <juberti@google.com> wrote:
As mentioned I think what you describe is hard to do when using stateless stack - see my email on Aug 1 for a suggestion on how to resolve this.


On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
Justin & Oleg,

Thanks for the feedback.  I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected attribute in the initial message, servers MUST verify that the ORIGIN attribute(s) present in the authenticated STUN requests match those that were received in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti <juberti@google.com> wrote:
I realized when looking at a code review for this that the stateless-stack approach makes it difficult to enforce this as written. Instead, I think the advice should be that the ORIGIN attributes in the authenticated request MUST be verified to be consistent with the REALM value that is supplied.


On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> wrote:
I agree with the changes.

Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-tram-stun-origin-00, the Security Considerations says:   

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, so the
   initial ORIGIN attribute will not have integrity protection and hence
   could be modified or removed from a STUN request without the server
   knowing.  Subsequent STUN requests containing the MESSAGE-INTEGRITY
   attribute will provide integrity protection for the contents of the
   ORIGIN attribute.  The strength of this protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Justin has proposed changing it to:

   The STUN MESSAGE-INTEGRITY attribute can provide integrity protection
   for all attributes present in a STUN request.  However, when using 
   STUN's long-term credential mechanism, as is done in TURN, MESSAGE-
   INTEGRITY is not present in the initial STUN message sent, and so the
   initial ORIGIN attribute will not have integrity protection. Hence,
   it could be modified or removed from a STUN request without the server
   knowing, which could affect the server's choice of REALM.
   
   With the long-term credential mechanism, subsequent STUN requests will     
   contain the MESSAGE-INTEGRITY attribute and will provide integrity protection 
   for the contents of the ORIGIN attribute(s).  To mitigate any potential concerns 
   arising from the unprotected attribute in the initial message, servers SHOULD 
   verify that the ORIGIN attribute(s) present in the authenticated STUN requests
   match those that were received in the initial, unauthenticated requests.

   The strength of the integrity protection is a function of
   the secret used to generate the MESSAGE-INTEGRITY value.

Anyone object to this clarification?  Any other suggested edits to the Security Considerations section?

- Alan -

_______________________________________________
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-ED6A3A08-35DE-4328-B822-FA70761D838B-- From nobody Sun Aug 17 22:48:29 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C0F1A02EC for ; Sun, 17 Aug 2014 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNWDwjFWxNmD for ; Sun, 17 Aug 2014 22:48:26 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC061A02F0 for ; Sun, 17 Aug 2014 22:48:22 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so5207949vcb.20 for ; Sun, 17 Aug 2014 22:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M9DWQG7GpqHG3nh+tYPIF8m2lYh+rpgDrSzqAsvdzBw=; b=jv5VrFNpRTV6BcTU9b+Uc6m6LryKh1kPExU0MNpJ9O5YxUr0inKWtsJwjLUmVQ/Ne5 VDWvxm5Gvxewm4jGQSSROYC7Fj/UT5BOB0G45V4t3NhaeciSAGAaUFhN5dSRq1HwqL+/ gaagaevMDQA395tMurbt5z6Vpctcu9tDjlZ6dD87J7pO+3MFCs57+dYPElJrnZ1KH7+z WaQ/wSt8BmgCaaRo9Tae5vtdixmkuvYCkcM4MXtD2CKCQz5XNL3pVJIZVM7ToDSPyKul nvUzN1uqaEz+gTsNtgifiV1B7wS3COjJB6V/PlT39mV8lFHxSE3GVnqArmofLhyAElrj Uz2A== 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-type; bh=M9DWQG7GpqHG3nh+tYPIF8m2lYh+rpgDrSzqAsvdzBw=; b=ILzXHeMvAJLMOLgCVqkRFIWoXa1O/J3KyDK1bQnftOIA9FU8I1m3eDMb/QfdxNNyO5 otETvVHE1BWcXlxnzNHzL0QhjFHGQsCTjbacDB3F0exuCcj+iOMlDpe3b8hx8KCYMTp1 /4wDQag3Te1Y6Jv4/PAgTyQsZHUsqkamyavAX4g0XrVCQNxRssLNhitPm50FAis0rNj/ M1zTCLMy5oSlGlHwOm7+WUs6BJkWwyWopNT1IMUqQIr0EfWh1K1d6cX1tkVI4o/6fR1r O4z2cJ4dD6jmHgTeCQ8G0ARLxfCfqgijmmqcpUDYbepIuPyynKD0uy/MsCyDnkyfz0uG 8HXA== X-Gm-Message-State: ALoCoQmlxLbHYRw+ZfDWkE5cNcOSK+fUplK+wqNrWhtmzw6FwNCb90fKISXpZkfIyPRupbB7PVv+ X-Received: by 10.221.44.69 with SMTP id uf5mr23555276vcb.4.1408340901362; Sun, 17 Aug 2014 22:48:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Sun, 17 Aug 2014 22:48:01 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Sun, 17 Aug 2014 22:48:01 -0700 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11339e88261c150500e0ebd2 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5pI_udrGzF8IRNLOgmZQoX_xzoA Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] STUN Origin Open Issue: Integrity Protection X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 05:48:28 -0000 --001a11339e88261c150500e0ebd2 Content-Type: text/plain; charset=UTF-8 I agree, this is the simplest advice. On Sun, Aug 17, 2014 at 3:40 PM, Oleg Moskalenko wrote: > Alan, I checked the new edition. The message-integrity wording is accurate > and it is similar to how i understand this issue. So i agree with the new > edition. > > Thanks! > Oleg > > Sent from my iPhone > > On Aug 17, 2014, at 11:42 AM, Alan Johnston > wrote: > > Justin, > > I now understand your issue. There is no real way for a client or server > to enforce that the ORIGIN attribute be the same across requests. The > existing text about MESSAGE-INTEGRITY isn't all that useful, either. > Instead, I suggest we include text saying that only DTLS or TLS transport > provides integrity protection in all cases for ORIGIN attributes. > > I'll send the suggested text in another list mail. > > - Alan - > > > > On Mon, Aug 11, 2014 at 11:53 AM, Justin Uberti > wrote: > >> As mentioned I think what you describe is hard to do when using stateless >> stack - see my email on Aug 1 for a suggestion on how to resolve this. >> >> >> On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston > > wrote: >> >>> Justin & Oleg, >>> >>> Thanks for the feedback. I will change the one requirement to a MUST: >>> >>> To mitigate any potential concerns arising from the unprotected >>> attribute in the initial message, servers MUST verify that the ORIGIN >>> attribute(s) present in the authenticated STUN requests match those that >>> were received in the initial, unauthenticated requests. >>> >>> Having running code is a good thing! >>> >>> - Alan - >>> >>> >>> On Fri, Aug 1, 2014 at 5:40 PM, Justin Uberti >>> wrote: >>> >>>> I realized when looking at a code review for this that the >>>> stateless-stack approach makes it difficult to enforce this as written. >>>> Instead, I think the advice should be that the ORIGIN attributes in the >>>> authenticated request MUST be verified to be consistent with the REALM >>>> value that is supplied. >>>> >>>> >>>> On Fri, Aug 1, 2014 at 8:42 AM, Oleg Moskalenko >>>> wrote: >>>> >>>>> I agree with the changes. >>>>> >>>>> Thanks >>>>> Oleg >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 8:07 AM, Alan Johnston < >>>>> alan.b.johnston@gmail.com> wrote: >>>>> >>>>>> In draft-ietf-tram-stun-origin-00, the Security Considerations says: >>>>>> >>>>>> >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity >>>>>> protection >>>>>> for all attributes present in a STUN request. However, MESSAGE- >>>>>> INTEGRITY is not present in the initial STUN message sent, so the >>>>>> initial ORIGIN attribute will not have integrity protection and >>>>>> hence >>>>>> could be modified or removed from a STUN request without the server >>>>>> knowing. Subsequent STUN requests containing the MESSAGE-INTEGRITY >>>>>> attribute will provide integrity protection for the contents of the >>>>>> ORIGIN attribute. The strength of this protection is a function of >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>> >>>>>> Justin has proposed changing it to: >>>>>> >>>>>> The STUN MESSAGE-INTEGRITY attribute can provide integrity >>>>>> protection >>>>>> for all attributes present in a STUN request. However, when using >>>>>> STUN's long-term credential mechanism, as is done in TURN, MESSAGE- >>>>>> INTEGRITY is not present in the initial STUN message sent, and so >>>>>> the >>>>>> initial ORIGIN attribute will not have integrity protection. Hence, >>>>>> it could be modified or removed from a STUN request without the >>>>>> server >>>>>> knowing, which could affect the server's choice of REALM. >>>>>> >>>>>> With the long-term credential mechanism, subsequent STUN requests >>>>>> will >>>>>> contain the MESSAGE-INTEGRITY attribute and will provide integrity >>>>>> protection >>>>>> for the contents of the ORIGIN attribute(s). To mitigate any >>>>>> potential concerns >>>>>> arising from the unprotected attribute in the initial message, >>>>>> servers SHOULD >>>>>> verify that the ORIGIN attribute(s) present in the authenticated >>>>>> STUN requests >>>>>> match those that were received in the initial, unauthenticated >>>>>> requests. >>>>>> >>>>>> The strength of the integrity protection is a function of >>>>>> the secret used to generate the MESSAGE-INTEGRITY value. >>>>>> >>>>>> Anyone object to this clarification? Any other suggested edits to >>>>>> the Security Considerations section? >>>>>> >>>>>> - Alan - >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>> >> > --001a11339e88261c150500e0ebd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree, this is the simplest advice.


On Sun, Aug 17, 2014 at 3:40= PM, Oleg Moskalenko <mom040267@gmail.com> wrote:
Alan, I checked the n= ew edition. The message-integrity wording is accurate and it is similar to = how i understand this issue. So i agree with the new edition.

Thanks!
Oleg

Sent from= my iPhone

On Aug 17, 2014, at 1= 1:42 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:

Justin,

<= /div>
I now understand your issue. =C2=A0There is no real way for a cli= ent or server to enforce that the ORIGIN attribute be the same across reque= sts. =C2=A0The existing text about MESSAGE-INTEGRITY isn't all that use= ful, either. =C2=A0Instead, =C2=A0I suggest we include text saying that onl= y DTLS or TLS transport provides integrity protection in all cases for ORIG= IN attributes. =C2=A0

I'll send the suggested text in another list mail.<= /div>

- Alan -



On Mon, Aug 11, 2014 at 11:53 AM, Justin Ube= rti <juberti@google.com> wrote:
As mentioned I think what you describe is hard to do when = using stateless stack - see my email on Aug 1 for a suggestion on how to re= solve this.


On Mon, Aug 11, 2014 at 9:22 AM, Alan Johnston <alan.b.johnston@gm= ail.com> wrote:
Justin & Oleg,

Thanks for the feedb= ack. =C2=A0I will change the one requirement to a MUST:

To mitigate any potential concerns arising from the unprotected = attribute in the initial message, servers MUST verify that the ORIGIN attri= bute(s) present in the authenticated STUN requests match those that were re= ceived in the initial, unauthenticated requests.

Having running code is a good thing!

- Alan -


On Fri, = Aug 1, 2014 at 5:40 PM, Justin Uberti <juberti@google.com> = wrote:
I realized when looking at a code review = for this that the stateless-stack approach makes it difficult to enforce th= is as written. Instead, I think the advice should be that the ORIGIN attrib= utes in the authenticated request MUST be verified to be consistent with th= e REALM value that is supplied.


On Fri, Aug 1= , 2014 at 8:42 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
I agree with the changes.
Thanks
Oleg


On Fri, Aug 1, 2014 at 8:07 AM= , Alan Johnston <alan.b.johnston@gmail.com> wrote:
In draft-ietf-= tram-stun-origin-00, the Security Considerations says: =C2=A0=C2=A0

=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can p= rovide integrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, MESSAGE-
=C2=A0 =C2=A0INTEGRITY is not present in the initial STUN message sent= , so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have inte= grity protection and hence
=C2=A0 =C2=A0could be modified or remo= ved from a STUN request without the server
=C2=A0 =C2=A0knowing. =C2=A0Subsequent STUN requests containing the ME= SSAGE-INTEGRITY
=C2=A0 =C2=A0attribute will provide integrity pro= tection for the contents of the
=C2=A0 =C2=A0ORIGIN attribute. = =C2=A0The strength of this protection is a function of
=C2=A0 =C2=A0the secret used to generate the MESSAGE-INTEGRITY value.<= /div>

Justin has proposed changing it to:

=
=C2=A0 =C2=A0The STUN MESSAGE-INTEGRITY attribute can provide in= tegrity protection
=C2=A0 =C2=A0for all attributes present in a STUN request. =C2=A0Howev= er, when using=C2=A0
=C2=A0 =C2=A0STUN's long-term credential= mechanism, as is done in TURN, MESSAGE-
=C2=A0 =C2=A0INTEGRITY i= s not present in the initial STUN message sent, and so the
=C2=A0 =C2=A0initial ORIGIN attribute will not have integrity protecti= on. Hence,
=C2=A0 =C2=A0it could be modified or removed from a ST= UN request without the server
=C2=A0 =C2=A0knowing, which could a= ffect the server's choice of REALM.
=C2=A0 =C2=A0
=C2=A0 =C2=A0With the long-term credential mec= hanism, subsequent STUN requests will =C2=A0 =C2=A0=C2=A0
=C2=A0 = =C2=A0contain the MESSAGE-INTEGRITY attribute and will provide integrity pr= otection=C2=A0
=C2=A0 =C2=A0for the contents of the ORIGIN attrib= ute(s). =C2=A0To mitigate any potential concerns=C2=A0
=C2=A0 =C2=A0arising from the unprotected attribute in the initial mes= sage, servers SHOULD=C2=A0
=C2=A0 =C2=A0verify that the ORIGIN at= tribute(s) present in the authenticated STUN requests
=C2=A0 =C2= =A0match those that were received in the initial, unauthenticated requests.=

=C2=A0 =C2=A0The strength of the integrity protection i= s a function of
=C2=A0 =C2=A0the secret used to generate the MESS= AGE-INTEGRITY value.

Anyone object to this clarifi= cation? =C2=A0Any other suggested edits to the Security Considerations sect= ion?

- Alan -

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



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






--001a11339e88261c150500e0ebd2-- From nobody Sun Aug 17 23:28:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF641A0300 for ; Sun, 17 Aug 2014 23:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hENZm9AD3Qzl for ; Sun, 17 Aug 2014 23:28:16 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444601A02F9 for ; Sun, 17 Aug 2014 23:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6072; q=dns/txt; s=iport; t=1408343296; x=1409552896; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=FkNBsFCY6jkL2J3wdz1AIU4GGpcU39pKKyoupV+floQ=; b=QuZLbIMSZEZdOTg59z7Nx6MzQsatOdZJEOzryG8YFnbRbBoNoUclDm4E TlbQvMuPK3inMXql/PrEb2B3PQXK1ZUV73kUP403LezcFX3/dmfuwowMf OBlhW1MT9nnN2d/1KMFjXeRNAI/kjhRHtaORg0dr53MFMBaIhYIDQL6zW U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFABCc8VOtJV2S/2dsb2JhbABZgw1TVwTMTwqHWAGBFhZ3hAMBAQEEAQEBGlEXBgEIEQQBAQEKHSgGCxQJCQEEARIIiCYDEQ27Xg2FMxMEjR+BfD6DKYEdBYUEAoVghj+EJoI5gi+QX4Yzg11sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,884,1400025600"; d="scan'208";a="70010594" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP; 18 Aug 2014 06:28:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7I6SFDu020984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 06:28:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 01:28:14 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] Call for adoption: draft-johnston-tram-turnbis-01 Thread-Index: Ac+6rZPKDQOO/KmeTUOPpy5PZdtY6A== Date: Mon, 18 Aug 2014 06:28:14 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28316D20@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.21] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vxkTWvaKw6n5s9DIVQwH8xwfISs Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 06:28:18 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Friday, August 15, 2014 8:32 PM > To: tram@ietf.org > Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 >=20 > +1 to WG >=20 > I think that both TURNbis and STUNbis should cover things that the WG > considers to be problems with the core protocols that apply broadly to > virtually any STUN/TURN deployment. For that reason ... >=20 > +1 to incorporating SSODA (I think IPv4/6 dual stack support should be > considered a core TURN requirement) >=20 > I'm uncertain what I think about the ORIGIN draft here. It mostly > applies to 3rd party TURN service deployments I think, so I agree with > not folding it into TURNbis. I'm just not sure whether an extension for > improved 3rd party support even needs to be referenced. Are we intending > to reference all such 3rd party support extensions? >=20 > To be clear, I don't object to it being referenced. I'm just not sure it > needs to be in order for TURNbis to be complete. we can consider adding a new section that discusses about third party=20 TURN servers. Cheers, -Tiru >=20 > --Brandon >=20 > On 08/14/2014 12:24 AM, Tirumaleswar Reddy (tireddy) wrote: > >> -----Original Message----- > >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Gonzalo > Salgueiro > >> (gsalguei) > >> Sent: Wednesday, August 13, 2014 8:29 PM > >> To: tram@ietf.org > >> Subject: Re: [tram] Call for adoption: draft-johnston-tram-turnbis-01 > >> > >> +1 to referencing ORIGIN. > >> > >> +1 to incorporating SSODA into TURNbis > >> > >> +1 to adoption of draft-johnston-tram-turnbis-01 as WG doc > > > > +1 to all above. > > > > -Tiru > > > >> > >> [so that's a +3 by my count] > >> > >> -G > >> > >> > >> On Aug 13, 2014, at 3:42 AM, Pal Martinsen (palmarti) > > >> wrote: > >> > >>> > >>> +1 to referencing ORIGIN. > >>> > >>> +1 to incorporating SSODA into TURNbis > >>> > >>> SSODA now have two implementations (Both OpenSource). Coturn > >>> (https://code.google.com/p/coturn/) and NATtools > >>> (https://github.com/cisco/NATTools) > >>> > >>> I think the SSODA draft is ready to be merged into TURNbis and contin= ue > >> the discussion there. There probably still issues to be discussed, but= better > to > >> have them in a WG document than an I-D? Or? > >>> > >>> .-. > >>> P=E5l-Erik > >>> > >>> > >>> On 12 Aug 2014, at 22:53, Justin Uberti wrote: > >>> > >>>> I agree that simply referencing ORIGIN makes more sense. Also agree > that > >> we should try to incorporate SSODA. > >>>> > >>>> On Tue, Aug 12, 2014 at 9:42 AM, Alan Johnston > >> wrote: > >>>> Hi Oleg, > >>>> > >>>> The ORIGIN attribute applies to both STUN and TURN, so if it were to= be > >> merged, it would be into STUN-bis. I'm not so sure about merging as t= he > >> ORIGIN draft is almost ready for last call. The ORIGIN RFC could be > >> normatively referenced by both STUN-bis and TURN-bis when they are > >> published next year, if needed. > >>>> > >>>> - Alan - > >>>> > >>>> > >>>> On Tue, Aug 12, 2014 at 11:25 AM, Oleg Moskalenko > >> wrote: > >>>> > >>>> > >>>> > >>>> On Tue, Aug 12, 2014 at 8:43 AM, Simon Perreault > > >> wrote: > >>>> With WG chair hat off, I will provide my own personal views... > >>>> > >>>> On Tue, Aug 12, 2014 at 11:33 AM, Simon Perreault > >> wrote: > >>>>> - What do we want to achieve with TURN-bis? That is, beyond the > >>>>> errata and tracker issues, when will we consider the draft to be > >>>>> "done" and ready to be sent to IESG? > >>>> > >>>> I think we need to merge TURN-IPv6 into the base spec. IPv4-only > >>>> protocols are a thing of the past. > >>>> > >>>> I don't think we need to merge TURN-TCP. The base spec could remain > >>>> compatible with the TURN-TCP RFC so that we don't need to update it > >>>> too. > >>>> > >>>> I think that it would make sense to merge the SSODA draft into the b= ase > >> spec. > >>>> > >>>> > >>>> I agree, and I'd merge the ORIGIN draft, too. That is a very importa= nt > >> change for a large enterprise. > >>>> > >>>> > >>>>> - Given what we want to achieve, is this draft a good start? "Good" > >>>>> meaning it is going in the right direction, not that it is close to > >>>>> the end goal. > >>>> > >>>> Since the draft is so close to the starting line, it's hard to go in > >>>> the wrong direction... > >>>> > >>>> 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 > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- > Brandon Williams; Senior Principal Software Engineer > Emerging Products Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Sun Aug 17 23:29:58 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DDE1A0300 for ; Sun, 17 Aug 2014 23:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqvam5gN6BMh for ; Sun, 17 Aug 2014 23:29:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737001A02F9 for ; Sun, 17 Aug 2014 23:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19034; q=dns/txt; s=iport; t=1408343395; x=1409552995; h=from:to:subject:date:message-id:mime-version; bh=A/xg8+xJX2PD33R2joRDceeel0sFoqukK+MEGnXJ6Z4=; b=R6H0U5UBAtALDAigfWkJRHrVKd1a9BHMmOzXemQAw+TSPhdEV081yYTJ 29WHAuPlgjiVb1MYxkS4uQ+Qo4EAjESiLTyAGdWJkPVrA0hxxsH0bOjm6 rpUSKQThKL8mNLTKSVlY7MGgfGA29L/hBAoSePuVmLFAU0Y8hSxWCwy2A U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFAF+c8VOtJA2G/2dsb2JhbABZgkdGU1cEgnjHf4Ffh1wBGX0Wd4QDAQEBBCMKXgEIEQQBAQsdAwIEMBQJCQEEARIIiDoNrC6UcBePGxYhB4JzNoEdBY5/giaEJoIpjH+GDRWGMIFjHoFcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,884,1400025600"; d="scan'208,217";a="345136119" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 18 Aug 2014 06:29:54 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7I6Tr7t002081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 06:29:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 01:29:53 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , "tram@ietf.org" Thread-Topic: [tram] STUN Origin Open Issue Resolution Proposal Thread-Index: Ac+6rc+F2fSekDpDT3uqBMhvB3WGfw== Date: Mon, 18 Aug 2014 06:29:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28316D39@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.21] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A28316D39xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oO-8-6S4ubNVZOv75viGazZXyC0 Subject: Re: [tram] STUN Origin Open Issue Resolution Proposal X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 06:29:56 -0000 --_000_913383AAA69FF945B8F946018B75898A28316D39xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VXBkYXRlZCB0ZXh0IGxvb2tzIGdvb2QuIENvbW1lbnQgb24gVURQIGZyYWdtZW50YXRpb24sIGlm IHRoaXMgcHJvYmxlbSBpcyByZXN0cmljdGluZyB2YXJpb3VzIFRVUk4gZHJhZnRzIHRoZW4gd2h5 IG5vdCBjb25zaWRlciBlbmhhbmNpbmcgVFVSTiB0byBoYW5kbGUgZnJhZ21lbnRhdGlvbiAoc2lt aWxhciB0byB0aGUgd2F5IGl04oCZcyBkb25lIGluIEVBUC1UTFMsIERUTFMgaGFuZHNoYWtlIGV0 Yy4pLg0KDQotVGlydQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQWxhbiBKb2huc3Rvbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIw MTQgMTI6MTUgQU0NClRvOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBbdHJhbV0gU1RVTiBPcmln aW4gT3BlbiBJc3N1ZSBSZXNvbHV0aW9uIFByb3Bvc2FsDQoNCkJhc2VkIG9uIHRoZSBkaXNjdXNz aW9uIG9uIHRoZSB0d28gT3BlbiBJc3N1ZXMgKEludGVncml0eSBQcm90ZWN0aW9uIGFuZCBTaXpl IG9mIEF0dHJpYnV0ZSkgZGlzY3Vzc2VkIG9uIHRoaXMgbGlzdCwgYW5kIHRoZSBYTVBQIE9yaWdp biBpc3N1ZSBkaXNjdXNzZWQgb24gdGhlIFhNUFAgbGlzdCAodGhhbmtzIHRvIFBldGVyIFNhaW50 LUFuZHJlIGZvciBoaXMgdGV4dCksIGhlcmUgaXMgbXkgcHJvcG9zZWQgY2hhbmdlcyB0byB0aGUg ZHJhZnQuDQoNCkxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMgbmV3 IHRleHQuICBJIHBsYW4gdG8gcmV2aXNlIHRoZSBkcmFmdCBpbiB0aGUgbmV4dCBmZXcgZGF5cyB3 aXRoIHRoZXNlIGNoYW5nZXMuDQoNCi0gQWxhbiAtDQoNClByb3Bvc2VkIGNoYW5nZXMgdG8gZHJh ZnQtaWV0Zi10cmFtLXN0dW4tb3JpZ2luLTAwOg0KDQpPTEQ6DQoNCkZvciBhIEphYmJlciBjbGll bnQgW1JGQzYxMjBdIHVzaW5nIFNUVU4gYW5kIFRVUk4sIHRoZSBPUklHSU4gYXR0cmlidXRlIGlz IHRoZSBKYWJiZXIgSUQgKEpJRCkgW1JGQzYxMjJdIG9mIHRoZSBKYWJiZXIgU2VydmVyIHRoYXQg dGhlIGNsaWVudCBpcyB1c2luZy4NCg0KTkVXOg0KDQogICBGb3IgYW4gWE1QUCBjbGllbnQgW1JG QzYxMjBdIHVzaW5nIFNUVU4gYW5kIFRVUk4sIHRoZSBPUklHSU4NCiAgIGF0dHJpYnV0ZSBpcyBh biBYTVBQIFVSSSBbUkZDNTEyMl0gcmVwcmVzZW50aW5nIHRoZSBkb21haW5wYXJ0DQogICBvZiB0 aGUgY2xpZW50J3MgSmFiYmVyIElEIChKSUQpIFtSRkM2MTIyXTsgZm9yIGV4YW1wbGUsIGlmIHRo ZQ0KICAgY2xpZW50J3MgSklEIGlzICJqdWxpZXRAaW0uZXhhbXBsZS5jb20vYmFsY29ueTxodHRw Oi8vanVsaWV0QGltLmV4YW1wbGUuY29tL2JhbGNvbnk+IiB0aGVuIHRoZSBPUklHSU4NCiAgIGF0 dHJpYnV0ZSB3b3VsZCBiZSAieG1wcDppbS5leGFtcGxlLmNvbTxodHRwOi8vaW0uZXhhbXBsZS5j b20vPiIuDQoNCg0KQWRkIHRvIFRVUk4gVXNhZ2Ugc2VjdGlvbjoNCg0KICAgSW5jbHVkaW5nIHRo ZSBPUklHSU4gYXR0cmlidXRlIGluIHRoZSBTZW5kIG1ldGhvZCBpcyBOT1QgUkVDT01NRU5ERUQu DQoNCk9MRDoNCg0KICAgSXQgTVVTVCBjb250YWluIGENCiAgIFVURi04IFtSRkMzNjI5XSBlbmNv ZGVkIHNlcXVlbmNlIG9mIGNoYXJhY3RlcnMgbGVzcyB0aGFuIDI2OCBieXRlcy4NCiAgIFRoZSB2 YWx1ZSBvZiAyNjggaXMgY2hvc2VuIHRvIGJlIGxhcmdlciB0aGFuIHRoZSBtYXhpbXVtIDI1Mw0K ICAgY2hhcmFjdGVyIGRvbWFpbiBuYW1lIHBsdXMgOCBjaGFyYWN0ZXJzIGZvciB0aGUgVVJJIHNj aGVtZSBwbHVzIDUNCiAgIGNoYXJhY3RlcnMgZm9yIHRoZSBwb3J0IG51bWJlci4gIFNlbmRlcnMg TUFZIGluY2x1ZGUgbXVsdGlwbGUgT1JJR0lODQogICBhdHRyaWJ1dGVzIGluIGEgcmVxdWVzdCwg YW5kIHJlY2VpdmVycyBNVVNUIHN1cHBvcnQgcGFyc2luZyBhbmQNCiAgIHJlY2VpdmluZyBtdWx0 aXBsZSBPUklHSU4gYXR0cmlidXRlcy4NCg0KTkVXOg0KDQpJdCBNVVNUIGNvbnRhaW4gYSBVVEYt OCBbUkZDMzYyOV0gZW5jb2RlZCBzZXF1ZW5jZSBvZiBjaGFyYWN0ZXJzLiAgU2VuZGVycyBNQVkg aW5jbHVkZSBtdWx0aXBsZSBPUklHSU4gYXR0cmlidXRlcyBpbiBhIHJlcXVlc3QsIGFuZCByZWNl aXZlcnMgTVVTVCBzdXBwb3J0IHBhcnNpbmcgYW5kIHJlY2VpdmluZyBtdWx0aXBsZSBPUklHSU4g YXR0cmlidXRlcy4gIFRoZSBzaXplIGFuZCBudW1iZXIgb2YgT1JJR0lOcyBpbmNsdWRlZCBpbiBh IFNUVU4gbWVzc2FnZSBjYW4gaGF2ZSBhIG1ham9yIGltcGFjdCBvbiB0aGUgc2l6ZSBvZiBhIFNU VU4gcGFja2V0LCBhbmQgY291bGQgcG90ZW50aWFsbHkgY2F1c2UgVURQIGZyYWdtZW50YXRpb24u ICBIVFRQIG9yaWdpbnMgYXJlIGxlc3MgdGhhbiAyNjcgY2hhcmFjdGVycyAodGhlIG1heGltdW0g MjUzIGNoYXJhY3RlciBkb21haW4gbmFtZSBwbHVzIDggY2hhcmFjdGVycyBmb3IgdGhlIFVSSSBz Y2hlbWUgcGx1cyA1IGNoYXJhY3RlcnMgZm9yIHRoZSBwb3J0IG51bWJlcikuICBJdCBpcyBOT1Qg UkVDT01NRU5ERUQgdGhhdCBhbiBPUklHSU4gYXR0cmlidXRlIGJlIGluY2x1ZGVkIGlmIHRoZSB0 b3RhbCBzaXplIChpbmNsdWRpbmcgdHlwZSwgbGVuZ3RoLCBhbmQgcGFkZGluZykgaXMgbGFyZ2Vy IHRoYW4gMjcyIG9jdGV0cy4gIE11bHRpcGxlIE9SSUdJTiBhdHRyaWJ1dGVzIFNIT1VMRCBOT1Qg YmUgaW5jbHVkZWQgaWYgdGhlIHRvdGFsIHNpemUgb2YgdGhlc2UgYXR0cmlidXRlcyBleGNlZWRz IDI3MiBvY3RldHMuDQoNCk9MRDoNCg0KVGhlIFNUVU4gTUVTU0FHRS1JTlRFR1JJVFkgYXR0cmli dXRlIGNhbiBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uIGZvciBhbGwgYXR0cmlidXRlcyBw cmVzZW50IGluIGEgU1RVTiByZXF1ZXN0LiAgSG93ZXZlciwgTUVTU0FHRS1JTlRFR1JJVFkgaXMg bm90IHByZXNlbnQgaW4gdGhlIGluaXRpYWwgU1RVTiBtZXNzYWdlIHNlbnQsIHNvIHRoZSBpbml0 aWFsIE9SSUdJTiBhdHRyaWJ1dGUgd2lsbCBub3QgaGF2ZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBh bmQgaGVuY2UgY291bGQgYmUgbW9kaWZpZWQgb3IgcmVtb3ZlZCBmcm9tIGEgU1RVTiByZXF1ZXN0 IHdpdGhvdXQgdGhlIHNlcnZlciBrbm93aW5nLiAgU3Vic2VxdWVudCBTVFVOIHJlcXVlc3RzIGNv bnRhaW5pbmcgdGhlIE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZSB3aWxsIHByb3ZpZGUgaW50 ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBjb250ZW50cyBvZiB0aGUgT1JJR0lOIGF0dHJpYnV0 ZS4gIFRoZSBzdHJlbmd0aCBvZiB0aGlzIHByb3RlY3Rpb24gaXMgYSBmdW5jdGlvbiBvZiB0aGUg c2VjcmV0IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIE1FU1NBR0UtSU5URUdSSVRZIHZhbHVlLg0KDQpO RVc6DQoNCldoaWxlIHRoZSBTVFVOIE1FU1NBR0UtSU5URUdSSVRZIGF0dHJpYnV0ZSBjYW4gcHJv dmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgYWxsIGF0dHJpYnV0ZXMgcHJlc2VudCBpbiBh IFNUVU4gcmVxdWVzdCwgTUVTU0FHRS1JTlRFR1JJVFkgaXMgbm90IHByZXNlbnQgaW4gdGhlIGlu aXRpYWwgU1RVTiBtZXNzYWdlIHNlbnQuIEFzIGEgcmVzdWx0LCBhbiBPUklHSU4gYXR0cmlidXRl IGNvdWxkIGJlIG1vZGlmaWVkIG9yIHJlbW92ZWQgZnJvbSBhIFNUVU4gcmVxdWVzdCB3aXRob3V0 IHRoZSBzZXJ2ZXIga25vd2luZy4gRFRMUyBvciBUTFMgdHJhbnNwb3J0IFNIT1VMRCBiZSB1c2Vk IHdoZW4gaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZSBPUklHSU4gYXR0cmlidXRlIGlzIGlt cG9ydGFudC4NCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A28316D39xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5VcGRhdGVkIHRleHQgbG9va3MgZ29vZC4gQ29tbWVudCBvbiBVRFAgZnJhZ21lbnRhdGlv biwgaWYgdGhpcyBwcm9ibGVtIGlzIHJlc3RyaWN0aW5nIHZhcmlvdXMgVFVSTiBkcmFmdHMgdGhl biB3aHkgbm90IGNvbnNpZGVyIGVuaGFuY2luZyBUVVJOIHRvIGhhbmRsZSBmcmFnbWVudGF0aW9u DQogKHNpbWlsYXIgdG8gdGhlIHdheSBpdOKAmXMgZG9uZSBpbiBFQVAtVExTLCBEVExTIGhhbmRz aGFrZSBldGMuKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkFsYW4gSm9obnN0b248YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBB dWd1c3QgMTgsIDIwMTQgMTI6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW3RyYW1dIFNUVU4gT3JpZ2luIE9wZW4gSXNzdWUgUmVzb2x1dGlv biBQcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgdHdvIE9wZW4gSXNzdWVzIChJ bnRlZ3JpdHkgUHJvdGVjdGlvbiBhbmQgU2l6ZSBvZiBBdHRyaWJ1dGUpIGRpc2N1c3NlZCBvbiB0 aGlzIGxpc3QsIGFuZCB0aGUgWE1QUCBPcmlnaW4gaXNzdWUgZGlzY3Vzc2VkIG9uIHRoZSBYTVBQ IGxpc3QgKHRoYW5rcyB0byZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlBldGVyDQog U2FpbnQtQW5kcmUmbmJzcDs8L3NwYW4+Zm9yIGhpcyB0ZXh0KSwgaGVyZSBpcyBteSBwcm9wb3Nl ZCBjaGFuZ2VzIHRvIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkxldCBtZSBrbm93IGlmIHlvdSBoYXZlIGNvbmNlcm5zIGFib3V0IHRoaXMg bmV3IHRleHQuICZuYnNwO0kgcGxhbiB0byByZXZpc2UgdGhlIGRyYWZ0IGluIHRoZSBuZXh0IGZl dyBkYXlzIHdpdGggdGhlc2UgY2hhbmdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBBbGFuIC08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJvcG9zZWQgY2hhbmdlcyB0byBkcmFmdC1p ZXRmLXRyYW0tc3R1bi1vcmlnaW4tMDA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9MRDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGEgSmFiYmVyIGNsaWVudCBbUkZDNjEyMF0gdXNp bmcgU1RVTiBhbmQgVFVSTiwgdGhlIE9SSUdJTiBhdHRyaWJ1dGUgaXMgdGhlIEphYmJlciBJRCAo SklEKSBbUkZDNjEyMl0gb2YgdGhlIEphYmJlciBTZXJ2ZXIgdGhhdCB0aGUgY2xpZW50IGlzIHVz aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ORVc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAmbmJzcDtGb3IgYW4mbmJzcDs8 c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5YTVBQPC9zcGFuPiZuYnNwO2NsaWVudCBb UkZDNjEyMF0gdXNpbmcgU1RVTiBhbmQgVFVSTiwgdGhlIE9SSUdJTjxicj4NCiZuYnNwOyAmbmJz cDthdHRyaWJ1dGUgaXMgYW4mbmJzcDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkNDIj5Y TVBQPC9zcGFuPiZuYnNwO1VSSSBbUkZDNTEyMl0gcmVwcmVzZW50aW5nIHRoZSBkb21haW5wYXJ0 PGJyPg0KJm5ic3A7ICZuYnNwO29mIHRoZSBjbGllbnQncyBKYWJiZXIgSUQgKEpJRCkgW1JGQzYx MjJdOyBmb3IgZXhhbXBsZSwgaWYgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO2NsaWVudCdzIEpJRCBp cyAmcXVvdDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL2p1bGlldEBpbS5leGFtcGxlLmNvbS9iYWxj b255IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+anVsaWV0QGlt LmV4YW1wbGUuY29tL2JhbGNvbnk8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZxdW90Ow0KIHRoZW4gdGhlIE9SSUdJTjxicj4NCiZuYnNwOyAmbmJzcDthdHRyaWJ1dGUgd291 bGQgYmUgJnF1b3Q7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZDQyI+eG1wcDwvc3Bhbj46 PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9pbS5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5pbS5leGFtcGxlLmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWRkIHRvIFRVUk4gVXNh Z2Ugc2VjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwO0luY2x1ZGluZyB0aGUgT1JJR0lOIGF0dHJpYnV0ZSBpbiB0 aGUgU2VuZCBtZXRob2QgaXMgTk9UIFJFQ09NTUVOREVELjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQ6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtJdCBNVVNUIGNv bnRhaW4gYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO1VURi04IFtSRkMzNjI5XSBlbmNvZGVkIHNlcXVlbmNlIG9mIGNoYXJh Y3RlcnMgbGVzcyB0aGFuIDI2OCBieXRlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtUaGUgdmFsdWUgb2YgMjY4IGlzIGNo b3NlbiB0byBiZSBsYXJnZXIgdGhhbiB0aGUgbWF4aW11bSAyNTM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtjaGFyYWN0ZXIg ZG9tYWluIG5hbWUgcGx1cyA4IGNoYXJhY3RlcnMgZm9yIHRoZSBVUkkgc2NoZW1lIHBsdXMgNTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO2NoYXJhY3RlcnMgZm9yIHRoZSBwb3J0IG51bWJlci4gJm5ic3A7U2VuZGVycyBNQVkg aW5jbHVkZSBtdWx0aXBsZSBPUklHSU48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDthdHRyaWJ1dGVzIGluIGEgcmVxdWVzdCwg YW5kIHJlY2VpdmVycyBNVVNUIHN1cHBvcnQgcGFyc2luZyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtyZWNlaXZpbmcg bXVsdGlwbGUgT1JJR0lOIGF0dHJpYnV0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgTVVTVCBjb250YWluIGEgVVRGLTggW1JGQzM2 MjldIGVuY29kZWQgc2VxdWVuY2Ugb2YgY2hhcmFjdGVycy4gJm5ic3A7U2VuZGVycyBNQVkgaW5j bHVkZSBtdWx0aXBsZSBPUklHSU4gYXR0cmlidXRlcyBpbiBhIHJlcXVlc3QsIGFuZCByZWNlaXZl cnMgTVVTVCBzdXBwb3J0IHBhcnNpbmcgYW5kIHJlY2VpdmluZyBtdWx0aXBsZSBPUklHSU4gYXR0 cmlidXRlcy4gJm5ic3A7VGhlIHNpemUgYW5kIG51bWJlciBvZiBPUklHSU5zDQogaW5jbHVkZWQg aW4gYSBTVFVOIG1lc3NhZ2UgY2FuIGhhdmUgYSBtYWpvciBpbXBhY3Qgb24gdGhlIHNpemUgb2Yg YSBTVFVOIHBhY2tldCwgYW5kIGNvdWxkIHBvdGVudGlhbGx5IGNhdXNlIFVEUCBmcmFnbWVudGF0 aW9uLiAmbmJzcDtIVFRQIG9yaWdpbnMgYXJlIGxlc3MgdGhhbiAyNjcgY2hhcmFjdGVycyAodGhl IG1heGltdW0gMjUzIGNoYXJhY3RlciBkb21haW4gbmFtZSBwbHVzIDggY2hhcmFjdGVycyBmb3Ig dGhlIFVSSSBzY2hlbWUgcGx1cyA1IGNoYXJhY3RlcnMNCiBmb3IgdGhlIHBvcnQgbnVtYmVyKS4g Jm5ic3A7SXQgaXMgTk9UIFJFQ09NTUVOREVEIHRoYXQgYW4gT1JJR0lOIGF0dHJpYnV0ZSBiZSBp bmNsdWRlZCBpZiB0aGUgdG90YWwgc2l6ZSAoaW5jbHVkaW5nIHR5cGUsIGxlbmd0aCwgYW5kIHBh ZGRpbmcpIGlzIGxhcmdlciB0aGFuIDI3MiBvY3RldHMuICZuYnNwO011bHRpcGxlIE9SSUdJTiBh dHRyaWJ1dGVzIFNIT1VMRCBOT1QgYmUgaW5jbHVkZWQgaWYgdGhlIHRvdGFsIHNpemUgb2YgdGhl c2UgYXR0cmlidXRlcyBleGNlZWRzDQogMjcyIG9jdGV0cy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0xEOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgU1RVTiBNRVNTQUdF LUlOVEVHUklUWSBhdHRyaWJ1dGUgY2FuIHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9y IGFsbCBhdHRyaWJ1dGVzIHByZXNlbnQgaW4gYSBTVFVOIHJlcXVlc3QuICZuYnNwO0hvd2V2ZXIs IE1FU1NBR0UtSU5URUdSSVRZIGlzIG5vdCBwcmVzZW50IGluIHRoZSBpbml0aWFsIFNUVU4gbWVz c2FnZSBzZW50LCBzbyB0aGUgaW5pdGlhbCBPUklHSU4gYXR0cmlidXRlIHdpbGwgbm90IGhhdmUN CiBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhbmQgaGVuY2UgY291bGQgYmUgbW9kaWZpZWQgb3IgcmVt b3ZlZCBmcm9tIGEgU1RVTiByZXF1ZXN0IHdpdGhvdXQgdGhlIHNlcnZlciBrbm93aW5nLiAmbmJz cDtTdWJzZXF1ZW50IFNUVU4gcmVxdWVzdHMgY29udGFpbmluZyB0aGUgTUVTU0FHRS1JTlRFR1JJ VFkgYXR0cmlidXRlIHdpbGwgcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBmb3IgdGhlIGNv bnRlbnRzIG9mIHRoZSBPUklHSU4gYXR0cmlidXRlLiAmbmJzcDtUaGUNCiBzdHJlbmd0aCBvZiB0 aGlzIHByb3RlY3Rpb24gaXMgYSBmdW5jdGlvbiBvZiB0aGUgc2VjcmV0IHVzZWQgdG8gZ2VuZXJh dGUgdGhlIE1FU1NBR0UtSU5URUdSSVRZIHZhbHVlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ORVc6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoZSBTVFVOIE1FU1NB R0UtSU5URUdSSVRZIGF0dHJpYnV0ZSBjYW4gcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBm b3IgYWxsIGF0dHJpYnV0ZXMgcHJlc2VudCBpbiBhIFNUVU4gcmVxdWVzdCwgTUVTU0FHRS1JTlRF R1JJVFkgaXMgbm90IHByZXNlbnQgaW4gdGhlIGluaXRpYWwgU1RVTiBtZXNzYWdlIHNlbnQuIEFz IGEgcmVzdWx0LCBhbiBPUklHSU4gYXR0cmlidXRlIGNvdWxkIGJlIG1vZGlmaWVkDQogb3IgcmVt b3ZlZCBmcm9tIGEgU1RVTiByZXF1ZXN0IHdpdGhvdXQgdGhlIHNlcnZlciBrbm93aW5nLiBEVExT IG9yIFRMUyB0cmFuc3BvcnQgU0hPVUxEIGJlIHVzZWQgd2hlbiBpbnRlZ3JpdHkgcHJvdGVjdGlv biBmb3IgdGhlIE9SSUdJTiBhdHRyaWJ1dGUgaXMgaW1wb3J0YW50LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A28316D39xmbrcdx10ciscoc_-- From nobody Mon Aug 18 05:19:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108631A005F for ; Mon, 18 Aug 2014 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX17eh-ypiAh for ; Mon, 18 Aug 2014 05:19:31 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322DF1A0081 for ; Mon, 18 Aug 2014 05:19:31 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so4845902wes.24 for ; Mon, 18 Aug 2014 05:19:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ZlOuBAgWoUtY3PqfzBLs0lJh75VeXNWn744cKKMuaY0=; b=Ze8059C66/Mj3qgeon8wTx9pxxu6mRqN9qOjcBnldMngip98Ah91Sqvvk89fY+T7Ce MWhFlfRe3i1K3PgOnZG1pwSjnIAAFw6X6ddEMGnd/B0eKA3ovatDvcFa1EHnzZIxukAh F1483mTYNlbziTB6ZxyfspOhrSzJzYPcTyE59V5Mo0I2HViN+F3BwGzoFNKB9Idye57H +gsvmlEedy7pGwL1ow3RXf40pbLNK0Lkr6tIgJ81fJKhpRvQQK+E3eugXaFbOQNlMUC0 W0mzBOm1YsB9Om6bTU7h8Izh0O18CEDJbkoxOKzJybk+YQnq2TDk9q8t833zNgakBvt9 lX/Q== X-Gm-Message-State: ALoCoQnlrOB+92TVzx4/dJn6KFuMA3fGy3aa/uLpli35jnGluLcDT92X1jM1Ppv+xdwu/51MZZ7d MIME-Version: 1.0 X-Received: by 10.180.188.203 with SMTP id gc11mr73275562wic.59.1408364369788; Mon, 18 Aug 2014 05:19:29 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Mon, 18 Aug 2014 05:19:29 -0700 (PDT) Date: Mon, 18 Aug 2014 08:19:29 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ohfrrOtI9cS_aGAXmSZToznfMQU Cc: Alan Johnston , "tram@ietf.org" Subject: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 12:19:33 -0000 On Mon, Aug 18, 2014 at 2:29 AM, Tirumaleswar Reddy (tireddy) wrote: > Comment on UDP fragmentation, if this problem is restricting various TURN > drafts then why not consider enhancing TURN to handle fragmentation (simi= lar > to the way it=E2=80=99s done in EAP-TLS, DTLS handshake etc.). TURN already has the DONT-FRAGMENT attribute which lets the client perform packetization-layer PMTUD. Although the text could be improved. So the client and server need to use a path MTU discovery algorithm that does not require ICMP messages. The Packetized Path MTU Discovery algorithm defined in [RFC4821] is one such algorithm. The details of how to use the algorithm of [RFC4821] with TURN are still under investigation. However, as a step towards this goal, this version of TURN supports a DONT-FRAGMENT attribute. When the client includes this attribute in a Send indication, this tells the server to set the DF bit in the resulting UDP datagram that it sends to the peer. Since some servers may be unable to set the DF bit, the client should also include this attribute in the Allocate request -- any server that does not support the DONT-FRAGMENT attribute will indicate this by rejecting the Allocate request. Are you proposing something different? Simon From nobody Mon Aug 18 06:40:32 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA9E1A0377 for ; Mon, 18 Aug 2014 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yt_9lqYSo_OS for ; Mon, 18 Aug 2014 06:40:30 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 21FAF1A0351 for ; Mon, 18 Aug 2014 06:40:29 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6AEE147522; Mon, 18 Aug 2014 13:40:29 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 38DCB4751A; Mon, 18 Aug 2014 13:40:29 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 2BC348004A; Mon, 18 Aug 2014 13:40:29 +0000 (GMT) Message-ID: <53F2024D.5030907@akamai.com> Date: Mon, 18 Aug 2014 09:40:29 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Simon Perreault , "Tirumaleswar Reddy (tireddy)" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4Oa8j8Kg6p__BD3p4P5PGCuIXyY Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 13:40:31 -0000 There's is also some text in STUN related fragmentation and maximum message sizes. Some previous discussion on the list suggested that the STUN text might be overly restrictive about message sizes (i.e. must be no larger the min MTU if path MTU is not known) and when it's OK to ignore the max message size guidance (i.e. only when doing something like PPMTUD). It may be appropriate for either STUNbis or TURNbis to address this. --Brandon On 08/18/2014 08:19 AM, Simon Perreault wrote: > On Mon, Aug 18, 2014 at 2:29 AM, Tirumaleswar Reddy (tireddy) > wrote: >> Comment on UDP fragmentation, if this problem is restricting various TURN >> drafts then why not consider enhancing TURN to handle fragmentation (similar >> to the way it’s done in EAP-TLS, DTLS handshake etc.). > > TURN already has the DONT-FRAGMENT attribute which lets the client > perform packetization-layer PMTUD. Although the text could be > improved. > > So the client and server need to use a path MTU discovery algorithm > that does not require ICMP messages. The Packetized Path MTU > Discovery algorithm defined in [RFC4821] is one such algorithm. > > The details of how to use the algorithm of [RFC4821] with TURN are > still under investigation. However, as a step towards this goal, > this version of TURN supports a DONT-FRAGMENT attribute. When the > client includes this attribute in a Send indication, this tells the > server to set the DF bit in the resulting UDP datagram that it sends > to the peer. Since some servers may be unable to set the DF bit, the > client should also include this attribute in the Allocate request -- > any server that does not support the DONT-FRAGMENT attribute will > indicate this by rejecting the Allocate request. > > Are you proposing something different? > > Simon > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 18 06:50:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C471A0390 for ; Mon, 18 Aug 2014 06:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4hwUEGr5OJ1 for ; Mon, 18 Aug 2014 06:50:38 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535641A0382 for ; Mon, 18 Aug 2014 06:50:38 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so4885179wgh.21 for ; Mon, 18 Aug 2014 06:50:37 -0700 (PDT) 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:content-type; bh=WslrF+dS3rIdnvfNZeCX03rrH3P7zo6IXLdYMyBVuT0=; b=hqZZbNQv+M2yJoms3l4mYvFHV+i4v1Fd1w3+duguxWVEb5tQAky7I7rsGYkySkLiNF a5JXlwY2vaheABDigQ+Vxvx9w6nyjwIbPJUx0bgES7cIkBy/2ngAxMJrcVUJ7WKOi6DT E2uPZWUIh3kXiOijiAgGfTZf1VO0qtJqrKUbJrSXDIc6KFkMiUVvfqUyyHoD81r1Ume8 bBLiu910Gau+s9zCmFhkSpe6att1WRepEGh1J8j5LQUcQwFrWzaiYgiA7rlQioxCUt+9 glqBPDuNnHndSdUOrZ6KrFJS9hgmI4hRGZX0WEgXZPHV1ECvtdKHrTZhFF5vjpSa5CCN trRw== X-Gm-Message-State: ALoCoQnTOctR2khZDCkUAFH00SK+D3d2JsaSlfNqYJTz7au916/LHWpXaVLaZ0CxQa0gTcIA6stI MIME-Version: 1.0 X-Received: by 10.194.71.210 with SMTP id x18mr7397064wju.6.1408369836906; Mon, 18 Aug 2014 06:50:36 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Mon, 18 Aug 2014 06:50:36 -0700 (PDT) In-Reply-To: <53F2024D.5030907@akamai.com> References: <53F2024D.5030907@akamai.com> Date: Mon, 18 Aug 2014 09:50:36 -0400 Message-ID: From: Simon Perreault To: Brandon Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gRfAm5ttoef34HDESmxtyAI8nlQ Cc: Alan Johnston , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 13:50:44 -0000 On Mon, Aug 18, 2014 at 9:40 AM, Brandon Williams wrote: > There's is also some text in STUN related fragmentation and maximum message > sizes. Right. There are two kinds of fragmentation that are at play here. We need to be precise in the words we use. I don't think that there are established terms, so let's invent them: - "STUN fragmentation" happens between the client and the server. - "TURN fragmentation" happens between the server and the peer. I was referring to TURN fragmentation, and you were referring to STUN fragmentation. Still not sure what Tiru was referring to. Simon From nobody Mon Aug 18 07:48:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451241A048F for ; Mon, 18 Aug 2014 07:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pphBbh8tuc8H for ; Mon, 18 Aug 2014 07:48:06 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12BB1A048A for ; Mon, 18 Aug 2014 07:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1408; q=dns/txt; s=iport; t=1408373287; x=1409582887; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=05evxxV3S31YUdp0gjFBXXPhFcRVmqFu+d7v9/nSezA=; b=QCPA5qbhmGMOCpyQ7uCWICmP5GLfl2/+MA5W5zWlml/ARQv3KjaR2/qN rBOm+1iMQznyUGAIbzaYW8naWHRXw6j1nlroTpGSR9tfUOcENTX8B13U5 X9k+bqzM6aZSrI5P0vQb5ZO0xfOMfOvEPl7s3UgXZmcgr88FLMwoc0Caf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAAIR8lOtJA2N/2dsb2JhbABZgw1TVwTMbAyHVgGBHRZ3hAQBAQQBAQFrCxACAQgOCi4nCyUCBAENBYhCDcB8F49MB4RMAQSRJYQmhneBV5Msg11sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,886,1400025600"; d="scan'208";a="348354805" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 18 Aug 2014 14:48:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7IEm5Fx013611 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 14:48:06 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 09:48:05 -0500 From: "Prashanth Patil (praspati)" To: Simon Perreault , Brandon Williams Thread-Topic: [tram] TURN and fragmentation Thread-Index: AQHPuvNqSmQy6pY6aUi9wv3iZtS59g== Date: Mon, 18 Aug 2014 14:48:05 +0000 Message-ID: References: <53F2024D.5030907@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.61.27] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gpqJN0tFYEuxb6DrANq37mF-EU8 Cc: Alan Johnston , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:48:08 -0000 I think Tiru is referring to fragmentation between the Turn Client and Turn Server. This leads to restrictions in the size of STUN messages. In context of the ORIGIN draft, this restricts the size/number of ORIGIN attributes.=20 Ability to handle fragments could be useful =8B to accommodate multiple ORIGIN attributes and if we ever want to incorporate other parameters in the authorization token (http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-01#secti on-6.2), thus increasing message size. -Prashanth On 8/18/14 7:20 PM, "Simon Perreault" wrote: >On Mon, Aug 18, 2014 at 9:40 AM, Brandon Williams > wrote: >> There's is also some text in STUN related fragmentation and maximum >>message >> sizes. > >Right. > >There are two kinds of fragmentation that are at play here. We need to >be precise in the words we use. I don't think that there are >established terms, so let's invent them: > >- "STUN fragmentation" happens between the client and the server. >- "TURN fragmentation" happens between the server and the peer. > >I was referring to TURN fragmentation, and you were referring to STUN >fragmentation. Still not sure what Tiru was referring to. > >Simon > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Aug 18 08:27:39 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790DA1A0639 for ; Mon, 18 Aug 2014 08:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaFB9USxY7Z7 for ; Mon, 18 Aug 2014 08:27:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD101A063D for ; Mon, 18 Aug 2014 08:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1820; q=dns/txt; s=iport; t=1408375635; x=1409585235; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MvDlpIsrKIwT3riPQ4h/8sJ0Z2ge1kUMo6zYBSifIhM=; b=MelrtbJ3CvoRFJvemaJisJ7OxJZSPnLSJHkJJ6LVx24Qd6nz6PXQ3/9I DC4VSa5yfgJj8niiV6Z7pw6W5w/2x1Ona9GfBiPQa9TSE6D5wuBcvp4IK pD/dTg4UnSuaAZcfRfOHfSRSgZE9inlnV1+0nhDshDShp0DBw5X4nT42P I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFACca8lOtJV2T/2dsb2JhbABZgw1TVwTMbAyHVgGBHRZ3hAMBAQEEAQEBNzQLDAQCAQgRBAEBAQoUECcLHQgCBAENBQiIOg3BBhePGzEHBoMpgR0FkSWEJohOkyyDXWyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.01,886,1400025600"; d="scan'208";a="70188800" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 18 Aug 2014 15:27:14 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7IFREkG023597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 15:27:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 10:27:14 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Prashanth Patil (praspati)" , Simon Perreault , Brandon Williams Thread-Topic: [tram] TURN and fragmentation Thread-Index: AQHPut6s+iF/dqna80qUkLhBBQDmc5vWsgaAgAAC1ACAABAQgP//tsPA Date: Mon, 18 Aug 2014 15:27:13 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28317096@xmb-rcd-x10.cisco.com> References: <53F2024D.5030907@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tgySahACWvT-QRYLJKcS_FkDNaM Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:27:36 -0000 Yes, I am referring to STUN fragmentation.=20 -Tiru > -----Original Message----- > From: Prashanth Patil (praspati) > Sent: Monday, August 18, 2014 8:18 PM > To: Simon Perreault; Brandon Williams > Cc: Alan Johnston; tram@ietf.org; Tirumaleswar Reddy (tireddy) > Subject: Re: [tram] TURN and fragmentation >=20 > I think Tiru is referring to fragmentation between the Turn Client and > Turn Server. This leads to restrictions in the size of STUN messages. In > context of the ORIGIN draft, this restricts the size/number of ORIGIN > attributes. >=20 > Ability to handle fragments could be useful < to accommodate multiple > ORIGIN attributes and if we ever want to incorporate other parameters in > the authorization token > (http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-01#sec= ti > on-6.2), thus increasing message size. >=20 > -Prashanth >=20 >=20 > On 8/18/14 7:20 PM, "Simon Perreault" wrote: >=20 > >On Mon, Aug 18, 2014 at 9:40 AM, Brandon Williams > > wrote: > >> There's is also some text in STUN related fragmentation and maximum > >>message > >> sizes. > > > >Right. > > > >There are two kinds of fragmentation that are at play here. We need to > >be precise in the words we use. I don't think that there are > >established terms, so let's invent them: > > > >- "STUN fragmentation" happens between the client and the server. > >- "TURN fragmentation" happens between the server and the peer. > > > >I was referring to TURN fragmentation, and you were referring to STUN > >fragmentation. Still not sure what Tiru was referring to. > > > >Simon > > > >_______________________________________________ > >tram mailing list > >tram@ietf.org > >https://www.ietf.org/mailman/listinfo/tram From nobody Mon Aug 18 08:29:33 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99681A063E for ; Mon, 18 Aug 2014 08:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9spWl7CMtc9 for ; Mon, 18 Aug 2014 08:29:30 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AA01A0640 for ; Mon, 18 Aug 2014 08:29:30 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so3839182wiv.15 for ; Mon, 18 Aug 2014 08:29:28 -0700 (PDT) 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:content-type; bh=DiZGhwrfuARptD5fgMSvUc5AGZmB6LDGIPjxLk7u0XY=; b=SUwcIAW6lDAcmNcmAMKQXoeYwoxSdmFO6m/UvxB3Kv/mL/dz+9qGkFsZstC0PeLzSp 8tP5gMzIcH8gKnKA4WNUiR6twoHZRg65kBUGVsRZNU5prIyQYvhuTg4mv2EABamvT5E9 LtrjdL+JJCqP3Kmbo80k3U6OW/FG/ffwmoD/wIJeL0Iw8s4Qt4F8s0pgajufLapyJavz 7KLO77uDNbrwCdgqsmfmrU0XDUaHeU+U5DceQ4GCBRh1sXOO7XdiUt46FF/LP+Ef993k KQuz+qLsXMqct0/mlYGRECjzK9zStGhizSd6JSWDW6PozOTNXK3Yzcg3FtsCYnYQxpN8 4hAg== X-Gm-Message-State: ALoCoQnOIDiTlr+q9SFeJ6sA8uc1wqPdWR8DJkNQ/jOQU5h5B0CcsuutxVwbSZsGeZYcmj0ecqM9 MIME-Version: 1.0 X-Received: by 10.194.71.11 with SMTP id q11mr41552137wju.33.1408375768764; Mon, 18 Aug 2014 08:29:28 -0700 (PDT) Received: by 10.180.80.131 with HTTP; Mon, 18 Aug 2014 08:29:28 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A28317096@xmb-rcd-x10.cisco.com> References: <53F2024D.5030907@akamai.com> <913383AAA69FF945B8F946018B75898A28317096@xmb-rcd-x10.cisco.com> Date: Mon, 18 Aug 2014 11:29:28 -0400 Message-ID: From: Simon Perreault To: "Tirumaleswar Reddy (tireddy)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9g2KUGu8_1X9hMXdbBcR1XLkIRM Cc: "Prashanth Patil \(praspati\)" , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:29:31 -0000 On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) wrote: > Yes, I am referring to STUN fragmentation. Got it, thanks. So, what's your idea, in detail? Thanks, Simon From nobody Mon Aug 18 08:47:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529151A066F for ; Mon, 18 Aug 2014 08:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fkr3_JfU7_Sg for ; Mon, 18 Aug 2014 08:47:31 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC191A066A for ; Mon, 18 Aug 2014 08:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1028; q=dns/txt; s=iport; t=1408376851; x=1409586451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/oWGycaQAgcnMu4VsoaaR8X4jKQqnvTs++QT6RrviNg=; b=IPTlOCyKqTkWuKRa0SRd8ZReKJml1OlY+aLSnalu7we+uS2bIGzM96ln Y1M6G+jhgN4mxJ+/ycPGlBQGAJliaE38xN6ffz5mKoZe8ZxWjk2Dpvdq7 l57PKgJJJBf37hc0AbHSgJfs0lvbzx4LpeI+ZTdOxIkKIDCLzr4RO+3g0 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAFEf8lOtJV2c/2dsb2JhbABZgw1TVwSCeMl+h1gBGYEEFneEAwEBAQMBIxFFDAQCAQgOAwQBAQECAgYdAwICAjAUAQgIAgQOBQiIMggNq3GVCReBLI1vMQcGgnM2gR0BBJElhCaITpMsg11sAQGBRoEHAQEB X-IronPort-AV: E=Sophos;i="5.01,886,1400025600"; d="scan'208";a="70201756" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 18 Aug 2014 15:47:30 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7IFlUuD015396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 15:47:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 10:47:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] TURN and fragmentation Thread-Index: AQHPut6s+iF/dqna80qUkLhBBQDmc5vWsgaAgAAC1ACAABAQgP//tsPAgABUzQD//6xGwA== Date: Mon, 18 Aug 2014 15:47:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283170D9@xmb-rcd-x10.cisco.com> References: <53F2024D.5030907@akamai.com> <913383AAA69FF945B8F946018B75898A28317096@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4r3aczQ6V6W66-0BFOrk2YlrPQA Cc: "Prashanth Patil \(praspati\)" , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 15:47:32 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21h aWx0bzpzcGVycmVhdWx0QGppdmUuY29tXQ0KPiBTZW50OiBNb25kYXksIEF1Z3VzdCAxOCwgMjAx NCA4OjU5IFBNDQo+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+IENjOiBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKTsgQnJhbmRvbiBXaWxsaWFtczsgQWxhbiBKb2huc3RvbjsN Cj4gdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50 YXRpb24NCj4gDQo+IE9uIE1vbiwgQXVnIDE4LCAyMDE0IGF0IDExOjI3IEFNLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpDQo+IDx0aXJlZGR5QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gWWVz LCBJIGFtIHJlZmVycmluZyB0byBTVFVOIGZyYWdtZW50YXRpb24uDQo+IA0KPiBHb3QgaXQsIHRo YW5rcy4NCj4gDQo+IFNvLCB3aGF0J3MgeW91ciBpZGVhLCBpbiBkZXRhaWwgPw0KDQpJIGhhdmUg bm90IHlldCBmaWd1cmVkIG91dCBhbGwgdGhlIGRldGFpbHMsIGF0IGhpZ2ggbGV2ZWwgdGhpbmtp bmcgdGhlIHByb2JsZW0gY2FuIGJlIHNvbHZlZCBzaW1pbGFyIHRvIHdheSBmcmFnbWVudGF0aW9u IGlzIGhhbmRsZWQgaW4gDQpFQVAtVExTIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1 MjE2I3NlY3Rpb24tMi4xLjUpLiANCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiANCj4gVGhhbmtzLA0K PiBTaW1vbg0K From nobody Mon Aug 18 21:37:39 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170D01A87D9; Mon, 18 Aug 2014 21:37:35 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnHqUAssaGmX; Mon, 18 Aug 2014 21:37:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDB11A87D4; Mon, 18 Aug 2014 21:37:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819043734.12776.22100.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 21:37:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/rWL2fv98q65UmKf-6foK7Ff8NqE Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-auth-problems-05.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 04:37:35 -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 Working Group of the IETF. Title : Problems with STUN long-term Authentication for TURN Authors : Tirumaleswar Reddy Ram Mohan Ravindranath Muthu Arul Mozhi Perumal Alper Yegin Filename : draft-ietf-tram-auth-problems-05.txt Pages : 8 Date : 2014-08-18 Abstract: This document discusses some of the security and practical problems with the current Session Traversal Utilities for NAT (STUN) authentication for Traversal Using Relays around NAT (TURN) messages. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-auth-problems-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-auth-problems-05 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 Mon Aug 18 22:37:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B621A02DB for ; Mon, 18 Aug 2014 22:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwTR1NkHC2w9 for ; Mon, 18 Aug 2014 22:37:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67DC1A02D7 for ; Mon, 18 Aug 2014 22:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6196; q=dns/txt; s=iport; t=1408426628; x=1409636228; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=v4QOBU8RM/LxMyMTI7hvGlZPHhDajbymt3E0D6tfBU8=; b=aG3o43AWt7IrbdaAZp0vRRXg8IXzvnmJ7cwlDNpTgl223tszsdgV2MbQ 2QF2OyIRs25+C/B9YOqL7hnuCRvpx+2RDT9Ns3sXeM3GzlkPvLR++bw8n VLwUH+5izd5GKFOXlzbTn6TZUxEDUlJ3zlnTpRcDeRHVpClA16xohJDrI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFACHi8lOtJV2R/2dsb2JhbABZgw1TUwQEgnjKEYdYARl6FneEAwEBAQMBIxFDBwcGAQgRAwEBAQECAgYdAwIEHxEUAQgJAQQBEggBiCUDCQgIBax7j3cNhTMXgSyLc4F8FiiCczaBHQWGEYkBghOEJoRog2aMeYYzg11sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.01,892,1400025600"; d="scan'208";a="348499609" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-2.cisco.com with ESMTP; 19 Aug 2014 05:36:50 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7J5aoUD003057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 05:36:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 00:36:50 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Alan Johnston , "tram@ietf.org" Thread-Topic: [tram] Fwd: New Version Notification for draft-johnston-tram-turnbis-01.txt Thread-Index: Ac+7b5ExxWB9vPGCQ8eyjdPIup/9MA== Date: Tue, 19 Aug 2014 05:36:50 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28317883@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.77.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O57oeO-HJi8TeWzhGs0UiMLPrtQ Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-turnbis-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 05:37:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBGcmlkYXksIEF1Z3Vz dCAxNSwgMjAxNCAxMDoyNyBQTQ0KPiBUbzogQWxhbiBKb2huc3RvbjsgdHJhbUBpZXRmLm9yZzsg VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIEZ3ZDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2huc3Rvbi10cmFtLQ0KPiB0dXJu YmlzLTAxLnR4dA0KPiANCj4gVGhhbmtzIHRvIGJvdGggb2YgeW91IGZvciB0YWtpbmcgb24gdGhp cyB0YXNrLg0KPiANCj4gUmVnYXJkaW5nIHF1ZXN0aW9ucyB0aGF0IHlvdSBhc2sgaW4gZWRpdG9y J3Mgbm90ZXM6DQo+IA0KPiAqIEkgdGhpbmsgaXQgd291bGQgbmljZSB0byBoYXZlIGEgdW5pZmll ZCBkb2N1bWVudCBmb3IgSVB2NCwgSVB2NiwgVURQLCBhbmQNCj4gVENQLCBhbmQgc28gbWVyZ2lu ZyBSRkM2MDYyIGFuZCBSRkM2MTU2IHRleHQgaW50byBUVVJOYmlzIHdvdWxkIGJlIGdvb2QuDQo+ IEluIHBhcnRpY3VsYXIsIHRoZSBJUHY2IGlzIHByb2JhYmx5IG5lY2Vzc2FyeSB0byBpbmNsdWRl IGlmIFNTT0RBIGlzIHRvIGJlDQo+IGluY2x1ZGVkLiANCg0KQWdyZWUgd2l0aCBhbGwgdGhlIGFi b3ZlIHBvaW50cyBleGNlcHQgbWVyZ2luZyBSRkMgNjA2MiBpbnRvIFRVUk5iaXMuIA0KVFVSTmJp cyByZWZlcnJpbmcgdG8gUkZDIDYwNjIgc2hvdWxkIHN1ZmZpY2UuDQoNCj4gVGhhdCBzYWlkLCBJ IGRvbid0IGZlZWwgc3Ryb25nbHkgZW5vdWdoIGFib3V0IGl0IHRvIHB1dCB1cCBhbnkNCj4gcmVz aXN0YW5jZSBpZiBhbnlvbmUgZWxzZSBkaXNhZ3JlZXMuDQo+IA0KPiAqIEkgZG9uJ3QgdGhpbmsg YSBzcGVjaWZpYyBhbGdvcml0aG0gZnJvbSBSRkM2MDU2IG5lZWRzIHRvIGJlIHJlY29tbWVuZGVk Lg0KDQpPa2F5Lg0KDQotVGlydQ0KDQo+IFRoZSBSRkMgaXRzZWxmIHByb3ZpZGVzIGEgZ29vZCBk aXNjdXNzaW9uIG9mIHRoZSB0cmFkZW9mZnMsIGJ1dCBpdHNlbGYgZmFsbHMgc2hvcnQNCj4gb2Yg cHJvdmlkaW5nIGFueSByZWNvbW1lbmRhdGlvbnMuIEl0IG1pZ2h0IGJlIHdvcnRod2hpbGUgdG8g bm90ZSB0aGF0DQo+IHNvbWUgb2YgdGhlIFJGQzYwNTYgZGlzY3Vzc2lvbiByZTogTkFQVCBhcHBs aWVzIHRvIFRVUk4gYWxsb2NhdGlvbnMgYXMgd2VsbC4NCg0KPiANCj4gLS1CcmFuZG9uDQo+IA0K PiBPbiAwOC8xMC8yMDE0IDA2OjU1IFBNLCBBbGFuIEpvaG5zdG9uIHdyb3RlOg0KPiA+IEFsbCwN Cj4gPg0KPiA+IFRpcnUgYW5kIEkgaGF2ZSBtYWRlIGEgc3RhcnQgdG8gdGhlIFRVUk5iaXMgZHJh ZnQuICBXZSBoYXZlIHN1Ym1pdHRlZA0KPiA+IGl0IGFzIGFuIGluZGl2aWR1YWwgZHJhZnQgc28g dGhlIHdvcmtpbmcgZ3JvdXAgY2FuIGRlY2lkZSBpZiB0aGlzIGlzIGENCj4gPiByZWFzb25hYmxl IHN0YXJ0aW5nIHBvaW50IGZvciBvdXIgY2hhcnRlcmVkIHdvcmsgaXRlbS4NCj4gPg0KPiA+IFRo ZSAtMDAgdmVyc2lvbiBpcyBlc3NlbnRpYWxseSB1bmNoYW5nZWQgZnJvbSBSRkMgNTc2NiB0byBt YWtlIGl0IGVhc3kNCj4gPiB0byB0cmFjayB0aGUgY2hhbmdlcy4gIFRoZSAtMDEgdmVyc2lvbiBy ZXByZXNlbnRzIG91ciBlZGl0cyBzbyBmYXINCj4gPiBpbmNsdWRpbmcgYSBudW1iZXIgb2YgRWRp dG9yJ3MgTm90ZXMuDQo+ID4NCj4gPiBGZWVkYmFjayBhbmQgY29tbWVudHMgYXJlIG1vc3Qgd2Vs Y29tZS4NCj4gPg0KPiA+IC0gQWxhbiAtDQo+ID4NCj4gPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBt ZXNzYWdlIC0tLS0tLS0tLS0NCj4gPiBGcm9tOiAqKiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4NCj4gPiBEYXRlOiBTdW4sIEF1ZyAx MCwgMjAxNCBhdCA1OjUwIFBNDQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u IGZvcg0KPiA+IGRyYWZ0LWpvaG5zdG9uLXRyYW0tdHVybmJpcy0wMS50eHQNCj4gPiBUbzogVGly dW1hbGVzd2FyIFJlZGR5IDx0aXJlZGR5QGNpc2NvLmNvbQ0KPiA8bWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tPj4sDQo+ID4gQWxhbiBKb2huc3RvbiA8YWxhbi5iLmpvaG5zdG9uQGdtYWlsLmNvbQ0K PiA+IDxtYWlsdG86YWxhbi5iLmpvaG5zdG9uQGdtYWlsLmNvbT4+LCBSb2hhbiBNYWh5IDxyb2hh bkBla2FiYWwuY29tDQo+ID4gPG1haWx0bzpyb2hhbkBla2FiYWwuY29tPj4sIEpvbmF0aGFuIFJv c2VuYmVyZyA8amRyb3NlbkBqZHJvc2VuLm5ldA0KPiA+IDxtYWlsdG86amRyb3NlbkBqZHJvc2Vu Lm5ldD4+LCBQaGlsaXAgTWF0dGhld3MNCj4gPiA8cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIDxt YWlsdG86cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhPj4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtam9obnN0b24tdHJhbS10dXJuYmlzLTAxLnR4dA0KPiA+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxhbiBKb2huc3RvbiBhbmQgcG9z dGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6ICAgICAgICAg ICBkcmFmdC1qb2huc3Rvbi10cmFtLXR1cm5iaXMNCj4gPiBSZXZpc2lvbjogICAgICAgMDENCj4g PiBUaXRsZTogICAgICAgICAgVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUIChUVVJO KTogUmVsYXkNCj4gPiBFeHRlbnNpb25zIHRvIFNlc3Npb24gVHJhdmVyc2FsIFV0aWxpdGllcyBm b3IgTkFUIChTVFVOKSBEb2N1bWVudA0KPiA+IGRhdGU6ICAyMDE0LTA4LTEwDQo+ID4gR3JvdXA6 ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBhZ2VzOiAgICAgICAgICA2OQ0K PiA+IFVSTDoNCj4gPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1q b2huc3Rvbi10cmFtLXR1cm5iaXMtMDEudHh0DQo+ID4gU3RhdHVzOiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1qb2huc3Rvbi10cmFtLXR1cm5iaXMvDQo+ID4gSHRtbGl6 ZWQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaG5zdG9uLXRyYW0tdHVybmJp cy0wMQ0KPiA+IERpZmY6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWpv aG5zdG9uLXRyYW0tdHVybmJpcy0wMQ0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgIElmIGEg aG9zdCBpcyBsb2NhdGVkIGJlaGluZCBhIE5BVCwgdGhlbiBpbiBjZXJ0YWluIHNpdHVhdGlvbnMg aXQgY2FuDQo+ID4gICAgIGJlIGltcG9zc2libGUgZm9yIHRoYXQgaG9zdCB0byBjb21tdW5pY2F0 ZSBkaXJlY3RseSB3aXRoIG90aGVyIGhvc3RzDQo+ID4gICAgIChwZWVycykuICBJbiB0aGVzZSBz aXR1YXRpb25zLCBpdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBob3N0IHRvIHVzZQ0KPiA+ICAgICB0 aGUgc2VydmljZXMgb2YgYW4gaW50ZXJtZWRpYXRlIG5vZGUgdGhhdCBhY3RzIGFzIGEgY29tbXVu aWNhdGlvbg0KPiA+ICAgICByZWxheS4gIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgcHJv dG9jb2wsIGNhbGxlZCBUVVJOIChUcmF2ZXJzYWwNCj4gPiAgICAgVXNpbmcgUmVsYXlzIGFyb3Vu ZCBOQVQpLCB0aGF0IGFsbG93cyB0aGUgaG9zdCB0byBjb250cm9sIHRoZQ0KPiA+ICAgICBvcGVy YXRpb24gb2YgdGhlIHJlbGF5IGFuZCB0byBleGNoYW5nZSBwYWNrZXRzIHdpdGggaXRzIHBlZXJz IHVzaW5nDQo+ID4gICAgIHRoZSByZWxheS4gIFRVUk4gZGlmZmVycyBmcm9tIHNvbWUgb3RoZXIg cmVsYXkgY29udHJvbCBwcm90b2NvbHMgaW4NCj4gPiAgICAgdGhhdCBpdCBhbGxvd3MgYSBjbGll bnQgdG8gY29tbXVuaWNhdGUgd2l0aCBtdWx0aXBsZSBwZWVycyB1c2luZyBhDQo+ID4gICAgIHNp bmdsZSByZWxheSBhZGRyZXNzLg0KPiA+DQo+ID4gICAgIFRoZSBUVVJOIHByb3RvY29sIHdhcyBk ZXNpZ25lZCB0byBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlIElDRQ0KPiA+ICAgICAoSW50ZXJhY3Rp dmUgQ29ubmVjdGl2aXR5IEVzdGFibGlzaG1lbnQpIGFwcHJvYWNoIHRvIE5BVCB0cmF2ZXJzYWws DQo+ID4gICAgIHRob3VnaCBpdCBhbHNvIGNhbiBiZSB1c2VkIHdpdGhvdXQgSUNFLg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQNCj4gPiB0b29scy5pZXRmLm9y ZyA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0 DQo+ID4NCj4gPg0KPiANCj4gLS0NCj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBh bCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsgQWth bWFpIFRlY2hub2xvZ2llcyBJbmMuDQo= From nobody Tue Aug 19 02:15:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2F21A8763 for ; Tue, 19 Aug 2014 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_bJoDDMD1By for ; Tue, 19 Aug 2014 02:15:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3A61A0348 for ; Tue, 19 Aug 2014 02:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2480; q=dns/txt; s=iport; t=1408439733; x=1409649333; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=+QSKslHUVhr4Lv/4DFWYSYdRorbvoFWKhiD16wqeib4=; b=awA5c03hNJBITgv9s4SALhtMUR3wokuzQ/EPfZyKfytz0c1qgdQCZNiQ 2Z/1ZMQ/00ahqisnKDctSXOP5PWmwp9uZG+MplT4hAVnDpTbZphYt+rYH GYACKCRw/qnsGA/6DKrH5Zf4d41yya8YORZe08hZsSmDfGSPbtbtuLI42 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFAEkV81OtJA2D/2dsb2JhbABZgw1TVwSCeMluh1gBGXUWd4QDAQEBAwEjETMSDAYBCA4DBAEBAQICBh0DAgQwFAEICQEEDgUIiDIIDawelTEXgSyNbzENgnM2gR0FkSWEJohOkyyDXWwBAYEGJByBBwEBAQ X-IronPort-AV: E=Sophos;i="5.01,893,1400025600"; d="scan'208";a="70434451" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 19 Aug 2014 09:15:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7J9FWns003402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Aug 2014 09:15:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 19 Aug 2014 04:15:32 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault Thread-Topic: [tram] TURN and fragmentation Thread-Index: Ac+7jhywuv5uhwsYToWrzO8B1UwDZg== Date: Tue, 19 Aug 2014 09:15:31 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/civXvFJ8L6-mq4wjRqHwRjCVL7k Cc: "Prashanth Patil \(praspati\)" , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 09:15:35 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpDQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDk6MTcgUE0NCj4gVG86 ICdTaW1vbiBQZXJyZWF1bHQnDQo+IENjOiBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgQnJh bmRvbiBXaWxsaWFtczsgQWxhbiBKb2huc3RvbjsNCj4gdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSRTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRpb24NCj4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVh dWx0QGppdmUuY29tXQ0KPiA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDg6NTkgUE0N Cj4gPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+IENjOiBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKTsgQnJhbmRvbiBXaWxsaWFtczsgQWxhbiBKb2huc3RvbjsNCj4gPiB0 cmFtQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIGFuZCBmcmFnbWVudGF0 aW9uDQo+ID4NCj4gPiBPbiBNb24sIEF1ZyAxOCwgMjAxNCBhdCAxMToyNyBBTSwgVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+IDx0aXJlZGR5QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4g PiBZZXMsIEkgYW0gcmVmZXJyaW5nIHRvIFNUVU4gZnJhZ21lbnRhdGlvbi4NCj4gPg0KPiA+IEdv dCBpdCwgdGhhbmtzLg0KPiA+DQo+ID4gU28sIHdoYXQncyB5b3VyIGlkZWEsIGluIGRldGFpbCA/ DQo+IA0KPiBJIGhhdmUgbm90IHlldCBmaWd1cmVkIG91dCBhbGwgdGhlIGRldGFpbHMsIGF0IGhp Z2ggbGV2ZWwgdGhpbmtpbmcgdGhlIHByb2JsZW0NCj4gY2FuIGJlIHNvbHZlZCBzaW1pbGFyIHRv IHdheSBmcmFnbWVudGF0aW9uIGlzIGhhbmRsZWQgaW4gRUFQLVRMUw0KPiAoaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTIxNiNzZWN0aW9uLTIuMS41KS4NCg0KVGhpbmtpbmcgYWxvdWQu IFNUVU4gZnJhZ21lbnRhdGlvbiBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQgYnkgdGhlIGZvbGxvd2lu ZyBhcHByb2FjaDoNClsxXSBJbnRyb2R1Y2UgYSBuZXcgU1RVTiBGUkFHTUVOVCBhdHRyaWJ1dGUg d2hpY2ggY2FycmllcyB0aGUgZnJhZ21lbnRhdGlvbiBkZXRhaWxzIGxpa2UgKE06IE1vcmUgZnJh Z21lbnRzOiB3aGljaCBpcyBzZXQgb24gYWxsIGZyYWdtZW50cyBidXQgdGhlIGxhc3QgZnJhZ21l bnQpLCAgUyAoRnJhZ21lbnRhdGlvbiBzdGFydCksIElkZW50aWZpZXIgZm9yIHNlcXVlbmNpbmcg ZXRjLikuDQpbMl0gU1RVTiBhdHRyaWJ1dGUgdGhhdCB3b3VsZCBiZSBzdWJqZWN0ZWQgdG8gZnJh Z21lbnRhdGlvbiBzaG91bGQgYmUgcGxhY2VkIGFmdGVyIHRoZSBTVFVOIEZSQUdNRU5UIGF0dHJp YnV0ZS4NClszXSBUVVJOIHNlcnZlciB1c2VzIGEgbmV3IFNUVU4gYXR0cmlidXRlIGxldOKAmXMg c2F5IEFDSyB0byBzaWduYWwgYmFjayB0byB0aGUgY2xpZW50IHRoYXQgaXQgcmVjZWl2ZWQgdGhl IGZyYWdtZW50IGJ5IHNpZ25hbGluZyBiYWNrIHRoZSBJZGVudGlmaWVyIGl0IHJlY2VpdmVkIGlu IHJlcXVlc3QuIA0KWzRdIE9uY2UgdGhlIGZpbmFsIGZyYWdtZW50IGlzIHJlY2VpdmVkLCBUVVJO IHNlcnZlciBtZXJnZXMgdGhlIGZyYWdtZW50cywgdmFsaWRhdGVzIHRoZSBTVFVOIG1lc3NhZ2Ug YW5kIHJlc3BvbmRzIGJhY2sgdG8gdGhlIGNsaWVudC4NCg0KLVRpcnUNCg0KPiANCj4gQ2hlZXJz LA0KPiAtVGlydQ0KPiANCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBTaW1vbg0K From nobody Wed Aug 20 07:01:58 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9C1A03C2; Wed, 20 Aug 2014 07:01:53 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNhEaG7_CLVu; Wed, 20 Aug 2014 07:01:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A266E1A03D9; Wed, 20 Aug 2014 07:01:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140820140144.3761.73322.idtracker@ietfa.amsl.com> Date: Wed, 20 Aug 2014 07:01:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6MzkkwMzG9WlDZ_aLKcOtDV_rFo Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 14:01:55 -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 Working Group of the IETF. Title : An Origin Attribute for the STUN Protocol Authors : Alan Johnston Justin Uberti John Yoakum Kundan Singh Filename : draft-ietf-tram-stun-origin-01.txt Pages : 13 Date : 2014-08-20 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-stun-origin-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-origin-01 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 Aug 20 11:48:26 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC531A069B for ; Wed, 20 Aug 2014 11:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTUPgoAO5Jzs for ; Wed, 20 Aug 2014 11:48:21 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E211A0466 for ; Wed, 20 Aug 2014 11:48:20 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so8308697wes.35 for ; Wed, 20 Aug 2014 11:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LxMgX+0v4v1P18uwJrggq1n1YkDIUGse9szZqDgiLSc=; b=Hx+ijkSDNWfnN+puSeJjnRxGQQY4+ywBDpvcYez+UnlucNprIUPczdqrLuP+qYroqi FuM/LudQJdQnCG30yAgUUnAKQ9O94Jg9hZ248b4HCMkOSaaBewJozetEi/XnanGijZ35 0hqW+NfXAsri6elb9kuGmhV1nQiTNKuIq9TcCRXNN4RLfB+8wmp7Ockj3Wa0lJ6FQdkD 80NZMdaSZoxt0nL0QNkEHuNCD2SiNdm6F5P/JR11OG/Dtwnqu1vNHIdtupC/YR4Tdyqt jZw64uIMmGYksfrzQN+kpXAybssV3Fwt6+OIO5WLS+0kBrPRyFM1v/3yQIINs0HarGda +GgA== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr61835482wjb.59.1408560499387; Wed, 20 Aug 2014 11:48:19 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Wed, 20 Aug 2014 11:48:19 -0700 (PDT) Date: Wed, 20 Aug 2014 11:48:19 -0700 Message-ID: From: Martin Thomson To: "tram@ietf.org" , Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gMpx_9TKGTsTX4G8wAIzfEX5ke4 Subject: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 18:48:23 -0000 I've read this through and have some comments: Definition of origin: This document uses a more expansive definition than the one in RFC 6454. While it appears that this is consistent, I think that this needs to be made more prominently. And given that RFC 6454 is a relatively large document (20 pages), I'm a little concerned that the definition for SIP and XMPP origins is a little lean. At a minimum, I think that you need to identify what components from the respective BNF definitions of XMPP and SIP URIs are kept and what are removed. Multiple origins: I'm not sure that you really need to concern yourself with multiple origins. The ability to carry multiple Origin header fields in HTTP is bound to the way that browsers fetch resources. This can sometimes mean that a resource is fetched by multiple origins (tabs, frames, windows, etc...) at the same time. Even then, it is relatively rare that this will happen. In the context of WebRTC, I can't think of a single case where origin will need to be doubled. Any single binding request will be at the behest of a single origin; and while a TURN allocation might be shared between multiple origins, that will only happen because it's the browser acting on its own writ, not on behalf on any origin. Individual channels might need an origin binding in that case. In the other contexts, it seems obvious that similar constraints apply. Privacy: The privacy section talks about protection in transit, but does not talk about the ability of a STUN or TURN server itself to learn about communication usage, something it would not normally be able to obtain. Some text on this would be useful, since these parties were previously either entirely supplemental to communication, or only involved in the peer-to-peer communications. I'm sure that this information could be turned into money, so there has to be at least some privacy implications there. Size: The recommended limit on size is a little odd. It should be impossible to generate an origin that exceeds this number. I would leave the advice at the point were the maximum size is noted and the potential this has to cause fragmentation. TLS SNI: I found the introduction to be a little long and wordy, perhaps excessively justified. The discussion of SNI might be appropriate for convincing the working group of the need for this solution over something based on SNI, I found this both completely obvious (of course SNI doesn't work) and actually somewhat non-sequitur. I think that this paragraph (at least) could be removed. Redundant text: To ensure backwards compatibility with [RFC3489], the ORIGIN attribute is padded to ensure its length is a multiple of 4 octets. From nobody Thu Aug 21 11:41:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593811A797C for ; Thu, 21 Aug 2014 11:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90nmMhAT9uXR for ; Thu, 21 Aug 2014 11:41:39 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732501A7113 for ; Thu, 21 Aug 2014 11:41:39 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so9685547wes.11 for ; Thu, 21 Aug 2014 11:41:38 -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:content-type; bh=j2l+0wwL8XLhZSuV+3z1VV/1DkHYqn+HKe0GES07IJo=; b=Wl2mBO0X38Ml9sSOcvBI+03HqzVMMBOEbCQJL2RMtA6ZDP3zOSSrOCHyMzrUTzSExb Gbaao2IIbgnpZNBQndSCufYgExkR0tIQHRlKgDWLQz+sT0F4nCjIK8RrHdZJinCuELhP DkgbvWeQ8QhhhsJIO8nE2Fcjrwsy8thvMwOFqTYWN6Xbpa3eag94qTxc8mAnLzbSBS6g 4QSv6cV/1BQZHaE/ZPGWogI/ZWylGjH/VwuQpKtQE7lnEiTRUq/VT1QGAkHoLq2Xj++U 8O6n39M9I4n/IARqgHioIE1zkHN2biEctCCag8MbUYE2v7wRKfn6m1R8ygkQADw3Uh08 x9/g== MIME-Version: 1.0 X-Received: by 10.194.77.212 with SMTP id u20mr296905wjw.27.1408646497952; Thu, 21 Aug 2014 11:41:37 -0700 (PDT) Received: by 10.216.108.135 with HTTP; Thu, 21 Aug 2014 11:41:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 13:41:37 -0500 Message-ID: From: Alan Johnston To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bfcf8581feac6050128126c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4HpzC9Nq3ggPAYkJ2ZXgyCrC5yw Cc: "tram@ietf.org" Subject: Re: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 18:41:42 -0000 --047d7bfcf8581feac6050128126c Content-Type: text/plain; charset=UTF-8 Martin, Thanks for doing this review. My comments are below. Hopefully others will also weigh in on the issues you raise. - Alan - On Wed, Aug 20, 2014 at 1:48 PM, Martin Thomson wrote: > I've read this through and have some comments: > > Definition of origin: > This document uses a more expansive definition than the one in RFC > 6454. While it appears that this is consistent, I think that this > needs to be made more prominently. > > That is a very good point to be made in the introduction and perhaps even the abstract. > And given that RFC 6454 is a relatively large document (20 pages), I'm > a little concerned that the definition for SIP and XMPP origins is a > little lean. At a minimum, I think that you need to identify what > components from the respective BNF definitions of XMPP and SIP URIs > are kept and what are removed. > Right. The XMPP does mention parts of the ABNF and gives an example. We should add the same for SIP. > Multiple origins: > I'm not sure that you really need to concern yourself with multiple > origins. The ability to carry multiple Origin header fields in HTTP > is bound to the way that browsers fetch resources. This can sometimes > mean that a resource is fetched by multiple origins (tabs, frames, > windows, etc...) at the same time. Even then, it is relatively rare > that this will happen. > > In the context of WebRTC, I can't think of a single case where origin > will need to be doubled. Any single binding request will be at the > behest of a single origin; and while a TURN allocation might be shared > between multiple origins, that will only happen because it's the > browser acting on its own writ, not on behalf on any origin. > Individual channels might need an origin binding in that case. > Interesting - I had thought, incorrectly it seems, that if a page from one domain fetched a script from another domain that accessed a resource, that the HTTP origin would include both domains. The case of a resource fetched at the same time by multiple origins doesn't seem to apply to WebRTC. Each of these origins would correspond to a different Peer Connection. I don't think a browser would ever share STUN bindings or TURN allocations across different Peer Connections. If we can rule out this behavior, then perhaps the text on multiple origins can just say that it can't happen. > > In the other contexts, it seems obvious that similar constraints apply. > > Since we are defining it for SIP and XMPP, we can just make it a MUST NOT. > Privacy: > The privacy section talks about protection in transit, but does not > talk about the ability of a STUN or TURN server itself to learn about > communication usage, something it would not normally be able to > obtain. Some text on this would be useful, since these parties were > previously either entirely supplemental to communication, or only > involved in the peer-to-peer communications. I'm sure that this > information could be turned into money, so there has to be at least > some privacy implications there. > That is a good point. For a STUN server, this is new information, not otherwise available. For a TURN server, if realm doesn't map 1:1 to origin, then this also provides new information. I will propose some text on this. > > Size: > The recommended limit on size is a little odd. It should be > impossible to generate an origin that exceeds this number. I would > leave the advice at the point were the maximum size is noted and the > potential this has to cause fragmentation. > > If we can do away with multiple origins, then I'm fine with this. > TLS SNI: > I found the introduction to be a little long and wordy, perhaps > excessively justified. The discussion of SNI might be appropriate for > convincing the working group of the need for this solution over > something based on SNI, I found this both completely obvious (of > course SNI doesn't work) and actually somewhat non-sequitur. I think > that this paragraph (at least) could be removed. > I hadn't read the Introduction in a while, and I agree. I can write a much better introduction. > > Redundant text: > To ensure backwards compatibility with [RFC3489], the ORIGIN > attribute is padded to ensure its length is a multiple of 4 octets. > Since this is already a MUST in RFC 5389, this is redundant and can be removed. --047d7bfcf8581feac6050128126c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

Thanks for doing this review. = =C2=A0My comments are below. =C2=A0Hopefully others will also weigh in on t= he issues you raise.

- Alan -


On Wed, Aug 20, 2014 at 1:48 PM, Martin = Thomson <martin.thomson@gmail.com> wrote:
I've read this through and have some comments:

Definition of origin:
This document uses a more expansive definition than the one in RFC
6454.=C2=A0 While it appears that this is consistent, I think that this
needs to be made more prominently.


That is a very good point to be made i= n the introduction and perhaps even the abstract.
=C2=A0
And given that RFC 6454 is a relatively large document (20 pages), I'm<= br> a little concerned that the definition for SIP and XMPP origins is a
little lean.=C2=A0 At a minimum, I think that you need to identify what
components from the respective BNF definitions of XMPP and SIP URIs
are kept and what are removed.

Right. = =C2=A0The XMPP does mention parts of the ABNF and gives an example. =C2=A0W= e should add the same for SIP.


Multiple origins:
I'm not sure that you really need to concern yourself with multiple
origins.=C2=A0 The ability to carry multiple Origin header fields in HTTP is bound to the way that browsers fetch resources.=C2=A0 This can sometimes=
mean that a resource is fetched by multiple origins (tabs, frames,
windows, etc...) at the same time.=C2=A0 Even then, it is relatively rare that this will happen.

In the context of WebRTC, I can't think of a single case where origin will need to be doubled.=C2=A0 Any single binding request will be at the behest of a single origin; and while a TURN allocation might be shared
between multiple origins, that will only happen because it's the
browser acting on its own writ, not on behalf on any origin.
Individual channels might need an origin binding in that case.

Interesting - I had thought, incorrectly it seems, = that if a page from one domain fetched a script from another domain that ac= cessed a resource, that the HTTP origin would include both domains. =C2=A0T= he case of a resource fetched at the same time by multiple origins doesn= 9;t seem to apply to WebRTC. =C2=A0Each of these origins would correspond t= o a different Peer Connection. =C2=A0I don't think a browser would ever= share STUN bindings or TURN allocations across different Peer Connections.= =C2=A0If we can rule out this behavior, then perhaps the text on multiple = origins can just say that it can't happen.
=C2=A0

In the other contexts, it seems obvious that similar constraints apply.


Since we are defining it for SIP and X= MPP, we can just make it a MUST NOT.
=C2=A0
Privacy:
The privacy section talks about protection in transit, but does not
talk about the ability of a STUN or TURN server itself to learn about
communication usage, something it would not normally be able to
obtain.=C2=A0 Some text on this would be useful, since these parties were previously either entirely supplemental to communication, or only
involved in the peer-to-peer communications.=C2=A0 I'm sure that this information could be turned into money, so there has to be at least
some privacy implications there.

That i= s a good point. =C2=A0For a STUN server, this is new information, not other= wise available. =C2=A0For a TURN server, if realm doesn't map 1:1 to or= igin, then this also provides new information. =C2=A0I will propose some te= xt on this.
=C2=A0

Size:
The recommended limit on size is a little odd.=C2=A0 It should be
impossible to generate an origin that exceeds this number.=C2=A0 I would leave the advice at the point were the maximum size is noted and the
potential this has to cause fragmentation.


If we can do away with multiple origin= s, then I'm fine with this.
=C2=A0
TLS SNI:
I found the introduction to be a little long and wordy, perhaps
excessively justified.=C2=A0 The discussion of SNI might be appropriate for=
convincing the working group of the need for this solution over
something based on SNI, I found this both completely obvious (of
course SNI doesn't work) and actually somewhat non-sequitur.=C2=A0 I th= ink
that this paragraph (at least) could be removed.

<= /div>
I hadn't read the Introduction in a while, and I agree. =C2= =A0I can write a much better introduction.
=C2=A0

Redundant text:
=C2=A0 =C2=A0To ensure backwards compatibility with [RFC3489], the ORIGIN =C2=A0 =C2=A0attribute is padded to ensure its length is a multiple of 4 oc= tets.

Since this is alrea= dy a MUST in RFC 5389, this is redundant and can be removed.



--047d7bfcf8581feac6050128126c-- From nobody Thu Aug 21 12:48:43 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FDF1A06CD for ; Thu, 21 Aug 2014 12:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0WswRNrBcEq for ; Thu, 21 Aug 2014 12:48:39 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85651A0698 for ; Thu, 21 Aug 2014 12:48:38 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u57so9861386wes.10 for ; Thu, 21 Aug 2014 12:48:37 -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:content-type; bh=pdSLwJNVkmwHut40ZTiXsKF75oezZZQA8JwZVEax5+4=; b=DFbzKmz2JtwZkkoXGw2bxqfI5LIpx9rRjYqrXTRShW/6tihDizMwa2S5XvLna05B63 qANL8UQnGGC1NJvd0lpz0/fRJjnd/mvxhny7KkcW9istuF/vYRqvMxXTPjJFxnxIUEYQ YKlfe/Vk/IcFEDTfGEjY5CsEdf4pYk/KQ+AqXr4yx37uJ1D0fS32egDKDSPDXoXV5mTw QAon5opUt3/2xhC/wznUii0CfiRnuWrUzQXc+msDO+RmgL3G3jsc+11r45i4Qblpt++L bL34L1bl44TmdOOkHl2IYCgNB3K4WINyK+0uhovkIH6a6AzzTD8tHyLRXVW4GQUCFPJT czag== MIME-Version: 1.0 X-Received: by 10.180.104.42 with SMTP id gb10mr24387114wib.65.1408650517502; Thu, 21 Aug 2014 12:48:37 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 21 Aug 2014 12:48:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Aug 2014 12:48:37 -0700 Message-ID: From: Martin Thomson To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nejhZdGuyBOl0hUsAQB2FZOkww4 Cc: "tram@ietf.org" Subject: Re: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:48:40 -0000 On 21 August 2014 11:41, Alan Johnston wrote: > Interesting - I had thought, incorrectly it seems, that if a page from one > domain fetched a script from another domain that accessed a resource, that > the HTTP origin would include both domains. The Origin: header field is populated by the entity that initiates the fetch. Typically, that's the origin in the address bar. Where the script that is being run was retrieved from doesn't matter. (e.g., a page can import jquery, but it runs code under its own domain, not jquery's). From nobody Thu Aug 21 21:30:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0BBE1A882B; Thu, 21 Aug 2014 21:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAXmXynCJLZS; Thu, 21 Aug 2014 21:30:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 695361A8825; Thu, 21 Aug 2014 21:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8022; q=dns/txt; s=iport; t=1408681806; x=1409891406; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=pqZFtz0lUG1crHecyN9rpSKqvuH9A44jFDO62uZvJXA=; b=T1i8GvAQQAZ8d4w8WqVJa2dHOTzolz0nsHE/Y1CSfmuckZXN8mFm6dgA q2xIfl2b+ZsVoHwWkpmqk3Rm+jiOKdf+53RhsD8kktldshH3rLUvc05AI B5LnoUQkM3kakecButD/9o+gp0LaVOGQs67es4JKUaAXgcYBYjcC8zUwj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJ7G9lOtJV2d/2dsb2JhbABZgw1TVwSCeMlkh04BGXYWd4QDAQEBAwEjBA0zCwcMBgEIEQQBAQMCBg4PAwIEMBQBCAkBBAENBQiIJgMJCA2ua5UTF4Esi3OBSxEBHxYbDRKCYTaBHQWFBAKMH4QpiFCTM4NebIEPOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,377,1406592000"; d="scan'208";a="349441871" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 22 Aug 2014 04:30:05 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7M4U3EC023379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 04:30:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 23:30:03 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: Review of draft-ietf-tram-turn-third-party-authz-01 Thread-Index: Ac+9wboQ5l8DJdE+SCio/9XibBSHZA== Date: Fri, 22 Aug 2014 04:30:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Yy81f89zGvoXJe9DcRZgTAMX0EM Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 04:30:08 -0000 SGkgSGFubmVzLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFubmVzIFRzY2hvZmVuaWcg W21haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0XQ0KPiBTZW50OiBGcmlkYXksIEF1Z3Vz dCAyMiwgMjAxNCAxMjoyMSBBTQ0KPiBUbzogb2F1dGhAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWll dGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6QHRvb2xzLmlldGYub3JnOw0KPiBHb256YWxv LkNhbWFyaWxsb0Blcmljc3Nvbi5jb20gPj4gR29uemFsbyBDYW1hcmlsbG87DQo+IHNwZXJyZWF1 bHRAaml2ZS5jb20NCj4gU3ViamVjdDogUmV2aWV3IG9mIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRo aXJkLXBhcnR5LWF1dGh6LTAxDQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBTaW1vbiBhc2tlZCB1cyAo RGVyZWsgYW5kIG15c2VsZikgdG8gZG8gYSBxdWljayByZXZpZXcgb2YgdGhpcyBkb2N1bWVudA0K PiBkZXZlbG9wZWQgd2l0aGluIGFub3RoZXIgd29ya2luZyBncm91cCB0aGF0IGhhcHBlbnMgdG8g dXNlIE9BdXRoLg0KPiANCj4gKiBCYWNrZ3JvdW5kDQo+IA0KPiBUVVJOIGlzIGEgc3BlY2lhbCB0 dW5uZWxsaW5nIGdhdGV3YXkgKHZlcnkgbXVjaCBsaWtlIGFuIElQc2VjIGdhdGV3YXkgd291bGQN Cj4gYmUpIGJ1dCBkZXNpZ25lZCBzcGVjaWZpY2FsbHkgdG8gcmVsYXkgdm9pY2UvdmlkZW8gdHJh ZmZpYy4gVG8gcHJldmVudCBhdHRhY2tzIGENCj4gVFVSTiBjbGllbnQgKHN1Y2ggYXMgYSBWb0lQ IHBob25lKSB1c2VzIGEgc2hhcmVkIHNlY3JldCAodXNlcm5hbWUgJg0KPiBwYXNzd29yZCkgd2l0 aCB0aGUgVFVSTiBzZXJ2ZXIgKD1nYXRld2F5KS4NCj4gDQo+IFNvLCBpZiBBbGljZSBjYWxscyBC b2IgYW5kIHVzZXMgYSBUVVJOIHNlcnZlciB0aGVuIGhlciBWb0lQIGNsaWVudCB1c2VzIFNJUCBv cg0KPiBXZWJSVEMgKGFzIGEgc2lnbmFsaW5nIHByb3RvY29sKSB0byBlc3RhYmxpc2ggdGhlIG5l Y2Vzc2FyeSBjb21tdW5pY2F0aW9uDQo+IHNvIHRoYXQgdm9pY2UgcGFja2V0cyBjYW4gYmUgZXhj aGFuZ2VkIGJldHdlZW4gdGhlIHR3byBWb0lQIGNsaWVudHMgd2l0aA0KPiB0aGUgaGVscCBvZiB0 aGUgVFVSTiBzZXJ2ZXIuDQo+IA0KPiBUaGUgbWFpbiBpZGVhIG9mIHRoaXMgZG9jdW1lbnQgaXMg dG8gcmUtdXNlIE9BdXRoIHRvIGF1dGhvcml6ZSB0aGUgdXNlIG9mDQo+IHRoaXMgVFVSTiBzZXJ2 ZXIuDQo+IA0KPiAqIFRoZSBEZXNpZ24NCj4gDQo+IEkgd291bGQgaGF2ZSB1c2VkIE9BdXRoIGFz IGlzIChvciBtYXliZSBzZWxlY3RlZCBhIHNwZWNpZmljIGdyYW50IHR5cGUpIHRvDQo+IG9idGFp biBhbiBhY2Nlc3MgdG9rZW4uIFRoZW4sIEkgd291bGQgaGF2ZSBkZWZpbmVkIGhvdyB0aGUgYWNj ZXNzIHRva2VuIGlzDQo+IGNhcnJpZWQgaW4gdGhlIFRVUk4gcHJvdG9jb2wuIFRoaXMgaXMgYSBi aXQgc2ltaWxhciB3aGF0IHdlIGhhdmUgYWxyZWFkeSBkb25lDQo+IHdpdGggdGhlIE9BdXRoIFNB U0wgZHJhZnQgd2hlcmUgd2UgZGVmaW5lZCBhIG5ldyB3YXkgdG8gY29udmV5IHRoZSBhY2Nlc3MN Cj4gdG9rZW4gZnJvbSB0aGUgU0FTTCBjbGllbnQgdG8gdGhlIFNBU0wgc2VydmVyLg0KPiANCj4g SG93IGRpZCB0aGUgYXV0aG9ycyBzb2x2ZSB0aGF0IHByb2JsZW0/IFRoZXkgcHJldHR5IG11Y2gg ZGlkIHdoYXQgSSBqdXN0DQo+IGV4cGxhaW5lZC4gU2luY2UgVFVSTiBkb2VzIG5vdCB1c2UgRFRM UyAob3IgVExTKSB0aGUgcHJvb2Ytb2YtcG9zc2Vzc2lvbg0KPiBzZWN1cml0eSB3b3JrIHdlIGFy ZSBkb2luZyBiZWNvbWVzIHJlbGV2YW50IChuYW1lbHkgdGhlIHN5bW1ldHJpYyBrZXktDQo+IGJh c2VkIHBhcnQpLg0KDQpZZXMsIHRoZSBjb21tdW5pY2F0aW9uIGIvdyBUVVJOIGNsaWVudCBhbmQg c2VydmVyIG1heSBvciBtYXkgbm90IHVzZSAoRClUTFMsIGhlbmNlIA0KcHJvb2Ytb2YtcG9zc2Vz c2lvbiBzZWN1cml0eSB3b3JrIGlzIHVzZWQuDQoNCj4gDQo+IFB1dHRpbmcgZGlzY292ZXJ5IGlu Zm9ybWF0aW9uIGluLWJhbmQgaW50byB0aGUgZXhjaGFuZ2UgaXMgYWxzbyBmaW5kICh3aGljaCBp cw0KPiB3aGF0IHdlIGRpZCBpbiB0aGUgU0FTTCBkb2N1bWVudCkuDQo+IA0KPiBJbnN0ZWFkIG9m IHVzaW5nIHRoZSBKV1QgYWNjZXNzIHRva2VuIGZvcm1hdCB0aGUgYXV0aG9ycyBoYXZlIGRlZmlu ZWQgYQ0KPiBuZXcsIGJpbmFyeSBlbmNvZGluZyB0byBrZWVwIHRoZSBzaXplIHNtYWxsZXIuIFRo ZSBPQXV0aCBmcmFtZXdvcmsgYWxsb3dzDQo+IG90aGVyIHRva2VuIGZvcm1hdHMgdG8gYmUgdXNl ZCAtIHNvIHRoYXQncyBmaW5lIGFzIHdlbGwuDQo+IChBcyBhIG1pbm9yIHJlbWFyaywgSSB3b3Vs ZCB1c2UgQUVBRCBjaXBoZXJzIGhlcmUgc2luY2UgdGhhdCdzIHdoYXQNCj4gZXZlcnlvbmUgaXMg ZG9pbmcgbm93YXlzLikNCg0KR29vZCBwb2ludCwgd2lsbCB1cGRhdGUgdGhlIGRyYWZ0IHRvIHVz ZSBBRUFELg0KDQo+IA0KPiBUd28gdGhpbmdzIHN1cnByaXNlZCBtZToNCj4gDQo+IGEpIFRoZSBz cGVjIGxlYXZlcyB0aGUgd2F5IHRvIG9idGFpbiB0aGUgYWNjZXNzIHRva2VuIHByZXR0eSBtdWNo IG9wZW4uDQo+IEEgYmlnIGJlbmVmaXQgZnJvbSB1c2luZyBPQXV0aCBpcyB0aGF0IHRoZXJlIGlz IGEgcHJvdG9jb2wgbWVjaGFuaXNtIGRlZmluZWQNCj4gZm9yIGdldHRpbmcgdGhlIGFjY2VzcyB0 b2tlbi4gWW91IGNvdWxkLCBmb3IgZXhhbXBsZSwgcmVjb21tZW5kIHVzaW5nDQo+IGF1dGhvcml6 YXRpb24gY29kZSBmbG93LiBUaGlzIGNvbmNlcm5zIHRoZSB0ZXh0IHdyaXR0ZW4gaW4gU2VjdGlv biA0Lg0KDQpVc2luZyBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBpcyBkaXNjdXNzZWQgaW4gU2Vj dGlvbiA0IG9mIHRoZSBkcmFmdC4NCg0KPHNuaXA+DQogICBPQXV0aCBpbiBbUkZDNjc0OV0gZGVm aW5lcyBmb3VyIGdyYW50IHR5cGVzLiAgVGhpcyBzcGVjaWZpY2F0aW9uIHVzZXMNCiAgIHRoZSBP QXV0aCBncmFudCB0eXBlICJJbXBsaWNpdCIgZXhwbGFpbmVkIGluIHNlY3Rpb24gMS4zLjIgb2YN CiAgIFtSRkM2NzQ5XSB3aGVyZSB0aGUgV2ViUlRDIGNsaWVudCBpcyBpc3N1ZWQgYW4gYWNjZXNz IHRva2VuIGRpcmVjdGx5Lg0KPC9zbmlwPg0KDQpBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB3ZSBh ZGQgbW9yZSBkZXRhaWxzID8NCg0KPiANCj4gYikgWW91IGRlc2NyaWJlIGEga2V5IGVzdGFibGlz aG1lbnQgc2NoZW1lIHRvIGJlIHVzZWQgYmV0d2VlbiB0aGUNCj4gcmVzb3VyY2Ugc2VydmVyIGFu ZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFdoYXQgYXNzdW1wdGlvbiBkbyB5b3UgbWFrZQ0K PiBhYm91dCB0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IGFuZCB0aGUgcmVzb3VyY2UNCj4gc2VydmVyPyBBcmUgdGhleSBzdXBwb3NlZCB0byBoYXZlIGEg YnVzaW5lc3MgcmVsYXRpb25zaGlwIG9yIHNvbWUgb3RoZXINCj4gcmVsYXRpb25zaGlwIHdpdGgg ZWFjaCBvdGhlciA/DQoNCkF1dGhvcml6YXRpb24gYW5kIFJlc291cmNlIHNlcnZlcnMgY291bGQg aGF2ZSBhIGJ1c2luZXNzIHJlbGF0aW9uc2hpcCAobG9vc2VseSBjb3VwbGVkLCBmb3IgZXhhbXBs ZSBFbnRlcnByaXNlIG5ldHdvcmsgdXNpbmcgVFVSTiBzZXJ2ZXIgcHJvdmlkZWQgYnkgdGhpcmQg cGFydHkgcHJvdmlkZXIgbGlrZSBBa2FtYWkpIG9yIGNvdWxkIGJlIGRlcGxveWVkIGluIHRoZSBz YW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbiAodGlnaHRseSBjb3VwbGVkLCBmb3IgZXhhbXBsZSBH b29nbGUgcHJvdmlkaW5nIGJvdGggV2ViUlRDIGFuZCBUVVJOIHNlcnZlcnMpDQoNCj4gDQo+IE1p bm9yIGFzcGVjdHM6DQo+IA0KPiAgKiBXb3VsZCB0aGUgVFVSTiBzZXJ2ZXIgbmFtZSByZWFsbHkg YmUgYW4gZW1haWwgYWxpa2UgYWRkcmVzcyByYXRoZXIgdGhhbg0KPiBhIFVSSSA/DQoNClllcywg Zm9yIG1vcmUgaW5mb3JtYXRpb24gcGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3ZlcnktMDANCg0KPiANCj4g ICogV291bGQgeW91IHVzZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gdG8gcHJvdmlzaW9u IHRoZSBjbGllbnQgd2l0aCB0aGUNCj4gbmVjZXNzYXJ5IHBhcmFtZXRlcj8gSXMgdGhlcmUgdGhl IGV4cGVjdGF0aW9uIHRoYXQgcmFuZG9tIGNsaWVudHMgd291bGQNCj4gd29yayB3aXRoIHJhbmRv bSBhdXRob3JpemF0aW9uIHNlcnZlcnMgPw0KDQpObywgY2xpZW50IG11c3QgYXV0aGVudGljYXRl IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChTSVAvV2ViUlRDIHNlcnZlcikgdG8gbWFr ZSBhIGNhbGwuDQoNCj4gDQo+ICAqIFdvdWxkbid0IHlvdSB3YW50IHRvIGRlZmluZSBhIHNjb3Bl IHZhbHVlIGZvciB1c2Ugd2l0aCB0aGUgVFVSTiBzZXJ2aWNlDQo+IHNvIHRoYXQgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGlzIGFibGUgdG8gcmVzdHJpY3QgdGhlIGFjY2VzcyB0b2tlbiBmb3Ig dXNlDQo+IHdpdGggVFVSTiBvbmx5Pw0KDQpUaGUgc2NvcGUgdmFsdWUgZm9yIHVzZSB3aXRoIHRo ZSBUVVJOIHNlcnZpY2UgaXMgZGVmaW5lZCBpbiBzZWN0aW9uIDQNCg0KPHNuaXA+DQogICBUaGUg c2NvcGUgb2YgdGhlIGFjY2VzcyB0b2tlbiBleHBsYWluZWQgaW4gc2VjdGlvbiAzLjMgb2YgW1JG QzY3NDldDQogICBNVVNUIGJlIFRVUk4uDQo8L3NuaXA+DQoNCj4gDQo+ICAqIENyeXB0byBhbGdv cml0aG0gbmVnb3RpYXRpb246IHdvdWxkIHlvdSBleHBlY3QgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIHRvDQo+IHRlbGwgdGhlIGNsaWVudCB3aGF0IGNyeXB0byBhbGdvcml0aG1zIHRvIHVzZSAo c2luY2UgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQo+IG5vdCBvbmx5IG5lZWRzIHRvIHNoYXJl IGEga2V5IHdpdGggdGhlIHJlc291cmNlIHNlcnZlciBidXQgYWxzbyBuZWVkcyB0byBoYXZlDQo+ IGtub3dsZWRnZSBhYm91dCB0aGUgc3VwcG9ydGVkIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcykg Pw0KDQpDdXJyZW50bHkgU1RVTiBvbmx5IHVzZXMgSE1BQy1TSEExLCBoZW5jZSBkZXRhaWxzIGFi b3V0IGF1dGhvcml6YXRpb24gc2VydmVyIHRlbGxpbmcgdGhlIGNsaWVudCBhYm91dCB0aGUgY3J5 cHRvIGFsZ29yaXRobSB0byB1c2UgaXMgbm90IGV4cGxpY2l0bHkgbWVudGlvbmVkIGluIHRoZSBk cmFmdC4NCg0KPiANCj4gICogSW4geW91ciBUVVJOIDwtPiBPQXV0aCB0ZXJtaW5vbG9neSBtYXBw aW5nIHlvdSBzYXkgdGhhdCB0aGUgcmVzb3VyY2UNCj4gb3duZXIgY29ycmVzcG9uZHMgdG8gdGhl IFJUQ1dlYiBzZXJ2ZXIuIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHRydWUuIFRoZQ0KPiByZXNvdXJj ZSBvd25lciBpcyB0aGUgdXNlciBidXQgSSBiZWxpZXZlIHlvdSBhcmUgdHJ5aW5nIHRvIHNheSB0 aGF0IHRoZSB1c2VyDQo+IGdyYW50cyBhdXRob3JpemF0aW9uIGltcGxpY2l0bHkgYnkgbWFraW5n IGEgV2ViUlRDIGNhbGwuDQoNClRoZSByZXNvdXJjZSBvd25lciBpcyB0aGUgV2ViUlRDIHNlcnZl ci4gV2hlbiBjbGllbnQgbWFrZXMgYSBjYWxsIHVzaW5nIHRoZSBXZWJSVEMgc2VydmVyLCBpdCBh dXRob3JpemVzIHRoZSBjbGllbnQgdG8gdXNlIHRoZSByZXNvdXJjZXMgb24gdGhlIFRVUk4gc2Vy dmVyIGZvciBhIHNwZWNpZmljIHBlcmlvZCBvZiB0aW1lLiBUaGUgdXNlciBpcyBncmFudGVkIGF1 dGhvcml6YXRpb24gaW1wbGljaXRseSBieSBtYWtpbmcgYSBXZWJSVEMgY2FsbC4NCg0KQ2hlZXJz LA0KLVRpcnUNCg0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+IA0KPiANCg0K From nobody Thu Aug 21 21:57:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BCA1A0021 for ; Thu, 21 Aug 2014 21:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-1vOnsnm4Xk for ; Thu, 21 Aug 2014 21:57:46 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1541A0027 for ; Thu, 21 Aug 2014 21:57:45 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so11826103vcb.15 for ; Thu, 21 Aug 2014 21:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=H799tMXiqUjho3she1Qz6JvNj6BY4HEiKmXvWurJouE=; b=eyGJYU13PlQGNeBpdCbYCGQyLKJUYpaV7YkqJDKM5ifoKPrfsfkkEnHIs23c9FFusM wn/gw2ZhvAXbIQH94A6SMD//SNCtkwi/25TE7ptEH062ETp+ycO+6gj6ELYSLuZif7j4 1pi3XOi4HEw8ZT0gwO2XnldAxwvu8t54yorWXfe9l8dsIwnvB/tNo7YAy88NpjDV8sf+ TQ5vIA+rIRfB6wteGJdpMGpj4MzNF+LtCqPdBDxpdsJhfDNWvO8n0qF3Sjsb5UL2fcX8 aNNZ3nfdQTsDJJ24DMmewQwJgwrpjQ+8Tl98KGoVhsst5iv1joPaxgguQQI4Olr7BDKc Z6rQ== 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-type; bh=H799tMXiqUjho3she1Qz6JvNj6BY4HEiKmXvWurJouE=; b=e+p9sZsqs1HIG9ipkDZFkBiZ3tCQeDQQQIrjQ539CgtQoi5vUOcbvEeWxS+ZTY5LwY BqncNOsg25d1L8f/MPJd+S339pMojHN5w9CcNW7lMG2T2WgUzX4haRpjNJLyEidRUAXP ZT2dgl+ff4k5BOqx85wW/EXh0gljnhAbwvqviSPWpQXA4H8DcKCm12rOreTXvH0h7E05 R07WZKlB4dz4NQdAhFm3y3N1VjZdgiUzeV9w8WpwYyK3t++j7spBWsr6Hh3SpySvnnKC 7D4wsk2C38XyjWszpgk8IGgyD0M0n1Ju+rcfxhgdNuMlOk55r0iEJXzJM0KbbinpCvIY u5Qg== X-Gm-Message-State: ALoCoQmFUhcMR+4tMTfV8JYhgvPbtrMx9mHGeBPjbfsGiiy/ZeiCc135msXX4UY2/ayHHlJvEQ6x X-Received: by 10.52.129.200 with SMTP id ny8mr1931482vdb.27.1408683464996; Thu, 21 Aug 2014 21:57:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Thu, 21 Aug 2014 21:57:24 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Thu, 21 Aug 2014 21:57:24 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=bcaec51dd27f885fdf050130adc2 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6Gn4gJcakC2xG4XoQvx7RBqHUTk Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 04:57:47 -0000 --bcaec51dd27f885fdf050130adc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > -----Original Message----- > > From: Tirumaleswar Reddy (tireddy) > > Sent: Monday, August 18, 2014 9:17 PM > > To: 'Simon Perreault' > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; > > tram@ietf.org > > Subject: RE: [tram] TURN and fragmentation > > > > > -----Original Message----- > > > From: Simon Perreault [mailto:sperreault@jive.com] > > > Sent: Monday, August 18, 2014 8:59 PM > > > To: Tirumaleswar Reddy (tireddy) > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; > > > tram@ietf.org > > > Subject: Re: [tram] TURN and fragmentation > > > > > > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) > > > wrote: > > > > Yes, I am referring to STUN fragmentation. > > > > > > Got it, thanks. > > > > > > So, what's your idea, in detail ? > > > > I have not yet figured out all the details, at high level thinking the > problem > > can be solved similar to way fragmentation is handled in EAP-TLS > > (http://tools.ietf.org/html/rfc5216#section-2.1.5). > > Thinking aloud. STUN fragmentation problem can be solved by the following > approach: > [1] Introduce a new STUN FRAGMENT attribute which carries the > fragmentation details like (M: More fragments: which is set on all > fragments but the last fragment), S (Fragmentation start), Identifier fo= r > sequencing etc.). > [2] STUN attribute that would be subjected to fragmentation should be > placed after the STUN FRAGMENT attribute. > [3] TURN server uses a new STUN attribute let=E2=80=99s say ACK to signal= back to > the client that it received the fragment by signaling back the Identifier > it received in request. > [4] Once the final fragment is received, TURN server merges the fragments= , > validates the STUN message and responds back to the client. > While I'm sure something like that would work, it seems pretty complicated and AFAIK there is no use case that requires it at the moment. I think we should save this for later, as opposed to solving it in turn-bis. --bcaec51dd27f885fdf050130adc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) <tir= eddy@cisco.com> wrote:
> -----Original Message--= ---
> From: Tirumaleswar Reddy (tireddy)
> Sent: Monday, August 18, 2014 9:17 PM
> To: 'Simon Perreault'
> Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;
> tram@ietf.org
> Subject: RE: [tram] TURN and fragmentation
>
> > -----Original Message-----
> > From: Simon Perreault [mailto:sperreault@jive.com]
> > Sent: Monday, August 18, 2014 8:59 PM
> > To: Tirumaleswar Reddy (tireddy)
> > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;<= br> > > tram@ietf.org
> > Subject: Re: [tram] TURN and fragmentation
> >
> > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) > > <tireddy@cisco.com>= ; wrote:
> > > Yes, I am referring to STUN fragmentation.
> >
> > Got it, thanks.
> >
> > So, what's your idea, in detail ?
>
> I have not yet figured out all the details, at high level thinking the= problem
> can be solved similar to way fragmentation is handled in EAP-TLS
> (http://tools.ietf.org/html/rfc5216#section-2.1.5).

Thinking aloud. STUN fragmentation problem can be solved by the follo= wing approach:
[1] Introduce a new STUN FRAGMENT attribute which carries the fragmentation= details like (M: More fragments: which is set on all fragments but the las= t fragment),=C2=A0 S (Fragmentation start), Identifier for sequencing etc.)= .
[2] STUN attribute that would be subjected to fragmentation should be place= d after the STUN FRAGMENT attribute.
[3] TURN server uses a new STUN attribute let=E2=80=99s say ACK to signal b= ack to the client that it received the fragment by signaling back the Ident= ifier it received in request.
[4] Once the final fragment is received, TURN server merges the fragments, = validates the STUN message and responds back to the client.

While I'm sure something like that would work, it = seems pretty complicated and AFAIK there is no use case that requires it at= the moment. I think we should save this for later, as opposed to solving i= t in turn-bis.
--bcaec51dd27f885fdf050130adc2-- From nobody Thu Aug 21 22:06:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E261A0027 for ; Thu, 21 Aug 2014 22:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyQhGtznUhA7 for ; Thu, 21 Aug 2014 22:05:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F309C1A002A for ; Thu, 21 Aug 2014 22:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13024; q=dns/txt; s=iport; t=1408683959; x=1409893559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EyE7/TS6LVyHDK37wrOv/ZP37LYFORLThdSPn0g0ZT8=; b=J/q4jv1TOJm6xlEeXcuqAW9fVhuZw6NhRaH4ipb8em/2e6iZQWQvrKYi rrIZaMdWe512Q7CN8NV3tOO1aH2zaBIhVtZRsS5wJPRkD2wsmHfJUW5Ax EQ6HI46TJxVUBBYfc3v8I8IQByeWD9cjKbtzon2aKBwJoWmrEXKZ6HlG9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAIbP9lOtJA2F/2dsb2JhbABZgkdGU1cEgnjIAYFjh04BGXcWd4QDAQEBAwEjCjoSBQcEAgEIDgMEAQEBCh0DAgICMBQJCAEBBA4FCIgyCA2uY5URF48bFhsGAQaCczaBHQWFBAKMH4QpiFCTM4NebAEBgQYkHIEHAQEB X-IronPort-AV: E=Sophos; i="5.04,378,1406592000"; d="scan'208,217"; a="71412239" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP; 22 Aug 2014 05:05:44 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7M55iDj029898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 05:05:44 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 00:05:44 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] TURN and fragmentation Thread-Index: Ac+7jhywuv5uhwsYToWrzO8B1UwDZgCYVwwAAAph/mA= Date: Fri, 22 Aug 2014 05:05:43 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A283198ED@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.87] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A283198EDxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/PPZDUiDhaAe77XRanm3nWgpdZ_0 Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:06:02 -0000 --_000_913383AAA69FF945B8F946018B75898A283198EDxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFtUUl0NCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xl LmNvbV0NClNlbnQ6IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDEwOjI3IEFNDQpUbzogVGlydW1h bGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IFNpbW9uIFBlcnJlYXVsdDsgUHJhc2hhbnRoIFBh dGlsIChwcmFzcGF0aSk7IEFsYW4gSm9obnN0b247IHRyYW1AaWV0Zi5vcmc7IEJyYW5kb24gV2ls bGlhbXMNClN1YmplY3Q6IFJlOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21lbnRhdGlvbg0KDQoNCg0K T24gVHVlLCBBdWcgMTksIDIwMTQgYXQgMjoxNSBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KSA8dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRpcnVtYWxlc3dhciBSZWRk eSAodGlyZWRkeSkNCj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgOToxNyBQTQ0KPiBU bzogJ1NpbW9uIFBlcnJlYXVsdCcNCj4gQ2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBC cmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5zdG9uOw0KPiB0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSRTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRp b24NCj4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFNpbW9uIFBl cnJlYXVsdCBbbWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb208bWFpbHRvOnNwZXJyZWF1bHRAaml2 ZS5jb20+XQ0KPiA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDg6NTkgUE0NCj4gPiBU bzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+IENjOiBQcmFzaGFudGggUGF0aWwg KHByYXNwYXRpKTsgQnJhbmRvbiBXaWxsaWFtczsgQWxhbiBKb2huc3RvbjsNCj4gPiB0cmFtQGll dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gVFVS TiBhbmQgZnJhZ21lbnRhdGlvbg0KPiA+DQo+ID4gT24gTW9uLCBBdWcgMTgsIDIwMTQgYXQgMTE6 MjcgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiA8dGlyZWRkeUBjaXNjby5j b208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQo+ID4gPiBZZXMsIEkgYW0gcmVm ZXJyaW5nIHRvIFNUVU4gZnJhZ21lbnRhdGlvbi4NCj4gPg0KPiA+IEdvdCBpdCwgdGhhbmtzLg0K PiA+DQo+ID4gU28sIHdoYXQncyB5b3VyIGlkZWEsIGluIGRldGFpbCA/DQo+DQo+IEkgaGF2ZSBu b3QgeWV0IGZpZ3VyZWQgb3V0IGFsbCB0aGUgZGV0YWlscywgYXQgaGlnaCBsZXZlbCB0aGlua2lu ZyB0aGUgcHJvYmxlbQ0KPiBjYW4gYmUgc29sdmVkIHNpbWlsYXIgdG8gd2F5IGZyYWdtZW50YXRp b24gaXMgaGFuZGxlZCBpbiBFQVAtVExTDQo+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM1MjE2I3NlY3Rpb24tMi4xLjUpLg0KVGhpbmtpbmcgYWxvdWQuIFNUVU4gZnJhZ21lbnRhdGlv biBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQgYnkgdGhlIGZvbGxvd2luZyBhcHByb2FjaDoNClsxXSBJ bnRyb2R1Y2UgYSBuZXcgU1RVTiBGUkFHTUVOVCBhdHRyaWJ1dGUgd2hpY2ggY2FycmllcyB0aGUg ZnJhZ21lbnRhdGlvbiBkZXRhaWxzIGxpa2UgKE06IE1vcmUgZnJhZ21lbnRzOiB3aGljaCBpcyBz ZXQgb24gYWxsIGZyYWdtZW50cyBidXQgdGhlIGxhc3QgZnJhZ21lbnQpLCAgUyAoRnJhZ21lbnRh dGlvbiBzdGFydCksIElkZW50aWZpZXIgZm9yIHNlcXVlbmNpbmcgZXRjLikuDQpbMl0gU1RVTiBh dHRyaWJ1dGUgdGhhdCB3b3VsZCBiZSBzdWJqZWN0ZWQgdG8gZnJhZ21lbnRhdGlvbiBzaG91bGQg YmUgcGxhY2VkIGFmdGVyIHRoZSBTVFVOIEZSQUdNRU5UIGF0dHJpYnV0ZS4NClszXSBUVVJOIHNl cnZlciB1c2VzIGEgbmV3IFNUVU4gYXR0cmlidXRlIGxldOKAmXMgc2F5IEFDSyB0byBzaWduYWwg YmFjayB0byB0aGUgY2xpZW50IHRoYXQgaXQgcmVjZWl2ZWQgdGhlIGZyYWdtZW50IGJ5IHNpZ25h bGluZyBiYWNrIHRoZSBJZGVudGlmaWVyIGl0IHJlY2VpdmVkIGluIHJlcXVlc3QuDQpbNF0gT25j ZSB0aGUgZmluYWwgZnJhZ21lbnQgaXMgcmVjZWl2ZWQsIFRVUk4gc2VydmVyIG1lcmdlcyB0aGUg ZnJhZ21lbnRzLCB2YWxpZGF0ZXMgdGhlIFNUVU4gbWVzc2FnZSBhbmQgcmVzcG9uZHMgYmFjayB0 byB0aGUgY2xpZW50Lg0KDQpXaGlsZSBJJ20gc3VyZSBzb21ldGhpbmcgbGlrZSB0aGF0IHdvdWxk IHdvcmssIGl0IHNlZW1zIHByZXR0eSBjb21wbGljYXRlZCBhbmQgQUZBSUsgdGhlcmUgaXMgbm8g dXNlIGNhc2UgdGhhdCByZXF1aXJlcyBpdCBhdCB0aGUgbW9tZW50LiBJIHRoaW5rIHdlIHNob3Vs ZCBzYXZlIHRoaXMgZm9yIGxhdGVyLCBhcyBvcHBvc2VkIHRvIHNvbHZpbmcgaXQgaW4gdHVybi1i aXMuDQoNCltUUl0gQWdyZWVkLCB0aGlzIHByb3Bvc2FsIGNhbWUgdXAgYXMgcGFydCBvZiBkaXNj dXNzaW9uIHRoYXQgaXQgd291bGQgc29sdmUgdGhlIGZyYWdtZW50YXRpb24gcHJvYmxlbSBmb3Ig T1JJR0lOLiBBZnRlciBjb21tZW50cyBmcm9tIE1hcnRpbiwgdGhlcmUgaXMgbm8gdXNlIGNhc2Ug dGhhdCByZXF1aXJlcyB0aGlzIHByb2JsZW0gdG8gYmUgc29sdmVkIGltbWVkaWF0ZWx5Lg0KDQot VGlydQ0K --_000_913383AAA69FF945B8F946018B75898A283198EDxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFtUUl08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0aSBb bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEF1 Z3VzdCAyMiwgMjAxNCAxMDoyNyBBTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gU2ltb24gUGVycmVhdWx0OyBQcmFzaGFudGggUGF0 aWwgKHByYXNwYXRpKTsgQWxhbiBKb2huc3RvbjsgdHJhbUBpZXRmLm9yZzsgQnJhbmRvbiBXaWxs aWFtczxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAxOSwgMjAxNCBhdCAyOjE1IEFNLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRk eSk8YnI+DQomZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDk6MTcgUE08YnI+DQom Z3Q7IFRvOiAnU2ltb24gUGVycmVhdWx0Jzxicj4NCiZndDsgQ2M6IFByYXNoYW50aCBQYXRpbCAo cHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5zdG9uOzxicj4NCiZndDsgPGEg aHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPiZndDsgU3ViamVjdDogUkU6IFt0cmFtXSBUVVJOIGFuZCBmcmFnbWVudGF0 aW9uPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsgJmd0OyBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzo8YSBocmVmPSJtYWls dG86c3BlcnJlYXVsdEBqaXZlLmNvbSI+c3BlcnJlYXVsdEBqaXZlLmNvbTwvYT5dPGJyPg0KJmd0 OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDg6NTkgUE08YnI+DQomZ3Q7ICZn dDsgVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQomZ3Q7ICZndDsgQ2M6IFBy YXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5zdG9u Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFt0cmFtXSBUVVJOIGFuZCBmcmFn bWVudGF0aW9uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIE1vbiwgQXVnIDE4LCAy MDE0IGF0IDExOjI3IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KJmd0OyAm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iPnRpcmVkZHlAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgWWVzLCBJIGFtIHJlZmVycmlu ZyB0byBTVFVOIGZyYWdtZW50YXRpb24uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEdv dCBpdCwgdGhhbmtzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTbywgd2hhdCdzIHlv dXIgaWRlYSwgaW4gZGV0YWlsID88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGhhdmUgbm90IHlldCBm aWd1cmVkIG91dCBhbGwgdGhlIGRldGFpbHMsIGF0IGhpZ2ggbGV2ZWwgdGhpbmtpbmcgdGhlIHBy b2JsZW08YnI+DQomZ3Q7IGNhbiBiZSBzb2x2ZWQgc2ltaWxhciB0byB3YXkgZnJhZ21lbnRhdGlv biBpcyBoYW5kbGVkIGluIEVBUC1UTFM8YnI+DQomZ3Q7ICg8YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM1MjE2I3NlY3Rpb24tMi4xLjUiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjE2I3NlY3Rpb24tMi4xLjU8L2E+KS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpbmtpbmcgYWxvdWQuIFNU VU4gZnJhZ21lbnRhdGlvbiBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQgYnkgdGhlIGZvbGxvd2luZyBh cHByb2FjaDo8YnI+DQpbMV0gSW50cm9kdWNlIGEgbmV3IFNUVU4gRlJBR01FTlQgYXR0cmlidXRl IHdoaWNoIGNhcnJpZXMgdGhlIGZyYWdtZW50YXRpb24gZGV0YWlscyBsaWtlIChNOiBNb3JlIGZy YWdtZW50czogd2hpY2ggaXMgc2V0IG9uIGFsbCBmcmFnbWVudHMgYnV0IHRoZSBsYXN0IGZyYWdt ZW50KSwmbmJzcDsgUyAoRnJhZ21lbnRhdGlvbiBzdGFydCksIElkZW50aWZpZXIgZm9yIHNlcXVl bmNpbmcgZXRjLikuPGJyPg0KWzJdIFNUVU4gYXR0cmlidXRlIHRoYXQgd291bGQgYmUgc3ViamVj dGVkIHRvIGZyYWdtZW50YXRpb24gc2hvdWxkIGJlIHBsYWNlZCBhZnRlciB0aGUgU1RVTiBGUkFH TUVOVCBhdHRyaWJ1dGUuPGJyPg0KWzNdIFRVUk4gc2VydmVyIHVzZXMgYSBuZXcgU1RVTiBhdHRy aWJ1dGUgbGV04oCZcyBzYXkgQUNLIHRvIHNpZ25hbCBiYWNrIHRvIHRoZSBjbGllbnQgdGhhdCBp dCByZWNlaXZlZCB0aGUgZnJhZ21lbnQgYnkgc2lnbmFsaW5nIGJhY2sgdGhlIElkZW50aWZpZXIg aXQgcmVjZWl2ZWQgaW4gcmVxdWVzdC48YnI+DQpbNF0gT25jZSB0aGUgZmluYWwgZnJhZ21lbnQg aXMgcmVjZWl2ZWQsIFRVUk4gc2VydmVyIG1lcmdlcyB0aGUgZnJhZ21lbnRzLCB2YWxpZGF0ZXMg dGhlIFNUVU4gbWVzc2FnZSBhbmQgcmVzcG9uZHMgYmFjayB0byB0aGUgY2xpZW50LjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgSSdtIHN1cmUgc29t ZXRoaW5nIGxpa2UgdGhhdCB3b3VsZCB3b3JrLCBpdCBzZWVtcyBwcmV0dHkgY29tcGxpY2F0ZWQg YW5kIEFGQUlLIHRoZXJlIGlzIG5vIHVzZSBjYXNlIHRoYXQgcmVxdWlyZXMgaXQgYXQgdGhlIG1v bWVudC4gSSB0aGluayB3ZSBzaG91bGQgc2F2ZSB0aGlzIGZvciBsYXRlciwgYXMgb3Bwb3NlZCB0 byBzb2x2aW5nIGl0IGluIHR1cm4tYmlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bVFJdIEFncmVlZCwgdGhpcyBwcm9wb3NhbCBj YW1lIHVwIGFzIHBhcnQgb2YgZGlzY3Vzc2lvbiB0aGF0IGl0IHdvdWxkIHNvbHZlIHRoZSBmcmFn bWVudGF0aW9uIHByb2JsZW0gZm9yIE9SSUdJTi4gQWZ0ZXIgY29tbWVudHMgZnJvbSBNYXJ0aW4s IHRoZXJlIGlzIG5vIHVzZQ0KIGNhc2UgdGhhdCByZXF1aXJlcyB0aGlzIHByb2JsZW0gdG8gYmUg c29sdmVkIGltbWVkaWF0ZWx5LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A283198EDxmbrcdx10ciscoc_-- From nobody Thu Aug 21 22:10:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602171A0026 for ; Thu, 21 Aug 2014 22:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dn7HEyp_Cf1b for ; Thu, 21 Aug 2014 22:10:01 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764081A0028 for ; Thu, 21 Aug 2014 22:10:01 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so11855512vcb.37 for ; Thu, 21 Aug 2014 22:10:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+SIXyJYrVFspd7vPVMCxWKiYv7OtkKwxpyhJzU90pSA=; b=NUsK5Agh9kgMB/VKyEJCSip45RJB9jslizH6rLS1GgkJFXN9LN4L/+jOFKlFLQspQA Y+jvQkxLL/MdXW6jxCIZEu0nImLdBR5GjwXtOB236f/RshN/xvgbDWIJJeiG9Jentk+K rFCfVNGaGUU//x6rJBgM+qpzhoITenkapBuVDFsj6nt7UCRJhPeJIDmW0fXIR4YikNiJ VikA+ngli3E/ziEs0eCxeqaEF3hxXBhnJGo07mQSwc18pzqIOo92d6Z6OpR++3ZfhmHu Qyhvux6gEU+KT7J3D0GY3s3864jq3C/7CWFCEm3TaKlMDcVKNu42kN19rglEGhN0T5VP IuaA== 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-type; bh=+SIXyJYrVFspd7vPVMCxWKiYv7OtkKwxpyhJzU90pSA=; b=NXUPLZrRSESf4S/6k6vdLaPeryaCbU5eE+lsEBhNBUZRBWwVTZ3GMlcBKisdisMesq cZD/rH2udAUhKbmynsyabk3C3vJjbTEKJb6FJ9uIRRj4GKMYN+xQ/cEEwLwz9syeOeJT iPtrVLn+bBUNvtHimRmMIYXnavM69jeRsKDmY5zmzPWF4eGNyq/v0yucEif99toxbgxN Nc9g4uBjLEXLhx1WEryO0IkU/Uoaox77GGL2CzL7VCNF3a29dyjdlRaF5MMJ0l7iGN03 fEE3CR6xKTqrUyUjzJHSZ0GfCRwVePv8UOt6wGJIPMTRVwwF7RJVm9RcRX5S50surHaC uX9g== X-Gm-Message-State: ALoCoQlgi+3nT2MZkZMRR5Tfqe3clJJljpSFhmVGp7pjWzeu7yq2/D5HdcYtbZC5hmEitDD/w37k X-Received: by 10.220.172.8 with SMTP id j8mr18643vcz.32.1408684200442; Thu, 21 Aug 2014 22:10:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Thu, 21 Aug 2014 22:09:40 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Thu, 21 Aug 2014 22:09:40 -0700 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=001a11c3678c5e5c22050130d904 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Ni2uOyFcjI0aroNnN9wzRrDO6yM Cc: Martin Thomson , "tram@ietf.org" Subject: Re: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:10:04 -0000 --001a11c3678c5e5c22050130d904 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 11:41 AM, Alan Johnston wrote: > Martin, > > Thanks for doing this review. My comments are below. Hopefully others > will also weigh in on the issues you raise. > > - Alan - > > > On Wed, Aug 20, 2014 at 1:48 PM, Martin Thomson > wrote: > >> I've read this through and have some comments: >> >> Definition of origin: >> This document uses a more expansive definition than the one in RFC >> 6454. While it appears that this is consistent, I think that this >> needs to be made more prominently. >> >> > That is a very good point to be made in the introduction and perhaps even > the abstract. > > >> And given that RFC 6454 is a relatively large document (20 pages), I'm >> a little concerned that the definition for SIP and XMPP origins is a >> little lean. At a minimum, I think that you need to identify what >> components from the respective BNF definitions of XMPP and SIP URIs >> are kept and what are removed. >> > > Right. The XMPP does mention parts of the ABNF and gives an example. We > should add the same for SIP. > > >> Multiple origins: >> I'm not sure that you really need to concern yourself with multiple >> origins. The ability to carry multiple Origin header fields in HTTP >> is bound to the way that browsers fetch resources. This can sometimes >> mean that a resource is fetched by multiple origins (tabs, frames, >> windows, etc...) at the same time. Even then, it is relatively rare >> that this will happen. >> >> In the context of WebRTC, I can't think of a single case where origin >> will need to be doubled. Any single binding request will be at the >> behest of a single origin; and while a TURN allocation might be shared >> between multiple origins, that will only happen because it's the >> browser acting on its own writ, not on behalf on any origin. >> Individual channels might need an origin binding in that case. >> > > Interesting - I had thought, incorrectly it seems, that if a page from one > domain fetched a script from another domain that accessed a resource, that > the HTTP origin would include both domains. The case of a resource fetched > at the same time by multiple origins doesn't seem to apply to WebRTC. Each > of these origins would correspond to a different Peer Connection. I don't > think a browser would ever share STUN bindings or TURN allocations across > different Peer Connections. If we can rule out this behavior, then perhaps > the text on multiple origins can just say that it can't happen. > Yes, I think this would never happen; each PC has its own state, and sharing this state across origins would be problematic, to say the least. > > >> >> In the other contexts, it seems obvious that similar constraints apply. >> >> > Since we are defining it for SIP and XMPP, we can just make it a MUST NOT. > > >> Privacy: >> The privacy section talks about protection in transit, but does not >> talk about the ability of a STUN or TURN server itself to learn about >> communication usage, something it would not normally be able to >> obtain. Some text on this would be useful, since these parties were >> previously either entirely supplemental to communication, or only >> involved in the peer-to-peer communications. I'm sure that this >> information could be turned into money, so there has to be at least >> some privacy implications there. >> > > That is a good point. For a STUN server, this is new information, not > otherwise available. For a TURN server, if realm doesn't map 1:1 to > origin, then this also provides new information. I will propose some text > on this. > Note that this is in many ways similar to the SOFTWARE attribute, which in the pre-WebRTC days provided similar information about usage. Of course, in the WebRTC case, the TURN server will be specified by the application, so the application at least knows who will have access to this data. > > >> >> Size: >> The recommended limit on size is a little odd. It should be >> impossible to generate an origin that exceeds this number. I would >> leave the advice at the point were the maximum size is noted and the >> potential this has to cause fragmentation. >> >> > If we can do away with multiple origins, then I'm fine with this. > > >> TLS SNI: >> I found the introduction to be a little long and wordy, perhaps >> excessively justified. The discussion of SNI might be appropriate for >> convincing the working group of the need for this solution over >> something based on SNI, I found this both completely obvious (of >> course SNI doesn't work) and actually somewhat non-sequitur. I think >> that this paragraph (at least) could be removed. >> > > I hadn't read the Introduction in a while, and I agree. I can write a > much better introduction. > > >> >> Redundant text: >> To ensure backwards compatibility with [RFC3489], the ORIGIN >> attribute is padded to ensure its length is a multiple of 4 octets. >> > > Since this is already a MUST in RFC 5389, this is redundant and can be > removed. > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a11c3678c5e5c22050130d904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 11:41 AM, Alan Johnston &= lt;alan.b.jo= hnston@gmail.com> wrote:
Martin,

= Thanks for doing this review. =C2=A0My comments are below. =C2=A0Hopefully = others will also weigh in on the issues you raise.

- Alan -


On Wed, Aug 20, 2014 at = 1:48 PM, Martin Thomson <martin.thomson@gmail.com> wr= ote:
I've read this through and have some comments:

Definition of origin:
This document uses a more expansive definition than the one in RFC
6454.=C2=A0 While it appears that this is consistent, I think that this
needs to be made more prominently.


That is a very good point to be = made in the introduction and perhaps even the abstract.
=C2=A0
And given that RFC 6454 is a relatively large document (20 pages), I'm<= br> a little concerned that the definition for SIP and XMPP origins is a
little lean.=C2=A0 At a minimum, I think that you need to identify what
components from the respective BNF definitions of XMPP and SIP URIs
are kept and what are removed.

Ri= ght. =C2=A0The XMPP does mention parts of the ABNF and gives an example. = =C2=A0We should add the same for SIP.

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Multiple origins:
I'm not sure that you really need to concern yourself with multiple
origins.=C2=A0 The ability to carry multiple Origin header fields in HTTP is bound to the way that browsers fetch resources.=C2=A0 This can sometimes=
mean that a resource is fetched by multiple origins (tabs, frames,
windows, etc...) at the same time.=C2=A0 Even then, it is relatively rare that this will happen.

In the context of WebRTC, I can't think of a single case where origin will need to be doubled.=C2=A0 Any single binding request will be at the behest of a single origin; and while a TURN allocation might be shared
between multiple origins, that will only happen because it's the
browser acting on its own writ, not on behalf on any origin.
Individual channels might need an origin binding in that case.

Interesting - I had thought, incorrectly it s= eems, that if a page from one domain fetched a script from another domain t= hat accessed a resource, that the HTTP origin would include both domains. = =C2=A0The case of a resource fetched at the same time by multiple origins d= oesn't seem to apply to WebRTC. =C2=A0Each of these origins would corre= spond to a different Peer Connection. =C2=A0I don't think a browser wou= ld ever share STUN bindings or TURN allocations across different Peer Conne= ctions. =C2=A0If we can rule out this behavior, then perhaps the text on mu= ltiple origins can just say that it can't happen.

Yes, I think this would = never happen; each PC has its own state, and sharing this state across orig= ins would be problematic, to say the least.
=C2=A0

In the other contexts, it seems obvious that similar constraints apply.


Since we are defining it for SIP= and XMPP, we can just make it a MUST NOT.
=C2=A0=
Privacy:
The privacy section talks about protection in transit, but does not
talk about the ability of a STUN or TURN server itself to learn about
communication usage, something it would not normally be able to
obtain.=C2=A0 Some text on this would be useful, since these parties were previously either entirely supplemental to communication, or only
involved in the peer-to-peer communications.=C2=A0 I'm sure that this information could be turned into money, so there has to be at least
some privacy implications there.

= That is a good point. =C2=A0For a STUN server, this is new information, not= otherwise available. =C2=A0For a TURN server, if realm doesn't map 1:1= to origin, then this also provides new information. =C2=A0I will propose s= ome text on this.

Note that this is in man= y ways similar to the SOFTWARE attribute, which in the pre-WebRTC days prov= ided similar information about usage. Of course, in the WebRTC case, the TU= RN server will be specified by the application, so the application at least= knows who will have access to this data.
=
=C2=A0

Size:
The recommended limit on size is a little odd.=C2=A0 It should be
impossible to generate an origin that exceeds this number.=C2=A0 I would leave the advice at the point were the maximum size is noted and the
potential this has to cause fragmentation.


If we can do away with multiple = origins, then I'm fine with this.
=C2=A0
TLS SNI:
I found the introduction to be a little long and wordy, perhaps
excessively justified.=C2=A0 The discussion of SNI might be appropriate for=
convincing the working group of the need for this solution over
something based on SNI, I found this both completely obvious (of
course SNI doesn't work) and actually somewhat non-sequitur.=C2=A0 I th= ink
that this paragraph (at least) could be removed.

<= /div>
I hadn't read the Introduction in a while, and I agree.= =C2=A0I can write a much better introduction.
= =C2=A0

Redundant text:
=C2=A0 =C2=A0To ensure backwards compatibility with [RFC3489], the ORIGIN =C2=A0 =C2=A0attribute is padded to ensure its length is a multiple of 4 oc= tets.

Since this is= already a MUST in RFC 5389, this is redundant and can be removed.




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


--001a11c3678c5e5c22050130d904-- From nobody Thu Aug 21 22:28:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091C81A0009 for ; Thu, 21 Aug 2014 22:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7LymYK61sByu for ; Thu, 21 Aug 2014 22:28:01 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B691A002A for ; Thu, 21 Aug 2014 22:28:01 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so9648483wib.8 for ; Thu, 21 Aug 2014 22:27:59 -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:content-type; bh=eWdfFRHv3NpmsbKVFJHEkVhJCht20/eQ9oswJu/4quY=; b=ZMzZrAlEpZiyLASNNmnIEmDgW2d9200CR5CBOiRzEnP5a87F7/Hc3igu3mVKuW8uFq KOMtGJAwCbhLJ69uLrle3LnfIl+6TCRs9jeOG0dRVuojtCX2YAUWz0Dl21QCsJYt4siC qO+TOIgK/6nmIiSf6aWDNiAtreTH2aD8uOoSP6vtj2t6LxmQhhG3O+A9rsDpFJW5XACa vagllCRDzwJvUcbzhFawBu70dLQtvj3sopY/5s66RVTrJPhI3W8IeqD5Re3cOWtpy/4z CfAmkkrBwIjtALjBZziNlLK1/m7G8oXllnfVTpZ+0FMHRc8JZ5/5dKEcP5cC24HOF5qf f4dA== MIME-Version: 1.0 X-Received: by 10.180.182.67 with SMTP id ec3mr8633435wic.21.1408685279846; Thu, 21 Aug 2014 22:27:59 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Thu, 21 Aug 2014 22:27:59 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> Date: Thu, 21 Aug 2014 22:27:59 -0700 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b5dbcdab4a585050131190f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RF4UG2CQQ9BvSMbG0kXEog0J9Rk Cc: "Prashanth Patil \(praspati\)" , "tram@ietf.org" , Brandon Williams , "Tirumaleswar Reddy \(tireddy\)" , Simon Perreault , Alan Johnston Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 05:28:03 -0000 --047d7b5dbcdab4a585050131190f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Justin, The multiple-ORIGIN use case is not important enough to justify the invention of the whole machinery of the STUN fragmentation. Oleg On Thu, Aug 21, 2014 at 9:57 PM, Justin Uberti wrote: > > > > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> > -----Original Message----- >> > From: Tirumaleswar Reddy (tireddy) >> > Sent: Monday, August 18, 2014 9:17 PM >> > To: 'Simon Perreault' >> > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; >> > tram@ietf.org >> > Subject: RE: [tram] TURN and fragmentation >> > >> > > -----Original Message----- >> > > From: Simon Perreault [mailto:sperreault@jive.com] >> > > Sent: Monday, August 18, 2014 8:59 PM >> > > To: Tirumaleswar Reddy (tireddy) >> > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; >> > > tram@ietf.org >> > > Subject: Re: [tram] TURN and fragmentation >> > > >> > > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) >> > > wrote: >> > > > Yes, I am referring to STUN fragmentation. >> > > >> > > Got it, thanks. >> > > >> > > So, what's your idea, in detail ? >> > >> > I have not yet figured out all the details, at high level thinking the >> problem >> > can be solved similar to way fragmentation is handled in EAP-TLS >> > (http://tools.ietf.org/html/rfc5216#section-2.1.5). >> >> Thinking aloud. STUN fragmentation problem can be solved by the followin= g >> approach: >> [1] Introduce a new STUN FRAGMENT attribute which carries the >> fragmentation details like (M: More fragments: which is set on all >> fragments but the last fragment), S (Fragmentation start), Identifier f= or >> sequencing etc.). >> [2] STUN attribute that would be subjected to fragmentation should be >> placed after the STUN FRAGMENT attribute. >> [3] TURN server uses a new STUN attribute let=E2=80=99s say ACK to signa= l back to >> the client that it received the fragment by signaling back the Identifie= r >> it received in request. >> [4] Once the final fragment is received, TURN server merges the >> fragments, validates the STUN message and responds back to the client. >> > > While I'm sure something like that would work, it seems pretty complicate= d > and AFAIK there is no use case that requires it at the moment. I think we > should save this for later, as opposed to solving it in turn-bis. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b5dbcdab4a585050131190f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Justin, The multiple-ORIGIN use case is not i= mportant enough to justify the invention of the whole machinery of the STUN= fragmentation.

Oleg


On Thu, Aug 21, 2014 at 9:57 PM, Justin = Uberti <juberti@google.com> wrote:



On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswa= r Reddy (tireddy) <tireddy@cisco.com> wrote:
> -----Original Message-----
> From: Tirumaleswar Reddy (tireddy)
> Sent: Monday, August 18, 2014 9:17 PM
> To: 'Simon Perreault'
> Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;
> tram@ietf.org
> Subject: RE: [tram] TURN and fragmentation
>
> > -----Original Message-----
> > From: Simon Perreault [mailto:sperreault@jive.com]
> > Sent: Monday, August 18, 2014 8:59 PM
> > To: Tirumaleswar Reddy (tireddy)
> > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston;<= br> > > tram@ietf.org<= /a>
> > Subject: Re: [tram] TURN and fragmentation
> >
> > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) > > <tiredd= y@cisco.com> wrote:
> > > Yes, I am referring to STUN fragmentation.
> >
> > Got it, thanks.
> >
> > So, what's your idea, in detail ?
>
> I have not yet figured out all the details, at high level thinking the= problem
> can be solved similar to way fragmentation is handled in EAP-TLS
> (http://tools.ietf.org/html/rfc5216#section-2.1.5).

Thinking aloud. STUN fragmentation problem can be solved by the follo= wing approach:
[1] Introduce a new STUN FRAGMENT attribute which carries the fragmentation= details like (M: More fragments: which is set on all fragments but the las= t fragment),=C2=A0 S (Fragmentation start), Identifier for sequencing etc.)= .
[2] STUN attribute that would be subjected to fragmentation should be place= d after the STUN FRAGMENT attribute.
[3] TURN server uses a new STUN attribute let=E2=80=99s say ACK to signal b= ack to the client that it received the fragment by signaling back the Ident= ifier it received in request.
[4] Once the final fragment is received, TURN server merges the fragments, = validates the STUN message and responds back to the client.

While I'm sure something like that wou= ld work, it seems pretty complicated and AFAIK there is no use case that re= quires it at the moment. I think we should save this for later, as opposed = to solving it in turn-bis.

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


--047d7b5dbcdab4a585050131190f-- From nobody Thu Aug 21 23:56:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8051A00E8 for ; Thu, 21 Aug 2014 23:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8fjZODqIluS0 for ; Thu, 21 Aug 2014 23:56:49 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027701A00E0 for ; Thu, 21 Aug 2014 23:56:48 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so10246523wes.29 for ; Thu, 21 Aug 2014 23:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r96KsLA/5PyzWPN+5dVEnGqPUyNixa+xJGJSNiFpF8M=; b=iZGTNagJHseslCn1whWTlPOyuXCqeP6HAd7TMdAOSVh8kLTcfMUK/G7C/9n8m4cK5a 5NjIkCmPUBJ7qyhvCmqphWVtiQIw30D+HpZXvoYqznr+jAe9YRdbkw/s6eOK/svrwBSR IPYHayEufjpQngpt9q+qe2gHsXG+nezdQkev4iGe5dxX6aUHnnDcNHLrzJF+NwmFApel L2F968X0FNctUzWXI8TBJVPVd49Eh16TWnpd3Ptw5xwj4DVfvXXVvQ8ELnLQN8gXqk+W B+2LDMFxEdAS40Gx6Kue3ZHtYtn+jjU2GMOyGmMGQusMXLPiOJ4M+suTGGUFDNcnQmSz y8Tw== MIME-Version: 1.0 X-Received: by 10.180.94.234 with SMTP id df10mr27742558wib.76.1408690607633; Thu, 21 Aug 2014 23:56:47 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Thu, 21 Aug 2014 23:56:47 -0700 (PDT) Date: Thu, 21 Aug 2014 23:56:47 -0700 Message-ID: From: Oleg Moskalenko To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=f46d0444ea9f4439da050132572a Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tbyWHdCIuqkZIRueHQ_xf-nxO_g Subject: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 06:56:50 -0000 --f46d0444ea9f4439da050132572a Content-Type: text/plain; charset=UTF-8 I have the following comment: In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has to be used, because the HKDF-Expand function of length 16 does not make much sense, according to RFC 5869 section 2.3. So, I suggest to use AES_256_CBC consistently across the draft text as the default encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, anyway. Thanks Oleg --f46d0444ea9f4439da050132572a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have the following comment:

In the section 4.1.1 and= 4.1.2, the encryption algorithm AES_256_CBC has to be used, because the HK= DF-Expand function of length 16 does not make much sense, according to RFC = 5869 section 2.3.
So, I suggest to use AES_256_CBC consistently across the dr=
aft text as the default 
encryption algorithm. In the section 4.1.3 it i=
s already used as the default algorithm, 

anyway.

Thanks
Oleg

--f46d0444ea9f4439da050132572a-- From nobody Fri Aug 22 00:48:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAAA1A0111 for ; Fri, 22 Aug 2014 00:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSxxmk5FaiMi for ; Fri, 22 Aug 2014 00:48:34 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509AD1A010E for ; Fri, 22 Aug 2014 00:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6942; q=dns/txt; s=iport; t=1408693714; x=1409903314; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mf/u6onykDvaC6+/tQXb8/ms8GGmTsSjb3ZH6eaPH/U=; b=YV6UIxkDRVYJA1qjoQfeNA7C2xs6ns0+o6iVdpH+V69KbdlvOrq52RXz Tysm1Epuf1GBN0DavHhZ3zeG8D7v+bZm9hjGf98slArm/BfUqKyryElHE xSgHUMFffBPlQiGLbm8N844tYyY3Q1M9zcIvJfv7olzn2V4vI9YZg6atr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAEL19lOtJA2N/2dsb2JhbABZgkdGU1cEgnjRLQEZchZ3hAMBAQEEIwpcAgEIDgMEAQELHQMCAgIwFAkIAgQBEgiIOq54lRIXjxsWIQGCeTaBHQWPEoIToCyDXmyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,378,1406592000"; d="scan'208,217";a="349261444" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2014 07:48:33 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7M7mXml029633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 07:48:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 02:48:33 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko , "tram@ietf.org" Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPvdZLiKE/bGshdk+Ml1/4PhD66pvcPwww Date: Fri, 22 Aug 2014 07:48:32 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.52.145] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A28319AADxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8hll7KeYiTbyAELZl-cbRlYUoN8 Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 07:48:35 -0000 --_000_913383AAA69FF945B8F946018B75898A28319AADxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE9s ZWcgTW9za2FsZW5rbw0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgMTI6MjcgUE0NClRv OiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhp cmQtcGFydHktYXV0aHotMDMNCg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudDoNCkluIHRo ZSBzZWN0aW9uIDQuMS4xIGFuZCA0LjEuMiwgdGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtIEFFU18y NTZfQ0JDIGhhcyB0byBiZSB1c2VkLCBiZWNhdXNlIHRoZSBIS0RGLUV4cGFuZCBmdW5jdGlvbiBv ZiBsZW5ndGggMTYgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLCBhY2NvcmRpbmcgdG8gUkZDIDU4 Njkgc2VjdGlvbiAyLjMuDQoNClNvLCBJIHN1Z2dlc3QgdG8gdXNlIEFFU18yNTZfQ0JDIGNvbnNp c3RlbnRseSBhY3Jvc3MgdGhlIGRyYWZ0IHRleHQgYXMgdGhlIGRlZmF1bHQNCmVuY3J5cHRpb24g YWxnb3JpdGhtLiBJbiB0aGUgc2VjdGlvbiA0LjEuMyBpdCBpcyBhbHJlYWR5IHVzZWQgYXMgdGhl IGRlZmF1bHQgYWxnb3JpdGhtLA0KDQoNCmFueXdheS4NCg0KW1RSXSBUaGFua3MsIHdpbGwgdGhh dCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KLVRpcnUNCg0KVGhhbmtzDQpPbGVnDQo= --_000_913383AAA69FF945B8F946018B75898A28319AADxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+T2xlZyBNb3NrYWxlbmtvPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDEyOjI3IFBNPGJyPg0KPGI+VG86PC9iPiB0cmFtQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10 aGlyZC1wYXJ0eS1hdXRoei0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+SSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudDo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbiB0aGUgc2VjdGlvbiA0 LjEuMSBhbmQgNC4xLjIsIHRoZSBlbmNyeXB0aW9uIGFsZ29yaXRobSBBRVNfMjU2X0NCQyBoYXMg dG8gYmUgdXNlZCwgYmVjYXVzZSB0aGUgSEtERi1FeHBhbmQgZnVuY3Rpb24gb2YgbGVuZ3RoIDE2 IGRvZXMgbm90IG1ha2UgbXVjaCBzZW5zZSwgYWNjb3JkaW5nIHRvIFJGQyA1ODY5IHNlY3Rpb24g Mi4zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNvLCBJIHN1Z2dlc3Qg dG8gdXNlIEFFU18yNTZfQ0JDIGNvbnNpc3RlbnRseSBhY3Jvc3MgdGhlIGRyYWZ0IHRleHQgYXMg dGhlIGRlZmF1bHQgPGJyPmVuY3J5cHRpb24gYWxnb3JpdGhtLiBJbiB0aGUgc2VjdGlvbiA0LjEu MyBpdCBpcyBhbHJlYWR5IHVzZWQgYXMgdGhlIGRlZmF1bHQgYWxnb3JpdGhtLCA8YnI+PGJyPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5hbnl3YXkuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPltUUl0gVGhhbmtzLCB3aWxsIHRoYXQgaW4gdGhlIG5leHQgcmV2aXNpb24uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PlRoYW5rczxicj5PbGVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A28319AADxmbrcdx10ciscoc_-- From nobody Fri Aug 22 08:34:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063451A0574 for ; Fri, 22 Aug 2014 08:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 APs2FM5d-lCW for ; Fri, 22 Aug 2014 08:34:47 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3621A0336 for ; Fri, 22 Aug 2014 08:34:46 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id x48so10842220wes.33 for ; Fri, 22 Aug 2014 08:34:45 -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:content-type; bh=crlYrVS4ugAll2RCDlUXClxg9Ly3DaPLCvfDq+6gjZ0=; b=hxpB/Z35GJDCr7/JAMsRtyro5IgTbJdibN5rSo9tKzSbrcBGPPlTqaxINOoEYGhbPX XUJgWZpQgWfTajc37+ovVJYbcC3XgerWaObkcdRnALxKrd3m81lz6cti/54wSuF+NANc SGvIFwAwC03SsyM5z/y5KML4ZNh6PwKoV8JaTVzlvshQvQTHcsMWyl9mBRAUClkQsQk+ 8kJkW+rQhF5VltpZlM2YF4cRdtkfj7DwrJbrl2sf2xpRSpodYzOKAXhRtIhqAEKVuplr cECMtAz+F8g3nxWfetMI6UfGqgcKLNXIQpXEjMBKim8OrLed/jxvABZ8XRWnYnWj5OSP b6uA== MIME-Version: 1.0 X-Received: by 10.180.106.138 with SMTP id gu10mr30236473wib.21.1408721685569; Fri, 22 Aug 2014 08:34:45 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 22 Aug 2014 08:34:45 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> Date: Fri, 22 Aug 2014 08:34:45 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=e89a8f2345d3a7e82c0501399347 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3f6DeO6CNWvMk3UDfnJzWqxty7s Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:34:48 -0000 --e89a8f2345d3a7e82c0501399347 Content-Type: text/plain; charset=UTF-8 Sorry, scratch that - I take back my comment. Thanks Oleg On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg > Moskalenko > *Sent:* Friday, August 22, 2014 12:27 PM > *To:* tram@ietf.org > *Subject:* [tram] draft-ietf-tram-turn-third-party-authz-03 > > > > I have the following comment: > > In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has > to be used, because the HKDF-Expand function of length 16 does not make > much sense, according to RFC 5869 section 2.3. > > So, I suggest to use AES_256_CBC consistently across the draft text as the default > encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, > > anyway. > > [TR] Thanks, will that in the next revision. > > -Tiru > > Thanks > Oleg > > --e89a8f2345d3a7e82c0501399347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, scratch that - I take back my comment.

Thanks
Oleg


=
On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar R= eddy (tireddy) <tireddy@cisco.com> wrote:

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: tram@ietf.org=
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03<= /u>

=C2=A0

I have the following commen= t:

In the section 4.1.1 and 4.1.2, the encryption algorithm A= ES_256_CBC has to be used, because the HKDF-Expand function of length 16 do= es not make much sense, according to RFC 5869 section 2.3.= 

S=
o, I suggest to use AES_256_CBC consistently across the draft text as the d=
efault 
encryption algorithm. In the section 4.1.3 it is already used as=
 the default algorithm, 


anyway.
=
[TR] Thanks, will that in the next revision.
-Tiru=

Thanks
Oleg

--e89a8f2345d3a7e82c0501399347-- From nobody Fri Aug 22 08:37:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3C01A064E for ; Fri, 22 Aug 2014 08:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILcpPmiCDtQt for ; Fri, 22 Aug 2014 08:37:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 97E391A0337 for ; Fri, 22 Aug 2014 08:37:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E9BBB285A3; Fri, 22 Aug 2014 15:37:06 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C99182856D; Fri, 22 Aug 2014 15:37:06 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id BE7E780047; Fri, 22 Aug 2014 15:37:06 +0000 (GMT) Message-ID: <53F763A2.1000309@akamai.com> Date: Fri, 22 Aug 2014 11:37:06 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Justin Uberti , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/i3K9Sr3dfksqR8tA5me2_JuhTGo Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:37:13 -0000 On 08/22/2014 12:57 AM, Justin Uberti wrote: > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) > > wrote: > > > -----Original Message----- > > From: Tirumaleswar Reddy (tireddy) > > Sent: Monday, August 18, 2014 9:17 PM > > To: 'Simon Perreault' > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; > > tram@ietf.org > > Subject: RE: [tram] TURN and fragmentation > > > > > -----Original Message----- > > > From: Simon Perreault [mailto:sperreault@jive.com > ] > > > Sent: Monday, August 18, 2014 8:59 PM > > > To: Tirumaleswar Reddy (tireddy) > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnston; > > > tram@ietf.org > > > Subject: Re: [tram] TURN and fragmentation > > > > > > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tireddy) > > > > wrote: > > > > Yes, I am referring to STUN fragmentation. > > > > > > Got it, thanks. > > > > > > So, what's your idea, in detail ? > > > > I have not yet figured out all the details, at high level > thinking the problem > > can be solved similar to way fragmentation is handled in EAP-TLS > > (http://tools.ietf.org/html/rfc5216#section-2.1.5). > > Thinking aloud. STUN fragmentation problem can be solved by the > following approach: > [1] Introduce a new STUN FRAGMENT attribute which carries the > fragmentation details like (M: More fragments: which is set on all > fragments but the last fragment), S (Fragmentation start), > Identifier for sequencing etc.). > [2] STUN attribute that would be subjected to fragmentation should > be placed after the STUN FRAGMENT attribute. > [3] TURN server uses a new STUN attribute let’s say ACK to signal > back to the client that it received the fragment by signaling back > the Identifier it received in request. > [4] Once the final fragment is received, TURN server merges the > fragments, validates the STUN message and responds back to the client. > > > While I'm sure something like that would work, it seems pretty > complicated and AFAIK there is no use case that requires it at the > moment. I think we should save this for later, as opposed to solving it > in turn-bis. I agree that a fragmentation solution doesn't belong directly in turn-bis. That said, I think either turn-bis or stun-bis might need to provide better guidance on fragmentation. For example, the current wording limits stun messages to 548 bytes in cases where the path MTU is not yet known and the messages itself is not being used to probe the path MTU. It's easy to come up with a set of reasonable values for an allocate request (at least) that would violate this restriction, especially when you add the new origin and 3rd party auth attributes. In the rare case of a client that really does have such a small PMTU, the standards as currently published can actually prevent the client from being able to use a turn relay that relies on the new attributes without ignoring the fragmentation guidance. --Brandon -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Fri Aug 22 09:11:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E9B1A0695 for ; Fri, 22 Aug 2014 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 vyJpS778sawv for ; Fri, 22 Aug 2014 09:11:19 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0CC1A0692 for ; Fri, 22 Aug 2014 09:11:18 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so10927143wev.27 for ; Fri, 22 Aug 2014 09:11:17 -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:content-type; bh=xOrHufU/xOjD3m6Wl4BMGfYD13LzRuWJzNM/3Zulgsk=; b=rhYs9oKeGEbF5IDfQKKSioK1OdBgIFJyCZ4Ihou+z/ZoQWWmh5Fm17xMw2vFbh81Zb KioKU+sGLMdS59aShqdzikaWXajFMzwJiBnr+a5RzVxrxUm1DF3AowJfq2WiHqvTWd/7 B7EmoiYhBv/jaURkBm074Xi3OgNtogLWt/cFlQ2EznAZqs7uVPyVCXGADlr+7RETSxo8 MmI2WeGO1ZF2r+Jk6MX24RMjLTbuU/y0Dx7J0Gzk59ZBnCcLx/DIOQj46jdjrHRDK0UF Y3WSXSf4+kI7tX8o6w91TEtdEcrBMS2m0/YQGultzcPrntKHUmCpPdD4O1/1bHUMlTec mnPg== MIME-Version: 1.0 X-Received: by 10.194.5.234 with SMTP id v10mr6150674wjv.45.1408723877296; Fri, 22 Aug 2014 09:11:17 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 22 Aug 2014 09:11:17 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> Date: Fri, 22 Aug 2014 09:11:17 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b5d2fde4b024805013a16df Archived-At: http://mailarchive.ietf.org/arch/msg/tram/REyucDOMi8Y8jUce60O__Ta7uoE Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:11:20 -0000 --047d7b5d2fde4b024805013a16df Content-Type: text/plain; charset=UTF-8 But I still think that making a single algorithm (like AES_256_CBC) default across all use cases is a good idea, I just used wrong explanation for that. Oleg On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko wrote: > Sorry, scratch that - I take back my comment. > > Thanks > Oleg > > > On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg >> Moskalenko >> *Sent:* Friday, August 22, 2014 12:27 PM >> *To:* tram@ietf.org >> *Subject:* [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> >> >> I have the following comment: >> >> In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has >> to be used, because the HKDF-Expand function of length 16 does not make >> much sense, according to RFC 5869 section 2.3. >> >> So, I suggest to use AES_256_CBC consistently across the draft text as the default >> encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, >> >> anyway. >> >> [TR] Thanks, will that in the next revision. >> >> -Tiru >> >> Thanks >> Oleg >> >> > --047d7b5d2fde4b024805013a16df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But I still think that=C2=A0making a single algorithm (lik= e AES_256_CBC) default across all use cases is a good idea, I just used wro= ng explanation for that.

Oleg


On Fri, Aug 22, 2014 at 8:34 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
Sorry, scratch that - I take back my comment.

Thanks
Oleg=


On Fri, Aug 22, 2014 at 12:48 AM, Tiruma= leswar Reddy (tireddy) <tireddy@cisco.com> wrote:

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: tram@ietf.org=
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03<= /u>

=C2=A0

I have the following commen= t:

In the section 4.1.1 and 4.1.2, the encryption algorithm A= ES_256_CBC has to be used, because the HKDF-Expand function of length 16 do= es not make much sense, according to RFC 5869 section 2.3.= 

S=
o, I suggest to use AES_256_CBC consistently across the draft text as the d=
efault 
encryption algorithm. In the section 4.1.3 it is already used as=
 the default algorithm, 



anyway.
=
[TR] Thanks, will that in the next revision.
-Tiru=

Thanks
Oleg


--047d7b5d2fde4b024805013a16df-- From nobody Fri Aug 22 09:25:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63DB1A03BA for ; Fri, 22 Aug 2014 09:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHu2enuAtZpe for ; Fri, 22 Aug 2014 09:25:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 758061A00A6 for ; Fri, 22 Aug 2014 09:25:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5782; q=dns/txt; s=iport; t=1408724713; x=1409934313; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GaMbnm8Ebuj0/RXK4EPDts3pRp3aB/szymbAa6APbUE=; b=UlPO8jNrqNWI7yCLVf80pyyJu456Kf/P9GYejeIWlcU9WdugM9e69Uor y+QS2Z79jLlaRMh0DEZ/977QF8B31Z137DFePLauwsWcaPSDoChSUQhgk 7d/CttQIJPl4CRZePM+qajEmv7w+yZ0H38AAhg5UXg2wlQC+w+lgqwF/3 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAE5u91OtJV2d/2dsb2JhbABZgw1TVwSCeMlih0wBGXUWd4QDAQEBBCMRMxIMBAIBCBEEAQEBAgIGHQMCAgIwFAEICAEBBAENBQgTiCcNrz2VExeBLI1vFhsHBoJzNoEdBZEmhCmIUpM0gWQegVxsAQGBBiQcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="349585199" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2014 16:25:07 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s7MGP7Ek012555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:25:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 11:25:06 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Justin Uberti Thread-Topic: [tram] TURN and fragmentation Thread-Index: Ac+7jhywuv5uhwsYToWrzO8B1UwDZgCYVwwAABZXXQAACSnGAA== Date: Fri, 22 Aug 2014 16:25:06 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> <53F763A2.1000309@akamai.com> In-Reply-To: <53F763A2.1000309@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.254.212] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mEGxK7v2GgbL3rvyiqtaK3wKfHk Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 16:25:17 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBGcmlkYXksIEF1Z3Vz dCAyMiwgMjAxNCA5OjA3IFBNDQo+IFRvOiBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpDQo+IENjOiBTaW1vbiBQZXJyZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJh c3BhdGkpOyBBbGFuIEpvaG5zdG9uOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJh bV0gVFVSTiBhbmQgZnJhZ21lbnRhdGlvbg0KPiANCj4gDQo+IA0KPiBPbiAwOC8yMi8yMDE0IDEy OjU3IEFNLCBKdXN0aW4gVWJlcnRpIHdyb3RlOg0KPiA+IE9uIFR1ZSwgQXVnIDE5LCAyMDE0IGF0 IDI6MTUgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiA8dGlyZWRkeUBjaXNj by5jb20gPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gICAgICA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gICAgICA+IEZyb206IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCj4gPiAgICAgID4gU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIw MTQgOToxNyBQTQ0KPiA+ICAgICAgPiBUbzogJ1NpbW9uIFBlcnJlYXVsdCcNCj4gPiAgICAgID4g Q2M6IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpv aG5zdG9uOw0KPiA+ICAgICAgPiB0cmFtQGlldGYub3JnIDxtYWlsdG86dHJhbUBpZXRmLm9yZz4N Cj4gPiAgICAgID4gU3ViamVjdDogUkU6IFt0cmFtXSBUVVJOIGFuZCBmcmFnbWVudGF0aW9uDQo+ ID4gICAgICA+DQo+ID4gICAgICA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAg ICAgID4gPiBGcm9tOiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29t DQo+ID4gICAgIDxtYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT5dDQo+ID4gICAgICA+ID4gU2Vu dDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgODo1OSBQTQ0KPiA+ICAgICAgPiA+IFRvOiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gICAgICA+ID4gQ2M6IFByYXNoYW50aCBQYXRp bCAocHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5zdG9uOw0KPiA+ICAgICAg PiA+IHRyYW1AaWV0Zi5vcmcgPG1haWx0bzp0cmFtQGlldGYub3JnPg0KPiA+ICAgICAgPiA+IFN1 YmplY3Q6IFJlOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21lbnRhdGlvbg0KPiA+ICAgICAgPiA+DQo+ ID4gICAgICA+ID4gT24gTW9uLCBBdWcgMTgsIDIwMTQgYXQgMTE6MjcgQU0sIFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCj4gPiAgICAgID4gPiA8dGlyZWRkeUBjaXNjby5jb20gPG1haWx0 bzp0aXJlZGR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KPiA+ICAgICAgPiA+ID4gWWVzLCBJIGFtIHJl ZmVycmluZyB0byBTVFVOIGZyYWdtZW50YXRpb24uDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4g PiBHb3QgaXQsIHRoYW5rcy4NCj4gPiAgICAgID4gPg0KPiA+ICAgICAgPiA+IFNvLCB3aGF0J3Mg eW91ciBpZGVhLCBpbiBkZXRhaWwgPw0KPiA+ICAgICAgPg0KPiA+ICAgICAgPiBJIGhhdmUgbm90 IHlldCBmaWd1cmVkIG91dCBhbGwgdGhlIGRldGFpbHMsIGF0IGhpZ2ggbGV2ZWwNCj4gPiAgICAg dGhpbmtpbmcgdGhlIHByb2JsZW0NCj4gPiAgICAgID4gY2FuIGJlIHNvbHZlZCBzaW1pbGFyIHRv IHdheSBmcmFnbWVudGF0aW9uIGlzIGhhbmRsZWQgaW4gRUFQLVRMUw0KPiA+ICAgICAgPiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIxNiNzZWN0aW9uLTIuMS41KS4NCj4gPg0KPiA+ ICAgICBUaGlua2luZyBhbG91ZC4gU1RVTiBmcmFnbWVudGF0aW9uIHByb2JsZW0gY2FuIGJlIHNv bHZlZCBieSB0aGUNCj4gPiAgICAgZm9sbG93aW5nIGFwcHJvYWNoOg0KPiA+ICAgICBbMV0gSW50 cm9kdWNlIGEgbmV3IFNUVU4gRlJBR01FTlQgYXR0cmlidXRlIHdoaWNoIGNhcnJpZXMgdGhlDQo+ ID4gICAgIGZyYWdtZW50YXRpb24gZGV0YWlscyBsaWtlIChNOiBNb3JlIGZyYWdtZW50czogd2hp Y2ggaXMgc2V0IG9uIGFsbA0KPiA+ICAgICBmcmFnbWVudHMgYnV0IHRoZSBsYXN0IGZyYWdtZW50 KSwgIFMgKEZyYWdtZW50YXRpb24gc3RhcnQpLA0KPiA+ICAgICBJZGVudGlmaWVyIGZvciBzZXF1 ZW5jaW5nIGV0Yy4pLg0KPiA+ICAgICBbMl0gU1RVTiBhdHRyaWJ1dGUgdGhhdCB3b3VsZCBiZSBz dWJqZWN0ZWQgdG8gZnJhZ21lbnRhdGlvbiBzaG91bGQNCj4gPiAgICAgYmUgcGxhY2VkIGFmdGVy IHRoZSBTVFVOIEZSQUdNRU5UIGF0dHJpYnV0ZS4NCj4gPiAgICAgWzNdIFRVUk4gc2VydmVyIHVz ZXMgYSBuZXcgU1RVTiBhdHRyaWJ1dGUgbGV04oCZcyBzYXkgQUNLIHRvIHNpZ25hbA0KPiA+ICAg ICBiYWNrIHRvIHRoZSBjbGllbnQgdGhhdCBpdCByZWNlaXZlZCB0aGUgZnJhZ21lbnQgYnkgc2ln bmFsaW5nIGJhY2sNCj4gPiAgICAgdGhlIElkZW50aWZpZXIgaXQgcmVjZWl2ZWQgaW4gcmVxdWVz dC4NCj4gPiAgICAgWzRdIE9uY2UgdGhlIGZpbmFsIGZyYWdtZW50IGlzIHJlY2VpdmVkLCBUVVJO IHNlcnZlciBtZXJnZXMgdGhlDQo+ID4gICAgIGZyYWdtZW50cywgdmFsaWRhdGVzIHRoZSBTVFVO IG1lc3NhZ2UgYW5kIHJlc3BvbmRzIGJhY2sgdG8gdGhlIGNsaWVudC4NCj4gPg0KPiA+DQo+ID4g V2hpbGUgSSdtIHN1cmUgc29tZXRoaW5nIGxpa2UgdGhhdCB3b3VsZCB3b3JrLCBpdCBzZWVtcyBw cmV0dHkNCj4gPiBjb21wbGljYXRlZCBhbmQgQUZBSUsgdGhlcmUgaXMgbm8gdXNlIGNhc2UgdGhh dCByZXF1aXJlcyBpdCBhdCB0aGUNCj4gPiBtb21lbnQuIEkgdGhpbmsgd2Ugc2hvdWxkIHNhdmUg dGhpcyBmb3IgbGF0ZXIsIGFzIG9wcG9zZWQgdG8gc29sdmluZyBpdA0KPiA+IGluIHR1cm4tYmlz Lg0KPiANCj4gSSBhZ3JlZSB0aGF0IGEgZnJhZ21lbnRhdGlvbiBzb2x1dGlvbiBkb2Vzbid0IGJl bG9uZyBkaXJlY3RseSBpbg0KPiB0dXJuLWJpcy4gVGhhdCBzYWlkLCBJIHRoaW5rIGVpdGhlciB0 dXJuLWJpcyBvciBzdHVuLWJpcyBtaWdodCBuZWVkIHRvDQo+IHByb3ZpZGUgYmV0dGVyIGd1aWRh bmNlIG9uIGZyYWdtZW50YXRpb24uIEZvciBleGFtcGxlLCB0aGUgY3VycmVudA0KPiB3b3JkaW5n IGxpbWl0cyBzdHVuIG1lc3NhZ2VzIHRvIDU0OCBieXRlcyBpbiBjYXNlcyB3aGVyZSB0aGUgcGF0 aCBNVFUgaXMNCj4gbm90IHlldCBrbm93biBhbmQgdGhlIG1lc3NhZ2VzIGl0c2VsZiBpcyBub3Qg YmVpbmcgdXNlZCB0byBwcm9iZSB0aGUNCj4gcGF0aCBNVFUuIEl0J3MgZWFzeSB0byBjb21lIHVw IHdpdGggYSBzZXQgb2YgcmVhc29uYWJsZSB2YWx1ZXMgZm9yIGFuDQo+IGFsbG9jYXRlIHJlcXVl c3QgKGF0IGxlYXN0KSB0aGF0IHdvdWxkIHZpb2xhdGUgdGhpcyByZXN0cmljdGlvbiwNCj4gZXNw ZWNpYWxseSB3aGVuIHlvdSBhZGQgdGhlIG5ldyBvcmlnaW4gYW5kIDNyZCBwYXJ0eSBhdXRoIGF0 dHJpYnV0ZXMuIEluDQo+IHRoZSByYXJlIGNhc2Ugb2YgYSBjbGllbnQgdGhhdCByZWFsbHkgZG9l cyBoYXZlIHN1Y2ggYSBzbWFsbCBQTVRVLCB0aGUNCj4gc3RhbmRhcmRzIGFzIGN1cnJlbnRseSBw dWJsaXNoZWQgY2FuIGFjdHVhbGx5IHByZXZlbnQgdGhlIGNsaWVudCBmcm9tDQo+IGJlaW5nIGFi bGUgdG8gdXNlIGEgdHVybiByZWxheSB0aGF0IHJlbGllcyBvbiB0aGUgbmV3IGF0dHJpYnV0ZXMg d2l0aG91dA0KPiBpZ25vcmluZyB0aGUgZnJhZ21lbnRhdGlvbiBndWlkYW5jZS4NCg0KVHVubmVs aW5nIFRVUk4gb3ZlciBUVVJOIGZvciBwcml2YWN5IHByb3Bvc2VkIGluIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdhcnR6LXJ0Y3dlYi1yZXR1cm4tMDAgY291bGQgYmUgYW5v dGhlciByZWFzb24gdG8gZXZhbHVhdGUgdGhlIHJlYXNvbnMgdG8gc3VwcG9ydCBTVFVOIGZyYWdt ZW50YXRpb24uIFdlIGNhbiByZW1vdmUgc3RlcCAzIG9wdGltaXphdGlvbiB3aGljaCB3b3VsZCBz aW1wbGlmeSB0aGUgc29sdXRpb24uDQogDQotVGlydQ0KDQo+IA0KPiAtLUJyYW5kb24NCj4gDQo+ IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5l ZXINCj4gRW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMg SW5jLg0K From nobody Fri Aug 22 11:04:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FAB1A06B0 for ; Fri, 22 Aug 2014 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvJXIWEuO2UB for ; Fri, 22 Aug 2014 11:04:28 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B521A0939 for ; Fri, 22 Aug 2014 11:04:27 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id el20so10393202lab.17 for ; Fri, 22 Aug 2014 11:04:24 -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:content-type; bh=zmSyQHtVDcbTYFgPhddp2ZFiAl/2KqPKD1PCZF0zRKg=; b=CXyXPazciYhulCXoAtsfxfBDbFmWTu+Pn0Mu4aYZc0R0B7ObTIUHl76dAoIAlDvyG2 3z6e1cSH+nhjlGRLts3Mgiawr+wYSAS5pRZUHi+j08pNw9HZPFBHhJROXrSZSQ7lZfie TPre0cmte/SM98na6vec/TDVZHj2B1gqqxXBCXsD0S69n9M4DVlzKBXBkL3FI+tCd/VN /IZiuQjNkAyvs3QFfvdA2koIZ8ukjY3gUmbm/Fj5R+95JG24MqyWYXxL46wQ4Px5FRHn YoRD4KMRZ7DvOEyHW05yW9pVEccuS61/Jc/4KEIu9pDSLsJE7m1L3as2xA0x7klbV71g F8XA== MIME-Version: 1.0 X-Received: by 10.112.5.170 with SMTP id t10mr5732832lbt.64.1408730664645; Fri, 22 Aug 2014 11:04:24 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 22 Aug 2014 11:04:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 11:04:24 -0700 Message-ID: From: Martin Thomson To: Justin Uberti Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ddDUILUio6uc8iL8DvoKIHAuMVk Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 18:04:31 -0000 On 21 August 2014 22:09, Justin Uberti wrote: > Of course, in the WebRTC case, the TURN server will be specified by the > application, so the application at least knows who will have access to this > data. That's only true if we don't have browser-configured STUN servers (or even TURN servers, as unlikely as that seems). Obviously, if the browser configures a STUN server, then they might want to take some precautions here, but that doesn't remove the privacy considerations. From nobody Fri Aug 22 16:57:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8A1A6FB4 for ; Fri, 22 Aug 2014 16:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTJWlJkuJzrE for ; Fri, 22 Aug 2014 16:57:09 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A5B1A6F64 for ; Fri, 22 Aug 2014 16:57:09 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ij19so12763035vcb.25 for ; Fri, 22 Aug 2014 16:57:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=A0JUaW+r8gZLn7l+kKLaiN4RE2dVFtLy1YRq1Y4KKGI=; b=ajlHpvtoSY9Aa8YNoCboIXNUjLXL6bkKXsWi4ZQTDtjKeWD5Ly6GvvEf3m8c2H9fsY FlRsSyElDokjl8g0UHYlf1FN8wBD0Rq4MygJ9LSfuKrmGlZikVxeb237LSitbdS4Vmxw FeqCTYJneS5XYH21Uz74h9ZAIcS7Zg9sUg9VynCGB7vpuNB1NXdv72K8aarwD395Zf2E QDaEaPGodKecGZ+PChPtAPaQnMbGiQcvsbR9NWnP37TtkeJ/6PBeR0KL/XkpbBU9/bU2 tFVGTvNCr/EMtT1cQcjtK1nq8Xl0zFiOkdtzK3QkSUnf+UtcDEKBDV8ncBxSrk/0lOeL MR7A== 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-type; bh=A0JUaW+r8gZLn7l+kKLaiN4RE2dVFtLy1YRq1Y4KKGI=; b=YvxRjcIOiSKyc/HNu4QtAEVzPwd48WYEHrc7ZTlIUVRVIU3Pwfw8ePxgbBRNV4t0M6 rbMDVeL4mjRM5K74dbKB5fKYGJMhsl/8NQTfmEwSJDI9t5A1caeXv7cVqExv21hNObCe vOhMP2YeDpnJqZ9Voo2fHcRqZn999fHOtSbOgnoFnL9Aru/ptuYXG7CnP5ln7CAs+h1g hBRDsUMFMtqGsyttmpowT8K3R0gR0cvPWfSovA6qnNNSb29ZZ1/GRVyvHkhz+nPC1JW6 +bb9eSPTrlx77ZnD+2Ulq0VOQHkHyfipDiw/r9DID+lidQQyUzFhVqFL/kQ9b52Vbun0 4jXQ== X-Gm-Message-State: ALoCoQnOO8lh1fDosdJGLIajFNAvO4VOT+0xxu5rGDfPUolBDVYD2N0MahFuF7oKJvG2oKnz9hBA X-Received: by 10.220.247.3 with SMTP id ma3mr2819552vcb.29.1408751828740; Fri, 22 Aug 2014 16:57:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 22 Aug 2014 16:56:48 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> <53F763A2.1000309@akamai.com> <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Fri, 22 Aug 2014 16:56:48 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e013c6eca544cdf0501409893 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xprB6bf_885UlRiihH7Ai_Klo1s Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:57:12 -0000 --089e013c6eca544cdf0501409893 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think RETURN requires us to handle fragmentation. As long as DATA isn't sent recursively encapsulated, which I don't yet see a need for, the only overhead is the 4-byte channel header. On Fri, Aug 22, 2014 at 9:25 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > > -----Original Message----- > > From: Brandon Williams [mailto:brandon.williams@akamai.com] > > Sent: Friday, August 22, 2014 9:07 PM > > To: Justin Uberti; Tirumaleswar Reddy (tireddy) > > Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; > tram@ietf.org > > Subject: Re: [tram] TURN and fragmentation > > > > > > > > On 08/22/2014 12:57 AM, Justin Uberti wrote: > > > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) > > > > wrote: > > > > > > > -----Original Message----- > > > > From: Tirumaleswar Reddy (tireddy) > > > > Sent: Monday, August 18, 2014 9:17 PM > > > > To: 'Simon Perreault' > > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnsto= n; > > > > tram@ietf.org > > > > Subject: RE: [tram] TURN and fragmentation > > > > > > > > > -----Original Message----- > > > > > From: Simon Perreault [mailto:sperreault@jive.com > > > ] > > > > > Sent: Monday, August 18, 2014 8:59 PM > > > > > To: Tirumaleswar Reddy (tireddy) > > > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan > Johnston; > > > > > tram@ietf.org > > > > > Subject: Re: [tram] TURN and fragmentation > > > > > > > > > > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tiredd= y) > > > > > > wrote: > > > > > > Yes, I am referring to STUN fragmentation. > > > > > > > > > > Got it, thanks. > > > > > > > > > > So, what's your idea, in detail ? > > > > > > > > I have not yet figured out all the details, at high level > > > thinking the problem > > > > can be solved similar to way fragmentation is handled in EAP-T= LS > > > > (http://tools.ietf.org/html/rfc5216#section-2.1.5). > > > > > > Thinking aloud. STUN fragmentation problem can be solved by the > > > following approach: > > > [1] Introduce a new STUN FRAGMENT attribute which carries the > > > fragmentation details like (M: More fragments: which is set on al= l > > > fragments but the last fragment), S (Fragmentation start), > > > Identifier for sequencing etc.). > > > [2] STUN attribute that would be subjected to fragmentation shoul= d > > > be placed after the STUN FRAGMENT attribute. > > > [3] TURN server uses a new STUN attribute let=E2=80=99s say ACK t= o signal > > > back to the client that it received the fragment by signaling bac= k > > > the Identifier it received in request. > > > [4] Once the final fragment is received, TURN server merges the > > > fragments, validates the STUN message and responds back to the > client. > > > > > > > > > While I'm sure something like that would work, it seems pretty > > > complicated and AFAIK there is no use case that requires it at the > > > moment. I think we should save this for later, as opposed to solving = it > > > in turn-bis. > > > > I agree that a fragmentation solution doesn't belong directly in > > turn-bis. That said, I think either turn-bis or stun-bis might need to > > provide better guidance on fragmentation. For example, the current > > wording limits stun messages to 548 bytes in cases where the path MTU i= s > > not yet known and the messages itself is not being used to probe the > > path MTU. It's easy to come up with a set of reasonable values for an > > allocate request (at least) that would violate this restriction, > > especially when you add the new origin and 3rd party auth attributes. I= n > > the rare case of a client that really does have such a small PMTU, the > > standards as currently published can actually prevent the client from > > being able to use a turn relay that relies on the new attributes withou= t > > ignoring the fragmentation guidance. > > Tunneling TURN over TURN for privacy proposed in > http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be > another reason to evaluate the reasons to support STUN fragmentation. We > can remove step 3 optimization which would simplify the solution. > > -Tiru > > > > > --Brandon > > > > -- > > Brandon Williams; Senior Principal Software Engineer > > Emerging Products Engineering; Akamai Technologies Inc. > --089e013c6eca544cdf0501409893 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think RETURN requires us to handle fragmentati= on. As long as DATA isn't sent recursively encapsulated, which I don= 9;t yet see a need for, the only overhead is the 4-byte channel header.


On Fri, Aug 2= 2, 2014 at 9:25 AM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com>= ; wrote:
>= -----Original Message-----
> From: Brandon Williams [mailto:brandon.williams@akamai.com]
> Sent: Friday, August 22, 2014 9:07 PM
> To: Justin Uberti; Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; tram@ietf.org
> Subject: Re: [tram] TURN and fragmentation
>
>
>
> On 08/22/2014 12:57 AM, Justin Uberti wrote:
> > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy)
> > <tireddy@cisco.com &l= t;mailto:tireddy@cisco.com>>= wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
> >=C2=A0 =C2=A0 =C2=A0 > From: Tirumaleswar Reddy (tireddy)
> >=C2=A0 =C2=A0 =C2=A0 > Sent: Monday, August 18, 2014 9:17 PM > >=C2=A0 =C2=A0 =C2=A0 > To: 'Simon Perreault'
> >=C2=A0 =C2=A0 =C2=A0 > Cc: Prashanth Patil (praspati); Brandon = Williams; Alan Johnston;
> >=C2=A0 =C2=A0 =C2=A0 > tram@ie= tf.org <mailto:tram@ietf.org>= ;
> >=C2=A0 =C2=A0 =C2=A0 > Subject: RE: [tram] TURN and fragmentati= on
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > > -----Original Message-----
> >=C2=A0 =C2=A0 =C2=A0 > > From: Simon Perreault [mailto:sperreault@jive.com
> >=C2=A0 =C2=A0 =C2=A0<mailto:sperreault@jive.com>]
> >=C2=A0 =C2=A0 =C2=A0 > > Sent: Monday, August 18, 2014 8:59 = PM
> >=C2=A0 =C2=A0 =C2=A0 > > To: Tirumaleswar Reddy (tireddy) > >=C2=A0 =C2=A0 =C2=A0 > > Cc: Prashanth Patil (praspati); Bra= ndon Williams; Alan Johnston;
> >=C2=A0 =C2=A0 =C2=A0 > > tr= am@ietf.org <mailto:tram@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0 > > Subject: Re: [tram] TURN and fragme= ntation
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > On Mon, Aug 18, 2014 at 11:27 AM, T= irumaleswar Reddy (tireddy)
> >=C2=A0 =C2=A0 =C2=A0 > > <tireddy@cisco.com <mailto:tireddy@cisco.com>> wrote:
> >=C2=A0 =C2=A0 =C2=A0 > > > Yes, I am referring to STUN fr= agmentation.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Got it, thanks.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > So, what's your idea, in detail= ?
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > I have not yet figured out all the detai= ls, at high level
> >=C2=A0 =C2=A0 =C2=A0thinking the problem
> >=C2=A0 =C2=A0 =C2=A0 > can be solved similar to way fragmentati= on is handled in EAP-TLS
> >=C2=A0 =C2=A0 =C2=A0 > (http://tools.ietf.org/html/rfc5216#= section-2.1.5).
> >
> >=C2=A0 =C2=A0 =C2=A0Thinking aloud. STUN fragmentation problem can= be solved by the
> >=C2=A0 =C2=A0 =C2=A0following approach:
> >=C2=A0 =C2=A0 =C2=A0[1] Introduce a new STUN FRAGMENT attribute wh= ich carries the
> >=C2=A0 =C2=A0 =C2=A0fragmentation details like (M: More fragments:= which is set on all
> >=C2=A0 =C2=A0 =C2=A0fragments but the last fragment),=C2=A0 S (Fra= gmentation start),
> >=C2=A0 =C2=A0 =C2=A0Identifier for sequencing etc.).
> >=C2=A0 =C2=A0 =C2=A0[2] STUN attribute that would be subjected to = fragmentation should
> >=C2=A0 =C2=A0 =C2=A0be placed after the STUN FRAGMENT attribute. > >=C2=A0 =C2=A0 =C2=A0[3] TURN server uses a new STUN attribute let= =E2=80=99s say ACK to signal
> >=C2=A0 =C2=A0 =C2=A0back to the client that it received the fragme= nt by signaling back
> >=C2=A0 =C2=A0 =C2=A0the Identifier it received in request.
> >=C2=A0 =C2=A0 =C2=A0[4] Once the final fragment is received, TURN = server merges the
> >=C2=A0 =C2=A0 =C2=A0fragments, validates the STUN message and resp= onds back to the client.
> >
> >
> > While I'm sure something like that would work, it seems prett= y
> > complicated and AFAIK there is no use case that requires it at th= e
> > moment. I think we should save this for later, as opposed to solv= ing it
> > in turn-bis.
>
> I agree that a fragmentation solution doesn't belong directly in > turn-bis. That said, I think either turn-bis or stun-bis might need to=
> provide better guidance on fragmentation. For example, the current
> wording limits stun messages to 548 bytes in cases where the path MTU = is
> not yet known and the messages itself is not being used to probe the > path MTU. It's easy to come up with a set of reasonable values for= an
> allocate request (at least) that would violate this restriction,
> especially when you add the new origin and 3rd party auth attributes. = In
> the rare case of a client that really does have such a small PMTU, the=
> standards as currently published can actually prevent the client from<= br> > being able to use a turn relay that relies on the new attributes witho= ut
> ignoring the fragmentation guidance.

Tunneling TURN over TURN for privacy proposed in = http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be ano= ther reason to evaluate the reasons to support STUN fragmentation. We can r= emove step 3 optimization which would simplify the solution.

-Tiru

>
> --Brandon
>
> --
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.

--089e013c6eca544cdf0501409893-- From nobody Fri Aug 22 16:57:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481581A6F64 for ; Fri, 22 Aug 2014 16:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecEAO5upZqLq for ; Fri, 22 Aug 2014 16:57:57 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFDA1A6F61 for ; Fri, 22 Aug 2014 16:57:56 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id la4so13045291vcb.19 for ; Fri, 22 Aug 2014 16:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jncG1R6VQuJZ/fqZCxBemUm2aEc9x/lY8J8ewgw7eTg=; b=CCBOJHE49OXqY72bZHtjVVS3CRPNuso75gEpa5CCNssf6oEBzu+WaUeUJkni00tsUa DFQcS4Tb04MeEWahzPpptAyXicQRqYX8xpGNNNn17m4jmRoa1ytzHAAPnX1YJg2WvwgB 8sEsVWMX6stBeFMx100aJg3JQlLpcHkzWgs8QvB3gZDeL4dC7Ihycm405WLyWE20ixqu O+L3vCQta3SDDO7AOi+Lgwqyzs9IUdxWavn5KZ4D3VoKLdLI25Fa5jfG5SWiD8q6GyCR v3ZXpuFIlvyi9UJyOc1aMCXb/As9tn1hTDjR3nDxqUARAkJGtm+NUDTOhKJiLRNW6siB G2cg== 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-type; bh=jncG1R6VQuJZ/fqZCxBemUm2aEc9x/lY8J8ewgw7eTg=; b=jMfcxusjxFO2A8D1HbNCNIKVC3MYdIXq7MXxzn8JGMW6XlyrccdW3UDqYzwMKISRz1 goUgQTaB8FCufBGMtW0WnxEyV5XgXaZmYON46dOV8tyTTgcM0c/zoM64gYKWwYDug18b clw9bBi6fJ5ItZIC4wLD/zyJaRW5U9hXllb1nYpwcVip9XPVxbuSw9HfDl/pnEVYjBfK Eilp8z3NBSDwvvfvAORVJYLfi+Vtpvc/4Mq/zNLWbWjo5n3a/3UarFwMwlEkZiqSXaki RVeWvQYFwbYBFzx4fZnGoqQZO6Dbmubp0fGOxSOawAQ285a0QvnB0V9fHYbRzCC6X3Wi WVJA== X-Gm-Message-State: ALoCoQnkGiKBYBODUelgNLDlxTjRUdrP1s6a9jsG32PmXkYV1w3q+1oyPV8g4j5wIcDQvfWHLE8i X-Received: by 10.220.97.138 with SMTP id l10mr5889444vcn.25.1408751876170; Fri, 22 Aug 2014 16:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 22 Aug 2014 16:57:36 -0700 (PDT) In-Reply-To: References: From: Justin Uberti Date: Fri, 22 Aug 2014 16:57:36 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c1d2cc28014f0501409bf7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/o70s_HbZ2ZztpS5qZwrQMuyMQEU Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Review of origin draft X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:57:58 -0000 --001a11c1d2cc28014f0501409bf7 Content-Type: text/plain; charset=UTF-8 Agreed. On Fri, Aug 22, 2014 at 11:04 AM, Martin Thomson wrote: > On 21 August 2014 22:09, Justin Uberti wrote: > > Of course, in the WebRTC case, the TURN server will be specified by the > > application, so the application at least knows who will have access to > this > > data. > > That's only true if we don't have browser-configured STUN servers (or > even TURN servers, as unlikely as that seems). > > Obviously, if the browser configures a STUN server, then they might > want to take some precautions here, but that doesn't remove the > privacy considerations. > --001a11c1d2cc28014f0501409bf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed.


On Fri, Aug 22, 2014 at 11:04 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 21 August 2014 22:09, Jus= tin Uberti <juberti@google.com= > wrote:
> Of course, in the WebRTC case, the TURN server will be specified by th= e
> application, so the application at least knows who will have access to= this
> data.

That's only true if we don't have browser-configured STUN ser= vers (or
even TURN servers, as unlikely as that seems).

Obviously, if the browser configures a STUN server, then they might
want to take some precautions here, but that doesn't remove the
privacy considerations.

--001a11c1d2cc28014f0501409bf7-- From nobody Fri Aug 22 19:27:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C17F11A70E2 for ; Fri, 22 Aug 2014 19:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YllD2YPClYYW for ; Fri, 22 Aug 2014 19:27:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B931A7031 for ; Fri, 22 Aug 2014 19:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21532; q=dns/txt; s=iport; t=1408760838; x=1409970438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tAJdR2Ike+XrjSyy+dXRStfAYR2/yedVKsVanONpKTM=; b=cjnKD8CCnRTYts2PlbsjYIQlUTLcLK2r2EyLDRVOCvTIeMv8BVyZ4ZqR yO5VA6eLSdmlAUYh2VHv4zOPcqAmGAsXNARc5+eLK/iPK/Ge4/FpiunMO YLTTQJMiuMS+lTnZ+KwPiR/Ldwc8kJA+uGB1iRIRGb7p6eO0zxEWDP3Mn 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAEn791OtJV2Q/2dsb2JhbABZgkdGU1cEgnjIAYFjh00BGXcWd4QDAQEBBCMKOhIMBAIBCA4DBAEBAQodAwICAjAUCQgBAQQOBQgTiCcNr22UexePGxYbBgEGgnM2gR0FhQQCjCCEKYhSkzSBZB6BXGwBAYEGJByBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,385,1406592000"; d="scan'208,217";a="349761503" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-4.cisco.com with ESMTP; 23 Aug 2014 02:27:17 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7N2RHSw000902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 02:27:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 21:27:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] TURN and fragmentation Thread-Index: Ac+7jhywuv5uhwsYToWrzO8B1UwDZgCYVwwAABZXXQAACSnGAAAISeUAAAXXCdA= Date: Sat, 23 Aug 2014 02:27:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831A17D@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> <53F763A2.1000309@akamai.com> <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.73.60] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2831A17Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zFrIuHos6oVYKeBOoF3CxGgIuhE Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 02:27:22 -0000 --_000_913383AAA69FF945B8F946018B75898A2831A17Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hyb21lIHNlZW1zIHRvIGJlIHVzaW5nIGNoYW5uZWxzICwgYnV0IEkgdGhvdWdodCBvdGhlciBi cm93c2VycyBsaWtlIGZpcmVmb3ggYXJlIHVzaW5nIFNlbmQvRGF0YSBpbmRpY2F0aW9ucy4NCg0K LVRpcnUNCg0KRnJvbTogSnVzdGluIFViZXJ0aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0N ClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjMsIDIwMTQgNToyNyBBTQ0KVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSkNCkNjOiBCcmFuZG9uIFdpbGxpYW1zOyBTaW1vbiBQZXJyZWF1bHQ7 IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBBbGFuIEpvaG5zdG9uOyB0cmFtQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRpb24NCg0KSSBkb24ndCB0 aGluayBSRVRVUk4gcmVxdWlyZXMgdXMgdG8gaGFuZGxlIGZyYWdtZW50YXRpb24uIEFzIGxvbmcg YXMgREFUQSBpc24ndCBzZW50IHJlY3Vyc2l2ZWx5IGVuY2Fwc3VsYXRlZCwgd2hpY2ggSSBkb24n dCB5ZXQgc2VlIGEgbmVlZCBmb3IsIHRoZSBvbmx5IG92ZXJoZWFkIGlzIHRoZSA0LWJ5dGUgY2hh bm5lbCBoZWFkZXIuDQoNCk9uIEZyaSwgQXVnIDIyLCAyMDE0IGF0IDk6MjUgQU0sIFRpcnVtYWxl c3dhciBSZWRkeSAodGlyZWRkeSkgPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNp c2NvLmNvbT4+IHdyb3RlOg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBC cmFuZG9uIFdpbGxpYW1zIFttYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tPG1haWx0 bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb20+XQ0KPiBTZW50OiBGcmlkYXksIEF1Z3VzdCAy MiwgMjAxNCA5OjA3IFBNDQo+IFRvOiBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpDQo+IENjOiBTaW1vbiBQZXJyZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJhc3Bh dGkpOyBBbGFuIEpvaG5zdG9uOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRpb24NCj4NCj4NCj4NCj4g T24gMDgvMjIvMjAxNCAxMjo1NyBBTSwgSnVzdGluIFViZXJ0aSB3cm90ZToNCj4gPiBPbiBUdWUs IEF1ZyAxOSwgMjAxNCBhdCAyOjE1IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ ID4gPHRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4gPG1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+Pj4gd3JvdGU6DQo+ID4N Cj4gPiAgICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAgICAgID4gRnJvbTog VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KPiA+ICAgICAgPiBTZW50OiBNb25kYXksIEF1 Z3VzdCAxOCwgMjAxNCA5OjE3IFBNDQo+ID4gICAgICA+IFRvOiAnU2ltb24gUGVycmVhdWx0Jw0K PiA+ICAgICAgPiBDYzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEJyYW5kb24gV2lsbGlh bXM7IEFsYW4gSm9obnN0b247DQo+ID4gICAgICA+IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1A aWV0Zi5vcmc+IDxtYWlsdG86dHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4+DQo+ ID4gICAgICA+IFN1YmplY3Q6IFJFOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21lbnRhdGlvbg0KPiA+ ICAgICAgPg0KPiA+ICAgICAgPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gICAg ICA+ID4gRnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbTxt YWlsdG86c3BlcnJlYXVsdEBqaXZlLmNvbT4NCj4gPiAgICAgPG1haWx0bzpzcGVycmVhdWx0QGpp dmUuY29tPG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPj5dDQo+ID4gICAgICA+ID4gU2VudDog TW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgODo1OSBQTQ0KPiA+ICAgICAgPiA+IFRvOiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gICAgICA+ID4gQ2M6IFByYXNoYW50aCBQYXRpbCAo cHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5zdG9uOw0KPiA+ICAgICAgPiA+ IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+IDxtYWlsdG86dHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4+DQo+ID4gICAgICA+ID4gU3ViamVjdDogUmU6IFt0cmFt XSBUVVJOIGFuZCBmcmFnbWVudGF0aW9uDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4gPiBPbiBN b24sIEF1ZyAxOCwgMjAxNCBhdCAxMToyNyBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KQ0KPiA+ICAgICAgPiA+IDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5j b20+IDxtYWlsdG86dGlyZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4+ IHdyb3RlOg0KPiA+ICAgICAgPiA+ID4gWWVzLCBJIGFtIHJlZmVycmluZyB0byBTVFVOIGZyYWdt ZW50YXRpb24uDQo+ID4gICAgICA+ID4NCj4gPiAgICAgID4gPiBHb3QgaXQsIHRoYW5rcy4NCj4g PiAgICAgID4gPg0KPiA+ICAgICAgPiA+IFNvLCB3aGF0J3MgeW91ciBpZGVhLCBpbiBkZXRhaWwg Pw0KPiA+ICAgICAgPg0KPiA+ICAgICAgPiBJIGhhdmUgbm90IHlldCBmaWd1cmVkIG91dCBhbGwg dGhlIGRldGFpbHMsIGF0IGhpZ2ggbGV2ZWwNCj4gPiAgICAgdGhpbmtpbmcgdGhlIHByb2JsZW0N Cj4gPiAgICAgID4gY2FuIGJlIHNvbHZlZCBzaW1pbGFyIHRvIHdheSBmcmFnbWVudGF0aW9uIGlz IGhhbmRsZWQgaW4gRUFQLVRMUw0KPiA+ICAgICAgPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNTIxNiNzZWN0aW9uLTIuMS41KS4NCj4gPg0KPiA+ICAgICBUaGlua2luZyBhbG91ZC4g U1RVTiBmcmFnbWVudGF0aW9uIHByb2JsZW0gY2FuIGJlIHNvbHZlZCBieSB0aGUNCj4gPiAgICAg Zm9sbG93aW5nIGFwcHJvYWNoOg0KPiA+ICAgICBbMV0gSW50cm9kdWNlIGEgbmV3IFNUVU4gRlJB R01FTlQgYXR0cmlidXRlIHdoaWNoIGNhcnJpZXMgdGhlDQo+ID4gICAgIGZyYWdtZW50YXRpb24g ZGV0YWlscyBsaWtlIChNOiBNb3JlIGZyYWdtZW50czogd2hpY2ggaXMgc2V0IG9uIGFsbA0KPiA+ ICAgICBmcmFnbWVudHMgYnV0IHRoZSBsYXN0IGZyYWdtZW50KSwgIFMgKEZyYWdtZW50YXRpb24g c3RhcnQpLA0KPiA+ICAgICBJZGVudGlmaWVyIGZvciBzZXF1ZW5jaW5nIGV0Yy4pLg0KPiA+ICAg ICBbMl0gU1RVTiBhdHRyaWJ1dGUgdGhhdCB3b3VsZCBiZSBzdWJqZWN0ZWQgdG8gZnJhZ21lbnRh dGlvbiBzaG91bGQNCj4gPiAgICAgYmUgcGxhY2VkIGFmdGVyIHRoZSBTVFVOIEZSQUdNRU5UIGF0 dHJpYnV0ZS4NCj4gPiAgICAgWzNdIFRVUk4gc2VydmVyIHVzZXMgYSBuZXcgU1RVTiBhdHRyaWJ1 dGUgbGV04oCZcyBzYXkgQUNLIHRvIHNpZ25hbA0KPiA+ICAgICBiYWNrIHRvIHRoZSBjbGllbnQg dGhhdCBpdCByZWNlaXZlZCB0aGUgZnJhZ21lbnQgYnkgc2lnbmFsaW5nIGJhY2sNCj4gPiAgICAg dGhlIElkZW50aWZpZXIgaXQgcmVjZWl2ZWQgaW4gcmVxdWVzdC4NCj4gPiAgICAgWzRdIE9uY2Ug dGhlIGZpbmFsIGZyYWdtZW50IGlzIHJlY2VpdmVkLCBUVVJOIHNlcnZlciBtZXJnZXMgdGhlDQo+ ID4gICAgIGZyYWdtZW50cywgdmFsaWRhdGVzIHRoZSBTVFVOIG1lc3NhZ2UgYW5kIHJlc3BvbmRz IGJhY2sgdG8gdGhlIGNsaWVudC4NCj4gPg0KPiA+DQo+ID4gV2hpbGUgSSdtIHN1cmUgc29tZXRo aW5nIGxpa2UgdGhhdCB3b3VsZCB3b3JrLCBpdCBzZWVtcyBwcmV0dHkNCj4gPiBjb21wbGljYXRl ZCBhbmQgQUZBSUsgdGhlcmUgaXMgbm8gdXNlIGNhc2UgdGhhdCByZXF1aXJlcyBpdCBhdCB0aGUN Cj4gPiBtb21lbnQuIEkgdGhpbmsgd2Ugc2hvdWxkIHNhdmUgdGhpcyBmb3IgbGF0ZXIsIGFzIG9w cG9zZWQgdG8gc29sdmluZyBpdA0KPiA+IGluIHR1cm4tYmlzLg0KPg0KPiBJIGFncmVlIHRoYXQg YSBmcmFnbWVudGF0aW9uIHNvbHV0aW9uIGRvZXNuJ3QgYmVsb25nIGRpcmVjdGx5IGluDQo+IHR1 cm4tYmlzLiBUaGF0IHNhaWQsIEkgdGhpbmsgZWl0aGVyIHR1cm4tYmlzIG9yIHN0dW4tYmlzIG1p Z2h0IG5lZWQgdG8NCj4gcHJvdmlkZSBiZXR0ZXIgZ3VpZGFuY2Ugb24gZnJhZ21lbnRhdGlvbi4g Rm9yIGV4YW1wbGUsIHRoZSBjdXJyZW50DQo+IHdvcmRpbmcgbGltaXRzIHN0dW4gbWVzc2FnZXMg dG8gNTQ4IGJ5dGVzIGluIGNhc2VzIHdoZXJlIHRoZSBwYXRoIE1UVSBpcw0KPiBub3QgeWV0IGtu b3duIGFuZCB0aGUgbWVzc2FnZXMgaXRzZWxmIGlzIG5vdCBiZWluZyB1c2VkIHRvIHByb2JlIHRo ZQ0KPiBwYXRoIE1UVS4gSXQncyBlYXN5IHRvIGNvbWUgdXAgd2l0aCBhIHNldCBvZiByZWFzb25h YmxlIHZhbHVlcyBmb3IgYW4NCj4gYWxsb2NhdGUgcmVxdWVzdCAoYXQgbGVhc3QpIHRoYXQgd291 bGQgdmlvbGF0ZSB0aGlzIHJlc3RyaWN0aW9uLA0KPiBlc3BlY2lhbGx5IHdoZW4geW91IGFkZCB0 aGUgbmV3IG9yaWdpbiBhbmQgM3JkIHBhcnR5IGF1dGggYXR0cmlidXRlcy4gSW4NCj4gdGhlIHJh cmUgY2FzZSBvZiBhIGNsaWVudCB0aGF0IHJlYWxseSBkb2VzIGhhdmUgc3VjaCBhIHNtYWxsIFBN VFUsIHRoZQ0KPiBzdGFuZGFyZHMgYXMgY3VycmVudGx5IHB1Ymxpc2hlZCBjYW4gYWN0dWFsbHkg cHJldmVudCB0aGUgY2xpZW50IGZyb20NCj4gYmVpbmcgYWJsZSB0byB1c2UgYSB0dXJuIHJlbGF5 IHRoYXQgcmVsaWVzIG9uIHRoZSBuZXcgYXR0cmlidXRlcyB3aXRob3V0DQo+IGlnbm9yaW5nIHRo ZSBmcmFnbWVudGF0aW9uIGd1aWRhbmNlLg0KVHVubmVsaW5nIFRVUk4gb3ZlciBUVVJOIGZvciBw cml2YWN5IHByb3Bvc2VkIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNjaHdh cnR6LXJ0Y3dlYi1yZXR1cm4tMDAgY291bGQgYmUgYW5vdGhlciByZWFzb24gdG8gZXZhbHVhdGUg dGhlIHJlYXNvbnMgdG8gc3VwcG9ydCBTVFVOIGZyYWdtZW50YXRpb24uIFdlIGNhbiByZW1vdmUg c3RlcCAzIG9wdGltaXphdGlvbiB3aGljaCB3b3VsZCBzaW1wbGlmeSB0aGUgc29sdXRpb24uDQoN Ci1UaXJ1DQoNCj4NCj4gLS1CcmFuZG9uDQo+DQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7IFNl bmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXINCj4gRW1lcmdpbmcgUHJvZHVjdHMgRW5n aW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KDQo= --_000_913383AAA69FF945B8F946018B75898A2831A17Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyb21lIHNlZW1zIHRv IGJlIHVzaW5nIGNoYW5uZWxzICwgYnV0IEkgdGhvdWdodCBvdGhlciBicm93c2VycyBsaWtlIGZp cmVmb3ggYXJlIHVzaW5nIFNlbmQvRGF0YSBpbmRpY2F0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkg W21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXks IEF1Z3VzdCAyMywgMjAxNCA1OjI3IEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiBCcmFuZG9uIFdpbGxpYW1zOyBTaW1vbiBQZXJy ZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBBbGFuIEpvaG5zdG9uOyB0cmFtQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21lbnRh dGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGRvbid0IHRoaW5rIFJFVFVSTiByZXF1aXJlcyB1cyB0byBoYW5kbGUgZnJhZ21lbnRhdGlv bi4gQXMgbG9uZyBhcyBEQVRBIGlzbid0IHNlbnQgcmVjdXJzaXZlbHkgZW5jYXBzdWxhdGVkLCB3 aGljaCBJIGRvbid0IHlldCBzZWUgYSBuZWVkIGZvciwgdGhlIG9ubHkgb3ZlcmhlYWQgaXMgdGhl IDQtYnl0ZSBjaGFubmVsIGhlYWRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcgMjIs IDIwMTQgYXQgOToyNSBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbSI+YnJhbmRvbi53 aWxsaWFtc0Bha2FtYWkuY29tPC9hPl08YnI+DQomZ3Q7IFNlbnQ6IEZyaWRheSwgQXVndXN0IDIy LCAyMDE0IDk6MDcgUE08YnI+DQomZ3Q7IFRvOiBKdXN0aW4gVWJlcnRpOyBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpPGJyPg0KJmd0OyBDYzogU2ltb24gUGVycmVhdWx0OyBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKTsgQWxhbiBKb2huc3RvbjsgPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0 Zi5vcmciPg0KdHJhbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbdHJhbV0g VFVSTiBhbmQgZnJhZ21lbnRhdGlvbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgT24gMDgvMjIvMjAxNCAxMjo1NyBBTSwgSnVzdGluIFViZXJ0aSB3cm90ZTo8YnI+DQom Z3Q7ICZndDsgT24gVHVlLCBBdWcgMTksIDIwMTQgYXQgMjoxNSBBTSwgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTxicj4NCiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tIj50aXJlZGR5QGNpc2NvLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86dGlyZWRkeUBjaXNjby5jb20iPnRpcmVkZHlAY2lzY28uY29tPC9hPiZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7IEZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0 IDk6MTcgUE08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFRvOiAnU2lt b24gUGVycmVhdWx0Jzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgQ2M6 IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBCcmFuZG9uIFdpbGxpYW1zOyBBbGFuIEpvaG5z dG9uOzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0ibWFp bHRvOnRyYW1AaWV0Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnRyYW1AaWV0Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgU3ViamVjdDogUkU6IFt0cmFtXSBUVVJOIGFuZCBm cmFnbWVudGF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBG cm9tOiBTaW1vbiBQZXJyZWF1bHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3BlcnJlYXVsdEBq aXZlLmNvbSI+c3BlcnJlYXVsdEBqaXZlLmNvbTwvYT48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb20i PnNwZXJyZWF1bHRAaml2ZS5jb208L2E+Jmd0O108YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgODo1OSBQTTxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBUbzogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgJmd0OyBDYzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEJyYW5kb24gV2lsbGlhbXM7 IEFsYW4gSm9obnN0b247PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7IDxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPiAmbHQ7 bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPiZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgU3ViamVjdDog UmU6IFt0cmFtXSBUVVJOIGFuZCBmcmFnbWVudGF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyAmZ3Q7IE9uIE1vbiwgQXVnIDE4LCAyMDE0IGF0IDExOjI3IEFNLCBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iPnRpcmVkZHlAY2lzY28u Y29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSI+dGly ZWRkeUBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyAmZ3Q7ICZndDsgWWVzLCBJIGFtIHJlZmVycmluZyB0byBTVFVOIGZy YWdtZW50YXRpb24uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IEdvdCBpdCwgdGhh bmtzLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBTbywgd2hhdCdzIHlvdXIgaWRl YSwgaW4gZGV0YWlsID88YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBJIGhhdmUgbm90IHlldCBmaWd1 cmVkIG91dCBhbGwgdGhlIGRldGFpbHMsIGF0IGhpZ2ggbGV2ZWw8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO3RoaW5raW5nIHRoZSBwcm9ibGVtPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyBjYW4gYmUgc29sdmVkIHNpbWlsYXIgdG8gd2F5IGZyYWdtZW50 YXRpb24gaXMgaGFuZGxlZCBpbiBFQVAtVExTPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyAoPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTIxNiNz ZWN0aW9uLTIuMS41IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTIxNiNzZWN0aW9uLTIuMS41PC9hPikuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlua2luZyBhbG91ZC4gU1RVTiBmcmFnbWVudGF0aW9uIHBy b2JsZW0gY2FuIGJlIHNvbHZlZCBieSB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwO2ZvbGxvd2luZyBhcHByb2FjaDo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O1sxXSBJbnRyb2R1Y2UgYSBuZXcgU1RVTiBGUkFHTUVOVCBhdHRyaWJ1dGUgd2hpY2ggY2Fycmll cyB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZyYWdtZW50YXRpb24gZGV0 YWlscyBsaWtlIChNOiBNb3JlIGZyYWdtZW50czogd2hpY2ggaXMgc2V0IG9uIGFsbDxicj4NCiZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZnJhZ21lbnRzIGJ1dCB0aGUgbGFzdCBmcmFnbWVu dCksJm5ic3A7IFMgKEZyYWdtZW50YXRpb24gc3RhcnQpLDxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7SWRlbnRpZmllciBmb3Igc2VxdWVuY2luZyBldGMuKS48YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO1syXSBTVFVOIGF0dHJpYnV0ZSB0aGF0IHdvdWxkIGJlIHN1 YmplY3RlZCB0byBmcmFnbWVudGF0aW9uIHNob3VsZDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7YmUgcGxhY2VkIGFmdGVyIHRoZSBTVFVOIEZSQUdNRU5UIGF0dHJpYnV0ZS48YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO1szXSBUVVJOIHNlcnZlciB1c2VzIGEgbmV3 IFNUVU4gYXR0cmlidXRlIGxldOKAmXMgc2F5IEFDSyB0byBzaWduYWw8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwO2JhY2sgdG8gdGhlIGNsaWVudCB0aGF0IGl0IHJlY2VpdmVkIHRo ZSBmcmFnbWVudCBieSBzaWduYWxpbmcgYmFjazxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7dGhlIElkZW50aWZpZXIgaXQgcmVjZWl2ZWQgaW4gcmVxdWVzdC48YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO1s0XSBPbmNlIHRoZSBmaW5hbCBmcmFnbWVudCBpcyByZWNl aXZlZCwgVFVSTiBzZXJ2ZXIgbWVyZ2VzIHRoZTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ZnJhZ21lbnRzLCB2YWxpZGF0ZXMgdGhlIFNUVU4gbWVzc2FnZSBhbmQgcmVzcG9uZHMg YmFjayB0byB0aGUgY2xpZW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBXaGlsZSBJJ20gc3VyZSBzb21ldGhpbmcgbGlrZSB0aGF0IHdvdWxkIHdvcmssIGl0 IHNlZW1zIHByZXR0eTxicj4NCiZndDsgJmd0OyBjb21wbGljYXRlZCBhbmQgQUZBSUsgdGhlcmUg aXMgbm8gdXNlIGNhc2UgdGhhdCByZXF1aXJlcyBpdCBhdCB0aGU8YnI+DQomZ3Q7ICZndDsgbW9t ZW50LiBJIHRoaW5rIHdlIHNob3VsZCBzYXZlIHRoaXMgZm9yIGxhdGVyLCBhcyBvcHBvc2VkIHRv IHNvbHZpbmcgaXQ8YnI+DQomZ3Q7ICZndDsgaW4gdHVybi1iaXMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgSSBhZ3JlZSB0aGF0IGEgZnJhZ21lbnRhdGlvbiBzb2x1dGlvbiBkb2Vzbid0IGJlbG9uZyBk aXJlY3RseSBpbjxicj4NCiZndDsgdHVybi1iaXMuIFRoYXQgc2FpZCwgSSB0aGluayBlaXRoZXIg dHVybi1iaXMgb3Igc3R1bi1iaXMgbWlnaHQgbmVlZCB0bzxicj4NCiZndDsgcHJvdmlkZSBiZXR0 ZXIgZ3VpZGFuY2Ugb24gZnJhZ21lbnRhdGlvbi4gRm9yIGV4YW1wbGUsIHRoZSBjdXJyZW50PGJy Pg0KJmd0OyB3b3JkaW5nIGxpbWl0cyBzdHVuIG1lc3NhZ2VzIHRvIDU0OCBieXRlcyBpbiBjYXNl cyB3aGVyZSB0aGUgcGF0aCBNVFUgaXM8YnI+DQomZ3Q7IG5vdCB5ZXQga25vd24gYW5kIHRoZSBt ZXNzYWdlcyBpdHNlbGYgaXMgbm90IGJlaW5nIHVzZWQgdG8gcHJvYmUgdGhlPGJyPg0KJmd0OyBw YXRoIE1UVS4gSXQncyBlYXN5IHRvIGNvbWUgdXAgd2l0aCBhIHNldCBvZiByZWFzb25hYmxlIHZh bHVlcyBmb3IgYW48YnI+DQomZ3Q7IGFsbG9jYXRlIHJlcXVlc3QgKGF0IGxlYXN0KSB0aGF0IHdv dWxkIHZpb2xhdGUgdGhpcyByZXN0cmljdGlvbiw8YnI+DQomZ3Q7IGVzcGVjaWFsbHkgd2hlbiB5 b3UgYWRkIHRoZSBuZXcgb3JpZ2luIGFuZCAzcmQgcGFydHkgYXV0aCBhdHRyaWJ1dGVzLiBJbjxi cj4NCiZndDsgdGhlIHJhcmUgY2FzZSBvZiBhIGNsaWVudCB0aGF0IHJlYWxseSBkb2VzIGhhdmUg c3VjaCBhIHNtYWxsIFBNVFUsIHRoZTxicj4NCiZndDsgc3RhbmRhcmRzIGFzIGN1cnJlbnRseSBw dWJsaXNoZWQgY2FuIGFjdHVhbGx5IHByZXZlbnQgdGhlIGNsaWVudCBmcm9tPGJyPg0KJmd0OyBi ZWluZyBhYmxlIHRvIHVzZSBhIHR1cm4gcmVsYXkgdGhhdCByZWxpZXMgb24gdGhlIG5ldyBhdHRy aWJ1dGVzIHdpdGhvdXQ8YnI+DQomZ3Q7IGlnbm9yaW5nIHRoZSBmcmFnbWVudGF0aW9uIGd1aWRh bmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlR1bm5lbGluZyBUVVJOIG92ZXIgVFVSTiBmb3IgcHJpdmFjeSBwcm9wb3NlZCBpbiA8YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zY2h3YXJ0ei1ydGN3ZWItcmV0dXJu LTAwIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z Y2h3YXJ0ei1ydGN3ZWItcmV0dXJuLTAwPC9hPiBjb3VsZCBiZSBhbm90aGVyIHJlYXNvbiB0byBl dmFsdWF0ZSB0aGUgcmVhc29ucyB0byBzdXBwb3J0IFNUVU4gZnJhZ21lbnRhdGlvbi4gV2UgY2Fu IHJlbW92ZSBzdGVwIDMgb3B0aW1pemF0aW9uIHdoaWNoIHdvdWxkIHNpbXBsaWZ5IHRoZSBzb2x1 dGlvbi48YnI+DQo8YnI+DQotVGlydTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLUJyYW5kb248YnI+DQomZ3Q7 PGJyPg0KJmd0OyAtLTxicj4NCiZndDsgQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBh bCBTb2Z0d2FyZSBFbmdpbmVlcjxicj4NCiZndDsgRW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJp bmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2831A17Dxmbrcdx10ciscoc_-- From nobody Fri Aug 22 23:04:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB51A86FB for ; Fri, 22 Aug 2014 23:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0LljUTQ39PO for ; Fri, 22 Aug 2014 23:04:36 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763731A00E4 for ; Fri, 22 Aug 2014 23:04:36 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id ij19so13225679vcb.39 for ; Fri, 22 Aug 2014 23:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BcWjvgUsDh1nlMzHs4GFBheimm6pURm97/llWnc4pOY=; b=W711KAURxlwk2H3D41J00d5vU3B5CUxDLTpyr82WqjeJ7Xhfp5X4ATn/QhqLFNAMzD 3F7Awa6yxd+DrNaKSrRe512QwRWXlx+S2MpZuP1dYy0eMBduGcJ/KwV9/2Z3nOh/VvZ4 DG9fCJ1SE9566GdDlqR21tHYG/d4cAj3n7s7DEaL7RP2NzlDeDR+owOAg4DdJhdYfBAp zfRNxlxNjxGKHwALSvrOlCIWV4/zVqM2+hhHJ/lAg3na5Lw5pFFU3psXDG+h6yhImAF9 4xXwgShuNYD/+Dl4sBrXSF7snZCoBPB2sZUZrkV3e1sHGt7aL/9rPGNA4rIXjvCF/cia NE2Q== 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-type; bh=BcWjvgUsDh1nlMzHs4GFBheimm6pURm97/llWnc4pOY=; b=ILOEfxZG5bDRzKysl5F6dw/NXlos7fgr9RN3i3fZuhCZJjprwoS3mTuo+iBY7/IqSX TEK6wtkLomhzVK8+Ykj6sP4XgYlsqYWSoj8HRTyBnY/qOUNOxp5SO6X41A8mqErkszDw zbAdItm9UTEyHy3PP+EECMbRR3R1oN8hQXcKocxPxhu79+eRNGXq+K83bcbxNH2kb7Hm fvwAWWdmN/oh5RtwLIETKSy1gvahz5MqIDPanUW0zRS+zxSwy6JNT5m9GzjlRES/HNoU V3nWdhFBRjF8JAirIZYcDHV2TP4IlDahIn9LWB3id96QLED1Bmr79XZg9oSB58iGYvhB wu/Q== X-Gm-Message-State: ALoCoQnxw2hLkVo73aCOZgL47U68PxcrdsI+usS3WfkpXvsSFOnAqEAG+/lU8bV5IIq2CrvOMe33 X-Received: by 10.221.44.69 with SMTP id uf5mr7208196vcb.4.1408773875455; Fri, 22 Aug 2014 23:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.133.193 with HTTP; Fri, 22 Aug 2014 23:04:15 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2831A17D@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> <53F763A2.1000309@akamai.com> <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2831A17D@xmb-rcd-x10.cisco.com> From: Justin Uberti Date: Fri, 22 Aug 2014 23:04:15 -0700 Message-ID: To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11339e886a7b17050145ba98 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/01ReHvnct_70w4qXSJxDIQ7w0K0 Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 06:04:38 -0000 --001a11339e886a7b17050145ba98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In which case they should switch to using channels... reducing message overhead is the whole point of channels. On Fri, Aug 22, 2014 at 7:27 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Chrome seems to be using channels , but I thought other browsers like > firefox are using Send/Data indications. > > > > -Tiru > > > > *From:* Justin Uberti [mailto:juberti@google.com] > *Sent:* Saturday, August 23, 2014 5:27 AM > *To:* Tirumaleswar Reddy (tireddy) > *Cc:* Brandon Williams; Simon Perreault; Prashanth Patil (praspati); Alan > Johnston; tram@ietf.org > > *Subject:* Re: [tram] TURN and fragmentation > > > > I don't think RETURN requires us to handle fragmentation. As long as DATA > isn't sent recursively encapsulated, which I don't yet see a need for, th= e > only overhead is the 4-byte channel header. > > > > On Fri, Aug 22, 2014 at 9:25 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > > > -----Original Message----- > > From: Brandon Williams [mailto:brandon.williams@akamai.com] > > Sent: Friday, August 22, 2014 9:07 PM > > To: Justin Uberti; Tirumaleswar Reddy (tireddy) > > Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; > tram@ietf.org > > Subject: Re: [tram] TURN and fragmentation > > > > > > > > On 08/22/2014 12:57 AM, Justin Uberti wrote: > > > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy) > > > > wrote: > > > > > > > -----Original Message----- > > > > From: Tirumaleswar Reddy (tireddy) > > > > Sent: Monday, August 18, 2014 9:17 PM > > > > To: 'Simon Perreault' > > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan Johnsto= n; > > > > tram@ietf.org > > > > Subject: RE: [tram] TURN and fragmentation > > > > > > > > > -----Original Message----- > > > > > From: Simon Perreault [mailto:sperreault@jive.com > > > ] > > > > > Sent: Monday, August 18, 2014 8:59 PM > > > > > To: Tirumaleswar Reddy (tireddy) > > > > > Cc: Prashanth Patil (praspati); Brandon Williams; Alan > Johnston; > > > > > tram@ietf.org > > > > > Subject: Re: [tram] TURN and fragmentation > > > > > > > > > > On Mon, Aug 18, 2014 at 11:27 AM, Tirumaleswar Reddy (tiredd= y) > > > > > > wrote: > > > > > > Yes, I am referring to STUN fragmentation. > > > > > > > > > > Got it, thanks. > > > > > > > > > > So, what's your idea, in detail ? > > > > > > > > I have not yet figured out all the details, at high level > > > thinking the problem > > > > can be solved similar to way fragmentation is handled in EAP-T= LS > > > > (http://tools.ietf.org/html/rfc5216#section-2.1.5). > > > > > > Thinking aloud. STUN fragmentation problem can be solved by the > > > following approach: > > > [1] Introduce a new STUN FRAGMENT attribute which carries the > > > fragmentation details like (M: More fragments: which is set on al= l > > > fragments but the last fragment), S (Fragmentation start), > > > Identifier for sequencing etc.). > > > [2] STUN attribute that would be subjected to fragmentation shoul= d > > > be placed after the STUN FRAGMENT attribute. > > > [3] TURN server uses a new STUN attribute let=E2=80=99s say ACK t= o signal > > > back to the client that it received the fragment by signaling bac= k > > > the Identifier it received in request. > > > [4] Once the final fragment is received, TURN server merges the > > > fragments, validates the STUN message and responds back to the > client. > > > > > > > > > While I'm sure something like that would work, it seems pretty > > > complicated and AFAIK there is no use case that requires it at the > > > moment. I think we should save this for later, as opposed to solving = it > > > in turn-bis. > > > > I agree that a fragmentation solution doesn't belong directly in > > turn-bis. That said, I think either turn-bis or stun-bis might need to > > provide better guidance on fragmentation. For example, the current > > wording limits stun messages to 548 bytes in cases where the path MTU i= s > > not yet known and the messages itself is not being used to probe the > > path MTU. It's easy to come up with a set of reasonable values for an > > allocate request (at least) that would violate this restriction, > > especially when you add the new origin and 3rd party auth attributes. I= n > > the rare case of a client that really does have such a small PMTU, the > > standards as currently published can actually prevent the client from > > being able to use a turn relay that relies on the new attributes withou= t > > ignoring the fragmentation guidance. > > Tunneling TURN over TURN for privacy proposed in > http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be > another reason to evaluate the reasons to support STUN fragmentation. We > can remove step 3 optimization which would simplify the solution. > > -Tiru > > > > > > --Brandon > > > > -- > > Brandon Williams; Senior Principal Software Engineer > > Emerging Products Engineering; Akamai Technologies Inc. > > > --001a11339e886a7b17050145ba98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In which case they should switch to using channels... redu= cing message overhead is the whole point of channels.


On Fri, Aug 22, 2014 at 7:27 = PM, Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:<= br>

Chrome seems to be using = channels , but I thought other browsers like firefox are using Send/Data in= dications.

=C2=A0

-Tiru

=C2=A0

From: Justin U= berti [mailto:juber= ti@google.com]
Sent: Saturday, August 23, 2014 5:27 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Brandon Williams; Simon Perreault; Prashanth Patil (praspati); A= lan Johnston; tram@ietf.= org


Subject: Re: [tram] TURN and fragmentation
=

=C2=A0

I don't think RETURN requires us to handle fragm= entation. As long as DATA isn't sent recursively encapsulated, which I = don't yet see a need for, the only overhead is the 4-byte channel heade= r.

=C2=A0<= /p>

On Fri, Aug 22, 2014 at 9:25 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

> -----Original Me= ssage-----
> From: Brandon Williams [mailto:brandon.williams@akamai.com]
> Sent: Friday, August 22, 2014 9:07 PM
> To: Justin Uberti; Tirumaleswar Reddy (tireddy)
> Cc: Simon Perreault; Prashanth Patil (praspati); Alan Johnston; tram@ietf.org
> Subject: Re: [tram] TURN and fragmentation
>
>
>
> On 08/22/2014 12:57 AM, Justin Uberti wrote:
> > On Tue, Aug 19, 2014 at 2:15 AM, Tirumaleswar Reddy (tireddy)
> > <tiredd= y@cisco.com <mailto:tireddy@cisco.com>> wrote:
> >
> >=C2=A0 =C2=A0 =C2=A0 > -----Original Message-----
> >=C2=A0 =C2=A0 =C2=A0 > From: Tirumaleswar Reddy (tireddy)
> >=C2=A0 =C2=A0 =C2=A0 > Sent: Monday, August 18, 2014 9:17 PM > >=C2=A0 =C2=A0 =C2=A0 > To: 'Simon Perreault'
> >=C2=A0 =C2=A0 =C2=A0 > Cc: Prashanth Patil (praspati); Brandon = Williams; Alan Johnston;
> >=C2=A0 =C2=A0 =C2=A0 > tram@ietf.org <mailto:tram@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0 > Subject: RE: [tram] TURN and fragmentati= on
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > > -----Original Message-----
> >=C2=A0 =C2=A0 =C2=A0 > > From: Simon Perreault [mailto:sperreault@jive.com=
> >=C2=A0 =C2=A0 =C2=A0<mailto:sperreault@jive.com>]
> >=C2=A0 =C2=A0 =C2=A0 > > Sent: Monday, August 18, 2014 8:59 = PM
> >=C2=A0 =C2=A0 =C2=A0 > > To: Tirumaleswar Reddy (tireddy) > >=C2=A0 =C2=A0 =C2=A0 > > Cc: Prashanth Patil (praspati); Bra= ndon Williams; Alan Johnston;
> >=C2=A0 =C2=A0 =C2=A0 > > tram@ietf.org <mailto:tram@ietf.org>
> >=C2=A0 =C2=A0 =C2=A0 > > Subject: Re: [tram] TURN and fragme= ntation
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > On Mon, Aug 18, 2014 at 11:27 AM, T= irumaleswar Reddy (tireddy)
> >=C2=A0 =C2=A0 =C2=A0 > > <tireddy@cisco.com <mailto:tireddy@cisco.com>> wrote: > >=C2=A0 =C2=A0 =C2=A0 > > > Yes, I am referring to STUN fr= agmentation.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > Got it, thanks.
> >=C2=A0 =C2=A0 =C2=A0 > >
> >=C2=A0 =C2=A0 =C2=A0 > > So, what's your idea, in detail= ?
> >=C2=A0 =C2=A0 =C2=A0 >
> >=C2=A0 =C2=A0 =C2=A0 > I have not yet figured out all the detai= ls, at high level
> >=C2=A0 =C2=A0 =C2=A0thinking the problem
> >=C2=A0 =C2=A0 =C2=A0 > can be solved similar to way fragmentati= on is handled in EAP-TLS
> >=C2=A0 =C2=A0 =C2=A0 > (http://tools.ietf.org/html/rfc5216#= section-2.1.5).
> >
> >=C2=A0 =C2=A0 =C2=A0Thinking aloud. STUN fragmentation problem can= be solved by the
> >=C2=A0 =C2=A0 =C2=A0following approach:
> >=C2=A0 =C2=A0 =C2=A0[1] Introduce a new STUN FRAGMENT attribute wh= ich carries the
> >=C2=A0 =C2=A0 =C2=A0fragmentation details like (M: More fragments:= which is set on all
> >=C2=A0 =C2=A0 =C2=A0fragments but the last fragment),=C2=A0 S (Fra= gmentation start),
> >=C2=A0 =C2=A0 =C2=A0Identifier for sequencing etc.).
> >=C2=A0 =C2=A0 =C2=A0[2] STUN attribute that would be subjected to = fragmentation should
> >=C2=A0 =C2=A0 =C2=A0be placed after the STUN FRAGMENT attribute. > >=C2=A0 =C2=A0 =C2=A0[3] TURN server uses a new STUN attribute let= =E2=80=99s say ACK to signal
> >=C2=A0 =C2=A0 =C2=A0back to the client that it received the fragme= nt by signaling back
> >=C2=A0 =C2=A0 =C2=A0the Identifier it received in request.
> >=C2=A0 =C2=A0 =C2=A0[4] Once the final fragment is received, TURN = server merges the
> >=C2=A0 =C2=A0 =C2=A0fragments, validates the STUN message and resp= onds back to the client.
> >
> >
> > While I'm sure something like that would work, it seems prett= y
> > complicated and AFAIK there is no use case that requires it at th= e
> > moment. I think we should save this for later, as opposed to solv= ing it
> > in turn-bis.
>
> I agree that a fragmentation solution doesn't belong directly in > turn-bis. That said, I think either turn-bis or stun-bis might need to=
> provide better guidance on fragmentation. For example, the current
> wording limits stun messages to 548 bytes in cases where the path MTU = is
> not yet known and the messages itself is not being used to probe the > path MTU. It's easy to come up with a set of reasonable values for= an
> allocate request (at least) that would violate this restriction,
> especially when you add the new origin and 3rd party auth attributes. = In
> the rare case of a client that really does have such a small PMTU, the=
> standards as currently published can actually prevent the client from<= br> > being able to use a turn relay that relies on the new attributes witho= ut
> ignoring the fragmentation guidance.

Tunneling TURN over TURN for privacy proposed in http://tools.ietf.org/html/draft-schwartz-rtcweb-return-00 could be ano= ther reason to evaluate the reasons to support STUN fragmentation. We can r= emove step 3 optimization which would simplify the solution.

-Tiru


>
> --Brandon
>
> --
> Brandon Williams; Senior Principal Software Engineer
> Emerging Products Engineering; Akamai Technologies Inc.<= /p>

=C2=A0


--001a11339e886a7b17050145ba98-- From nobody Fri Aug 22 23:47:27 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22F81A8704 for ; Fri, 22 Aug 2014 23:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 okyd0JuNQGM5 for ; Fri, 22 Aug 2014 23:47:24 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EA41A8702 for ; Fri, 22 Aug 2014 23:47:23 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so527181wib.4 for ; Fri, 22 Aug 2014 23:47:22 -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:content-type; bh=GXu0qyqOZ1bKNl0esBC7IysNGFED/gg4T8VIfVwgJb8=; b=ib22GSTHYs0HxaVLKhAg/PuavdN/lIk+UuuHCaPeY49ibGA1Q7wKFAgXnhcLpQQY/s CcW+u8vhmVUMt/e3fqI2hj8/wBoXIOHFwgrJIlAu265Xd5eZtLvzgfUl90Ia83ZE6JYb UX0GIKVa0qLRJH08plfOcgqiaJ9mjnRHHn7DQOCJ9RH1QXsmeoFno0HOO7GoJwpRJWjx y/IDPTtfltdLogP7mN/wJ0ULC+WK1IVwStbrtjKdnKUxYvk4ytBmcC43K27bCsLfuQ2z 00/hIUrAUPse/OU52DCgZkCe/P0qm0IdWB3YbJVLhGGhrORPUtucChuVihb3/EWxIr4R vRKA== MIME-Version: 1.0 X-Received: by 10.180.80.165 with SMTP id s5mr2576684wix.61.1408776442530; Fri, 22 Aug 2014 23:47:22 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Fri, 22 Aug 2014 23:47:22 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> Date: Fri, 22 Aug 2014 23:47:22 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=14dae9cc93ac6cd0cd050146532c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VemEfp0E4_zQb1mj6n50s_QpSeQ Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 06:47:26 -0000 --14dae9cc93ac6cd0cd050146532c Content-Type: text/plain; charset=UTF-8 Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is mentioning the HMAC-SHA-1 algorithm with 160 bits key. This is actually incorrect: HMAC-SHA-1 has 160 bits output result, but it uses 128 bits input key, normally. Another problem is that I am not sure that the hash agility plan idea described in RFC5389 is still valid. I am afraid that it is unnecessary complicated and outdated, taking into account the current level of SHA-256 adoption. The plan was designed to support, "transparently", the old TURN servers. But in these specs, we do not necessary have to support the "old" servers with HMAC-SHA-1 only implementations; as we are writing a new oAuth procedure, there will be only "new" servers supporting the draft specs, anyway. The "old" servers will not be able to use the oAuth specs. SO we can design a cleaner simpler hash agility procedure. So the text has to be fixed: OLD TEXT: ---------------- key_length: Length of the session key. Key length of 160-bits MUST be supported (i.e only 160-bit key is used by HMAC-SHA-1 for message integrity of STUN message). The key length facilitates the hash agility plan discussed in section 16.3 of [RFC5389] . NEW TEXT: ------------------ key_length: Length of the session key. Key length of 128-bits MUST be supported (128-bit key is used by HMAC-SHA-1 for message integrity of STUN message). Key length of 256-bits SHOULD be supported (256-bit key is used by HMAC-SHA-256). Other key lengths MAY be supported. The key length facilitates the hash agility: the SHA digest algorithm is chosen depending on the key length. Thanks Oleg On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko wrote: > But I still think that making a single algorithm (like AES_256_CBC) > default across all use cases is a good idea, I just used wrong explanation > for that. > > Oleg > > > On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko > wrote: > >> Sorry, scratch that - I take back my comment. >> >> Thanks >> Oleg >> >> >> On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) < >> tireddy@cisco.com> wrote: >> >>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg >>> Moskalenko >>> *Sent:* Friday, August 22, 2014 12:27 PM >>> *To:* tram@ietf.org >>> *Subject:* [tram] draft-ietf-tram-turn-third-party-authz-03 >>> >>> >>> >>> I have the following comment: >>> >>> In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has >>> to be used, because the HKDF-Expand function of length 16 does not make >>> much sense, according to RFC 5869 section 2.3. >>> >>> So, I suggest to use AES_256_CBC consistently across the draft text as the default >>> encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, >>> >>> >>> anyway. >>> >>> [TR] Thanks, will that in the next revision. >>> >>> -Tiru >>> >>> Thanks >>> Oleg >>> >>> >> > --14dae9cc93ac6cd0cd050146532c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tiru, I found an error in the 6.2 section (ACCESS_TOK= EN). It is mentioning the HMAC-SHA-1 algorithm with 160 bits key. This is a= ctually incorrect: HMAC-SHA-1 has 160 bits output result, but it uses 128 b= its input key, normally.

Another problem is that I am not sure that the hash agility plan idea d= escribed in RFC5389 is still valid. I am afraid that it is unnecessary comp= licated and outdated, taking into account the current level of SHA-256 adop= tion. The plan was designed to support, "transparently", the old = TURN servers. But in these specs, we do not necessary have to support the &= quot;old" servers with HMAC-SHA-1 only implementations; as we are writ= ing a new oAuth procedure, there will be only "new" servers suppo= rting the draft specs, anyway. The "old" servers will not be able= to use the oAuth specs. SO we can design a cleaner simpler hash agility pr= ocedure.


So the text has to be fixed:

OLD TEXT:
----------------

 key_length:  Length of the session key.  Key le=
ngth of 160-bits MUST
      be supported (i.e only 160-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  The key length facilitates
      the hash agility plan discussed in section=C2=A016.3 of [RFC5389].


NEW TEXT:

------------------

 key_length:  Length of the session =
key.  Key length of 128-bits MUST
      be supported (128-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  Key length of 256-bits SHOU=
LD
      be supported (256-bit key is used by HMAC-SHA-256<=
/font>). Other key lengths
      MAY be supported. The key length facilitates the=
 hash agility: 

      the SHA digest algorithm is chosen depending on t=
he key length.

Thanks
Oleg
<=
br>



<= div class=3D"gmail_extra">

On Fri, Aug 22= , 2014 at 9:11 AM, Oleg Moskalenko <mom040267@gmail.com> w= rote:
But I still think that=C2= =A0making a single algorithm (like AES_256_CBC) default across all use case= s is a good idea, I just used wrong explanation for that.

Oleg


On Fri, Aug 22, 2014 at 8:34 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
Sorry, scratch that - I take back my comment.

Thanks
Oleg


On Fri, Aug 22, 2014 at 12:48 AM, Tiruma= leswar Reddy (tireddy) <tireddy@cisco.com> wrote:

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: tram@ietf.org=
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03<= /u>

=C2=A0

I have the following commen= t:

In the section 4.1.1 and 4.1.2, the encryption algorithm A= ES_256_CBC has to be used, because the HKDF-Expand function of length 16 do= es not make much sense, according to RFC 5869 section 2.3.= 

S=
o, I suggest to use AES_256_CBC consistently across the draft text as the d=
efault 
encryption algorithm. In the section 4.1.3 it is already used as=
 the default algorithm, 




anyway.
=
[TR] Thanks, will that in the next revision.
-Tiru=

Thanks
Oleg



--14dae9cc93ac6cd0cd050146532c-- From nobody Sat Aug 23 00:37:41 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B591A870C for ; Sat, 23 Aug 2014 00:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 LVCDksrK4zfp for ; Sat, 23 Aug 2014 00:37:37 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD761A8703 for ; Sat, 23 Aug 2014 00:37:37 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so11406057wes.22 for ; Sat, 23 Aug 2014 00:37:36 -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:content-type; bh=2KUKZF4HdDxOKNfDP65CKBDzYLA+LxFYvJhzdB8PkYo=; b=PXvxwVTkUZivCRl6J45JigZe6GQNN0SFZ47Yn0zKFODDDk7EDZd5OlHuJWbFBq1K7b pXI/O5GYQ9y+V0GlbKsEKRv0I7urkHvsH2cTzr/ODPbmSzrCpL9DQQpB+GRrv80c4TtX RxDLBWjp/OMoFXvRB2OKJwm7pDUeo5lwxZ+CUs7o/8evuY8vZDYu2A03tu+KtoEX33xG mIwMDPuSaNYhcPpjdnjY6f5G/YihMK9lTAGprnzg5eP458jRtJVv9StPQBUt1vcRRYNC 4pBvjSJzErcaw2eaROMbucm/SiqRQPoY0w3oXXqNfWRHsv7qN4C9XQ+L0i+QeF40SxJA +m2A== MIME-Version: 1.0 X-Received: by 10.180.106.138 with SMTP id gu10mr2888516wib.21.1408779456060; Sat, 23 Aug 2014 00:37:36 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Sat, 23 Aug 2014 00:37:35 -0700 (PDT) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> Date: Sat, 23 Aug 2014 00:37:35 -0700 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=e89a8f2345d30ba1940501470738 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/g_3faTkxwb764NEnprmGJe9V_Nw Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 07:37:39 -0000 --e89a8f2345d30ba1940501470738 Content-Type: text/plain; charset=UTF-8 Actually, although, normally, 128-bits keys are used with HMAC-SHA-1, other key lengths are possible with that function. I admit that my suggestion may not be entirely accurate. Oleg On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko wrote: > Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is mentioning > the HMAC-SHA-1 algorithm with 160 bits key. This is actually incorrect: > HMAC-SHA-1 has 160 bits output result, but it uses 128 bits input key, > normally. > > Another problem is that I am not sure that the hash agility plan idea > described in RFC5389 is still valid. I am afraid that it is unnecessary > complicated and outdated, taking into account the current level of SHA-256 > adoption. The plan was designed to support, "transparently", the old TURN > servers. But in these specs, we do not necessary have to support the "old" > servers with HMAC-SHA-1 only implementations; as we are writing a new oAuth > procedure, there will be only "new" servers supporting the draft specs, > anyway. The "old" servers will not be able to use the oAuth specs. SO we > can design a cleaner simpler hash agility procedure. > > > So the text has to be fixed: > > OLD TEXT: > ---------------- > > key_length: Length of the session key. Key length of 160-bits MUST > be supported (i.e only 160-bit key is used by HMAC-SHA-1 for > message integrity of STUN message). The key length facilitates > the hash agility plan discussed in section 16.3 of [RFC5389] . > > > NEW TEXT: > ------------------ > > key_length: Length of the session key. Key length of 128-bits MUST > be supported (128-bit key is used by HMAC-SHA-1 for > message integrity of STUN message). Key length of 256-bits SHOULD > be supported (256-bit key is used by HMAC-SHA-256). Other key lengths > MAY be supported. The key length facilitates the hash agility: > the SHA digest algorithm is chosen depending on the key length. > > Thanks > Oleg > > > > > > > On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko > wrote: > >> But I still think that making a single algorithm (like AES_256_CBC) >> default across all use cases is a good idea, I just used wrong explanation >> for that. >> >> Oleg >> >> >> On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko >> wrote: >> >>> Sorry, scratch that - I take back my comment. >>> >>> Thanks >>> Oleg >>> >>> >>> On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) < >>> tireddy@cisco.com> wrote: >>> >>>> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Oleg >>>> Moskalenko >>>> *Sent:* Friday, August 22, 2014 12:27 PM >>>> *To:* tram@ietf.org >>>> *Subject:* [tram] draft-ietf-tram-turn-third-party-authz-03 >>>> >>>> >>>> >>>> I have the following comment: >>>> >>>> In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC >>>> has to be used, because the HKDF-Expand function of length 16 does not make >>>> much sense, according to RFC 5869 section 2.3. >>>> >>>> So, I suggest to use AES_256_CBC consistently across the draft text as the default >>>> encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, >>>> >>>> >>>> >>>> anyway. >>>> >>>> [TR] Thanks, will that in the next revision. >>>> >>>> -Tiru >>>> >>>> Thanks >>>> Oleg >>>> >>>> >>> >> > --e89a8f2345d30ba1940501470738 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually, although, normally, 128-bits keys are used = with HMAC-SHA-1, other key lengths are possible with that function. I admit= that my suggestion may not be entirely accurate.

Oleg



On Fri,= Aug 22, 2014 at 11:47 PM, Oleg Moskalenko <mom040267@gmail.com><= /span> wrote:
Tiru, I found an error= in the 6.2 section (ACCESS_TOKEN). It is mentioning the HMAC-SHA-1 algorit= hm with 160 bits key. This is actually incorrect: HMAC-SHA-1 has 160 bits o= utput result, but it uses 128 bits input key, normally.

Another problem is that I am not sure that the hash agility plan idea d= escribed in RFC5389 is still valid. I am afraid that it is unnecessary comp= licated and outdated, taking into account the current level of SHA-256 adop= tion. The plan was designed to support, "transparently", the old = TURN servers. But in these specs, we do not necessary have to support the &= quot;old" servers with HMAC-SHA-1 only implementations; as we are writ= ing a new oAuth procedure, there will be only "new" servers suppo= rting the draft specs, anyway. The "old" servers will not be able= to use the oAuth specs. SO we can design a cleaner simpler hash agility pr= ocedure.


So the text has to be fixed:

OLD TEXT:
----------------

 key_length:  Length of the session key.  Key length of 160=
-bits MUST
      be supported (i.e only 160-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  The key length facilitates
      the hash agility plan discussed in section=C2=A016.3 of [RFC5389]<=
/a>.


NEW TEXT:


------------------

 key_length:  Length of the session =
key.  Key length of 128-bits MUST
      be supported (128-bit key is used by HMAC-SHA-1 for
      message integrity of STUN message).  Key length of 256-bits SHOU=
LD
      be supported (256-bit key is used by HMAC-SHA-256<=
/font>). Other key lengths
      MAY be supported. The key length facilitates the=
 hash agility: 


      the SHA digest algorithm is chosen depending on t=
he key length.

Thanks

Oleg




On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalen= ko <mom040267@gmail.com> wrote:
But I still think that=C2= =A0making a single algorithm (like AES_256_CBC) default across all use case= s is a good idea, I just used wrong explanation for that.

Oleg


On Fri, Aug 22, 2014 at 8:34 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
Sorry, scratch that - I take back my comment.

Thanks
Oleg


On Fri, Aug 22, 2014 at 12:48 AM, Tiruma= leswar Reddy (tireddy) <tireddy@cisco.com> wrote:

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Friday, August 22, 2014 12:27 PM
To: tram@ietf.org=
Subject: [tram] draft-ietf-tram-turn-third-party-authz-03<= /u>

=C2=A0

I have the following commen= t:

In the section 4.1.1 and 4.1.2, the encryption algorithm A= ES_256_CBC has to be used, because the HKDF-Expand function of length 16 do= es not make much sense, according to RFC 5869 section 2.3.= 

S=
o, I suggest to use AES_256_CBC consistently across the draft text as the d=
efault 
encryption algorithm. In the section 4.1.3 it is already used as=
 the default algorithm, 





anyway.
=
[TR] Thanks, will that in the next revision.
-Tiru=

Thanks
Oleg




--e89a8f2345d30ba1940501470738-- From nobody Sat Aug 23 07:40:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074DB1A036E for ; Sat, 23 Aug 2014 07:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-MPlPtH4v0D for ; Sat, 23 Aug 2014 07:40:01 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BD21A035E for ; Sat, 23 Aug 2014 07:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26780; q=dns/txt; s=iport; t=1408804800; x=1410014400; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WAo+HAUkJmqdV8oH6GYLdt897ScjXzVvPzKaMS0oyz4=; b=bJzSgmQmywK92DXW+t9YacuN/nQ66NMnC3Jz9LvvZWVl8K4PgoKQ0Swg i/rgH6ncZ0f3CLNrRaBCoSy4hQN6kwb9WyZNQDpEyasClmC0mEGGKNRr0 9rf49LGBqo47cFj9RRO5pJmxzdbNYh4savXLc+rcLvyeJHvTPVW0kMt5B 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAKCm+FOtJA2H/2dsb2JhbABZgkdGU1cEgnjIAoFjh00BGW4Wd4QDAQEBBCMKOhIMBAIBCA4DBAEBAQodAwICAjAUCQgCBA4FCBOIJw2vZJRJF48bFhsGAQaCczaBHQWFBAKMIIQpiFKTNIFkHoFcbAEBgQYkHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,386,1406592000"; d="scan'208,217";a="349828825" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 23 Aug 2014 14:39:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7NEdxRC004799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 14:39:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 09:39:59 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Justin Uberti Thread-Topic: [tram] TURN and fragmentation Thread-Index: Ac+7jhywuv5uhwsYToWrzO8B1UwDZgCYVwwAABZXXQAACSnGAAAISeUAAAXXCdAABv45gAAKYZ7A Date: Sat, 23 Aug 2014 14:39:58 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831A3A7@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28317C8D@xmb-rcd-x10.cisco.com> <53F763A2.1000309@akamai.com> <913383AAA69FF945B8F946018B75898A28319E8B@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2831A17D@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.200] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2831A3A7xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WZDo-AFeWnSEg7Xiq04qvSNBqPY Cc: "Prashanth Patil \(praspati\)" , Simon Perreault , Alan Johnston , "tram@ietf.org" , Brandon Williams Subject: Re: [tram] TURN and fragmentation X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:40:03 -0000 --_000_913383AAA69FF945B8F946018B75898A2831A3A7xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WXVwLCBhbnkgaWRlYSB3aHkgY2hhbm5lbCBpcyBub3QgdXNlZCA/DQoNCi1UaXJ1DQoNCkZyb206 IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTZW50OiBTYXR1cmRh eSwgQXVndXN0IDIzLCAyMDE0IDExOjM0IEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KQ0KQ2M6IEJyYW5kb24gV2lsbGlhbXM7IFNpbW9uIFBlcnJlYXVsdDsgUHJhc2hhbnRoIFBh dGlsIChwcmFzcGF0aSk7IEFsYW4gSm9obnN0b247IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21lbnRhdGlvbg0KDQpJbiB3aGljaCBjYXNlIHRoZXkgc2hv dWxkIHN3aXRjaCB0byB1c2luZyBjaGFubmVscy4uLiByZWR1Y2luZyBtZXNzYWdlIG92ZXJoZWFk IGlzIHRoZSB3aG9sZSBwb2ludCBvZiBjaGFubmVscy4NCg0KT24gRnJpLCBBdWcgMjIsIDIwMTQg YXQgNzoyNyBQTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5j b208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpDaHJvbWUgc2VlbXMgdG8gYmUg dXNpbmcgY2hhbm5lbHMgLCBidXQgSSB0aG91Z2h0IG90aGVyIGJyb3dzZXJzIGxpa2UgZmlyZWZv eCBhcmUgdXNpbmcgU2VuZC9EYXRhIGluZGljYXRpb25zLg0KDQotVGlydQ0KDQpGcm9tOiBKdXN0 aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb20+XQ0KU2VudDogU2F0dXJkYXksIEF1Z3VzdCAyMywgMjAxNCA1OjI3IEFNDQpUbzogVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IEJyYW5kb24gV2lsbGlhbXM7IFNpbW9uIFBl cnJlYXVsdDsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEFsYW4gSm9obnN0b247IHRyYW1A aWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbdHJhbV0gVFVS TiBhbmQgZnJhZ21lbnRhdGlvbg0KDQpJIGRvbid0IHRoaW5rIFJFVFVSTiByZXF1aXJlcyB1cyB0 byBoYW5kbGUgZnJhZ21lbnRhdGlvbi4gQXMgbG9uZyBhcyBEQVRBIGlzbid0IHNlbnQgcmVjdXJz aXZlbHkgZW5jYXBzdWxhdGVkLCB3aGljaCBJIGRvbid0IHlldCBzZWUgYSBuZWVkIGZvciwgdGhl IG9ubHkgb3ZlcmhlYWQgaXMgdGhlIDQtYnl0ZSBjaGFubmVsIGhlYWRlci4NCg0KT24gRnJpLCBB dWcgMjIsIDIwMTQgYXQgOToyNSBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGly ZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0bzpi cmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb208bWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFp LmNvbT5dDQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDIyLCAyMDE0IDk6MDcgUE0NCj4gVG86IEp1 c3RpbiBVYmVydGk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gQ2M6IFNpbW9uIFBl cnJlYXVsdDsgUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEFsYW4gSm9obnN0b247IHRyYW1A aWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gVFVS TiBhbmQgZnJhZ21lbnRhdGlvbg0KPg0KPg0KPg0KPiBPbiAwOC8yMi8yMDE0IDEyOjU3IEFNLCBK dXN0aW4gVWJlcnRpIHdyb3RlOg0KPiA+IE9uIFR1ZSwgQXVnIDE5LCAyMDE0IGF0IDI6MTUgQU0s IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPiA8dGlyZWRkeUBjaXNjby5jb208bWFp bHRvOnRpcmVkZHlAY2lzY28uY29tPiA8bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPG1haWx0bzp0 aXJlZGR5QGNpc2NvLmNvbT4+PiB3cm90ZToNCj4gPg0KPiA+ICAgICAgPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ICAgICAgPiBGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpDQo+ID4gICAgICA+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDE4LCAyMDE0IDk6MTcgUE0NCj4g PiAgICAgID4gVG86ICdTaW1vbiBQZXJyZWF1bHQnDQo+ID4gICAgICA+IENjOiBQcmFzaGFudGgg UGF0aWwgKHByYXNwYXRpKTsgQnJhbmRvbiBXaWxsaWFtczsgQWxhbiBKb2huc3RvbjsNCj4gPiAg ICAgID4gdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4gPG1haWx0bzp0cmFtQGll dGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPj4NCj4gPiAgICAgID4gU3ViamVjdDogUkU6IFt0 cmFtXSBUVVJOIGFuZCBmcmFnbWVudGF0aW9uDQo+ID4gICAgICA+DQo+ID4gICAgICA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiAgICAgID4gPiBGcm9tOiBTaW1vbiBQZXJyZWF1 bHQgW21haWx0bzpzcGVycmVhdWx0QGppdmUuY29tPG1haWx0bzpzcGVycmVhdWx0QGppdmUuY29t Pg0KPiA+ICAgICA8bWFpbHRvOnNwZXJyZWF1bHRAaml2ZS5jb208bWFpbHRvOnNwZXJyZWF1bHRA aml2ZS5jb20+Pl0NCj4gPiAgICAgID4gPiBTZW50OiBNb25kYXksIEF1Z3VzdCAxOCwgMjAxNCA4 OjU5IFBNDQo+ID4gICAgICA+ID4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4g PiAgICAgID4gPiBDYzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0aSk7IEJyYW5kb24gV2lsbGlh bXM7IEFsYW4gSm9obnN0b247DQo+ID4gICAgICA+ID4gdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz4gPG1haWx0bzp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPj4N Cj4gPiAgICAgID4gPiBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRpb24N Cj4gPiAgICAgID4gPg0KPiA+ICAgICAgPiA+IE9uIE1vbiwgQXVnIDE4LCAyMDE0IGF0IDExOjI3 IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4gICAgICA+ID4gPHRpcmVkZHlA Y2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbT4gPG1haWx0bzp0aXJlZGR5QGNpc2Nv LmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+Pj4gd3JvdGU6DQo+ID4gICAgICA+ID4gPiBZ ZXMsIEkgYW0gcmVmZXJyaW5nIHRvIFNUVU4gZnJhZ21lbnRhdGlvbi4NCj4gPiAgICAgID4gPg0K PiA+ICAgICAgPiA+IEdvdCBpdCwgdGhhbmtzLg0KPiA+ICAgICAgPiA+DQo+ID4gICAgICA+ID4g U28sIHdoYXQncyB5b3VyIGlkZWEsIGluIGRldGFpbCA/DQo+ID4gICAgICA+DQo+ID4gICAgICA+ IEkgaGF2ZSBub3QgeWV0IGZpZ3VyZWQgb3V0IGFsbCB0aGUgZGV0YWlscywgYXQgaGlnaCBsZXZl bA0KPiA+ICAgICB0aGlua2luZyB0aGUgcHJvYmxlbQ0KPiA+ICAgICAgPiBjYW4gYmUgc29sdmVk IHNpbWlsYXIgdG8gd2F5IGZyYWdtZW50YXRpb24gaXMgaGFuZGxlZCBpbiBFQVAtVExTDQo+ID4g ICAgICA+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjE2I3NlY3Rpb24tMi4xLjUp Lg0KPiA+DQo+ID4gICAgIFRoaW5raW5nIGFsb3VkLiBTVFVOIGZyYWdtZW50YXRpb24gcHJvYmxl bSBjYW4gYmUgc29sdmVkIGJ5IHRoZQ0KPiA+ICAgICBmb2xsb3dpbmcgYXBwcm9hY2g6DQo+ID4g ICAgIFsxXSBJbnRyb2R1Y2UgYSBuZXcgU1RVTiBGUkFHTUVOVCBhdHRyaWJ1dGUgd2hpY2ggY2Fy cmllcyB0aGUNCj4gPiAgICAgZnJhZ21lbnRhdGlvbiBkZXRhaWxzIGxpa2UgKE06IE1vcmUgZnJh Z21lbnRzOiB3aGljaCBpcyBzZXQgb24gYWxsDQo+ID4gICAgIGZyYWdtZW50cyBidXQgdGhlIGxh c3QgZnJhZ21lbnQpLCAgUyAoRnJhZ21lbnRhdGlvbiBzdGFydCksDQo+ID4gICAgIElkZW50aWZp ZXIgZm9yIHNlcXVlbmNpbmcgZXRjLikuDQo+ID4gICAgIFsyXSBTVFVOIGF0dHJpYnV0ZSB0aGF0 IHdvdWxkIGJlIHN1YmplY3RlZCB0byBmcmFnbWVudGF0aW9uIHNob3VsZA0KPiA+ICAgICBiZSBw bGFjZWQgYWZ0ZXIgdGhlIFNUVU4gRlJBR01FTlQgYXR0cmlidXRlLg0KPiA+ICAgICBbM10gVFVS TiBzZXJ2ZXIgdXNlcyBhIG5ldyBTVFVOIGF0dHJpYnV0ZSBsZXTigJlzIHNheSBBQ0sgdG8gc2ln bmFsDQo+ID4gICAgIGJhY2sgdG8gdGhlIGNsaWVudCB0aGF0IGl0IHJlY2VpdmVkIHRoZSBmcmFn bWVudCBieSBzaWduYWxpbmcgYmFjaw0KPiA+ICAgICB0aGUgSWRlbnRpZmllciBpdCByZWNlaXZl ZCBpbiByZXF1ZXN0Lg0KPiA+ICAgICBbNF0gT25jZSB0aGUgZmluYWwgZnJhZ21lbnQgaXMgcmVj ZWl2ZWQsIFRVUk4gc2VydmVyIG1lcmdlcyB0aGUNCj4gPiAgICAgZnJhZ21lbnRzLCB2YWxpZGF0 ZXMgdGhlIFNUVU4gbWVzc2FnZSBhbmQgcmVzcG9uZHMgYmFjayB0byB0aGUgY2xpZW50Lg0KPiA+ DQo+ID4NCj4gPiBXaGlsZSBJJ20gc3VyZSBzb21ldGhpbmcgbGlrZSB0aGF0IHdvdWxkIHdvcmss IGl0IHNlZW1zIHByZXR0eQ0KPiA+IGNvbXBsaWNhdGVkIGFuZCBBRkFJSyB0aGVyZSBpcyBubyB1 c2UgY2FzZSB0aGF0IHJlcXVpcmVzIGl0IGF0IHRoZQ0KPiA+IG1vbWVudC4gSSB0aGluayB3ZSBz aG91bGQgc2F2ZSB0aGlzIGZvciBsYXRlciwgYXMgb3Bwb3NlZCB0byBzb2x2aW5nIGl0DQo+ID4g aW4gdHVybi1iaXMuDQo+DQo+IEkgYWdyZWUgdGhhdCBhIGZyYWdtZW50YXRpb24gc29sdXRpb24g ZG9lc24ndCBiZWxvbmcgZGlyZWN0bHkgaW4NCj4gdHVybi1iaXMuIFRoYXQgc2FpZCwgSSB0aGlu ayBlaXRoZXIgdHVybi1iaXMgb3Igc3R1bi1iaXMgbWlnaHQgbmVlZCB0bw0KPiBwcm92aWRlIGJl dHRlciBndWlkYW5jZSBvbiBmcmFnbWVudGF0aW9uLiBGb3IgZXhhbXBsZSwgdGhlIGN1cnJlbnQN Cj4gd29yZGluZyBsaW1pdHMgc3R1biBtZXNzYWdlcyB0byA1NDggYnl0ZXMgaW4gY2FzZXMgd2hl cmUgdGhlIHBhdGggTVRVIGlzDQo+IG5vdCB5ZXQga25vd24gYW5kIHRoZSBtZXNzYWdlcyBpdHNl bGYgaXMgbm90IGJlaW5nIHVzZWQgdG8gcHJvYmUgdGhlDQo+IHBhdGggTVRVLiBJdCdzIGVhc3kg dG8gY29tZSB1cCB3aXRoIGEgc2V0IG9mIHJlYXNvbmFibGUgdmFsdWVzIGZvciBhbg0KPiBhbGxv Y2F0ZSByZXF1ZXN0IChhdCBsZWFzdCkgdGhhdCB3b3VsZCB2aW9sYXRlIHRoaXMgcmVzdHJpY3Rp b24sDQo+IGVzcGVjaWFsbHkgd2hlbiB5b3UgYWRkIHRoZSBuZXcgb3JpZ2luIGFuZCAzcmQgcGFy dHkgYXV0aCBhdHRyaWJ1dGVzLiBJbg0KPiB0aGUgcmFyZSBjYXNlIG9mIGEgY2xpZW50IHRoYXQg cmVhbGx5IGRvZXMgaGF2ZSBzdWNoIGEgc21hbGwgUE1UVSwgdGhlDQo+IHN0YW5kYXJkcyBhcyBj dXJyZW50bHkgcHVibGlzaGVkIGNhbiBhY3R1YWxseSBwcmV2ZW50IHRoZSBjbGllbnQgZnJvbQ0K PiBiZWluZyBhYmxlIHRvIHVzZSBhIHR1cm4gcmVsYXkgdGhhdCByZWxpZXMgb24gdGhlIG5ldyBh dHRyaWJ1dGVzIHdpdGhvdXQNCj4gaWdub3JpbmcgdGhlIGZyYWdtZW50YXRpb24gZ3VpZGFuY2Uu DQpUdW5uZWxpbmcgVFVSTiBvdmVyIFRVUk4gZm9yIHByaXZhY3kgcHJvcG9zZWQgaW4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wMCBjb3Vs ZCBiZSBhbm90aGVyIHJlYXNvbiB0byBldmFsdWF0ZSB0aGUgcmVhc29ucyB0byBzdXBwb3J0IFNU VU4gZnJhZ21lbnRhdGlvbi4gV2UgY2FuIHJlbW92ZSBzdGVwIDMgb3B0aW1pemF0aW9uIHdoaWNo IHdvdWxkIHNpbXBsaWZ5IHRoZSBzb2x1dGlvbi4NCg0KLVRpcnUNCg0KPg0KPiAtLUJyYW5kb24N Cj4NCj4gLS0NCj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBF bmdpbmVlcg0KPiBFbWVyZ2luZyBQcm9kdWN0cyBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xv Z2llcyBJbmMuDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A2831A3A7xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pll1cCwgYW55IGlkZWEgd2h5IGNoYW5uZWwgaXMgbm90IHVzZWQgPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSnVzdGluIFViZXJ0 aSBbbWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRh eSwgQXVndXN0IDIzLCAyMDE0IDExOjM0IEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIg UmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiBCcmFuZG9uIFdpbGxpYW1zOyBTaW1vbiBQ ZXJyZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBBbGFuIEpvaG5zdG9uOyB0cmFt QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21l bnRhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbiB3aGljaCBjYXNlIHRoZXkgc2hvdWxkIHN3aXRjaCB0byB1c2luZyBjaGFubmVscy4u LiByZWR1Y2luZyBtZXNzYWdlIG92ZXJoZWFkIGlzIHRoZSB3aG9sZSBwb2ludCBvZiBjaGFubmVs cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcgMjIsIDIwMTQgYXQgNzoyNyBQTSwgVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyb21lIHNlZW1zIHRvIGJl IHVzaW5nIGNoYW5uZWxzICwgYnV0IEkgdGhvdWdodCBvdGhlciBicm93c2VycyBsaWtlIGZpcmVm b3ggYXJlIHVzaW5nIFNlbmQvRGF0YQ0KIGluZGljYXRpb25zLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4g VWJlcnRpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0 dXJkYXksIEF1Z3VzdCAyMywgMjAxNCA1OjI3IEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiBCcmFuZG9uIFdpbGxpYW1zOyBTaW1v biBQZXJyZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBBbGFuIEpvaG5zdG9uOw0K PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYu b3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gVFVSTiBhbmQgZnJhZ21l bnRhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGRvbid0IHRoaW5rIFJFVFVSTiByZXF1 aXJlcyB1cyB0byBoYW5kbGUgZnJhZ21lbnRhdGlvbi4gQXMgbG9uZyBhcyBEQVRBIGlzbid0IHNl bnQgcmVjdXJzaXZlbHkgZW5jYXBzdWxhdGVkLCB3aGljaCBJIGRvbid0IHlldCBzZWUgYSBuZWVk IGZvciwgdGhlIG9ubHkgb3ZlcmhlYWQgaXMgdGhlIDQtYnl0ZQ0KIGNoYW5uZWwgaGVhZGVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgQXVnIDIy LCAyMDE0IGF0IDk6MjUgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lz Y28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJv bTogQnJhbmRvbiBXaWxsaWFtcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpicmFuZG9uLndpbGxp YW1zQGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5icmFuZG9uLndpbGxpYW1zQGFrYW1haS5j b208L2E+XTxicj4NCiZndDsgU2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgOTowNyBQTTxi cj4NCiZndDsgVG86IEp1c3RpbiBVYmVydGk7IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8 YnI+DQomZ3Q7IENjOiBTaW1vbiBQZXJyZWF1bHQ7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkp OyBBbGFuIEpvaG5zdG9uOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPg0KdHJhbUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbdHJhbV0g VFVSTiBhbmQgZnJhZ21lbnRhdGlvbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgT24gMDgvMjIvMjAxNCAxMjo1NyBBTSwgSnVzdGluIFViZXJ0aSB3cm90ZTo8YnI+DQom Z3Q7ICZndDsgT24gVHVlLCBBdWcgMTksIDIwMTQgYXQgMjoxNSBBTSwgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTxicj4NCiZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+ICZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGly ZWRkeUBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgRnJvbTogVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsgU2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgOToxNyBQTTxicj4NCiZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgVG86ICdTaW1vbiBQZXJyZWF1bHQnPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBDYzogUHJhc2hhbnRoIFBhdGlsIChwcmFzcGF0 aSk7IEJyYW5kb24gV2lsbGlhbXM7IEFsYW4gSm9obnN0b247PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRy YW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPiZndDs8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFN1YmplY3Q6IFJFOiBbdHJhbV0gVFVS TiBhbmQgZnJhZ21lbnRhdGlvbjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 ICZndDsgRnJvbTogU2ltb24gUGVycmVhdWx0IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwZXJy ZWF1bHRAaml2ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVycmVhdWx0QGppdmUuY29tPC9hPjxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86c3BlcnJlYXVsdEBqaXZlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZXJyZWF1bHRAaml2ZS5j b208L2E+Jmd0O108YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsg U2VudDogTW9uZGF5LCBBdWd1c3QgMTgsIDIwMTQgODo1OSBQTTxicj4NCiZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBDYzogUHJhc2hh bnRoIFBhdGlsIChwcmFzcGF0aSk7IEJyYW5kb24gV2lsbGlhbXM7IEFsYW4gSm9obnN0b247PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0 bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT4gJmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1A aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsg Jmd0OyBTdWJqZWN0OiBSZTogW3RyYW1dIFRVUk4gYW5kIGZyYWdtZW50YXRpb248YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgT24gTW9uLCBBdWcgMTgsIDIwMTQgYXQgMTE6MjcgQU0s IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29tPC9hPiAmbHQ7bWFpbHRvOjxhIGhyZWY9 Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28u Y29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsgJmd0OyAmZ3Q7IFllcywgSSBhbSByZWZlcnJpbmcgdG8gU1RVTiBmcmFnbWVudGF0aW9u Ljxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmd0OyBHb3QgaXQsIHRoYW5rcy48YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZndDsgU28sIHdoYXQncyB5b3VyIGlkZWEsIGluIGRldGFp bCA/PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgSSBoYXZlIG5vdCB5ZXQgZmlndXJlZCBvdXQgYWxs IHRoZSBkZXRhaWxzLCBhdCBoaWdoIGxldmVsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDt0aGlua2luZyB0aGUgcHJvYmxlbTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsgY2FuIGJlIHNvbHZlZCBzaW1pbGFyIHRvIHdheSBmcmFnbWVudGF0aW9uIGlzIGhh bmRsZWQgaW4gRUFQLVRMUzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsg KDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMTYjc2VjdGlvbi0yLjEu NSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMTYjc2Vj dGlvbi0yLjEuNTwvYT4pLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7VGhpbmtpbmcgYWxvdWQuIFNUVU4gZnJhZ21lbnRhdGlvbiBwcm9ibGVtIGNhbiBi ZSBzb2x2ZWQgYnkgdGhlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtmb2xsb3dp bmcgYXBwcm9hY2g6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtbMV0gSW50cm9k dWNlIGEgbmV3IFNUVU4gRlJBR01FTlQgYXR0cmlidXRlIHdoaWNoIGNhcnJpZXMgdGhlPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtmcmFnbWVudGF0aW9uIGRldGFpbHMgbGlrZSAo TTogTW9yZSBmcmFnbWVudHM6IHdoaWNoIGlzIHNldCBvbiBhbGw8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwO2ZyYWdtZW50cyBidXQgdGhlIGxhc3QgZnJhZ21lbnQpLCZuYnNwOyBT IChGcmFnbWVudGF0aW9uIHN0YXJ0KSw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O0lkZW50aWZpZXIgZm9yIHNlcXVlbmNpbmcgZXRjLikuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtbMl0gU1RVTiBhdHRyaWJ1dGUgdGhhdCB3b3VsZCBiZSBzdWJqZWN0ZWQgdG8g ZnJhZ21lbnRhdGlvbiBzaG91bGQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Jl IHBsYWNlZCBhZnRlciB0aGUgU1RVTiBGUkFHTUVOVCBhdHRyaWJ1dGUuPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtbM10gVFVSTiBzZXJ2ZXIgdXNlcyBhIG5ldyBTVFVOIGF0dHJp YnV0ZSBsZXTigJlzIHNheSBBQ0sgdG8gc2lnbmFsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDtiYWNrIHRvIHRoZSBjbGllbnQgdGhhdCBpdCByZWNlaXZlZCB0aGUgZnJhZ21lbnQg Ynkgc2lnbmFsaW5nIGJhY2s8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBJ ZGVudGlmaWVyIGl0IHJlY2VpdmVkIGluIHJlcXVlc3QuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDtbNF0gT25jZSB0aGUgZmluYWwgZnJhZ21lbnQgaXMgcmVjZWl2ZWQsIFRVUk4g c2VydmVyIG1lcmdlcyB0aGU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2ZyYWdt ZW50cywgdmFsaWRhdGVzIHRoZSBTVFVOIG1lc3NhZ2UgYW5kIHJlc3BvbmRzIGJhY2sgdG8gdGhl IGNsaWVudC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2hp bGUgSSdtIHN1cmUgc29tZXRoaW5nIGxpa2UgdGhhdCB3b3VsZCB3b3JrLCBpdCBzZWVtcyBwcmV0 dHk8YnI+DQomZ3Q7ICZndDsgY29tcGxpY2F0ZWQgYW5kIEFGQUlLIHRoZXJlIGlzIG5vIHVzZSBj YXNlIHRoYXQgcmVxdWlyZXMgaXQgYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7IG1vbWVudC4gSSB0aGlu ayB3ZSBzaG91bGQgc2F2ZSB0aGlzIGZvciBsYXRlciwgYXMgb3Bwb3NlZCB0byBzb2x2aW5nIGl0 PGJyPg0KJmd0OyAmZ3Q7IGluIHR1cm4tYmlzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgYWdyZWUg dGhhdCBhIGZyYWdtZW50YXRpb24gc29sdXRpb24gZG9lc24ndCBiZWxvbmcgZGlyZWN0bHkgaW48 YnI+DQomZ3Q7IHR1cm4tYmlzLiBUaGF0IHNhaWQsIEkgdGhpbmsgZWl0aGVyIHR1cm4tYmlzIG9y IHN0dW4tYmlzIG1pZ2h0IG5lZWQgdG88YnI+DQomZ3Q7IHByb3ZpZGUgYmV0dGVyIGd1aWRhbmNl IG9uIGZyYWdtZW50YXRpb24uIEZvciBleGFtcGxlLCB0aGUgY3VycmVudDxicj4NCiZndDsgd29y ZGluZyBsaW1pdHMgc3R1biBtZXNzYWdlcyB0byA1NDggYnl0ZXMgaW4gY2FzZXMgd2hlcmUgdGhl IHBhdGggTVRVIGlzPGJyPg0KJmd0OyBub3QgeWV0IGtub3duIGFuZCB0aGUgbWVzc2FnZXMgaXRz ZWxmIGlzIG5vdCBiZWluZyB1c2VkIHRvIHByb2JlIHRoZTxicj4NCiZndDsgcGF0aCBNVFUuIEl0 J3MgZWFzeSB0byBjb21lIHVwIHdpdGggYSBzZXQgb2YgcmVhc29uYWJsZSB2YWx1ZXMgZm9yIGFu PGJyPg0KJmd0OyBhbGxvY2F0ZSByZXF1ZXN0IChhdCBsZWFzdCkgdGhhdCB3b3VsZCB2aW9sYXRl IHRoaXMgcmVzdHJpY3Rpb24sPGJyPg0KJmd0OyBlc3BlY2lhbGx5IHdoZW4geW91IGFkZCB0aGUg bmV3IG9yaWdpbiBhbmQgM3JkIHBhcnR5IGF1dGggYXR0cmlidXRlcy4gSW48YnI+DQomZ3Q7IHRo ZSByYXJlIGNhc2Ugb2YgYSBjbGllbnQgdGhhdCByZWFsbHkgZG9lcyBoYXZlIHN1Y2ggYSBzbWFs bCBQTVRVLCB0aGU8YnI+DQomZ3Q7IHN0YW5kYXJkcyBhcyBjdXJyZW50bHkgcHVibGlzaGVkIGNh biBhY3R1YWxseSBwcmV2ZW50IHRoZSBjbGllbnQgZnJvbTxicj4NCiZndDsgYmVpbmcgYWJsZSB0 byB1c2UgYSB0dXJuIHJlbGF5IHRoYXQgcmVsaWVzIG9uIHRoZSBuZXcgYXR0cmlidXRlcyB3aXRo b3V0PGJyPg0KJmd0OyBpZ25vcmluZyB0aGUgZnJhZ21lbnRhdGlvbiBndWlkYW5jZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlR1bm5lbGlu ZyBUVVJOIG92ZXIgVFVSTiBmb3IgcHJpdmFjeSBwcm9wb3NlZCBpbg0KPGEgaHJlZj0iaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHotcnRjd2ViLXJldHVybi0wMCIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Nod2FydHot cnRjd2ViLXJldHVybi0wMDwvYT4gY291bGQgYmUgYW5vdGhlciByZWFzb24gdG8gZXZhbHVhdGUg dGhlIHJlYXNvbnMgdG8gc3VwcG9ydCBTVFVOIGZyYWdtZW50YXRpb24uIFdlIGNhbiByZW1vdmUg c3RlcCAzIG9wdGltaXphdGlvbiB3aGljaCB3b3VsZCBzaW1wbGlmeSB0aGUgc29sdXRpb24uPGJy Pg0KPGJyPg0KLVRpcnU8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLUJyYW5kb248YnI+DQomZ3Q7PGJyPg0K Jmd0OyAtLTxicj4NCiZndDsgQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0 d2FyZSBFbmdpbmVlcjxicj4NCiZndDsgRW1lcmdpbmcgUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFr YW1haSBUZWNobm9sb2dpZXMgSW5jLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A2831A3A7xmbrcdx10ciscoc_-- From nobody Sat Aug 23 07:41:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA331A036E for ; Sat, 23 Aug 2014 07:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKgh93rlYAZy for ; Sat, 23 Aug 2014 07:41:42 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84F61A035E for ; Sat, 23 Aug 2014 07:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13190; q=dns/txt; s=iport; t=1408804901; x=1410014501; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GECtEWAM4Xvn/ktr0ncxlXlb2mIqkKhs39B86RS0Oto=; b=kJFIK+MOToyjbu3drtMVciP+niljoTb3AIdYqwdYFfni8EZc8yPDfIKs YgJHCrYKnx0hn84Yh6jsqRZ/bXAOD6m/6Xx4Z9kmsdXTi6+5oqA5F1Xv0 WOS6rRb6Tu8JUc1qcYDtjv3YlDAldXaL5BVfLKsJ3Y+n1WRopDCGNTfGk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFAFen+FOtJV2c/2dsb2JhbABZgkdGU1cEgnjRMgEZbhZ3hAMBAQEEIwpMEAIBCA4DBAEBCx0DAgICHxEUCQgCBA4FCIgmAxGvco8aDYUiF40fgXwWGwYBgnk2gR0FjxOCE4kTkGeGNYNebIFIgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,386,1406592000"; d="scan'208,217"; a="71765157" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 23 Aug 2014 14:41:41 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7NEffqG002602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 14:41:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 09:41:40 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPvh6kq35uUUTVWUmRVXfrcnASwZvdHvyAgAElPIA= Date: Sat, 23 Aug 2014 14:41:40 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831A3BB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.200] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2831A3BBxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tohjBuyZlincRb0-60CKoz4fZUI Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 14:41:43 -0000 --_000_913383AAA69FF945B8F946018B75898A2831A3BBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gcHJvYmxlbSwgIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHVzZSBzaW5nbGUgYWxnb3JpdGhtLg0K DQpUaGFua3MsDQotVGlydQ0KDQpGcm9tOiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAy NjdAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgOTo0MSBQTQ0KVG86 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3RyYW1dIGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAzDQoN CkJ1dCBJIHN0aWxsIHRoaW5rIHRoYXQgbWFraW5nIGEgc2luZ2xlIGFsZ29yaXRobSAobGlrZSBB RVNfMjU2X0NCQykgZGVmYXVsdCBhY3Jvc3MgYWxsIHVzZSBjYXNlcyBpcyBhIGdvb2QgaWRlYSwg SSBqdXN0IHVzZWQgd3JvbmcgZXhwbGFuYXRpb24gZm9yIHRoYXQuDQoNCk9sZWcNCg0KT24gRnJp LCBBdWcgMjIsIDIwMTQgYXQgODozNCBBTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20wNDAyNjdAZ21h aWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpTb3JyeSwgc2NyYXRj aCB0aGF0IC0gSSB0YWtlIGJhY2sgbXkgY29tbWVudC4NCg0KVGhhbmtzDQpPbGVnDQoNCk9uIEZy aSwgQXVnIDIyLCAyMDE0IGF0IDEyOjQ4IEFNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp IDx0aXJlZGR5QGNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBjaXNjby5jb20+PiB3cm90ZToNCkZy b206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBPbGVnIE1vc2thbGVua28NClNlbnQ6IEZyaWRheSwg QXVndXN0IDIyLCAyMDE0IDEyOjI3IFBNDQpUbzogdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0 eS1hdXRoei0wMw0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50Og0KSW4gdGhlIHNlY3Rp b24gNC4xLjEgYW5kIDQuMS4yLCB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gQUVTXzI1Nl9DQkMg aGFzIHRvIGJlIHVzZWQsIGJlY2F1c2UgdGhlIEhLREYtRXhwYW5kIGZ1bmN0aW9uIG9mIGxlbmd0 aCAxNiBkb2VzIG5vdCBtYWtlIG11Y2ggc2Vuc2UsIGFjY29yZGluZyB0byBSRkMgNTg2OSBzZWN0 aW9uIDIuMy4NCg0KU28sIEkgc3VnZ2VzdCB0byB1c2UgQUVTXzI1Nl9DQkMgY29uc2lzdGVudGx5 IGFjcm9zcyB0aGUgZHJhZnQgdGV4dCBhcyB0aGUgZGVmYXVsdA0KZW5jcnlwdGlvbiBhbGdvcml0 aG0uIEluIHRoZSBzZWN0aW9uIDQuMS4zIGl0IGlzIGFscmVhZHkgdXNlZCBhcyB0aGUgZGVmYXVs dCBhbGdvcml0aG0sDQoNCg0KDQoNCg0KDQphbnl3YXkuDQoNCltUUl0gVGhhbmtzLCB3aWxsIHRo YXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCi1UaXJ1DQoNClRoYW5rcw0KT2xlZw0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A2831A3BBxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29sYXMiLCJzZXJpZiI7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIHByb2Js ZW0sJm5ic3A7IHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIHVzZSBzaW5nbGUgYWxnb3JpdGhtLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21h aWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVn dXN0IDIyLCAyMDE0IDk6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSk8YnI+DQo8Yj5DYzo8L2I+IHRyYW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQg SSBzdGlsbCB0aGluayB0aGF0Jm5ic3A7bWFraW5nIGEgc2luZ2xlIGFsZ29yaXRobSAobGlrZSBB RVNfMjU2X0NCQykgZGVmYXVsdCBhY3Jvc3MgYWxsIHVzZSBjYXNlcyBpcyBhIGdvb2QgaWRlYSwg SSBqdXN0IHVzZWQgd3JvbmcgZXhwbGFuYXRpb24gZm9yIHRoYXQuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbGVnPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gRnJpLCBBdWcgMjIsIDIwMTQgYXQgODozNCBBTSwgT2xlZyBNb3NrYWxlbmtvICZsdDs8 YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vbTA0 MDI2N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Tb3JyeSwgc2NyYXRjaCB0aGF0IC0gSSB0YWtlIGJhY2sgbXkgY29t bWVudC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPk9sZWc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEF1ZyAyMiwgMjAxNCBhdCAxMjo0OCBBTSwgVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPk9sZWcgTW9za2FsZW5rbzxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEF1Z3VzdCAyMiwgMjAxNCAxMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFp bHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHkt YXV0aHotMDM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhdmUgdGhlIGZvbGxvd2luZyBj b21tZW50Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SW4gdGhlIHNlY3Rpb24gNC4xLjEgYW5kIDQuMS4yLCB0aGUgZW5jcnlw dGlvbiBhbGdvcml0aG0gQUVTXzI1Nl9DQkMgaGFzIHRvIGJlIHVzZWQsIGJlY2F1c2UgdGhlIEhL REYtRXhwYW5kIGZ1bmN0aW9uIG9mIGxlbmd0aCAxNg0KIGRvZXMgbm90IG1ha2UgbXVjaCBzZW5z ZSwgYWNjb3JkaW5nIHRvIFJGQyA1ODY5IHNlY3Rpb24gMi4zLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlNvLCBJIHN1Z2dlc3QgdG8gdXNlIEFFU18yNTZfQ0JDIGNvbnNp c3RlbnRseSBhY3Jvc3MgdGhlIGRyYWZ0IHRleHQgYXMgdGhlIGRlZmF1bHQgPGJyPmVuY3J5cHRp b24gYWxnb3JpdGhtLiBJbiB0aGUgc2VjdGlvbiA0LjEuMyBpdCBpcyBhbHJlYWR5IHVzZWQgYXMg dGhlIGRlZmF1bHQgYWxnb3JpdGhtLCA8YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmFueXdheS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gVGhhbmtzLCB3aWxsIHRoYXQgaW4gdGhlIG5leHQgcmV2 aXNpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRoYW5rczxicj5PbGVnPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_913383AAA69FF945B8F946018B75898A2831A3BBxmbrcdx10ciscoc_-- From nobody Sat Aug 23 08:18:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF9F1A02E5 for ; Sat, 23 Aug 2014 08:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybvTtXW4Rl_f for ; Sat, 23 Aug 2014 08:18:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785961A02E4 for ; Sat, 23 Aug 2014 08:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27992; q=dns/txt; s=iport; t=1408807098; x=1410016698; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Cv58xRfo39cYoBG6xFS2lakU0czbjwT7OxQLq/Isylo=; b=Cw7NY5RkjpBGNtbPjkNTp4YfTo9n7t8L87UH2bW9TFMEbfJhKkC4meR6 St68z0+tFeu1c1LwMMNV7WnoV5V15WiTToiLRPoLtcXsEkAA4tWjA/SkC 0LE5rokOlbuaFd4obfQFEnN+q+2oKdB4m4BpWcJID7fcMjQVUc5VuBcId g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFAIOv+FOtJV2S/2dsb2JhbABZgkdGU1cEgnjIAoFjh00BGW4Wd4QDAQEBBCMKTBACAQgOAwQBAQsLCwcDAgICHxEUCQgCBA4FCIgmAxENr2GPFw2FIheNH4F8FhsGAQYEgm82gR0FhhGJAoIThCmEaoNojH+GNYFmHIFcbAEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,386,1406592000"; d="scan'208,217";a="349550253" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 23 Aug 2014 15:18:17 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7NFIHA1025540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Aug 2014 15:18:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 23 Aug 2014 10:18:17 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPvh6kq35uUUTVWUmRVXfrcnASwZvdHvyAgAD0xgCAAA4IgIAAIsgQ Date: Sat, 23 Aug 2014 15:18:17 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831A3E5@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.200] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A2831A3E5xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/H4rCmjPbTzdKYEKxU0xDo3bcSOM Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 15:18:21 -0000 --_000_913383AAA69FF945B8F946018B75898A2831A3E5xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODY4I3NlY3Rpb24tMi4xLjEgZGlz Y3Vzc2VzIHRoZSBrZXkgbGVuZ3RoIGFuZCBvdXRwdXQgbGVuZ3RoOw0KPHNuaXA+DQprZXkgbGVu Z3RocyBsZXNzIHRoYW4gdGhlIG91dHB1dCBsZW5ndGgNCmRlY3JlYXNlIHNlY3VyaXR5IHN0cmVu Z3RoLCBhbmQga2V5cyBsb25nZXIgdGhhbiB0aGUgb3V0cHV0IGxlbmd0aCBkbw0Kbm90IHNpZ25p ZmljYW50bHkgaW5jcmVhc2Ugc2VjdXJpdHkgc3RyZW5ndGgNCjwvc25pcD4NCg0KTGV0IG1lIGtu b3cgaWYgeW91IHN0aWxsIHRoaW5rIHRoZSBiZWxvdyB0ZXh0IG5lZWRzIHRvIGJlIGZpeGVkLg0K DQpGb3IgdGhlIGhhc2ggYWdpbGl0eSBzdXBwb3J0LCBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHdp bGwgaGF2ZSB0byBuZWdvdGlhdGUgdGhlIGFsZ29yaXRobXMgc3VwcG9ydGVkIGFuZCBhZ3JlZSBv biB0aGUgaGFzaCBmdW5jdGlvbiAoSSBhbSBhc3N1bWluZyBTVFVOYmlzIGRyYWZ0IHdpbGwgY292 ZXIgdGhpcyBwYXJ0KS4gQWZ0ZXIgdGhpcyBzdGVwIGFzIGV4cGxhaW5lZCBpbiBkcmFmdC1pZXRm LW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAwLCBjbGllbnQgc2lnbmFscyB0aGUgcmVzcGVj dGl2ZSBhbGdvcml0aG0gdG8gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4g4oCYYWxn4oCZIHBhcmFt ZXRlciBhbmQgcmVjZWl2ZXMgdGhlIHN5bW1ldHJpYyBrZXkgd2hvc2UgaXMgbGVuZ3RoIGlzIGRl dGVybWluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGJhc2VkIG9uIHRoZSBhbGdvcml0 aG0gY29udmV5ZWQgYnkgdGhlIGNsaWVudC4NCg0KV2UgY2FuIGFkZCBhIG5vdGUgdG8gZXhwbGFp biB0aGlzIHBhcnQgdXNpbmcgbm9uLW5vcm1hdGl2ZSB0ZXh0IGFuZCB1cGRhdGUgaXQgb25jZSBT VFVOYmlzIGFkZHMgc3VwcG9ydCBmb3IgaGFzaCBhZ2lsaXR5Lg0KDQotVGlydQ0KDQpGcm9tOiBP bGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tXQ0KU2VudDogU2F0dXJk YXksIEF1Z3VzdCAyMywgMjAxNCAxOjA4IFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJl ZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gZHJhZnQtaWV0Zi10 cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCg0KQWN0dWFsbHksIGFsdGhvdWdoLCBub3Jt YWxseSwgMTI4LWJpdHMga2V5cyBhcmUgdXNlZCB3aXRoIEhNQUMtU0hBLTEsIG90aGVyIGtleSBs ZW5ndGhzIGFyZSBwb3NzaWJsZSB3aXRoIHRoYXQgZnVuY3Rpb24uIEkgYWRtaXQgdGhhdCBteSBz dWdnZXN0aW9uIG1heSBub3QgYmUgZW50aXJlbHkgYWNjdXJhdGUuDQpPbGVnDQoNCk9uIEZyaSwg QXVnIDIyLCAyMDE0IGF0IDExOjQ3IFBNLCBPbGVnIE1vc2thbGVua28gPG1vbTA0MDI2N0BnbWFp bC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+PiB3cm90ZToNClRpcnUsIEkgZm91bmQg YW4gZXJyb3IgaW4gdGhlIDYuMiBzZWN0aW9uIChBQ0NFU1NfVE9LRU4pLiBJdCBpcyBtZW50aW9u aW5nIHRoZSBITUFDLVNIQS0xIGFsZ29yaXRobSB3aXRoIDE2MCBiaXRzIGtleS4gVGhpcyBpcyBh Y3R1YWxseSBpbmNvcnJlY3Q6IEhNQUMtU0hBLTEgaGFzIDE2MCBiaXRzIG91dHB1dCByZXN1bHQs IGJ1dCBpdCB1c2VzIDEyOCBiaXRzIGlucHV0IGtleSwgbm9ybWFsbHkuDQoNCkFub3RoZXIgcHJv YmxlbSBpcyB0aGF0IEkgYW0gbm90IHN1cmUgdGhhdCB0aGUgaGFzaCBhZ2lsaXR5IHBsYW4gaWRl YSBkZXNjcmliZWQgaW4gUkZDNTM4OSBpcyBzdGlsbCB2YWxpZC4gSSBhbSBhZnJhaWQgdGhhdCBp dCBpcyB1bm5lY2Vzc2FyeSBjb21wbGljYXRlZCBhbmQgb3V0ZGF0ZWQsIHRha2luZyBpbnRvIGFj Y291bnQgdGhlIGN1cnJlbnQgbGV2ZWwgb2YgU0hBLTI1NiBhZG9wdGlvbi4gVGhlIHBsYW4gd2Fz IGRlc2lnbmVkIHRvIHN1cHBvcnQsICJ0cmFuc3BhcmVudGx5IiwgdGhlIG9sZCBUVVJOIHNlcnZl cnMuIEJ1dCBpbiB0aGVzZSBzcGVjcywgd2UgZG8gbm90IG5lY2Vzc2FyeSBoYXZlIHRvIHN1cHBv cnQgdGhlICJvbGQiIHNlcnZlcnMgd2l0aCBITUFDLVNIQS0xIG9ubHkgaW1wbGVtZW50YXRpb25z OyBhcyB3ZSBhcmUgd3JpdGluZyBhIG5ldyBvQXV0aCBwcm9jZWR1cmUsIHRoZXJlIHdpbGwgYmUg b25seSAibmV3IiBzZXJ2ZXJzIHN1cHBvcnRpbmcgdGhlIGRyYWZ0IHNwZWNzLCBhbnl3YXkuIFRo ZSAib2xkIiBzZXJ2ZXJzIHdpbGwgbm90IGJlIGFibGUgdG8gdXNlIHRoZSBvQXV0aCBzcGVjcy4g U08gd2UgY2FuIGRlc2lnbiBhIGNsZWFuZXIgc2ltcGxlciBoYXNoIGFnaWxpdHkgcHJvY2VkdXJl Lg0KDQoNClNvIHRoZSB0ZXh0IGhhcyB0byBiZSBmaXhlZDoNCk9MRCBURVhUOg0KLS0tLS0tLS0t LS0tLS0tLQ0KDQoga2V5X2xlbmd0aDogIExlbmd0aCBvZiB0aGUgc2Vzc2lvbiBrZXkuICBLZXkg bGVuZ3RoIG9mIDE2MC1iaXRzIE1VU1QNCg0KICAgICAgYmUgc3VwcG9ydGVkIChpLmUgb25seSAx NjAtYml0IGtleSBpcyB1c2VkIGJ5IEhNQUMtU0hBLTEgZm9yDQoNCiAgICAgIG1lc3NhZ2UgaW50 ZWdyaXR5IG9mIFNUVU4gbWVzc2FnZSkuICBUaGUga2V5IGxlbmd0aCBmYWNpbGl0YXRlcw0KDQog ICAgICB0aGUgaGFzaCBhZ2lsaXR5IHBsYW4gZGlzY3Vzc2VkIGluIHNlY3Rpb24gMTYuMyBvZiBb UkZDNTM4OV08aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTM4OSNzZWN0aW9uLTE2LjM+ Lg0KDQoNCk5FVyBURVhUOg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KIGtleV9sZW5n dGg6ICBMZW5ndGggb2YgdGhlIHNlc3Npb24ga2V5LiAgS2V5IGxlbmd0aCBvZiAxMjgtYml0cyBN VVNUDQoNCiAgICAgIGJlIHN1cHBvcnRlZCAoMTI4LWJpdCBrZXkgaXMgdXNlZCBieSBITUFDLVNI QS0xIGZvcg0KDQogICAgICBtZXNzYWdlIGludGVncml0eSBvZiBTVFVOIG1lc3NhZ2UpLiAgS2V5 IGxlbmd0aCBvZiAyNTYtYml0cyBTSE9VTEQNCg0KICAgICAgYmUgc3VwcG9ydGVkICgyNTYtYml0 IGtleSBpcyB1c2VkIGJ5IEhNQUMtU0hBLTI1NikuIE90aGVyIGtleSBsZW5ndGhzDQogICAgICBN QVkgYmUgc3VwcG9ydGVkLiBUaGUga2V5IGxlbmd0aCBmYWNpbGl0YXRlcyB0aGUgaGFzaCBhZ2ls aXR5Og0KDQoNCg0KDQogICAgICB0aGUgU0hBIGRpZ2VzdCBhbGdvcml0aG0gaXMgY2hvc2VuIGRl cGVuZGluZyBvbiB0aGUga2V5IGxlbmd0aC4NCg0KVGhhbmtzDQoNCg0KT2xlZw0KDQoNCg0KDQoN Cg0KT24gRnJpLCBBdWcgMjIsIDIwMTQgYXQgOToxMSBBTSwgT2xlZyBNb3NrYWxlbmtvIDxtb20w NDAyNjdAZ21haWwuY29tPG1haWx0bzptb20wNDAyNjdAZ21haWwuY29tPj4gd3JvdGU6DQpCdXQg SSBzdGlsbCB0aGluayB0aGF0IG1ha2luZyBhIHNpbmdsZSBhbGdvcml0aG0gKGxpa2UgQUVTXzI1 Nl9DQkMpIGRlZmF1bHQgYWNyb3NzIGFsbCB1c2UgY2FzZXMgaXMgYSBnb29kIGlkZWEsIEkganVz dCB1c2VkIHdyb25nIGV4cGxhbmF0aW9uIGZvciB0aGF0Lg0KDQpPbGVnDQoNCk9uIEZyaSwgQXVn IDIyLCAyMDE0IGF0IDg6MzQgQU0sIE9sZWcgTW9za2FsZW5rbyA8bW9tMDQwMjY3QGdtYWlsLmNv bTxtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT4+IHdyb3RlOg0KU29ycnksIHNjcmF0Y2ggdGhh dCAtIEkgdGFrZSBiYWNrIG15IGNvbW1lbnQuDQoNClRoYW5rcw0KT2xlZw0KDQpPbiBGcmksIEF1 ZyAyMiwgMjAxNCBhdCAxMjo0OCBBTSwgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGly ZWRkeUBjaXNjby5jb208bWFpbHRvOnRpcmVkZHlAY2lzY28uY29tPj4gd3JvdGU6DQpGcm9tOiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgT2xlZyBNb3NrYWxlbmtvDQpTZW50OiBGcmlkYXksIEF1Z3Vz dCAyMiwgMjAxNCAxMjoyNyBQTQ0KVG86IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+DQpTdWJqZWN0OiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0 aHotMDMNCg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudDoNCkluIHRoZSBzZWN0aW9uIDQu MS4xIGFuZCA0LjEuMiwgdGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtIEFFU18yNTZfQ0JDIGhhcyB0 byBiZSB1c2VkLCBiZWNhdXNlIHRoZSBIS0RGLUV4cGFuZCBmdW5jdGlvbiBvZiBsZW5ndGggMTYg ZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlLCBhY2NvcmRpbmcgdG8gUkZDIDU4Njkgc2VjdGlvbiAy LjMuDQoNClNvLCBJIHN1Z2dlc3QgdG8gdXNlIEFFU18yNTZfQ0JDIGNvbnNpc3RlbnRseSBhY3Jv c3MgdGhlIGRyYWZ0IHRleHQgYXMgdGhlIGRlZmF1bHQNCmVuY3J5cHRpb24gYWxnb3JpdGhtLiBJ biB0aGUgc2VjdGlvbiA0LjEuMyBpdCBpcyBhbHJlYWR5IHVzZWQgYXMgdGhlIGRlZmF1bHQgYWxn b3JpdGhtLA0KDQoNCg0KDQoNCg0KDQoNCg0KDQphbnl3YXkuDQoNCltUUl0gVGhhbmtzLCB3aWxs IHRoYXQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCi1UaXJ1DQoNClRoYW5rcw0KT2xlZw0KDQoN Cg0KDQo= --_000_913383AAA69FF945B8F946018B75898A2831A3E5xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlllcywNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ4Njgjc2VjdGlv bi0yLjEuMSI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDg2OCNzZWN0aW9uLTIuMS4x PC9hPiBkaXNjdXNzZXMgdGhlIGtleSBsZW5ndGggYW5kIG91dHB1dCBsZW5ndGg7DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmtleSBsZW5ndGhzIGxlc3MgdGhhbiB0 aGUgb3V0cHV0IGxlbmd0aDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5kZWNyZWFzZSBzZWN1cml0eSBzdHJlbmd0aCwgYW5kIGtleXMgbG9uZ2Vy IHRoYW4gdGhlIG91dHB1dCBsZW5ndGggZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bm90IHNpZ25pZmljYW50bHkgaW5jcmVhc2Ugc2VjdXJp dHkgc3RyZW5ndGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0Oy9zbmlwJmd0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+TGV0IG1lIGtub3cgaWYgeW91IHN0aWxsIHRoaW5rIHRoZSBiZWxvdyB0ZXh0IG5l ZWRzIHRvIGJlIGZpeGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rm9yIHRoZSBoYXNoIGFnaWxpdHkgc3VwcG9ydCwg VFVSTiBjbGllbnQgYW5kIHNlcnZlciB3aWxsIGhhdmUgdG8gbmVnb3RpYXRlIHRoZSBhbGdvcml0 aG1zIHN1cHBvcnRlZCBhbmQgYWdyZWUgb24gdGhlIGhhc2ggZnVuY3Rpb24gKEkgYW0gYXNzdW1p bmcgU1RVTmJpcyBkcmFmdA0KIHdpbGwgY292ZXIgdGhpcyBwYXJ0KS4gQWZ0ZXIgdGhpcyBzdGVw IGFzIGV4cGxhaW5lZCBpbiBkcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAw LCBjbGllbnQgc2lnbmFscyB0aGUgcmVzcGVjdGl2ZSBhbGdvcml0aG0gdG8gYXV0aG9yaXphdGlv biBzZXJ2ZXIgaW4g4oCYYWxn4oCZIHBhcmFtZXRlciBhbmQgcmVjZWl2ZXMgdGhlIHN5bW1ldHJp YyBrZXkgd2hvc2UgaXMgbGVuZ3RoIGlzIGRldGVybWluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24N CiBzZXJ2ZXIgYmFzZWQgb24gdGhlIGFsZ29yaXRobSBjb252ZXllZCBieSB0aGUgY2xpZW50LiA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPldlIGNhbiBhZGQgYSBub3RlIHRvIGV4cGxhaW4gdGhpcyBwYXJ0IHVzaW5nIG5v bi1ub3JtYXRpdmUgdGV4dCBhbmQgdXBkYXRlIGl0IG9uY2UgU1RVTmJpcyBhZGRzIHN1cHBvcnQg Zm9yIGhhc2ggYWdpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2N0Bn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAyMywgMjAxNCAx OjA4IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0K PGI+Q2M6PC9iPiB0cmFtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0g ZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+QWN0dWFsbHksIGFsdGhvdWdoLCBub3JtYWxseSwgMTI4LWJpdHMg a2V5cyBhcmUgdXNlZCB3aXRoIEhNQUMtU0hBLTEsIG90aGVyIGtleSBsZW5ndGhzIGFyZSBwb3Nz aWJsZSB3aXRoIHRoYXQgZnVuY3Rpb24uIEkgYWRtaXQgdGhhdCBteSBzdWdnZXN0aW9uIG1heSBu b3QgYmUgZW50aXJlbHkgYWNjdXJhdGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T2xlZzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIEF1ZyAyMiwgMjAxNCBhdCAxMTo0NyBQTSwgT2xlZyBNb3NrYWxlbmtv ICZsdDs8YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1vbTA0MDI2N0BnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5UaXJ1LCBJIGZvdW5kIGFuIGVycm9yIGluIHRoZSA2LjIgc2VjdGlvbiAoQUNDRVNTX1RPS0VO KS4gSXQgaXMgbWVudGlvbmluZyB0aGUgSE1BQy1TSEEtMSBhbGdvcml0aG0gd2l0aCAxNjAgYml0 cyBrZXkuIFRoaXMgaXMgYWN0dWFsbHkgaW5jb3JyZWN0OiBITUFDLVNIQS0xIGhhcyAxNjAgYml0 cyBvdXRwdXQgcmVzdWx0LCBidXQgaXQgdXNlcyAxMjggYml0cw0KIGlucHV0IGtleSwgbm9ybWFs bHkuIDxicj4NCjxicj4NCkFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IEkgYW0gbm90IHN1cmUgdGhh dCB0aGUgaGFzaCBhZ2lsaXR5IHBsYW4gaWRlYSBkZXNjcmliZWQgaW4gUkZDNTM4OSBpcyBzdGls bCB2YWxpZC4gSSBhbSBhZnJhaWQgdGhhdCBpdCBpcyB1bm5lY2Vzc2FyeSBjb21wbGljYXRlZCBh bmQgb3V0ZGF0ZWQsIHRha2luZyBpbnRvIGFjY291bnQgdGhlIGN1cnJlbnQgbGV2ZWwgb2YgU0hB LTI1NiBhZG9wdGlvbi4gVGhlIHBsYW4gd2FzIGRlc2lnbmVkIHRvIHN1cHBvcnQsDQogJnF1b3Q7 dHJhbnNwYXJlbnRseSZxdW90OywgdGhlIG9sZCBUVVJOIHNlcnZlcnMuIEJ1dCBpbiB0aGVzZSBz cGVjcywgd2UgZG8gbm90IG5lY2Vzc2FyeSBoYXZlIHRvIHN1cHBvcnQgdGhlICZxdW90O29sZCZx dW90OyBzZXJ2ZXJzIHdpdGggSE1BQy1TSEEtMSBvbmx5IGltcGxlbWVudGF0aW9uczsgYXMgd2Ug YXJlIHdyaXRpbmcgYSBuZXcgb0F1dGggcHJvY2VkdXJlLCB0aGVyZSB3aWxsIGJlIG9ubHkgJnF1 b3Q7bmV3JnF1b3Q7IHNlcnZlcnMgc3VwcG9ydGluZyB0aGUgZHJhZnQgc3BlY3MsIGFueXdheS4N CiBUaGUgJnF1b3Q7b2xkJnF1b3Q7IHNlcnZlcnMgd2lsbCBub3QgYmUgYWJsZSB0byB1c2UgdGhl IG9BdXRoIHNwZWNzLiBTTyB3ZSBjYW4gZGVzaWduIGEgY2xlYW5lciBzaW1wbGVyIGhhc2ggYWdp bGl0eSBwcm9jZWR1cmUuPGJyPg0KPGJyPg0KPGJyPg0KU28gdGhlIHRleHQgaGFzIHRvIGJlIGZp eGVkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PTEQgVEVYVDo8YnI+DQotLS0tLS0tLS0t LS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGtleV9sZW5ndGg6 Jm5ic3A7IExlbmd0aCBvZiB0aGUgc2Vzc2lvbiBrZXkuJm5ic3A7IEtleSBsZW5ndGggb2YgMTYw LWJpdHMgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIHN1cHBvcnRlZCAoaS5lIG9ubHkgMTYwLWJpdCBr ZXkgaXMgdXNlZCBieSBITUFDLVNIQS0xIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgaW50ZWdy aXR5IG9mIFNUVU4gbWVzc2FnZSkuJm5ic3A7IFRoZSBrZXkgbGVuZ3RoIGZhY2lsaXRhdGVzPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgaGFzaCBhZ2lsaXR5 IHBsYW4gZGlzY3Vzc2VkIGluIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzUzODkjc2VjdGlvbi0xNi4zIiB0YXJnZXQ9Il9ibGFuayI+c2VjdGlvbiZuYnNwOzE2LjMgb2Yg W1JGQzUzODldPC9hPi48YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+TkVXIFRFWFQ6PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0t LS0tLS0tLS0tLS0tLS0tPGJyPjxicj4ga2V5X2xlbmd0aDombmJzcDsgTGVuZ3RoIG9mIHRoZSBz ZXNzaW9uIGtleS4mbmJzcDsgS2V5IGxlbmd0aCBvZiAxMjgtYml0cyBNVVNUPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYmUgc3VwcG9ydGVkICgxMjgtYml0IGtleSBpcyB1c2VkIGJ5IEhNQUMtU0hBLTEgZm9yPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgbWVzc2FnZSBpbnRlZ3JpdHkgb2YgU1RVTiBtZXNzYWdlKS4mbmJzcDsgS2V5 IGxlbmd0aCBvZiAyNTYtYml0cyBTSE9VTEQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBzdXBwb3J0ZWQgKDI1 Ni1iaXQga2V5IGlzIHVzZWQgYnkgSE1BQy1TSEEtMjU2KS4gT3RoZXIga2V5IGxlbmd0aHM8YnI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1BWSBiZSBzdXBwb3J0ZWQuIFRoZSBrZXkg bGVuZ3RoIGZhY2lsaXRhdGVzIHRoZSBoYXNoIGFnaWxpdHk6IDxicj48YnI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBTSEEgZGlnZXN0IGFsZ29yaXRobSBpcyBjaG9zZW4g ZGVwZW5kaW5nIG9uIHRoZSBrZXkgbGVuZ3RoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+VGhhbmtzPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj48YnI+PHNw YW4gY2xhc3M9ImhvZW56YiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gY2xhc3M9ImhvZW56YiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izg4ODg4OCI+T2xlZzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izg4ODg4OCI+PGJyPjxicj48YnI+PHNwYW4gY2xh c3M9ImhvZW56YiI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IEF1ZyAyMiwgMjAxNCBhdCA5OjExIEFNLCBPbGVnIE1vc2thbGVua28gJmx0OzxhIGhyZWY9Im1h aWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9tMDQwMjY3QGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJ1dCBJIHN0aWxsIHRoaW5rIHRoYXQmbmJzcDttYWtpbmcgYSBzaW5nbGUgYWxnb3Jp dGhtIChsaWtlIEFFU18yNTZfQ0JDKSBkZWZhdWx0IGFjcm9zcyBhbGwgdXNlIGNhc2VzIGlzIGEg Z29vZCBpZGVhLCBJIGp1c3QgdXNlZCB3cm9uZyBleHBsYW5hdGlvbiBmb3IgdGhhdC48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+T2xlZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgQXVnIDIyLCAyMDE0IGF0IDg6MzQgQU0sIE9sZWcg TW9za2FsZW5rbyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tb20wNDAyNjdAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29ycnksIHNjcmF0Y2ggdGhhdCAtIEkg dGFrZSBiYWNrIG15IGNvbW1lbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5PbGVnPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBBdWcgMjIsIDIwMTQg YXQgMTI6NDggQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgJmx0OzxhIGhyZWY9Im1h aWx0bzp0aXJlZGR5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5PbGVnIE1vc2thbGVua288YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgMTI6MjcgUE08YnI+DQo8Yj5Ubzo8 L2I+IDxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RyYW1dIGRyYWZ0LWlldGYtdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSBoYXZl IHRoZSBmb2xsb3dpbmcgY29tbWVudDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIHRoZSBzZWN0aW9uIDQuMS4xIGFuZCA0 LjEuMiwgdGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtIEFFU18yNTZfQ0JDIGhhcyB0byBiZSB1c2Vk LCBiZWNhdXNlIHRoZSBIS0RGLUV4cGFuZCBmdW5jdGlvbiBvZiBsZW5ndGggMTYNCiBkb2VzIG5v dCBtYWtlIG11Y2ggc2Vuc2UsIGFjY29yZGluZyB0byBSRkMgNTg2OSBzZWN0aW9uIDIuMy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbywgSSBzdWdnZXN0IHRvIHVzZSBB RVNfMjU2X0NCQyBjb25zaXN0ZW50bHkgYWNyb3NzIHRoZSBkcmFmdCB0ZXh0IGFzIHRoZSBkZWZh dWx0IDxicj5lbmNyeXB0aW9uIGFsZ29yaXRobS4gSW4gdGhlIHNlY3Rpb24gNC4xLjMgaXQgaXMg YWxyZWFkeSB1c2VkIGFzIHRoZSBkZWZhdWx0IGFsZ29yaXRobSwgPGJyPjxicj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+YW55d2F5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwcmUg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W1RSXSBUaGFua3MsIHdpbGwgdGhhdCBpbiB0aGUgbmV4dCByZXZpc2lv bi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnU8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VGhhbmtzPGJyPk9sZWc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_913383AAA69FF945B8F946018B75898A2831A3E5xmbrcdx10ciscoc_-- From nobody Sat Aug 23 10:18:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650641A068F for ; Sat, 23 Aug 2014 10:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=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 mOQOwoYFezA4 for ; Sat, 23 Aug 2014 10:18:05 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1C31A04E8 for ; Sat, 23 Aug 2014 10:18:05 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so18153008pac.3 for ; Sat, 23 Aug 2014 10:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=SNOMMpx4kmcQKvQCy0FRsxN960qgcbfxaF8h05xYOjI=; b=V3apjBUTSaRLDTTyrOkhYfyMAvFRY4vkSvArqYHadqNJFmwqCPVKHoqGj2RgMmNyEs KtJkuMyf9PYKrtfkG1ERKb5/+VSvSZy5lEQbUrXTpPG0WC+cGcUO7zz5KbAJ/ENulr7U Bn6fSyZzB6/7Aswyc3Zyf6+5ib2AhmFtpPoxi6CSBLYJ51H35Nj5YrtE342XoL1NAY3s ILtK3XU7MDtckskZcWekNQAoBhIBdBEzu3yJ6xnqH6dpcNjALKCyxC5RWCaNi2tqYnq0 vJELr27cnPKlAzVpxJkFhS2ZKxyH9vxsdPxVxzOhWEsJlQJ+V2Z5/9Sygig+nKpp+C6v 8RpQ== X-Received: by 10.68.197.65 with SMTP id is1mr14899653pbc.125.1408814285029; Sat, 23 Aug 2014 10:18:05 -0700 (PDT) Received: from [10.164.128.117] (45.sub-70-197-8.myvzw.com. [70.197.8.45]) by mx.google.com with ESMTPSA id qt2sm32303321pbb.29.2014.08.23.10.18.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 10:18:03 -0700 (PDT) References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> <913383AAA69FF945B8F946018B75898A2831A3E5@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: <913383AAA69FF945B8F946018B75898A2831A3E5@xmb-rcd-x10.cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-DBB022D1-0F44-409F-AA8C-08C757604E48 Content-Transfer-Encoding: 7bit Message-Id: <80169DBD-32AF-4078-9EEE-F86CB2D9F76B@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Sat, 23 Aug 2014 10:18:02 -0700 To: "Tirumaleswar Reddy (tireddy)" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qTwy7yEvxuqlQEMpQ6ATFu3-oNw Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 17:18:09 -0000 --Apple-Mail-DBB022D1-0F44-409F-AA8C-08C757604E48 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable That's fine, thanks. Oleg > On Aug 23, 2014, at 8:18 AM, "Tirumaleswar Reddy (tireddy)" wrote: >=20 > Yes, http://tools.ietf.org/html/rfc4868#section-2.1.1 discusses the key le= ngth and output length; > > key lengths less than the output length > decrease security strength, and keys longer than the output length do > not significantly increase security strength > > =20 > Let me know if you still think the below text needs to be fixed. > =20 > For the hash agility support, TURN client and server will have to negotiat= e the algorithms supported and agree on the hash function (I am assuming STU= Nbis draft will cover this part). After this step as explained in draft-ietf= -oauth-pop-key-distribution-00, client signals the respective algorithm to a= uthorization server in =91alg=92 parameter and receives the symmetric key wh= ose is length is determined by the authorization server based on the algorit= hm conveyed by the client. > =20 > We can add a note to explain this part using non-normative text and update= it once STUNbis adds support for hash agility. > =20 > -Tiru > =20 > From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 > Sent: Saturday, August 23, 2014 1:08 PM > To: Tirumaleswar Reddy (tireddy) > Cc: tram@ietf.org > Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 > =20 > Actually, although, normally, 128-bits keys are used with HMAC-SHA-1, othe= r key lengths are possible with that function. I admit that my suggestion ma= y not be entirely accurate. >=20 > Oleg >=20 > =20 >=20 > On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko wr= ote: > Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is mentioning= the HMAC-SHA-1 algorithm with 160 bits key. This is actually incorrect: HMA= C-SHA-1 has 160 bits output result, but it uses 128 bits input key, normally= .=20 >=20 > Another problem is that I am not sure that the hash agility plan idea desc= ribed in RFC5389 is still valid. I am afraid that it is unnecessary complica= ted and outdated, taking into account the current level of SHA-256 adoption.= The plan was designed to support, "transparently", the old TURN servers. Bu= t in these specs, we do not necessary have to support the "old" servers with= HMAC-SHA-1 only implementations; as we are writing a new oAuth procedure, t= here will be only "new" servers supporting the draft specs, anyway. The "old= " servers will not be able to use the oAuth specs. SO we can design a cleane= r simpler hash agility procedure. >=20 >=20 > So the text has to be fixed: >=20 > OLD TEXT: > ---------------- >=20 > key_length: Length of the session key. Key length of 160-bits MUST > be supported (i.e only 160-bit key is used by HMAC-SHA-1 for > message integrity of STUN message). The key length facilitates > the hash agility plan discussed in section 16.3 of [RFC5389]. >=20 > NEW TEXT: >=20 > =20 > ------------------ >=20 > key_length: Length of the session key. Key length of 128-bits MUST > be supported (128-bit key is used by HMAC-SHA-1 for > message integrity of STUN message). Key length of 256-bits SHOULD > be supported (256-bit key is used by HMAC-SHA-256). Other key length= s > MAY be supported. The key length facilitates the hash agility:=20 >=20 > =20 > the SHA digest algorithm is chosen depending on the key length. > Thanks >=20 > Oleg >=20 >=20 > =20 > =20 > =20 >=20 > On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko wro= te: > But I still think that making a single algorithm (like AES_256_CBC) defaul= t across all use cases is a good idea, I just used wrong explanation for tha= t. > =20 > Oleg > =20 >=20 > On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko wro= te: > Sorry, scratch that - I take back my comment. > =20 > Thanks > Oleg > =20 >=20 > On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy (tireddy) wrote: > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Friday, August 22, 2014 12:27 PM > To: tram@ietf.org > Subject: [tram] draft-ietf-tram-turn-third-party-authz-03 > =20 > I have the following comment: >=20 > In the section 4.1.1 and 4.1.2, the encryption algorithm AES_256_CBC has t= o be used, because the HKDF-Expand function of length 16 does not make much s= ense, according to RFC 5869 section 2.3. > So, I suggest to use AES_256_CBC consistently across the draft text as the= default=20 > encryption algorithm. In the section 4.1.3 it is already used as the defau= lt algorithm,=20 >=20 > =20 > =20 > =20 > =20 > anyway. > [TR] Thanks, will that in the next revision. > -Tiru > Thanks > Oleg > =20 > =20 > =20 > =20 --Apple-Mail-DBB022D1-0F44-409F-AA8C-08C757604E48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
That's fine, thanks.

Oleg
=

On Aug 23, 2014, at 8:18 AM, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> wrote:

Yes, http://tools.ie= tf.org/html/rfc4868#section-2.1.1 discusses the key length and output le= ngth;

<snip>

key lengths less than the output length

decrease security strength, and keys longer than the output l= ength do

not significantly increase security strength

</snip>

 

Let me know if you still th= ink the below text needs to be fixed.

 

For the hash agility suppor= t, TURN client and server will have to negotiate the algorithms supported an= d agree on the hash function (I am assuming STUNbis draft will cover this part). After this step as explained in draft-ietf-oauth-pop= -key-distribution-00, client signals the respective algorithm to authorizati= on server in =E2=80=98alg=E2=80=99 parameter and receives the symmetric key w= hose is length is determined by the authorization server based on the algorithm conveyed by the client.

 

We can add a note to explai= n this part using non-normative text and update it once STUNbis adds support= for hash agility.

 

-Tiru

=

 

From: Oleg Moskal= enko [mailto:mom040267@gmail.com]=
Sent: Saturday, August 23, 2014 1:08 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03

 

Actually, although, no= rmally, 128-bits keys are used with HMAC-SHA-1, other key lengths are possib= le with that function. I admit that my suggestion may not be entirely accura= te.

Oleg

 

On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko <= ;mom040267@gmail.co= m> wrote:

Tiru, I found an error= in the 6.2 section (ACCESS_TOKEN). It is mentioning the HMAC-SHA-1 algorith= m with 160 bits key. This is actually incorrect: HMAC-SHA-1 has 160 bits out= put result, but it uses 128 bits input key, normally.

Another problem is that I am not sure that the hash agility plan idea descri= bed in RFC5389 is still valid. I am afraid that it is unnecessary complicate= d and outdated, taking into account the current level of SHA-256 adoption. T= he plan was designed to support, "transparently", the old TURN servers. But in these specs, we do not necess= ary have to support the "old" servers with HMAC-SHA-1 only implementations; a= s we are writing a new oAuth procedure, there will be only "new" servers sup= porting the draft specs, anyway. The "old" servers will not be able to use the oAuth specs. SO we can design= a cleaner simpler hash agility procedure.


So the text has to be fixed:

OLD TEXT:
----------------

 k=
ey_length:  Length of the session key.  Key length of 160-bits MUS=
T
&n=
bsp;     be supported (i.e only 160-bit key is used by H=
MAC-SHA-1 for
&n=
bsp;     message integrity of STUN message).  The k=
ey length facilitates
      the hash agility=
 plan discussed in section 16.3 of [RFC5389].

=

NE=
W TEXT:

 
--=
----------------

 key_length:  Length of the session key.  K=
ey length of 128-bits MUST
&n=
bsp;     be supported (128-bit key is used by HMAC-SHA-1=
 for
&n=
bsp;     message integrity of STUN message).  Key l=
ength of 256-bits SHOULD
&n=
bsp;     be supported (256-bit key is used by HMAC-SHA-2=
56). Other key lengths
      MAY be supported. T=
he key length facilitates the hash agility:

= 
 
      the SHA digest a=
lgorithm is chosen depending on the key length.
Th=
anks

=

Oleg


 

 

 

On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko <= mom040267@gmail.com= > wrote:

But I still think that making a single algorithm= (like AES_256_CBC) default across all use cases is a good idea, I just used= wrong explanation for that.=

 

Oleg<= /p>

 

On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko <= mom040267@gmail.com= > wrote:

Sorry, scratch that - I take back my comment.

 

Thanks

Oleg<= /p>

 

 

 

= --Apple-Mail-DBB022D1-0F44-409F-AA8C-08C757604E48-- From nobody Sat Aug 23 23:24:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7283A1A0842; Sat, 23 Aug 2014 23:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCbdB5M8lpjn; Sat, 23 Aug 2014 23:24:48 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A29A1A6FCC; Sat, 23 Aug 2014 23:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11746; q=dns/txt; s=iport; t=1408861488; x=1410071088; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=hsp8kEquICRPB9xQFozxVFhjw8PWxzUxze/QHsXTugQ=; b=MtIis64dY0ocmC4evakCBZcz+IICqEMWUZMjQP/Nr89WcFHpEhnjXEiG dWmK0+jfbRziG4silqb/2HZGZKx9vKeZw36Ml7AWmYZdZdyBPFVQ+NM02 Z6F/pozlKI5hFQVV0fRsoxIiYzHonqQpA/2e2e+FYGYFeiK0wvhxsIsmB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAN2D+VOtJV2U/2dsb2JhbABPCoMNU1cEgnjJSIdNARlvFneEAwEBAQMBIwQNMwsHBQcGAQgRBAEBAwIGHQMCBDAUAQgJAQQBDQUIiCYDCQgNrzeULBeBLItzgUsGCwEfMQ2CczaBHQWFBAKMIIQpiFKTNIFmHIFcbIEPOYEHAQEB X-IronPort-AV: E=Sophos;i="5.04,389,1406592000"; d="scan'208";a="71861458" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 24 Aug 2014 06:24:46 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7O6OkM1013225 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Aug 2014 06:24:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Sun, 24 Aug 2014 01:24:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: Review of draft-ietf-tram-turn-third-party-authz-01 Thread-Index: Ac+/ZBYS752gcJGOSr6ZhlHlrD++Og== Date: Sun, 24 Aug 2014 06:24:45 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831A4F0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.49.208] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FzGfWxook0fwhzGzlmedpLS0UAY Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 06:24:50 -0000 SGkgSGFubmVzLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVu aWdAZ214Lm5ldF0NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMjIsIDIwMTQgMjowNiBQTQ0KPiBU bzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgb2F1dGhAaWV0Zi5vcmcNCj4gQ2M6IGRy YWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6QHRvb2xzLmlldGYub3JnOw0KPiBH b256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20gPj4gR29uemFsbyBDYW1hcmlsbG87DQo+IHNw ZXJyZWF1bHRAaml2ZS5jb207IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFJldmlldyBv ZiBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMQ0KPiANCj4gSGkgVGly dSwNCj4gDQo+IH5zbmlwfg0KPiA+PiAqIFRoZSBEZXNpZ24NCj4gPj4NCj4gPj4gSSB3b3VsZCBo YXZlIHVzZWQgT0F1dGggYXMgaXMgKG9yIG1heWJlIHNlbGVjdGVkIGEgc3BlY2lmaWMgZ3JhbnQN Cj4gPj4gdHlwZSkgdG8gb2J0YWluIGFuIGFjY2VzcyB0b2tlbi4gVGhlbiwgSSB3b3VsZCBoYXZl IGRlZmluZWQgaG93IHRoZQ0KPiA+PiBhY2Nlc3MgdG9rZW4gaXMgY2FycmllZCBpbiB0aGUgVFVS TiBwcm90b2NvbC4gVGhpcyBpcyBhIGJpdCBzaW1pbGFyDQo+ID4+IHdoYXQgd2UgaGF2ZSBhbHJl YWR5IGRvbmUgd2l0aCB0aGUgT0F1dGggU0FTTCBkcmFmdCB3aGVyZSB3ZSBkZWZpbmVkDQo+ID4+ IGEgbmV3IHdheSB0byBjb252ZXkgdGhlIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSBTQVNMIGNsaWVu dCB0byB0aGUgU0FTTA0KPiBzZXJ2ZXIuDQo+ID4+DQo+ID4+IEhvdyBkaWQgdGhlIGF1dGhvcnMg c29sdmUgdGhhdCBwcm9ibGVtPyBUaGV5IHByZXR0eSBtdWNoIGRpZCB3aGF0IEkNCj4gPj4ganVz dCBleHBsYWluZWQuIFNpbmNlIFRVUk4gZG9lcyBub3QgdXNlIERUTFMgKG9yIFRMUykgdGhlDQo+ ID4+IHByb29mLW9mLXBvc3Nlc3Npb24gc2VjdXJpdHkgd29yayB3ZSBhcmUgZG9pbmcgYmVjb21l cyByZWxldmFudA0KPiA+PiAobmFtZWx5IHRoZSBzeW1tZXRyaWMga2V5LSBiYXNlZCBwYXJ0KS4N Cj4gPg0KPiA+IFllcywgdGhlIGNvbW11bmljYXRpb24gYi93IFRVUk4gY2xpZW50IGFuZCBzZXJ2 ZXIgbWF5IG9yIG1heSBub3QgdXNlDQo+ID4gKEQpVExTLCBoZW5jZSBwcm9vZi1vZi1wb3NzZXNz aW9uIHNlY3VyaXR5IHdvcmsgaXMgdXNlZC4NCj4gDQo+IEkga25vdyBzYXcgaW4gb25lIG9mIHRo ZSByZWZlcmVuY2VzIHRoYXQgdGhlcmUgaXMgYSBwcm9wb3NhbCBmb3IgRFRMUy4NCj4gSW4gdGhh dCBjYXNlIHlvdSBtaWdodCBhbHJlYWR5IHdhbnQgdG8gY29uc2lkZXIgcmUtdXNpbmcgdGhlIGNo YW5uZWwgYmluZGluZw0KPiB3b3JrIGFzIHdlbGwuDQoNClRVUk4gcmVxdWVzdC9yZXNwb25zZSB3 aWxsIGFsd2F5cyBiZSBpbnRlZ3JpdHkgcHJvdGVjdGVkIGluZGVwZW5kZW50IG9mIHdoZXRoZXIg KEQpVExTIGlzIHVzZWQgb3Igbm90IGFuZCB0aGUgbWVkaWEgdHJhZmZpYyByZWxheWVkIHRocm91 Z2ggdGhlIFRVUk4gc2VydmVyIGlzIGVuY3J5cHRlZCAoZS5nLiB1c2luZyBEVExTLVNSVFApIGZv ciBlbmQtdG8tZW5kIHNlY3VyaXR5LiBJcyB0aGVyZSBuZWVkIHRvIHN1cHBvcnQgY2hhbm5lbCBi aW5kaW5nID8NCg0KPiANCj4gDQo+ID4NCj4gPj4NCj4gPj4gUHV0dGluZyBkaXNjb3ZlcnkgaW5m b3JtYXRpb24gaW4tYmFuZCBpbnRvIHRoZSBleGNoYW5nZSBpcyBhbHNvIGZpbmQNCj4gPj4gKHdo aWNoIGlzIHdoYXQgd2UgZGlkIGluIHRoZSBTQVNMIGRvY3VtZW50KS4NCj4gPj4NCj4gPj4gSW5z dGVhZCBvZiB1c2luZyB0aGUgSldUIGFjY2VzcyB0b2tlbiBmb3JtYXQgdGhlIGF1dGhvcnMgaGF2 ZSBkZWZpbmVkDQo+ID4+IGEgbmV3LCBiaW5hcnkgZW5jb2RpbmcgdG8ga2VlcCB0aGUgc2l6ZSBz bWFsbGVyLiBUaGUgT0F1dGggZnJhbWV3b3JrDQo+ID4+IGFsbG93cyBvdGhlciB0b2tlbiBmb3Jt YXRzIHRvIGJlIHVzZWQgLSBzbyB0aGF0J3MgZmluZSBhcyB3ZWxsLg0KPiA+PiAoQXMgYSBtaW5v ciByZW1hcmssIEkgd291bGQgdXNlIEFFQUQgY2lwaGVycyBoZXJlIHNpbmNlIHRoYXQncyB3aGF0 DQo+ID4+IGV2ZXJ5b25lIGlzIGRvaW5nIG5vd2F5cy4pDQo+ID4NCj4gPiBHb29kIHBvaW50LCB3 aWxsIHVwZGF0ZSB0aGUgZHJhZnQgdG8gdXNlIEFFQUQuDQo+IA0KPiBPaw0KPiANCj4gPg0KPiA+ Pg0KPiA+PiBUd28gdGhpbmdzIHN1cnByaXNlZCBtZToNCj4gPj4NCj4gPj4gYSkgVGhlIHNwZWMg bGVhdmVzIHRoZSB3YXkgdG8gb2J0YWluIHRoZSBhY2Nlc3MgdG9rZW4gcHJldHR5IG11Y2ggb3Bl bi4NCj4gPj4gQSBiaWcgYmVuZWZpdCBmcm9tIHVzaW5nIE9BdXRoIGlzIHRoYXQgdGhlcmUgaXMg YSBwcm90b2NvbCBtZWNoYW5pc20NCj4gPj4gZGVmaW5lZCBmb3IgZ2V0dGluZyB0aGUgYWNjZXNz IHRva2VuLiBZb3UgY291bGQsIGZvciBleGFtcGxlLA0KPiA+PiByZWNvbW1lbmQgdXNpbmcgYXV0 aG9yaXphdGlvbiBjb2RlIGZsb3cuIFRoaXMgY29uY2VybnMgdGhlIHRleHQgd3JpdHRlbg0KPiBp biBTZWN0aW9uIDQuDQo+ID4NCj4gPiBVc2luZyBhdXRob3JpemF0aW9uIGNvZGUgZmxvdyBpcyBk aXNjdXNzZWQgaW4gU2VjdGlvbiA0IG9mIHRoZSBkcmFmdC4NCj4gPg0KPiA+IDxzbmlwPg0KPiA+ ICAgIE9BdXRoIGluIFtSRkM2NzQ5XSBkZWZpbmVzIGZvdXIgZ3JhbnQgdHlwZXMuICBUaGlzIHNw ZWNpZmljYXRpb24gdXNlcw0KPiA+ICAgIHRoZSBPQXV0aCBncmFudCB0eXBlICJJbXBsaWNpdCIg ZXhwbGFpbmVkIGluIHNlY3Rpb24gMS4zLjIgb2YNCj4gPiAgICBbUkZDNjc0OV0gd2hlcmUgdGhl IFdlYlJUQyBjbGllbnQgaXMgaXNzdWVkIGFuIGFjY2VzcyB0b2tlbiBkaXJlY3RseS4NCj4gPiA8 L3NuaXA+DQo+ID4NCj4gPiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB3ZSBhZGQgbW9yZSBkZXRh aWxzID8NCj4gDQo+IEkgbWlzc2VkIHRoYXQuIFRoYXQncyBmaW5lLg0KPiANCj4gPg0KPiA+Pg0K PiA+PiBiKSBZb3UgZGVzY3JpYmUgYSBrZXkgZXN0YWJsaXNobWVudCBzY2hlbWUgdG8gYmUgdXNl ZCBiZXR3ZWVuIHRoZQ0KPiA+PiByZXNvdXJjZSBzZXJ2ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4gV2hhdCBhc3N1bXB0aW9uIGRvIHlvdQ0KPiA+PiBtYWtlIGFib3V0IHRoZSByZWxh dGlvbnNoaXAgYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHRoZQ0KPiA+PiBy ZXNvdXJjZSBzZXJ2ZXI/IEFyZSB0aGV5IHN1cHBvc2VkIHRvIGhhdmUgYSBidXNpbmVzcyByZWxh dGlvbnNoaXAgb3INCj4gPj4gc29tZSBvdGhlciByZWxhdGlvbnNoaXAgd2l0aCBlYWNoIG90aGVy ID8NCj4gPg0KPiA+IEF1dGhvcml6YXRpb24gYW5kIFJlc291cmNlIHNlcnZlcnMgY291bGQgaGF2 ZSBhIGJ1c2luZXNzIHJlbGF0aW9uc2hpcA0KPiA+IChsb29zZWx5IGNvdXBsZWQsIGZvciBleGFt cGxlIEVudGVycHJpc2UgbmV0d29yayB1c2luZyBUVVJOIHNlcnZlcg0KPiA+IHByb3ZpZGVkIGJ5 IHRoaXJkIHBhcnR5IHByb3ZpZGVyIGxpa2UgQWthbWFpKSBvciBjb3VsZCBiZSBkZXBsb3llZCBp bg0KPiA+IHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbiAodGlnaHRseSBjb3VwbGVkLCBm b3IgZXhhbXBsZSBHb29nbGUNCj4gPiBwcm92aWRpbmcgYm90aCBXZWJSVEMgYW5kIFRVUk4gc2Vy dmVycykNCj4gDQo+IEkgZ3Vlc3MgeW91IGFzc3VtZSB0aGF0IHRoZXJlIGlzIHNvbWUgbG9uZy10 ZXJtIHNlY3JldCAoc3VjaCBhcyBhc3ltbWV0cmljDQo+IGNyZWRlbnRpYWwpIGluIHBsYWNlIGFu ZCB5b3UgdGhlbiBkZXJpdmUgdGhlIHN5bW1ldHJpYyBrZXlzIGZyb20gaXQgKGJ5IHVzaW5nDQo+ IERTS1BQKS4gDQoNClllcw0KDQo+IE1heWJlIHlvdSB3YW50IHRvIHNheSB0aGF0IChpbiBhZGRp dGlvbiB0byB0aGUgYXNzdW1lZCByZWxhdGlvbnNoaXANCj4gYmV0d2VlbiB0aGUgdHdvIGVudGl0 aWVzKS4gSWYgdGhlcmUgaXMgbm8gcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHR3byBwYXJ0aWVz DQo+IHRoZW4gdGhleSB3aWxsIGNlcnRhaW5seSBiZSBhIGNoYWxsZW5nZSB0byBnZXQgdGhpcyBk b25lIHNlY3VyZWx5Lg0KDQpBZ3JlZWQsIHdpbGwgdXBkYXRlIHRoZSBkcmFmdC4NCg0KPiANCj4g DQo+ID4NCj4gPj4NCj4gPj4gTWlub3IgYXNwZWN0czoNCj4gPj4NCj4gPj4gICogV291bGQgdGhl IFRVUk4gc2VydmVyIG5hbWUgcmVhbGx5IGJlIGFuIGVtYWlsIGFsaWtlIGFkZHJlc3MgcmF0aGVy DQo+ID4+IHRoYW4gYSBVUkkgPw0KPiA+DQo+ID4gWWVzLCBmb3IgbW9yZSBpbmZvcm1hdGlvbiBw bGVhc2UgcmVmZXIgdG8NCj4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRyYW0tdHVybi1zZXJ2ZXItZGlzY292ZXJ5LTAwDQo+ID4NCj4gDQo+IFRoYW5rcy4gV2h5IGRv IHlvdSBuZWVkIHRoZSB1c2VybmFtZSBwYXJ0IGZvciB0aGUgZGlzY292ZXJ5IG9mIHRoZSBUVVJO DQo+IHNlcnZlciBjYXBhYmlsaXRpZXM/IEkgY291bGRuJ3QgZmluZCB0aGUgYW5zd2VyIHRvIHRo YXQgcXVlc3Rpb24gYnkgcXVpY2tseQ0KPiBsb29raW5nIGF0IHRoZSBUVVJOIHNlcnZlciBkaXNj b3ZlcnkgZG9jdW1lbnQuIERvIHlvdSBleHBlY3QgdGhhdCB0aGUNCj4gY29uZmlndXJhdGlvbiBp cyBkaWZmZXJlbnQgZnJvbSB1c2VyIHRvIHVzZXI/DQo+IA0KPiBUaGUgcHJvY2VkdXJlIHNlZW1z IHRvIGJlOg0KPiANCj4gQ2xpZW50IC0+IFRVUk4gc2VydmVyOiBFc3RhYmxpc2ggVHVubmVsDQo+ IENsaWVudCA8LSBUVVJOIHNlcnZlcjogZXJyb3IgLSBoZXJlIGlzIG15ICJlbWFpbCIgYWxpa2Ug YWRkcmVzcw0KPiAoZm9vQHR1cm4uY29tKQ0KPiBDbGllbnQgLT4gRE5TOiBETlMgTG9va3VwICh0 dXJuLmNvbSkNCj4gQ2xpZW50IDwtIEROUzogc29tZXRoaW5nIGRvbWFpbiBuYW1lIGJhY2sgQ2xp ZW50IC0+IEROUzogTkFQVFIgQ2xpZW50IDwtDQo+IEROUzogSVAgYWRkcmVzcyBiYWNrDQo+IA0K PiBJcyB0aGlzIGNvcnJlY3Q/DQoNClRoZSBwcm9jZWR1cmUgaXMgYXMgZm9sbG93czoNCg0KQ2xp ZW50IC0+IEROUzogRE5TIExvb2t1cCAodHVybi5jb20pDQpDbGllbnQgPC0gRE5TOiBzb21ldGhp bmcgZG9tYWluIG5hbWUgYmFjayBDbGllbnQgLT4gRE5TOiBOQVBUUiBDbGllbnQgPC0NCkROUzog SVAgYWRkcmVzcyBiYWNrDQpDbGllbnQgLT4gVFVSTiBzZXJ2ZXI6IEVzdGFibGlzaCBUdW5uZWwN CkNsaWVudCA8LSBUVVJOIHNlcnZlcjogZXJyb3IgLSBoZXJlIGlzIG15ICJlbWFpbCIgYWxpa2Ug YWRkcmVzcw0KKGZvb0B0dXJuLmNvbSkNCg0KVGhlIHVuaXF1ZSBUVVJOIHNlcnZlciBuYW1lIChm b29AdHVybi5jb20pIGlzIHByb3ZpZGVkIGJ5IHRoZSBUVVJOIHNlcnZlciBpbiB0aGUgZXJyb3Ig cmVzcG9uc2Ugc28gdGhhdCBjbGllbnQgY2FuIGNvbnZleSB0aGUgdW5pcXVlIFRVUk4gc2VydmVy IG5hbWUgdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBBdXRob3JpemF0aW9uIHNlcnZlciB1 c2VzIHRoZSBUVVJOIHNlcnZlciBuYW1lIHRvIGlkZW50aWZ5IHRoZSBhcHByb3ByaWF0ZSBrZXlp bmcgbWF0ZXJpYWwgdG8gZ2VuZXJhdGUgdGhlIHNlbGYtY29udGFpbmVkIHRva2VuLiANCg0KPiAN Cj4gPj4NCj4gPj4gICogV291bGQgeW91IHVzZSBEeW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24g dG8gcHJvdmlzaW9uIHRoZSBjbGllbnQNCj4gPj4gd2l0aCB0aGUgbmVjZXNzYXJ5IHBhcmFtZXRl cj8gSXMgdGhlcmUgdGhlIGV4cGVjdGF0aW9uIHRoYXQgcmFuZG9tDQo+ID4+IGNsaWVudHMgd291 bGQgd29yayB3aXRoIHJhbmRvbSBhdXRob3JpemF0aW9uIHNlcnZlcnMgPw0KPiA+DQo+ID4gTm8s IGNsaWVudCBtdXN0IGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciAo U0lQL1dlYlJUQw0KPiBzZXJ2ZXIpIHRvIG1ha2UgYSBjYWxsLg0KPiANCj4gT2suDQo+IA0KPiA+ DQo+ID4+DQo+ID4+ICAqIFdvdWxkbid0IHlvdSB3YW50IHRvIGRlZmluZSBhIHNjb3BlIHZhbHVl IGZvciB1c2Ugd2l0aCB0aGUgVFVSTg0KPiA+PiBzZXJ2aWNlIHNvIHRoYXQgdGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIGlzIGFibGUgdG8gcmVzdHJpY3QgdGhlDQo+ID4+IGFjY2VzcyB0b2tlbiBm b3IgdXNlIHdpdGggVFVSTiBvbmx5Pw0KPiA+DQo+ID4gVGhlIHNjb3BlIHZhbHVlIGZvciB1c2Ug d2l0aCB0aGUgVFVSTiBzZXJ2aWNlIGlzIGRlZmluZWQgaW4gc2VjdGlvbiA0DQo+ID4NCj4gPiA8 c25pcD4NCj4gPiAgICBUaGUgc2NvcGUgb2YgdGhlIGFjY2VzcyB0b2tlbiBleHBsYWluZWQgaW4g c2VjdGlvbiAzLjMgb2YgW1JGQzY3NDldDQo+ID4gICAgTVVTVCBiZSBUVVJOLg0KPiA+IDwvc25p cD4NCj4gDQo+IE9rLiBUaGUgc2NvcGUgc3RyaW5nIGlzICd0dXJuJy4NCg0KWWVzLCB1cGRhdGVk IHRoZSBhYm92ZSBsaW5lIHRvIG1ha2UgaXQgbW9yZSBjbGVhci4NCg0KTkVXOg0KVGhlIHZhbHVl IG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy4zIG9mIFtSRkM2 NzQ5XSBtdXN0IGJlICd0dXJuJyBzdHJpbmcuDQoNCj4gDQo+ID4NCj4gPj4NCj4gPj4gICogQ3J5 cHRvIGFsZ29yaXRobSBuZWdvdGlhdGlvbjogd291bGQgeW91IGV4cGVjdCB0aGUgYXV0aG9yaXph dGlvbg0KPiA+PiBzZXJ2ZXIgdG8gdGVsbCB0aGUgY2xpZW50IHdoYXQgY3J5cHRvIGFsZ29yaXRo bXMgdG8gdXNlIChzaW5jZSB0aGUNCj4gPj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgbm90IG9ubHkg bmVlZHMgdG8gc2hhcmUgYSBrZXkgd2l0aCB0aGUgcmVzb3VyY2UNCj4gPj4gc2VydmVyIGJ1dCBh bHNvIG5lZWRzIHRvIGhhdmUga25vd2xlZGdlIGFib3V0IHRoZSBzdXBwb3J0ZWQNCj4gY3J5cHRv Z3JhcGhpYyBhbGdvcml0aG1zKSA/DQo+ID4NCj4gPiBDdXJyZW50bHkgU1RVTiBvbmx5IHVzZXMg SE1BQy1TSEExLCBoZW5jZSBkZXRhaWxzIGFib3V0IGF1dGhvcml6YXRpb24NCj4gc2VydmVyIHRl bGxpbmcgdGhlIGNsaWVudCBhYm91dCB0aGUgY3J5cHRvIGFsZ29yaXRobSB0byB1c2UgaXMgbm90 IGV4cGxpY2l0bHkNCj4gbWVudGlvbmVkIGluIHRoZSBkcmFmdC4NCj4gDQo+IE9LLiBJcyB0aGVy ZSBhbnkgcGxhbiB0byBwcm92aWRlIG1vcmUgdGhhbiBqdXN0IEhNQUMtU0hBMSA/DQoNClllcywg dGhlcmUgaXMgZnV0dXJlIHBsYW4gdG8gcHJvdmlkZSBTVFVOIGhhc2ggYWdpbGl0eSBpbiBTVFVO YmlzIGRyYWZ0ICh3b3JrIGlzIHlldCB0byBzdGFydCBvbiB0aGlzIGRyYWZ0KS4gQ3J5cHRvIGFs Z29yaXRobSBuZWdvdGlhdGlvbiBjb3VsZCB3b3JrIGFzIGZvbGxvd3M6DQpGb3IgdGhlIGhhc2gg YWdpbGl0eSBzdXBwb3J0LCBUVVJOIGNsaWVudCBhbmQgc2VydmVyIHdpbGwgaGF2ZSB0byBuZWdv dGlhdGUgdGhlIGFsZ29yaXRobXMgc3VwcG9ydGVkIGFuZCBhZ3JlZSBvbiB0aGUgaGFzaCBmdW5j dGlvbi4gQWZ0ZXIgdGhpcyBzdGVwIGFzIGV4cGxhaW5lZCBpbiBkcmFmdC1pZXRmLW9hdXRoLXBv cC1rZXktZGlzdHJpYnV0aW9uLTAwLCBjbGllbnQgc2lnbmFscyB0aGUgcmVzcGVjdGl2ZSBhbGdv cml0aG0gdG8gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4g4oCYYWxn4oCZIHBhcmFtZXRlciBhbmQg cmVjZWl2ZXMgdGhlIHN5bW1ldHJpYyBrZXkgd2hvc2UgaXMgbGVuZ3RoIGlzIGRldGVybWluZWQg YnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGJhc2VkIG9uIHRoZSBhbGdvcml0aG0gY29udmV5 ZWQgYnkgdGhlIGNsaWVudC4gDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+ID4NCj4gPj4NCj4g Pj4gICogSW4geW91ciBUVVJOIDwtPiBPQXV0aCB0ZXJtaW5vbG9neSBtYXBwaW5nIHlvdSBzYXkg dGhhdCB0aGUNCj4gPj4gcmVzb3VyY2Ugb3duZXIgY29ycmVzcG9uZHMgdG8gdGhlIFJUQ1dlYiBz ZXJ2ZXIuIEkgZG9uJ3QgdGhpbmsgdGhhdCdzDQo+ID4+IHRydWUuIFRoZSByZXNvdXJjZSBvd25l ciBpcyB0aGUgdXNlciBidXQgSSBiZWxpZXZlIHlvdSBhcmUgdHJ5aW5nIHRvDQo+ID4+IHNheSB0 aGF0IHRoZSB1c2VyIGdyYW50cyBhdXRob3JpemF0aW9uIGltcGxpY2l0bHkgYnkgbWFraW5nIGEg V2ViUlRDIGNhbGwuDQo+ID4NCj4gPiBUaGUgcmVzb3VyY2Ugb3duZXIgaXMgdGhlIFdlYlJUQyBz ZXJ2ZXIuIFdoZW4gY2xpZW50IG1ha2VzIGEgY2FsbCB1c2luZw0KPiB0aGUgV2ViUlRDIHNlcnZl ciwgaXQgYXV0aG9yaXplcyB0aGUgY2xpZW50IHRvIHVzZSB0aGUgcmVzb3VyY2VzIG9uIHRoZSBU VVJODQo+IHNlcnZlciBmb3IgYSBzcGVjaWZpYyBwZXJpb2Qgb2YgdGltZS4gVGhlIHVzZXIgaXMg Z3JhbnRlZCBhdXRob3JpemF0aW9uDQo+IGltcGxpY2l0bHkgYnkgbWFraW5nIGEgV2ViUlRDIGNh bGwuDQo+IFRoYXQncyB3aGF0IEkgdGhvdWdodC4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0K PiA+DQo+ID4gQ2hlZXJzLA0KPiA+IC1UaXJ1DQo+ID4NCj4gPj4NCj4gPj4gQ2lhbw0KPiA+PiBI YW5uZXMNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPg0KDQo= From nobody Mon Aug 25 07:10:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029451A895F for ; Mon, 25 Aug 2014 07:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ku67lsxA9F7Y for ; Mon, 25 Aug 2014 07:10:51 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7B88D1A8958 for ; Mon, 25 Aug 2014 07:10:51 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 90795475BE; Mon, 25 Aug 2014 14:10:50 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 83E9D475B9; Mon, 25 Aug 2014 14:10:50 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 7CC5080044; Mon, 25 Aug 2014 14:10:50 +0000 (GMT) Message-ID: <53FB43EA.9070409@akamai.com> Date: Mon, 25 Aug 2014 10:10:50 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BUYyUDmG6b9ef8U08Lfqhch4NIE Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:10:54 -0000 rfc2104 states that the key may be any length up to the block size, but that when it is shorter it must be padded with zero bytes in order to extend it out to the block size. When longer, it must be first hashed using the algorithm in order to trim it. In other words, every SHA-1 key has a 160 bit form, even if the user provided a key that is either shorter or longer. --Brandon On 08/23/2014 03:37 AM, Oleg Moskalenko wrote: > Actually, although, normally, 128-bits keys are used with HMAC-SHA-1, > other key lengths are possible with that function. I admit that my > suggestion may not be entirely accurate. > > Oleg > > > > On Fri, Aug 22, 2014 at 11:47 PM, Oleg Moskalenko > wrote: > > Tiru, I found an error in the 6.2 section (ACCESS_TOKEN). It is > mentioning the HMAC-SHA-1 algorithm with 160 bits key. This is > actually incorrect: HMAC-SHA-1 has 160 bits output result, but it > uses 128 bits input key, normally. > > Another problem is that I am not sure that the hash agility plan > idea described in RFC5389 is still valid. I am afraid that it is > unnecessary complicated and outdated, taking into account the > current level of SHA-256 adoption. The plan was designed to support, > "transparently", the old TURN servers. But in these specs, we do not > necessary have to support the "old" servers with HMAC-SHA-1 only > implementations; as we are writing a new oAuth procedure, there will > be only "new" servers supporting the draft specs, anyway. The "old" > servers will not be able to use the oAuth specs. SO we can design a > cleaner simpler hash agility procedure. > > > So the text has to be fixed: > > OLD TEXT: > ---------------- > > key_length: Length of the session key. Key length of 160-bits MUST > be supported (i.e only 160-bit key is used by HMAC-SHA-1 for > message integrity of STUN message). The key length facilitates > the hash agility plan discussed insection 16.3 of [RFC5389] . > > > NEW TEXT: > > > ------------------ > > key_length: Length of the session key. Key length of 128-bits MUST > be supported (128-bit key is used by HMAC-SHA-1 for > message integrity of STUN message).Key length of256-bits SHOULD > be supported (256-bit key is used by HMAC-SHA-256).Other key lengths > MAY be supported. The key length facilitates the hash agility: > > > the SHA digest algorithm is chosen depending on the key length. > > Thanks > > Oleg > > > > > > > > On Fri, Aug 22, 2014 at 9:11 AM, Oleg Moskalenko > > wrote: > > But I still think that making a single algorithm (like > AES_256_CBC) default across all use cases is a good idea, I just > used wrong explanation for that. > > Oleg > > > On Fri, Aug 22, 2014 at 8:34 AM, Oleg Moskalenko > > wrote: > > Sorry, scratch that - I take back my comment. > > Thanks > Oleg > > > On Fri, Aug 22, 2014 at 12:48 AM, Tirumaleswar Reddy > (tireddy) > wrote: > > *From:*tram [mailto:tram-bounces@ietf.org > ] *On Behalf Of *Oleg > Moskalenko > *Sent:* Friday, August 22, 2014 12:27 PM > *To:* tram@ietf.org > *Subject:* [tram] > draft-ietf-tram-turn-third-party-authz-03____ > > __ __ > > I have the following comment:____ > > In the section 4.1.1 and 4.1.2, the encryption algorithm > AES_256_CBC has to be used, because the HKDF-Expand > function of length 16 does not make much sense, > according to RFC 5869 section 2.3.____ > > So, I suggest to use AES_256_CBC consistently across the draft text as the default > encryption algorithm. In the section 4.1.3 it is already used as the default algorithm, > > > > > > ____ > > anyway.____ > > [TR] Thanks, will that in the next revision.____ > > -Tiru____ > > Thanks > Oleg____ > > > > > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 25 07:28:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAD51A0188; Fri, 22 Aug 2014 01:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kba3-NLFL06V; Fri, 22 Aug 2014 01:35:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5553E1A0191; Fri, 22 Aug 2014 01:35:07 -0700 (PDT) Received: from [172.16.254.100] ([80.92.114.249]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M3S2C-1WU9go1ueu-00r1J1; Fri, 22 Aug 2014 10:34:58 +0200 Message-ID: <53F700D2.8000502@gmx.net> Date: Fri, 22 Aug 2014 10:35:30 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , "oauth@ietf.org" References: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m5jWC4pc6ErdgInVWJt2Vj206UgfBno45" X-Provags-ID: V03:K0:iXrENLDsXRIoizRo7EJEp5Bhe/ruMX123xRzhAewCtG1YH49mDk yGZxo26kpzH+LE5O2mjaosbZ+56XCvLbYxVUrBjcAlG1mrGoo0d6wVgQvXCDtxluTlOsUHu 52EEtRD5fL83R5IG8nT18TwV00WRcmye9XrmhAubpaXilsOwXn7M4Lior3rfeOePT9aLVud B3h7umL4GmdyDC3o12WGQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tram/f6l9y4PnzJGKRZmdUiEgMIT_F6o X-Mailman-Approved-At: Mon, 25 Aug 2014 07:28:02 -0700 Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 08:35:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m5jWC4pc6ErdgInVWJt2Vj206UgfBno45 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tiru, ~snip~ >> * The Design >> >> I would have used OAuth as is (or maybe selected a specific grant type= ) to >> obtain an access token. Then, I would have defined how the access toke= n is >> carried in the TURN protocol. This is a bit similar what we have alrea= dy done >> with the OAuth SASL draft where we defined a new way to convey the acc= ess >> token from the SASL client to the SASL server. >> >> How did the authors solve that problem? They pretty much did what I ju= st >> explained. Since TURN does not use DTLS (or TLS) the proof-of-possessi= on >> security work we are doing becomes relevant (namely the symmetric key-= >> based part). >=20 > Yes, the communication b/w TURN client and server may or may not use (D= )TLS, hence=20 > proof-of-possession security work is used. I know saw in one of the references that there is a proposal for DTLS. In that case you might already want to consider re-using the channel binding work as well. >=20 >> >> Putting discovery information in-band into the exchange is also find (= which is >> what we did in the SASL document). >> >> Instead of using the JWT access token format the authors have defined = a >> new, binary encoding to keep the size smaller. The OAuth framework all= ows >> other token formats to be used - so that's fine as well. >> (As a minor remark, I would use AEAD ciphers here since that's what >> everyone is doing noways.) >=20 > Good point, will update the draft to use AEAD. Ok >=20 >> >> Two things surprised me: >> >> a) The spec leaves the way to obtain the access token pretty much open= =2E >> A big benefit from using OAuth is that there is a protocol mechanism d= efined >> for getting the access token. You could, for example, recommend using >> authorization code flow. This concerns the text written in Section 4. >=20 > Using authorization code flow is discussed in Section 4 of the draft. >=20 > > OAuth in [RFC6749] defines four grant types. This specification use= s > the OAuth grant type "Implicit" explained in section 1.3.2 of > [RFC6749] where the WebRTC client is issued an access token directly= =2E > >=20 > Are you suggesting that we add more details ? I missed that. That's fine. >=20 >> >> b) You describe a key establishment scheme to be used between the >> resource server and the authorization server. What assumption do you m= ake >> about the relationship between the authorization server and the resour= ce >> server? Are they supposed to have a business relationship or some othe= r >> relationship with each other ? >=20 > Authorization and Resource servers could have a business relationship (= loosely coupled, for example Enterprise network using TURN server provide= d by third party provider like Akamai) or could be deployed in the same a= dministrative domain (tightly coupled, for example Google providing both = WebRTC and TURN servers) I guess you assume that there is some long-term secret (such as asymmetric credential) in place and you then derive the symmetric keys from it (by using DSKPP). Maybe you want to say that (in addition to the assumed relationship between the two entities). If there is no relationship between the two parties then they will certainly be a challenge to get this done securely. >=20 >> >> Minor aspects: >> >> * Would the TURN server name really be an email alike address rather = than >> a URI ? >=20 > Yes, for more information please refer to http://tools.ietf.org/html/dr= aft-ietf-tram-turn-server-discovery-00 >=20 Thanks. Why do you need the username part for the discovery of the TURN server capabilities? I couldn't find the answer to that question by quickly looking at the TURN server discovery document. Do you expect that the configuration is different from user to user? The procedure seems to be: Client -> TURN server: Establish Tunnel Client <- TURN server: error - here is my "email" alike address (foo@turn.com) Client -> DNS: DNS Lookup (turn.com) Client <- DNS: something domain name back Client -> DNS: NAPTR Client <- DNS: IP address back Is this correct? >> >> * Would you use Dynamic Client Registration to provision the client w= ith the >> necessary parameter? Is there the expectation that random clients woul= d >> work with random authorization servers ? >=20 > No, client must authenticate with the authorization server (SIP/WebRTC = server) to make a call. Ok. >=20 >> >> * Wouldn't you want to define a scope value for use with the TURN ser= vice >> so that the authorization server is able to restrict the access token = for use >> with TURN only? >=20 > The scope value for use with the TURN service is defined in section 4 >=20 > > The scope of the access token explained in section 3.3 of [RFC6749] > MUST be TURN. > Ok. The scope string is 'turn'. >=20 >> >> * Crypto algorithm negotiation: would you expect the authorization se= rver to >> tell the client what crypto algorithms to use (since the authorization= server >> not only needs to share a key with the resource server but also needs = to have >> knowledge about the supported cryptographic algorithms) ? >=20 > Currently STUN only uses HMAC-SHA1, hence details about authorization s= erver telling the client about the crypto algorithm to use is not explici= tly mentioned in the draft. OK. Is there any plan to provide more than just HMAC-SHA1? >=20 >> >> * In your TURN <-> OAuth terminology mapping you say that the resourc= e >> owner corresponds to the RTCWeb server. I don't think that's true. The= >> resource owner is the user but I believe you are trying to say that th= e user >> grants authorization implicitly by making a WebRTC call. >=20 > The resource owner is the WebRTC server. When client makes a call using= the WebRTC server, it authorizes the client to use the resources on the = TURN server for a specific period of time. The user is granted authorizat= ion implicitly by making a WebRTC call. That's what I thought. Ciao Hannes >=20 > Cheers, > -Tiru >=20 >> >> Ciao >> Hannes >> >> >> >=20 --m5jWC4pc6ErdgInVWJt2Vj206UgfBno45 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJT9wDTAAoJEGhJURNOOiAtm1YH/ip1lM9gfGo5G23vMfd7Yzi6 Mv6Sn2Gfp3/X3NpO7qIpKAZ6HR/6h35UEksEDA5qzC6XEVuHsWEqFsx10l15jHj1 mjzjKpYVl6NMm7ecoY/gGIQCC2B4ZdCxODQxgvKaOiOoyKn9VilbEXUe/7ZRSzMp kxhVB5eo82saS15mF5eRhIbAlMgwqCa/FfQ1G3u/dvR/1m6BaPfBpRtnFE4sCpWo qIEHDqMJlPU+uDFDCNSbuE42Dd+2pPIjEayRuFifc9PE3//LLAceQwJObElKz1Qb PPeZw4+N+aqeM27GHLf/xV3yPSftS7+TmOLC7joGYX9mphN9iHhf+ATY1Nl+d1c= =tX8I -----END PGP SIGNATURE----- --m5jWC4pc6ErdgInVWJt2Vj206UgfBno45-- From nobody Mon Aug 25 07:28:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFFC1A885A; Sun, 24 Aug 2014 15:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_DOMAIN_NOVOWEL=0.5, URI_NOVOWEL=0.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ2VXqVr4UI1; Sun, 24 Aug 2014 15:16:43 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 45F3E1A8857; Sun, 24 Aug 2014 15:16:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id 748065382384; Sun, 24 Aug 2014 15:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at promanage-inc.com Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q45Z1jrWhqQK; Sun, 24 Aug 2014 15:16:41 -0700 (PDT) Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id CB1635382376; Sun, 24 Aug 2014 15:16:41 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <53F700D2.8000502@gmx.net> Date: Sun, 24 Aug 2014 15:16:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75ABCB88-B531-442F-9643-C954ED3AA528@xmlgrrl.com> References: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> <53F700D2.8000502@gmx.net> To: "Tirumaleswar Reddy (tireddy)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HTj7BKsNBRO8_yEXMP1aafZiZco X-Mailman-Approved-At: Mon, 25 Aug 2014 07:28:02 -0700 Cc: "tram@ietf.org" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "sperreault@jive.com" , Hannes Tschofenig , "oauth@ietf.org" Subject: Re: [tram] [OAUTH-WG] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 22:16:45 -0000 In case the UMA model of establishing and conducting loosely coupled = AS-RS relationships is of interest, you can find more information here: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-10 (for the AS's = protection API, the OAuth token securing that API, and the declaration = of AS config data including endpoints) http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-03 (for the = resource set registration sub-API) Eve On 22 Aug 2014, at 1:35 AM, Hannes Tschofenig = wrote: > Hi Tiru, >> ... >>> ... >>> b) You describe a key establishment scheme to be used between the >>> resource server and the authorization server. What assumption do you = make >>> about the relationship between the authorization server and the = resource >>> server? Are they supposed to have a business relationship or some = other >>> relationship with each other ? >>=20 >> Authorization and Resource servers could have a business relationship = (loosely coupled, for example Enterprise network using TURN server = provided by third party provider like Akamai) or could be deployed in = the same administrative domain (tightly coupled, for example Google = providing both WebRTC and TURN servers) >=20 > I guess you assume that there is some long-term secret (such as > asymmetric credential) in place and you then derive the symmetric keys > from it (by using DSKPP). Maybe you want to say that (in addition to = the > assumed relationship between the two entities). If there is no > relationship between the two parties then they will certainly be a > challenge to get this done securely. Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From nobody Mon Aug 25 07:35:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A61A898A for ; Mon, 25 Aug 2014 07:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvSSGQ4KCFQJ for ; Mon, 25 Aug 2014 07:35:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 66C021A8966 for ; Mon, 25 Aug 2014 07:35:40 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C60242853E; Mon, 25 Aug 2014 14:35:37 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id B072B284F0; Mon, 25 Aug 2014 14:35:37 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id AD4B28004B; Mon, 25 Aug 2014 14:35:37 +0000 (GMT) Message-ID: <53FB49B9.2010202@akamai.com> Date: Mon, 25 Aug 2014 10:35:37 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Oleg Moskalenko , "Tirumaleswar Reddy (tireddy)" References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BuqgXvIZxHX4zz5dal72idnVOrI Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:35:42 -0000 I agree that the 5389 hash agility plan seems problematic and should be replaced with something more suitable to the stated purpose. That should probably be part of the stun-bis effort, or at happen concurrently so that stun-bis can reference the relevant document. Completion of this effort might be a requirement for publishing the 3rd party auth draft, because we don't want to end up publishing a draft that requires an immediate update in order to satisfy a not-yet-written hash agility requirement. The area that I think is most likely to be challenging with the current 3rd party auth draft is algorithm identification. It will be necessary at some point in the future for the TURN server to select from among multiple supported auth algorithms, but there is no obvious way at the moment for the auth algorithm to be communicated from the auth server to either the client or the TURN server. The only value that could currently be used to guess the auth algorithm is the key_length in the token, but using key_length as an algorithm identifier seems risky, even if it would work with the most likely candidates today. --Brandon On 08/23/2014 02:47 AM, Oleg Moskalenko wrote: > Another problem is that I am not sure that the hash agility plan idea > described in RFC5389 is still valid. I am afraid that it is unnecessary > complicated and outdated, taking into account the current level of > SHA-256 adoption. The plan was designed to support, "transparently", the > old TURN servers. But in these specs, we do not necessary have to > support the "old" servers with HMAC-SHA-1 only implementations; as we > are writing a new oAuth procedure, there will be only "new" servers > supporting the draft specs, anyway. The "old" servers will not be able > to use the oAuth specs. SO we can design a cleaner simpler hash agility > procedure. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 25 07:58:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC671A9096; Mon, 25 Aug 2014 07:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXX9lLgMAloh; Mon, 25 Aug 2014 07:58:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3761A909B; Mon, 25 Aug 2014 07:58:32 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 596F7475C0; Mon, 25 Aug 2014 14:58:32 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4D06C475BF; Mon, 25 Aug 2014 14:58:32 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4579E202F; Mon, 25 Aug 2014 14:58:32 +0000 (GMT) Message-ID: <53FB4F18.7030709@akamai.com> Date: Mon, 25 Aug 2014 10:58:32 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Hannes Tschofenig , "Tirumaleswar Reddy (tireddy)" , "oauth@ietf.org" References: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> <53F700D2.8000502@gmx.net> In-Reply-To: <53F700D2.8000502@gmx.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-kh6sOU04NBNw1I_kYQKURUe-1U Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 14:58:35 -0000 The TURN server name value in the THIRD-PARTY-AUTHORIZATION attribute servers 2 purposes, although only one of them is clearly called out in the document. The first purpose is to allow the OAuth server to select from among multiple 3rd party TURN service providers so that the appropriate key material can be selected when generating the token. The second purpose, which isn't called out in the document, is to provide a unique identifier for the specific server within the deployment so that the generated ACCESS-TOKEN value will only be considered valid by that specific server (i.e. to prevent replay of the token to multiple TURN servers). So, you can consider "foo@turn.com" to mean "generate a token for the server named foo at service provider turn.com". I think the client would perform the required DNS lookups first to get the address of a specific server, after which it would attempt to establish the tunnel in order to get the error with the server name back. Alternatively, based on the service provider's naming conventions and use of IP addresses, it might be possible to avoid the initial exchange with the TURN server by allowing the client to construct the server name without having to ask (at least that's what I hope to do). --Brandon On 08/22/2014 04:35 AM, Hannes Tschofenig wrote: >>> Minor aspects: >>> >> >>> >> * Would the TURN server name really be an email alike address rather than >>> >>a URI ? >> > >> >Yes, for more information please refer tohttp://tools.ietf.org/html/draft-ietf-tram-turn-server-discovery-00 >> > > Thanks. Why do you need the username part for the discovery of the TURN > server capabilities? I couldn't find the answer to that question by > quickly looking at the TURN server discovery document. Do you expect > that the configuration is different from user to user? > > The procedure seems to be: > > Client -> TURN server: Establish Tunnel > Client <- TURN server: error - here is my "email" alike address > (foo@turn.com) > Client -> DNS: DNS Lookup (turn.com) > Client <- DNS: something domain name back > Client -> DNS: NAPTR > Client <- DNS: IP address back > > Is this correct? > -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 25 08:07:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFEB1A909A; Mon, 25 Aug 2014 08:06:57 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65H7ZC3P5Z1G; Mon, 25 Aug 2014 08:06:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDE51A909F; Mon, 25 Aug 2014 08:06:47 -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: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825150647.23591.54399.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 08:06:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Q5Ap4m9siyQhIT6qi8hNRy66Sok Cc: tram mailing list , tram chair , RFC Editor Subject: [tram] Document Action: 'Problems with STUN long-term Authentication for TURN' to Informational RFC (draft-ietf-tram-auth-problems-05.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 15:06:57 -0000 The IESG has approved the following document: - 'Problems with STUN long-term Authentication for TURN' (draft-ietf-tram-auth-problems-05.txt) as Informational RFC This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ Technical Summary This document discusses some of the issues with STUN authentication for TURN messages. Working Group Summary This document became a WG item after having been discussed within the TRAM community. By the time the document became a WG item, there was consensus on its contents. After becoming a WG item the document was reviewed by a dedicated reviewer, whose comments were addressed by the draft's editors. Document Quality This is a discussion document that is not intended to be implemented. Personnel Gonzalo Camarillo is the document Shepherd. Spencer Dawkins is the responsible AD. From nobody Mon Aug 25 09:47:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42711A001E for ; Mon, 25 Aug 2014 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGmjDx4AZCsu for ; Mon, 25 Aug 2014 09:47:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F371A002A for ; Mon, 25 Aug 2014 09:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1855; q=dns/txt; s=iport; t=1408985024; x=1410194624; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dsF7lqQc+71EyrpNLdywPa7uXFIgn05xv8asFYVWLPg=; b=kPnDERxblmr/Jso9iOfnVWe2r/u0S2HZdEKU8VO7Q5yZzc1f65++B8Sp 6H7tRnT1GtPg+YfZEeMRLPqeWAgI8oL+p85D/gRNphJx+HMXNWBG+gEPT oTTXZjczwe8vVBiYVbP6eqr1Af+gL4Clp4Oo1fHKTdh8ksJDoVE/bys3C o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FACxn+1OtJV2S/2dsb2JhbABZgw1TUwQEzFeHSwGBIhZ3hAQBAQQ6PRICAQg2EDIbAQYDAgQTCRKIJwgFv3MXjwdMhEwFjxOCE4QphnqBWJM0g15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="350062160" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP; 25 Aug 2014 16:43:43 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7PGhfD1002859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Aug 2014 16:43:42 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.38]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 11:43:41 -0500 From: "Prashanth Patil (praspati)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-tram-turn-mobility-01.txt Thread-Index: AQHPwGQHc9Rg7Ez/10eWiCShwyNsvJviNq6A Date: Mon, 25 Aug 2014 16:43:41 +0000 Message-ID: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> In-Reply-To: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.65.67.214] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Q_m9w7Fq-kFnaUTssxJjgv_a6Wg Subject: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:47:25 -0000 All, We've submitted a revision of the 'Mobility with TURN' draft. The update addresses comments raised by Brandon during IETF-90 regarding TURN client and server behavior when a STUN refresh message carrying MOBILITY-TICKET attribute is lost. Comments welcome. Thanks, Prashanth On 8/25/14 6:26 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-wing-tram-turn-mobility-01.txt >has been successfully submitted by Prashanth Patil and posted to the >IETF repository. > >Name: draft-wing-tram-turn-mobility >Revision: 01 >Title: Mobility with TURN >Document date: 2014-08-25 >Group: Individual Submission >Pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ >Htmlized: =20 >http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-tram-turn-mobility-01 > >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 TURN. > This is achieved by allowing a client to retain an allocation on the > TURN server when the IP address of the client changes. > > =20 > =20 > > >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. > >The IETF Secretariat > From nobody Mon Aug 25 09:50:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273481A0023 for ; Mon, 25 Aug 2014 09:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZphDPNiKwm9 for ; Mon, 25 Aug 2014 09:50:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D45C1A002D for ; Mon, 25 Aug 2014 09:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3802; q=dns/txt; s=iport; t=1408985423; x=1410195023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3LqhWG3lFQ+ph4kLUXsl20mpK/q/4ccT1lcB1LGAVgw=; b=VF9QXSwWZ4cqljBnS8Bbf/uM7sqIwt3ekjQ9eecSNDM4YY4cR9RxNRuj 5GDSqbUFCJJDcob9gOLj4nmlJYBiCltwPEtK2IRCbC37HW4koTWJkrvFS vuGHsw85sEWr+kD08FgsSXCVcuZvIUZ4Q8l3hYAEvyQHsDkaEiaXc6I8f U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFANBo+1OtJA2D/2dsb2JhbABagw2BKgSCeNEqARmBCRZ3hAMBAQEEIxFFDAQCAQgRBAEBAQICBgsSAwICAjAUAQgIAgQBDQUIiDqrLZRXF4EsjW8WGwcGBIJvNoEdAQSRJoZjmUyBZhyBXGyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="72108490" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP; 25 Aug 2014 16:50:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7PGoMnl004346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 16:50:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 11:50:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPvh6kq35uUUTVWUmRVXfrcnASwZvdHvyAgAD0xgCAA6d+gP//zzEA Date: Mon, 25 Aug 2014 16:50:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831AEC3@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> <53FB49B9.2010202@akamai.com> In-Reply-To: <53FB49B9.2010202@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hn0vykjzP668nepEtvUthVqNFj0 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 16:50:25 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEF1Z3Vz dCAyNSwgMjAxNCA4OjA2IFBNDQo+IFRvOiBPbGVnIE1vc2thbGVua287IFRpcnVtYWxlc3dhciBS ZWRkeSAodGlyZWRkeSkNCj4gQ2M6IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmFt XSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiANCj4gSSBhZ3Jl ZSB0aGF0IHRoZSA1Mzg5IGhhc2ggYWdpbGl0eSBwbGFuIHNlZW1zIHByb2JsZW1hdGljIGFuZCBz aG91bGQgYmUNCj4gcmVwbGFjZWQgd2l0aCBzb21ldGhpbmcgbW9yZSBzdWl0YWJsZSB0byB0aGUg c3RhdGVkIHB1cnBvc2UuIFRoYXQgc2hvdWxkDQo+IHByb2JhYmx5IGJlIHBhcnQgb2YgdGhlIHN0 dW4tYmlzIGVmZm9ydCwgb3IgYXQgaGFwcGVuIGNvbmN1cnJlbnRseSBzbyB0aGF0DQo+IHN0dW4t YmlzIGNhbiByZWZlcmVuY2UgdGhlIHJlbGV2YW50IGRvY3VtZW50LiBDb21wbGV0aW9uIG9mIHRo aXMgZWZmb3J0DQo+IG1pZ2h0IGJlIGEgcmVxdWlyZW1lbnQgZm9yIHB1Ymxpc2hpbmcgdGhlIDNy ZCBwYXJ0eSBhdXRoIGRyYWZ0LCBiZWNhdXNlIHdlDQo+IGRvbid0IHdhbnQgdG8gZW5kIHVwIHB1 Ymxpc2hpbmcgYSBkcmFmdCB0aGF0IHJlcXVpcmVzIGFuIGltbWVkaWF0ZSB1cGRhdGUgaW4NCj4g b3JkZXIgdG8gc2F0aXNmeSBhIG5vdC15ZXQtd3JpdHRlbiBoYXNoIGFnaWxpdHkgcmVxdWlyZW1l bnQuDQo+IA0KPiBUaGUgYXJlYSB0aGF0IEkgdGhpbmsgaXMgbW9zdCBsaWtlbHkgdG8gYmUgY2hh bGxlbmdpbmcgd2l0aCB0aGUgY3VycmVudCAzcmQgcGFydHkNCj4gYXV0aCBkcmFmdCBpcyBhbGdv cml0aG0gaWRlbnRpZmljYXRpb24uIEl0IHdpbGwgYmUgbmVjZXNzYXJ5IGF0IHNvbWUgcG9pbnQg aW4gdGhlDQo+IGZ1dHVyZSBmb3IgdGhlIFRVUk4gc2VydmVyIHRvIHNlbGVjdCBmcm9tIGFtb25n IG11bHRpcGxlIHN1cHBvcnRlZCBhdXRoDQo+IGFsZ29yaXRobXMsIGJ1dCB0aGVyZSBpcyBubyBv YnZpb3VzIHdheSBhdCB0aGUgbW9tZW50IGZvciB0aGUgYXV0aA0KPiBhbGdvcml0aG0gdG8gYmUg Y29tbXVuaWNhdGVkIGZyb20gdGhlIGF1dGggc2VydmVyIHRvIGVpdGhlciB0aGUgY2xpZW50IG9y DQo+IHRoZSBUVVJOIHNlcnZlci4gVGhlIG9ubHkgdmFsdWUgdGhhdCBjb3VsZCBjdXJyZW50bHkg YmUgdXNlZCB0byBndWVzcyB0aGUNCj4gYXV0aCBhbGdvcml0aG0gaXMgdGhlIGtleV9sZW5ndGgg aW4gdGhlIHRva2VuLCBidXQgdXNpbmcga2V5X2xlbmd0aCBhcyBhbg0KPiBhbGdvcml0aG0gaWRl bnRpZmllciBzZWVtcyByaXNreSwgZXZlbiBpZiBpdCB3b3VsZCB3b3JrIHdpdGggdGhlIG1vc3Qg bGlrZWx5DQo+IGNhbmRpZGF0ZXMgdG9kYXkuDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0 byBhZGRyZXNzIHRoZSBwcm9ibGVtIGluIHRoZSBmb2xsb3dpbmcgd2F5Og0KV2hlbiBTVFVOIHN1 cHBvcnRzIEhNQUMgYWxnb3JpdGhtcyBvdGhlciB0aGFuIEhNQUMtU0hBLTEgdGhlbiBjbGllbnQg d2lsbCBjb252ZXkgdGhlIGFsZ29yaXRobSBuZWdvdGlhdGVkIHdpdGggdGhlIFRVUk4gc2VydmVy IHRvICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gdGhlIHZhbHVlIG9mICdhbGcnIHBhcmFt ZXRlciBkZWZpbmVkIGluDQpbSS1ELmlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb25dLiAg QXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyBsZW5ndGggb2YgdGhlIG1hY19rZXkgYmFz ZWQgb24gdGhlIEhNQUMgYWxnb3JpdGhtIGNvbnZleWVkIGJ5IHRoZSBjbGllbnQuDQoNCi1UaXJ1 DQoNCj4gDQo+IC0tQnJhbmRvbg0KPiANCj4gT24gMDgvMjMvMjAxNCAwMjo0NyBBTSwgT2xlZyBN b3NrYWxlbmtvIHdyb3RlOg0KPiA+IEFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IEkgYW0gbm90IHN1 cmUgdGhhdCB0aGUgaGFzaCBhZ2lsaXR5IHBsYW4gaWRlYQ0KPiA+IGRlc2NyaWJlZCBpbiBSRkM1 Mzg5IGlzIHN0aWxsIHZhbGlkLiBJIGFtIGFmcmFpZCB0aGF0IGl0IGlzDQo+ID4gdW5uZWNlc3Nh cnkgY29tcGxpY2F0ZWQgYW5kIG91dGRhdGVkLCB0YWtpbmcgaW50byBhY2NvdW50IHRoZSBjdXJy ZW50DQo+ID4gbGV2ZWwgb2YNCj4gPiBTSEEtMjU2IGFkb3B0aW9uLiBUaGUgcGxhbiB3YXMgZGVz aWduZWQgdG8gc3VwcG9ydCwgInRyYW5zcGFyZW50bHkiLA0KPiA+IHRoZSBvbGQgVFVSTiBzZXJ2 ZXJzLiBCdXQgaW4gdGhlc2Ugc3BlY3MsIHdlIGRvIG5vdCBuZWNlc3NhcnkgaGF2ZSB0bw0KPiA+ IHN1cHBvcnQgdGhlICJvbGQiIHNlcnZlcnMgd2l0aCBITUFDLVNIQS0xIG9ubHkgaW1wbGVtZW50 YXRpb25zOyBhcyB3ZQ0KPiA+IGFyZSB3cml0aW5nIGEgbmV3IG9BdXRoIHByb2NlZHVyZSwgdGhl cmUgd2lsbCBiZSBvbmx5ICJuZXciIHNlcnZlcnMNCj4gPiBzdXBwb3J0aW5nIHRoZSBkcmFmdCBz cGVjcywgYW55d2F5LiBUaGUgIm9sZCIgc2VydmVycyB3aWxsIG5vdCBiZSBhYmxlDQo+ID4gdG8g dXNlIHRoZSBvQXV0aCBzcGVjcy4gU08gd2UgY2FuIGRlc2lnbiBhIGNsZWFuZXIgc2ltcGxlciBo YXNoDQo+ID4gYWdpbGl0eSBwcm9jZWR1cmUuDQo+IA0KPiAtLQ0KPiBCcmFuZG9uIFdpbGxpYW1z OyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nIFByb2R1Y3RzDQo+ IEVuZ2luZWVyaW5nOyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCg== From nobody Mon Aug 25 10:03:27 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F051A00C2; Mon, 25 Aug 2014 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXQ5RBq4-H0m; Mon, 25 Aug 2014 10:03:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA0B1A006C; Mon, 25 Aug 2014 10:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4546; q=dns/txt; s=iport; t=1408986194; x=1410195794; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0Zz8B9ujcDNIrfQXAd3m6mgI7iHSa2zD/vr699odZAE=; b=aPxhh4/s0py2P2yCbJSQ8RusERGlNsCLNw8YHBRIoEM6ooJuK4uPDJGh YJ2z/0pP9voRo4yVuqNVrOsxNFXf/SLi/+gHZnHu4siDGtrXDdVwHVzs8 7SDts/7mau+7+NNJ8el1IlUUycSvzopgZS5+q992yziApoWnQFRtBllXE s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFACFr+1OtJA2H/2dsb2JhbABagw1TVwSCeMlVh1UBGYEJFneEAwEBAQMBIwQNOAoDDAQCAQgRBAEBAQICBh0DAgICMBQBCAgBAQQBDQUIiDIIqzKUWReBLI0+EQEfFhsHBoJzNoEdAQSRJoQpgjqGGJM0g15sgQ85gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72112117" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP; 25 Aug 2014 17:03:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7PH3D27032047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 17:03:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 12:03:13 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 Thread-Index: Ac+9wboQ5l8DJdE+SCio/9XibBSHZAATDasAAKRAZgAABjwp0A== Date: Mon, 25 Aug 2014 17:03:12 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831AF14@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A2831989C@xmb-rcd-x10.cisco.com> <53F700D2.8000502@gmx.net> <53FB4F18.7030709@akamai.com> In-Reply-To: <53FB4F18.7030709@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/R9Z-OvXaW3ffoJKHDk_-ab_sbNs Cc: "sperreault@jive.com" , "draft-ietf-tram-turn-third-party-authz@tools.ietf.org" , "Gonzalo.Camarillo@ericsson.com >> Gonzalo Camarillo" , "tram@ietf.org" Subject: Re: [tram] Review of draft-ietf-tram-turn-third-party-authz-01 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:03:25 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEF1Z3Vz dCAyNSwgMjAxNCA4OjI5IFBNDQo+IFRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KTsgb2F1dGhAaWV0Zi5vcmcNCj4gQ2M6IHNwZXJyZWF1bHRAaml2ZS5j b207IGRyYWZ0LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LQ0KPiBhdXRoekB0b29scy5pZXRm Lm9yZzsgR29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tID4+IEdvbnphbG8NCj4gQ2FtYXJp bGxvOyB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJhbV0gUmV2aWV3IG9mIGRyYWZ0 LWlldGYtdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAxDQo+IA0KPiBUaGUgVFVSTiBzZXJ2 ZXIgbmFtZSB2YWx1ZSBpbiB0aGUgVEhJUkQtUEFSVFktQVVUSE9SSVpBVElPTiBhdHRyaWJ1dGUN Cj4gc2VydmVycyAyIHB1cnBvc2VzLCBhbHRob3VnaCBvbmx5IG9uZSBvZiB0aGVtIGlzIGNsZWFy bHkgY2FsbGVkIG91dCBpbiB0aGUNCj4gZG9jdW1lbnQuIFRoZSBmaXJzdCBwdXJwb3NlIGlzIHRv IGFsbG93IHRoZSBPQXV0aCBzZXJ2ZXIgdG8gc2VsZWN0IGZyb20NCj4gYW1vbmcgbXVsdGlwbGUg M3JkIHBhcnR5IFRVUk4gc2VydmljZSBwcm92aWRlcnMgc28gdGhhdCB0aGUgYXBwcm9wcmlhdGUg a2V5DQo+IG1hdGVyaWFsIGNhbiBiZSBzZWxlY3RlZCB3aGVuIGdlbmVyYXRpbmcgdGhlIHRva2Vu LiBUaGUgc2Vjb25kIHB1cnBvc2UsDQo+IHdoaWNoIGlzbid0IGNhbGxlZCBvdXQgaW4gdGhlIGRv Y3VtZW50LCBpcyB0byBwcm92aWRlIGEgdW5pcXVlIGlkZW50aWZpZXIgZm9yDQo+IHRoZSBzcGVj aWZpYyBzZXJ2ZXIgd2l0aGluIHRoZSBkZXBsb3ltZW50IHNvIHRoYXQgdGhlIGdlbmVyYXRlZCBB Q0NFU1MtDQo+IFRPS0VOIHZhbHVlIHdpbGwgb25seSBiZSBjb25zaWRlcmVkIHZhbGlkIGJ5IHRo YXQgc3BlY2lmaWMgc2VydmVyIChpLmUuIHRvDQo+IHByZXZlbnQgcmVwbGF5IG9mIHRoZSB0b2tl biB0byBtdWx0aXBsZSBUVVJOIHNlcnZlcnMpLiBTbywgeW91IGNhbiBjb25zaWRlcg0KPiAiZm9v QHR1cm4uY29tIiB0byBtZWFuICJnZW5lcmF0ZSBhIHRva2VuIGZvciB0aGUgc2VydmVyIG5hbWVk IGZvbyBhdA0KPiBzZXJ2aWNlIHByb3ZpZGVyIHR1cm4uY29tIi4NCg0KVGhlIHNlY29uZCBwdXJw b3NlIGlzIGFsc28gZGlzY3Vzc2VkIGluIHNlY3Rpb24gNi4yDQo8c25pcD4NCkhNQUMgaXMgY29t cHV0ZWQgdXNpbmcgdGhlIGVuY3J5cHRlZCBwb3J0aW9uDQpvZiB0aGUgdG9rZW4gYW5kIFRVUk4g c2VydmVyIG5hbWUgdG8gZW5zdXJlIHRoYXQgdGhlIGNsaWVudCBkb2VzIG5vdA0KdXNlIHRoZSBz YW1lIHRva2VuIHRvIGdhaW4gaWxsZWdhbCBhY2Nlc3MgdG8gb3RoZXIgVFVSTiBzZXJ2ZXJzDQpw cm92aWRlZCBieSB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4uICBUaGlzIGF0dGFjayBp cyBwb3NzaWJsZQ0Kd2hlbiBtdWx0aXBsZSBUVVJOIHNlcnZlcnMgaW4gYSBzaW5nbGUgYWRtaW5p c3RyYXRpdmUgZG9tYWluIHNoYXJlDQp0aGUgc2FtZSBzeW1tZXRyaWMga2V5IHdpdGggdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLg0KPC9zbmlwPg0KDQotVGlydQ0KDQo+IA0KPiBJIHRoaW5rIHRo ZSBjbGllbnQgd291bGQgcGVyZm9ybSB0aGUgcmVxdWlyZWQgRE5TIGxvb2t1cHMgZmlyc3QgdG8g Z2V0IHRoZQ0KPiBhZGRyZXNzIG9mIGEgc3BlY2lmaWMgc2VydmVyLCBhZnRlciB3aGljaCBpdCB3 b3VsZCBhdHRlbXB0IHRvIGVzdGFibGlzaCB0aGUNCj4gdHVubmVsIGluIG9yZGVyIHRvIGdldCB0 aGUgZXJyb3Igd2l0aCB0aGUgc2VydmVyIG5hbWUgYmFjay4gQWx0ZXJuYXRpdmVseSwNCj4gYmFz ZWQgb24gdGhlIHNlcnZpY2UgcHJvdmlkZXIncyBuYW1pbmcgY29udmVudGlvbnMgYW5kIHVzZSBv ZiBJUCBhZGRyZXNzZXMsDQo+IGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGF2b2lkIHRoZSBpbml0 aWFsIGV4Y2hhbmdlIHdpdGggdGhlIFRVUk4gc2VydmVyIGJ5DQo+IGFsbG93aW5nIHRoZSBjbGll bnQgdG8gY29uc3RydWN0IHRoZSBzZXJ2ZXIgbmFtZSB3aXRob3V0IGhhdmluZyB0byBhc2sgKGF0 DQo+IGxlYXN0IHRoYXQncyB3aGF0IEkgaG9wZSB0byBkbykuDQo+IA0KPiAtLUJyYW5kb24NCj4g DQo+IE9uIDA4LzIyLzIwMTQgMDQ6MzUgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiA+ Pj4gTWlub3IgYXNwZWN0czoNCj4gPj4+ID4+DQo+ID4+PiA+PiAgKiBXb3VsZCB0aGUgVFVSTiBz ZXJ2ZXIgbmFtZSByZWFsbHkgYmUgYW4gZW1haWwgYWxpa2UgYWRkcmVzcw0KPiA+Pj4gPj5yYXRo ZXIgdGhhbiBhIFVSSSA/DQo+ID4+ID4NCj4gPj4gPlllcywgZm9yIG1vcmUgaW5mb3JtYXRpb24g cGxlYXNlIHJlZmVyDQo+ID4+ID50b2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdHJhbS10dXJuLXNlcnZlci1kaXNjb3ZlcnktMA0KPiA+PiA+MA0KPiA+PiA+DQo+ID4gVGhh bmtzLiBXaHkgZG8geW91IG5lZWQgdGhlIHVzZXJuYW1lIHBhcnQgZm9yIHRoZSBkaXNjb3Zlcnkg b2YgdGhlDQo+ID4gVFVSTiBzZXJ2ZXIgY2FwYWJpbGl0aWVzPyBJIGNvdWxkbid0IGZpbmQgdGhl IGFuc3dlciB0byB0aGF0IHF1ZXN0aW9uDQo+ID4gYnkgcXVpY2tseSBsb29raW5nIGF0IHRoZSBU VVJOIHNlcnZlciBkaXNjb3ZlcnkgZG9jdW1lbnQuIERvIHlvdQ0KPiA+IGV4cGVjdCB0aGF0IHRo ZSBjb25maWd1cmF0aW9uIGlzIGRpZmZlcmVudCBmcm9tIHVzZXIgdG8gdXNlcj8NCj4gPg0KPiA+ IFRoZSBwcm9jZWR1cmUgc2VlbXMgdG8gYmU6DQo+ID4NCj4gPiBDbGllbnQgLT4gVFVSTiBzZXJ2 ZXI6IEVzdGFibGlzaCBUdW5uZWwgQ2xpZW50IDwtIFRVUk4gc2VydmVyOiBlcnJvciAtDQo+ID4g aGVyZSBpcyBteSAiZW1haWwiIGFsaWtlIGFkZHJlc3MNCj4gPiAoZm9vQHR1cm4uY29tKQ0KPiA+ IENsaWVudCAtPiBETlM6IEROUyBMb29rdXAgKHR1cm4uY29tKQ0KPiA+IENsaWVudCA8LSBETlM6 IHNvbWV0aGluZyBkb21haW4gbmFtZSBiYWNrIENsaWVudCAtPiBETlM6IE5BUFRSIENsaWVudA0K PiA+IDwtIEROUzogSVAgYWRkcmVzcyBiYWNrDQo+ID4NCj4gPiBJcyB0aGlzIGNvcnJlY3Q/DQo+ ID4NCj4gDQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdh cmUgRW5naW5lZXIgRW1lcmdpbmcgUHJvZHVjdHMNCj4gRW5naW5lZXJpbmc7IEFrYW1haSBUZWNo bm9sb2dpZXMgSW5jLg0K From nobody Mon Aug 25 10:10:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C271A007C for ; Mon, 25 Aug 2014 10:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFmr8Kfx_mqY for ; Mon, 25 Aug 2014 10:10:25 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFB1A00EC for ; Mon, 25 Aug 2014 10:10:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9BB2E4746F; Mon, 25 Aug 2014 17:10:13 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8629A4746B; Mon, 25 Aug 2014 17:10:13 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 817D4202E; Mon, 25 Aug 2014 17:10:13 +0000 (GMT) Message-ID: <53FB6DF5.2090702@akamai.com> Date: Mon, 25 Aug 2014 13:10:13 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> <53FB49B9.2010202@akamai.com> <913383AAA69FF945B8F946018B75898A2831AEC3@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831AEC3@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LWPQwUGrYXkY6cGpOvKazjp8wcI Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:10:28 -0000 I don't think that the client will be (or can safely be allow to be) responsible for selecting the algorithm. Somehow, this decision must be up to the OAuth server. The most that I think the client can do is send a list of what it supports, which will allow the server to select the best of the bunch (or reject if none are good enough). I haven't read the referenced draft or your proposed changes so it may be that you've already dealt with this part of the problem. --Brandon On 08/25/2014 12:50 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Monday, August 25, 2014 8:06 PM >> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy) >> Cc: tram@ietf.org >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> I agree that the 5389 hash agility plan seems problematic and should be >> replaced with something more suitable to the stated purpose. That should >> probably be part of the stun-bis effort, or at happen concurrently so that >> stun-bis can reference the relevant document. Completion of this effort >> might be a requirement for publishing the 3rd party auth draft, because we >> don't want to end up publishing a draft that requires an immediate update in >> order to satisfy a not-yet-written hash agility requirement. >> >> The area that I think is most likely to be challenging with the current 3rd party >> auth draft is algorithm identification. It will be necessary at some point in the >> future for the TURN server to select from among multiple supported auth >> algorithms, but there is no obvious way at the moment for the auth >> algorithm to be communicated from the auth server to either the client or >> the TURN server. The only value that could currently be used to guess the >> auth algorithm is the key_length in the token, but using key_length as an >> algorithm identifier seems risky, even if it would work with the most likely >> candidates today. > > I have updated the draft to address the problem in the following way: > When STUN supports HMAC algorithms other than HMAC-SHA-1 then client will convey the algorithm negotiated with the TURN server to the authorization server in the value of 'alg' parameter defined in > [I-D.ietf-oauth-pop-key-distribution]. Authorization server determines length of the mac_key based on the HMAC algorithm conveyed by the client. > > -Tiru > >> >> --Brandon >> >> On 08/23/2014 02:47 AM, Oleg Moskalenko wrote: >>> Another problem is that I am not sure that the hash agility plan idea >>> described in RFC5389 is still valid. I am afraid that it is >>> unnecessary complicated and outdated, taking into account the current >>> level of >>> SHA-256 adoption. The plan was designed to support, "transparently", >>> the old TURN servers. But in these specs, we do not necessary have to >>> support the "old" servers with HMAC-SHA-1 only implementations; as we >>> are writing a new oAuth procedure, there will be only "new" servers >>> supporting the draft specs, anyway. The "old" servers will not be able >>> to use the oAuth specs. SO we can design a cleaner simpler hash >>> agility procedure. >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 25 10:27:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3331A0079 for ; Mon, 25 Aug 2014 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBeUC7VmeT-a for ; Mon, 25 Aug 2014 10:27:46 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC561A00E1 for ; Mon, 25 Aug 2014 10:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5772; q=dns/txt; s=iport; t=1408987666; x=1410197266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7e0rlOL8i0jyckcVjD3FPgxFWa1fgrpRf5Y08d7csbs=; b=AG3VsiJ15RImXQOTTNM6PvyvWxdsb4a0VlmwXxwOo/ye6ieAMbqTKqBk EFjJdXgjjH74mwW+0guUVMtI923LHu/tXYi45AEISkH/Fg6AmsKix+zko vVIWAaqxz3bPAHVWm078WrZ14CYMHX2XLfMNCNUW0oemsYJlAkMl7b8zg M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAA5x+1OtJA2F/2dsb2JhbABagw2BKgSCeNEqARmBCRZ3hAMBAQEDASMRRQwEAgEIEQQBAQECAgYLEgMCAgIwFAEICAIEAQ0FCIgyCKswlF8XgSyNbxYbBwYEgm82gR0BBJEmhmOZTIFmHIFcbIFIgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,398,1406592000"; d="scan'208";a="72176467" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 25 Aug 2014 17:27:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7PHRjP9031746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 17:27:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 12:27:45 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: AQHPvh6kq35uUUTVWUmRVXfrcnASwZvdHvyAgAD0xgCAA6d+gP//zzEAgABcAYD//61+4A== Date: Mon, 25 Aug 2014 17:27:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831AF6D@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> <53FB49B9.2010202@akamai.com> <913383AAA69FF945B8F946018B75898A2831AEC3@xmb-rcd-x10.cisco.com> <53FB6DF5.2090702@akamai.com> In-Reply-To: <53FB6DF5.2090702@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.78.209] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/UqaUzAqe3acTO3kiUsWhVHF56ls Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:27:48 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEF1Z3Vz dCAyNSwgMjAxNCAxMDo0MCBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsg T2xlZyBNb3NrYWxlbmtvDQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJh bV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCj4gDQo+IEkgZG9u J3QgdGhpbmsgdGhhdCB0aGUgY2xpZW50IHdpbGwgYmUgKG9yIGNhbiBzYWZlbHkgYmUgYWxsb3cg dG8gYmUpIHJlc3BvbnNpYmxlDQo+IGZvciBzZWxlY3RpbmcgdGhlIGFsZ29yaXRobS4gU29tZWhv dywgdGhpcyBkZWNpc2lvbiBtdXN0IGJlIHVwIHRvIHRoZSBPQXV0aA0KPiBzZXJ2ZXIuIFRoZSBt b3N0IHRoYXQgSSB0aGluayB0aGUgY2xpZW50IGNhbiBkbyBpcyBzZW5kIGEgbGlzdCBvZiB3aGF0 IGl0DQo+IHN1cHBvcnRzLCB3aGljaCB3aWxsIGFsbG93IHRoZSBzZXJ2ZXIgdG8gc2VsZWN0IHRo ZSBiZXN0IG9mIHRoZSBidW5jaCAob3IgcmVqZWN0DQo+IGlmIG5vbmUgYXJlIGdvb2QgZW5vdWdo KS4NCg0KSSBhbSB0aGlua2luZyBvdGhlciB3YXkgYXJvdW5kLiBUVVJOIHNlcnZlciBzZW5kcyBs aXN0cyBvZiBITUFDIGFsZ29yaXRobXMgaXQgc3VwcG9ydHMsIGNsaWVudCBwaWNrcyB0aGUgYWxn b3JpdGhtIGl0IHdvdWxkIGxpa2UgdG8gdXNlIGFuZCBjb252ZXlzIGl0IHRvIHRoZSBhdXRob3Jp emF0aW9uIHNlcnZlci4gT0F1dGggaGFzIGFscmVhZHkgZGVmaW5lZCAnYWxnJyBwYXJhbWV0ZXIg Zm9yIHRoZSBjbGllbnQgdG8gc2lnbmFsIHRoZSBhbGdvcml0aG0gdG8gdGhlIGF1dGhvcml6YXRp b24gc2VydmVyLiANCg0KLVRpcnUNCg0KPiANCj4gSSBoYXZlbid0IHJlYWQgdGhlIHJlZmVyZW5j ZWQgZHJhZnQgb3IgeW91ciBwcm9wb3NlZCBjaGFuZ2VzIHNvIGl0IG1heSBiZQ0KPiB0aGF0IHlv dSd2ZSBhbHJlYWR5IGRlYWx0IHdpdGggdGhpcyBwYXJ0IG9mIHRoZSBwcm9ibGVtLg0KPiANCj4g LS1CcmFuZG9uDQo+IA0KPiBPbiAwOC8yNS8yMDE0IDEyOjUwIFBNLCBUaXJ1bWFsZXN3YXIgUmVk ZHkgKHRpcmVkZHkpIHdyb3RlOg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFttYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWku Y29tXQ0KPiA+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAyNSwgMjAxNCA4OjA2IFBNDQo+ID4+IFRv OiBPbGVnIE1vc2thbGVua287IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCj4gPj4gQ2M6 IHRyYW1AaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0t dHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiA+Pg0KPiA+PiBJIGFncmVlIHRoYXQgdGhlIDUz ODkgaGFzaCBhZ2lsaXR5IHBsYW4gc2VlbXMgcHJvYmxlbWF0aWMgYW5kIHNob3VsZA0KPiA+PiBi ZSByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBtb3JlIHN1aXRhYmxlIHRvIHRoZSBzdGF0ZWQgcHVy cG9zZS4gVGhhdA0KPiA+PiBzaG91bGQgcHJvYmFibHkgYmUgcGFydCBvZiB0aGUgc3R1bi1iaXMg ZWZmb3J0LCBvciBhdCBoYXBwZW4NCj4gPj4gY29uY3VycmVudGx5IHNvIHRoYXQgc3R1bi1iaXMg Y2FuIHJlZmVyZW5jZSB0aGUgcmVsZXZhbnQgZG9jdW1lbnQuDQo+ID4+IENvbXBsZXRpb24gb2Yg dGhpcyBlZmZvcnQgbWlnaHQgYmUgYSByZXF1aXJlbWVudCBmb3IgcHVibGlzaGluZyB0aGUNCj4g Pj4gM3JkIHBhcnR5IGF1dGggZHJhZnQsIGJlY2F1c2Ugd2UgZG9uJ3Qgd2FudCB0byBlbmQgdXAg cHVibGlzaGluZyBhDQo+ID4+IGRyYWZ0IHRoYXQgcmVxdWlyZXMgYW4gaW1tZWRpYXRlIHVwZGF0 ZSBpbiBvcmRlciB0byBzYXRpc2Z5IGEgbm90LXlldC0NCj4gd3JpdHRlbiBoYXNoIGFnaWxpdHkg cmVxdWlyZW1lbnQuDQo+ID4+DQo+ID4+IFRoZSBhcmVhIHRoYXQgSSB0aGluayBpcyBtb3N0IGxp a2VseSB0byBiZSBjaGFsbGVuZ2luZyB3aXRoIHRoZQ0KPiA+PiBjdXJyZW50IDNyZCBwYXJ0eSBh dXRoIGRyYWZ0IGlzIGFsZ29yaXRobSBpZGVudGlmaWNhdGlvbi4gSXQgd2lsbCBiZQ0KPiA+PiBu ZWNlc3NhcnkgYXQgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIGZvciB0aGUgVFVSTiBzZXJ2ZXIg dG8gc2VsZWN0DQo+ID4+IGZyb20gYW1vbmcgbXVsdGlwbGUgc3VwcG9ydGVkIGF1dGggYWxnb3Jp dGhtcywgYnV0IHRoZXJlIGlzIG5vDQo+ID4+IG9idmlvdXMgd2F5IGF0IHRoZSBtb21lbnQgZm9y IHRoZSBhdXRoIGFsZ29yaXRobSB0byBiZSBjb21tdW5pY2F0ZWQNCj4gPj4gZnJvbSB0aGUgYXV0 aCBzZXJ2ZXIgdG8gZWl0aGVyIHRoZSBjbGllbnQgb3IgdGhlIFRVUk4gc2VydmVyLiBUaGUNCj4g Pj4gb25seSB2YWx1ZSB0aGF0IGNvdWxkIGN1cnJlbnRseSBiZSB1c2VkIHRvIGd1ZXNzIHRoZSBh dXRoIGFsZ29yaXRobQ0KPiA+PiBpcyB0aGUga2V5X2xlbmd0aCBpbiB0aGUgdG9rZW4sIGJ1dCB1 c2luZyBrZXlfbGVuZ3RoIGFzIGFuIGFsZ29yaXRobQ0KPiA+PiBpZGVudGlmaWVyIHNlZW1zIHJp c2t5LCBldmVuIGlmIGl0IHdvdWxkIHdvcmsgd2l0aCB0aGUgbW9zdCBsaWtlbHkNCj4gY2FuZGlk YXRlcyB0b2RheS4NCj4gPg0KPiA+IEkgaGF2ZSB1cGRhdGVkIHRoZSBkcmFmdCB0byBhZGRyZXNz IHRoZSBwcm9ibGVtIGluIHRoZSBmb2xsb3dpbmcgd2F5Og0KPiA+IFdoZW4gU1RVTiBzdXBwb3J0 cyBITUFDIGFsZ29yaXRobXMgb3RoZXIgdGhhbiBITUFDLVNIQS0xIHRoZW4gY2xpZW50DQo+ID4g d2lsbCBjb252ZXkgdGhlIGFsZ29yaXRobSBuZWdvdGlhdGVkIHdpdGggdGhlIFRVUk4gc2VydmVy IHRvICB0aGUNCj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gdGhlIHZhbHVlIG9mICdhbGcnIHBh cmFtZXRlciBkZWZpbmVkIGluIFtJLUQuaWV0Zi1vYXV0aC0NCj4gcG9wLWtleS1kaXN0cmlidXRp b25dLiAgQXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGV0ZXJtaW5lcyBsZW5ndGggb2YgdGhlDQo+IG1h Y19rZXkgYmFzZWQgb24gdGhlIEhNQUMgYWxnb3JpdGhtIGNvbnZleWVkIGJ5IHRoZSBjbGllbnQu DQo+ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4+DQo+ID4+IC0tQnJhbmRvbg0KPiA+Pg0KPiA+PiBP biAwOC8yMy8yMDE0IDAyOjQ3IEFNLCBPbGVnIE1vc2thbGVua28gd3JvdGU6DQo+ID4+PiBBbm90 aGVyIHByb2JsZW0gaXMgdGhhdCBJIGFtIG5vdCBzdXJlIHRoYXQgdGhlIGhhc2ggYWdpbGl0eSBw bGFuDQo+ID4+PiBpZGVhIGRlc2NyaWJlZCBpbiBSRkM1Mzg5IGlzIHN0aWxsIHZhbGlkLiBJIGFt IGFmcmFpZCB0aGF0IGl0IGlzDQo+ID4+PiB1bm5lY2Vzc2FyeSBjb21wbGljYXRlZCBhbmQgb3V0 ZGF0ZWQsIHRha2luZyBpbnRvIGFjY291bnQgdGhlDQo+ID4+PiBjdXJyZW50IGxldmVsIG9mDQo+ ID4+PiBTSEEtMjU2IGFkb3B0aW9uLiBUaGUgcGxhbiB3YXMgZGVzaWduZWQgdG8gc3VwcG9ydCwg InRyYW5zcGFyZW50bHkiLA0KPiA+Pj4gdGhlIG9sZCBUVVJOIHNlcnZlcnMuIEJ1dCBpbiB0aGVz ZSBzcGVjcywgd2UgZG8gbm90IG5lY2Vzc2FyeSBoYXZlDQo+ID4+PiB0byBzdXBwb3J0IHRoZSAi b2xkIiBzZXJ2ZXJzIHdpdGggSE1BQy1TSEEtMSBvbmx5IGltcGxlbWVudGF0aW9uczsNCj4gPj4+ IGFzIHdlIGFyZSB3cml0aW5nIGEgbmV3IG9BdXRoIHByb2NlZHVyZSwgdGhlcmUgd2lsbCBiZSBv bmx5ICJuZXciDQo+ID4+PiBzZXJ2ZXJzIHN1cHBvcnRpbmcgdGhlIGRyYWZ0IHNwZWNzLCBhbnl3 YXkuIFRoZSAib2xkIiBzZXJ2ZXJzIHdpbGwNCj4gPj4+IG5vdCBiZSBhYmxlIHRvIHVzZSB0aGUg b0F1dGggc3BlY3MuIFNPIHdlIGNhbiBkZXNpZ24gYSBjbGVhbmVyDQo+ID4+PiBzaW1wbGVyIGhh c2ggYWdpbGl0eSBwcm9jZWR1cmUuDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEJyYW5kb24gV2lsbGlh bXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4gPj4gUHJv ZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiANCj4gLS0NCj4g QnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVy Z2luZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo= From nobody Mon Aug 25 10:50:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689021A0151 for ; Mon, 25 Aug 2014 10:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iY0tsexaW2ra for ; Mon, 25 Aug 2014 10:50:01 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 339F81A0181 for ; Mon, 25 Aug 2014 10:49:58 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A510D475C7; Mon, 25 Aug 2014 17:49:57 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8F43C475C5; Mon, 25 Aug 2014 17:49:57 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 4ACF42063; Mon, 25 Aug 2014 17:49:57 +0000 (GMT) Message-ID: <53FB7745.50602@akamai.com> Date: Mon, 25 Aug 2014 13:49:57 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A28319AAD@xmb-rcd-x10.cisco.com> <53FB49B9.2010202@akamai.com> <913383AAA69FF945B8F946018B75898A2831AEC3@xmb-rcd-x10.cisco.com> <53FB6DF5.2090702@akamai.com> <913383AAA69FF945B8F946018B75898A2831AF6D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831AF6D@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HJuMJ5HQyyM3-Ry1Fyd9VQcm-9Q Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 17:50:04 -0000 Why should it be necessary for the TURN server to send a list? Can't the list of supported auth algorithms be agreed upon between the relay and oauth servers out-of-band like the other security parameters? And how is this better than a more typical model wherein the client advertises its capabilities and the server enforces its policy? --Brandon On 08/25/2014 01:27 PM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Monday, August 25, 2014 10:40 PM >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >> Cc: tram@ietf.org >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> I don't think that the client will be (or can safely be allow to be) responsible >> for selecting the algorithm. Somehow, this decision must be up to the OAuth >> server. The most that I think the client can do is send a list of what it >> supports, which will allow the server to select the best of the bunch (or reject >> if none are good enough). > > I am thinking other way around. TURN server sends lists of HMAC algorithms it supports, client picks the algorithm it would like to use and conveys it to the authorization server. OAuth has already defined 'alg' parameter for the client to signal the algorithm to the authorization server. > > -Tiru > >> >> I haven't read the referenced draft or your proposed changes so it may be >> that you've already dealt with this part of the problem. >> >> --Brandon >> >> On 08/25/2014 12:50 PM, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>> Sent: Monday, August 25, 2014 8:06 PM >>>> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy) >>>> Cc: tram@ietf.org >>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>> >>>> I agree that the 5389 hash agility plan seems problematic and should >>>> be replaced with something more suitable to the stated purpose. That >>>> should probably be part of the stun-bis effort, or at happen >>>> concurrently so that stun-bis can reference the relevant document. >>>> Completion of this effort might be a requirement for publishing the >>>> 3rd party auth draft, because we don't want to end up publishing a >>>> draft that requires an immediate update in order to satisfy a not-yet- >> written hash agility requirement. >>>> >>>> The area that I think is most likely to be challenging with the >>>> current 3rd party auth draft is algorithm identification. It will be >>>> necessary at some point in the future for the TURN server to select >>>> from among multiple supported auth algorithms, but there is no >>>> obvious way at the moment for the auth algorithm to be communicated >>>> from the auth server to either the client or the TURN server. The >>>> only value that could currently be used to guess the auth algorithm >>>> is the key_length in the token, but using key_length as an algorithm >>>> identifier seems risky, even if it would work with the most likely >> candidates today. >>> >>> I have updated the draft to address the problem in the following way: >>> When STUN supports HMAC algorithms other than HMAC-SHA-1 then client >>> will convey the algorithm negotiated with the TURN server to the >> authorization server in the value of 'alg' parameter defined in [I-D.ietf-oauth- >> pop-key-distribution]. Authorization server determines length of the >> mac_key based on the HMAC algorithm conveyed by the client. >>> >>> -Tiru >>> >>>> >>>> --Brandon >>>> >>>> On 08/23/2014 02:47 AM, Oleg Moskalenko wrote: >>>>> Another problem is that I am not sure that the hash agility plan >>>>> idea described in RFC5389 is still valid. I am afraid that it is >>>>> unnecessary complicated and outdated, taking into account the >>>>> current level of >>>>> SHA-256 adoption. The plan was designed to support, "transparently", >>>>> the old TURN servers. But in these specs, we do not necessary have >>>>> to support the "old" servers with HMAC-SHA-1 only implementations; >>>>> as we are writing a new oAuth procedure, there will be only "new" >>>>> servers supporting the draft specs, anyway. The "old" servers will >>>>> not be able to use the oAuth specs. SO we can design a cleaner >>>>> simpler hash agility procedure. >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>> Products Engineering; Akamai Technologies Inc. >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Mon Aug 25 22:32:41 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C51A06F8 for ; Mon, 25 Aug 2014 22:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Oot7XBHNVbDM for ; Mon, 25 Aug 2014 22:32:37 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF38F1A06F6 for ; Mon, 25 Aug 2014 22:32:36 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id ho1so3528890wib.4 for ; Mon, 25 Aug 2014 22:32:35 -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:content-type; bh=BeknPifvKB6ICstxAKAtiC3E8oMPFNC0+9hHBuc3UVM=; b=WGuFklDZCIOjnflitFLfxgIpI8xxFQ2wP6m8W2FAlnloL0a+ELlkLl+TQ/rx7Qy5v4 Khffo/mky1FqsDEcCmXGW0DaAQ2m8sEjZEo1CMg31fyxXYk0XmvXcKiqpRQS+7JyDFZv VF7rdc5wTNeogszQw++FtM2uVmaXeCMo2ry61oIf5tjKY3jDxh2whtn02WsLirgIduC8 NQYnO7bQmKUx/LokpWZIGF68A2sWZZReuMOYU7UW3/chwFyCfRTnTxwt9WsxB5mzEXdS U1Cd2cdFgHnNaRPADFDS7BG5ThmdVqI8H1XbKkWBB7+wwjjCA2lDXUSD779UPpO5PdKM oOsw== MIME-Version: 1.0 X-Received: by 10.180.80.165 with SMTP id s5mr19307195wix.61.1409031155668; Mon, 25 Aug 2014 22:32:35 -0700 (PDT) Received: by 10.194.38.232 with HTTP; Mon, 25 Aug 2014 22:32:35 -0700 (PDT) In-Reply-To: References: <20140825125641.32342.40970.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 22:32:35 -0700 Message-ID: From: Oleg Moskalenko To: "Prashanth Patil (praspati)" Content-Type: multipart/alternative; boundary=14dae9cc93ac82ddf9050181a191 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3TO_9Mw0qvJB6bFCuUWXUkp-Btw Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-tram-turn-mobility-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 05:32:39 -0000 --14dae9cc93ac82ddf9050181a191 Content-Type: text/plain; charset=UTF-8 I agree with the updates. The current rfc5766-turn-server and coturn servers are missing only one thing from the new specs: the added last paragraph in the section 3.2.2, about the REFRESH re-transmission. It will be updated in the next versions. Oleg On Mon, Aug 25, 2014 at 9:43 AM, Prashanth Patil (praspati) < praspati@cisco.com> wrote: > All, > We've submitted a revision of the 'Mobility with TURN' draft. The update > addresses comments raised by Brandon during IETF-90 regarding TURN client > and server behavior when a STUN refresh message carrying MOBILITY-TICKET > attribute is lost. > > Comments welcome. > > Thanks, > Prashanth > > > On 8/25/14 6:26 PM, "internet-drafts@ietf.org" > wrote: > > > > >A new version of I-D, draft-wing-tram-turn-mobility-01.txt > >has been successfully submitted by Prashanth Patil and posted to the > >IETF repository. > > > >Name: draft-wing-tram-turn-mobility > >Revision: 01 > >Title: Mobility with TURN > >Document date: 2014-08-25 > >Group: Individual Submission > >Pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-wing-tram-turn-mobility-01.txt > >Status: > >https://datatracker.ietf.org/doc/draft-wing-tram-turn-mobility/ > >Htmlized: > >http://tools.ietf.org/html/draft-wing-tram-turn-mobility-01 > >Diff: > >http://www.ietf.org/rfcdiff?url2=draft-wing-tram-turn-mobility-01 > > > >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 TURN. > > This is achieved by allowing a client to retain an allocation on the > > TURN server when the IP address of the client changes. > > > > > > > > > > > >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. > > > >The IETF Secretariat > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --14dae9cc93ac82ddf9050181a191 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with the updates.=C2=A0

The cur= rent rfc5766-turn-server and coturn servers are missing only one thing from= the new specs: the added last paragraph in the section 3.2.2, about the RE= FRESH re-transmission. It will be updated in the next versions.

Oleg



On Mon, Aug 25, 2014 at 9:43 AM, Pras= hanth Patil (praspati) <praspati@cisco.com> wrote:
All,
We've submitted a revision of the 'Mobility with TURN' draft. T= he update
addresses comments raised by Brandon during IETF-90 regarding TURN client and server behavior when a STUN refresh message carrying MOBILITY-TICKET attribute is lost.

Comments welcome.

Thanks,
Prashanth


On 8/25/14 6:26 PM, "inter= net-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-wing-tram-turn-mobility-01.txt
>has been successfully submitted by Prashanth Patil and posted to the >IETF repository.
>
>Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-wing-tram-turn-mobility >Revision:=C2=A0 =C2=A0 =C2=A0 01
>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mobility with TURN
>Document date: 2014-08-25
>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010
>URL:
>http://www.ietf.org/internet-drafts/draft-w= ing-tram-turn-mobility-01.txt
>Status:
>https://datatracker.ietf.org/doc/draft-wing-tram-tur= n-mobility/
>Htmlized:
>http://tools.ietf.org/html/draft-wing-tram-turn-mobility= -01
>Diff:
>http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-tr= am-turn-mobility-01
>
>Abstract:
>=C2=A0 =C2=A0It is desirable to minimize traffic disruption caused by c= hanging IP
>=C2=A0 =C2=A0address during a mobility event.=C2=A0 One mechanism to mi= nimize
>=C2=A0 =C2=A0disruption is to expose a shorter network path to the mobi= lity event
>=C2=A0 =C2=A0so only the local network elements are aware of the change= d IP
>=C2=A0 =C2=A0address but the remote peer is unaware of the changed IP a= ddress.
>
>=C2=A0 =C2=A0This draft provides such an IP address mobility solution u= sing TURN.
>=C2=A0 =C2=A0This is achieved by allowing a client to retain an allocat= ion on the
>=C2=A0 =C2=A0TURN server when the IP address of the client changes.
>
>
>
>
>
>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.
>
>The IETF Secretariat
>

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

--14dae9cc93ac82ddf9050181a191-- From nobody Mon Aug 25 23:19:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B33C1A02FB for ; Mon, 25 Aug 2014 23:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT9fjif7fKDi for ; Mon, 25 Aug 2014 23:19:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9191A0058 for ; Mon, 25 Aug 2014 23:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7662; q=dns/txt; s=iport; t=1409033972; x=1410243572; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=0JVtXLEH5/ZPwy1f+foS5Inul3cudxSd3Uq99BtOTx8=; b=JQTf9qptdLWI2O81L31yUq0mH6lEGbC1gWfWbQVZF7SlAoqUo/tKBs/N GlALPZu8bxyUk5cSlnM1UJQKRTBmW2WHkgFyzpXy9+2iNytRMy/uxbR5m bRpqV4FaL3SIX/f3ZuBguYkaqljKePO0vNrvx0R98aSfo3EGQZ8eij+Wt c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPAl/FOtJA2E/2dsb2JhbABagw2BKgSCeNEpARl8FneEAwEBAQQjEUUMBgEIEQQBAQECAgYLEgMCBDAUAQgJAQQBDQUIiDqobZUoF4EsiFOFHBYbDQSCbzaBHQWRJoZjmUyBZhyBXGyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,402,1406592000"; d="scan'208";a="350263578" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2014 06:19:31 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7Q6JUlr014432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 06:19:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 01:19:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/A9a2Hx53Tz1jLRy2hjIRkf7ki6w== Date: Tue, 26 Aug 2014 06:19:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831B66F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Wp42__YLKZXWXHmCJupygmSC5F0 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 06:19:33 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBNb25kYXksIEF1Z3Vz dCAyNSwgMjAxNCAxMToyMCBQTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsg T2xlZyBNb3NrYWxlbmtvDQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdHJh bV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCj4gDQo+IFdoeSBz aG91bGQgaXQgYmUgbmVjZXNzYXJ5IGZvciB0aGUgVFVSTiBzZXJ2ZXIgdG8gc2VuZCBhIGxpc3Q/ IENhbid0IHRoZSBsaXN0DQo+IG9mIHN1cHBvcnRlZCBhdXRoIGFsZ29yaXRobXMgYmUgYWdyZWVk IHVwb24gYmV0d2VlbiB0aGUgcmVsYXkgYW5kIG9hdXRoDQo+IHNlcnZlcnMgb3V0LW9mLWJhbmQg bGlrZSB0aGUgb3RoZXIgc2VjdXJpdHkgcGFyYW1ldGVycz8gQW5kIGhvdyBpcyB0aGlzDQo+IGJl dHRlciB0aGFuIGEgbW9yZSB0eXBpY2FsIG1vZGVsIHdoZXJlaW4gdGhlIGNsaWVudCBhZHZlcnRp c2VzIGl0cyBjYXBhYmlsaXRpZXMNCj4gYW5kIHRoZSBzZXJ2ZXIgZW5mb3JjZXMgaXRzIHBvbGlj eT8NCg0KQm90aCBtb2RlbHMgd2lsbCB3b3JrIGFuZCBldmVuIGluIHRoZSBhYm92ZSBjYXNlIGNs aWVudCB3aWxsIGhhdmUgdG8gc2lnbmFsIHRoZSBhbGdvcml0aG0gdG8gdGhlIGF1dGhvcml6YXRp b24gc2VydmVyIHNvIGFzIHRvIGdldCBrZXkgd2l0aCBjb3JyZWN0IGxlbmd0aC4gSW4gdGhlIGJl bG93IHByb3Bvc2FsLCB0aGVyZSBpcyBubyBuZWVkIGZvciBsaXN0IG9mIHN1cHBvcnRlZCBhdXRo ZW50aWNhdGlvbiBhbGdvcml0aG1zIHRvIGJlIGFncmVlZCB1cG9uIGJldHdlZW4gdGhlIFJTIGFu ZCBBUyBzZXJ2ZXJzLiANCg0KLVRpcnUNCg0KPiANCj4gLS1CcmFuZG9uDQo+IA0KPiBPbiAwOC8y NS8yMDE0IDAxOjI3IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0KPiA+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1z IFttYWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiA+PiBTZW50OiBNb25kYXks IEF1Z3VzdCAyNSwgMjAxNCAxMDo0MCBQTQ0KPiA+PiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KTsgT2xlZyBNb3NrYWxlbmtvDQo+ID4+IENjOiB0cmFtQGlldGYub3JnDQo+ID4+IFN1 YmplY3Q6IFJlOiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHot MDMNCj4gPj4NCj4gPj4gSSBkb24ndCB0aGluayB0aGF0IHRoZSBjbGllbnQgd2lsbCBiZSAob3Ig Y2FuIHNhZmVseSBiZSBhbGxvdyB0byBiZSkNCj4gPj4gcmVzcG9uc2libGUgZm9yIHNlbGVjdGlu ZyB0aGUgYWxnb3JpdGhtLiBTb21laG93LCB0aGlzIGRlY2lzaW9uIG11c3QNCj4gPj4gYmUgdXAg dG8gdGhlIE9BdXRoIHNlcnZlci4gVGhlIG1vc3QgdGhhdCBJIHRoaW5rIHRoZSBjbGllbnQgY2Fu IGRvIGlzDQo+ID4+IHNlbmQgYSBsaXN0IG9mIHdoYXQgaXQgc3VwcG9ydHMsIHdoaWNoIHdpbGwg YWxsb3cgdGhlIHNlcnZlciB0bw0KPiA+PiBzZWxlY3QgdGhlIGJlc3Qgb2YgdGhlIGJ1bmNoIChv ciByZWplY3QgaWYgbm9uZSBhcmUgZ29vZCBlbm91Z2gpLg0KPiA+DQo+ID4gSSBhbSB0aGlua2lu ZyBvdGhlciB3YXkgYXJvdW5kLiBUVVJOIHNlcnZlciBzZW5kcyBsaXN0cyBvZiBITUFDDQo+IGFs Z29yaXRobXMgaXQgc3VwcG9ydHMsIGNsaWVudCBwaWNrcyB0aGUgYWxnb3JpdGhtIGl0IHdvdWxk IGxpa2UgdG8gdXNlIGFuZA0KPiBjb252ZXlzIGl0IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4gT0F1dGggaGFzIGFscmVhZHkgZGVmaW5lZCAnYWxnJw0KPiBwYXJhbWV0ZXIgZm9yIHRoZSBj bGllbnQgdG8gc2lnbmFsIHRoZSBhbGdvcml0aG0gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy Lg0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+Pg0KPiA+PiBJIGhhdmVuJ3QgcmVhZCB0aGUgcmVm ZXJlbmNlZCBkcmFmdCBvciB5b3VyIHByb3Bvc2VkIGNoYW5nZXMgc28gaXQNCj4gPj4gbWF5IGJl IHRoYXQgeW91J3ZlIGFscmVhZHkgZGVhbHQgd2l0aCB0aGlzIHBhcnQgb2YgdGhlIHByb2JsZW0u DQo+ID4+DQo+ID4+IC0tQnJhbmRvbg0KPiA+Pg0KPiA+PiBPbiAwOC8yNS8yMDE0IDEyOjUwIFBN LCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0KPiA+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogQnJhbmRvbiBXaWxsaWFtcyBbbWFpbHRvOmJy YW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbV0NCj4gPj4+PiBTZW50OiBNb25kYXksIEF1Z3VzdCAy NSwgMjAxNCA4OjA2IFBNDQo+ID4+Pj4gVG86IE9sZWcgTW9za2FsZW5rbzsgVGlydW1hbGVzd2Fy IFJlZGR5ICh0aXJlZGR5KQ0KPiA+Pj4+IENjOiB0cmFtQGlldGYub3JnDQo+ID4+Pj4gU3ViamVj dDogUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0K PiA+Pj4+DQo+ID4+Pj4gSSBhZ3JlZSB0aGF0IHRoZSA1Mzg5IGhhc2ggYWdpbGl0eSBwbGFuIHNl ZW1zIHByb2JsZW1hdGljIGFuZA0KPiA+Pj4+IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNvbWV0 aGluZyBtb3JlIHN1aXRhYmxlIHRvIHRoZSBzdGF0ZWQNCj4gPj4+PiBwdXJwb3NlLiBUaGF0IHNo b3VsZCBwcm9iYWJseSBiZSBwYXJ0IG9mIHRoZSBzdHVuLWJpcyBlZmZvcnQsIG9yIGF0DQo+ID4+ Pj4gaGFwcGVuIGNvbmN1cnJlbnRseSBzbyB0aGF0IHN0dW4tYmlzIGNhbiByZWZlcmVuY2UgdGhl IHJlbGV2YW50DQo+IGRvY3VtZW50Lg0KPiA+Pj4+IENvbXBsZXRpb24gb2YgdGhpcyBlZmZvcnQg bWlnaHQgYmUgYSByZXF1aXJlbWVudCBmb3IgcHVibGlzaGluZyB0aGUNCj4gPj4+PiAzcmQgcGFy dHkgYXV0aCBkcmFmdCwgYmVjYXVzZSB3ZSBkb24ndCB3YW50IHRvIGVuZCB1cCBwdWJsaXNoaW5n IGENCj4gPj4+PiBkcmFmdCB0aGF0IHJlcXVpcmVzIGFuIGltbWVkaWF0ZSB1cGRhdGUgaW4gb3Jk ZXIgdG8gc2F0aXNmeSBhDQo+ID4+Pj4gbm90LXlldC0NCj4gPj4gd3JpdHRlbiBoYXNoIGFnaWxp dHkgcmVxdWlyZW1lbnQuDQo+ID4+Pj4NCj4gPj4+PiBUaGUgYXJlYSB0aGF0IEkgdGhpbmsgaXMg bW9zdCBsaWtlbHkgdG8gYmUgY2hhbGxlbmdpbmcgd2l0aCB0aGUNCj4gPj4+PiBjdXJyZW50IDNy ZCBwYXJ0eSBhdXRoIGRyYWZ0IGlzIGFsZ29yaXRobSBpZGVudGlmaWNhdGlvbi4gSXQgd2lsbA0K PiA+Pj4+IGJlIG5lY2Vzc2FyeSBhdCBzb21lIHBvaW50IGluIHRoZSBmdXR1cmUgZm9yIHRoZSBU VVJOIHNlcnZlciB0bw0KPiA+Pj4+IHNlbGVjdCBmcm9tIGFtb25nIG11bHRpcGxlIHN1cHBvcnRl ZCBhdXRoIGFsZ29yaXRobXMsIGJ1dCB0aGVyZSBpcw0KPiA+Pj4+IG5vIG9idmlvdXMgd2F5IGF0 IHRoZSBtb21lbnQgZm9yIHRoZSBhdXRoIGFsZ29yaXRobSB0byBiZQ0KPiA+Pj4+IGNvbW11bmlj YXRlZCBmcm9tIHRoZSBhdXRoIHNlcnZlciB0byBlaXRoZXIgdGhlIGNsaWVudCBvciB0aGUgVFVS Tg0KPiA+Pj4+IHNlcnZlci4gVGhlIG9ubHkgdmFsdWUgdGhhdCBjb3VsZCBjdXJyZW50bHkgYmUg dXNlZCB0byBndWVzcyB0aGUNCj4gPj4+PiBhdXRoIGFsZ29yaXRobSBpcyB0aGUga2V5X2xlbmd0 aCBpbiB0aGUgdG9rZW4sIGJ1dCB1c2luZyBrZXlfbGVuZ3RoDQo+ID4+Pj4gYXMgYW4gYWxnb3Jp dGhtIGlkZW50aWZpZXIgc2VlbXMgcmlza3ksIGV2ZW4gaWYgaXQgd291bGQgd29yayB3aXRoDQo+ ID4+Pj4gdGhlIG1vc3QgbGlrZWx5DQo+ID4+IGNhbmRpZGF0ZXMgdG9kYXkuDQo+ID4+Pg0KPiA+ Pj4gSSBoYXZlIHVwZGF0ZWQgdGhlIGRyYWZ0IHRvIGFkZHJlc3MgdGhlIHByb2JsZW0gaW4gdGhl IGZvbGxvd2luZyB3YXk6DQo+ID4+PiBXaGVuIFNUVU4gc3VwcG9ydHMgSE1BQyBhbGdvcml0aG1z IG90aGVyIHRoYW4gSE1BQy1TSEEtMSB0aGVuDQo+IGNsaWVudA0KPiA+Pj4gd2lsbCBjb252ZXkg dGhlIGFsZ29yaXRobSBuZWdvdGlhdGVkIHdpdGggdGhlIFRVUk4gc2VydmVyIHRvICB0aGUNCj4g Pj4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaW4gdGhlIHZhbHVlIG9mICdhbGcnIHBhcmFtZXRlciBk ZWZpbmVkIGluDQo+ID4+IFtJLUQuaWV0Zi1vYXV0aC0gcG9wLWtleS1kaXN0cmlidXRpb25dLiAg QXV0aG9yaXphdGlvbiBzZXJ2ZXINCj4gPj4gZGV0ZXJtaW5lcyBsZW5ndGggb2YgdGhlIG1hY19r ZXkgYmFzZWQgb24gdGhlIEhNQUMgYWxnb3JpdGhtDQo+IGNvbnZleWVkIGJ5IHRoZSBjbGllbnQu DQo+ID4+Pg0KPiA+Pj4gLVRpcnUNCj4gPj4+DQo+ID4+Pj4NCj4gPj4+PiAtLUJyYW5kb24NCj4g Pj4+Pg0KPiA+Pj4+IE9uIDA4LzIzLzIwMTQgMDI6NDcgQU0sIE9sZWcgTW9za2FsZW5rbyB3cm90 ZToNCj4gPj4+Pj4gQW5vdGhlciBwcm9ibGVtIGlzIHRoYXQgSSBhbSBub3Qgc3VyZSB0aGF0IHRo ZSBoYXNoIGFnaWxpdHkgcGxhbg0KPiA+Pj4+PiBpZGVhIGRlc2NyaWJlZCBpbiBSRkM1Mzg5IGlz IHN0aWxsIHZhbGlkLiBJIGFtIGFmcmFpZCB0aGF0IGl0IGlzDQo+ID4+Pj4+IHVubmVjZXNzYXJ5 IGNvbXBsaWNhdGVkIGFuZCBvdXRkYXRlZCwgdGFraW5nIGludG8gYWNjb3VudCB0aGUNCj4gPj4+ Pj4gY3VycmVudCBsZXZlbCBvZg0KPiA+Pj4+PiBTSEEtMjU2IGFkb3B0aW9uLiBUaGUgcGxhbiB3 YXMgZGVzaWduZWQgdG8gc3VwcG9ydCwNCj4gPj4+Pj4gInRyYW5zcGFyZW50bHkiLCB0aGUgb2xk IFRVUk4gc2VydmVycy4gQnV0IGluIHRoZXNlIHNwZWNzLCB3ZSBkbw0KPiA+Pj4+PiBub3QgbmVj ZXNzYXJ5IGhhdmUgdG8gc3VwcG9ydCB0aGUgIm9sZCIgc2VydmVycyB3aXRoIEhNQUMtU0hBLTEN Cj4gPj4+Pj4gb25seSBpbXBsZW1lbnRhdGlvbnM7IGFzIHdlIGFyZSB3cml0aW5nIGEgbmV3IG9B dXRoIHByb2NlZHVyZSwgdGhlcmUNCj4gd2lsbCBiZSBvbmx5ICJuZXciDQo+ID4+Pj4+IHNlcnZl cnMgc3VwcG9ydGluZyB0aGUgZHJhZnQgc3BlY3MsIGFueXdheS4gVGhlICJvbGQiIHNlcnZlcnMg d2lsbA0KPiA+Pj4+PiBub3QgYmUgYWJsZSB0byB1c2UgdGhlIG9BdXRoIHNwZWNzLiBTTyB3ZSBj YW4gZGVzaWduIGEgY2xlYW5lcg0KPiA+Pj4+PiBzaW1wbGVyIGhhc2ggYWdpbGl0eSBwcm9jZWR1 cmUuDQo+ID4+Pj4NCj4gPj4+PiAtLQ0KPiA+Pj4+IEJyYW5kb24gV2lsbGlhbXM7IFNlbmlvciBQ cmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcNCj4gPj4+PiBQcm9kdWN0cyBFbmdp bmVlcmluZzsgQWthbWFpIFRlY2hub2xvZ2llcyBJbmMuDQo+ID4+DQo+ID4+IC0tDQo+ID4+IEJy YW5kb24gV2lsbGlhbXM7IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdp bmcNCj4gPj4gUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0K PiANCj4gLS0NCj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5jaXBhbCBTb2Z0d2FyZSBF bmdpbmVlciBFbWVyZ2luZyBQcm9kdWN0cw0KPiBFbmdpbmVlcmluZzsgQWthbWFpIFRlY2hub2xv Z2llcyBJbmMuDQo= From nobody Tue Aug 26 11:30:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8441A0191 for ; Tue, 26 Aug 2014 11:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yoD1YprBSZe for ; Tue, 26 Aug 2014 11:30:11 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD701A0155 for ; Tue, 26 Aug 2014 11:30:10 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 20640284DE; Tue, 26 Aug 2014 18:30:10 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 0CCBC284C4; Tue, 26 Aug 2014 18:30:10 +0000 (GMT) Received: from [172.28.115.172] (bowill.kendall.corp.akamai.com [172.28.115.172]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 0039B2039; Tue, 26 Aug 2014 18:30:09 +0000 (GMT) Message-ID: <53FCD231.9080201@akamai.com> Date: Tue, 26 Aug 2014 14:30:09 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Tirumaleswar Reddy (tireddy)" , Oleg Moskalenko References: <913383AAA69FF945B8F946018B75898A2831B66F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A2831B66F@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BOp8x-hCmJ3bKmtc-FdXqMj5ezQ Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 18:30:18 -0000 I don't think that it's reasonable for the client to select a single auth algorithm from a list of those supported by the relay server, because there is a risk that it will select one that doesn't meet the policy requirements being enforced by the oauth server. In addition, I think the oauth administrator has to know the algorithms supported by the relay server in order to configure a reasonable policy. I don't think the policy configuration requirement can be met with in-band communication of the supported algorithms. I agree that the client and the oauth server have to agree on the algorithm in order for the oauth server to send an appropriately sized key. I'm suggesting that the algorithm should be selected by the oauth server from among the union of the set supported by the client and the algorithm supported by the relay server. I'm also suggesting that the client should not be allowed to declare what the union set is, which is a shortcoming of delivering the information in-band. All of the above having been said, I think that we may be getting ahead of the discussion. Is there general agreement that we need to come up with a new hash agility approach for STUN? And if so, has someone actually taken that on? What we come up with on hash agility for 3rd party auth may depend upon how hash agility is resolved for STUN in general. --Brandon On 08/26/2014 02:19 AM, Tirumaleswar Reddy (tireddy) wrote: >> -----Original Message----- >> From: Brandon Williams [mailto:brandon.williams@akamai.com] >> Sent: Monday, August 25, 2014 11:20 PM >> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >> Cc: tram@ietf.org >> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >> >> Why should it be necessary for the TURN server to send a list? Can't the list >> of supported auth algorithms be agreed upon between the relay and oauth >> servers out-of-band like the other security parameters? And how is this >> better than a more typical model wherein the client advertises its capabilities >> and the server enforces its policy? > > Both models will work and even in the above case client will have to signal the algorithm to the authorization server so as to get key with correct length. In the below proposal, there is no need for list of supported authentication algorithms to be agreed upon between the RS and AS servers. > > -Tiru > >> >> --Brandon >> >> On 08/25/2014 01:27 PM, Tirumaleswar Reddy (tireddy) wrote: >>>> -----Original Message----- >>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>> Sent: Monday, August 25, 2014 10:40 PM >>>> To: Tirumaleswar Reddy (tireddy); Oleg Moskalenko >>>> Cc: tram@ietf.org >>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>> >>>> I don't think that the client will be (or can safely be allow to be) >>>> responsible for selecting the algorithm. Somehow, this decision must >>>> be up to the OAuth server. The most that I think the client can do is >>>> send a list of what it supports, which will allow the server to >>>> select the best of the bunch (or reject if none are good enough). >>> >>> I am thinking other way around. TURN server sends lists of HMAC >> algorithms it supports, client picks the algorithm it would like to use and >> conveys it to the authorization server. OAuth has already defined 'alg' >> parameter for the client to signal the algorithm to the authorization server. >>> >>> -Tiru >>> >>>> >>>> I haven't read the referenced draft or your proposed changes so it >>>> may be that you've already dealt with this part of the problem. >>>> >>>> --Brandon >>>> >>>> On 08/25/2014 12:50 PM, Tirumaleswar Reddy (tireddy) wrote: >>>>>> -----Original Message----- >>>>>> From: Brandon Williams [mailto:brandon.williams@akamai.com] >>>>>> Sent: Monday, August 25, 2014 8:06 PM >>>>>> To: Oleg Moskalenko; Tirumaleswar Reddy (tireddy) >>>>>> Cc: tram@ietf.org >>>>>> Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 >>>>>> >>>>>> I agree that the 5389 hash agility plan seems problematic and >>>>>> should be replaced with something more suitable to the stated >>>>>> purpose. That should probably be part of the stun-bis effort, or at >>>>>> happen concurrently so that stun-bis can reference the relevant >> document. >>>>>> Completion of this effort might be a requirement for publishing the >>>>>> 3rd party auth draft, because we don't want to end up publishing a >>>>>> draft that requires an immediate update in order to satisfy a >>>>>> not-yet- >>>> written hash agility requirement. >>>>>> >>>>>> The area that I think is most likely to be challenging with the >>>>>> current 3rd party auth draft is algorithm identification. It will >>>>>> be necessary at some point in the future for the TURN server to >>>>>> select from among multiple supported auth algorithms, but there is >>>>>> no obvious way at the moment for the auth algorithm to be >>>>>> communicated from the auth server to either the client or the TURN >>>>>> server. The only value that could currently be used to guess the >>>>>> auth algorithm is the key_length in the token, but using key_length >>>>>> as an algorithm identifier seems risky, even if it would work with >>>>>> the most likely >>>> candidates today. >>>>> >>>>> I have updated the draft to address the problem in the following way: >>>>> When STUN supports HMAC algorithms other than HMAC-SHA-1 then >> client >>>>> will convey the algorithm negotiated with the TURN server to the >>>> authorization server in the value of 'alg' parameter defined in >>>> [I-D.ietf-oauth- pop-key-distribution]. Authorization server >>>> determines length of the mac_key based on the HMAC algorithm >> conveyed by the client. >>>>> >>>>> -Tiru >>>>> >>>>>> >>>>>> --Brandon >>>>>> >>>>>> On 08/23/2014 02:47 AM, Oleg Moskalenko wrote: >>>>>>> Another problem is that I am not sure that the hash agility plan >>>>>>> idea described in RFC5389 is still valid. I am afraid that it is >>>>>>> unnecessary complicated and outdated, taking into account the >>>>>>> current level of >>>>>>> SHA-256 adoption. The plan was designed to support, >>>>>>> "transparently", the old TURN servers. But in these specs, we do >>>>>>> not necessary have to support the "old" servers with HMAC-SHA-1 >>>>>>> only implementations; as we are writing a new oAuth procedure, there >> will be only "new" >>>>>>> servers supporting the draft specs, anyway. The "old" servers will >>>>>>> not be able to use the oAuth specs. SO we can design a cleaner >>>>>>> simpler hash agility procedure. >>>>>> >>>>>> -- >>>>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>>>> Products Engineering; Akamai Technologies Inc. >>>> >>>> -- >>>> Brandon Williams; Senior Principal Software Engineer Emerging >>>> Products Engineering; Akamai Technologies Inc. >> >> -- >> Brandon Williams; Senior Principal Software Engineer Emerging Products >> Engineering; Akamai Technologies Inc. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Wed Aug 27 02:48:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9D31A047D; Wed, 27 Aug 2014 02:48:31 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNZfijmpZmdi; Wed, 27 Aug 2014 02:48:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E30F71A0465; Wed, 27 Aug 2014 02:48:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 02:48:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iOnXA-7v3tB5F9U0Hi9bGEAVWIQ Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 09:48:32 -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 Working Group of the IETF. Title : TURN Extension for Third Party Authorization Authors : Tirumaleswar Reddy Prashanth Patil Ram Mohan Ravindranath Justin Uberti Filename : draft-ietf-tram-turn-third-party-authz-02.txt Pages : 16 Date : 2014-08-27 Abstract: This document proposes the use of OAuth to obtain and validate ephemeral tokens that can be used for TURN authentication. The usage of ephemeral tokens ensure that access to a TURN server can be controlled even if the tokens are compromised. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turn-third-party-authz-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 Wed Aug 27 03:37:27 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D781A059F; Wed, 27 Aug 2014 03:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYs2chPEbWor; Wed, 27 Aug 2014 03:37:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CA371A04B0; Wed, 27 Aug 2014 03:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1409135843; x=1410345443; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dL5evOWoPayGX/6YzjY7mR7yswaQ3wyq5T8fDgiBBNU=; b=RA+KBhXaxQ5dAnt2x8+9v7arrziX1bd5gGiPl6teLKgV8HGS/k59kroD HTuK5jbBN/5c7wEJCFnxpIWTYs5dry1M+I3i3dsNvPGzZLNAHlWKeV+sA BFwYzDnPJ7yWJ53WNKBWodBngGhbvS/uKR4iAa8dRo53IFVaSUS2eeJG/ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAGC0/VOtJV2a/2dsb2JhbABbgw1TUwQEzCoMh0oBgQ8Wd4QDAQEBBAEBATc0CwwEAgEIEQQBAQsUCQcnCxQJCAIEAQ0FCAGIOQgFvykXjxsxBwaDKYEdBZEvhC2IVZM+g15sgQgkHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,409,1406592000"; d="scan'208";a="72784158" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 27 Aug 2014 10:37:23 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7RAbMbt022017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 10:37:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 05:37:22 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" , "oauth-ext-review@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt Thread-Index: AQHPwdwflerwR/6zbESoNvi+uBdM05vkNMkA Date: Wed, 27 Aug 2014 10:37:21 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831C7EE@xmb-rcd-x10.cisco.com> References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> In-Reply-To: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zcmx3gPSx0sn_bn8_5NdY_-Vh9Y Cc: "Hannes.Tschofenig@gmx.net" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 10:37:24 -0000 This version addresses comments from Hannes and Oleg.=20 -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, August 27, 2014 3:19 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the TURN Revised and Modernized Working > Group of the IETF. >=20 > Title : TURN Extension for Third Party Authorization > Authors : Tirumaleswar Reddy > Prashanth Patil > Ram Mohan Ravindranath > Justin Uberti > Filename : draft-ietf-tram-turn-third-party-authz-02.txt > Pages : 16 > Date : 2014-08-27 >=20 > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turn-third-party-authz/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tram-turn-third-party-authz-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turn-third-party-authz= -02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Aug 27 07:44:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625E41A0718; Wed, 27 Aug 2014 07:44:46 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCf47vmF4lGa; Wed, 27 Aug 2014 07:44:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CC51A06CA; Wed, 27 Aug 2014 07:44:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827144443.15265.68440.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 07:44:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0aq5eNsSUydcoy-5CxBxYoMpFnU Cc: tram@ietf.org Subject: [tram] I-D Action: draft-ietf-tram-turnbis-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 14:44:46 -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 Working Group of the IETF. Title : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) Authors : Tirumaleswar Reddy Alan Johnston Philip Matthews Jonathan Rosenberg Filename : draft-ietf-tram-turnbis-00.txt Pages : 68 Date : 2014-08-27 Abstract: If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal, though it also can be used without ICE. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tram-turnbis-00 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 Aug 27 07:48:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD901A06CA for ; Wed, 27 Aug 2014 07:48:19 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3G95I_a161o for ; Wed, 27 Aug 2014 07:48:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFAE1A06FB for ; Wed, 27 Aug 2014 07:48:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827144817.1606.19306.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 07:48:17 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/tram/yZPOTXXbedpv60WlvryB3E1wYKs Subject: [tram] Milestones changed for tram WG X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 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 Aug 2014 14:48:19 -0000 Changed milestone "Send draft adding DTLS as a transport for STUN/TURN to IESG for publication as Proposed Standard", resolved as "Done". Changed milestone "Send analysis of problems with current TURN authentication to IESG for publication as Informational", resolved as "Done". Changed milestone "Send new TURN server discovery mechanism for enterprises and ISPs to IESG for publication as Proposed Standard", added draft-ietf-tram-turn-server-discovery to milestone. Changed milestone "Send new authentication mechanism(s) to IESG for publication as Proposed Standard", added draft-ietf-tram-stun-origin, draft-ietf-tram-turn-third-party-authz to milestone. Changed milestone "Send TURN-bis draft to IESG for publication as Proposed Standard", added draft-ietf-tram-turnbis to milestone. URL: http://datatracker.ietf.org/wg/tram/charter/ From nobody Wed Aug 27 08:09:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE161A096C for ; Wed, 27 Aug 2014 08:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 sfZHlLilNMhP for ; Wed, 27 Aug 2014 08:09:15 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C6D01A0ADD for ; Wed, 27 Aug 2014 08:09:14 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id l4so631110lbv.23 for ; Wed, 27 Aug 2014 08:09:12 -0700 (PDT) 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:content-type; bh=yBmpHCJ1pthuPAMr18JsmIgxv/fmFI4AOoBtfsmlpAw=; b=l9HCvLWq1d6FUqsDK2pu8v+EfG0IqMyJ6GV6rc6mFqB/jjyUR/AccrELe24oP0FMUr RCXJXci6/TIJzBwU9L6t4etRq2C376zLepV4uGPqienHUlNrc6xzjGCpt5dfmFzklXIb 0pgozmogXddoxZHgNfRwFqviQKhlspNSF6QEPyH/CBnvbiitIq10vvqT4Skio86gJVZc 0MR+JJ3EixdzlxMUiSQ/5a9ZzP/Tz4tlB1cCHBN1a59d12E49GZ7kT9/HLBclUQRL8EC bFjyQ9RZsHN4UkIOKY4zsUIS8XNE/xGk4EsWcHROTO78OgNsJrahI0K6W7pFZJCPEfd2 hORw== X-Gm-Message-State: ALoCoQk/ZLOa/mQF7TNiN25Yd7omG5lvH20YclJTMFLGcKtXhBtbZlGBaObs2OUx2DT3CB1UW8Rr MIME-Version: 1.0 X-Received: by 10.152.6.133 with SMTP id b5mr35014756laa.16.1409152152604; Wed, 27 Aug 2014 08:09:12 -0700 (PDT) Received: by 10.25.135.10 with HTTP; Wed, 27 Aug 2014 08:09:12 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A2831C7EE@xmb-rcd-x10.cisco.com> References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2831C7EE@xmb-rcd-x10.cisco.com> Date: Wed, 27 Aug 2014 11:09:12 -0400 Message-ID: From: Simon Perreault To: Oleg Moskalenko , "Hannes.Tschofenig@gmx.net" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/HXaWmtAKgzqjuJtdk78NsJ7h0no Cc: "oauth-ext-review@ietf.org" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:09:19 -0000 On Wed, Aug 27, 2014 at 6:37 AM, Tirumaleswar Reddy (tireddy) wrote: > This version addresses comments from Hannes and Oleg. Hannes, Oleg, Can you please confirm that your comments have been addressed? Thanks, Simon From nobody Wed Aug 27 09:21:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD781A0B0B; Wed, 27 Aug 2014 09:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 4watY-Ap9Ril; Wed, 27 Aug 2014 09:21:28 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC691A0AEA; Wed, 27 Aug 2014 09:21:28 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id p10so547231pdj.36 for ; Wed, 27 Aug 2014 09:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=1jNUbD9sdnEL2JRPeJGacivcPiosKXItB62R1XHJkd8=; b=tuupxvDvReFAVKx6D4VCtwAFbzzMdCrOOzqZYprsmGM9X0jjghenahLjRWWo/FohIZ X5XhSuZSqzSNU/upHzw83Di2QCJ7icLxuNcocQBGKNNp1VnxmpkYIxX0LwZ4AW7clU19 r3LGtvwhCX5wvFrr2xpsTmc4UFwpOja5ZE+C1KKhdSxADry7t24aiR/KEI0m/dO5fJ5H nOFQwiGUoyfcGNapB79169pBUjZTLD37tEfeXVXDGelLoARMkIC2krJ7Slj3HX4o1BZn Q1qiHZqDExd2kKukBL29yxkKhrLPUTYnRX+J3+emrVu0q0u4ZCDc4imszVDFom/1siYe YZng== X-Received: by 10.68.209.194 with SMTP id mo2mr47180314pbc.80.1409156486487; Wed, 27 Aug 2014 09:21:26 -0700 (PDT) Received: from [10.186.195.252] (181.sub-70-197-10.myvzw.com. [70.197.10.181]) by mx.google.com with ESMTPSA id oh7sm1202804pdb.68.2014.08.27.09.21.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 09:21:24 -0700 (PDT) References: <20140827094830.9888.36362.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A2831C7EE@xmb-rcd-x10.cisco.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <56DC09EC-370D-4D61-B290-71FFA54C1C72@gmail.com> X-Mailer: iPhone Mail (11D201) From: Oleg Moskalenko Date: Wed, 27 Aug 2014 09:21:21 -0700 To: Simon Perreault Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ABx-2zx8PUBWJ3VGyGKDq_Vf1P4 Cc: "oauth-ext-review@ietf.org" , "Hannes.Tschofenig@gmx.net" , "tram@ietf.org" , "Tirumaleswar Reddy \(tireddy\)" Subject: Re: [tram] I-D Action: draft-ietf-tram-turn-third-party-authz-02.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:21:29 -0000 Yes, I got the answer and I agree with the answer. Oleg > On Aug 27, 2014, at 8:09 AM, Simon Perreault wrote: > > On Wed, Aug 27, 2014 at 6:37 AM, Tirumaleswar Reddy (tireddy) > wrote: >> This version addresses comments from Hannes and Oleg. > > Hannes, Oleg, > > Can you please confirm that your comments have been addressed? > > Thanks, > Simon From nobody Thu Aug 28 01:53:48 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559201A0B05 for ; Thu, 28 Aug 2014 01:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxQGiCJvhm8P for ; Thu, 28 Aug 2014 01:53:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180E61A04A8 for ; Thu, 28 Aug 2014 01:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11754; q=dns/txt; s=iport; t=1409216023; x=1410425623; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=494zAHWAZf6/DBl9KQL+5/56Lv8FlZ+OdOgAx0GVKa0=; b=FczKsvHL8w3LL/cM5y+3O25PBseobqtFQqY5EW4B/nS5DEekg0TQ5nOH 3C0e7wLR9UJBIoqTYsZyRZl2mX9MaYT5/rfCl/zLZHaxL3tIouxZAuwzB fVvWXy1AJWOI668ld0t25OVTR3QI2hVQo64JQwkhQammtyzdaQTivo4Bw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFALnt/lOtJV2T/2dsb2JhbABbgw1TVwSCeMkuh08BGYEBFneEAwEBAQMBIxFFBQcGAQgRBAEBAQICBgsSAwIEMBQBCAkBBAENBQgBiDEIDapQlDoXgSyIU4R8AQEeFhsNBIJvNoEdBY8bghSGZ5lcgWIEHIFcbAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,416,1406592000"; d="scan'208";a="350976656" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 08:53:42 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7S8rgI5030775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 08:53:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 03:53:41 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , Oleg Moskalenko Thread-Topic: [tram] draft-ietf-tram-turn-third-party-authz-03 Thread-Index: Ac/CnY2TUvE2dNeVQDqXwzAVxiaxZw== Date: Thu, 28 Aug 2014 08:53:41 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831D2DB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.49.215] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/U_dhgboTBySkTnH_iDpoFNx4CY4 Cc: "tram@ietf.org" Subject: Re: [tram] draft-ietf-tram-turn-third-party-authz-03 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 08:53:45 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmFuZG9uIFdpbGxpYW1zIFtt YWlsdG86YnJhbmRvbi53aWxsaWFtc0Bha2FtYWkuY29tXQ0KPiBTZW50OiBXZWRuZXNkYXksIEF1 Z3VzdCAyNywgMjAxNCAxMjowMCBBTQ0KPiBUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KTsgT2xlZyBNb3NrYWxlbmtvDQo+IENjOiB0cmFtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBb dHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDMNCj4gDQo+IEkg ZG9uJ3QgdGhpbmsgdGhhdCBpdCdzIHJlYXNvbmFibGUgZm9yIHRoZSBjbGllbnQgdG8gc2VsZWN0 IGEgc2luZ2xlIGF1dGggYWxnb3JpdGhtDQo+IGZyb20gYSBsaXN0IG9mIHRob3NlIHN1cHBvcnRl ZCBieSB0aGUgcmVsYXkgc2VydmVyLCBiZWNhdXNlIHRoZXJlIGlzIGEgcmlzayB0aGF0DQo+IGl0 IHdpbGwgc2VsZWN0IG9uZSB0aGF0IGRvZXNuJ3QgbWVldCB0aGUgcG9saWN5IHJlcXVpcmVtZW50 cyBiZWluZyBlbmZvcmNlZCBieQ0KPiB0aGUgb2F1dGggc2VydmVyLg0KDQpXaHkgc2hvdWxkIHRo ZSBwb2xpY3kgcmVxdWlyZW1lbnRzIGVuZm9yY2VkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBjYXJlIGFib3V0IHRoZSBhbGdvcml0aG0gdXNlZCBieSB0aGUgY2xpZW50IGFuZCBUVVJOIHNl cnZlciB0byBpbnRlZ3JpdHkgcHJvdGVjdCBtZXNzYWdlcyA/DQoNCj4gDQo+IEluIGFkZGl0aW9u LCBJIHRoaW5rIHRoZSBvYXV0aCBhZG1pbmlzdHJhdG9yIGhhcyB0byBrbm93IHRoZSBhbGdvcml0 aG1zDQo+IHN1cHBvcnRlZCBieSB0aGUgcmVsYXkgc2VydmVyIGluIG9yZGVyIHRvIGNvbmZpZ3Vy ZSBhIHJlYXNvbmFibGUgcG9saWN5Lg0KDQpBcyBwYXJ0IG9mIGNvbW11bmljYXRpb24gYmV0d2Vl biBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgcmVzb3VyY2Ugc2VydmVyIHRvIGVzdGFibGlzaCBh IGxvbmctdGVybSBzeW1tZXRyaWMga2V5LCByZXNvdXJjZSBzZXJ2ZXIgY2FuIGluZm9ybSB0aGUg YWxnb3JpdGhtcyBpdCBzdXBwb3J0cy4NCkJ1dCB3aGF0IEkgZG9uJ3QgdW5kZXJzdGFuZCBpcyB3 aHkgc2hvdWxkIGF1dGhvcml6YXRpb24gc2VydmVyIGtub3cgdGhlIGFsZ29yaXRobXMgc3VwcG9y dGVkIGJ5IHRoZSByZXNvdXJjZSBvciByZWxheSBzZXJ2ZXIgPw0KRG8geW91IHNlZSBzb21lIGF0 dGFjayBvciBzZWN1cml0eSBob2xlIGJlY2F1c2Ugb2Ygd2hpY2ggeW91IGFyZSBzdWdnZXN0aW5n IHRoaXMgYXBwcm9hY2ggPw0KDQo+IEkgZG9uJ3QgdGhpbmsgdGhlIHBvbGljeSBjb25maWd1cmF0 aW9uIHJlcXVpcmVtZW50IGNhbiBiZSBtZXQgd2l0aCBpbi1iYW5kDQo+IGNvbW11bmljYXRpb24g b2YgdGhlIHN1cHBvcnRlZCBhbGdvcml0aG1zLg0KPiANCj4gSSBhZ3JlZSB0aGF0IHRoZSBjbGll bnQgYW5kIHRoZSBvYXV0aCBzZXJ2ZXIgaGF2ZSB0byBhZ3JlZSBvbiB0aGUgYWxnb3JpdGhtIGlu DQo+IG9yZGVyIGZvciB0aGUgb2F1dGggc2VydmVyIHRvIHNlbmQgYW4gYXBwcm9wcmlhdGVseSBz aXplZCBrZXkuIA0KDQpPa2F5Lg0KDQo+IEknbSBzdWdnZXN0aW5nDQo+IHRoYXQgdGhlIGFsZ29y aXRobSBzaG91bGQgYmUgc2VsZWN0ZWQgYnkgdGhlIG9hdXRoIHNlcnZlciBmcm9tIGFtb25nIHRo ZQ0KPiB1bmlvbiBvZiB0aGUgc2V0IHN1cHBvcnRlZCBieSB0aGUgY2xpZW50IGFuZCB0aGUgYWxn b3JpdGhtIHN1cHBvcnRlZCBieSB0aGUNCj4gcmVsYXkgc2VydmVyLiBJJ20gYWxzbyBzdWdnZXN0 aW5nIHRoYXQgdGhlIGNsaWVudCBzaG91bGQgbm90IGJlIGFsbG93ZWQgdG8NCj4gZGVjbGFyZSB3 aGF0IHRoZSB1bmlvbiBzZXQgaXMsIHdoaWNoIGlzIGEgc2hvcnRjb21pbmcgb2YgZGVsaXZlcmlu ZyB0aGUNCj4gaW5mb3JtYXRpb24gaW4tYmFuZC4NCj4gDQo+IEFsbCBvZiB0aGUgYWJvdmUgaGF2 aW5nIGJlZW4gc2FpZCwgSSB0aGluayB0aGF0IHdlIG1heSBiZSBnZXR0aW5nIGFoZWFkIG9mIHRo ZQ0KPiBkaXNjdXNzaW9uLiBJcyB0aGVyZSBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHdlIG5lZWQg dG8gY29tZSB1cCB3aXRoIGEgbmV3DQo+IGhhc2ggYWdpbGl0eSBhcHByb2FjaCBmb3IgU1RVTj8g DQoNCkkgdGhpbmsgU1RVTmJpcyB3aWxsIHByb3ZpZGUgaGFzaCBhZ2lsaXR5IHN1cHBvcnQuIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90cmFtL2N1cnJlbnQvbXNnMDAwMDAu aHRtbCBjaGFydGVyIHByb3Bvc2FsIG1lbnRpb25zIHN1cHBvcnRpbmcgaGFzaCBhZ2lsaXR5Lg0K DQo+IEFuZCBpZiBzbywgaGFzIHNvbWVvbmUgYWN0dWFsbHkgdGFrZW4gdGhhdA0KPiBvbj8gV2hh dCB3ZSBjb21lIHVwIHdpdGggb24gaGFzaCBhZ2lsaXR5IGZvciAzcmQgcGFydHkgYXV0aCBtYXkg ZGVwZW5kDQo+IHVwb24gaG93IGhhc2ggYWdpbGl0eSBpcyByZXNvbHZlZCBmb3IgU1RVTiBpbiBn ZW5lcmFsLg0KDQotVGlydQ0KDQo+IA0KPiAtLUJyYW5kb24NCj4gDQo+IE9uIDA4LzI2LzIwMTQg MDI6MTkgQU0sIFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgd3JvdGU6DQo+ID4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEJyYW5kb24gV2lsbGlhbXMgW21haWx0 bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb21dDQo+ID4+IFNlbnQ6IE1vbmRheSwgQXVndXN0 IDI1LCAyMDE0IDExOjIwIFBNDQo+ID4+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp OyBPbGVnIE1vc2thbGVua28NCj4gPj4gQ2M6IHRyYW1AaWV0Zi5vcmcNCj4gPj4gU3ViamVjdDog UmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiA+ Pg0KPiA+PiBXaHkgc2hvdWxkIGl0IGJlIG5lY2Vzc2FyeSBmb3IgdGhlIFRVUk4gc2VydmVyIHRv IHNlbmQgYSBsaXN0PyBDYW4ndA0KPiA+PiB0aGUgbGlzdCBvZiBzdXBwb3J0ZWQgYXV0aCBhbGdv cml0aG1zIGJlIGFncmVlZCB1cG9uIGJldHdlZW4gdGhlDQo+ID4+IHJlbGF5IGFuZCBvYXV0aCBz ZXJ2ZXJzIG91dC1vZi1iYW5kIGxpa2UgdGhlIG90aGVyIHNlY3VyaXR5DQo+ID4+IHBhcmFtZXRl cnM/IEFuZCBob3cgaXMgdGhpcyBiZXR0ZXIgdGhhbiBhIG1vcmUgdHlwaWNhbCBtb2RlbCB3aGVy ZWluDQo+ID4+IHRoZSBjbGllbnQgYWR2ZXJ0aXNlcyBpdHMgY2FwYWJpbGl0aWVzIGFuZCB0aGUg c2VydmVyIGVuZm9yY2VzIGl0cyBwb2xpY3k/DQo+ID4NCj4gPiBCb3RoIG1vZGVscyB3aWxsIHdv cmsgYW5kIGV2ZW4gaW4gdGhlIGFib3ZlIGNhc2UgY2xpZW50IHdpbGwgaGF2ZSB0byBzaWduYWwN Cj4gdGhlIGFsZ29yaXRobSB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc28gYXMgdG8gZ2V0 IGtleSB3aXRoIGNvcnJlY3QgbGVuZ3RoLg0KPiBJbiB0aGUgYmVsb3cgcHJvcG9zYWwsIHRoZXJl IGlzIG5vIG5lZWQgZm9yIGxpc3Qgb2Ygc3VwcG9ydGVkIGF1dGhlbnRpY2F0aW9uDQo+IGFsZ29y aXRobXMgdG8gYmUgYWdyZWVkIHVwb24gYmV0d2VlbiB0aGUgUlMgYW5kIEFTIHNlcnZlcnMuDQo+ ID4NCj4gPiAtVGlydQ0KPiA+DQo+ID4+DQo+ID4+IC0tQnJhbmRvbg0KPiA+Pg0KPiA+PiBPbiAw OC8yNS8yMDE0IDAxOjI3IFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0K PiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogQnJhbmRvbiBX aWxsaWFtcyBbbWFpbHRvOmJyYW5kb24ud2lsbGlhbXNAYWthbWFpLmNvbV0NCj4gPj4+PiBTZW50 OiBNb25kYXksIEF1Z3VzdCAyNSwgMjAxNCAxMDo0MCBQTQ0KPiA+Pj4+IFRvOiBUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpOyBPbGVnIE1vc2thbGVua28NCj4gPj4+PiBDYzogdHJhbUBpZXRm Lm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbdHJhbV0gZHJhZnQtaWV0Zi10cmFtLXR1cm4tdGhp cmQtcGFydHktYXV0aHotMDMNCj4gPj4+Pg0KPiA+Pj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUg Y2xpZW50IHdpbGwgYmUgKG9yIGNhbiBzYWZlbHkgYmUgYWxsb3cgdG8NCj4gPj4+PiBiZSkgcmVz cG9uc2libGUgZm9yIHNlbGVjdGluZyB0aGUgYWxnb3JpdGhtLiBTb21laG93LCB0aGlzIGRlY2lz aW9uDQo+ID4+Pj4gbXVzdCBiZSB1cCB0byB0aGUgT0F1dGggc2VydmVyLiBUaGUgbW9zdCB0aGF0 IEkgdGhpbmsgdGhlIGNsaWVudA0KPiA+Pj4+IGNhbiBkbyBpcyBzZW5kIGEgbGlzdCBvZiB3aGF0 IGl0IHN1cHBvcnRzLCB3aGljaCB3aWxsIGFsbG93IHRoZQ0KPiA+Pj4+IHNlcnZlciB0byBzZWxl Y3QgdGhlIGJlc3Qgb2YgdGhlIGJ1bmNoIChvciByZWplY3QgaWYgbm9uZSBhcmUgZ29vZA0KPiBl bm91Z2gpLg0KPiA+Pj4NCj4gPj4+IEkgYW0gdGhpbmtpbmcgb3RoZXIgd2F5IGFyb3VuZC4gVFVS TiBzZXJ2ZXIgc2VuZHMgbGlzdHMgb2YgSE1BQw0KPiA+PiBhbGdvcml0aG1zIGl0IHN1cHBvcnRz LCBjbGllbnQgcGlja3MgdGhlIGFsZ29yaXRobSBpdCB3b3VsZCBsaWtlIHRvDQo+ID4+IHVzZSBh bmQgY29udmV5cyBpdCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIE9BdXRoIGhhcyBhbHJl YWR5IGRlZmluZWQNCj4gJ2FsZycNCj4gPj4gcGFyYW1ldGVyIGZvciB0aGUgY2xpZW50IHRvIHNp Z25hbCB0aGUgYWxnb3JpdGhtIHRvIHRoZSBhdXRob3JpemF0aW9uDQo+IHNlcnZlci4NCj4gPj4+ DQo+ID4+PiAtVGlydQ0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+IEkgaGF2ZW4ndCByZWFkIHRoZSBy ZWZlcmVuY2VkIGRyYWZ0IG9yIHlvdXIgcHJvcG9zZWQgY2hhbmdlcyBzbyBpdA0KPiA+Pj4+IG1h eSBiZSB0aGF0IHlvdSd2ZSBhbHJlYWR5IGRlYWx0IHdpdGggdGhpcyBwYXJ0IG9mIHRoZSBwcm9i bGVtLg0KPiA+Pj4+DQo+ID4+Pj4gLS1CcmFuZG9uDQo+ID4+Pj4NCj4gPj4+PiBPbiAwOC8yNS8y MDE0IDEyOjUwIFBNLCBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIHdyb3RlOg0KPiA+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IEJyYW5kb24gV2ls bGlhbXMgW21haWx0bzpicmFuZG9uLndpbGxpYW1zQGFrYW1haS5jb21dDQo+ID4+Pj4+PiBTZW50 OiBNb25kYXksIEF1Z3VzdCAyNSwgMjAxNCA4OjA2IFBNDQo+ID4+Pj4+PiBUbzogT2xlZyBNb3Nr YWxlbmtvOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQo+ID4+Pj4+PiBDYzogdHJhbUBp ZXRmLm9yZw0KPiA+Pj4+Pj4gU3ViamVjdDogUmU6IFt0cmFtXSBkcmFmdC1pZXRmLXRyYW0tdHVy bi10aGlyZC1wYXJ0eS1hdXRoei0wMw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgYWdyZWUgdGhhdCB0 aGUgNTM4OSBoYXNoIGFnaWxpdHkgcGxhbiBzZWVtcyBwcm9ibGVtYXRpYyBhbmQNCj4gPj4+Pj4+ IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIHNvbWV0aGluZyBtb3JlIHN1aXRhYmxlIHRvIHRoZSBz dGF0ZWQNCj4gPj4+Pj4+IHB1cnBvc2UuIFRoYXQgc2hvdWxkIHByb2JhYmx5IGJlIHBhcnQgb2Yg dGhlIHN0dW4tYmlzIGVmZm9ydCwgb3INCj4gPj4+Pj4+IGF0IGhhcHBlbiBjb25jdXJyZW50bHkg c28gdGhhdCBzdHVuLWJpcyBjYW4gcmVmZXJlbmNlIHRoZQ0KPiA+Pj4+Pj4gcmVsZXZhbnQNCj4g Pj4gZG9jdW1lbnQuDQo+ID4+Pj4+PiBDb21wbGV0aW9uIG9mIHRoaXMgZWZmb3J0IG1pZ2h0IGJl IGEgcmVxdWlyZW1lbnQgZm9yIHB1Ymxpc2hpbmcNCj4gPj4+Pj4+IHRoZSAzcmQgcGFydHkgYXV0 aCBkcmFmdCwgYmVjYXVzZSB3ZSBkb24ndCB3YW50IHRvIGVuZCB1cA0KPiA+Pj4+Pj4gcHVibGlz aGluZyBhIGRyYWZ0IHRoYXQgcmVxdWlyZXMgYW4gaW1tZWRpYXRlIHVwZGF0ZSBpbiBvcmRlciB0 bw0KPiA+Pj4+Pj4gc2F0aXNmeSBhDQo+ID4+Pj4+PiBub3QteWV0LQ0KPiA+Pj4+IHdyaXR0ZW4g aGFzaCBhZ2lsaXR5IHJlcXVpcmVtZW50Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBhcmVhIHRo YXQgSSB0aGluayBpcyBtb3N0IGxpa2VseSB0byBiZSBjaGFsbGVuZ2luZyB3aXRoIHRoZQ0KPiA+ Pj4+Pj4gY3VycmVudCAzcmQgcGFydHkgYXV0aCBkcmFmdCBpcyBhbGdvcml0aG0gaWRlbnRpZmlj YXRpb24uIEl0IHdpbGwNCj4gPj4+Pj4+IGJlIG5lY2Vzc2FyeSBhdCBzb21lIHBvaW50IGluIHRo ZSBmdXR1cmUgZm9yIHRoZSBUVVJOIHNlcnZlciB0bw0KPiA+Pj4+Pj4gc2VsZWN0IGZyb20gYW1v bmcgbXVsdGlwbGUgc3VwcG9ydGVkIGF1dGggYWxnb3JpdGhtcywgYnV0IHRoZXJlDQo+ID4+Pj4+ PiBpcyBubyBvYnZpb3VzIHdheSBhdCB0aGUgbW9tZW50IGZvciB0aGUgYXV0aCBhbGdvcml0aG0g dG8gYmUNCj4gPj4+Pj4+IGNvbW11bmljYXRlZCBmcm9tIHRoZSBhdXRoIHNlcnZlciB0byBlaXRo ZXIgdGhlIGNsaWVudCBvciB0aGUNCj4gPj4+Pj4+IFRVUk4gc2VydmVyLiBUaGUgb25seSB2YWx1 ZSB0aGF0IGNvdWxkIGN1cnJlbnRseSBiZSB1c2VkIHRvIGd1ZXNzDQo+ID4+Pj4+PiB0aGUgYXV0 aCBhbGdvcml0aG0gaXMgdGhlIGtleV9sZW5ndGggaW4gdGhlIHRva2VuLCBidXQgdXNpbmcNCj4g Pj4+Pj4+IGtleV9sZW5ndGggYXMgYW4gYWxnb3JpdGhtIGlkZW50aWZpZXIgc2VlbXMgcmlza3ks IGV2ZW4gaWYgaXQNCj4gPj4+Pj4+IHdvdWxkIHdvcmsgd2l0aCB0aGUgbW9zdCBsaWtlbHkNCj4g Pj4+PiBjYW5kaWRhdGVzIHRvZGF5Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGhhdmUgdXBkYXRlZCB0 aGUgZHJhZnQgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbSBpbiB0aGUgZm9sbG93aW5nIHdheToNCj4g Pj4+Pj4gV2hlbiBTVFVOIHN1cHBvcnRzIEhNQUMgYWxnb3JpdGhtcyBvdGhlciB0aGFuIEhNQUMt U0hBLTEgdGhlbg0KPiA+PiBjbGllbnQNCj4gPj4+Pj4gd2lsbCBjb252ZXkgdGhlIGFsZ29yaXRo bSBuZWdvdGlhdGVkIHdpdGggdGhlIFRVUk4gc2VydmVyIHRvICB0aGUNCj4gPj4+PiBhdXRob3Jp emF0aW9uIHNlcnZlciBpbiB0aGUgdmFsdWUgb2YgJ2FsZycgcGFyYW1ldGVyIGRlZmluZWQgaW4N Cj4gPj4+PiBbSS1ELmlldGYtb2F1dGgtIHBvcC1rZXktZGlzdHJpYnV0aW9uXS4gIEF1dGhvcml6 YXRpb24gc2VydmVyDQo+ID4+Pj4gZGV0ZXJtaW5lcyBsZW5ndGggb2YgdGhlIG1hY19rZXkgYmFz ZWQgb24gdGhlIEhNQUMgYWxnb3JpdGhtDQo+ID4+IGNvbnZleWVkIGJ5IHRoZSBjbGllbnQuDQo+ ID4+Pj4+DQo+ID4+Pj4+IC1UaXJ1DQo+ID4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gLS1CcmFu ZG9uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gT24gMDgvMjMvMjAxNCAwMjo0NyBBTSwgT2xlZyBNb3Nr YWxlbmtvIHdyb3RlOg0KPiA+Pj4+Pj4+IEFub3RoZXIgcHJvYmxlbSBpcyB0aGF0IEkgYW0gbm90 IHN1cmUgdGhhdCB0aGUgaGFzaCBhZ2lsaXR5IHBsYW4NCj4gPj4+Pj4+PiBpZGVhIGRlc2NyaWJl ZCBpbiBSRkM1Mzg5IGlzIHN0aWxsIHZhbGlkLiBJIGFtIGFmcmFpZCB0aGF0IGl0IGlzDQo+ID4+ Pj4+Pj4gdW5uZWNlc3NhcnkgY29tcGxpY2F0ZWQgYW5kIG91dGRhdGVkLCB0YWtpbmcgaW50byBh Y2NvdW50IHRoZQ0KPiA+Pj4+Pj4+IGN1cnJlbnQgbGV2ZWwgb2YNCj4gPj4+Pj4+PiBTSEEtMjU2 IGFkb3B0aW9uLiBUaGUgcGxhbiB3YXMgZGVzaWduZWQgdG8gc3VwcG9ydCwNCj4gPj4+Pj4+PiAi dHJhbnNwYXJlbnRseSIsIHRoZSBvbGQgVFVSTiBzZXJ2ZXJzLiBCdXQgaW4gdGhlc2Ugc3BlY3Ms IHdlIGRvDQo+ID4+Pj4+Pj4gbm90IG5lY2Vzc2FyeSBoYXZlIHRvIHN1cHBvcnQgdGhlICJvbGQi IHNlcnZlcnMgd2l0aCBITUFDLVNIQS0xDQo+ID4+Pj4+Pj4gb25seSBpbXBsZW1lbnRhdGlvbnM7 IGFzIHdlIGFyZSB3cml0aW5nIGEgbmV3IG9BdXRoIHByb2NlZHVyZSwNCj4gPj4+Pj4+PiB0aGVy ZQ0KPiA+PiB3aWxsIGJlIG9ubHkgIm5ldyINCj4gPj4+Pj4+PiBzZXJ2ZXJzIHN1cHBvcnRpbmcg dGhlIGRyYWZ0IHNwZWNzLCBhbnl3YXkuIFRoZSAib2xkIiBzZXJ2ZXJzDQo+ID4+Pj4+Pj4gd2ls bCBub3QgYmUgYWJsZSB0byB1c2UgdGhlIG9BdXRoIHNwZWNzLiBTTyB3ZSBjYW4gZGVzaWduIGEN Cj4gPj4+Pj4+PiBjbGVhbmVyIHNpbXBsZXIgaGFzaCBhZ2lsaXR5IHByb2NlZHVyZS4NCj4gPj4+ Pj4+DQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4gQnJhbmRvbiBXaWxsaWFtczsgU2VuaW9yIFByaW5j aXBhbCBTb2Z0d2FyZSBFbmdpbmVlciBFbWVyZ2luZw0KPiA+Pj4+Pj4gUHJvZHVjdHMgRW5naW5l ZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0KPiA+Pj4+DQo+ID4+Pj4gLS0NCj4gPj4+ PiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNpcGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVt ZXJnaW5nDQo+ID4+Pj4gUHJvZHVjdHMgRW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMg SW5jLg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBCcmFuZG9uIFdpbGxpYW1zOyBTZW5pb3IgUHJpbmNp cGFsIFNvZnR3YXJlIEVuZ2luZWVyIEVtZXJnaW5nDQo+ID4+IFByb2R1Y3RzIEVuZ2luZWVyaW5n OyBBa2FtYWkgVGVjaG5vbG9naWVzIEluYy4NCj4gDQo+IC0tDQo+IEJyYW5kb24gV2lsbGlhbXM7 IFNlbmlvciBQcmluY2lwYWwgU29mdHdhcmUgRW5naW5lZXIgRW1lcmdpbmcgUHJvZHVjdHMNCj4g RW5naW5lZXJpbmc7IEFrYW1haSBUZWNobm9sb2dpZXMgSW5jLg0K From nobody Fri Aug 29 11:50:01 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9465E1A0AE8 for ; Fri, 29 Aug 2014 11:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nluECPkQx4B for ; Fri, 29 Aug 2014 11:49:57 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id E1ACF1A0AE4 for ; Fri, 29 Aug 2014 11:49:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CF47947712 for ; Fri, 29 Aug 2014 18:49:54 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A8708476FA for ; Fri, 29 Aug 2014 18:49:54 +0000 (GMT) Received: from [172.28.115.172] (unknown [172.28.115.172]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id A2E2380044; Fri, 29 Aug 2014 18:49:54 +0000 (GMT) Message-ID: <5400CB52.1090202@akamai.com> Date: Fri, 29 Aug 2014 14:49:54 -0400 From: Brandon Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Wsw12PExp8iU6YzgJtafwvitukg Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 18:49:58 -0000 Hi all, In working through some relay server selection issues with a customer, we began discussing some corner cases related to server redirection via the TRY-ALTERNATE error response for allocate requests. We also discussed the impact on call setup time. I'd like to get some feedback from the list on the issue. Here's the basic problem. For a 3rd party TURN service that uses DNS to select from among multiple candidate relay servers, the location of the requester will often be determined using the source IP address of the DNS request. This will typically be the client's configured DNS server, not the client itself. Some public DNS servers support end-user identification in the DNS request, but it's not common and it requires a trust relationship between the client's DNS server and the relay provider's DNS server. There are two problems (at least) with this approach: 1. The DNS server is not geolocated with the client, so a bad relay is returned. 2. The DNS server is shared by multiple clients, making it more difficult to load balance the clients across multiple relays. Each of these can be resolved by sending a TRY-ALTERNATE error to the client on the allocate request, but this also has some issues, mostly relating to call setup time. Even one redirection can noticeably extend call setup delays. If the initial relay server selection is horrible (e.g. because the DNS server is located very far away from the client), this is worth the tradeoff, but in cases where the initial selection is suboptimal but still reasonable, it may be preferable to continue call setup using the initial relay server selection while waiting for the new relay allocation. If there is some bad luck and the client receives multiple TRY-ALTERNATE error responses, the negative impact on call setup could be quite substantial. So, similar to the case described in the peer-specific redirection I.D., in some cases, it may be useful for the client to indicate to the server whether it would like performance-based redirection and also what type of response (success or error) it would like to receive in that case. What I am discussing with this customer is the idea of using the CHECK-ALTERNATE attribute defined in the peer-specific redirection draft for allocate requests. The value for the attribute would be one of: noredirect, senderror, or sendsuccess. This would allow the client to optimize call setup and also to mitigate the risk of redirection loops. Is anyone else interested in this idea? I.e. would it be worthwhile for me to write up a short I.D.? Does anyone have ideas for a better way to handle the same problem that I should consider instead? Thanks, --Brandon PS: I know that at least the geolocation problem could be mostly resolved using anycast addresses. Experience suggests that anycast addresses are unsuitable for broad deployments with lots of POPs, frequently preventing deployments in some areas due to management burden. They usually require the use of fallback to unicast, and so become an optimization, not a full solution. -- Brandon Williams; Senior Principal Software Engineer Emerging Products Engineering; Akamai Technologies Inc. From nobody Sat Aug 30 21:21:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9AA1A6F85 for ; Sat, 30 Aug 2014 21:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIDnisnGEDAP for ; Sat, 30 Aug 2014 21:21:04 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD041A6F83 for ; Sat, 30 Aug 2014 21:21:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5064; q=dns/txt; s=iport; t=1409458864; x=1410668464; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=H02bIm/P/bFS3hF+7KWodabepxcBMn3SL2Wkvtr9lts=; b=aXUoCnAbilTRV4i/YueqpMwAankW+uYW1j7qy+I9ah0FsLpG1FB+YAH1 nzHIbCz2H+GUUT17944cx3dN/KCj2hoRy3mZF0nJGelKGtYJyabd0VBp6 Oe+skRQjUPVFqXxdjqYoWt7sWFU33BtbCOLVU9to6F231koBUk8PSzvD1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJehAlStJV2Y/2dsb2JhbABbgw1TVwTHTwyHSgGBDRZ3hAMBAQEDAQEBAQssKwkEDAcGAQgRBAEBCxQJLgsUCQkBBAESCBOIHwgNuwkBF48cPoMpgR0FhQUCjCqELohYij6JBYNhbAEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,435,1406592000"; d="scan'208";a="73741257" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 31 Aug 2014 04:20:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7V4KwSl009056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 31 Aug 2014 04:20:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Sat, 30 Aug 2014 23:20:58 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Brandon Williams , "tram@ietf.org" Thread-Topic: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE Thread-Index: Ac/E0vKrX2PzBon2S3OFvz2IGk0m3g== Date: Sun, 31 Aug 2014 04:20:57 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A2831E164@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/B0__baG_5_lX0Esqgk5dq2UljfQ Subject: Re: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK-ALTERNATE X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 04:21:07 -0000 Hi Brandon, Please see inline=20 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Brandon Williams > Sent: Saturday, August 30, 2014 12:20 AM > To: tram@ietf.org > Subject: [tram] DNS-based relay selection, ALTERNATE-SERVER, and CHECK- > ALTERNATE >=20 > Hi all, >=20 > In working through some relay server selection issues with a customer, we > began discussing some corner cases related to server redirection via the = TRY- > ALTERNATE error response for allocate requests. We also discussed the > impact on call setup time. I'd like to get some feedback from the list on= the > issue. >=20 > Here's the basic problem. For a 3rd party TURN service that uses DNS to > select from among multiple candidate relay servers, the location of the > requester will often be determined using the source IP address of the DNS > request. This will typically be the client's configured DNS server, not t= he client > itself. Some public DNS servers support end-user identification in the DN= S > request, but it's not common and it requires a trust relationship between= the > client's DNS server and the relay provider's DNS server.=20 Few questions 1) Is trust relationship mandatory ?=20 I don't see any such discussion in http://tools.ietf.org/html/draft-vanderg= aast-edns-client-subnet-01#section-9 2) Is end-user identification required or just detecting user's geolocation= sufficient ?=20 The reason for the question is in CDN, identifying user's geolocation is su= fficient for DNS based redirection (http://tools.ietf.org/html/rfc7336#sect= ion-2.1.1) 3)If Google/OpenDNS public DNS servers already support edns-client-subnet t= hen what is the problem ? > There are two > problems (at least) with this approach: >=20 > 1. The DNS server is not geolocated with the client, so a bad relay > is returned. >=20 > 2. The DNS server is shared by multiple clients, making it more > difficult to load balance the clients across multiple relays. >=20 > Each of these can be resolved by sending a TRY-ALTERNATE error to the cli= ent > on the allocate request, but this also has some issues, mostly relating t= o call > setup time. Is it mandatory for the endpoints in the Enterprise network to use the 3rd = party TURN service ? I mean if firewall is configured to permit media sessions to any external p= eer only through the 3rd party TURN service, it may help if client only adv= ertises relayed candidates.=20 This way ICE can be concluded faster. >=20 > Even one redirection can noticeably extend call setup delays.=20 It will be useful if you can share the numbers on the call setup delay noti= ced. > If the initial > relay server selection is horrible (e.g. because the DNS server is locate= d very > far away from the client), this is worth the tradeoff, but in cases where= the > initial selection is suboptimal but still reasonable, it may be preferabl= e to > continue call setup using the initial relay server selection while waitin= g for the > new relay allocation.=20 So the idea is that the client will trigger ICE restart later using the new= relay allocation. > If there is some bad luck and the client receives multiple > TRY-ALTERNATE error responses, the negative impact on call setup could be > quite substantial. >=20 > So, similar to the case described in the peer-specific redirection I.D., = in some > cases, it may be useful for the client to indicate to the server whether = it > would like performance-based redirection and also what type of response > (success or error) it would like to receive in that case. > What I am discussing with this customer is the idea of using the CHECK- > ALTERNATE attribute defined in the peer-specific redirection draft for > allocate requests. The value for the attribute would be one of: > noredirect, senderror, or sendsuccess. This would allow the client to opt= imize > call setup and also to mitigate the risk of redirection loops. >=20 > Is anyone else interested in this idea?=20 Yes, once you convince that there is a problem :) Cheers, -Tiru > I.e. would it be worthwhile for me to > write up a short I.D.? Does anyone have ideas for a better way to handle = the > same problem that I should consider instead? >=20 > Thanks, > --Brandon >=20 > PS: I know that at least the geolocation problem could be mostly resolved > using anycast addresses. Experience suggests that anycast addresses are > unsuitable for broad deployments with lots of POPs, frequently preventing > deployments in some areas due to management burden. They usually > require the use of fallback to unicast, and so become an optimization, no= t a > full solution. >=20 > -- > Brandon Williams; Senior Principal Software Engineer Emerging Products > Engineering; Akamai Technologies Inc. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram