From nobody Wed Apr 3 02:37:18 2019 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B54BF1294FA; Sat, 23 Mar 2019 03:05:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, spencerdawkins.ietf@gmail.com, The IESG , draft-ietf-tram-stunbis@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155333551067.15597.6627526664714812149.idtracker@ietfa.amsl.com> Date: Sat, 23 Mar 2019 03:05:10 -0700 Archived-At: X-Mailman-Approved-At: Wed, 03 Apr 2019 02:37:16 -0700 Subject: [tram] Protocol Action: 'Session Traversal Utilities for NAT (STUN)' to Proposed Standard (draft-ietf-tram-stunbis-21.txt) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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 Mar 2019 10:05:11 -0000 The IESG has approved the following document: - 'Session Traversal Utilities for NAT (STUN)' (draft-ietf-tram-stunbis-21.txt) as Proposed Standard This document is the product of the TURN Revised and Modernized Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ Technical Summary Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. This document obsoletes the original STUN specification RFC 5389. Working Group Summary The working group had a strong consensus around this draft. Document Quality Marc Petit-Huguenin reported that he has implemented this draft. The document quality is satisfactory. The draft has sections pertaining to security and DNS, and those are sufficiently reviewed. Personnel Tolga Asveren is the document shepherd. Spencer Dawkins is the responsible Area director. From nobody Thu Apr 4 06:59:53 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4529212066D; Thu, 4 Apr 2019 06:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iWVf_c0Z752; Thu, 4 Apr 2019 06:59:46 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40051.outbound.protection.outlook.com [40.107.4.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F81C120691; Thu, 4 Apr 2019 06:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nzzFJlW10Jdgnx5zlCVLJvlXGRv2t7yw320vkaab9tA=; b=TJ72GVCO0O4JrRumX6z63dxtH3M5rNyFPosPJ7R7V9nU11dxbjxPzpbTf7hWSlirsycg6evNuee3aJj8YGRtT0iNyXdb1Lcil8J9tRg/xfBtHa0FaIvihj+6peWN2Qyc6ba2qmGVHUxVR2d4jM1lZmj0Kfzu+f+l/c9Aiqwo0Rw= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2154.eurprd07.prod.outlook.com (10.168.34.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.11; Thu, 4 Apr 2019 13:59:43 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1771.006; Thu, 4 Apr 2019 13:59:43 +0000 From: Magnus Westerlund To: "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Thu, 4 Apr 2019 13:59:43 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c15c449b-587b-46cf-e284-08d6b905c9cc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2154; x-ms-traffictypediagnostic: HE1PR0701MB2154: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(366004)(136003)(376002)(189003)(199004)(51444003)(9686003)(68736007)(10750500005)(105586002)(6506007)(2501003)(99286004)(102836004)(30864003)(305945005)(316002)(186003)(14454004)(71200400001)(71190400001)(66574012)(86362001)(110136005)(6436002)(55016002)(476003)(450100002)(81166006)(8676002)(33656002)(26005)(7736002)(44832011)(97736004)(8936002)(5660300002)(486006)(7696005)(2906002)(6116002)(18074004)(256004)(53936002)(52536014)(6306002)(3846002)(478600001)(66066001)(14444005)(561944003)(53946003)(25786009)(106356001)(74316002)(966005)(81156014)(151285002)(579004)(554374003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2154; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xEwsrjMSj3XFG8JYqKmUHsyMG4gh7I69HQUccvbbbGhJiUpRbfh0/C/CxIptkwcQJwXvEEnhPMu7ia0oP3CE1wi+zu5ziRHslYxSZGoF/BkogoHC8pXn4c5RaiwC111aSkq7RFaMPtmKDD1TzPYmjC1aNP/kmcTZwLDyocCzbmLFsyDoHgm+Ie4PKLeed0Tzxv9pA8gyuO5y7s0tEnbLc+mHzK76neEXXu54UMipf4yiqlGr3qZIjMU95lYe6/z1Ui9lsks9odgsceHZLEF/zARWBkBxlRog2qaN/SWBFFgiETyVdl/dqJH8/laPKpuF9XpSqkPhmKK9OyDOue0g5NAcSt7QDqLc2LQyN5LKraJLQs+8OwnQg14LjZ3Z8B11RPypTLtqv0JQvxwDgf+LFwIwwWudFYMwx9TOhAlA8GU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c15c449b-587b-46cf-e284-08d6b905c9cc X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 13:59:43.0075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2154 Archived-At: Subject: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 04 Apr 2019 13:59:51 -0000 Hi,=0A= =0A= I have now finished the AD review. There are a lot of details that I=0A= think needs fixing or at least feedback on. I also think there are a=0A= couple of more serious issues here. Especially regarding the handling of=0A= MTU and fragmentation, as well as IP header fields in address family=0A= translation and with non UDP transport. We need to conclude on these=0A= before we go to IETF last call.=0A= =0A= My Review comments are:=0A= =0A= A. Section 1: "The client can arrange=0A= for the server to relay packets to and from certain other hosts=0A= (called peers) and can control aspects of how the relaying is done."=0A= =0A= I don't think this is an accurate description of what Turn does. One may=0A= easily get the impression that the whole packet TURN receives are=0A= relayed, rather than the transport protocol data part and some of the=0A= header information are relayed between the client <-> peer, with a=0A= knowledge of the peer transport address for the client. I think that=0A= should be clarified in the introduction.=0A= =0A= B. Section 2.7:=0A= =0A= "Applications using TCP can more or less=0A= ignore this issue because fragmentation avoidance is now a standard=0A= part of TCP, but applications using UDP (and thus any application=0A= using this version of TURN) must handle fragmentation avoidance=0A= themselves."=0A= =0A= Lower case "must", and as the document uses RFC 2119, this must have the=0A= meaning of "MUST". A reformulation here is likely in order.=0A= =0A= C. Section 2.7:=0A= =0A= In this approach, the application exploits the=0A= fact that the IP specification [RFC0791] specifies that IP packets up=0A= to 576 bytes should never need to be fragmented.=0A= =0A= As a guideline, sending a maximum of 500 bytes of application data in=0A= a single TURN message (by the client on the client-to-server leg) or=0A= a UDP datagram (by the peer on the peer-to-server leg) will generally=0A= avoid IP fragmentation. To further reduce the chance of=0A= fragmentation, it is recommended that the client use ChannelData=0A= messages when transferring significant volumes of data, since the=0A= overhead of the ChannelData message is less than Send and Data=0A= indications.=0A= =0A= In that first paragraph I think it is worth discussing the IPv6=0A= requirement of supporting a 1280 minimal size.=0A= =0A= Secondly, I think recommending only a 500 MTU is way to conservative.=0A= Those studies I have seen appears to indicate that at least 1220 bytes=0A= UDP payloads should be be working as well as 500 bytes. See for example=0A= figure 12 in this:=0A= https://static.googleusercontent.com/media/research.google.com/sv//pubs/arc= hive/46403.pdf=0A= =0A= =0A= D. Section 2.7:=0A= =0A= [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that=0A= uses STUN to discover the path MTU, and so might be a suitable=0A= approach to be used in conjunction with a TURN server that supports=0A= the DONT-FRAGMENT attribute. When the client includes the DONT-=0A= FRAGMENT attribute in a Send indication, this tells the server to set=0A= the DF bit in the resulting UDP datagram that it sends to the peer.=0A= Since some servers may be unable to set the DF bit, the client should=0A= also include this attribute in the Allocate request -- any server=0A= that does not support the DONT-FRAGMENT attribute will indicate this=0A= by rejecting the Allocate request.=0A= =0A= I want to verify that the WG is working on resolving the issues with the=0A= STUN PMTUD document. I definitely sees the point of the recommendation,=0A= but only if the WG will conclude on that document in a reasonable time=0A= frame.=0A= =0A= E. Section 3:=0A= =0A= Server-Reflexive Transport Address: A transport address on the=0A= "public side" of a NAT. This address is allocated by the NAT to=0A= correspond to a specific host transport address.=0A= =0A= Shouldn't "public side" be replace with "external side"? That is the=0A= terminology used by the Behave RFCs.=0A= =0A= F. Section 3:=0A= =0A= 5-tuple: The combination (client IP address and port, server IP=0A= address and port, and transport protocol (currently one of UDP,=0A= TCP, or (D)TLS)) used to communicate between the client and the=0A= server.=0A= =0A= I see some issues that the 5-tuple aggregates the transport protocol=0A= with the security protocol. I agree from the TURN protocol perspective=0A= the protocol combination is the important one. However, writing like you=0A= do here you obfuscate both that when security is in place you have a=0A= combination, as well as that there are 4 alternatives defined by this=0A= document.=0A= =0A= G. Section 4.1:=0A= =0A= The "turn" and "turns" URI schemes are used to designate a TURN=0A= server (also known as a relay) on Internet hosts accessible using the=0A= TURN protocol. The TURN protocol supports sending messages over UDP,=0A= TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be=0A= used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the=0A= "turn" scheme MUST be used otherwise. The required part of=0A= the "turn" URI denotes the TURN server host. The part, if=0A= present, denotes the port on which the TURN server is awaiting=0A= connection requests. If it is absent, the default port is 3478 for=0A= both UDP and TCP. The default port for TURN over TLS and TURN over=0A= DTLS is 5349.=0A= =0A= First, I was wondering if this document needed to update RFC 7065? The=0A= high level obvious is the reference, but otherwise on the surface it=0A= doesn't look necessary. My main complaint when reading was that it was=0A= not obvious what not specifying the transport parameter means. Then I=0A= saw this in Section 3.1 of RFC 7065:=0A= =0A= The , , and components are passed without=0A= modification to the [RFC5928] algorithm. is set to false if=0A= is equal to "turn", and set to true if is equal to=0A= "turns" and passed to the [RFC5928] algorithm with the other=0A= components.=0A= =0A= After some digging I figured out that RFC5928 is actually updated by RFC=0A= 7350 that defines the resolution and SRV records for DTLS.=0A= =0A= Can you please update the text in Section 4 to also reference RFC 7350=0A= so that one doesn't miss this definitions.=0A= =0A= H. Section 5:=0A= =0A= If the server requires requests to be=0A= authenticated, then the server's administrator MUST choose a realm=0A= value that will uniquely identify the username and password=0A= combination that the client must use, even if the client uses=0A= multiple servers under different administrations.=0A= =0A= Just to verify, TURN does not allow a single server address to host=0A= multiple realms do it? Each Realm needs its own unique server transport=0A= address?=0A= =0A= I. Section 5:=0A= =0A= For each Allocate request, the server SHOULD generate a=0A= new random nonce when the allocation is first attempted following the=0A= randomness recommendations in [RFC4086] and SHOULD expire the nonce=0A= at least once every hour during the lifetime of the allocation.=0A= =0A= So, I think this text due to its use of RFC 2119 language is a bit=0A= confusing in its relation to STUNbis. To me it is unclear if the above=0A= overrides completely what is written in Section 5 of STUNbis:=0A= =0A= To indicate that it supports this specification, a server MUST=0A= prepend the NONCE attribute value with the character string composed=0A= of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]=0A= encoding of the 24 bit STUN Security Features as defined in=0A= Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes,=0A= with bit 0 as the most significant bit of the first byte and bit 23=0A= as the least significant bit of the third byte. If no security=0A= features are used, then a byte array with all 24 bits set to zero=0A= MUST be encoded instead. For the remainder of this document the term=0A= "nonce cookie" will refer to the complete 13 character string=0A= prepended to the NONCE attribute value.=0A= =0A= Or is the randomness recommendations in TURNbis only for the NONCE=0A= attribute value part?=0A= =0A= Secondly, I interpret the text to say that compared to STUN, where a=0A= Nonce can be long lived after the initial Long Term Credential=0A= establishment, in TURN for each allocation one will have to to the=0A= Allocate, expired nonce->here is your new nonce, resend allocate using=0A= new nonce, success dance.=0A= =0A= I think part of the problem with the above text in TURNbis is that the=0A= sentences prior to the quoted one appear to be rehashing of the STUNbis=0A= requirements. Then the quoted part that actually changes behavior=0A= without being clear about it. I think it would be good to make it clear=0A= what is a change compared to STUNbis.=0A= =0A= J. Section 6:=0A= =0A= Note that, rather than storing the password explicitly, for=0A= security reasons, it may be desirable for the server to store the key=0A= value, which is a secure hash over the username, realm, and password=0A= (see [I-D.ietf-tram-stunbis]).=0A= =0A= Why isn't this recommendation stronger. Are there any reasons why a=0A= server would actually store the plain text password at all?=0A= =0A= K. Section 7.1:=0A= =0A= The client first picks a host transport address. It is RECOMMENDED=0A= that the client pick a currently unused transport address, typically=0A= by allowing the underlying OS to pick a currently unused port for a=0A= new socket.=0A= =0A= I think talk about socket in this context should be skipped as it=0A= otherwise have been eliminated.=0A= =0A= L. Section 7.1:=0A= =0A= The client then picks a transport protocol to use between the client=0A= and the server. The transport protocol MUST be one of UDP, TCP, TLS-=0A= over-TCP or DTLS-over-UDP.=0A= =0A= I find it strange that this indicates that one should pick the transport=0A= protocol to use client to server without considering the server=0A= capabilities. Especially as the client configuration or server discovery=0A= procedures will indicate transport protocol support.=0A= =0A= Secondly, what is the motivation for the MUST in the second sentence?=0A= This is appears to have strange interactions with any future extensions=0A= and have no impact. A client must obvious chose a client to server=0A= transport protocol it supports, and one that the server supports or the=0A= client hope it will support.=0A= =0A= M. Section 7.1:=0A= =0A= The client also picks a server transport address, which SHOULD be=0A= done as follows. The client uses one or more procedures described in=0A= [RFC8155] to discover a TURN server and uses the TURN server=0A= resolution mechanism defined in [RFC5928] to get a list of server=0A= transport addresses that can be tried to create a TURN allocation.=0A= =0A= 1) So RFC 8155 states that it has no recommendation on server selection,=0A= nor on how to related local configuration to any auto-discovery servers.=0A= To me it appears that the protocol utilizing TURN should consider what=0A= makes sense in their deployments. Thus, does the need for such=0A= consideration needs to be highlighted somewhere in this specification.=0A= =0A= 2) The RFC5928 reference should be complemented with an RFC 7350=0A= reference.=0A= =0A= N. Section 7.1:=0A= =0A= Clients MUST NOT include a REQUESTED-ADDRESS-=0A= FAMILY attribute in an Allocate request that contains a RESERVATION-=0A= TOKEN attribute, for the reasons outlined in [RFC6156].=0A= =0A= Considering that this document obsoletes RFC 6156, I think it is bad=0A= form to reference that document, rather than to move the necessary=0A= motivation into this document.=0A= =0A= O. Section 7.1:=0A= =0A= If the client wishes to obtain a relayed transport address of a=0A= specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A= attribute in the request.=0A= =0A= I don't find anything describing what the default behavior is if one=0A= doesn't include the attribute, but the TURN server supports multiple=0A= address families.=0A= =0A= I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= Should the text in 7.1 be explicit about this default?=0A= =0A= P. Section 7.2:=0A= =0A= Otherwise, if the attribute is included but=0A= specifies a protocol other that UDP, the server rejects the=0A= request with a 442 (Unsupported Transport Protocol) error.=0A= =0A= Assuming that you don't support an extension for that transport=0A= protocol. Should that be made explicit?=0A= =0A= Q. Section 8.3:=0A= =0A= If the client receives a success response to its Refresh request with=0A= a non-zero lifetime, it updates its copy of the allocation data=0A= structure with the time-to-expiry value contained in the response.=0A= =0A= If the client receives a 437 (Allocation Mismatch) error response to=0A= a request to delete the allocation, then the allocation no longer=0A= exists and it should consider its request as having effectively=0A= succeeded.=0A= =0A= So there are no considerations for the client if it receives an error=0A= response to a refresh request when Lifetime was non-zero?=0A= =0A= I am bit surprised by that. I assume that there are certain cases when=0A= the request could be resent, and others where the meaning is that the=0A= allocation is gone.=0A= =0A= R. Section 11.5:=0A= =0A= When the server receives an ICMP packet, the server verifies that the=0A= type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either=0A= 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the=0A= IP packet in the ICMP packet payload contains a UDP header. If=0A= either of these conditions fail, then the ICMP packet is silently=0A= dropped.=0A= =0A= Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A= Problem are for ICMPv4?=0A= =0A= S. Section 12.5:=0A= =0A= Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to=0A= a multiple of four bytes in order to ensure the alignment of=0A= subsequent messages. The padding is not reflected in the length=0A= field of the ChannelData message, so the actual size of a ChannelData=0A= message (including padding) is (4 + Length) rounded up to the nearest=0A= multiple of 4. Over UDP, the padding is not required but MAY be=0A= included.=0A= =0A= Are there anywhere written what one may or may not include of the TURN=0A= related messages in a single UDP datagram. Because it is technically=0A= feasible I belive to include two Send Indications in one UDP datagram to=0A= the server.=0A= =0A= T. Section 13.1:=0A= =0A= Flow Label=0A= =0A= Preferred behavior: The relay sets the Flow label to 0. The relay=0A= can choose to set the Flow label to a different value if it=0A= supports the IPv6 Flow Label field [RFC6437].=0A= =0A= Alternate behavior: The relay sets the Flow label to the default=0A= value for outgoing packets.=0A= =0A= I think this section should be improved in two ways.=0A= =0A= First of all I think it should clarify that each allocation to peer flow=0A= is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= =0A= Secondly, I think in the spirit of RFC 6473 the preferred behavior=0A= should be to set the IPv6 flow label if the implementation is capable,=0A= or leave it to the underlying network stack to actually set it. Compared=0A= to RFC 7915, the TURN server actually have an understanding of what are=0A= different flows without having examining additional protocol layers.=0A= =0A= Thirdly, I don't understand what the alternative behavior actually is.=0A= This as it is either setting it to 0, or classifying things as flow and=0A= then provide it with a random flow label. I think the right alternative=0A= behavior is to set it 0.=0A= =0A= U. Section 13. 1,2,3:=0A= =0A= For both preferred and alternate behavior, the DONT-FRAGMENT=0A= attribute MUST be ignored by the server.=0A= =0A= I don't understand why just because one performs v4<->v6 or v6 to v4=0A= translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= attribute. If the client has request to not fragment and the server is=0A= unable to do that when forwarding to the peer it needs to generate an=0A= ICMP attribute response saying the packet is to big. Otherwise the relay=0A= breaks the Path MTU discovery mechanisms.=0A= =0A= V. Section 13.2:=0A= =0A= Fragmentation:=0A= =0A= If the incoming packet included a Fragment header and the outgoing=0A= packet size exceeds the outgoing link's MTU, the relay MUST=0A= fragment the outgoing packet into fragments of no more than 1280=0A= bytes. The relay sets the fields of the Fragment header as=0A= appropriate for a packet originating from the server.=0A= =0A= Is really the intention here to refragment the packet without providing=0A= any indication that the practical MTU is smaller than what the peer or=0A= client thinks it is?=0A= =0A= W. Section 14:=0A= =0A= Preferred Behavior: Set the outgoing value to the incoming value,=0A= UNLESS the server is doing Active Queue Management, the incoming=0A= ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server=0A= wishes to indicate that congestion has been experienced, in which=0A= case set the outgoing value to CE (=3D0b11).=0A= =0A= First of all do you have any special meaning with all capital UNLESS?=0A= =0A= Secondly, I don't know how wise it is to have partial definitions of=0A= what the ECN behavior is. Maybe simpler to say that that the relay is=0A= performing AQM it can support the ECN marking behavior as defined in RFC=0A= 3168.=0A= =0A= X. Section 14:=0A= =0A= How are these IP level fields handled when the transport is TCP or=0A= TLS/TCP? There there are not necessary a one to one mapping between=0A= datagrams and TCP packets. And if there are no support then there are=0A= need for clarification of behaviors when using TCP based transport.=0A= =0A= Y. Section 16.4. DATA=0A= =0A= The DATA attribute is present in all Send and Data indications. The=0A= value portion of this attribute is variable length and consists of=0A= the application data (that is, the data that would immediately follow=0A= the UDP header if the data was been sent directly between the client=0A= and the peer). If the length of this attribute is not a multiple of=0A= 4, then padding must be added after this attribute.=0A= =0A= Can you please clarify if one would get all the remaining bytes of the=0A= IP packet payload or only the number of bytes the UDP length field=0A= indiactes?=0A= =0A= The reason I ask is that there is possibility that there are a=0A= discrepancy between these fields, something the proposal for an=0A= experimental specification for UDP options attempt to utilize.=0A= https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= =0A= Note, I only want you to clarify what is actually included. I would=0A= assume using the UDP length field makes sense in this case.=0A= =0A= Z. The use of "relay" in the meaning of "Turn Server". There are many=0A= occurrences of relay in this meaning. Either make it explicit to be a=0A= synonym or change it to server.=0A= =0A= AA. Section 16.7=0A= =0A= rffu is lacking a definition. I would suggest making it upper case and=0A= copy the definition from 16.8.=0A= =0A= AB. Section 16.12:=0A= =0A= Rsvd in Format figure does not match definition below which uses "Reserved"= .=0A= =0A= AC. Section 16.12:=0A= =0A= Reason Phrase (variable). This field is under defined. First of all the=0A= format of the text string is not defined, which it is in Stunbis=0A= Error-Code attribute is defined as.=0A= =0A= The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= sequence of less than 128 characters (which can be as long as 509=0A= bytes when encoding them or 763 bytes when decoding them).=0A= =0A= Secondly, I think it might be worth pointing out the padding here. It is=0A= not clear if there is any form of string termination and how the padding=0A= which will be interpreted as NULL characters 0-3 depending on the=0A= alignment. I note this later issue appears to be existing in STUNBis also.= =0A= =0A= AD. Section 16.2:=0A= =0A= Why isn't the text here say that this attribute may also be used to=0A= indicate the desired lifetime in allocation requests?=0A= =0A= AE. Section 16.9: DONT-FRAGMENT=0A= =0A= I think it would be good to indicate the use of the attribute in=0A= Allocate Requests also.=0A= =0A= AF. Section 24.2=0A= =0A= [Protocol-Numbers]=0A= "IANA Protocol Numbers Registry", 2005,=0A= .=0A= =0A= This is a normative reference based on how it is used in Section 16.8.=0A= =0A= AG. Seciton 18.=0A= =0A= Sometime before the 20 minute lifetime is up, the client refreshes=0A= the allocation. This is done using a Refresh request. As before,=0A= the client includes the latest username, realm, and nonce values in=0A= the request. The client also includes the SOFTWARE attribute,=0A= following the recommended practice of always including this attribute=0A= in Allocate and Refresh messages. When the server receives the=0A= Refresh request, it notices that the nonce value has expired, and so=0A= replies with 438 (Stale Nonce) error given a new nonce value. The=0A= client then reattempts the request, this time with the new nonce=0A= value. This second attempt is accepted, and the server replies with=0A= a success response. Note that the client did not include a LIFETIME=0A= attribute in the request, so the server refreshes the allocation for=0A= the default lifetime of 10 minutes (as can be seen by the LIFETIME=0A= attribute in the success response).=0A= =0A= I notice that this part nor the text before appears to discuss the=0A= permission lifetime that will expire after 5 minutes. Thus, it needs to=0A= be refreshed prior to the Allocation.=0A= =0A= AH. Section 18.=0A= =0A= I am missing any example having to do with Address Family interactions.=0A= =0A= AI. DTLS Cipher Suits=0A= =0A= Am I understanding it correct that the definition of what DTLS cipher=0A= suit that a TURN Server currently is to support is the ones in RFC 7525?=0A= =0A= In that case, I think the wording is a bit weak as the only reference I=0A= find are in Section 2.1:=0A= =0A= If (D)TLS transport is=0A= used between the TURN client and the TURN server, the guidance given=0A= in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= =0A= =0A= Cheers=0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Fri Apr 5 01:11:50 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74812038D; Fri, 5 Apr 2019 01:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_H-IMLJZQie; Fri, 5 Apr 2019 01:11:42 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20066.outbound.protection.outlook.com [40.107.2.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B7A120350; Fri, 5 Apr 2019 01:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rYRyaT3VJvmkSqr0go2bEzb/A9PkszpPE031JRV8tx8=; b=Ddige9YWoBWXopMT774NExTRFmvF1cRvW5OTD9kPOQOLSBfV/iVCgcC+6WSqwcg5bgV7VqZ7Bq4YEFpcxHPY3POmmZSOkAlyLffFenk+r2H+qBHgFGRxfXU9qFioxL2224JEXWY03oHk/2oeo42Xzvbcr8womdcGyHPuH30Q8YQ= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2490.eurprd07.prod.outlook.com (10.168.126.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.6; Fri, 5 Apr 2019 08:11:38 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1771.006; Fri, 5 Apr 2019 08:11:38 +0000 From: Magnus Westerlund To: "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Fri, 5 Apr 2019 08:11:38 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 00053d9c-ab52-45a1-6c3b-08d6b99e542c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2490; x-ms-traffictypediagnostic: HE1PR0701MB2490: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(136003)(396003)(51444003)(199004)(189003)(55016002)(966005)(74316002)(14444005)(3846002)(2501003)(7736002)(71190400001)(14454004)(450100002)(5660300002)(6436002)(81156014)(10750500005)(66066001)(68736007)(446003)(476003)(53946003)(478600001)(18074004)(6246003)(26005)(8676002)(33656002)(52536014)(2906002)(53546011)(6506007)(186003)(97736004)(44832011)(71200400001)(486006)(30864003)(105586002)(256004)(316002)(66574012)(229853002)(305945005)(110136005)(81166006)(6116002)(9686003)(25786009)(53936002)(86362001)(102836004)(76176011)(8936002)(6306002)(106356001)(561944003)(99286004)(7696005)(151285002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2490; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Csi4BiVTriSk7qE2+6CZtNcAbjbmI0kwz+ugUJ47cysLEZ4TNap7GYZy22UVmDSZd/8ptJseO2DOQzpyRlu7UPHFkuPwrwHX0RflANrwik2kRuUZtRnCGP4P6fAuu+4brBkREDIrZgyi4xzQx0uVNOjLJJLSZ62aB92u+tTDb9rVig1z26vEXQsI1gLbYOz6Tr7pijbhg4qDuzBBKwMA7Yza6kLlycj1JEJLfyQWkcY6zFbnVsnbxtcSr0x0LEN7zN6zjlaeVQGEFt5q+2Vo3/3HjhsXunCzL9m6wJaf/SmytgpVO6DVf3O8MQOMaoyJeo2yfzWwr5c2SFrErDhW/I1kAmsMtINPmBwkxPK70L3QsxznSxwfZafi0/XKBD+Ns8A46ISVVT4NCfN0Ebd7S5ePF/AYi+P4r5JVqRneTq8= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00053d9c-ab52-45a1-6c3b-08d6b99e542c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 08:11:38.5891 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2490 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 08:11:47 -0000 Hi,=0A= =0A= One addition.=0A= =0A= Section 16.13. ICMP Attribute=0A= =0A= This attribute is flawed as it lacks a data part to carry values certain=0A= codes have. I specifically think of ICMPv6 Type =3D 2, Packet Too Big.=0A= That message has a 32-bit unsigned integer carrying the MTU of the Next=0A= Hop Link that causes the ICMP message to be sent. That really should be=0A= replicated back to the client.=0A= =0A= There is also the question if ICMP messages for Parameter Problem should=0A= included the pointer?=0A= =0A= I really think there need to be a 32-bit data field with the ICMP=0A= attribute.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= =0A= On 2019-04-04 16:00, Magnus Westerlund wrote:=0A= > Hi,=0A= >=0A= > I have now finished the AD review. There are a lot of details that I=0A= > think needs fixing or at least feedback on. I also think there are a=0A= > couple of more serious issues here. Especially regarding the handling of= =0A= > MTU and fragmentation, as well as IP header fields in address family=0A= > translation and with non UDP transport. We need to conclude on these=0A= > before we go to IETF last call.=0A= >=0A= > My Review comments are:=0A= >=0A= > A. Section 1: "The client can arrange=0A= > for the server to relay packets to and from certain other hosts=0A= > (called peers) and can control aspects of how the relaying is done."= =0A= >=0A= > I don't think this is an accurate description of what Turn does. One may= =0A= > easily get the impression that the whole packet TURN receives are=0A= > relayed, rather than the transport protocol data part and some of the=0A= > header information are relayed between the client <-> peer, with a=0A= > knowledge of the peer transport address for the client. I think that=0A= > should be clarified in the introduction.=0A= >=0A= > B. Section 2.7:=0A= >=0A= > "Applications using TCP can more or less=0A= > ignore this issue because fragmentation avoidance is now a standard=0A= > part of TCP, but applications using UDP (and thus any application=0A= > using this version of TURN) must handle fragmentation avoidance=0A= > themselves."=0A= >=0A= > Lower case "must", and as the document uses RFC 2119, this must have the= =0A= > meaning of "MUST". A reformulation here is likely in order.=0A= >=0A= > C. Section 2.7:=0A= >=0A= > In this approach, the application exploits the=0A= > fact that the IP specification [RFC0791] specifies that IP packets up= =0A= > to 576 bytes should never need to be fragmented.=0A= >=0A= > As a guideline, sending a maximum of 500 bytes of application data in= =0A= > a single TURN message (by the client on the client-to-server leg) or= =0A= > a UDP datagram (by the peer on the peer-to-server leg) will generally= =0A= > avoid IP fragmentation. To further reduce the chance of=0A= > fragmentation, it is recommended that the client use ChannelData=0A= > messages when transferring significant volumes of data, since the=0A= > overhead of the ChannelData message is less than Send and Data=0A= > indications.=0A= >=0A= > In that first paragraph I think it is worth discussing the IPv6=0A= > requirement of supporting a 1280 minimal size.=0A= >=0A= > Secondly, I think recommending only a 500 MTU is way to conservative.=0A= > Those studies I have seen appears to indicate that at least 1220 bytes=0A= > UDP payloads should be be working as well as 500 bytes. See for example= =0A= > figure 12 in this:=0A= > https://static.googleusercontent.com/media/research.google.com/sv//pubs/a= rchive/46403.pdf=0A= >=0A= >=0A= > D. Section 2.7:=0A= >=0A= > [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that=0A= > uses STUN to discover the path MTU, and so might be a suitable=0A= > approach to be used in conjunction with a TURN server that supports=0A= > the DONT-FRAGMENT attribute. When the client includes the DONT-=0A= > FRAGMENT attribute in a Send indication, this tells the server to set= =0A= > the DF bit in the resulting UDP datagram that it sends to the peer.=0A= > Since some servers may be unable to set the DF bit, the client should= =0A= > also include this attribute in the Allocate request -- any server=0A= > that does not support the DONT-FRAGMENT attribute will indicate this= =0A= > by rejecting the Allocate request.=0A= >=0A= > I want to verify that the WG is working on resolving the issues with the= =0A= > STUN PMTUD document. I definitely sees the point of the recommendation,= =0A= > but only if the WG will conclude on that document in a reasonable time=0A= > frame.=0A= >=0A= > E. Section 3:=0A= >=0A= > Server-Reflexive Transport Address: A transport address on the=0A= > "public side" of a NAT. This address is allocated by the NAT to=0A= > correspond to a specific host transport address.=0A= >=0A= > Shouldn't "public side" be replace with "external side"? That is the=0A= > terminology used by the Behave RFCs.=0A= >=0A= > F. Section 3:=0A= >=0A= > 5-tuple: The combination (client IP address and port, server IP=0A= > address and port, and transport protocol (currently one of UDP,=0A= > TCP, or (D)TLS)) used to communicate between the client and the=0A= > server.=0A= >=0A= > I see some issues that the 5-tuple aggregates the transport protocol=0A= > with the security protocol. I agree from the TURN protocol perspective=0A= > the protocol combination is the important one. However, writing like you= =0A= > do here you obfuscate both that when security is in place you have a=0A= > combination, as well as that there are 4 alternatives defined by this=0A= > document.=0A= >=0A= > G. Section 4.1:=0A= >=0A= > The "turn" and "turns" URI schemes are used to designate a TURN=0A= > server (also known as a relay) on Internet hosts accessible using the= =0A= > TURN protocol. The TURN protocol supports sending messages over UDP,= =0A= > TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be=0A= > used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the= =0A= > "turn" scheme MUST be used otherwise. The required part of=0A= > the "turn" URI denotes the TURN server host. The part, if=0A= > present, denotes the port on which the TURN server is awaiting=0A= > connection requests. If it is absent, the default port is 3478 for=0A= > both UDP and TCP. The default port for TURN over TLS and TURN over=0A= > DTLS is 5349.=0A= >=0A= > First, I was wondering if this document needed to update RFC 7065? The=0A= > high level obvious is the reference, but otherwise on the surface it=0A= > doesn't look necessary. My main complaint when reading was that it was=0A= > not obvious what not specifying the transport parameter means. Then I=0A= > saw this in Section 3.1 of RFC 7065:=0A= >=0A= > The , , and components are passed without=0A= > modification to the [RFC5928] algorithm. is set to false if= =0A= > is equal to "turn", and set to true if is equal to= =0A= > "turns" and passed to the [RFC5928] algorithm with the other=0A= > components.=0A= >=0A= > After some digging I figured out that RFC5928 is actually updated by RFC= =0A= > 7350 that defines the resolution and SRV records for DTLS.=0A= >=0A= > Can you please update the text in Section 4 to also reference RFC 7350=0A= > so that one doesn't miss this definitions.=0A= >=0A= > H. Section 5:=0A= >=0A= > If the server requires requests to be=0A= > authenticated, then the server's administrator MUST choose a realm=0A= > value that will uniquely identify the username and password=0A= > combination that the client must use, even if the client uses=0A= > multiple servers under different administrations.=0A= >=0A= > Just to verify, TURN does not allow a single server address to host=0A= > multiple realms do it? Each Realm needs its own unique server transport= =0A= > address?=0A= >=0A= > I. Section 5:=0A= >=0A= > For each Allocate request, the server SHOULD generate a=0A= > new random nonce when the allocation is first attempted following the= =0A= > randomness recommendations in [RFC4086] and SHOULD expire the nonce=0A= > at least once every hour during the lifetime of the allocation.=0A= >=0A= > So, I think this text due to its use of RFC 2119 language is a bit=0A= > confusing in its relation to STUNbis. To me it is unclear if the above=0A= > overrides completely what is written in Section 5 of STUNbis:=0A= >=0A= > To indicate that it supports this specification, a server MUST=0A= > prepend the NONCE attribute value with the character string composed= =0A= > of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]=0A= > encoding of the 24 bit STUN Security Features as defined in=0A= > Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes,= =0A= > with bit 0 as the most significant bit of the first byte and bit 23=0A= > as the least significant bit of the third byte. If no security=0A= > features are used, then a byte array with all 24 bits set to zero=0A= > MUST be encoded instead. For the remainder of this document the term= =0A= > "nonce cookie" will refer to the complete 13 character string=0A= > prepended to the NONCE attribute value.=0A= >=0A= > Or is the randomness recommendations in TURNbis only for the NONCE=0A= > attribute value part?=0A= >=0A= > Secondly, I interpret the text to say that compared to STUN, where a=0A= > Nonce can be long lived after the initial Long Term Credential=0A= > establishment, in TURN for each allocation one will have to to the=0A= > Allocate, expired nonce->here is your new nonce, resend allocate using=0A= > new nonce, success dance.=0A= >=0A= > I think part of the problem with the above text in TURNbis is that the=0A= > sentences prior to the quoted one appear to be rehashing of the STUNbis= =0A= > requirements. Then the quoted part that actually changes behavior=0A= > without being clear about it. I think it would be good to make it clear= =0A= > what is a change compared to STUNbis.=0A= >=0A= > J. Section 6:=0A= >=0A= > Note that, rather than storing the password explicitly, for=0A= > security reasons, it may be desirable for the server to store the key= =0A= > value, which is a secure hash over the username, realm, and password= =0A= > (see [I-D.ietf-tram-stunbis]).=0A= >=0A= > Why isn't this recommendation stronger. Are there any reasons why a=0A= > server would actually store the plain text password at all?=0A= >=0A= > K. Section 7.1:=0A= >=0A= > The client first picks a host transport address. It is RECOMMENDED=0A= > that the client pick a currently unused transport address, typically= =0A= > by allowing the underlying OS to pick a currently unused port for a=0A= > new socket.=0A= >=0A= > I think talk about socket in this context should be skipped as it=0A= > otherwise have been eliminated.=0A= >=0A= > L. Section 7.1:=0A= >=0A= > The client then picks a transport protocol to use between the client=0A= > and the server. The transport protocol MUST be one of UDP, TCP, TLS-= =0A= > over-TCP or DTLS-over-UDP.=0A= >=0A= > I find it strange that this indicates that one should pick the transport= =0A= > protocol to use client to server without considering the server=0A= > capabilities. Especially as the client configuration or server discovery= =0A= > procedures will indicate transport protocol support.=0A= >=0A= > Secondly, what is the motivation for the MUST in the second sentence?=0A= > This is appears to have strange interactions with any future extensions= =0A= > and have no impact. A client must obvious chose a client to server=0A= > transport protocol it supports, and one that the server supports or the= =0A= > client hope it will support.=0A= >=0A= > M. Section 7.1:=0A= >=0A= > The client also picks a server transport address, which SHOULD be=0A= > done as follows. The client uses one or more procedures described in= =0A= > [RFC8155] to discover a TURN server and uses the TURN server=0A= > resolution mechanism defined in [RFC5928] to get a list of server=0A= > transport addresses that can be tried to create a TURN allocation.=0A= >=0A= > 1) So RFC 8155 states that it has no recommendation on server selection,= =0A= > nor on how to related local configuration to any auto-discovery servers.= =0A= > To me it appears that the protocol utilizing TURN should consider what=0A= > makes sense in their deployments. Thus, does the need for such=0A= > consideration needs to be highlighted somewhere in this specification.=0A= >=0A= > 2) The RFC5928 reference should be complemented with an RFC 7350=0A= > reference.=0A= >=0A= > N. Section 7.1:=0A= >=0A= > Clients MUST NOT include a REQUESTED-ADDRESS-=0A= > FAMILY attribute in an Allocate request that contains a RESERVATION-= =0A= > TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >=0A= > Considering that this document obsoletes RFC 6156, I think it is bad=0A= > form to reference that document, rather than to move the necessary=0A= > motivation into this document.=0A= >=0A= > O. Section 7.1:=0A= >=0A= > If the client wishes to obtain a relayed transport address of a=0A= > specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A= > attribute in the request.=0A= >=0A= > I don't find anything describing what the default behavior is if one=0A= > doesn't include the attribute, but the TURN server supports multiple=0A= > address families.=0A= >=0A= > I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= > Should the text in 7.1 be explicit about this default?=0A= >=0A= > P. Section 7.2:=0A= >=0A= > Otherwise, if the attribute is included but=0A= > specifies a protocol other that UDP, the server rejects the=0A= > request with a 442 (Unsupported Transport Protocol) error.=0A= >=0A= > Assuming that you don't support an extension for that transport=0A= > protocol. Should that be made explicit?=0A= >=0A= > Q. Section 8.3:=0A= >=0A= > If the client receives a success response to its Refresh request with= =0A= > a non-zero lifetime, it updates its copy of the allocation data=0A= > structure with the time-to-expiry value contained in the response.=0A= >=0A= > If the client receives a 437 (Allocation Mismatch) error response to= =0A= > a request to delete the allocation, then the allocation no longer=0A= > exists and it should consider its request as having effectively=0A= > succeeded.=0A= >=0A= > So there are no considerations for the client if it receives an error=0A= > response to a refresh request when Lifetime was non-zero?=0A= >=0A= > I am bit surprised by that. I assume that there are certain cases when=0A= > the request could be resent, and others where the meaning is that the=0A= > allocation is gone.=0A= >=0A= > R. Section 11.5:=0A= >=0A= > When the server receives an ICMP packet, the server verifies that the= =0A= > type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either=0A= > 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the= =0A= > IP packet in the ICMP packet payload contains a UDP header. If=0A= > either of these conditions fail, then the ICMP packet is silently=0A= > dropped.=0A= >=0A= > Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A= > Problem are for ICMPv4?=0A= >=0A= > S. Section 12.5:=0A= >=0A= > Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to= =0A= > a multiple of four bytes in order to ensure the alignment of=0A= > subsequent messages. The padding is not reflected in the length=0A= > field of the ChannelData message, so the actual size of a ChannelData= =0A= > message (including padding) is (4 + Length) rounded up to the nearest= =0A= > multiple of 4. Over UDP, the padding is not required but MAY be=0A= > included.=0A= >=0A= > Are there anywhere written what one may or may not include of the TURN=0A= > related messages in a single UDP datagram. Because it is technically=0A= > feasible I belive to include two Send Indications in one UDP datagram to= =0A= > the server.=0A= >=0A= > T. Section 13.1:=0A= >=0A= > Flow Label=0A= >=0A= > Preferred behavior: The relay sets the Flow label to 0. The relay= =0A= > can choose to set the Flow label to a different value if it=0A= > supports the IPv6 Flow Label field [RFC6437].=0A= >=0A= > Alternate behavior: The relay sets the Flow label to the default=0A= > value for outgoing packets.=0A= >=0A= > I think this section should be improved in two ways.=0A= >=0A= > First of all I think it should clarify that each allocation to peer flow= =0A= > is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= >=0A= > Secondly, I think in the spirit of RFC 6473 the preferred behavior=0A= > should be to set the IPv6 flow label if the implementation is capable,=0A= > or leave it to the underlying network stack to actually set it. Compared= =0A= > to RFC 7915, the TURN server actually have an understanding of what are= =0A= > different flows without having examining additional protocol layers.=0A= >=0A= > Thirdly, I don't understand what the alternative behavior actually is.=0A= > This as it is either setting it to 0, or classifying things as flow and= =0A= > then provide it with a random flow label. I think the right alternative= =0A= > behavior is to set it 0.=0A= >=0A= > U. Section 13. 1,2,3:=0A= >=0A= > For both preferred and alternate behavior, the DONT-FRAGMENT=0A= > attribute MUST be ignored by the server.=0A= >=0A= > I don't understand why just because one performs v4<->v6 or v6 to v4=0A= > translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= > attribute. If the client has request to not fragment and the server is=0A= > unable to do that when forwarding to the peer it needs to generate an=0A= > ICMP attribute response saying the packet is to big. Otherwise the relay= =0A= > breaks the Path MTU discovery mechanisms.=0A= >=0A= > V. Section 13.2:=0A= >=0A= > Fragmentation:=0A= >=0A= > If the incoming packet included a Fragment header and the outgoing= =0A= > packet size exceeds the outgoing link's MTU, the relay MUST=0A= > fragment the outgoing packet into fragments of no more than 1280=0A= > bytes. The relay sets the fields of the Fragment header as=0A= > appropriate for a packet originating from the server.=0A= >=0A= > Is really the intention here to refragment the packet without providing= =0A= > any indication that the practical MTU is smaller than what the peer or=0A= > client thinks it is?=0A= >=0A= > W. Section 14:=0A= >=0A= > Preferred Behavior: Set the outgoing value to the incoming value,= =0A= > UNLESS the server is doing Active Queue Management, the incoming=0A= > ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server= =0A= > wishes to indicate that congestion has been experienced, in which= =0A= > case set the outgoing value to CE (=3D0b11).=0A= >=0A= > First of all do you have any special meaning with all capital UNLESS?=0A= >=0A= > Secondly, I don't know how wise it is to have partial definitions of=0A= > what the ECN behavior is. Maybe simpler to say that that the relay is=0A= > performing AQM it can support the ECN marking behavior as defined in RFC= =0A= > 3168.=0A= >=0A= > X. Section 14:=0A= >=0A= > How are these IP level fields handled when the transport is TCP or=0A= > TLS/TCP? There there are not necessary a one to one mapping between=0A= > datagrams and TCP packets. And if there are no support then there are=0A= > need for clarification of behaviors when using TCP based transport.=0A= >=0A= > Y. Section 16.4. DATA=0A= >=0A= > The DATA attribute is present in all Send and Data indications. The= =0A= > value portion of this attribute is variable length and consists of=0A= > the application data (that is, the data that would immediately follow= =0A= > the UDP header if the data was been sent directly between the client= =0A= > and the peer). If the length of this attribute is not a multiple of= =0A= > 4, then padding must be added after this attribute.=0A= >=0A= > Can you please clarify if one would get all the remaining bytes of the=0A= > IP packet payload or only the number of bytes the UDP length field=0A= > indiactes?=0A= >=0A= > The reason I ask is that there is possibility that there are a=0A= > discrepancy between these fields, something the proposal for an=0A= > experimental specification for UDP options attempt to utilize.=0A= > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >=0A= > Note, I only want you to clarify what is actually included. I would=0A= > assume using the UDP length field makes sense in this case.=0A= >=0A= > Z. The use of "relay" in the meaning of "Turn Server". There are many=0A= > occurrences of relay in this meaning. Either make it explicit to be a=0A= > synonym or change it to server.=0A= >=0A= > AA. Section 16.7=0A= >=0A= > rffu is lacking a definition. I would suggest making it upper case and=0A= > copy the definition from 16.8.=0A= >=0A= > AB. Section 16.12:=0A= >=0A= > Rsvd in Format figure does not match definition below which uses "Reserve= d".=0A= >=0A= > AC. Section 16.12:=0A= >=0A= > Reason Phrase (variable). This field is under defined. First of all the= =0A= > format of the text string is not defined, which it is in Stunbis=0A= > Error-Code attribute is defined as.=0A= >=0A= > The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= > sequence of less than 128 characters (which can be as long as 509=0A= > bytes when encoding them or 763 bytes when decoding them).=0A= >=0A= > Secondly, I think it might be worth pointing out the padding here. It is= =0A= > not clear if there is any form of string termination and how the padding= =0A= > which will be interpreted as NULL characters 0-3 depending on the=0A= > alignment. I note this later issue appears to be existing in STUNBis also= .=0A= >=0A= > AD. Section 16.2:=0A= >=0A= > Why isn't the text here say that this attribute may also be used to=0A= > indicate the desired lifetime in allocation requests?=0A= >=0A= > AE. Section 16.9: DONT-FRAGMENT=0A= >=0A= > I think it would be good to indicate the use of the attribute in=0A= > Allocate Requests also.=0A= >=0A= > AF. Section 24.2=0A= >=0A= > [Protocol-Numbers]=0A= > "IANA Protocol Numbers Registry", 2005,=0A= > .=0A= >=0A= > This is a normative reference based on how it is used in Section 16.8.=0A= >=0A= > AG. Seciton 18.=0A= >=0A= > Sometime before the 20 minute lifetime is up, the client refreshes=0A= > the allocation. This is done using a Refresh request. As before,=0A= > the client includes the latest username, realm, and nonce values in=0A= > the request. The client also includes the SOFTWARE attribute,=0A= > following the recommended practice of always including this attribute= =0A= > in Allocate and Refresh messages. When the server receives the=0A= > Refresh request, it notices that the nonce value has expired, and so= =0A= > replies with 438 (Stale Nonce) error given a new nonce value. The=0A= > client then reattempts the request, this time with the new nonce=0A= > value. This second attempt is accepted, and the server replies with= =0A= > a success response. Note that the client did not include a LIFETIME= =0A= > attribute in the request, so the server refreshes the allocation for= =0A= > the default lifetime of 10 minutes (as can be seen by the LIFETIME=0A= > attribute in the success response).=0A= >=0A= > I notice that this part nor the text before appears to discuss the=0A= > permission lifetime that will expire after 5 minutes. Thus, it needs to= =0A= > be refreshed prior to the Allocation.=0A= >=0A= > AH. Section 18.=0A= >=0A= > I am missing any example having to do with Address Family interactions.= =0A= >=0A= > AI. DTLS Cipher Suits=0A= >=0A= > Am I understanding it correct that the definition of what DTLS cipher=0A= > suit that a TURN Server currently is to support is the ones in RFC 7525?= =0A= >=0A= > In that case, I think the wording is a bit weak as the only reference I= =0A= > find are in Section 2.1:=0A= >=0A= > If (D)TLS transport is=0A= > used between the TURN client and the TURN server, the guidance given= =0A= > in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= >=0A= >=0A= > Cheers=0A= >=0A= > Magnus Westerlund =0A= >=0A= > ----------------------------------------------------------------------=0A= > Network Architecture & Protocols, Ericsson Research=0A= > ----------------------------------------------------------------------=0A= > Ericsson AB | Phone +46 10 7148287=0A= > Torshamnsgatan 23 | Mobile +46 73 0949079=0A= > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= > ----------------------------------------------------------------------=0A= >=0A= >=0A= > _______________________________________________=0A= > tram mailing list=0A= > tram@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/tram=0A= >=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Fri Apr 5 01:21:00 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535181201BE; Fri, 5 Apr 2019 01:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csvOrikc9fCQ; Fri, 5 Apr 2019 01:20:52 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20056.outbound.protection.outlook.com [40.107.2.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A830912038D; Fri, 5 Apr 2019 01:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HE+7eVqB+bWlruqAmKnrhvovGi6j5sBzlPGz5vlwGPg=; b=G8dKMuwhE1EoRTGxvDbmWP/Fgbminbjf328N115aqY4oIxlLp6uI3923h9a5TJ1zaY8ck7MEc2lxWqqOidbcwFc2HUsQXiRvB0yvzJqJljcJQenSJ0i5kdf/gi5mtZWoPh3a+SpElAlZa2cdTm6Dxuus5p/Cvsziu+IXOdF0gAU= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1PR0702MB3801.eurprd07.prod.outlook.com (52.133.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.8; Fri, 5 Apr 2019 08:20:48 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1792.007; Fri, 5 Apr 2019 08:20:48 +0000 From: Gonzalo Camarillo To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Fri, 5 Apr 2019 08:20:48 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 662a843d-f5cc-4460-f080-08d6b99f9bc6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0702MB3801; x-ms-traffictypediagnostic: HE1PR0702MB3801: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0998671D02 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(396003)(136003)(51444003)(199004)(189003)(51914003)(10750500005)(33656002)(186003)(76176011)(6506007)(66066001)(2201001)(446003)(14454004)(71200400001)(6116002)(71190400001)(102836004)(2906002)(476003)(53936002)(74316002)(7736002)(3846002)(26005)(68736007)(6246003)(450100002)(18074004)(7696005)(86362001)(256004)(305945005)(14444005)(53946003)(6436002)(44832011)(25786009)(6306002)(99286004)(52536014)(97736004)(110136005)(8676002)(53546011)(5660300002)(229853002)(81156014)(81166006)(8936002)(9686003)(486006)(478600001)(966005)(30864003)(66574012)(561944003)(316002)(106356001)(105586002)(2501003)(55016002)(151285002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3801; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: gdMAj7TO6w7D6F7ZKQa+R4zLZZ00tDXRiPQe7Yez44BjXIW6sAlgbq7xd1mESnEwFn2MUTUpoPgsNlZ2R5DwzUBHEG1Fvrpp8/SjJVTaIUhIbC+ZjbhGS33W08XRvCvkIjIBUHCp0pa5IdPPFmUrs15zvArWbim9DLsvvtfCZU3hg6EcFikgzbFRL7j0IigOxKuKpiDKU38SeKYqAm8K+2hB9NMdSRlDQtb6dtDFz5SElsUvKaXIXMIdaO89lgC0hksFCwsYehVA2HgceDHu/jrEppTTPpT2Nhx6uwX+l6h7x2vqzO4BsFSY6v4q2pqFj8257p2VB1vwyEQgCTe8y+jvonlGP4C/zgufH7au9gRAMqPW/fb9SMH4A8HO8TBu8blnHka6kiQp0fwykiMjJMrjH7lq0XRJYhxTYJip56o= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 662a843d-f5cc-4460-f080-08d6b99f9bc6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2019 08:20:48.3508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3801 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 05 Apr 2019 08:20:59 -0000 Thanks for the review, Magnus!=0A= =0A= Authors, could you please look into Magnus's comments and provide him=0A= with responses?=0A= =0A= Thanks,=0A= =0A= Gonzalo=0A= =0A= On 05-Apr-19 10:11, Magnus Westerlund wrote:=0A= > Hi,=0A= > =0A= > One addition.=0A= > =0A= > Section 16.13. ICMP Attribute=0A= > =0A= > This attribute is flawed as it lacks a data part to carry values certain= =0A= > codes have. I specifically think of ICMPv6 Type =3D 2, Packet Too Big.=0A= > That message has a 32-bit unsigned integer carrying the MTU of the Next= =0A= > Hop Link that causes the ICMP message to be sent. That really should be= =0A= > replicated back to the client.=0A= > =0A= > There is also the question if ICMP messages for Parameter Problem should= =0A= > included the pointer?=0A= > =0A= > I really think there need to be a 32-bit data field with the ICMP=0A= > attribute.=0A= > =0A= > Cheers=0A= > =0A= > Magnus=0A= > =0A= > =0A= > On 2019-04-04 16:00, Magnus Westerlund wrote:=0A= >> Hi,=0A= >>=0A= >> I have now finished the AD review. There are a lot of details that I=0A= >> think needs fixing or at least feedback on. I also think there are a=0A= >> couple of more serious issues here. Especially regarding the handling of= =0A= >> MTU and fragmentation, as well as IP header fields in address family=0A= >> translation and with non UDP transport. We need to conclude on these=0A= >> before we go to IETF last call.=0A= >>=0A= >> My Review comments are:=0A= >>=0A= >> A. Section 1: "The client can arrange=0A= >> for the server to relay packets to and from certain other hosts=0A= >> (called peers) and can control aspects of how the relaying is done."= =0A= >>=0A= >> I don't think this is an accurate description of what Turn does. One may= =0A= >> easily get the impression that the whole packet TURN receives are=0A= >> relayed, rather than the transport protocol data part and some of the=0A= >> header information are relayed between the client <-> peer, with a=0A= >> knowledge of the peer transport address for the client. I think that=0A= >> should be clarified in the introduction.=0A= >>=0A= >> B. Section 2.7:=0A= >>=0A= >> "Applications using TCP can more or less=0A= >> ignore this issue because fragmentation avoidance is now a standard= =0A= >> part of TCP, but applications using UDP (and thus any application=0A= >> using this version of TURN) must handle fragmentation avoidance=0A= >> themselves."=0A= >>=0A= >> Lower case "must", and as the document uses RFC 2119, this must have the= =0A= >> meaning of "MUST". A reformulation here is likely in order.=0A= >>=0A= >> C. Section 2.7:=0A= >>=0A= >> In this approach, the application exploits the=0A= >> fact that the IP specification [RFC0791] specifies that IP packets up= =0A= >> to 576 bytes should never need to be fragmented.=0A= >>=0A= >> As a guideline, sending a maximum of 500 bytes of application data in= =0A= >> a single TURN message (by the client on the client-to-server leg) or= =0A= >> a UDP datagram (by the peer on the peer-to-server leg) will generally= =0A= >> avoid IP fragmentation. To further reduce the chance of=0A= >> fragmentation, it is recommended that the client use ChannelData=0A= >> messages when transferring significant volumes of data, since the=0A= >> overhead of the ChannelData message is less than Send and Data=0A= >> indications.=0A= >>=0A= >> In that first paragraph I think it is worth discussing the IPv6=0A= >> requirement of supporting a 1280 minimal size.=0A= >>=0A= >> Secondly, I think recommending only a 500 MTU is way to conservative.=0A= >> Those studies I have seen appears to indicate that at least 1220 bytes= =0A= >> UDP payloads should be be working as well as 500 bytes. See for example= =0A= >> figure 12 in this:=0A= >> https://static.googleusercontent.com/media/research.google.com/sv//pubs/= archive/46403.pdf=0A= >>=0A= >>=0A= >> D. Section 2.7:=0A= >>=0A= >> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that=0A= >> uses STUN to discover the path MTU, and so might be a suitable=0A= >> approach to be used in conjunction with a TURN server that supports= =0A= >> the DONT-FRAGMENT attribute. When the client includes the DONT-=0A= >> FRAGMENT attribute in a Send indication, this tells the server to set= =0A= >> the DF bit in the resulting UDP datagram that it sends to the peer.= =0A= >> Since some servers may be unable to set the DF bit, the client should= =0A= >> also include this attribute in the Allocate request -- any server=0A= >> that does not support the DONT-FRAGMENT attribute will indicate this= =0A= >> by rejecting the Allocate request.=0A= >>=0A= >> I want to verify that the WG is working on resolving the issues with the= =0A= >> STUN PMTUD document. I definitely sees the point of the recommendation,= =0A= >> but only if the WG will conclude on that document in a reasonable time= =0A= >> frame.=0A= >>=0A= >> E. Section 3:=0A= >>=0A= >> Server-Reflexive Transport Address: A transport address on the=0A= >> "public side" of a NAT. This address is allocated by the NAT to= =0A= >> correspond to a specific host transport address.=0A= >>=0A= >> Shouldn't "public side" be replace with "external side"? That is the=0A= >> terminology used by the Behave RFCs.=0A= >>=0A= >> F. Section 3:=0A= >>=0A= >> 5-tuple: The combination (client IP address and port, server IP=0A= >> address and port, and transport protocol (currently one of UDP,=0A= >> TCP, or (D)TLS)) used to communicate between the client and the=0A= >> server.=0A= >>=0A= >> I see some issues that the 5-tuple aggregates the transport protocol=0A= >> with the security protocol. I agree from the TURN protocol perspective= =0A= >> the protocol combination is the important one. However, writing like you= =0A= >> do here you obfuscate both that when security is in place you have a=0A= >> combination, as well as that there are 4 alternatives defined by this=0A= >> document.=0A= >>=0A= >> G. Section 4.1:=0A= >>=0A= >> The "turn" and "turns" URI schemes are used to designate a TURN=0A= >> server (also known as a relay) on Internet hosts accessible using the= =0A= >> TURN protocol. The TURN protocol supports sending messages over UDP,= =0A= >> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be= =0A= >> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the= =0A= >> "turn" scheme MUST be used otherwise. The required part of=0A= >> the "turn" URI denotes the TURN server host. The part, if=0A= >> present, denotes the port on which the TURN server is awaiting=0A= >> connection requests. If it is absent, the default port is 3478 for= =0A= >> both UDP and TCP. The default port for TURN over TLS and TURN over= =0A= >> DTLS is 5349.=0A= >>=0A= >> First, I was wondering if this document needed to update RFC 7065? The= =0A= >> high level obvious is the reference, but otherwise on the surface it=0A= >> doesn't look necessary. My main complaint when reading was that it was= =0A= >> not obvious what not specifying the transport parameter means. Then I=0A= >> saw this in Section 3.1 of RFC 7065:=0A= >>=0A= >> The , , and components are passed without=0A= >> modification to the [RFC5928] algorithm. is set to false if= =0A= >> is equal to "turn", and set to true if is equal to= =0A= >> "turns" and passed to the [RFC5928] algorithm with the other=0A= >> components.=0A= >>=0A= >> After some digging I figured out that RFC5928 is actually updated by RFC= =0A= >> 7350 that defines the resolution and SRV records for DTLS.=0A= >>=0A= >> Can you please update the text in Section 4 to also reference RFC 7350= =0A= >> so that one doesn't miss this definitions.=0A= >>=0A= >> H. Section 5:=0A= >>=0A= >> If the server requires requests to be=0A= >> authenticated, then the server's administrator MUST choose a realm=0A= >> value that will uniquely identify the username and password=0A= >> combination that the client must use, even if the client uses=0A= >> multiple servers under different administrations.=0A= >>=0A= >> Just to verify, TURN does not allow a single server address to host=0A= >> multiple realms do it? Each Realm needs its own unique server transport= =0A= >> address?=0A= >>=0A= >> I. Section 5:=0A= >>=0A= >> For each Allocate request, the server SHOULD generate a=0A= >> new random nonce when the allocation is first attempted following the= =0A= >> randomness recommendations in [RFC4086] and SHOULD expire the nonce= =0A= >> at least once every hour during the lifetime of the allocation.=0A= >>=0A= >> So, I think this text due to its use of RFC 2119 language is a bit=0A= >> confusing in its relation to STUNbis. To me it is unclear if the above= =0A= >> overrides completely what is written in Section 5 of STUNbis:=0A= >>=0A= >> To indicate that it supports this specification, a server MUST=0A= >> prepend the NONCE attribute value with the character string composed= =0A= >> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]= =0A= >> encoding of the 24 bit STUN Security Features as defined in=0A= >> Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes,= =0A= >> with bit 0 as the most significant bit of the first byte and bit 23= =0A= >> as the least significant bit of the third byte. If no security=0A= >> features are used, then a byte array with all 24 bits set to zero=0A= >> MUST be encoded instead. For the remainder of this document the term= =0A= >> "nonce cookie" will refer to the complete 13 character string=0A= >> prepended to the NONCE attribute value.=0A= >>=0A= >> Or is the randomness recommendations in TURNbis only for the NONCE=0A= >> attribute value part?=0A= >>=0A= >> Secondly, I interpret the text to say that compared to STUN, where a=0A= >> Nonce can be long lived after the initial Long Term Credential=0A= >> establishment, in TURN for each allocation one will have to to the=0A= >> Allocate, expired nonce->here is your new nonce, resend allocate using= =0A= >> new nonce, success dance.=0A= >>=0A= >> I think part of the problem with the above text in TURNbis is that the= =0A= >> sentences prior to the quoted one appear to be rehashing of the STUNbis= =0A= >> requirements. Then the quoted part that actually changes behavior=0A= >> without being clear about it. I think it would be good to make it clear= =0A= >> what is a change compared to STUNbis.=0A= >>=0A= >> J. Section 6:=0A= >>=0A= >> Note that, rather than storing the password explicitly, for=0A= >> security reasons, it may be desirable for the server to store the key= =0A= >> value, which is a secure hash over the username, realm, and password= =0A= >> (see [I-D.ietf-tram-stunbis]).=0A= >>=0A= >> Why isn't this recommendation stronger. Are there any reasons why a=0A= >> server would actually store the plain text password at all?=0A= >>=0A= >> K. Section 7.1:=0A= >>=0A= >> The client first picks a host transport address. It is RECOMMENDED= =0A= >> that the client pick a currently unused transport address, typically= =0A= >> by allowing the underlying OS to pick a currently unused port for a= =0A= >> new socket.=0A= >>=0A= >> I think talk about socket in this context should be skipped as it=0A= >> otherwise have been eliminated.=0A= >>=0A= >> L. Section 7.1:=0A= >>=0A= >> The client then picks a transport protocol to use between the client= =0A= >> and the server. The transport protocol MUST be one of UDP, TCP, TLS-= =0A= >> over-TCP or DTLS-over-UDP.=0A= >>=0A= >> I find it strange that this indicates that one should pick the transport= =0A= >> protocol to use client to server without considering the server=0A= >> capabilities. Especially as the client configuration or server discovery= =0A= >> procedures will indicate transport protocol support.=0A= >>=0A= >> Secondly, what is the motivation for the MUST in the second sentence?=0A= >> This is appears to have strange interactions with any future extensions= =0A= >> and have no impact. A client must obvious chose a client to server=0A= >> transport protocol it supports, and one that the server supports or the= =0A= >> client hope it will support.=0A= >>=0A= >> M. Section 7.1:=0A= >>=0A= >> The client also picks a server transport address, which SHOULD be=0A= >> done as follows. The client uses one or more procedures described in= =0A= >> [RFC8155] to discover a TURN server and uses the TURN server=0A= >> resolution mechanism defined in [RFC5928] to get a list of server=0A= >> transport addresses that can be tried to create a TURN allocation.=0A= >>=0A= >> 1) So RFC 8155 states that it has no recommendation on server selection,= =0A= >> nor on how to related local configuration to any auto-discovery servers.= =0A= >> To me it appears that the protocol utilizing TURN should consider what= =0A= >> makes sense in their deployments. Thus, does the need for such=0A= >> consideration needs to be highlighted somewhere in this specification.= =0A= >>=0A= >> 2) The RFC5928 reference should be complemented with an RFC 7350=0A= >> reference.=0A= >>=0A= >> N. Section 7.1:=0A= >>=0A= >> Clients MUST NOT include a REQUESTED-ADDRESS-=0A= >> FAMILY attribute in an Allocate request that contains a RESERVATION-= =0A= >> TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >>=0A= >> Considering that this document obsoletes RFC 6156, I think it is bad=0A= >> form to reference that document, rather than to move the necessary=0A= >> motivation into this document.=0A= >>=0A= >> O. Section 7.1:=0A= >>=0A= >> If the client wishes to obtain a relayed transport address of a=0A= >> specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A= >> attribute in the request.=0A= >>=0A= >> I don't find anything describing what the default behavior is if one=0A= >> doesn't include the attribute, but the TURN server supports multiple=0A= >> address families.=0A= >>=0A= >> I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= >> Should the text in 7.1 be explicit about this default?=0A= >>=0A= >> P. Section 7.2:=0A= >>=0A= >> Otherwise, if the attribute is included but=0A= >> specifies a protocol other that UDP, the server rejects the=0A= >> request with a 442 (Unsupported Transport Protocol) error.=0A= >>=0A= >> Assuming that you don't support an extension for that transport=0A= >> protocol. Should that be made explicit?=0A= >>=0A= >> Q. Section 8.3:=0A= >>=0A= >> If the client receives a success response to its Refresh request with= =0A= >> a non-zero lifetime, it updates its copy of the allocation data=0A= >> structure with the time-to-expiry value contained in the response.=0A= >>=0A= >> If the client receives a 437 (Allocation Mismatch) error response to= =0A= >> a request to delete the allocation, then the allocation no longer=0A= >> exists and it should consider its request as having effectively=0A= >> succeeded.=0A= >>=0A= >> So there are no considerations for the client if it receives an error=0A= >> response to a refresh request when Lifetime was non-zero?=0A= >>=0A= >> I am bit surprised by that. I assume that there are certain cases when= =0A= >> the request could be resent, and others where the meaning is that the=0A= >> allocation is gone.=0A= >>=0A= >> R. Section 11.5:=0A= >>=0A= >> When the server receives an ICMP packet, the server verifies that the= =0A= >> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either= =0A= >> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the= =0A= >> IP packet in the ICMP packet payload contains a UDP header. If=0A= >> either of these conditions fail, then the ICMP packet is silently=0A= >> dropped.=0A= >>=0A= >> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A= >> Problem are for ICMPv4?=0A= >>=0A= >> S. Section 12.5:=0A= >>=0A= >> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to= =0A= >> a multiple of four bytes in order to ensure the alignment of=0A= >> subsequent messages. The padding is not reflected in the length=0A= >> field of the ChannelData message, so the actual size of a ChannelData= =0A= >> message (including padding) is (4 + Length) rounded up to the nearest= =0A= >> multiple of 4. Over UDP, the padding is not required but MAY be=0A= >> included.=0A= >>=0A= >> Are there anywhere written what one may or may not include of the TURN= =0A= >> related messages in a single UDP datagram. Because it is technically=0A= >> feasible I belive to include two Send Indications in one UDP datagram to= =0A= >> the server.=0A= >>=0A= >> T. Section 13.1:=0A= >>=0A= >> Flow Label=0A= >>=0A= >> Preferred behavior: The relay sets the Flow label to 0. The relay= =0A= >> can choose to set the Flow label to a different value if it=0A= >> supports the IPv6 Flow Label field [RFC6437].=0A= >>=0A= >> Alternate behavior: The relay sets the Flow label to the default= =0A= >> value for outgoing packets.=0A= >>=0A= >> I think this section should be improved in two ways.=0A= >>=0A= >> First of all I think it should clarify that each allocation to peer flow= =0A= >> is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= >>=0A= >> Secondly, I think in the spirit of RFC 6473 the preferred behavior=0A= >> should be to set the IPv6 flow label if the implementation is capable,= =0A= >> or leave it to the underlying network stack to actually set it. Compared= =0A= >> to RFC 7915, the TURN server actually have an understanding of what are= =0A= >> different flows without having examining additional protocol layers.=0A= >>=0A= >> Thirdly, I don't understand what the alternative behavior actually is.= =0A= >> This as it is either setting it to 0, or classifying things as flow and= =0A= >> then provide it with a random flow label. I think the right alternative= =0A= >> behavior is to set it 0.=0A= >>=0A= >> U. Section 13. 1,2,3:=0A= >>=0A= >> For both preferred and alternate behavior, the DONT-FRAGMENT=0A= >> attribute MUST be ignored by the server.=0A= >>=0A= >> I don't understand why just because one performs v4<->v6 or v6 to v4=0A= >> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= >> attribute. If the client has request to not fragment and the server is= =0A= >> unable to do that when forwarding to the peer it needs to generate an=0A= >> ICMP attribute response saying the packet is to big. Otherwise the relay= =0A= >> breaks the Path MTU discovery mechanisms.=0A= >>=0A= >> V. Section 13.2:=0A= >>=0A= >> Fragmentation:=0A= >>=0A= >> If the incoming packet included a Fragment header and the outgoing= =0A= >> packet size exceeds the outgoing link's MTU, the relay MUST=0A= >> fragment the outgoing packet into fragments of no more than 1280= =0A= >> bytes. The relay sets the fields of the Fragment header as=0A= >> appropriate for a packet originating from the server.=0A= >>=0A= >> Is really the intention here to refragment the packet without providing= =0A= >> any indication that the practical MTU is smaller than what the peer or= =0A= >> client thinks it is?=0A= >>=0A= >> W. Section 14:=0A= >>=0A= >> Preferred Behavior: Set the outgoing value to the incoming value,= =0A= >> UNLESS the server is doing Active Queue Management, the incoming= =0A= >> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server= =0A= >> wishes to indicate that congestion has been experienced, in which= =0A= >> case set the outgoing value to CE (=3D0b11).=0A= >>=0A= >> First of all do you have any special meaning with all capital UNLESS?=0A= >>=0A= >> Secondly, I don't know how wise it is to have partial definitions of=0A= >> what the ECN behavior is. Maybe simpler to say that that the relay is=0A= >> performing AQM it can support the ECN marking behavior as defined in RFC= =0A= >> 3168.=0A= >>=0A= >> X. Section 14:=0A= >>=0A= >> How are these IP level fields handled when the transport is TCP or=0A= >> TLS/TCP? There there are not necessary a one to one mapping between=0A= >> datagrams and TCP packets. And if there are no support then there are=0A= >> need for clarification of behaviors when using TCP based transport.=0A= >>=0A= >> Y. Section 16.4. DATA=0A= >>=0A= >> The DATA attribute is present in all Send and Data indications. The= =0A= >> value portion of this attribute is variable length and consists of=0A= >> the application data (that is, the data that would immediately follow= =0A= >> the UDP header if the data was been sent directly between the client= =0A= >> and the peer). If the length of this attribute is not a multiple of= =0A= >> 4, then padding must be added after this attribute.=0A= >>=0A= >> Can you please clarify if one would get all the remaining bytes of the= =0A= >> IP packet payload or only the number of bytes the UDP length field=0A= >> indiactes?=0A= >>=0A= >> The reason I ask is that there is possibility that there are a=0A= >> discrepancy between these fields, something the proposal for an=0A= >> experimental specification for UDP options attempt to utilize.=0A= >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >>=0A= >> Note, I only want you to clarify what is actually included. I would=0A= >> assume using the UDP length field makes sense in this case.=0A= >>=0A= >> Z. The use of "relay" in the meaning of "Turn Server". There are many=0A= >> occurrences of relay in this meaning. Either make it explicit to be a=0A= >> synonym or change it to server.=0A= >>=0A= >> AA. Section 16.7=0A= >>=0A= >> rffu is lacking a definition. I would suggest making it upper case and= =0A= >> copy the definition from 16.8.=0A= >>=0A= >> AB. Section 16.12:=0A= >>=0A= >> Rsvd in Format figure does not match definition below which uses "Reserv= ed".=0A= >>=0A= >> AC. Section 16.12:=0A= >>=0A= >> Reason Phrase (variable). This field is under defined. First of all the= =0A= >> format of the text string is not defined, which it is in Stunbis=0A= >> Error-Code attribute is defined as.=0A= >>=0A= >> The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= >> sequence of less than 128 characters (which can be as long as 509=0A= >> bytes when encoding them or 763 bytes when decoding them).=0A= >>=0A= >> Secondly, I think it might be worth pointing out the padding here. It is= =0A= >> not clear if there is any form of string termination and how the padding= =0A= >> which will be interpreted as NULL characters 0-3 depending on the=0A= >> alignment. I note this later issue appears to be existing in STUNBis als= o.=0A= >>=0A= >> AD. Section 16.2:=0A= >>=0A= >> Why isn't the text here say that this attribute may also be used to=0A= >> indicate the desired lifetime in allocation requests?=0A= >>=0A= >> AE. Section 16.9: DONT-FRAGMENT=0A= >>=0A= >> I think it would be good to indicate the use of the attribute in=0A= >> Allocate Requests also.=0A= >>=0A= >> AF. Section 24.2=0A= >>=0A= >> [Protocol-Numbers]=0A= >> "IANA Protocol Numbers Registry", 2005,=0A= >> .=0A= >>=0A= >> This is a normative reference based on how it is used in Section 16.8.= =0A= >>=0A= >> AG. Seciton 18.=0A= >>=0A= >> Sometime before the 20 minute lifetime is up, the client refreshes=0A= >> the allocation. This is done using a Refresh request. As before,=0A= >> the client includes the latest username, realm, and nonce values in= =0A= >> the request. The client also includes the SOFTWARE attribute,=0A= >> following the recommended practice of always including this attribute= =0A= >> in Allocate and Refresh messages. When the server receives the=0A= >> Refresh request, it notices that the nonce value has expired, and so= =0A= >> replies with 438 (Stale Nonce) error given a new nonce value. The=0A= >> client then reattempts the request, this time with the new nonce=0A= >> value. This second attempt is accepted, and the server replies with= =0A= >> a success response. Note that the client did not include a LIFETIME= =0A= >> attribute in the request, so the server refreshes the allocation for= =0A= >> the default lifetime of 10 minutes (as can be seen by the LIFETIME=0A= >> attribute in the success response).=0A= >>=0A= >> I notice that this part nor the text before appears to discuss the=0A= >> permission lifetime that will expire after 5 minutes. Thus, it needs to= =0A= >> be refreshed prior to the Allocation.=0A= >>=0A= >> AH. Section 18.=0A= >>=0A= >> I am missing any example having to do with Address Family interactions.= =0A= >>=0A= >> AI. DTLS Cipher Suits=0A= >>=0A= >> Am I understanding it correct that the definition of what DTLS cipher=0A= >> suit that a TURN Server currently is to support is the ones in RFC 7525?= =0A= >>=0A= >> In that case, I think the wording is a bit weak as the only reference I= =0A= >> find are in Section 2.1:=0A= >>=0A= >> If (D)TLS transport is=0A= >> used between the TURN client and the TURN server, the guidance given= =0A= >> in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= >>=0A= >>=0A= >> Cheers=0A= >>=0A= >> Magnus Westerlund =0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> Network Architecture & Protocols, Ericsson Research=0A= >> ----------------------------------------------------------------------= =0A= >> Ericsson AB | Phone +46 10 7148287=0A= >> Torshamnsgatan 23 | Mobile +46 73 0949079=0A= >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> tram mailing list=0A= >> tram@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tram=0A= >>=0A= > =0A= From nobody Sun Apr 7 09:01:32 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A744120325 for ; Sun, 7 Apr 2019 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iV-ey3K-EXs for ; Sun, 7 Apr 2019 09:01:28 -0700 (PDT) Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBF7120199 for ; Sun, 7 Apr 2019 09:01:28 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:4dcb:ec5c:ac78:495b] (unknown [IPv6:2601:648:8400:8e7d:4dcb:ec5c:ac78:495b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 361B1AE5F4 for ; Sun, 7 Apr 2019 18:01:26 +0200 (CEST) To: "tram@ietf.org" From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA= Message-ID: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> Date: Sun, 7 Apr 2019 09:01:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="asaxXg8nyowpPGiyg7T3UlzghvGmF7iAH" Archived-At: Subject: [tram] New test vector for stunbis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 07 Apr 2019 16:01:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --asaxXg8nyowpPGiyg7T3UlzghvGmF7iAH Content-Type: multipart/mixed; boundary="9VH3cgS71kvYA1YJX6bLbPzrnI3ojXKbr"; protected-headers="v1" From: Marc Petit-Huguenin To: "tram@ietf.org" Message-ID: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> Subject: New test vector for stunbis --9VH3cgS71kvYA1YJX6bLbPzrnI3ojXKbr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Now that IANA has allocated codepoints for stunbis, it is time to calcula= te the final test vector in section B.1. It would be great is someone co= uld redo the calculations and assert that my results are correct. Thanks= =2E =2E... Username: "" and=20 "\xe3\x83\x9e\xe3\x83\x88\xe3\x83\xaa\xe3\x83\x83\xe3\x82\xaf\xe3\x82\xb9= " (without quote) respectively before and after UsernameCasePreserved [RFC8265] processing Password: "TheMtr" and "TheMatrIX" (without quotes) respectively before and after OpaqueString [RFC8265] processing Nonce: "bMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) Realm: "example.org" (without quotes) 00 01 00 9c Request type and message length 21 12 a4 42 Magic cookie 78 ad 34 33 } c6 ad 72 c0 } Transaction ID 29 da 41 2e } 00 1e 00 20 USERHASH attribute header 4a 3c f3 8f } ef 69 92 bd } a9 52 c6 78 } 04 17 da 0f } Userhash value (32 bytes) 24 81 94 15 } 56 9e 60 b2 } 05 c4 6e 41 } 40 7f 17 04 } 00 15 00 29 NONCE attribute header 6f 62 4d 61 } 74 4a 6f 73 } 32 41 41 41 } 43 66 2f 2f } 34 39 39 6b } Nonce value and padding (3 bytes) 39 35 34 64 } 36 4f 4c 33 } 34 6f 4c 39 } 46 53 54 76 } 79 36 34 73 } 41 00 00 00 } 00 14 00 0b REALM attribute header 65 78 61 6d } 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) 6f 72 67 00 } 00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header e4 68 6c 8f } 0e de b5 90 } 13 e0 70 90 } 01 0a 93 ef } HMAC-SHA256 value cc bc cc 54 } 4c 0a 45 d9 } f8 30 aa 6d } 6f 73 5a 01 } =2E... --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --9VH3cgS71kvYA1YJX6bLbPzrnI3ojXKbr-- --asaxXg8nyowpPGiyg7T3UlzghvGmF7iAH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlyqHtMACgkQKcRFldZq fsREgw/+LrRe/2O0m4r/lbNHDGB9BQURsp12ALUm9NY19LhUgGY93QRJTTVEPTWD r16kwzaI+NJ5bvco0Lcqelp2Bmc+WfFC7n0+Q6+XNgsgzdv0t8Lpg5FG+A4BKF7L ugdBzKrQCdkdum0DuvpyDU9cSLx/5EotHxbuJEyNvzrYEgGdDX7bRHth8GqMbqGV uW1RDFPjC6C5MBN62b4jXtg5Ivx50e9n/m74IRypcEGfxJ1vcnXzdYjyKWX4a+R8 u66ldivV8UJIBCEbdvU8d/XdONzarwj18BTyWjPMN7KWAf8r4iFF/wZ9PY/PsMKP RGyUBw9H9+cwoZ1okVkkEbWiBRlxpr6k5F16Yqz9XLGyRrjBbrv2uFUgle0lAoVo PhOByGE60IB316f6gGiqwF1coIEFq+FQGJORNA+jLw745taTtVLGoo5jnHsfvDA+ xmAIac/k9qJ5pUnb8QbhZONWZjI4e0DbH1t1QcsLjOVV129ZYL1IRoln5zf4BULU VexEMJ9OkX1QsYxcEWf4KVOM35CMGjj34nwEfXAMTr4H4O4TiE2eALUM2122a2qr Q/neCJc+16UL2lbNdmCfkd6pWVlcj/UPGTQQ9Vhar1xdCASYy4SwgZ0pKtWapaYi ouQnXjl5m6WiWCubD0DY/UjwT5MHm31eX8rnGR1iWwlXPU5HnqU= =lo1H -----END PGP SIGNATURE----- --asaxXg8nyowpPGiyg7T3UlzghvGmF7iAH-- From nobody Mon Apr 8 03:38:05 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EEF12004F; Mon, 8 Apr 2019 03:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSSrLHlEliDN; Mon, 8 Apr 2019 03:37:55 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40076.outbound.protection.outlook.com [40.107.4.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00653120019; Mon, 8 Apr 2019 03:37:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3uZbhaS8BEkEN6ClIZLGTNW5QxrmSlGrEQOx7cn1VLM=; b=J1jqgZOA8UZkeiLUVSpo/hoEDqo34IcjoLY8b/u0tCz6Q/qbWYX9d7M+XHQpMYDAkbbBjieieKZ8wW7DWxjBoI+LiK1ZYJ2YozJdW+WmDtaakVp3aCqml9KqLNMdywAqtbJHqSvPJT1Wt5u+ApRZSCwrvLfJtQv0udVlhBeah8M= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1PR0702MB3563.eurprd07.prod.outlook.com (52.133.6.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.11; Mon, 8 Apr 2019 10:37:52 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1792.007; Mon, 8 Apr 2019 10:37:52 +0000 From: Gonzalo Camarillo To: "Gonzalo Salgueiro (gsalguei)" CC: IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-stun-pmtud@ietf.org" , "Asveren, Tolga" , "tram@ietf.org" Thread-Topic: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) Thread-Index: AQHUkuV9WRgg08P2B0upj6+dKkdDsg== Date: Mon, 8 Apr 2019 10:37:52 +0000 Message-ID: References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> <2EE82D0D-5024-4C71-8F25-0506D5530814@cisco.com> <487146f2-f343-3c56-aeca-2e3fcfe54675@ericsson.com> <5A81A440-4ABF-4818-A1AE-83F5EF78D0EF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-originating-ip: [37.136.23.131] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b37de99-6dbd-4c2c-a9e7-08d6bc0e40ec x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0702MB3563; x-ms-traffictypediagnostic: HE1PR0702MB3563: x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(136003)(346002)(376002)(396003)(40764003)(45074003)(199004)(189003)(55016002)(6116002)(3846002)(7696005)(68736007)(6916009)(6246003)(66066001)(9686003)(71190400001)(71200400001)(53936002)(4326008)(25786009)(86362001)(476003)(81166006)(81156014)(102836004)(52536014)(446003)(26005)(106356001)(8676002)(6506007)(105586002)(14444005)(256004)(53546011)(76176011)(229853002)(14454004)(478600001)(54906003)(8936002)(93886005)(2906002)(99286004)(316002)(7736002)(5660300002)(186003)(74316002)(6436002)(33656002)(305945005)(97736004)(486006)(44832011)(69594002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3563; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EdntH5yur04QLy3DSXl79j0kaHQ2+HJB7CB5CMVYbCjdzlLz242wpIerLg+Q5gAfJh4PreRg1NRn+gXwUrmPUc8VKHTJz/6d8cLf5aKkoy3EFFGWlJ2gHIO9pwzelEGVAz6aUZHFrtFH3XQvTqZZT7uO1Q0QZGuA638hSky/HncR13SIrzwhhiSNuG7NX4OOdVEh/KJ8fG202T3csnk/us6n5jGnMIQ1blp260Byuo3lozhsDCz9/pCNW1gfuFSyFHHo249CusXswpCjZj7e9+EaUtGjle9CKrzQNiWhgtYXIoCwnWm7JQsrXeC/k7gGZPvJbqIM3YM7/DuXuT/GBcCNA2vU7cIWG2uY+yDY88+6MGhToH8gkwX96kJ+gQJylw7mVKArOo+NPSBDdu0uRLBNDmIhoNz/X5VuyXsAKeM= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b37de99-6dbd-4c2c-a9e7-08d6bc0e40ec X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 10:37:52.2488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3563 Archived-At: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 10:37:57 -0000 Hi Gonzalo S,=0A= =0A= what is your time plan for working on this?=0A= =0A= Cheers,=0A= =0A= Gonzalo=0A= =0A= On 22-Mar-19 20:43, Gonzalo Salgueiro (gsalguei) wrote:=0A= > Hi Gonzalo - =0A= > =0A= > I apologize but this PMTUD draft has gotten little attention beyond outli= ning proposals for clearing some of the raised DISCUSSes. This one has tak= en a back seat as we are actively prioritizing completion of the STUN draft= before some AD=92s step down. I think we should have that one completed b= y Prague or very soon after and then we will work on this PMTUD draft.=0A= > =0A= > Cheers,=0A= > =0A= > Gonzalo=0A= > =0A= > =0A= >> On Mar 22, 2019, at 3:52 AM, Gonzalo Camarillo wrote:=0A= >>=0A= >> Hi Gonzalo S,=0A= >>=0A= >> could you please give me a status update on this?=0A= >>=0A= >> Thanks,=0A= >>=0A= >> Gonzalo=0A= >>=0A= >> On 19-Feb-19 20:13, Gonzalo Salgueiro (gsalguei) wrote:=0A= >>> Hi Gonzalo - =0A= >>>=0A= >>> We have made a decision on the PADDING but are still working through so= me of the comments raised in DISCUSS. We hope to have this finished after = finalizing STUN, which should be very close.=0A= >>>=0A= >>> Cheers,=0A= >>>=0A= >>> Gonzalo=0A= >>>=0A= >>>> On Feb 18, 2019, at 8:17 AM, Gonzalo Camarillo wrote:=0A= >>>>=0A= >>>> Hi Gonzalo S,=0A= >>>>=0A= >>>> what is the current status of this?=0A= >>>>=0A= >>>> Cheers,=0A= >>>>=0A= >>>> Gonzalo=0A= >>>>=0A= >>>> On 18-Jan-19 20:12, Gonzalo Salgueiro (gsalguei) wrote:=0A= >>>>> Thanks, Spencer. We will proceed with bringing the definition of=0A= >>>>> PADDING into the current draft.=0A= >>>>>=0A= >>>>> Cheers,=0A= >>>>>=0A= >>>>> Gonzalo=0A= >>>>>=0A= >>>>>> On Jan 14, 2019, at 9:25 AM, Spencer Dawkins at IETF=0A= >>>>>> >=0A= >>>>>> wrote:=0A= >>>>>>=0A= >>>>>> Hi, Gonzalo,=0A= >>>>>>=0A= >>>>>> On Mon, Jan 14, 2019 at 8:05 AM Gonzalo Camarillo=0A= >>>>>> >>>>> > wrote:=0A= >>>>>>=0A= >>>>>> What is the next step here?=0A= >>>>>>=0A= >>>>>> Gonzalo=0A= >>>>>>=0A= >>>>>> On 13-Dec-18 16:27, Spencer Dawkins at IETF wrote:=0A= >>>>>>> Hi, Simon, =0A= >>>>>>>=0A= >>>>>>> On Thu, Dec 13, 2018 at 7:12 AM Simon Perreault=0A= >>>>>>> >>>>> >>>>> >> wrote:=0A= >>>>>>>=0A= >>>>>>> - Pull the definition of PADDING into this document. Declare=0A= >>>>>> that=0A= >>>>>>> we've gathered sufficient experience with PADDING that it now= =0A= >>>>>>> warrants being elevated to Standards Track. That is, it's been= =0A= >>>>>>> proven to work.____=0A= >>>>>>>=0A= >>>>>>> __ __=0A= >>>>>>>=0A= >>>>>>> This is plausible. It solves the first-order problem. ____=0A= >>>>>>>=0A= >>>>>>> __ __=0A= >>>>>>>=0A= >>>>>>> I note that RFC 5780 defined a number of new attributes. Is=0A= >>>>>> pulling=0A= >>>>>>> PADDING forward the right thing to do, or are there others that= =0A= >>>>>>> would also qualify (so, perhaps a status change for RFC=0A= >>>>>> 5780)? ____=0A= >>>>>>>=0A= >>>>>>> __ __=0A= >>>>>>>=0A= >>>>>>> I don=92t think the others have been implemented much, so=0A= >>>>>> that=92s why I=0A= >>>>>>> think only pulling PADDING makes sense. If I remember=0A= >>>>>> correctly, I=0A= >>>>>>> only implemented PADDING in Numb (I don=92t have access to the= =0A= >>>>>> source=0A= >>>>>>> code anymore so can=92t be sure).____=0A= >>>>>>>=0A= >>>>>>> __ __=0A= >>>>>>>=0A= >>>>>>> Anyone else with an opinion?=0A= >>>>>>>=0A= >>>>>>>=0A= >>>>>>> That's helpful information. =0A= >>>>>>>=0A= >>>>>>> We should wait for anyone else with information to weigh in, but=0A= >>>>>> if it's=0A= >>>>>>> correct that the other experimental attributes haven't been=0A= >>>>>> implemented=0A= >>>>>>> and deployed in a way that would provide guidance for=0A= >>>>>> standards-track=0A= >>>>>>> use, I think defining PADDING in this document makes more sense=0A= >>>>>> to me=0A= >>>>>>> than adding a downref to an experimental RFC that we wouldn't=0A= >>>>>> consider=0A= >>>>>>> if the reference was using anything except PADDING. =0A= >>>>>>=0A= >>>>>>=0A= >>>>>> No one has objected in the past month (which included holidays, but = I=0A= >>>>>> would have asked this question with a week or two timeout, if the=0A= >>>>>> holidays had not been coming up). =0A= >>>>>>=0A= >>>>>> I think bringing the definition of PADDING into the current draft is= =0A= >>>>>> the right thing to do. =0A= >>>>>>=0A= >>>>>> If TRAM people thought that the other experimental attributes in RFC= =0A= >>>>>> 5780 don't have enough implementation experience to justify moving= =0A= >>>>>> them past Experimental status, changing the status of RFC 5780 to=0A= >>>>>> Historic might be appropriate at some point, but that's not related = to=0A= >>>>>> the conversation we're having now, and I haven't asked a question=0A= >>>>>> about that, so I'll ignore that for now.=0A= >>>>>>=0A= >>>>>> Thanks for your help with this.=0A= >>>>>>=0A= >>>>>> Spencer=0A= >>>>>>=0A= >>>>>>=0A= >>>>>>>=0A= >>>>>>> Thanks,=0A= >>>>>>>=0A= >>>>>>> Spencer=0A= >>>>>>>=0A= >>>>>>> ____=0A= >>>>>>>=0A= >>>>>>> __ __=0A= >>>>>>>=0A= >>>>>>> Simon____=0A= >>>>>>>=0A= >>>>>>=0A= >>>>>=0A= >>>=0A= > =0A= From nobody Mon Apr 8 08:58:46 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0276120160; Mon, 8 Apr 2019 08:58:43 -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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YYLrYBNI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mEMu11OL 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 U7CbNCjW-Yur; Mon, 8 Apr 2019 08:58:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E0D120049; Mon, 8 Apr 2019 08:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7488; q=dns/txt; s=iport; t=1554739121; x=1555948721; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LViyE7W4mXeXlxIlVruS6BaFabO9Z2Kfdz18tj5Ybwg=; b=YYLrYBNInt84wW+yjPrfsERKF1vSpBLXdyOeXXf6lwZkvkO58DonQvsd B7+V7Zsu5l1DPRCarv6N735RqmqASZwTC2iZJxOG/ybV9XhYFOp1BMzKl Tg9oxg/pjqvDLc21bJ3SeGrrtGNTiLhG4S+O5RhNs+WONPRBm3UyXBrtu k=; IronPort-PHdr: =?us-ascii?q?9a23=3AvgsgSBO0NRceuQWqHOol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj0N/fuYDE3HexJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgA7b6tc/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYE+KScDgTwgBAsnhA6DRwOPKIJXiTiNYIJSA1QOAQEshEA?= =?us-ascii?q?CF4VOIjgSAQEDAQEJAQIBAm0cDIVKAQEBAwEjEQwBATcBBAsCAQgYAgIjAwI?= =?us-ascii?q?CAh8RFAEQAgQOBYMigV4DDQgBoy0CihRxgS+CeQEBBYR6DQuCDAiBCyWLRxe?= =?us-ascii?q?BQD+BEScfgkw+ghqCKjgCglAxgiaHbYUpmD02CQKMH4NYRoNEGoIFhhaMQYx?= =?us-ascii?q?thkyJW4I9AgQCBAUCDgEBBYFmIYFWcBVlAYJBggo3bQEGgkSKU3KBKI9FAQE?= X-IronPort-AV: E=Sophos;i="5.60,325,1549929600"; d="scan'208";a="459614028" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 15:58:19 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x38FwJrh023790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 15:58:19 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 10:58:19 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 10:58:17 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Apr 2019 11:58:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LViyE7W4mXeXlxIlVruS6BaFabO9Z2Kfdz18tj5Ybwg=; b=mEMu11OL5oeRWEf1YcgmC/V0UuSDYm73KPg6+0PmTp/Mb3VO+uQQelJB6jXyy78IrLZks1/i18GxXQbMKox4oHciQSaoAFCuh+XIBOBQwwJ8eVKI+h1qfHqwmE/hUZlMDTuI2v5tKvtsqx9wysxX7SMsh2nSV4/fCDB0t1K3b3E= Received: from BY5PR11MB3895.namprd11.prod.outlook.com (10.255.72.92) by BY5PR11MB4022.namprd11.prod.outlook.com (10.255.161.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Mon, 8 Apr 2019 15:58:15 +0000 Received: from BY5PR11MB3895.namprd11.prod.outlook.com ([fe80::ce5:bf39:3408:19cb]) by BY5PR11MB3895.namprd11.prod.outlook.com ([fe80::ce5:bf39:3408:19cb%3]) with mapi id 15.20.1771.016; Mon, 8 Apr 2019 15:58:15 +0000 From: "Gonzalo Salgueiro (gsalguei)" To: Gonzalo Camarillo CC: IESG , "tram-chairs@ietf.org" , "draft-ietf-tram-stun-pmtud@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) Thread-Index: AQHUkuV9WRgg08P2B0upj6+dKkdDsqYzIfWA Date: Mon, 8 Apr 2019 15:58:15 +0000 Message-ID: <168002DC-813F-4F65-917E-0D990216D7B3@cisco.com> References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> <2EE82D0D-5024-4C71-8F25-0506D5530814@cisco.com> <487146f2-f343-3c56-aeca-2e3fcfe54675@ericsson.com> <5A81A440-4ABF-4818-A1AE-83F5EF78D0EF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gsalguei@cisco.com; x-originating-ip: [2001:420:2280:1330:8cf1:35a:7fa8:3e18] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fca7050f-9605-48c8-5a3f-08d6bc3b030d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BY5PR11MB4022; x-ms-traffictypediagnostic: BY5PR11MB4022: x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39860400002)(396003)(136003)(189003)(199004)(40764003)(45074003)(54906003)(8676002)(76176011)(186003)(105586002)(81156014)(53936002)(68736007)(11346002)(486006)(316002)(33656002)(6916009)(446003)(6246003)(106356001)(2616005)(6512007)(99286004)(7736002)(86362001)(93886005)(14454004)(81166006)(476003)(478600001)(8936002)(82746002)(4326008)(46003)(6436002)(83716004)(71200400001)(71190400001)(2906002)(229853002)(305945005)(36756003)(5660300002)(6116002)(97736004)(25786009)(53546011)(14444005)(102836004)(6486002)(256004)(6506007)(69594002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR11MB4022; H:BY5PR11MB3895.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Rn8nV5BoTfiNqh4CcQjDImXGPXxwZbFnkxS/RogUzZpBORh709tR92baj87yLOmqQK0BM14IgzENZ5K/h2maK6G1q4L+if0MsEFzF3Ry2R5crK8JviItbx1FOSBI+3Npn1wM4ydrJm3thbOJDSxsAO0mbnMDO+4UJm1Iq/gN3MAv+f+3UOPusYLEw89ZT7BJUQS6JDk+hF87/UiW9pOeAMskBJaqQ4hRsd+0pcRNB7Wyb6vzdnIF6YixZo/EnzN5TJsFD3WEnv/a7wCnofbDBGczzSuqu3YQDwS3qkmkisEoJpiVMdTNyfKhQOChx9kT8FPOqWMZRQERS+Wnhh7Lwg5pCUChBI2ivUPPFooLX8MD0efnN8Cyf2Q0t++zqFu38vm+EhUPU4MXAexrcCWB1Li671oQy9bS9p+kqbjEVk4= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fca7050f-9605-48c8-5a3f-08d6bc3b030d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 15:58:15.8041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4022 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 08 Apr 2019 15:58:44 -0000 SGkgR29uemFsbyAtIA0KDQpXZSBoYXZlIGFscmVhZHkgc3RhcnRlZCBnb2luZyB0aHJvdWdoIHRo ZSBESVNDVVNTIHBvaW50cyB3aXRoIHRoZSBuZXcgZWRpdG9yIGFuZCBlbWFpbHMgc2hvdWxkIGJl IGZvcnRoY29taW5nIHRoaXMgd2Vlay4NCg0KVGhhbmtzLA0KDQpHb256YWxvDQoNCg0KPiBPbiBB cHIgOCwgMjAxOSwgYXQgNjozNyBBTSwgR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJp bGxvQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBHb256YWxvIFMsDQo+IA0KPiB3aGF0 IGlzIHlvdXIgdGltZSBwbGFuIGZvciB3b3JraW5nIG9uIHRoaXM/DQo+IA0KPiBDaGVlcnMsDQo+ IA0KPiBHb256YWxvDQo+IA0KPiBPbiAyMi1NYXItMTkgMjA6NDMsIEdvbnphbG8gU2FsZ3VlaXJv IChnc2FsZ3VlaSkgd3JvdGU6DQo+PiBIaSBHb256YWxvIC0gDQo+PiANCj4+IEkgYXBvbG9naXpl IGJ1dCB0aGlzIFBNVFVEIGRyYWZ0IGhhcyBnb3R0ZW4gbGl0dGxlIGF0dGVudGlvbiBiZXlvbmQg b3V0bGluaW5nIHByb3Bvc2FscyBmb3IgY2xlYXJpbmcgc29tZSBvZiB0aGUgcmFpc2VkIERJU0NV U1Nlcy4gIFRoaXMgb25lIGhhcyB0YWtlbiBhIGJhY2sgc2VhdCBhcyB3ZSBhcmUgYWN0aXZlbHkg cHJpb3JpdGl6aW5nIGNvbXBsZXRpb24gb2YgdGhlIFNUVU4gZHJhZnQgYmVmb3JlIHNvbWUgQUTi gJlzIHN0ZXAgZG93bi4gIEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgdGhhdCBvbmUgY29tcGxldGVk IGJ5IFByYWd1ZSBvciB2ZXJ5IHNvb24gYWZ0ZXIgYW5kIHRoZW4gd2Ugd2lsbCB3b3JrIG9uIHRo aXMgUE1UVUQgZHJhZnQuDQo+PiANCj4+IENoZWVycywNCj4+IA0KPj4gR29uemFsbw0KPj4gDQo+ PiANCj4+PiBPbiBNYXIgMjIsIDIwMTksIGF0IDM6NTIgQU0sIEdvbnphbG8gQ2FtYXJpbGxvIDxH b256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIEdvbnph bG8gUywNCj4+PiANCj4+PiBjb3VsZCB5b3UgcGxlYXNlIGdpdmUgbWUgYSBzdGF0dXMgdXBkYXRl IG9uIHRoaXM/DQo+Pj4gDQo+Pj4gVGhhbmtzLA0KPj4+IA0KPj4+IEdvbnphbG8NCj4+PiANCj4+ PiBPbiAxOS1GZWItMTkgMjA6MTMsIEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSkgd3JvdGU6 DQo+Pj4+IEhpIEdvbnphbG8gLSANCj4+Pj4gDQo+Pj4+IFdlIGhhdmUgbWFkZSBhIGRlY2lzaW9u IG9uIHRoZSBQQURESU5HIGJ1dCBhcmUgc3RpbGwgd29ya2luZyB0aHJvdWdoIHNvbWUgb2YgdGhl IGNvbW1lbnRzIHJhaXNlZCBpbiBESVNDVVNTLiAgV2UgaG9wZSB0byBoYXZlIHRoaXMgZmluaXNo ZWQgYWZ0ZXIgZmluYWxpemluZyBTVFVOLCB3aGljaCBzaG91bGQgYmUgdmVyeSBjbG9zZS4NCj4+ Pj4gDQo+Pj4+IENoZWVycywNCj4+Pj4gDQo+Pj4+IEdvbnphbG8NCj4+Pj4gDQo+Pj4+PiBPbiBG ZWIgMTgsIDIwMTksIGF0IDg6MTcgQU0sIEdvbnphbG8gQ2FtYXJpbGxvIDxHb256YWxvLkNhbWFy aWxsb0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBIaSBHb256YWxvIFMsDQo+ Pj4+PiANCj4+Pj4+IHdoYXQgaXMgdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoaXM/DQo+Pj4+PiAN Cj4+Pj4+IENoZWVycywNCj4+Pj4+IA0KPj4+Pj4gR29uemFsbw0KPj4+Pj4gDQo+Pj4+PiBPbiAx OC1KYW4tMTkgMjA6MTIsIEdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSkgd3JvdGU6DQo+Pj4+ Pj4gVGhhbmtzLCBTcGVuY2VyLiAgV2Ugd2lsbCBwcm9jZWVkIHdpdGggYnJpbmdpbmcgdGhlIGRl ZmluaXRpb24gb2YNCj4+Pj4+PiBQQURESU5HIGludG8gdGhlIGN1cnJlbnQgZHJhZnQuDQo+Pj4+ Pj4gDQo+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+IA0KPj4+Pj4+IEdvbnphbG8NCj4+Pj4+PiANCj4+ Pj4+Pj4gT24gSmFuIDE0LCAyMDE5LCBhdCA5OjI1IEFNLCBTcGVuY2VyIERhd2tpbnMgYXQgSUVU Rg0KPj4+Pj4+PiA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20gPG1haWx0bzpzcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+DQo+Pj4+Pj4+IHdyb3RlOg0KPj4+Pj4+PiANCj4+Pj4+ Pj4gSGksIEdvbnphbG8sDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBPbiBNb24sIEphbiAxNCwgMjAxOSBh dCA4OjA1IEFNIEdvbnphbG8gQ2FtYXJpbGxvDQo+Pj4+Pj4+IDxnb256YWxvLmNhbWFyaWxsb0Bl cmljc3Nvbi5jb20NCj4+Pj4+Pj4gPG1haWx0bzpnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nvbi5j b20+PiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICBXaGF0IGlzIHRoZSBuZXh0IHN0ZXAgaGVy ZT8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+ICBHb256YWxvDQo+Pj4+Pj4+IA0KPj4+Pj4+PiAgT24gMTMt RGVjLTE4IDE2OjI3LCBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiB3cm90ZToNCj4+Pj4+Pj4+IEhp LCBTaW1vbiwgDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE9uIFRodSwgRGVjIDEzLCAyMDE4IGF0IDc6 MTIgQU0gU2ltb24gUGVycmVhdWx0DQo+Pj4+Pj4+PiA8U2ltb24uUGVycmVhdWx0QGxvZ21laW4u Y29tDQo+Pj4+Pj4+ICA8bWFpbHRvOlNpbW9uLlBlcnJlYXVsdEBsb2dtZWluLmNvbT4gPG1haWx0 bzpTaW1vbi5QZXJyZWF1bHRAbG9nbWVpbi5jb20NCj4+Pj4+Pj4gIDxtYWlsdG86U2ltb24uUGVy cmVhdWx0QGxvZ21laW4uY29tPj4+IHdyb3RlOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgICAtIFB1 bGwgdGhlIGRlZmluaXRpb24gb2YgUEFERElORyBpbnRvIHRoaXMgZG9jdW1lbnQuIERlY2xhcmUN Cj4+Pj4+Pj4gIHRoYXQNCj4+Pj4+Pj4+ICAgIHdlJ3ZlIGdhdGhlcmVkIHN1ZmZpY2llbnQgZXhw ZXJpZW5jZSB3aXRoIFBBRERJTkcgdGhhdCBpdCBub3cNCj4+Pj4+Pj4+ICAgIHdhcnJhbnRzIGJl aW5nIGVsZXZhdGVkIHRvIFN0YW5kYXJkcyBUcmFjay4gVGhhdCBpcywgaXQncyBiZWVuDQo+Pj4+ Pj4+PiAgICBwcm92ZW4gdG8gd29yay5fX19fDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgIF9fIF9f DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgIFRoaXMgaXMgcGxhdXNpYmxlLiBJdCBzb2x2ZXMgdGhl IGZpcnN0LW9yZGVyIHByb2JsZW0uIF9fX18NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgX18gX18N Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgSSBub3RlIHRoYXQgUkZDIDU3ODAgZGVmaW5lZCBhIG51 bWJlciBvZiBuZXcgYXR0cmlidXRlcy4gSXMNCj4+Pj4+Pj4gIHB1bGxpbmcNCj4+Pj4+Pj4+ICAg IFBBRERJTkcgZm9yd2FyZCB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIG9yIGFyZSB0aGVyZSBvdGhl cnMgdGhhdA0KPj4+Pj4+Pj4gICAgd291bGQgYWxzbyBxdWFsaWZ5IChzbywgcGVyaGFwcyBhIHN0 YXR1cyBjaGFuZ2UgZm9yIFJGQw0KPj4+Pj4+PiAgNTc4MCk/IF9fX18NCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gICAgX18gX18NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gICAgSSBkb27igJl0IHRoaW5rIHRo ZSBvdGhlcnMgaGF2ZSBiZWVuIGltcGxlbWVudGVkIG11Y2gsIHNvDQo+Pj4+Pj4+ICB0aGF04oCZ cyB3aHkgSQ0KPj4+Pj4+Pj4gICAgdGhpbmsgb25seSBwdWxsaW5nIFBBRERJTkcgbWFrZXMgc2Vu c2UuIElmIEkgcmVtZW1iZXINCj4+Pj4+Pj4gIGNvcnJlY3RseSwgSQ0KPj4+Pj4+Pj4gICAgb25s eSBpbXBsZW1lbnRlZCBQQURESU5HIGluIE51bWIgKEkgZG9u4oCZdCBoYXZlIGFjY2VzcyB0byB0 aGUNCj4+Pj4+Pj4gIHNvdXJjZQ0KPj4+Pj4+Pj4gICAgY29kZSBhbnltb3JlIHNvIGNhbuKAmXQg YmUgc3VyZSkuX19fXw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgICBfXyBfXw0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiAgICBBbnlvbmUgZWxzZSB3aXRoIGFuIG9waW5pb24/DQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gVGhhdCdzIGhlbHBmdWwgaW5mb3JtYXRpb24uIA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiBXZSBzaG91bGQgd2FpdCBmb3IgYW55b25lIGVsc2Ugd2l0aCBpbmZvcm1hdGlvbiB0 byB3ZWlnaCBpbiwgYnV0DQo+Pj4+Pj4+ICBpZiBpdCdzDQo+Pj4+Pj4+PiBjb3JyZWN0IHRoYXQg dGhlIG90aGVyIGV4cGVyaW1lbnRhbCBhdHRyaWJ1dGVzIGhhdmVuJ3QgYmVlbg0KPj4+Pj4+PiAg aW1wbGVtZW50ZWQNCj4+Pj4+Pj4+IGFuZCBkZXBsb3llZCBpbiBhIHdheSB0aGF0IHdvdWxkIHBy b3ZpZGUgZ3VpZGFuY2UgZm9yDQo+Pj4+Pj4+ICBzdGFuZGFyZHMtdHJhY2sNCj4+Pj4+Pj4+IHVz ZSwgSSB0aGluayBkZWZpbmluZyBQQURESU5HIGluIHRoaXMgZG9jdW1lbnQgbWFrZXMgbW9yZSBz ZW5zZQ0KPj4+Pj4+PiAgdG8gbWUNCj4+Pj4+Pj4+IHRoYW4gYWRkaW5nIGEgZG93bnJlZiB0byBh biBleHBlcmltZW50YWwgUkZDIHRoYXQgd2Ugd291bGRuJ3QNCj4+Pj4+Pj4gIGNvbnNpZGVyDQo+ Pj4+Pj4+PiBpZiB0aGUgcmVmZXJlbmNlIHdhcyB1c2luZyBhbnl0aGluZyBleGNlcHQgUEFERElO Ry4gIA0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE5vIG9uZSBoYXMgb2JqZWN0ZWQgaW4g dGhlIHBhc3QgbW9udGggKHdoaWNoIGluY2x1ZGVkIGhvbGlkYXlzLCBidXQgSQ0KPj4+Pj4+PiB3 b3VsZCBoYXZlIGFza2VkIHRoaXMgcXVlc3Rpb24gd2l0aCBhIHdlZWsgb3IgdHdvIHRpbWVvdXQs IGlmIHRoZQ0KPj4+Pj4+PiBob2xpZGF5cyBoYWQgbm90IGJlZW4gY29taW5nIHVwKS4gDQo+Pj4+ Pj4+IA0KPj4+Pj4+PiBJIHRoaW5rIGJyaW5naW5nIHRoZSBkZWZpbml0aW9uIG9mIFBBRERJTkcg aW50byB0aGUgY3VycmVudCBkcmFmdCBpcw0KPj4+Pj4+PiB0aGUgcmlnaHQgdGhpbmcgdG8gZG8u IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gSWYgVFJBTSBwZW9wbGUgdGhvdWdodCB0aGF0IHRoZSBvdGhl ciBleHBlcmltZW50YWwgYXR0cmlidXRlcyBpbiBSRkMNCj4+Pj4+Pj4gNTc4MCBkb24ndCBoYXZl IGVub3VnaCBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIHRvIGp1c3RpZnkgbW92aW5nDQo+Pj4+ Pj4+IHRoZW0gcGFzdCBFeHBlcmltZW50YWwgc3RhdHVzLCBjaGFuZ2luZyB0aGUgc3RhdHVzIG9m IFJGQyA1NzgwIHRvDQo+Pj4+Pj4+IEhpc3RvcmljIG1pZ2h0IGJlIGFwcHJvcHJpYXRlIGF0IHNv bWUgcG9pbnQsIGJ1dCB0aGF0J3Mgbm90IHJlbGF0ZWQgdG8NCj4+Pj4+Pj4gdGhlIGNvbnZlcnNh dGlvbiB3ZSdyZSBoYXZpbmcgbm93LCBhbmQgSSBoYXZlbid0IGFza2VkIGEgcXVlc3Rpb24NCj4+ Pj4+Pj4gYWJvdXQgdGhhdCwgc28gSSdsbCBpZ25vcmUgdGhhdCBmb3Igbm93Lg0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gVGhhbmtzIGZvciB5b3VyIGhlbHAgd2l0aCB0aGlzLg0KPj4+Pj4+PiANCj4+Pj4+ Pj4gU3BlbmNlcg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoYW5r cywNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gU3BlbmNlcg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgICBf X19fDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgIF9fIF9fDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAg IFNpbW9uX19fXw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+IA0KPj4+PiANCj4+IA0KDQo= From nobody Wed Apr 10 09:33:14 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329A212037D for ; Wed, 10 Apr 2019 09:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=vidyo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4t_qgulVkWA for ; Wed, 10 Apr 2019 09:33:11 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07E61203BA for ; Wed, 10 Apr 2019 09:33:09 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id w30so3583783qta.8 for ; Wed, 10 Apr 2019 09:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vidyo.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0+AP6oVr4tIc/GCn3AspbzzagZafyMM6sfhzP8g7nlo=; b=BqHbXuE0uK6MEIVorreLb4a0XpKdPtxFdBgDJ5X09loxX2NizibfTlD+lwLQwAnso2 TfqQk89ZoOFPaKHHQ7U3DmQ5fGYYpC23suOaENRB2quWv1XnEedU+x93NIn0ELLzqF+o cq0EBT1APKPizdRj+HOu24PxanzVuSfaVW8RilmTCVFnAgumWiPbaPHH8HW5HrUAOcD2 37pbC9lfEIY9+3nSwh3CtN4rbUT++Zqbw8I8Pnv9F7mKC0ortCmX6A+Fzz8y43z86d4o /ia+DIzPbFqOJ049kebTf5pQbWyuRF07l88hvsqGtp+hmU8hiUOxnpXDEqybfPYQ4XsD lzQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0+AP6oVr4tIc/GCn3AspbzzagZafyMM6sfhzP8g7nlo=; b=Q4kHOWyYw+6p+ioGOCZRGcXDCdit2eBS1UfXf8M4RWy3baRXp4fBgs6+Rs74IT2JbP QbzQ/pZWUd28ZvgvZFksCxDKOloOk2y4L1WFTuzvq3ChJ9QG/+yR3xnsmyVun48afti/ GU1dLBWOyryqH/2tv6dDiGvkCWoeV122pgSHEh+9pbuDMjnqgFMkg/fCL8xNke3U/Akk dC77vigD/NnUy5dzKpRNBRbWm1dlfCcSZWcbovQrpcal6wJ5YrpImDWPyjdVOGBWV46u 7ibI++JK/kuGvi98isQHSI0KZR0IIrWJHNoOmfGX4AhsEto4piHeTITpaXPwR7TjP6I9 KvNQ== X-Gm-Message-State: APjAAAUSe2LMSL9fifo36yx3BzLaBR7P8kFjrBNOelbvKMymjjVGBHkK DYJQJf0aJMPrImfo5FXnYXw4ug== X-Google-Smtp-Source: APXvYqysU82p035+bQbpMnoiD1OvCv/smuEpzF4O0LpjYqm51iO2kSiNYn+49Te3cfBpeQgCg+hw7Q== X-Received: by 2002:a0c:9973:: with SMTP id i48mr36706752qvd.9.1554913988511; Wed, 10 Apr 2019 09:33:08 -0700 (PDT) Received: from [172.16.1.246] ([160.79.220.2]) by smtp.gmail.com with ESMTPSA id m129sm20738392qkb.55.2019.04.10.09.33.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 09:33:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Jonathan Lennox In-Reply-To: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> Date: Wed, 10 Apr 2019 12:33:06 -0400 Cc: "tram@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A91D4E6-1507-46E9-97B7-919CD534372A@vidyo.com> References: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> To: Marc Petit-Huguenin X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [tram] New test vector for stunbis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 10 Apr 2019 16:33:13 -0000 My unit test agrees. > On Apr 7, 2019, at 12:01 PM, Marc Petit-Huguenin = wrote: >=20 > Now that IANA has allocated codepoints for stunbis, it is time to = calculate the final test vector in section B.1. It would be great is = someone could redo the calculations and assert that my results are = correct. Thanks. >=20 >=20 > .... > Username: "" and=20 > = "\xe3\x83\x9e\xe3\x83\x88\xe3\x83\xaa\xe3\x83\x83\xe3\x82\xaf\xe3\x82\xb9"= > (without quote) respectively before and after UsernameCasePreserved > [RFC8265] processing >=20 > Password: "TheMtr" and "TheMatrIX" (without > quotes) respectively before and after OpaqueString [RFC8265] = processing >=20 > Nonce: "bMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) >=20 > Realm: "example.org" (without quotes) >=20 > 00 01 00 9c Request type and message length > 21 12 a4 42 Magic cookie > 78 ad 34 33 } > c6 ad 72 c0 } Transaction ID > 29 da 41 2e } > 00 1e 00 20 USERHASH attribute header > 4a 3c f3 8f } > ef 69 92 bd } > a9 52 c6 78 } > 04 17 da 0f } Userhash value (32 bytes) > 24 81 94 15 } > 56 9e 60 b2 } > 05 c4 6e 41 } > 40 7f 17 04 } > 00 15 00 29 NONCE attribute header > 6f 62 4d 61 } > 74 4a 6f 73 } > 32 41 41 41 } > 43 66 2f 2f } > 34 39 39 6b } Nonce value and padding (3 bytes) > 39 35 34 64 } > 36 4f 4c 33 } > 34 6f 4c 39 } > 46 53 54 76 } > 79 36 34 73 } > 41 00 00 00 } > 00 14 00 0b REALM attribute header > 65 78 61 6d } > 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) > 6f 72 67 00 } > 00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header > e4 68 6c 8f } > 0e de b5 90 } > 13 e0 70 90 } > 01 0a 93 ef } HMAC-SHA256 value > cc bc cc 54 } > 4c 0a 45 d9 } > f8 30 aa 6d } > 6f 73 5a 01 } > .... >=20 > --=20 > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Apr 11 01:27:38 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF08120288; Thu, 11 Apr 2019 01:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrzGv2RqTJCF; Thu, 11 Apr 2019 01:27:32 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E97812011D; Thu, 11 Apr 2019 01:27:31 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1554970944; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:dlp-product: dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=lFs5fgXNmovVQ9/7bYqqP0UI8apZaUV4QZqgZz P/Mtw=; b=kr2ABPOvP4g2ERoQ5mTZAKBQPpIH85UDyUxQ+kuq cuwSsjxclmzbt9sjZ+wFCvTfcS3x66Ze2UC47/DzsUh8qhd9A2 95E2xk7bENdofGLvk3604B2NJvUGJrcbvGePbXwZ/f6z9tuUcw bdyAkdhHR8xJnLOEDn0sLeIUKgh1u3o= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5db5_98a3_3bc6bffc_e264_4d03_9be9_83f7d520ee3e; Thu, 11 Apr 2019 02:22:23 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Apr 2019 02:26:47 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Apr 2019 02:26:48 -0600 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Apr 2019 02:26:13 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2981.namprd16.prod.outlook.com (20.178.235.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Thu, 11 Apr 2019 08:26:12 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%4]) with mapi id 15.20.1771.014; Thu, 11 Apr 2019 08:26:12 +0000 From: "Konda, Tirumaleswar Reddy" To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiP6YtJoYwgAmD5DA= Date: Thu, 11 Apr 2019 08:26:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 70cf5d88-fd3f-4a01-6603-08d6be575b43 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2981; x-ms-traffictypediagnostic: BYAPR16MB2981: x-ms-exchange-purlcount: 22 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(39860400002)(346002)(366004)(376002)(189003)(199004)(32952001)(51914003)(51444003)(13464003)(53946003)(106356001)(110136005)(486006)(256004)(53546011)(6506007)(18074004)(81166006)(14444005)(66066001)(6246003)(86362001)(53936002)(8676002)(8936002)(52536014)(966005)(72206003)(478600001)(2906002)(81156014)(102836004)(561944003)(33656002)(14454004)(316002)(7736002)(68736007)(2201001)(99286004)(305945005)(7696005)(476003)(30864003)(6306002)(105586002)(80792005)(97736004)(26005)(6116002)(71200400001)(3846002)(74316002)(2501003)(229853002)(6436002)(25786009)(5660300002)(55016002)(9686003)(71190400001)(186003)(66574012)(151285002)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2981; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CeKCi0pBc3fCSjk6UNjwsnr2++BniGl6X1AXQ8A4MQkTjIowSqg9UnCiCxUfwVQ9D5HlfcUy06+NIc8PknbbO1wg7AlAfoqPqetp3Z8uq/WdW1SyHcJEwMc6Lx/jjIFKYwQxRn+6v37emHrGiQGr2IqWfK61iD0r/c3N0zYqTCszJwnoiwl5HDJJtnw2KI1BsBf4xGRx2Rrzl2j052VOrbmSuGxsc6yGOjNEL6eqs29Av2xEL4+Q0sJjaotQpBVi7qhLjWjMoxToVW+OTdJta22strwnWODXVMuxI7KzYcez0Ov9XcJug5kfHAgY5Jhxy9QJ6CDbawVgJSIdPpnVyvGjY1KQQRkXkYSP13qHANZZOsBqsGaQ5zShd2DdH+67j64GiTgRMBbYUJo51U8nlnS3L6CjK+lBYlxvyCmEzxc= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 70cf5d88-fd3f-4a01-6603-08d6be575b43 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 08:26:12.0188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2981 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6522> : inlines <7052> : streams <1818332> : uri <2830028> Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 08:27:36 -0000 Hi Magnus, Thanks for the detailed review. Please see inline=20 > -----Original Message----- > From: tram On Behalf Of Magnus Westerlund > Sent: Thursday, April 4, 2019 7:30 PM > To: tram@ietf.org; draft-ietf-tram-turnbis@ietf.org > Subject: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 >=20 >=20 >=20 > Hi, >=20 > I have now finished the AD review. There are a lot of details that I thin= k needs > fixing or at least feedback on. I also think there are a couple of more s= erious > issues here. Especially regarding the handling of MTU and fragmentation, = as > well as IP header fields in address family translation and with non UDP > transport. We need to conclude on these before we go to IETF last call. >=20 > My Review comments are: >=20 > A. Section 1: "The client can arrange > for the server to relay packets to and from certain other hosts > (called peers) and can control aspects of how the relaying is done." >=20 > I don't think this is an accurate description of what Turn does. One may = easily > get the impression that the whole packet TURN receives are relayed, rathe= r > than the transport protocol data part and some of the header information = are > relayed between the client <-> peer, with a knowledge of the peer transpo= rt > address for the client. I think that should be clarified in the introduct= ion. Sure, updated the text as follows: When a peer sends a packet to the relayed transport address, the server rel= ays the transport protocol data from the packet to the client. The client k= nows the peer from which the transport protocol data was relayed by the ser= ver. When the server receives an ICMP error packet, the server also relays = certain layer 3/4 header fields from the ICMP header to the client. When th= e client sends a packet to the server, the server relays the transport prot= ocol data from the packet to the appropriate peer using the relayed transpo= rt address as the source. >=20 > B. Section 2.7: >=20 > "Applications using TCP can more or less > ignore this issue because fragmentation avoidance is now a standard > part of TCP, but applications using UDP (and thus any application > using this version of TURN) must handle fragmentation avoidance > themselves." >=20 > Lower case "must", and as the document uses RFC 2119, this must have the > meaning of "MUST". A reformulation here is likely in order. Replaced "must" with "MUST".=20 >=20 > C. Section 2.7: >=20 > In this approach, the application exploits the > fact that the IP specification [RFC0791] specifies that IP packets up > to 576 bytes should never need to be fragmented. >=20 > As a guideline, sending a maximum of 500 bytes of application data in > a single TURN message (by the client on the client-to-server leg) or > a UDP datagram (by the peer on the peer-to-server leg) will generally > avoid IP fragmentation. To further reduce the chance of > fragmentation, it is recommended that the client use ChannelData > messages when transferring significant volumes of data, since the > overhead of the ChannelData message is less than Send and Data > indications. >=20 > In that first paragraph I think it is worth discussing the IPv6 requireme= nt of > supporting a 1280 minimal size. Yes.=20 >=20 > Secondly, I think recommending only a 500 MTU is way to conservative. > Those studies I have seen appears to indicate that at least 1220 bytes UD= P > payloads should be be working as well as 500 bytes. See for example figur= e 12 > in this: > https://static.googleusercontent.com/media/research.google.com/sv//pubs/a= rc > hive/46403.pdf I have updated the text as follows to address your comments: In this approach, the application MUST assume a PMTU of 1280 bytes, as IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater as specified in [RFC8200]. If IPv4 support on legacy or otherwise unusual networks is a consideration, the application MAY assume on a PMTU of 576 bytes for IPv4 datagrams, as every IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes as discussed in [RFC0791]. >=20 >=20 > D. Section 2.7: >=20 > [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that > uses STUN to discover the path MTU, and so might be a suitable > approach to be used in conjunction with a TURN server that supports > the DONT-FRAGMENT attribute. When the client includes the DONT- > FRAGMENT 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. >=20 > I want to verify that the WG is working on resolving the issues with the = STUN > PMTUD document. I definitely sees the point of the recommendation, but on= ly > if the WG will conclude on that document in a reasonable time frame. The authors of the ietf-tram-stun-pmtud draft are working on resolving the = DISCUSS from ISEG review. >=20 > E. Section 3: >=20 > Server-Reflexive Transport Address: A transport address on the > "public side" of a NAT. This address is allocated by the NAT to > correspond to a specific host transport address. >=20 > Shouldn't "public side" be replace with "external side"? That is the term= inology > used by the Behave RFCs. Okay, replaced "public side" with "external side".=20 >=20 > F. Section 3: >=20 > 5-tuple: The combination (client IP address and port, server IP > address and port, and transport protocol (currently one of UDP, > TCP, or (D)TLS)) used to communicate between the client and the > server. >=20 > I see some issues that the 5-tuple aggregates the transport protocol with= the > security protocol. I agree from the TURN protocol perspective the protoco= l > combination is the important one. However, writing like you do here you > obfuscate both that when security is in place you have a combination, as = well as > that there are 4 alternatives defined by this document. (D)TLS can be considered as pseudo transport protocol.=20 >=20 > G. Section 4.1: >=20 > The "turn" and "turns" URI schemes are used to designate a TURN > server (also known as a relay) on Internet hosts accessible using the > TURN protocol. The TURN protocol supports sending messages over UDP, > TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be > used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the > "turn" scheme MUST be used otherwise. The required part of > the "turn" URI denotes the TURN server host. The part, if > present, denotes the port on which the TURN server is awaiting > connection requests. If it is absent, the default port is 3478 for > both UDP and TCP. The default port for TURN over TLS and TURN over > DTLS is 5349. >=20 > First, I was wondering if this document needed to update RFC 7065? The hi= gh > level obvious is the reference, but otherwise on the surface it doesn't l= ook > necessary. My main complaint when reading was that it was not obvious wha= t > not specifying the transport parameter means. Then I saw this in Section = 3.1 of > RFC 7065: >=20 > The , , and components are passed without > modification to the [RFC5928] algorithm. is set to false if > is equal to "turn", and set to true if is equal to > "turns" and passed to the [RFC5928] algorithm with the other > components. >=20 > After some digging I figured out that RFC5928 is actually updated by RFC > 7350 that defines the resolution and SRV records for DTLS. >=20 > Can you please update the text in Section 4 to also reference RFC 7350 so= that > one doesn't miss this definitions. Sure, added the following line to Section 4: DTLS as a transport protocol for TURN is defined in RFC7350. >=20 > H. Section 5: >=20 > If the server requires requests to be > authenticated, then the server's administrator MUST choose a realm > value that will uniquely identify the username and password > combination that the client must use, even if the client uses > multiple servers under different administrations. >=20 > Just to verify, TURN does not allow a single server address to host multi= ple > realms do it? Each Realm needs its own unique server transport address? No, I don't see any such restriction in TURN. For example, in an Enterpris= e network with multiple realms, the TURN server based on the client subnet = can choose the realm. >=20 > I. Section 5: >=20 > For each Allocate request, the server SHOULD generate a > new random nonce when the allocation is first attempted following the > randomness recommendations in [RFC4086] and SHOULD expire the nonce > at least once every hour during the lifetime of the allocation. >=20 > So, I think this text due to its use of RFC 2119 language is a bit confus= ing in its > relation to STUNbis. To me it is unclear if the above overrides completel= y what > is written in Section 5 of STUNbis: >=20 > To indicate that it supports this specification, a server MUST > prepend the NONCE attribute value with the character string composed > of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648] > encoding of the 24 bit STUN Security Features as defined in > Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes, > with bit 0 as the most significant bit of the first byte and bit 23 > as the least significant bit of the third byte. If no security > features are used, then a byte array with all 24 bits set to zero > MUST be encoded instead. For the remainder of this document the term > "nonce cookie" will refer to the complete 13 character string > prepended to the NONCE attribute value. >=20 > Or is the randomness recommendations in TURNbis only for the NONCE > attribute value part? Yes, the randomness recommendations in TURNbis is only for the NONCE attrib= ute value part.=20 >=20 > Secondly, I interpret the text to say that compared to STUN, where a Nonc= e can > be long lived after the initial Long Term Credential establishment, in TU= RN for > each allocation one will have to to the Allocate, expired nonce->here is = your > new nonce, resend allocate using new nonce, success dance. >=20 > I think part of the problem with the above text in TURNbis is that the se= ntences > prior to the quoted one appear to be rehashing of the STUNbis requirement= s. > Then the quoted part that actually changes behavior without being clear a= bout > it. I think it would be good to make it clear what is a change compared t= o > STUNbis. No changes other than the randomness for the NONCE attribute value part. A= dded the following line for clarity: To indicate that the server supports [I-D.ietf-tram-stunbis], the server prepends the NONCE attribute value with the "nonce cookie" (Section 9.2 of [I-D.ietf-tram-stunbis]). Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-1= 8, discusses using the nonce cookie with the STUN security feature for the = NONCE attribute=20 sent in the Allocate response. >=20 > J. Section 6: >=20 > Note that, rather than storing the password explicitly, for > security reasons, it may be desirable for the server to store the key > value, which is a secure hash over the username, realm, and password > (see [I-D.ietf-tram-stunbis]). >=20 > Why isn't this recommendation stronger. Are there any reasons why a serve= r > would actually store the plain text password at all? Good point, no reason to store the plain text password. Updated text as fol= lows: For security reasons, the server MUST NOT store the password explicitly and MUST store the key value, which is a secure hash over the username, realm, and password (see Section 16.1.3 in [I-D.ietf-tram-stunbis]). >=20 > K. Section 7.1: >=20 > The client first picks a host transport address. It is RECOMMENDED > that the client pick a currently unused transport address, typically > by allowing the underlying OS to pick a currently unused port for a > new socket. >=20 > I think talk about socket in this context should be skipped as it otherwi= se have > been eliminated. The above text is from https://tools.ietf.org/html/rfc5766#section-6.1. I p= resume you are proposing the following update: =20 The client first picks a host transport address. It is RECOMMENDED that the client pick a currently unused transport address, typically by allowing the underlying OS to pick a currently unused port. >=20 > L. Section 7.1: >=20 > The client then picks a transport protocol to use between the client > and the server. The transport protocol MUST be one of UDP, TCP, TLS- > over-TCP or DTLS-over-UDP. >=20 > I find it strange that this indicates that one should pick the transport = protocol to > use client to server without considering the server capabilities. Especia= lly as the > client configuration or server discovery procedures will indicate transpo= rt > protocol support. The server may support more than one transport protocol.=20 >=20 > Secondly, what is the motivation for the MUST in the second sentence? > This is appears to have strange interactions with any future extensions a= nd > have no impact. A client must obvious chose a client to server transport > protocol it supports, and one that the server supports or the client hope= it will > support. https://tools.ietf.org/html/rfc5766#section-6.1 has the same text, I have u= pdated the text as follows: The client then picks a transport protocol to use between the client and th= e server based on the transport protocols supported by the server. =20 The TURN server MUST enable one of the transport protocols, UDP, TCP, TLS- = over-TCP or DTLS-over-UDP. >=20 > M. Section 7.1: >=20 > The client also picks a server transport address, which SHOULD be > done as follows. The client uses one or more procedures described in > [RFC8155] to discover a TURN server and uses the TURN server > resolution mechanism defined in [RFC5928] to get a list of server > transport addresses that can be tried to create a TURN allocation. >=20 > 1) So RFC 8155 states that it has no recommendation on server selection, = nor > on how to related local configuration to any auto-discovery servers. > To me it appears that the protocol utilizing TURN should consider what ma= kes > sense in their deployments. Thus, does the need for such consideration ne= eds to > be highlighted somewhere in this specification. https://tools.ietf.org/html/rfc8155#section-3 discusses using auto-discover= y in the absence of local configuration or if the local configuration does = not work. https://tools.ietf.org/html/rfc8155#section-9 explains the mechan= isms to authenticate the discovered TURN server. =20 I am not sure about the additional considerations you are looking in this s= pecification. >=20 > 2) The RFC5928 reference should be complemented with an RFC 7350 > reference. Done. >=20 > N. Section 7.1: >=20 > Clients MUST NOT include a REQUESTED-ADDRESS- > FAMILY attribute in an Allocate request that contains a RESERVATION- > TOKEN attribute, for the reasons outlined in [RFC6156]. >=20 > Considering that this document obsoletes RFC 6156, I think it is bad form= to > reference that document, rather than to move the necessary motivation int= o > this document. Done, updated text as follows: Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Allocat= e request that contains a RESERVATION-TOKEN attribute, for the reason that = server uses the previously reserved transport address corresponding to the = included token and the client cannot obtain a relayed transport address of = a specific address type. >=20 > O. Section 7.1: >=20 > If the client wishes to obtain a relayed transport address of a > specific address type then it includes a REQUESTED-ADDRESS-FAMILY > attribute in the request. >=20 > I don't find anything describing what the default behavior is if one does= n't > include the attribute, but the TURN server supports multiple address fami= lies. >=20 > I see that bullet 7 in Section 7.2 indicates that IPv4 is default. > Should the text in 7.1 be explicit about this default? The text in Section 7.1 is added for TURN clients not supporting TURNbis sp= ecification to provide backward compatibility.=20 >=20 > P. Section 7.2: >=20 > Otherwise, if the attribute is included but > specifies a protocol other that UDP, the server rejects the > request with a 442 (Unsupported Transport Protocol) error. >=20 > Assuming that you don't support an extension for that transport protocol. > Should that be made explicit? I did not get the above comment. The attribute REQUESTED-TRANSPORT is origi= nally defined in TURN (see https://tools.ietf.org/html/rfc5766#section-6.2)= , and TURNbis does not update the use of the attribute. >=20 > Q. Section 8.3: >=20 > If the client receives a success response to its Refresh request with > a non-zero lifetime, it updates its copy of the allocation data > structure with the time-to-expiry value contained in the response. >=20 > If the client receives a 437 (Allocation Mismatch) error response to > a request to delete the allocation, then the allocation no longer > exists and it should consider its request as having effectively > succeeded. >=20 > So there are no considerations for the client if it receives an error res= ponse to a > refresh request when Lifetime was non-zero? >=20 > I am bit surprised by that. I assume that there are certain cases when th= e > request could be resent, and others where the meaning is that the allocat= ion is > gone. TURNbis does not update the refresh behavior already defined in https://too= ls.ietf.org/html/rfc5766#section-7.3. I will add the following line: If the client receives an error response to its request to refresh the allo= cation, it should consider the allocation no longer exists. >=20 > R. Section 11.5: >=20 > When the server receives an ICMP packet, the server verifies that the > type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either > 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the > IP packet in the ICMP packet payload contains a UDP header. If > either of these conditions fail, then the ICMP packet is silently > dropped. >=20 > Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter > Problem are for ICMPv4? I don't get the above comment, please explain the question with an example.= =20 >=20 > S. Section 12.5: >=20 > Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to > a multiple of four bytes in order to ensure the alignment of > subsequent messages. The padding is not reflected in the length > field of the ChannelData message, so the actual size of a ChannelData > message (including padding) is (4 + Length) rounded up to the nearest > multiple of 4. Over UDP, the padding is not required but MAY be > included. >=20 > Are there anywhere written what one may or may not include of the TURN > related messages in a single UDP datagram. Because it is technically feas= ible I > belive to include two Send Indications in one UDP datagram to the server. As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-11.2,= one send indication in one UDP datagram to the server. >=20 > T. Section 13.1: >=20 > Flow Label >=20 > Preferred behavior: The relay sets the Flow label to 0. The relay > can choose to set the Flow label to a different value if it > supports the IPv6 Flow Label field [RFC6437]. >=20 > Alternate behavior: The relay sets the Flow label to the default > value for outgoing packets. >=20 > I think this section should be improved in two ways. >=20 > First of all I think it should clarify that each allocation to peer flow = is its own > IPv6 Flow in perspective of the IPv6 Flow label. >=20 > Secondly, I think in the spirit of RFC 6473 the preferred behavior should= be to > set the IPv6 flow label if the implementation is capable, or leave it to = the > underlying network stack to actually set it. Compared to RFC 7915, the TU= RN > server actually have an understanding of what are different flows without > having examining additional protocol layers. Updated text as follows: Preferred behavior: The TURN server can use the relayed transport address, peer transport addre= ss and UDP protocol number=20 to generate and set the flow label value in the IPv6 packet as discussed in= Section 3 of [RFC6437]. If the TURN server is incapable of=20 generating the flow label value from the IPv6 packet's 5-tuple, it sets the= Flow label to 0.=20 (Please note the proposed update deviates from the behavior defined https:/= /tools.ietf.org/html/rfc6156#section-8.1) =20 >=20 > Thirdly, I don't understand what the alternative behavior actually is. > This as it is either setting it to 0, or classifying things as flow and t= hen provide it > with a random flow label. I think the right alternative behavior is to se= t it 0. Updated text to say: Alternate behavior: The relay sets the Flow label to the default value of zero for outgoing packets. >=20 > U. Section 13. 1,2,3: >=20 > For both preferred and alternate behavior, the DONT-FRAGMENT > attribute MUST be ignored by the server. >=20 > I don't understand why just because one performs v4<->v6 or v6 to v4 > translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT > attribute. If the client has request to not fragment and the server is un= able to > do that when forwarding to the peer it needs to generate an ICMP attribut= e > response saying the packet is to big. Otherwise the relay breaks the Path= MTU > discovery mechanisms. TURNbis is using the translation algorithms specified in RFC7915.=20 [a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header to = not fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#secti= on-4), DON'T-FRAGMENT attribute can be ignored.=20 [b] For IPv6 to IPv4: The translation algorithm in https://tools.ietf.org/h= tml/rfc7915#section-5 is used. If the IPv6 endpoint wants to discover the = path MTU, it will send IPv6 packets without Fragment header and DON'T-FRAGM= ENT attribute can be ignored. [c] For IPv6 to IPv6: If the IPv6 endpoint wants to discover the path MTU, = it will send IPv6 packets without Fragment header and DON'T-FRAGMENT attrib= ute can be ignored. Please note ignoring the DONT-FRAGMENT attribute is picked from https://too= ls.ietf.org/html/rfc6156#section-8 and discussed in the BEHAVE WG https://m= ailarchive.ietf.org/arch/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc. =20 >=20 > V. Section 13.2: >=20 > Fragmentation: >=20 > If the incoming packet included a Fragment header and the outgoing > packet size exceeds the outgoing link's MTU, the relay MUST > fragment the outgoing packet into fragments of no more than 1280 > bytes. The relay sets the fields of the Fragment header as > appropriate for a packet originating from the server. >=20 > Is really the intention here to refragment the packet without providing a= ny > indication that the practical MTU is smaller than what the peer or client= thinks > it is? Yes, TURNbis is following the existing behavior already defined in https://= tools.ietf.org/html/rfc6156#section-8.1.=20 >=20 > W. Section 14: >=20 > Preferred Behavior: Set the outgoing value to the incoming value, > UNLESS the server is doing Active Queue Management, the incoming > ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server > wishes to indicate that congestion has been experienced, in which > case set the outgoing value to CE (=3D0b11). >=20 > First of all do you have any special meaning with all capital UNLESS? >=20 > Secondly, I don't know how wise it is to have partial definitions of what= the ECN > behavior is. Maybe simpler to say that that the relay is performing AQM i= t can > support the ECN marking behavior as defined in RFC 3168. The above text is same as https://tools.ietf.org/html/rfc5766#section-12, r= eplaced "UNLESS" with "unless". >=20 > X. Section 14: >=20 > How are these IP level fields handled when the transport is TCP or TLS/TC= P? > There there are not necessary a one to one mapping between datagrams and > TCP packets. And if there are no support then there are need for clarific= ation of > behaviors when using TCP based transport. Section 14 already clarifies that the descriptions in this section do not a= pply to TURN messages sent over TCP or TLS transport from the server to the= client. >=20 > Y. Section 16.4. DATA >=20 > The DATA attribute is present in all Send and Data indications. The > value portion of this attribute is variable length and consists of > the application data (that is, the data that would immediately follow > the UDP header if the data was been sent directly between the client > and the peer). If the length of this attribute is not a multiple of > 4, then padding must be added after this attribute. >=20 > Can you please clarify if one would get all the remaining bytes of the IP= packet > payload or only the number of bytes the UDP length field indicates ? >=20 > The reason I ask is that there is possibility that there are a discrepanc= y between > these fields, something the proposal for an experimental specification fo= r UDP > options attempt to utilize. > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ >=20 > Note, I only want you to clarify what is actually included. I would assum= e using > the UDP length field makes sense in this case. The application data does not include the options discussed in draft-ietf-t= svwg-udp-options. =20 Please clarify the specific update you are looking in this section.=20 >=20 > Z. The use of "relay" in the meaning of "Turn Server". There are many > occurrences of relay in this meaning. Either make it explicit to be a syn= onym or > change it to server. Sure, updated draft. >=20 > AA. Section 16.7 >=20 > rffu is lacking a definition. I would suggest making it upper case and co= py the > definition from 16.8. Updated. >=20 > AB. Section 16.12: >=20 > Rsvd in Format figure does not match definition below which uses "Reserve= d". Fixed. >=20 > AC. Section 16.12: >=20 > Reason Phrase (variable). This field is under defined. First of all the f= ormat of > the text string is not defined, which it is in Stunbis Error-Code attribu= te is > defined as. >=20 > The reason phrase MUST be a UTF-8 [RFC3629] encoded > sequence of less than 128 characters (which can be as long as 509 > bytes when encoding them or 763 bytes when decoding them). Thanks, updated section to use UTF-8 encoding. =20 >=20 > Secondly, I think it might be worth pointing out the padding here. It is = not clear > if there is any form of string termination and how the padding which will= be > interpreted as NULL characters 0-3 depending on the alignment. I note thi= s > later issue appears to be existing in STUNBis also. Padding is discussed in STUN for variable length attributes, please see htt= ps://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14. =20 >=20 > AD. Section 16.2: >=20 > Why isn't the text here say that this attribute may also be used to indic= ate the > desired lifetime in allocation requests? https://tools.ietf.org/html/rfc5766#section-14.2 did not discuss desired li= fetime. Anyways, added the following line: The TURN client can include the LIFETIME attribute with the desired lifetim= e in Allocate and Refresh requests. >=20 > AE. Section 16.9: DONT-FRAGMENT >=20 > I think it would be good to indicate the use of the attribute in Allocate= Requests > also. The above point is discussed in Section 7.1: If the client wishes to later use the DONT-FRAGMENT attribute in one or more Send indications on this allocation, then the client SHOULD include the DONT-FRAGMENT attribute in the Allocate request. This allows the client to test whether this attribute is supported by the server. >=20 > AF. Section 24.2 >=20 > [Protocol-Numbers] > "IANA Protocol Numbers Registry", 2005, > . >=20 > This is a normative reference based on how it is used in Section 16.8. Okay, moved as Normative reference. >=20 > AG. Seciton 18. >=20 > Sometime before the 20 minute lifetime is up, the client refreshes > the allocation. This is done using a Refresh request. As before, > the client includes the latest username, realm, and nonce values in > the request. The client also includes the SOFTWARE attribute, > following the recommended practice of always including this attribute > in Allocate and Refresh messages. When the server receives the > Refresh request, it notices that the nonce value has expired, and so > replies with 438 (Stale Nonce) error given a new nonce value. The > client then reattempts the request, this time with the new nonce > value. This second attempt is accepted, and the server replies with > a success response. Note that the client did not include a LIFETIME > attribute in the request, so the server refreshes the allocation for > the default lifetime of 10 minutes (as can be seen by the LIFETIME > attribute in the success response). >=20 > I notice that this part nor the text before appears to discuss the permis= sion > lifetime that will expire after 5 minutes. Thus, it needs to be refreshed= prior to > the Allocation. I have added text to discuss refreshing the channel binding, https://tools.= ietf.org/html/rfc5766#section-16 did not discuss refreshing the permissions= and channel bindings. =20 >=20 > AH. Section 18. >=20 > I am missing any example having to do with Address Family interactions. There was no ask from the WG members to add an example and even https://too= ls.ietf.org/html/rfc6156 did not have an translation example. >=20 > AI. DTLS Cipher Suits >=20 > Am I understanding it correct that the definition of what DTLS cipher sui= t that a > TURN Server currently is to support is the ones in RFC 7525 ? No, the cipher suites and (D)TLS profile is discussed in https://tools.ietf= .org/html/draft-ietf-tram-stunbis-21#section-6.2.3 and it follows the recom= mendations in RFC7525.=20 >=20 > In that case, I think the wording is a bit weak as the only reference I f= ind are in > Section 2.1: >=20 > If (D)TLS transport is > used between the TURN client and the TURN server, the guidance given > in [RFC7525] MUST be followed to avoid attacks on (D)TLS. RFC7525 provides various recommendations to avoid attacks on (D)TLS. Best Regards, -Tiru >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Apr 11 06:02:51 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E511201B8 for ; Thu, 11 Apr 2019 06:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.441 X-Spam-Level: X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JtxRXZuRcRn for ; Thu, 11 Apr 2019 06:02:48 -0700 (PDT) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 964F41200D8 for ; Thu, 11 Apr 2019 06:02:48 -0700 (PDT) Received: from [IPv6:2601:648:8400:8e7d:21c0:fced:89cb:5569] (unknown [IPv6:2601:648:8400:8e7d:21c0:fced:89cb:5569]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1EEBFAE5F4; Thu, 11 Apr 2019 15:02:45 +0200 (CEST) To: Jonathan Lennox Cc: "tram@ietf.org" References: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> <8A91D4E6-1507-46E9-97B7-919CD534372A@vidyo.com> From: Marc Petit-Huguenin Openpgp: preference=signencrypt Autocrypt: addr=petithug@acm.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtCZNYXJjIFBldGl0 LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPokCOAQTAQgAIgIbIwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AFAlfy11wACgkQKcRFldZqfsRWqBAAu/61DGo+j38UefTKnEse0mftPBXa S4lre7vknn33MI0L5QXmiM8zRs9FOKSuXPx0EV+JhI4pWZGW/2MJPuyifXHvnIChcdGInN8J GBdTLZSOgdDFZL9msO+QUsvMA8ZUsqlKOEcVL1NyoLupblCWNq4fYhBCx1zDwX9LZSuGn8lZ Mk8a4QFGoR6dWKaOxeCwnoquW5IK1CfRIhYjHfQMjA5gY0H46F0iCqBaFF/S7krQwIJd0XN4 YbSL4KOrWuxtgQ+iH/iaxxBXgJ1blBNRzXaWJBF4PHv23nSnEzWO17j+uVMaHJu7ycYEf8T9 pVc0xcok1BM2rCrNE5FUFAzsUtAtBZEEK6sSIeOhRG93uD/Hv1hrWzEwf+Z7B1tVQLCQQ4kL 7wyS7SXI/JTuW2xTEGCmwMeWYGERdkgsatmx4zi5nVHDjt3/mlPMj4L+u05SkI2iV4W6xxU1 jHlBIJDs7AVM0dsxzTyIPf2Sz843WyHuBgkoCskxGfOwlkZzDX9rwcWRKal1wjy1w/25LsBY U50INandw3UbrS2I73VX8ARI8uOWZrW7uzRLf8EmuPhtSQ35ThmdoNSgGMP9EXwNgzi/i+5G hbX5KbrSLG9SITFJEcJA4tnwu3nqmBh7D7vbd5ln5X7rmqPdyjidt0zcSjvuaBA+nkmakA4A O+choWy5Ag0EToyH3AEQAL+LguHhcSDCL/IevdcvH/5/fzO2fmuuTxdGwrZZSm7l6/HD2Ira h6Wpa1LvVeRbnsRq8k6O8/i3wVapEoQPmNY3vjWfXaJb8R4vHcqgcxw9N9jhZa+mvGJk9+cI ilDyPzHRBBID4d/3oFKQCQ4Y2SIkO66znPhfBOS2f2AU7AtXHhVEyj6WsLK6boEMcj7j+w5a es2nZam0jhgoz+4DQem4uk8outrRlboGnZN7A2kCNuy39UeOp7BpvQ95IKcJCIeSoiJt2A4B NPQroqhW0zGn9Y9FJ9UiZ9YIeNPYbscUxxvrD+OU9Jv67hW0v3KfvoIKDwVKpO3MW6o+1teS Gt1KCSz+CvGJCvIxfCk7S5K5SBne7ZNKz7rkGXYIzlyr7ZoEgRHmqGmcK/sHTS4e6g2pQQrR USkspyqLZl5Uzmg7yI5oGBL0aHTzYdDkkOKMRXYnl7ivBeNtGcniGqlONLJxpbwec8j7hLRq pXFuepbtPqX/GefuK8rdo+ppEqpRJ50cJTegchTfWfSjn5/mG1B4Oz9OnOcBEeTLO729n0K9 BeTx1pmisD6P/fyrqZZTozDwVEi7Wo9AOaqWOhuTe8L0FlFIk6fc/yM0wzvDWP7sNrevEYHK V9rd+Yc/Jjt293J4uayrt6DNMmSkAw3nlBq3uK5d54J0FAsAUcsE/W2/ABEBAAGJAh8EGAEI AAkCGwwFAlfy11wACgkQKcRFldZqfsSQyA/+Kx3eWtKyb/y35TjgtjT/Hrtw+aIpr1uK97LA ln1j5m7+lQ/jh0/rvSZjs+YQMYLqVGI8oaaF/u+qrokkU6pfrhVZ49D1BmmSTMBSYgnBDYqZ yZ+uzQnnDYt/mpo2OLbl9BhuifR5QXLp43cE1FIhyDT46wfse5tNZ+ll4m4HtXuTw4W3b4cP Hto10260Mki7hXbkDMZ+icBFDMkrrZyYHSnBhelzIM7XnY7A/XZdulfFcDXEcZhAFEv3ylJs xTnGwzDyP1VAdBFL3hpP1CqfP1Kti4hKcxXZYbIgTSsBjcYbPchw3ktUTU29I/nWKH5gmD+q wFizyhtt8Qhl6U67OdZ/XbRGBXs/7tlYJIGiGZyG7IQtDOX0PsVd+6WRcDdFqkpBwYkxU8gd iCeW+YTQ5d8mXXPT2dhFAeK2hCFa2+IdaXvH8ovjZpTMeKstHrWJUDaSqQ4GFT676DbDyqtm P6Ul9cjGVtXIs64FWqR9wrbwBH1GuIHhDmG9sN5AkyB9mxXaEG3uG4E6qQeedtIKC6p+ebAs aTGgztFWMJDC8LUznu7B0oyWxNVoE/RGt5mesOeAtqYr6Jtdh7unyk8BYP1y4e+SSMwvtwh+ 69tJwNhGYbOJrdX34tXNAKb6r/rFRjVJm+sPPs5ok7LddvV35o+Fho0LRNDsioDV3HytlhA= Message-ID: <935c3056-e975-27aa-10b3-4a5673865913@acm.org> Date: Thu, 11 Apr 2019 06:02:36 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <8A91D4E6-1507-46E9-97B7-919CD534372A@vidyo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kaba6GwoFkaBcXjZywqLErYbTTmZtV8TT" Archived-At: Subject: Re: [tram] New test vector for stunbis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 11 Apr 2019 13:02:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kaba6GwoFkaBcXjZywqLErYbTTmZtV8TT Content-Type: multipart/mixed; boundary="pdCw8XLlXUW7IXfuMbTDatcNV8Nyk9uBc"; protected-headers="v1" From: Marc Petit-Huguenin To: Jonathan Lennox Cc: "tram@ietf.org" Message-ID: <935c3056-e975-27aa-10b3-4a5673865913@acm.org> Subject: Re: [tram] New test vector for stunbis References: <12edea4c-b376-f6f6-30c0-ee8670ee4bed@acm.org> <8A91D4E6-1507-46E9-97B7-919CD534372A@vidyo.com> In-Reply-To: <8A91D4E6-1507-46E9-97B7-919CD534372A@vidyo.com> --pdCw8XLlXUW7IXfuMbTDatcNV8Nyk9uBc Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Thank you. On 4/10/19 9:33 AM, Jonathan Lennox wrote: > My unit test agrees. >=20 >> On Apr 7, 2019, at 12:01 PM, Marc Petit-Huguenin wr= ote: >> >> Now that IANA has allocated codepoints for stunbis, it is time to calc= ulate the final test vector in section B.1. It would be great is someone= could redo the calculations and assert that my results are correct. Tha= nks. >> >> >> .... >> Username: "" and=20 >> "\xe3\x83\x9e\xe3\x83\x88\xe3\x83\xaa\xe3\x83\x83\xe3\x82\xaf\xe3\x82\= xb9" >> (without quote) respectively before and after UsernameCasePreserved >> [RFC8265] processing >> >> Password: "TheMtr" and "TheMatrIX" (without >> quotes) respectively before and after OpaqueString [RFC8265] processin= g >> >> Nonce: "bMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) >> >> Realm: "example.org" (without quotes) >> >> 00 01 00 9c Request type and message length >> 21 12 a4 42 Magic cookie >> 78 ad 34 33 } >> c6 ad 72 c0 } Transaction ID >> 29 da 41 2e } >> 00 1e 00 20 USERHASH attribute header >> 4a 3c f3 8f } >> ef 69 92 bd } >> a9 52 c6 78 } >> 04 17 da 0f } Userhash value (32 bytes) >> 24 81 94 15 } >> 56 9e 60 b2 } >> 05 c4 6e 41 } >> 40 7f 17 04 } >> 00 15 00 29 NONCE attribute header >> 6f 62 4d 61 } >> 74 4a 6f 73 } >> 32 41 41 41 } >> 43 66 2f 2f } >> 34 39 39 6b } Nonce value and padding (3 bytes) >> 39 35 34 64 } >> 36 4f 4c 33 } >> 34 6f 4c 39 } >> 46 53 54 76 } >> 79 36 34 73 } >> 41 00 00 00 } >> 00 14 00 0b REALM attribute header >> 65 78 61 6d } >> 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) >> 6f 72 67 00 } >> 00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header >> e4 68 6c 8f } >> 0e de b5 90 } >> 13 e0 70 90 } >> 01 0a 93 ef } HMAC-SHA256 value >> cc bc cc 54 } >> 4c 0a 45 d9 } >> f8 30 aa 6d } >> 6f 73 5a 01 } >> .... >> --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --pdCw8XLlXUW7IXfuMbTDatcNV8Nyk9uBc-- --Kaba6GwoFkaBcXjZywqLErYbTTmZtV8TT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAlyvOvMACgkQKcRFldZq fsQbNA//YR3o9VaSmtNxqRwrlB/n7oHT3dZEWwZnT7pL+1eKKdUmZbzC7z4nhh28 SAKO+cUoUEmPSjkpJ8GXRdVY6dZQYqAIlK3J2K0COY0jx6k0o6L3OxQ9RCqWAfWm ndfMusjrugdQ0EId6UExE+vtoBbHRZ5OyTJjtxwFLJZxmJe2CPrsa9Hrzco0hIV0 xdSlzM2Ej9Q9j5mfSaAKKqpfz6xmHmFZaezdgEiEGQDfIXm68ZnJRPNMNQnCIopB A101m4VbE2pDTqHz3Cdf7tbTfOm2amWX042i0MoBn9RP76ZrTv9U4CiCc5ICklU8 Tzrg5APUkSLVcnNTijmJ1PQS25GeJy9NSrR7A5nGCu3wvS4rA9asxtvdsGEmtObs VuPNGyw6KZpVNsRwhvKpCvsOp2ItB/ch4i5/RUlUXnChoNerTIN49/YQquVjayNK ITB7YRLh2YIPJ0N8Q/8sO3Ng9HQDygMXHoYiKRvlSku4JxKj0/ITjez3mWjosYyI yDhxrjE5ltJmb1SpfKRGfUSRLzV3ALY78XEl+3Qs9vo/BidKiJYJ+rlqKNPzph+1 +kiAARZTcItBNPCCfc9h8tlagtLzxGkjm3AKM/bzFSf+N2rFlRoIwDkakUOP8P25 SLqcdusiCf5AtHoeZZVfHKv7TRaxCVsSDHS9x85avGdOEYN4FKU= =vXjm -----END PGP SIGNATURE----- --Kaba6GwoFkaBcXjZywqLErYbTTmZtV8TT-- From nobody Mon Apr 15 03:39:30 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6D12008D; Mon, 15 Apr 2019 03:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC71u9ySaETb; Mon, 15 Apr 2019 03:39:25 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30056.outbound.protection.outlook.com [40.107.3.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700E612006A; Mon, 15 Apr 2019 03:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qIxdXJ4H3M+DxjZ+wdHTTt+yfLm9KXdcUvxVHo95FVg=; b=kSRRWRy9gNQPTbk/eMU3pRx2yP2sfgTNdsyZzi0PZFqrtGcgsCPjSbB6rbkHWZGT/dyPhuqxEJ2sU6jA3JcNteoAMzmzf1ilY8QrH8CqQG+Takp80HSZwTP6a0EGyrzVFGBbSAfLx4SI4Leb64EOq29Rlsu7+f2EX/sJ17yR2xY= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1PR0702MB3802.eurprd07.prod.outlook.com (52.133.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 10:39:20 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 10:39:20 +0000 From: Gonzalo Camarillo To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Mon, 15 Apr 2019 10:39:20 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-originating-ip: [37.136.23.131] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 87448c2c-2bdc-4a68-1601-08d6c18e9e8e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0702MB3802; x-ms-traffictypediagnostic: HE1PR0702MB3802: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(366004)(396003)(136003)(189003)(199004)(51444003)(51914003)(97736004)(81166006)(8936002)(30864003)(8676002)(81156014)(66574012)(446003)(450100002)(561944003)(486006)(68736007)(6246003)(186003)(2201001)(53936002)(6506007)(53946003)(26005)(53546011)(86362001)(74316002)(102836004)(476003)(105586002)(9686003)(6306002)(106356001)(305945005)(7736002)(55016002)(316002)(110136005)(44832011)(52536014)(76176011)(2501003)(478600001)(14454004)(99286004)(2906002)(229853002)(6436002)(5660300002)(7696005)(33656002)(25786009)(71190400001)(18074004)(256004)(66066001)(71200400001)(14444005)(3846002)(966005)(6116002)(151285002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3802; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dlXv6Ew1uBg7yLEGGXBXAA2YZDfib8JNuoNUYTAzH03z8bAMYb0cCz51hWx9sCWjhoA/3OhPnRjmFYEwkLNHQ+M80soetKShARTqlUFaWHfc9LLcXUI2H1x8iKv5Pti8GvfHOsNSuitnIbtf6u/6EPZFfRKhUf5koUCIR4mHXSwXubf0/d3De/6HM8rcJxpt7QG+Yddyn0le0G7/XSJXc/pcSdlS9DH5+bOKw6pSm6aVAIVBtpoRFYwqoy/ZBbunVr5liyYLKr64eF2EUbRqdDMVCH8X8ELHjMXUQSThW/kHwkoYgykmVhGg0ZScv2QPeMtJvQl6tJg2XRav4oUWuQxcUtYhXJ/NHRGbpqnafmFSqfDYWYEs1Kc8zeILYKR3QND6BMIfFFdyGXnCjwzAPJpVicleKFvW3Ba5VxzONXs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 87448c2c-2bdc-4a68-1601-08d6c18e9e8e X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 10:39:20.7191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3802 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 10:39:28 -0000 Authors of TURNbis,=0A= =0A= could you please look into this and let us know your time plan to=0A= address Magnus's review? Thanks!=0A= =0A= Cheers,=0A= =0A= Gonzalo=0A= =0A= On 05-Apr-19 11:20, Gonzalo Camarillo wrote:=0A= > Thanks for the review, Magnus!=0A= > =0A= > Authors, could you please look into Magnus's comments and provide him=0A= > with responses?=0A= > =0A= > Thanks,=0A= > =0A= > Gonzalo=0A= > =0A= > On 05-Apr-19 10:11, Magnus Westerlund wrote:=0A= >> Hi,=0A= >>=0A= >> One addition.=0A= >>=0A= >> Section 16.13. ICMP Attribute=0A= >>=0A= >> This attribute is flawed as it lacks a data part to carry values certain= =0A= >> codes have. I specifically think of ICMPv6 Type =3D 2, Packet Too Big.= =0A= >> That message has a 32-bit unsigned integer carrying the MTU of the Next= =0A= >> Hop Link that causes the ICMP message to be sent. That really should be= =0A= >> replicated back to the client.=0A= >>=0A= >> There is also the question if ICMP messages for Parameter Problem should= =0A= >> included the pointer?=0A= >>=0A= >> I really think there need to be a 32-bit data field with the ICMP=0A= >> attribute.=0A= >>=0A= >> Cheers=0A= >>=0A= >> Magnus=0A= >>=0A= >>=0A= >> On 2019-04-04 16:00, Magnus Westerlund wrote:=0A= >>> Hi,=0A= >>>=0A= >>> I have now finished the AD review. There are a lot of details that I=0A= >>> think needs fixing or at least feedback on. I also think there are a=0A= >>> couple of more serious issues here. Especially regarding the handling o= f=0A= >>> MTU and fragmentation, as well as IP header fields in address family=0A= >>> translation and with non UDP transport. We need to conclude on these=0A= >>> before we go to IETF last call.=0A= >>>=0A= >>> My Review comments are:=0A= >>>=0A= >>> A. Section 1: "The client can arrange=0A= >>> for the server to relay packets to and from certain other hosts=0A= >>> (called peers) and can control aspects of how the relaying is done."= =0A= >>>=0A= >>> I don't think this is an accurate description of what Turn does. One ma= y=0A= >>> easily get the impression that the whole packet TURN receives are=0A= >>> relayed, rather than the transport protocol data part and some of the= =0A= >>> header information are relayed between the client <-> peer, with a=0A= >>> knowledge of the peer transport address for the client. I think that=0A= >>> should be clarified in the introduction.=0A= >>>=0A= >>> B. Section 2.7:=0A= >>>=0A= >>> "Applications using TCP can more or less=0A= >>> ignore this issue because fragmentation avoidance is now a standard= =0A= >>> part of TCP, but applications using UDP (and thus any application=0A= >>> using this version of TURN) must handle fragmentation avoidance=0A= >>> themselves."=0A= >>>=0A= >>> Lower case "must", and as the document uses RFC 2119, this must have th= e=0A= >>> meaning of "MUST". A reformulation here is likely in order.=0A= >>>=0A= >>> C. Section 2.7:=0A= >>>=0A= >>> In this approach, the application exploits the=0A= >>> fact that the IP specification [RFC0791] specifies that IP packets u= p=0A= >>> to 576 bytes should never need to be fragmented.=0A= >>>=0A= >>> As a guideline, sending a maximum of 500 bytes of application data i= n=0A= >>> a single TURN message (by the client on the client-to-server leg) or= =0A= >>> a UDP datagram (by the peer on the peer-to-server leg) will generall= y=0A= >>> avoid IP fragmentation. To further reduce the chance of=0A= >>> fragmentation, it is recommended that the client use ChannelData=0A= >>> messages when transferring significant volumes of data, since the=0A= >>> overhead of the ChannelData message is less than Send and Data=0A= >>> indications.=0A= >>>=0A= >>> In that first paragraph I think it is worth discussing the IPv6=0A= >>> requirement of supporting a 1280 minimal size.=0A= >>>=0A= >>> Secondly, I think recommending only a 500 MTU is way to conservative.= =0A= >>> Those studies I have seen appears to indicate that at least 1220 bytes= =0A= >>> UDP payloads should be be working as well as 500 bytes. See for example= =0A= >>> figure 12 in this:=0A= >>> https://static.googleusercontent.com/media/research.google.com/sv//pubs= /archive/46403.pdf=0A= >>>=0A= >>>=0A= >>> D. Section 2.7:=0A= >>>=0A= >>> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that=0A= >>> uses STUN to discover the path MTU, and so might be a suitable=0A= >>> approach to be used in conjunction with a TURN server that supports= =0A= >>> the DONT-FRAGMENT attribute. When the client includes the DONT-=0A= >>> FRAGMENT attribute in a Send indication, this tells the server to se= t=0A= >>> the DF bit in the resulting UDP datagram that it sends to the peer.= =0A= >>> Since some servers may be unable to set the DF bit, the client shoul= d=0A= >>> also include this attribute in the Allocate request -- any server=0A= >>> that does not support the DONT-FRAGMENT attribute will indicate this= =0A= >>> by rejecting the Allocate request.=0A= >>>=0A= >>> I want to verify that the WG is working on resolving the issues with th= e=0A= >>> STUN PMTUD document. I definitely sees the point of the recommendation,= =0A= >>> but only if the WG will conclude on that document in a reasonable time= =0A= >>> frame.=0A= >>>=0A= >>> E. Section 3:=0A= >>>=0A= >>> Server-Reflexive Transport Address: A transport address on the=0A= >>> "public side" of a NAT. This address is allocated by the NAT to= =0A= >>> correspond to a specific host transport address.=0A= >>>=0A= >>> Shouldn't "public side" be replace with "external side"? That is the=0A= >>> terminology used by the Behave RFCs.=0A= >>>=0A= >>> F. Section 3:=0A= >>>=0A= >>> 5-tuple: The combination (client IP address and port, server IP=0A= >>> address and port, and transport protocol (currently one of UDP,= =0A= >>> TCP, or (D)TLS)) used to communicate between the client and the= =0A= >>> server.=0A= >>>=0A= >>> I see some issues that the 5-tuple aggregates the transport protocol=0A= >>> with the security protocol. I agree from the TURN protocol perspective= =0A= >>> the protocol combination is the important one. However, writing like yo= u=0A= >>> do here you obfuscate both that when security is in place you have a=0A= >>> combination, as well as that there are 4 alternatives defined by this= =0A= >>> document.=0A= >>>=0A= >>> G. Section 4.1:=0A= >>>=0A= >>> The "turn" and "turns" URI schemes are used to designate a TURN=0A= >>> server (also known as a relay) on Internet hosts accessible using th= e=0A= >>> TURN protocol. The TURN protocol supports sending messages over UDP= ,=0A= >>> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be= =0A= >>> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the= =0A= >>> "turn" scheme MUST be used otherwise. The required part of= =0A= >>> the "turn" URI denotes the TURN server host. The part, if=0A= >>> present, denotes the port on which the TURN server is awaiting=0A= >>> connection requests. If it is absent, the default port is 3478 for= =0A= >>> both UDP and TCP. The default port for TURN over TLS and TURN over= =0A= >>> DTLS is 5349.=0A= >>>=0A= >>> First, I was wondering if this document needed to update RFC 7065? The= =0A= >>> high level obvious is the reference, but otherwise on the surface it=0A= >>> doesn't look necessary. My main complaint when reading was that it was= =0A= >>> not obvious what not specifying the transport parameter means. Then I= =0A= >>> saw this in Section 3.1 of RFC 7065:=0A= >>>=0A= >>> The , , and components are passed without=0A= >>> modification to the [RFC5928] algorithm. is set to false i= f=0A= >>> is equal to "turn", and set to true if is equal to= =0A= >>> "turns" and passed to the [RFC5928] algorithm with the other=0A= >>> components.=0A= >>>=0A= >>> After some digging I figured out that RFC5928 is actually updated by RF= C=0A= >>> 7350 that defines the resolution and SRV records for DTLS.=0A= >>>=0A= >>> Can you please update the text in Section 4 to also reference RFC 7350= =0A= >>> so that one doesn't miss this definitions.=0A= >>>=0A= >>> H. Section 5:=0A= >>>=0A= >>> If the server requires requests to be=0A= >>> authenticated, then the server's administrator MUST choose a realm= =0A= >>> value that will uniquely identify the username and password=0A= >>> combination that the client must use, even if the client uses=0A= >>> multiple servers under different administrations.=0A= >>>=0A= >>> Just to verify, TURN does not allow a single server address to host=0A= >>> multiple realms do it? Each Realm needs its own unique server transport= =0A= >>> address?=0A= >>>=0A= >>> I. Section 5:=0A= >>>=0A= >>> For each Allocate request, the server SHOULD generate a=0A= >>> new random nonce when the allocation is first attempted following th= e=0A= >>> randomness recommendations in [RFC4086] and SHOULD expire the nonce= =0A= >>> at least once every hour during the lifetime of the allocation.=0A= >>>=0A= >>> So, I think this text due to its use of RFC 2119 language is a bit=0A= >>> confusing in its relation to STUNbis. To me it is unclear if the above= =0A= >>> overrides completely what is written in Section 5 of STUNbis:=0A= >>>=0A= >>> To indicate that it supports this specification, a server MUST=0A= >>> prepend the NONCE attribute value with the character string composed= =0A= >>> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]= =0A= >>> encoding of the 24 bit STUN Security Features as defined in=0A= >>> Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes= ,=0A= >>> with bit 0 as the most significant bit of the first byte and bit 23= =0A= >>> as the least significant bit of the third byte. If no security=0A= >>> features are used, then a byte array with all 24 bits set to zero=0A= >>> MUST be encoded instead. For the remainder of this document the ter= m=0A= >>> "nonce cookie" will refer to the complete 13 character string=0A= >>> prepended to the NONCE attribute value.=0A= >>>=0A= >>> Or is the randomness recommendations in TURNbis only for the NONCE=0A= >>> attribute value part?=0A= >>>=0A= >>> Secondly, I interpret the text to say that compared to STUN, where a=0A= >>> Nonce can be long lived after the initial Long Term Credential=0A= >>> establishment, in TURN for each allocation one will have to to the=0A= >>> Allocate, expired nonce->here is your new nonce, resend allocate using= =0A= >>> new nonce, success dance.=0A= >>>=0A= >>> I think part of the problem with the above text in TURNbis is that the= =0A= >>> sentences prior to the quoted one appear to be rehashing of the STUNbis= =0A= >>> requirements. Then the quoted part that actually changes behavior=0A= >>> without being clear about it. I think it would be good to make it clear= =0A= >>> what is a change compared to STUNbis.=0A= >>>=0A= >>> J. Section 6:=0A= >>>=0A= >>> Note that, rather than storing the password explicitly, for=0A= >>> security reasons, it may be desirable for the server to store the ke= y=0A= >>> value, which is a secure hash over the username, realm, and password= =0A= >>> (see [I-D.ietf-tram-stunbis]).=0A= >>>=0A= >>> Why isn't this recommendation stronger. Are there any reasons why a=0A= >>> server would actually store the plain text password at all?=0A= >>>=0A= >>> K. Section 7.1:=0A= >>>=0A= >>> The client first picks a host transport address. It is RECOMMENDED= =0A= >>> that the client pick a currently unused transport address, typically= =0A= >>> by allowing the underlying OS to pick a currently unused port for a= =0A= >>> new socket.=0A= >>>=0A= >>> I think talk about socket in this context should be skipped as it=0A= >>> otherwise have been eliminated.=0A= >>>=0A= >>> L. Section 7.1:=0A= >>>=0A= >>> The client then picks a transport protocol to use between the client= =0A= >>> and the server. The transport protocol MUST be one of UDP, TCP, TLS= -=0A= >>> over-TCP or DTLS-over-UDP.=0A= >>>=0A= >>> I find it strange that this indicates that one should pick the transpor= t=0A= >>> protocol to use client to server without considering the server=0A= >>> capabilities. Especially as the client configuration or server discover= y=0A= >>> procedures will indicate transport protocol support.=0A= >>>=0A= >>> Secondly, what is the motivation for the MUST in the second sentence?= =0A= >>> This is appears to have strange interactions with any future extensions= =0A= >>> and have no impact. A client must obvious chose a client to server=0A= >>> transport protocol it supports, and one that the server supports or the= =0A= >>> client hope it will support.=0A= >>>=0A= >>> M. Section 7.1:=0A= >>>=0A= >>> The client also picks a server transport address, which SHOULD be=0A= >>> done as follows. The client uses one or more procedures described i= n=0A= >>> [RFC8155] to discover a TURN server and uses the TURN server=0A= >>> resolution mechanism defined in [RFC5928] to get a list of server=0A= >>> transport addresses that can be tried to create a TURN allocation.= =0A= >>>=0A= >>> 1) So RFC 8155 states that it has no recommendation on server selection= ,=0A= >>> nor on how to related local configuration to any auto-discovery servers= .=0A= >>> To me it appears that the protocol utilizing TURN should consider what= =0A= >>> makes sense in their deployments. Thus, does the need for such=0A= >>> consideration needs to be highlighted somewhere in this specification.= =0A= >>>=0A= >>> 2) The RFC5928 reference should be complemented with an RFC 7350=0A= >>> reference.=0A= >>>=0A= >>> N. Section 7.1:=0A= >>>=0A= >>> Clients MUST NOT include a REQUESTED-ADDRESS-=0A= >>> FAMILY attribute in an Allocate request that contains a RESERVATION-= =0A= >>> TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >>>=0A= >>> Considering that this document obsoletes RFC 6156, I think it is bad=0A= >>> form to reference that document, rather than to move the necessary=0A= >>> motivation into this document.=0A= >>>=0A= >>> O. Section 7.1:=0A= >>>=0A= >>> If the client wishes to obtain a relayed transport address of a=0A= >>> specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A= >>> attribute in the request.=0A= >>>=0A= >>> I don't find anything describing what the default behavior is if one=0A= >>> doesn't include the attribute, but the TURN server supports multiple=0A= >>> address families.=0A= >>>=0A= >>> I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= >>> Should the text in 7.1 be explicit about this default?=0A= >>>=0A= >>> P. Section 7.2:=0A= >>>=0A= >>> Otherwise, if the attribute is included but=0A= >>> specifies a protocol other that UDP, the server rejects the=0A= >>> request with a 442 (Unsupported Transport Protocol) error.=0A= >>>=0A= >>> Assuming that you don't support an extension for that transport=0A= >>> protocol. Should that be made explicit?=0A= >>>=0A= >>> Q. Section 8.3:=0A= >>>=0A= >>> If the client receives a success response to its Refresh request wit= h=0A= >>> a non-zero lifetime, it updates its copy of the allocation data=0A= >>> structure with the time-to-expiry value contained in the response.= =0A= >>>=0A= >>> If the client receives a 437 (Allocation Mismatch) error response to= =0A= >>> a request to delete the allocation, then the allocation no longer=0A= >>> exists and it should consider its request as having effectively=0A= >>> succeeded.=0A= >>>=0A= >>> So there are no considerations for the client if it receives an error= =0A= >>> response to a refresh request when Lifetime was non-zero?=0A= >>>=0A= >>> I am bit surprised by that. I assume that there are certain cases when= =0A= >>> the request could be resent, and others where the meaning is that the= =0A= >>> allocation is gone.=0A= >>>=0A= >>> R. Section 11.5:=0A= >>>=0A= >>> When the server receives an ICMP packet, the server verifies that th= e=0A= >>> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either= =0A= >>> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that th= e=0A= >>> IP packet in the ICMP packet payload contains a UDP header. If=0A= >>> either of these conditions fail, then the ICMP packet is silently=0A= >>> dropped.=0A= >>>=0A= >>> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A= >>> Problem are for ICMPv4?=0A= >>>=0A= >>> S. Section 12.5:=0A= >>>=0A= >>> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to= =0A= >>> a multiple of four bytes in order to ensure the alignment of=0A= >>> subsequent messages. The padding is not reflected in the length=0A= >>> field of the ChannelData message, so the actual size of a ChannelDat= a=0A= >>> message (including padding) is (4 + Length) rounded up to the neares= t=0A= >>> multiple of 4. Over UDP, the padding is not required but MAY be=0A= >>> included.=0A= >>>=0A= >>> Are there anywhere written what one may or may not include of the TURN= =0A= >>> related messages in a single UDP datagram. Because it is technically=0A= >>> feasible I belive to include two Send Indications in one UDP datagram t= o=0A= >>> the server.=0A= >>>=0A= >>> T. Section 13.1:=0A= >>>=0A= >>> Flow Label=0A= >>>=0A= >>> Preferred behavior: The relay sets the Flow label to 0. The rela= y=0A= >>> can choose to set the Flow label to a different value if it=0A= >>> supports the IPv6 Flow Label field [RFC6437].=0A= >>>=0A= >>> Alternate behavior: The relay sets the Flow label to the default= =0A= >>> value for outgoing packets.=0A= >>>=0A= >>> I think this section should be improved in two ways.=0A= >>>=0A= >>> First of all I think it should clarify that each allocation to peer flo= w=0A= >>> is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= >>>=0A= >>> Secondly, I think in the spirit of RFC 6473 the preferred behavior=0A= >>> should be to set the IPv6 flow label if the implementation is capable,= =0A= >>> or leave it to the underlying network stack to actually set it. Compare= d=0A= >>> to RFC 7915, the TURN server actually have an understanding of what are= =0A= >>> different flows without having examining additional protocol layers.=0A= >>>=0A= >>> Thirdly, I don't understand what the alternative behavior actually is.= =0A= >>> This as it is either setting it to 0, or classifying things as flow and= =0A= >>> then provide it with a random flow label. I think the right alternative= =0A= >>> behavior is to set it 0.=0A= >>>=0A= >>> U. Section 13. 1,2,3:=0A= >>>=0A= >>> For both preferred and alternate behavior, the DONT-FRAGMENT=0A= >>> attribute MUST be ignored by the server.=0A= >>>=0A= >>> I don't understand why just because one performs v4<->v6 or v6 to v4=0A= >>> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= >>> attribute. If the client has request to not fragment and the server is= =0A= >>> unable to do that when forwarding to the peer it needs to generate an= =0A= >>> ICMP attribute response saying the packet is to big. Otherwise the rela= y=0A= >>> breaks the Path MTU discovery mechanisms.=0A= >>>=0A= >>> V. Section 13.2:=0A= >>>=0A= >>> Fragmentation:=0A= >>>=0A= >>> If the incoming packet included a Fragment header and the outgoin= g=0A= >>> packet size exceeds the outgoing link's MTU, the relay MUST=0A= >>> fragment the outgoing packet into fragments of no more than 1280= =0A= >>> bytes. The relay sets the fields of the Fragment header as=0A= >>> appropriate for a packet originating from the server.=0A= >>>=0A= >>> Is really the intention here to refragment the packet without providing= =0A= >>> any indication that the practical MTU is smaller than what the peer or= =0A= >>> client thinks it is?=0A= >>>=0A= >>> W. Section 14:=0A= >>>=0A= >>> Preferred Behavior: Set the outgoing value to the incoming value,= =0A= >>> UNLESS the server is doing Active Queue Management, the incoming= =0A= >>> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server= =0A= >>> wishes to indicate that congestion has been experienced, in which= =0A= >>> case set the outgoing value to CE (=3D0b11).=0A= >>>=0A= >>> First of all do you have any special meaning with all capital UNLESS?= =0A= >>>=0A= >>> Secondly, I don't know how wise it is to have partial definitions of=0A= >>> what the ECN behavior is. Maybe simpler to say that that the relay is= =0A= >>> performing AQM it can support the ECN marking behavior as defined in RF= C=0A= >>> 3168.=0A= >>>=0A= >>> X. Section 14:=0A= >>>=0A= >>> How are these IP level fields handled when the transport is TCP or=0A= >>> TLS/TCP? There there are not necessary a one to one mapping between=0A= >>> datagrams and TCP packets. And if there are no support then there are= =0A= >>> need for clarification of behaviors when using TCP based transport.=0A= >>>=0A= >>> Y. Section 16.4. DATA=0A= >>>=0A= >>> The DATA attribute is present in all Send and Data indications. The= =0A= >>> value portion of this attribute is variable length and consists of= =0A= >>> the application data (that is, the data that would immediately follo= w=0A= >>> the UDP header if the data was been sent directly between the client= =0A= >>> and the peer). If the length of this attribute is not a multiple of= =0A= >>> 4, then padding must be added after this attribute.=0A= >>>=0A= >>> Can you please clarify if one would get all the remaining bytes of the= =0A= >>> IP packet payload or only the number of bytes the UDP length field=0A= >>> indiactes?=0A= >>>=0A= >>> The reason I ask is that there is possibility that there are a=0A= >>> discrepancy between these fields, something the proposal for an=0A= >>> experimental specification for UDP options attempt to utilize.=0A= >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >>>=0A= >>> Note, I only want you to clarify what is actually included. I would=0A= >>> assume using the UDP length field makes sense in this case.=0A= >>>=0A= >>> Z. The use of "relay" in the meaning of "Turn Server". There are many= =0A= >>> occurrences of relay in this meaning. Either make it explicit to be a= =0A= >>> synonym or change it to server.=0A= >>>=0A= >>> AA. Section 16.7=0A= >>>=0A= >>> rffu is lacking a definition. I would suggest making it upper case and= =0A= >>> copy the definition from 16.8.=0A= >>>=0A= >>> AB. Section 16.12:=0A= >>>=0A= >>> Rsvd in Format figure does not match definition below which uses "Reser= ved".=0A= >>>=0A= >>> AC. Section 16.12:=0A= >>>=0A= >>> Reason Phrase (variable). This field is under defined. First of all the= =0A= >>> format of the text string is not defined, which it is in Stunbis=0A= >>> Error-Code attribute is defined as.=0A= >>>=0A= >>> The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= >>> sequence of less than 128 characters (which can be as long as 509=0A= >>> bytes when encoding them or 763 bytes when decoding them).=0A= >>>=0A= >>> Secondly, I think it might be worth pointing out the padding here. It i= s=0A= >>> not clear if there is any form of string termination and how the paddin= g=0A= >>> which will be interpreted as NULL characters 0-3 depending on the=0A= >>> alignment. I note this later issue appears to be existing in STUNBis al= so.=0A= >>>=0A= >>> AD. Section 16.2:=0A= >>>=0A= >>> Why isn't the text here say that this attribute may also be used to=0A= >>> indicate the desired lifetime in allocation requests?=0A= >>>=0A= >>> AE. Section 16.9: DONT-FRAGMENT=0A= >>>=0A= >>> I think it would be good to indicate the use of the attribute in=0A= >>> Allocate Requests also.=0A= >>>=0A= >>> AF. Section 24.2=0A= >>>=0A= >>> [Protocol-Numbers]=0A= >>> "IANA Protocol Numbers Registry", 2005,=0A= >>> .=0A= >>>=0A= >>> This is a normative reference based on how it is used in Section 16.8.= =0A= >>>=0A= >>> AG. Seciton 18.=0A= >>>=0A= >>> Sometime before the 20 minute lifetime is up, the client refreshes= =0A= >>> the allocation. This is done using a Refresh request. As before,= =0A= >>> the client includes the latest username, realm, and nonce values in= =0A= >>> the request. The client also includes the SOFTWARE attribute,=0A= >>> following the recommended practice of always including this attribut= e=0A= >>> in Allocate and Refresh messages. When the server receives the=0A= >>> Refresh request, it notices that the nonce value has expired, and so= =0A= >>> replies with 438 (Stale Nonce) error given a new nonce value. The= =0A= >>> client then reattempts the request, this time with the new nonce=0A= >>> value. This second attempt is accepted, and the server replies with= =0A= >>> a success response. Note that the client did not include a LIFETIME= =0A= >>> attribute in the request, so the server refreshes the allocation for= =0A= >>> the default lifetime of 10 minutes (as can be seen by the LIFETIME= =0A= >>> attribute in the success response).=0A= >>>=0A= >>> I notice that this part nor the text before appears to discuss the=0A= >>> permission lifetime that will expire after 5 minutes. Thus, it needs to= =0A= >>> be refreshed prior to the Allocation.=0A= >>>=0A= >>> AH. Section 18.=0A= >>>=0A= >>> I am missing any example having to do with Address Family interactions.= =0A= >>>=0A= >>> AI. DTLS Cipher Suits=0A= >>>=0A= >>> Am I understanding it correct that the definition of what DTLS cipher= =0A= >>> suit that a TURN Server currently is to support is the ones in RFC 7525= ?=0A= >>>=0A= >>> In that case, I think the wording is a bit weak as the only reference I= =0A= >>> find are in Section 2.1:=0A= >>>=0A= >>> If (D)TLS transport is=0A= >>> used between the TURN client and the TURN server, the guidance given= =0A= >>> in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= >>>=0A= >>>=0A= >>> Cheers=0A= >>>=0A= >>> Magnus Westerlund =0A= >>>=0A= >>> ----------------------------------------------------------------------= =0A= >>> Network Architecture & Protocols, Ericsson Research=0A= >>> ----------------------------------------------------------------------= =0A= >>> Ericsson AB | Phone +46 10 7148287=0A= >>> Torshamnsgatan 23 | Mobile +46 73 0949079=0A= >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= >>> ----------------------------------------------------------------------= =0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> tram mailing list=0A= >>> tram@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/tram=0A= >>>=0A= >>=0A= > =0A= From nobody Mon Apr 15 04:06:07 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CD712008A; Mon, 15 Apr 2019 04:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIl8MuyOALg6; Mon, 15 Apr 2019 04:06:01 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA001120074; Mon, 15 Apr 2019 04:06:00 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1555326037; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=4 dtZP+Bo2jA9uLSA9BjLd71dVagULYsOapCPPyetr2 k=; b=dFxlGqFL4w//QdbWu9Cx3qfWcowAW0/yey89qveQY1wA TIbEQE9SK2tBx2V4W3jWRu1aRj4/lodLPm1kCNEViGrZliFrfc FOVRjeqSIFNtNrwZv8wcDLeVMxfT6VJ0erWqbpt9sKxJlS+P8T FWiXxCUw5SmaHHwalOOe/RehETM= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5716_a445_3accbb0c_038a_4059_ab5a_cb9b4c12baf8; Mon, 15 Apr 2019 05:00:36 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 05:05:45 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Apr 2019 05:05:45 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 05:05:44 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2662.namprd16.prod.outlook.com (20.177.224.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Mon, 15 Apr 2019 11:05:42 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 11:05:42 +0000 From: "Konda, Tirumaleswar Reddy" To: Gonzalo Camarillo , Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiP6Y9IDAQ Date: Mon, 15 Apr 2019 11:05:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f93ab223-1436-4e54-1160-08d6c1924d63 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2662; x-ms-traffictypediagnostic: BYAPR16MB2662: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(376002)(396003)(366004)(199004)(189003)(51914003)(13464003)(32952001)(229853002)(55016002)(6246003)(74316002)(305945005)(53936002)(18074004)(256004)(14444005)(105586002)(9686003)(446003)(486006)(53946003)(11346002)(6436002)(6306002)(476003)(2201001)(52536014)(86362001)(30864003)(7696005)(71200400001)(71190400001)(106356001)(66574012)(76176011)(26005)(66066001)(186003)(6506007)(966005)(110136005)(102836004)(53546011)(14454004)(25786009)(316002)(99286004)(68736007)(5660300002)(81156014)(8936002)(478600001)(93886005)(97736004)(8676002)(7736002)(561944003)(33656002)(2906002)(6116002)(80792005)(3846002)(81166006)(72206003)(2501003)(151285002)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2662; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zKj4HcZKiDfs+6X7rDXQjSS2QSeq1OyKx+Q4bsfujDa/V5nzK4q/olophemKkU8eduT43HZ8JryPwDl0I2GTflwOpk9lU2urw9DJX1APmb6My7pjkLRhsgK3yssgfwJogESdFBuRtYj2vVODKWzdqBfJyZLsHn5VqfyY0NvvNqTY04KmgphRmYht+oWz8I2dRZYgwp/8dbez/1C26JjZXvrDO7R94BmlqoEgWA0pHR6YQfWQp2ziNpRZBlizfcYgIK26JwY13GgUjwLmf4BFSRVML0VhuP4fiXxiVYQnQEB9+eWHYtuB4tU/WwPpW7x2BTJWvOSa+Hky0w2BPYo+y6PsyQ5QCt/hyMSGmZ84ga50ihm8XSG6P/t0RSoXvoRoKXUasSV0Zjpd1FllZn+KDtRw/uIJvuxuj/xhHCCMoHY= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f93ab223-1436-4e54-1160-08d6c1924d63 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 11:05:42.5386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2662 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6524> : inlines <7052> : streams <1818724> : uri <2832357> Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 11:06:05 -0000 > -----Original Message----- > From: tram On Behalf Of Gonzalo Camarillo > Sent: Monday, April 15, 2019 4:09 PM > To: Magnus Westerlund ; tram@ietf.org; > draft-ietf-tram-turnbis@ietf.org > Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 >=20 >=20 >=20 > Authors of TURNbis, >=20 > could you please look into this and let us know your time plan to address > Magnus's review? Thanks! I have already responded to the comments from Magnus https://mailarchive.ie= tf.org/arch/msg/tram/CVcl_2D-uads0zw3kS9uVqr0WFk, waiting for his response. Cheers, -Tiru >=20 > Cheers, >=20 > Gonzalo >=20 > On 05-Apr-19 11:20, Gonzalo Camarillo wrote: > > Thanks for the review, Magnus! > > > > Authors, could you please look into Magnus's comments and provide him > > with responses? > > > > Thanks, > > > > Gonzalo > > > > On 05-Apr-19 10:11, Magnus Westerlund wrote: > >> Hi, > >> > >> One addition. > >> > >> Section 16.13. ICMP Attribute > >> > >> This attribute is flawed as it lacks a data part to carry values > >> certain codes have. I specifically think of ICMPv6 Type =3D 2, Packet = Too Big. > >> That message has a 32-bit unsigned integer carrying the MTU of the > >> Next Hop Link that causes the ICMP message to be sent. That really > >> should be replicated back to the client. > >> > >> There is also the question if ICMP messages for Parameter Problem > >> should included the pointer? > >> > >> I really think there need to be a 32-bit data field with the ICMP > >> attribute. > >> > >> Cheers > >> > >> Magnus > >> > >> > >> On 2019-04-04 16:00, Magnus Westerlund wrote: > >>> Hi, > >>> > >>> I have now finished the AD review. There are a lot of details that I > >>> think needs fixing or at least feedback on. I also think there are a > >>> couple of more serious issues here. Especially regarding the > >>> handling of MTU and fragmentation, as well as IP header fields in > >>> address family translation and with non UDP transport. We need to > >>> conclude on these before we go to IETF last call. > >>> > >>> My Review comments are: > >>> > >>> A. Section 1: "The client can arrange > >>> for the server to relay packets to and from certain other hosts > >>> (called peers) and can control aspects of how the relaying is done= ." > >>> > >>> I don't think this is an accurate description of what Turn does. One > >>> may easily get the impression that the whole packet TURN receives > >>> are relayed, rather than the transport protocol data part and some > >>> of the header information are relayed between the client <-> peer, > >>> with a knowledge of the peer transport address for the client. I > >>> think that should be clarified in the introduction. > >>> > >>> B. Section 2.7: > >>> > >>> "Applications using TCP can more or less > >>> ignore this issue because fragmentation avoidance is now a standar= d > >>> part of TCP, but applications using UDP (and thus any application > >>> using this version of TURN) must handle fragmentation avoidance > >>> themselves." > >>> > >>> Lower case "must", and as the document uses RFC 2119, this must have > >>> the meaning of "MUST". A reformulation here is likely in order. > >>> > >>> C. Section 2.7: > >>> > >>> In this approach, the application exploits the > >>> fact that the IP specification [RFC0791] specifies that IP packets= up > >>> to 576 bytes should never need to be fragmented. > >>> > >>> As a guideline, sending a maximum of 500 bytes of application data= in > >>> a single TURN message (by the client on the client-to-server leg) = or > >>> a UDP datagram (by the peer on the peer-to-server leg) will genera= lly > >>> avoid IP fragmentation. To further reduce the chance of > >>> fragmentation, it is recommended that the client use ChannelData > >>> messages when transferring significant volumes of data, since the > >>> overhead of the ChannelData message is less than Send and Data > >>> indications. > >>> > >>> In that first paragraph I think it is worth discussing the IPv6 > >>> requirement of supporting a 1280 minimal size. > >>> > >>> Secondly, I think recommending only a 500 MTU is way to conservative. > >>> Those studies I have seen appears to indicate that at least 1220 > >>> bytes UDP payloads should be be working as well as 500 bytes. See > >>> for example figure 12 in this: > >>> https://static.googleusercontent.com/media/research.google.com/sv//p > >>> ubs/archive/46403.pdf > >>> > >>> > >>> D. Section 2.7: > >>> > >>> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that > >>> uses STUN to discover the path MTU, and so might be a suitable > >>> approach to be used in conjunction with a TURN server that support= s > >>> the DONT-FRAGMENT attribute. When the client includes the DONT- > >>> FRAGMENT 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 sho= uld > >>> also include this attribute in the Allocate request -- any server > >>> that does not support the DONT-FRAGMENT attribute will indicate th= is > >>> by rejecting the Allocate request. > >>> > >>> I want to verify that the WG is working on resolving the issues with > >>> the STUN PMTUD document. I definitely sees the point of the > >>> recommendation, but only if the WG will conclude on that document in > >>> a reasonable time frame. > >>> > >>> E. Section 3: > >>> > >>> Server-Reflexive Transport Address: A transport address on the > >>> "public side" of a NAT. This address is allocated by the NAT t= o > >>> correspond to a specific host transport address. > >>> > >>> Shouldn't "public side" be replace with "external side"? That is the > >>> terminology used by the Behave RFCs. > >>> > >>> F. Section 3: > >>> > >>> 5-tuple: The combination (client IP address and port, server IP > >>> address and port, and transport protocol (currently one of UDP, > >>> TCP, or (D)TLS)) used to communicate between the client and the > >>> server. > >>> > >>> I see some issues that the 5-tuple aggregates the transport protocol > >>> with the security protocol. I agree from the TURN protocol > >>> perspective the protocol combination is the important one. However, > >>> writing like you do here you obfuscate both that when security is in > >>> place you have a combination, as well as that there are 4 > >>> alternatives defined by this document. > >>> > >>> G. Section 4.1: > >>> > >>> The "turn" and "turns" URI schemes are used to designate a TURN > >>> server (also known as a relay) on Internet hosts accessible using = the > >>> TURN protocol. The TURN protocol supports sending messages over U= DP, > >>> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST b= e > >>> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and t= he > >>> "turn" scheme MUST be used otherwise. The required part of > >>> the "turn" URI denotes the TURN server host. The part, if > >>> present, denotes the port on which the TURN server is awaiting > >>> connection requests. If it is absent, the default port is 3478 fo= r > >>> both UDP and TCP. The default port for TURN over TLS and TURN ove= r > >>> DTLS is 5349. > >>> > >>> First, I was wondering if this document needed to update RFC 7065? > >>> The high level obvious is the reference, but otherwise on the > >>> surface it doesn't look necessary. My main complaint when reading > >>> was that it was not obvious what not specifying the transport > >>> parameter means. Then I saw this in Section 3.1 of RFC 7065: > >>> > >>> The , , and components are passed without > >>> modification to the [RFC5928] algorithm. is set to false= if > >>> is equal to "turn", and set to true if is equal = to > >>> "turns" and passed to the [RFC5928] algorithm with the other > >>> components. > >>> > >>> After some digging I figured out that RFC5928 is actually updated by > >>> RFC > >>> 7350 that defines the resolution and SRV records for DTLS. > >>> > >>> Can you please update the text in Section 4 to also reference RFC > >>> 7350 so that one doesn't miss this definitions. > >>> > >>> H. Section 5: > >>> > >>> If the server requires requests to be > >>> authenticated, then the server's administrator MUST choose a realm > >>> value that will uniquely identify the username and password > >>> combination that the client must use, even if the client uses > >>> multiple servers under different administrations. > >>> > >>> Just to verify, TURN does not allow a single server address to host > >>> multiple realms do it? Each Realm needs its own unique server > >>> transport address? > >>> > >>> I. Section 5: > >>> > >>> For each Allocate request, the server SHOULD generate a > >>> new random nonce when the allocation is first attempted following = the > >>> randomness recommendations in [RFC4086] and SHOULD expire the > nonce > >>> at least once every hour during the lifetime of the allocation. > >>> > >>> So, I think this text due to its use of RFC 2119 language is a bit > >>> confusing in its relation to STUNbis. To me it is unclear if the > >>> above overrides completely what is written in Section 5 of STUNbis: > >>> > >>> To indicate that it supports this specification, a server MUST > >>> prepend the NONCE attribute value with the character string compos= ed > >>> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648= ] > >>> encoding of the 24 bit STUN Security Features as defined in > >>> Section 18.1. The 24 bit Security Feature set is encoded as 3 byt= es, > >>> with bit 0 as the most significant bit of the first byte and bit 2= 3 > >>> as the least significant bit of the third byte. If no security > >>> features are used, then a byte array with all 24 bits set to zero > >>> MUST be encoded instead. For the remainder of this document the t= erm > >>> "nonce cookie" will refer to the complete 13 character string > >>> prepended to the NONCE attribute value. > >>> > >>> Or is the randomness recommendations in TURNbis only for the NONCE > >>> attribute value part? > >>> > >>> Secondly, I interpret the text to say that compared to STUN, where a > >>> Nonce can be long lived after the initial Long Term Credential > >>> establishment, in TURN for each allocation one will have to to the > >>> Allocate, expired nonce->here is your new nonce, resend allocate > >>> using new nonce, success dance. > >>> > >>> I think part of the problem with the above text in TURNbis is that > >>> the sentences prior to the quoted one appear to be rehashing of the > >>> STUNbis requirements. Then the quoted part that actually changes > >>> behavior without being clear about it. I think it would be good to > >>> make it clear what is a change compared to STUNbis. > >>> > >>> J. Section 6: > >>> > >>> Note that, rather than storing the password explicitly, for > >>> security reasons, it may be desirable for the server to store the = key > >>> value, which is a secure hash over the username, realm, and passwo= rd > >>> (see [I-D.ietf-tram-stunbis]). > >>> > >>> Why isn't this recommendation stronger. Are there any reasons why a > >>> server would actually store the plain text password at all? > >>> > >>> K. Section 7.1: > >>> > >>> The client first picks a host transport address. It is RECOMMENDE= D > >>> that the client pick a currently unused transport address, typical= ly > >>> by allowing the underlying OS to pick a currently unused port for = a > >>> new socket. > >>> > >>> I think talk about socket in this context should be skipped as it > >>> otherwise have been eliminated. > >>> > >>> L. Section 7.1: > >>> > >>> The client then picks a transport protocol to use between the clien= t > >>> and the server. The transport protocol MUST be one of UDP, TCP, T= LS- > >>> over-TCP or DTLS-over-UDP. > >>> > >>> I find it strange that this indicates that one should pick the > >>> transport protocol to use client to server without considering the > >>> server capabilities. Especially as the client configuration or > >>> server discovery procedures will indicate transport protocol support. > >>> > >>> Secondly, what is the motivation for the MUST in the second sentence? > >>> This is appears to have strange interactions with any future > >>> extensions and have no impact. A client must obvious chose a client > >>> to server transport protocol it supports, and one that the server > >>> supports or the client hope it will support. > >>> > >>> M. Section 7.1: > >>> > >>> The client also picks a server transport address, which SHOULD be > >>> done as follows. The client uses one or more procedures described= in > >>> [RFC8155] to discover a TURN server and uses the TURN server > >>> resolution mechanism defined in [RFC5928] to get a list of server > >>> transport addresses that can be tried to create a TURN allocation. > >>> > >>> 1) So RFC 8155 states that it has no recommendation on server > >>> selection, nor on how to related local configuration to any auto-disc= overy > servers. > >>> To me it appears that the protocol utilizing TURN should consider > >>> what makes sense in their deployments. Thus, does the need for such > >>> consideration needs to be highlighted somewhere in this specification= . > >>> > >>> 2) The RFC5928 reference should be complemented with an RFC 7350 > >>> reference. > >>> > >>> N. Section 7.1: > >>> > >>> Clients MUST NOT include a REQUESTED-ADDRESS- > >>> FAMILY attribute in an Allocate request that contains a RESERVATIO= N- > >>> TOKEN attribute, for the reasons outlined in [RFC6156]. > >>> > >>> Considering that this document obsoletes RFC 6156, I think it is bad > >>> form to reference that document, rather than to move the necessary > >>> motivation into this document. > >>> > >>> O. Section 7.1: > >>> > >>> If the client wishes to obtain a relayed transport address of a > >>> specific address type then it includes a REQUESTED-ADDRESS-FAMILY > >>> attribute in the request. > >>> > >>> I don't find anything describing what the default behavior is if one > >>> doesn't include the attribute, but the TURN server supports multiple > >>> address families. > >>> > >>> I see that bullet 7 in Section 7.2 indicates that IPv4 is default. > >>> Should the text in 7.1 be explicit about this default? > >>> > >>> P. Section 7.2: > >>> > >>> Otherwise, if the attribute is included but > >>> specifies a protocol other that UDP, the server rejects the > >>> request with a 442 (Unsupported Transport Protocol) error. > >>> > >>> Assuming that you don't support an extension for that transport > >>> protocol. Should that be made explicit? > >>> > >>> Q. Section 8.3: > >>> > >>> If the client receives a success response to its Refresh request w= ith > >>> a non-zero lifetime, it updates its copy of the allocation data > >>> structure with the time-to-expiry value contained in the response. > >>> > >>> If the client receives a 437 (Allocation Mismatch) error response = to > >>> a request to delete the allocation, then the allocation no longer > >>> exists and it should consider its request as having effectively > >>> succeeded. > >>> > >>> So there are no considerations for the client if it receives an > >>> error response to a refresh request when Lifetime was non-zero? > >>> > >>> I am bit surprised by that. I assume that there are certain cases > >>> when the request could be resent, and others where the meaning is > >>> that the allocation is gone. > >>> > >>> R. Section 11.5: > >>> > >>> When the server receives an ICMP packet, the server verifies that = the > >>> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or eithe= r > >>> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that = the > >>> IP packet in the ICMP packet payload contains a UDP header. If > >>> either of these conditions fail, then the ICMP packet is silently > >>> dropped. > >>> > >>> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter > >>> Problem are for ICMPv4? > >>> > >>> S. Section 12.5: > >>> > >>> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded > to > >>> a multiple of four bytes in order to ensure the alignment of > >>> subsequent messages. The padding is not reflected in the length > >>> field of the ChannelData message, so the actual size of a ChannelD= ata > >>> message (including padding) is (4 + Length) rounded up to the near= est > >>> multiple of 4. Over UDP, the padding is not required but MAY be > >>> included. > >>> > >>> Are there anywhere written what one may or may not include of the > >>> TURN related messages in a single UDP datagram. Because it is > >>> technically feasible I belive to include two Send Indications in one > >>> UDP datagram to the server. > >>> > >>> T. Section 13.1: > >>> > >>> Flow Label > >>> > >>> Preferred behavior: The relay sets the Flow label to 0. The re= lay > >>> can choose to set the Flow label to a different value if it > >>> supports the IPv6 Flow Label field [RFC6437]. > >>> > >>> Alternate behavior: The relay sets the Flow label to the defaul= t > >>> value for outgoing packets. > >>> > >>> I think this section should be improved in two ways. > >>> > >>> First of all I think it should clarify that each allocation to peer > >>> flow is its own IPv6 Flow in perspective of the IPv6 Flow label. > >>> > >>> Secondly, I think in the spirit of RFC 6473 the preferred behavior > >>> should be to set the IPv6 flow label if the implementation is > >>> capable, or leave it to the underlying network stack to actually set > >>> it. Compared to RFC 7915, the TURN server actually have an > >>> understanding of what are different flows without having examining > additional protocol layers. > >>> > >>> Thirdly, I don't understand what the alternative behavior actually is= . > >>> This as it is either setting it to 0, or classifying things as flow > >>> and then provide it with a random flow label. I think the right > >>> alternative behavior is to set it 0. > >>> > >>> U. Section 13. 1,2,3: > >>> > >>> For both preferred and alternate behavior, the DONT-FRAGMENT > >>> attribute MUST be ignored by the server. > >>> > >>> I don't understand why just because one performs v4<->v6 or v6 to v4 > >>> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT > >>> attribute. If the client has request to not fragment and the server > >>> is unable to do that when forwarding to the peer it needs to > >>> generate an ICMP attribute response saying the packet is to big. > >>> Otherwise the relay breaks the Path MTU discovery mechanisms. > >>> > >>> V. Section 13.2: > >>> > >>> Fragmentation: > >>> > >>> If the incoming packet included a Fragment header and the outgo= ing > >>> packet size exceeds the outgoing link's MTU, the relay MUST > >>> fragment the outgoing packet into fragments of no more than 128= 0 > >>> bytes. The relay sets the fields of the Fragment header as > >>> appropriate for a packet originating from the server. > >>> > >>> Is really the intention here to refragment the packet without > >>> providing any indication that the practical MTU is smaller than what > >>> the peer or client thinks it is? > >>> > >>> W. Section 14: > >>> > >>> Preferred Behavior: Set the outgoing value to the incoming valu= e, > >>> UNLESS the server is doing Active Queue Management, the incomin= g > >>> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the serv= er > >>> wishes to indicate that congestion has been experienced, in whi= ch > >>> case set the outgoing value to CE (=3D0b11). > >>> > >>> First of all do you have any special meaning with all capital UNLESS? > >>> > >>> Secondly, I don't know how wise it is to have partial definitions of > >>> what the ECN behavior is. Maybe simpler to say that that the relay > >>> is performing AQM it can support the ECN marking behavior as defined > >>> in RFC 3168. > >>> > >>> X. Section 14: > >>> > >>> How are these IP level fields handled when the transport is TCP or > >>> TLS/TCP? There there are not necessary a one to one mapping between > >>> datagrams and TCP packets. And if there are no support then there > >>> are need for clarification of behaviors when using TCP based transpor= t. > >>> > >>> Y. Section 16.4. DATA > >>> > >>> The DATA attribute is present in all Send and Data indications. T= he > >>> value portion of this attribute is variable length and consists of > >>> the application data (that is, the data that would immediately fol= low > >>> the UDP header if the data was been sent directly between the clie= nt > >>> and the peer). If the length of this attribute is not a multiple = of > >>> 4, then padding must be added after this attribute. > >>> > >>> Can you please clarify if one would get all the remaining bytes of > >>> the IP packet payload or only the number of bytes the UDP length > >>> field indiactes? > >>> > >>> The reason I ask is that there is possibility that there are a > >>> discrepancy between these fields, something the proposal for an > >>> experimental specification for UDP options attempt to utilize. > >>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > >>> > >>> Note, I only want you to clarify what is actually included. I would > >>> assume using the UDP length field makes sense in this case. > >>> > >>> Z. The use of "relay" in the meaning of "Turn Server". There are > >>> many occurrences of relay in this meaning. Either make it explicit > >>> to be a synonym or change it to server. > >>> > >>> AA. Section 16.7 > >>> > >>> rffu is lacking a definition. I would suggest making it upper case > >>> and copy the definition from 16.8. > >>> > >>> AB. Section 16.12: > >>> > >>> Rsvd in Format figure does not match definition below which uses > "Reserved". > >>> > >>> AC. Section 16.12: > >>> > >>> Reason Phrase (variable). This field is under defined. First of all > >>> the format of the text string is not defined, which it is in Stunbis > >>> Error-Code attribute is defined as. > >>> > >>> The reason phrase MUST be a UTF-8 [RFC3629] encoded > >>> sequence of less than 128 characters (which can be as long as 509 > >>> bytes when encoding them or 763 bytes when decoding them). > >>> > >>> Secondly, I think it might be worth pointing out the padding here. > >>> It is not clear if there is any form of string termination and how > >>> the padding which will be interpreted as NULL characters 0-3 > >>> depending on the alignment. I note this later issue appears to be exi= sting in > STUNBis also. > >>> > >>> AD. Section 16.2: > >>> > >>> Why isn't the text here say that this attribute may also be used to > >>> indicate the desired lifetime in allocation requests? > >>> > >>> AE. Section 16.9: DONT-FRAGMENT > >>> > >>> I think it would be good to indicate the use of the attribute in > >>> Allocate Requests also. > >>> > >>> AF. Section 24.2 > >>> > >>> [Protocol-Numbers] > >>> "IANA Protocol Numbers Registry", 2005, > >>> . > >>> > >>> This is a normative reference based on how it is used in Section 16.8= . > >>> > >>> AG. Seciton 18. > >>> > >>> Sometime before the 20 minute lifetime is up, the client refreshes > >>> the allocation. This is done using a Refresh request. As before, > >>> the client includes the latest username, realm, and nonce values i= n > >>> the request. The client also includes the SOFTWARE attribute, > >>> following the recommended practice of always including this attrib= ute > >>> in Allocate and Refresh messages. When the server receives the > >>> Refresh request, it notices that the nonce value has expired, and = so > >>> replies with 438 (Stale Nonce) error given a new nonce value. The > >>> client then reattempts the request, this time with the new nonce > >>> value. This second attempt is accepted, and the server replies wi= th > >>> a success response. Note that the client did not include a LIFETI= ME > >>> attribute in the request, so the server refreshes the allocation f= or > >>> the default lifetime of 10 minutes (as can be seen by the LIFETIME > >>> attribute in the success response). > >>> > >>> I notice that this part nor the text before appears to discuss the > >>> permission lifetime that will expire after 5 minutes. Thus, it needs > >>> to be refreshed prior to the Allocation. > >>> > >>> AH. Section 18. > >>> > >>> I am missing any example having to do with Address Family interaction= s. > >>> > >>> AI. DTLS Cipher Suits > >>> > >>> Am I understanding it correct that the definition of what DTLS > >>> cipher suit that a TURN Server currently is to support is the ones in= RFC > 7525? > >>> > >>> In that case, I think the wording is a bit weak as the only > >>> reference I find are in Section 2.1: > >>> > >>> If (D)TLS transport is > >>> used between the TURN client and the TURN server, the guidance giv= en > >>> in [RFC7525] MUST be followed to avoid attacks on (D)TLS. > >>> > >>> > >>> Cheers > >>> > >>> Magnus Westerlund > >>> > >>> -------------------------------------------------------------------- > >>> -- Network Architecture & Protocols, Ericsson Research > >>> ---------------------------------------------------------------------= - > >>> Ericsson AB | Phone +46 10 7148287 > >>> Torshamnsgatan 23 | Mobile +46 73 0949079 > >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > >>> -------------------------------------------------------------------- > >>> -- > >>> > >>> > >>> _______________________________________________ > >>> 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 Mon Apr 15 06:43:42 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D931C1201AB; Mon, 15 Apr 2019 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZQEw0J6qqap; Mon, 15 Apr 2019 06:43:37 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D83E12017E; Mon, 15 Apr 2019 06:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U5xEDZc50POkP1fAYSpri1fjOlzcE60HpeXiMIyiM04=; b=jSkPLfs2ygLOfWTbzpbz09/aZII7eIeSlLuIE/2Nzdz9p6CXCs6PzipPe+y1WwA0JXIlZrH3tYnly+SE54Nie2QRretUaqVj8sP0ojUZtfwWnxoHJCXLYguoFWvtO+PQSevef6Gbbtl4YGdBNZaAxa7+cVJnXYNShFA1Kb5jpeI= Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com (52.133.6.143) by HE1SPR01MB03.eurprd07.prod.outlook.com (10.160.67.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 13:43:32 +0000 Received: from HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264]) by HE1PR0702MB3689.eurprd07.prod.outlook.com ([fe80::8016:9a82:4ff3:a264%6]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 13:43:31 +0000 From: Gonzalo Camarillo To: "Konda, Tirumaleswar Reddy" , Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Mon, 15 Apr 2019 13:43:31 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gonzalo.camarillo@ericsson.com; x-originating-ip: [37.136.23.131] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0f63db95-9933-42f2-06ad-08d6c1a8597f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1SPR01MB03; x-ms-traffictypediagnostic: HE1SPR01MB03: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(366004)(346002)(376002)(39860400002)(136003)(13464003)(51914003)(189003)(199004)(476003)(2906002)(52536014)(7696005)(71200400001)(6506007)(99286004)(44832011)(446003)(2201001)(71190400001)(66574012)(97736004)(26005)(86362001)(2501003)(6246003)(6436002)(55016002)(53946003)(6306002)(9686003)(316002)(30864003)(486006)(110136005)(53936002)(229853002)(81156014)(81166006)(5660300002)(305945005)(105586002)(8936002)(7736002)(6116002)(33656002)(561944003)(53546011)(8676002)(93886005)(68736007)(25786009)(66066001)(76176011)(478600001)(102836004)(3846002)(18074004)(256004)(106356001)(74316002)(966005)(14454004)(14444005)(186003)(151285002)(559001)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1SPR01MB03; H:HE1PR0702MB3689.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aioWi9ZCIz1qtxnfZjsHNUTiXd713HduTKKfoGVEDa+qM2q7rWwosBlJnLWXAIAnfiP5jLsDRN5jPZZhWfbY000B8iRMZulVo+vVG2A4YO9NnuW2mvU6lWu5KGV12jCO+vtyRREwjbi4oATrT2vD0WUF4kkbnPrBgZtKPh9oFNrl0hGJbc/6ycp1SzPpTuruK+GnMQ/9uo+nBy5FUBzMjdGL2DQLuGG0SrTMlM8YxDz8TQQlxeOa3OsSQzE25o1k8ldUv4QBnFGOE5HnoU5BTTcoA+PfwYjEMLU/odnz2iqM8hDW7Bmx2ATPoxLCFJlASxQh+O/1xlVHU+WA+91p4HI5Y+HEDoljLNzeRKiSDIUpOrNZ0p7nFASvZ6Z38axH1+EEYT0aA0liuqSQQBnBn7flTWDXZDbVK3uROocGryU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0f63db95-9933-42f2-06ad-08d6c1a8597f X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 13:43:31.7996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1SPR01MB03 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 13:43:42 -0000 Hi Magnus,=0A= =0A= could you please look into Tiru's responses and let us know how you want=0A= to proceed? Thanks!=0A= =0A= Cheers,=0A= =0A= Gonzalo=0A= =0A= On 15-Apr-19 14:05, Konda, Tirumaleswar Reddy wrote:=0A= >> -----Original Message-----=0A= >> From: tram On Behalf Of Gonzalo Camarillo=0A= >> Sent: Monday, April 15, 2019 4:09 PM=0A= >> To: Magnus Westerlund ; tram@ietf.org;= =0A= >> draft-ietf-tram-turnbis@ietf.org=0A= >> Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23=0A= >>=0A= >>=0A= >>=0A= >> Authors of TURNbis,=0A= >>=0A= >> could you please look into this and let us know your time plan to addres= s=0A= >> Magnus's review? Thanks!=0A= > =0A= > I have already responded to the comments from Magnus https://mailarchive.= ietf.org/arch/msg/tram/CVcl_2D-uads0zw3kS9uVqr0WFk, waiting for his respons= e.=0A= > =0A= > Cheers,=0A= > -Tiru=0A= > =0A= >>=0A= >> Cheers,=0A= >>=0A= >> Gonzalo=0A= >>=0A= >> On 05-Apr-19 11:20, Gonzalo Camarillo wrote:=0A= >>> Thanks for the review, Magnus!=0A= >>>=0A= >>> Authors, could you please look into Magnus's comments and provide him= =0A= >>> with responses?=0A= >>>=0A= >>> Thanks,=0A= >>>=0A= >>> Gonzalo=0A= >>>=0A= >>> On 05-Apr-19 10:11, Magnus Westerlund wrote:=0A= >>>> Hi,=0A= >>>>=0A= >>>> One addition.=0A= >>>>=0A= >>>> Section 16.13. ICMP Attribute=0A= >>>>=0A= >>>> This attribute is flawed as it lacks a data part to carry values=0A= >>>> certain codes have. I specifically think of ICMPv6 Type =3D 2, Packet = Too Big.=0A= >>>> That message has a 32-bit unsigned integer carrying the MTU of the=0A= >>>> Next Hop Link that causes the ICMP message to be sent. That really=0A= >>>> should be replicated back to the client.=0A= >>>>=0A= >>>> There is also the question if ICMP messages for Parameter Problem=0A= >>>> should included the pointer?=0A= >>>>=0A= >>>> I really think there need to be a 32-bit data field with the ICMP=0A= >>>> attribute.=0A= >>>>=0A= >>>> Cheers=0A= >>>>=0A= >>>> Magnus=0A= >>>>=0A= >>>>=0A= >>>> On 2019-04-04 16:00, Magnus Westerlund wrote:=0A= >>>>> Hi,=0A= >>>>>=0A= >>>>> I have now finished the AD review. There are a lot of details that I= =0A= >>>>> think needs fixing or at least feedback on. I also think there are a= =0A= >>>>> couple of more serious issues here. Especially regarding the=0A= >>>>> handling of MTU and fragmentation, as well as IP header fields in=0A= >>>>> address family translation and with non UDP transport. We need to=0A= >>>>> conclude on these before we go to IETF last call.=0A= >>>>>=0A= >>>>> My Review comments are:=0A= >>>>>=0A= >>>>> A. Section 1: "The client can arrange=0A= >>>>> for the server to relay packets to and from certain other hosts=0A= >>>>> (called peers) and can control aspects of how the relaying is done= ."=0A= >>>>>=0A= >>>>> I don't think this is an accurate description of what Turn does. One= =0A= >>>>> may easily get the impression that the whole packet TURN receives=0A= >>>>> are relayed, rather than the transport protocol data part and some=0A= >>>>> of the header information are relayed between the client <-> peer,=0A= >>>>> with a knowledge of the peer transport address for the client. I=0A= >>>>> think that should be clarified in the introduction.=0A= >>>>>=0A= >>>>> B. Section 2.7:=0A= >>>>>=0A= >>>>> "Applications using TCP can more or less=0A= >>>>> ignore this issue because fragmentation avoidance is now a standar= d=0A= >>>>> part of TCP, but applications using UDP (and thus any application= =0A= >>>>> using this version of TURN) must handle fragmentation avoidance=0A= >>>>> themselves."=0A= >>>>>=0A= >>>>> Lower case "must", and as the document uses RFC 2119, this must have= =0A= >>>>> the meaning of "MUST". A reformulation here is likely in order.=0A= >>>>>=0A= >>>>> C. Section 2.7:=0A= >>>>>=0A= >>>>> In this approach, the application exploits the=0A= >>>>> fact that the IP specification [RFC0791] specifies that IP packets= up=0A= >>>>> to 576 bytes should never need to be fragmented.=0A= >>>>>=0A= >>>>> As a guideline, sending a maximum of 500 bytes of application data= in=0A= >>>>> a single TURN message (by the client on the client-to-server leg) = or=0A= >>>>> a UDP datagram (by the peer on the peer-to-server leg) will genera= lly=0A= >>>>> avoid IP fragmentation. To further reduce the chance of=0A= >>>>> fragmentation, it is recommended that the client use ChannelData= =0A= >>>>> messages when transferring significant volumes of data, since the= =0A= >>>>> overhead of the ChannelData message is less than Send and Data=0A= >>>>> indications.=0A= >>>>>=0A= >>>>> In that first paragraph I think it is worth discussing the IPv6=0A= >>>>> requirement of supporting a 1280 minimal size.=0A= >>>>>=0A= >>>>> Secondly, I think recommending only a 500 MTU is way to conservative.= =0A= >>>>> Those studies I have seen appears to indicate that at least 1220=0A= >>>>> bytes UDP payloads should be be working as well as 500 bytes. See=0A= >>>>> for example figure 12 in this:=0A= >>>>> https://static.googleusercontent.com/media/research.google.com/sv//p= =0A= >>>>> ubs/archive/46403.pdf=0A= >>>>>=0A= >>>>>=0A= >>>>> D. Section 2.7:=0A= >>>>>=0A= >>>>> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that= =0A= >>>>> uses STUN to discover the path MTU, and so might be a suitable=0A= >>>>> approach to be used in conjunction with a TURN server that support= s=0A= >>>>> the DONT-FRAGMENT attribute. When the client includes the DONT-= =0A= >>>>> FRAGMENT attribute in a Send indication, this tells the server to = set=0A= >>>>> the DF bit in the resulting UDP datagram that it sends to the peer= .=0A= >>>>> Since some servers may be unable to set the DF bit, the client sho= uld=0A= >>>>> also include this attribute in the Allocate request -- any server= =0A= >>>>> that does not support the DONT-FRAGMENT attribute will indicate th= is=0A= >>>>> by rejecting the Allocate request.=0A= >>>>>=0A= >>>>> I want to verify that the WG is working on resolving the issues with= =0A= >>>>> the STUN PMTUD document. I definitely sees the point of the=0A= >>>>> recommendation, but only if the WG will conclude on that document in= =0A= >>>>> a reasonable time frame.=0A= >>>>>=0A= >>>>> E. Section 3:=0A= >>>>>=0A= >>>>> Server-Reflexive Transport Address: A transport address on the=0A= >>>>> "public side" of a NAT. This address is allocated by the NAT t= o=0A= >>>>> correspond to a specific host transport address.=0A= >>>>>=0A= >>>>> Shouldn't "public side" be replace with "external side"? That is the= =0A= >>>>> terminology used by the Behave RFCs.=0A= >>>>>=0A= >>>>> F. Section 3:=0A= >>>>>=0A= >>>>> 5-tuple: The combination (client IP address and port, server IP= =0A= >>>>> address and port, and transport protocol (currently one of UDP,= =0A= >>>>> TCP, or (D)TLS)) used to communicate between the client and the= =0A= >>>>> server.=0A= >>>>>=0A= >>>>> I see some issues that the 5-tuple aggregates the transport protocol= =0A= >>>>> with the security protocol. I agree from the TURN protocol=0A= >>>>> perspective the protocol combination is the important one. However,= =0A= >>>>> writing like you do here you obfuscate both that when security is in= =0A= >>>>> place you have a combination, as well as that there are 4=0A= >>>>> alternatives defined by this document.=0A= >>>>>=0A= >>>>> G. Section 4.1:=0A= >>>>>=0A= >>>>> The "turn" and "turns" URI schemes are used to designate a TURN=0A= >>>>> server (also known as a relay) on Internet hosts accessible using = the=0A= >>>>> TURN protocol. The TURN protocol supports sending messages over U= DP,=0A= >>>>> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST b= e=0A= >>>>> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and t= he=0A= >>>>> "turn" scheme MUST be used otherwise. The required part of= =0A= >>>>> the "turn" URI denotes the TURN server host. The part, if= =0A= >>>>> present, denotes the port on which the TURN server is awaiting=0A= >>>>> connection requests. If it is absent, the default port is 3478 fo= r=0A= >>>>> both UDP and TCP. The default port for TURN over TLS and TURN ove= r=0A= >>>>> DTLS is 5349.=0A= >>>>>=0A= >>>>> First, I was wondering if this document needed to update RFC 7065?=0A= >>>>> The high level obvious is the reference, but otherwise on the=0A= >>>>> surface it doesn't look necessary. My main complaint when reading=0A= >>>>> was that it was not obvious what not specifying the transport=0A= >>>>> parameter means. Then I saw this in Section 3.1 of RFC 7065:=0A= >>>>>=0A= >>>>> The , , and components are passed without= =0A= >>>>> modification to the [RFC5928] algorithm. is set to false= if=0A= >>>>> is equal to "turn", and set to true if is equal = to=0A= >>>>> "turns" and passed to the [RFC5928] algorithm with the other=0A= >>>>> components.=0A= >>>>>=0A= >>>>> After some digging I figured out that RFC5928 is actually updated by= =0A= >>>>> RFC=0A= >>>>> 7350 that defines the resolution and SRV records for DTLS.=0A= >>>>>=0A= >>>>> Can you please update the text in Section 4 to also reference RFC=0A= >>>>> 7350 so that one doesn't miss this definitions.=0A= >>>>>=0A= >>>>> H. Section 5:=0A= >>>>>=0A= >>>>> If the server requires requests to be=0A= >>>>> authenticated, then the server's administrator MUST choose a realm= =0A= >>>>> value that will uniquely identify the username and password=0A= >>>>> combination that the client must use, even if the client uses=0A= >>>>> multiple servers under different administrations.=0A= >>>>>=0A= >>>>> Just to verify, TURN does not allow a single server address to host= =0A= >>>>> multiple realms do it? Each Realm needs its own unique server=0A= >>>>> transport address?=0A= >>>>>=0A= >>>>> I. Section 5:=0A= >>>>>=0A= >>>>> For each Allocate request, the server SHOULD generate a=0A= >>>>> new random nonce when the allocation is first attempted following = the=0A= >>>>> randomness recommendations in [RFC4086] and SHOULD expire the=0A= >> nonce=0A= >>>>> at least once every hour during the lifetime of the allocation.=0A= >>>>>=0A= >>>>> So, I think this text due to its use of RFC 2119 language is a bit=0A= >>>>> confusing in its relation to STUNbis. To me it is unclear if the=0A= >>>>> above overrides completely what is written in Section 5 of STUNbis:= =0A= >>>>>=0A= >>>>> To indicate that it supports this specification, a server MUST=0A= >>>>> prepend the NONCE attribute value with the character string compos= ed=0A= >>>>> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648= ]=0A= >>>>> encoding of the 24 bit STUN Security Features as defined in=0A= >>>>> Section 18.1. The 24 bit Security Feature set is encoded as 3 byt= es,=0A= >>>>> with bit 0 as the most significant bit of the first byte and bit 2= 3=0A= >>>>> as the least significant bit of the third byte. If no security=0A= >>>>> features are used, then a byte array with all 24 bits set to zero= =0A= >>>>> MUST be encoded instead. For the remainder of this document the t= erm=0A= >>>>> "nonce cookie" will refer to the complete 13 character string=0A= >>>>> prepended to the NONCE attribute value.=0A= >>>>>=0A= >>>>> Or is the randomness recommendations in TURNbis only for the NONCE=0A= >>>>> attribute value part?=0A= >>>>>=0A= >>>>> Secondly, I interpret the text to say that compared to STUN, where a= =0A= >>>>> Nonce can be long lived after the initial Long Term Credential=0A= >>>>> establishment, in TURN for each allocation one will have to to the=0A= >>>>> Allocate, expired nonce->here is your new nonce, resend allocate=0A= >>>>> using new nonce, success dance.=0A= >>>>>=0A= >>>>> I think part of the problem with the above text in TURNbis is that=0A= >>>>> the sentences prior to the quoted one appear to be rehashing of the= =0A= >>>>> STUNbis requirements. Then the quoted part that actually changes=0A= >>>>> behavior without being clear about it. I think it would be good to=0A= >>>>> make it clear what is a change compared to STUNbis.=0A= >>>>>=0A= >>>>> J. Section 6:=0A= >>>>>=0A= >>>>> Note that, rather than storing the password explicitly, for=0A= >>>>> security reasons, it may be desirable for the server to store the = key=0A= >>>>> value, which is a secure hash over the username, realm, and passwo= rd=0A= >>>>> (see [I-D.ietf-tram-stunbis]).=0A= >>>>>=0A= >>>>> Why isn't this recommendation stronger. Are there any reasons why a= =0A= >>>>> server would actually store the plain text password at all?=0A= >>>>>=0A= >>>>> K. Section 7.1:=0A= >>>>>=0A= >>>>> The client first picks a host transport address. It is RECOMMENDE= D=0A= >>>>> that the client pick a currently unused transport address, typical= ly=0A= >>>>> by allowing the underlying OS to pick a currently unused port for = a=0A= >>>>> new socket.=0A= >>>>>=0A= >>>>> I think talk about socket in this context should be skipped as it=0A= >>>>> otherwise have been eliminated.=0A= >>>>>=0A= >>>>> L. Section 7.1:=0A= >>>>>=0A= >>>>> The client then picks a transport protocol to use between the clien= t=0A= >>>>> and the server. The transport protocol MUST be one of UDP, TCP, T= LS-=0A= >>>>> over-TCP or DTLS-over-UDP.=0A= >>>>>=0A= >>>>> I find it strange that this indicates that one should pick the=0A= >>>>> transport protocol to use client to server without considering the=0A= >>>>> server capabilities. Especially as the client configuration or=0A= >>>>> server discovery procedures will indicate transport protocol support.= =0A= >>>>>=0A= >>>>> Secondly, what is the motivation for the MUST in the second sentence?= =0A= >>>>> This is appears to have strange interactions with any future=0A= >>>>> extensions and have no impact. A client must obvious chose a client= =0A= >>>>> to server transport protocol it supports, and one that the server=0A= >>>>> supports or the client hope it will support.=0A= >>>>>=0A= >>>>> M. Section 7.1:=0A= >>>>>=0A= >>>>> The client also picks a server transport address, which SHOULD be= =0A= >>>>> done as follows. The client uses one or more procedures described= in=0A= >>>>> [RFC8155] to discover a TURN server and uses the TURN server=0A= >>>>> resolution mechanism defined in [RFC5928] to get a list of server= =0A= >>>>> transport addresses that can be tried to create a TURN allocation.= =0A= >>>>>=0A= >>>>> 1) So RFC 8155 states that it has no recommendation on server=0A= >>>>> selection, nor on how to related local configuration to any auto-disc= overy=0A= >> servers.=0A= >>>>> To me it appears that the protocol utilizing TURN should consider=0A= >>>>> what makes sense in their deployments. Thus, does the need for such= =0A= >>>>> consideration needs to be highlighted somewhere in this specification= .=0A= >>>>>=0A= >>>>> 2) The RFC5928 reference should be complemented with an RFC 7350=0A= >>>>> reference.=0A= >>>>>=0A= >>>>> N. Section 7.1:=0A= >>>>>=0A= >>>>> Clients MUST NOT include a REQUESTED-ADDRESS-=0A= >>>>> FAMILY attribute in an Allocate request that contains a RESERVATIO= N-=0A= >>>>> TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >>>>>=0A= >>>>> Considering that this document obsoletes RFC 6156, I think it is bad= =0A= >>>>> form to reference that document, rather than to move the necessary=0A= >>>>> motivation into this document.=0A= >>>>>=0A= >>>>> O. Section 7.1:=0A= >>>>>=0A= >>>>> If the client wishes to obtain a relayed transport address of a=0A= >>>>> specific address type then it includes a REQUESTED-ADDRESS-FAMILY= =0A= >>>>> attribute in the request.=0A= >>>>>=0A= >>>>> I don't find anything describing what the default behavior is if one= =0A= >>>>> doesn't include the attribute, but the TURN server supports multiple= =0A= >>>>> address families.=0A= >>>>>=0A= >>>>> I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= >>>>> Should the text in 7.1 be explicit about this default?=0A= >>>>>=0A= >>>>> P. Section 7.2:=0A= >>>>>=0A= >>>>> Otherwise, if the attribute is included but=0A= >>>>> specifies a protocol other that UDP, the server rejects the= =0A= >>>>> request with a 442 (Unsupported Transport Protocol) error.=0A= >>>>>=0A= >>>>> Assuming that you don't support an extension for that transport=0A= >>>>> protocol. Should that be made explicit?=0A= >>>>>=0A= >>>>> Q. Section 8.3:=0A= >>>>>=0A= >>>>> If the client receives a success response to its Refresh request w= ith=0A= >>>>> a non-zero lifetime, it updates its copy of the allocation data=0A= >>>>> structure with the time-to-expiry value contained in the response.= =0A= >>>>>=0A= >>>>> If the client receives a 437 (Allocation Mismatch) error response = to=0A= >>>>> a request to delete the allocation, then the allocation no longer= =0A= >>>>> exists and it should consider its request as having effectively=0A= >>>>> succeeded.=0A= >>>>>=0A= >>>>> So there are no considerations for the client if it receives an=0A= >>>>> error response to a refresh request when Lifetime was non-zero?=0A= >>>>>=0A= >>>>> I am bit surprised by that. I assume that there are certain cases=0A= >>>>> when the request could be resent, and others where the meaning is=0A= >>>>> that the allocation is gone.=0A= >>>>>=0A= >>>>> R. Section 11.5:=0A= >>>>>=0A= >>>>> When the server receives an ICMP packet, the server verifies that = the=0A= >>>>> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or eithe= r=0A= >>>>> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that = the=0A= >>>>> IP packet in the ICMP packet payload contains a UDP header. If=0A= >>>>> either of these conditions fail, then the ICMP packet is silently= =0A= >>>>> dropped.=0A= >>>>>=0A= >>>>> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter= =0A= >>>>> Problem are for ICMPv4?=0A= >>>>>=0A= >>>>> S. Section 12.5:=0A= >>>>>=0A= >>>>> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded= =0A= >> to=0A= >>>>> a multiple of four bytes in order to ensure the alignment of=0A= >>>>> subsequent messages. The padding is not reflected in the length= =0A= >>>>> field of the ChannelData message, so the actual size of a ChannelD= ata=0A= >>>>> message (including padding) is (4 + Length) rounded up to the near= est=0A= >>>>> multiple of 4. Over UDP, the padding is not required but MAY be= =0A= >>>>> included.=0A= >>>>>=0A= >>>>> Are there anywhere written what one may or may not include of the=0A= >>>>> TURN related messages in a single UDP datagram. Because it is=0A= >>>>> technically feasible I belive to include two Send Indications in one= =0A= >>>>> UDP datagram to the server.=0A= >>>>>=0A= >>>>> T. Section 13.1:=0A= >>>>>=0A= >>>>> Flow Label=0A= >>>>>=0A= >>>>> Preferred behavior: The relay sets the Flow label to 0. The re= lay=0A= >>>>> can choose to set the Flow label to a different value if it=0A= >>>>> supports the IPv6 Flow Label field [RFC6437].=0A= >>>>>=0A= >>>>> Alternate behavior: The relay sets the Flow label to the defaul= t=0A= >>>>> value for outgoing packets.=0A= >>>>>=0A= >>>>> I think this section should be improved in two ways.=0A= >>>>>=0A= >>>>> First of all I think it should clarify that each allocation to peer= =0A= >>>>> flow is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= >>>>>=0A= >>>>> Secondly, I think in the spirit of RFC 6473 the preferred behavior=0A= >>>>> should be to set the IPv6 flow label if the implementation is=0A= >>>>> capable, or leave it to the underlying network stack to actually set= =0A= >>>>> it. Compared to RFC 7915, the TURN server actually have an=0A= >>>>> understanding of what are different flows without having examining=0A= >> additional protocol layers.=0A= >>>>>=0A= >>>>> Thirdly, I don't understand what the alternative behavior actually is= .=0A= >>>>> This as it is either setting it to 0, or classifying things as flow= =0A= >>>>> and then provide it with a random flow label. I think the right=0A= >>>>> alternative behavior is to set it 0.=0A= >>>>>=0A= >>>>> U. Section 13. 1,2,3:=0A= >>>>>=0A= >>>>> For both preferred and alternate behavior, the DONT-FRAGMENT=0A= >>>>> attribute MUST be ignored by the server.=0A= >>>>>=0A= >>>>> I don't understand why just because one performs v4<->v6 or v6 to v4= =0A= >>>>> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= >>>>> attribute. If the client has request to not fragment and the server= =0A= >>>>> is unable to do that when forwarding to the peer it needs to=0A= >>>>> generate an ICMP attribute response saying the packet is to big.=0A= >>>>> Otherwise the relay breaks the Path MTU discovery mechanisms.=0A= >>>>>=0A= >>>>> V. Section 13.2:=0A= >>>>>=0A= >>>>> Fragmentation:=0A= >>>>>=0A= >>>>> If the incoming packet included a Fragment header and the outgo= ing=0A= >>>>> packet size exceeds the outgoing link's MTU, the relay MUST=0A= >>>>> fragment the outgoing packet into fragments of no more than 128= 0=0A= >>>>> bytes. The relay sets the fields of the Fragment header as=0A= >>>>> appropriate for a packet originating from the server.=0A= >>>>>=0A= >>>>> Is really the intention here to refragment the packet without=0A= >>>>> providing any indication that the practical MTU is smaller than what= =0A= >>>>> the peer or client thinks it is?=0A= >>>>>=0A= >>>>> W. Section 14:=0A= >>>>>=0A= >>>>> Preferred Behavior: Set the outgoing value to the incoming valu= e,=0A= >>>>> UNLESS the server is doing Active Queue Management, the incomin= g=0A= >>>>> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the serv= er=0A= >>>>> wishes to indicate that congestion has been experienced, in whi= ch=0A= >>>>> case set the outgoing value to CE (=3D0b11).=0A= >>>>>=0A= >>>>> First of all do you have any special meaning with all capital UNLESS?= =0A= >>>>>=0A= >>>>> Secondly, I don't know how wise it is to have partial definitions of= =0A= >>>>> what the ECN behavior is. Maybe simpler to say that that the relay=0A= >>>>> is performing AQM it can support the ECN marking behavior as defined= =0A= >>>>> in RFC 3168.=0A= >>>>>=0A= >>>>> X. Section 14:=0A= >>>>>=0A= >>>>> How are these IP level fields handled when the transport is TCP or=0A= >>>>> TLS/TCP? There there are not necessary a one to one mapping between= =0A= >>>>> datagrams and TCP packets. And if there are no support then there=0A= >>>>> are need for clarification of behaviors when using TCP based transpor= t.=0A= >>>>>=0A= >>>>> Y. Section 16.4. DATA=0A= >>>>>=0A= >>>>> The DATA attribute is present in all Send and Data indications. T= he=0A= >>>>> value portion of this attribute is variable length and consists of= =0A= >>>>> the application data (that is, the data that would immediately fol= low=0A= >>>>> the UDP header if the data was been sent directly between the clie= nt=0A= >>>>> and the peer). If the length of this attribute is not a multiple = of=0A= >>>>> 4, then padding must be added after this attribute.=0A= >>>>>=0A= >>>>> Can you please clarify if one would get all the remaining bytes of=0A= >>>>> the IP packet payload or only the number of bytes the UDP length=0A= >>>>> field indiactes?=0A= >>>>>=0A= >>>>> The reason I ask is that there is possibility that there are a=0A= >>>>> discrepancy between these fields, something the proposal for an=0A= >>>>> experimental specification for UDP options attempt to utilize.=0A= >>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >>>>>=0A= >>>>> Note, I only want you to clarify what is actually included. I would= =0A= >>>>> assume using the UDP length field makes sense in this case.=0A= >>>>>=0A= >>>>> Z. The use of "relay" in the meaning of "Turn Server". There are=0A= >>>>> many occurrences of relay in this meaning. Either make it explicit=0A= >>>>> to be a synonym or change it to server.=0A= >>>>>=0A= >>>>> AA. Section 16.7=0A= >>>>>=0A= >>>>> rffu is lacking a definition. I would suggest making it upper case=0A= >>>>> and copy the definition from 16.8.=0A= >>>>>=0A= >>>>> AB. Section 16.12:=0A= >>>>>=0A= >>>>> Rsvd in Format figure does not match definition below which uses=0A= >> "Reserved".=0A= >>>>>=0A= >>>>> AC. Section 16.12:=0A= >>>>>=0A= >>>>> Reason Phrase (variable). This field is under defined. First of all= =0A= >>>>> the format of the text string is not defined, which it is in Stunbis= =0A= >>>>> Error-Code attribute is defined as.=0A= >>>>>=0A= >>>>> The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= >>>>> sequence of less than 128 characters (which can be as long as 509= =0A= >>>>> bytes when encoding them or 763 bytes when decoding them).=0A= >>>>>=0A= >>>>> Secondly, I think it might be worth pointing out the padding here.=0A= >>>>> It is not clear if there is any form of string termination and how=0A= >>>>> the padding which will be interpreted as NULL characters 0-3=0A= >>>>> depending on the alignment. I note this later issue appears to be exi= sting in=0A= >> STUNBis also.=0A= >>>>>=0A= >>>>> AD. Section 16.2:=0A= >>>>>=0A= >>>>> Why isn't the text here say that this attribute may also be used to= =0A= >>>>> indicate the desired lifetime in allocation requests?=0A= >>>>>=0A= >>>>> AE. Section 16.9: DONT-FRAGMENT=0A= >>>>>=0A= >>>>> I think it would be good to indicate the use of the attribute in=0A= >>>>> Allocate Requests also.=0A= >>>>>=0A= >>>>> AF. Section 24.2=0A= >>>>>=0A= >>>>> [Protocol-Numbers]=0A= >>>>> "IANA Protocol Numbers Registry", 2005,=0A= >>>>> .=0A= >>>>>=0A= >>>>> This is a normative reference based on how it is used in Section 16.8= .=0A= >>>>>=0A= >>>>> AG. Seciton 18.=0A= >>>>>=0A= >>>>> Sometime before the 20 minute lifetime is up, the client refreshes= =0A= >>>>> the allocation. This is done using a Refresh request. As before,= =0A= >>>>> the client includes the latest username, realm, and nonce values i= n=0A= >>>>> the request. The client also includes the SOFTWARE attribute,=0A= >>>>> following the recommended practice of always including this attrib= ute=0A= >>>>> in Allocate and Refresh messages. When the server receives the=0A= >>>>> Refresh request, it notices that the nonce value has expired, and = so=0A= >>>>> replies with 438 (Stale Nonce) error given a new nonce value. The= =0A= >>>>> client then reattempts the request, this time with the new nonce= =0A= >>>>> value. This second attempt is accepted, and the server replies wi= th=0A= >>>>> a success response. Note that the client did not include a LIFETI= ME=0A= >>>>> attribute in the request, so the server refreshes the allocation f= or=0A= >>>>> the default lifetime of 10 minutes (as can be seen by the LIFETIME= =0A= >>>>> attribute in the success response).=0A= >>>>>=0A= >>>>> I notice that this part nor the text before appears to discuss the=0A= >>>>> permission lifetime that will expire after 5 minutes. Thus, it needs= =0A= >>>>> to be refreshed prior to the Allocation.=0A= >>>>>=0A= >>>>> AH. Section 18.=0A= >>>>>=0A= >>>>> I am missing any example having to do with Address Family interaction= s.=0A= >>>>>=0A= >>>>> AI. DTLS Cipher Suits=0A= >>>>>=0A= >>>>> Am I understanding it correct that the definition of what DTLS=0A= >>>>> cipher suit that a TURN Server currently is to support is the ones in= RFC=0A= >> 7525?=0A= >>>>>=0A= >>>>> In that case, I think the wording is a bit weak as the only=0A= >>>>> reference I find are in Section 2.1:=0A= >>>>>=0A= >>>>> If (D)TLS transport is=0A= >>>>> used between the TURN client and the TURN server, the guidance giv= en=0A= >>>>> in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= >>>>>=0A= >>>>>=0A= >>>>> Cheers=0A= >>>>>=0A= >>>>> Magnus Westerlund=0A= >>>>>=0A= >>>>> --------------------------------------------------------------------= =0A= >>>>> -- Network Architecture & Protocols, Ericsson Research=0A= >>>>> ---------------------------------------------------------------------= -=0A= >>>>> Ericsson AB | Phone +46 10 7148287=0A= >>>>> Torshamnsgatan 23 | Mobile +46 73 0949079=0A= >>>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com= =0A= >>>>> --------------------------------------------------------------------= =0A= >>>>> --=0A= >>>>>=0A= >>>>>=0A= >>>>> _______________________________________________=0A= >>>>> tram mailing list=0A= >>>>> tram@ietf.org=0A= >>>>> https://www.ietf.org/mailman/listinfo/tram=0A= >>>>>=0A= >>>>=0A= >>>=0A= >>=0A= >> _______________________________________________=0A= >> tram mailing list=0A= >> tram@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/tram=0A= > =0A= From nobody Mon Apr 15 07:21:43 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D27F120375; Mon, 15 Apr 2019 07:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9tSfpB0dia7; Mon, 15 Apr 2019 07:21:37 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40051.outbound.protection.outlook.com [40.107.4.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA7821201AA; Mon, 15 Apr 2019 07:21:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UoGQAXRmQIXEyUxDvbHVSzyuD2oA5UgfQwpBNjpiAHs=; b=XTvWLDcx/ph0rYZQsl7JrhlgA02Ww3lHr4+gce39nB3woQtXLdDpF9XSu+NTERovylXPE5Orip4uY8JQBy79clPfMgdxrV0zVsThgvYe3M15166j19HGKJY32Oci9GVEVeleDCb5rgwJ2AtD/wgNKaAsqs/ecnpHck6pU0Mryhc= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2828.eurprd07.prod.outlook.com (10.168.94.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Mon, 15 Apr 2019 14:21:33 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Mon, 15 Apr 2019 14:21:33 +0000 From: Magnus Westerlund To: Gonzalo Camarillo , "Konda, Tirumaleswar Reddy" , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Mon, 15 Apr 2019 14:21:33 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 37072baf-b7fe-4711-b0ae-08d6c1ada95a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2828; x-ms-traffictypediagnostic: HE1PR0701MB2828: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(396003)(376002)(366004)(136003)(13464003)(51914003)(189003)(199004)(25584004)(3846002)(14454004)(25786009)(186003)(71200400001)(71190400001)(478600001)(7696005)(99286004)(966005)(6116002)(561944003)(44832011)(76176011)(68736007)(30864003)(81166006)(53546011)(102836004)(66574012)(52536014)(8936002)(26005)(2501003)(5660300002)(33656002)(8676002)(6506007)(105586002)(106356001)(93886005)(53946003)(110136005)(6246003)(256004)(18074004)(305945005)(66066001)(7736002)(14444005)(81156014)(86362001)(476003)(74316002)(9686003)(6306002)(316002)(229853002)(97736004)(6436002)(2906002)(446003)(55016002)(53936002)(486006)(2201001)(151285002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2828; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ApWtZ5BEtIBBHLnTQkvg73AnVk985wgGnMEJ9XopBp7GgR+9hPJW8K6aoFvfdSUOPqy6ki6ndR4epxUiEXHQb8/m2XK4EM4ybc9TiyUl2Zl3AU1ARZnbwdN4/GFH6G6yy9+OmOtEg489O4Fwzxr8ocfI8R62sTInQPjmPLA5hDq2ipXYc+UtmMl3yKOP9ZoIe3OC2p6cxhOSVoQom+8hxsl+SZPNARKxkXwHmmrawC2xEIxnDvz9IWsE7d0TH0Vv02suP4G4HAqI0doJcOEx/G2QJ2mBlKeEsDACYQZw+dsZGHMkjrN+eE+ubVabNMa9IdOZry31b6hR/JuiTnr2gG9VdpvdNAwfEwZCaDa9p1gkd2A8SHa3ApKt6/LKsulJNeYpz2mbrb0S3urGLYs/QG1bxO/cnVzVIEbcRDPaXbs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37072baf-b7fe-4711-b0ae-08d6c1ada95a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 14:21:33.1897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2828 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 15 Apr 2019 14:21:42 -0000 On 2019-04-15 15:43, Gonzalo Camarillo wrote:=0A= > Hi Magnus,=0A= >=0A= > could you please look into Tiru's responses and let us know how you want= =0A= > to proceed? Thanks!=0A= =0A= =0A= Working on it. There are many questions and comments to answer on.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= =0A= =0A= >=0A= > Cheers,=0A= >=0A= > Gonzalo=0A= >=0A= > On 15-Apr-19 14:05, Konda, Tirumaleswar Reddy wrote:=0A= >>> -----Original Message-----=0A= >>> From: tram On Behalf Of Gonzalo Camarillo=0A= >>> Sent: Monday, April 15, 2019 4:09 PM=0A= >>> To: Magnus Westerlund ; tram@ietf.org;= =0A= >>> draft-ietf-tram-turnbis@ietf.org=0A= >>> Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23=0A= >>>=0A= >>>=0A= >>>=0A= >>> Authors of TURNbis,=0A= >>>=0A= >>> could you please look into this and let us know your time plan to addre= ss=0A= >>> Magnus's review? Thanks!=0A= >> I have already responded to the comments from Magnus https://mailarchive= .ietf.org/arch/msg/tram/CVcl_2D-uads0zw3kS9uVqr0WFk, waiting for his respon= se.=0A= >>=0A= >> Cheers,=0A= >> -Tiru=0A= >>=0A= >>> Cheers,=0A= >>>=0A= >>> Gonzalo=0A= >>>=0A= >>> On 05-Apr-19 11:20, Gonzalo Camarillo wrote:=0A= >>>> Thanks for the review, Magnus!=0A= >>>>=0A= >>>> Authors, could you please look into Magnus's comments and provide him= =0A= >>>> with responses?=0A= >>>>=0A= >>>> Thanks,=0A= >>>>=0A= >>>> Gonzalo=0A= >>>>=0A= >>>> On 05-Apr-19 10:11, Magnus Westerlund wrote:=0A= >>>>> Hi,=0A= >>>>>=0A= >>>>> One addition.=0A= >>>>>=0A= >>>>> Section 16.13. ICMP Attribute=0A= >>>>>=0A= >>>>> This attribute is flawed as it lacks a data part to carry values=0A= >>>>> certain codes have. I specifically think of ICMPv6 Type =3D 2, Packet= Too Big.=0A= >>>>> That message has a 32-bit unsigned integer carrying the MTU of the=0A= >>>>> Next Hop Link that causes the ICMP message to be sent. That really=0A= >>>>> should be replicated back to the client.=0A= >>>>>=0A= >>>>> There is also the question if ICMP messages for Parameter Problem=0A= >>>>> should included the pointer?=0A= >>>>>=0A= >>>>> I really think there need to be a 32-bit data field with the ICMP=0A= >>>>> attribute.=0A= >>>>>=0A= >>>>> Cheers=0A= >>>>>=0A= >>>>> Magnus=0A= >>>>>=0A= >>>>>=0A= >>>>> On 2019-04-04 16:00, Magnus Westerlund wrote:=0A= >>>>>> Hi,=0A= >>>>>>=0A= >>>>>> I have now finished the AD review. There are a lot of details that I= =0A= >>>>>> think needs fixing or at least feedback on. I also think there are a= =0A= >>>>>> couple of more serious issues here. Especially regarding the=0A= >>>>>> handling of MTU and fragmentation, as well as IP header fields in=0A= >>>>>> address family translation and with non UDP transport. We need to=0A= >>>>>> conclude on these before we go to IETF last call.=0A= >>>>>>=0A= >>>>>> My Review comments are:=0A= >>>>>>=0A= >>>>>> A. Section 1: "The client can arrange=0A= >>>>>> for the server to relay packets to and from certain other hosts= =0A= >>>>>> (called peers) and can control aspects of how the relaying is don= e."=0A= >>>>>>=0A= >>>>>> I don't think this is an accurate description of what Turn does. One= =0A= >>>>>> may easily get the impression that the whole packet TURN receives=0A= >>>>>> are relayed, rather than the transport protocol data part and some= =0A= >>>>>> of the header information are relayed between the client <-> peer,= =0A= >>>>>> with a knowledge of the peer transport address for the client. I=0A= >>>>>> think that should be clarified in the introduction.=0A= >>>>>>=0A= >>>>>> B. Section 2.7:=0A= >>>>>>=0A= >>>>>> "Applications using TCP can more or less=0A= >>>>>> ignore this issue because fragmentation avoidance is now a standa= rd=0A= >>>>>> part of TCP, but applications using UDP (and thus any application= =0A= >>>>>> using this version of TURN) must handle fragmentation avoidance= =0A= >>>>>> themselves."=0A= >>>>>>=0A= >>>>>> Lower case "must", and as the document uses RFC 2119, this must have= =0A= >>>>>> the meaning of "MUST". A reformulation here is likely in order.=0A= >>>>>>=0A= >>>>>> C. Section 2.7:=0A= >>>>>>=0A= >>>>>> In this approach, the application exploits the=0A= >>>>>> fact that the IP specification [RFC0791] specifies that IP packet= s up=0A= >>>>>> to 576 bytes should never need to be fragmented.=0A= >>>>>>=0A= >>>>>> As a guideline, sending a maximum of 500 bytes of application dat= a in=0A= >>>>>> a single TURN message (by the client on the client-to-server leg)= or=0A= >>>>>> a UDP datagram (by the peer on the peer-to-server leg) will gener= ally=0A= >>>>>> avoid IP fragmentation. To further reduce the chance of=0A= >>>>>> fragmentation, it is recommended that the client use ChannelData= =0A= >>>>>> messages when transferring significant volumes of data, since the= =0A= >>>>>> overhead of the ChannelData message is less than Send and Data=0A= >>>>>> indications.=0A= >>>>>>=0A= >>>>>> In that first paragraph I think it is worth discussing the IPv6=0A= >>>>>> requirement of supporting a 1280 minimal size.=0A= >>>>>>=0A= >>>>>> Secondly, I think recommending only a 500 MTU is way to conservative= .=0A= >>>>>> Those studies I have seen appears to indicate that at least 1220=0A= >>>>>> bytes UDP payloads should be be working as well as 500 bytes. See=0A= >>>>>> for example figure 12 in this:=0A= >>>>>> https://static.googleusercontent.com/media/research.google.com/sv//p= =0A= >>>>>> ubs/archive/46403.pdf=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> D. Section 2.7:=0A= >>>>>>=0A= >>>>>> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that= =0A= >>>>>> uses STUN to discover the path MTU, and so might be a suitable=0A= >>>>>> approach to be used in conjunction with a TURN server that suppor= ts=0A= >>>>>> the DONT-FRAGMENT attribute. When the client includes the DONT-= =0A= >>>>>> FRAGMENT attribute in a Send indication, this tells the server to= set=0A= >>>>>> the DF bit in the resulting UDP datagram that it sends to the pee= r.=0A= >>>>>> Since some servers may be unable to set the DF bit, the client sh= ould=0A= >>>>>> also include this attribute in the Allocate request -- any server= =0A= >>>>>> that does not support the DONT-FRAGMENT attribute will indicate t= his=0A= >>>>>> by rejecting the Allocate request.=0A= >>>>>>=0A= >>>>>> I want to verify that the WG is working on resolving the issues with= =0A= >>>>>> the STUN PMTUD document. I definitely sees the point of the=0A= >>>>>> recommendation, but only if the WG will conclude on that document in= =0A= >>>>>> a reasonable time frame.=0A= >>>>>>=0A= >>>>>> E. Section 3:=0A= >>>>>>=0A= >>>>>> Server-Reflexive Transport Address: A transport address on the= =0A= >>>>>> "public side" of a NAT. This address is allocated by the NAT = to=0A= >>>>>> correspond to a specific host transport address.=0A= >>>>>>=0A= >>>>>> Shouldn't "public side" be replace with "external side"? That is the= =0A= >>>>>> terminology used by the Behave RFCs.=0A= >>>>>>=0A= >>>>>> F. Section 3:=0A= >>>>>>=0A= >>>>>> 5-tuple: The combination (client IP address and port, server IP= =0A= >>>>>> address and port, and transport protocol (currently one of UDP= ,=0A= >>>>>> TCP, or (D)TLS)) used to communicate between the client and th= e=0A= >>>>>> server.=0A= >>>>>>=0A= >>>>>> I see some issues that the 5-tuple aggregates the transport protocol= =0A= >>>>>> with the security protocol. I agree from the TURN protocol=0A= >>>>>> perspective the protocol combination is the important one. However,= =0A= >>>>>> writing like you do here you obfuscate both that when security is in= =0A= >>>>>> place you have a combination, as well as that there are 4=0A= >>>>>> alternatives defined by this document.=0A= >>>>>>=0A= >>>>>> G. Section 4.1:=0A= >>>>>>=0A= >>>>>> The "turn" and "turns" URI schemes are used to designate a TURN= =0A= >>>>>> server (also known as a relay) on Internet hosts accessible using= the=0A= >>>>>> TURN protocol. The TURN protocol supports sending messages over = UDP,=0A= >>>>>> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST = be=0A= >>>>>> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and = the=0A= >>>>>> "turn" scheme MUST be used otherwise. The required part o= f=0A= >>>>>> the "turn" URI denotes the TURN server host. The part, if= =0A= >>>>>> present, denotes the port on which the TURN server is awaiting=0A= >>>>>> connection requests. If it is absent, the default port is 3478 f= or=0A= >>>>>> both UDP and TCP. The default port for TURN over TLS and TURN ov= er=0A= >>>>>> DTLS is 5349.=0A= >>>>>>=0A= >>>>>> First, I was wondering if this document needed to update RFC 7065?= =0A= >>>>>> The high level obvious is the reference, but otherwise on the=0A= >>>>>> surface it doesn't look necessary. My main complaint when reading=0A= >>>>>> was that it was not obvious what not specifying the transport=0A= >>>>>> parameter means. Then I saw this in Section 3.1 of RFC 7065:=0A= >>>>>>=0A= >>>>>> The , , and components are passed without= =0A= >>>>>> modification to the [RFC5928] algorithm. is set to fals= e if=0A= >>>>>> is equal to "turn", and set to true if is equal= to=0A= >>>>>> "turns" and passed to the [RFC5928] algorithm with the other=0A= >>>>>> components.=0A= >>>>>>=0A= >>>>>> After some digging I figured out that RFC5928 is actually updated by= =0A= >>>>>> RFC=0A= >>>>>> 7350 that defines the resolution and SRV records for DTLS.=0A= >>>>>>=0A= >>>>>> Can you please update the text in Section 4 to also reference RFC=0A= >>>>>> 7350 so that one doesn't miss this definitions.=0A= >>>>>>=0A= >>>>>> H. Section 5:=0A= >>>>>>=0A= >>>>>> If the server requires requests to be=0A= >>>>>> authenticated, then the server's administrator MUST choose a real= m=0A= >>>>>> value that will uniquely identify the username and password=0A= >>>>>> combination that the client must use, even if the client uses=0A= >>>>>> multiple servers under different administrations.=0A= >>>>>>=0A= >>>>>> Just to verify, TURN does not allow a single server address to host= =0A= >>>>>> multiple realms do it? Each Realm needs its own unique server=0A= >>>>>> transport address?=0A= >>>>>>=0A= >>>>>> I. Section 5:=0A= >>>>>>=0A= >>>>>> For each Allocate request, the server SHOULD generate a=0A= >>>>>> new random nonce when the allocation is first attempted following= the=0A= >>>>>> randomness recommendations in [RFC4086] and SHOULD expire the=0A= >>> nonce=0A= >>>>>> at least once every hour during the lifetime of the allocation.= =0A= >>>>>>=0A= >>>>>> So, I think this text due to its use of RFC 2119 language is a bit= =0A= >>>>>> confusing in its relation to STUNbis. To me it is unclear if the=0A= >>>>>> above overrides completely what is written in Section 5 of STUNbis:= =0A= >>>>>>=0A= >>>>>> To indicate that it supports this specification, a server MUST=0A= >>>>>> prepend the NONCE attribute value with the character string compo= sed=0A= >>>>>> of "obMatJos2" concatenated with the (4 character) Base64 [RFC464= 8]=0A= >>>>>> encoding of the 24 bit STUN Security Features as defined in=0A= >>>>>> Section 18.1. The 24 bit Security Feature set is encoded as 3 by= tes,=0A= >>>>>> with bit 0 as the most significant bit of the first byte and bit = 23=0A= >>>>>> as the least significant bit of the third byte. If no security= =0A= >>>>>> features are used, then a byte array with all 24 bits set to zero= =0A= >>>>>> MUST be encoded instead. For the remainder of this document the = term=0A= >>>>>> "nonce cookie" will refer to the complete 13 character string=0A= >>>>>> prepended to the NONCE attribute value.=0A= >>>>>>=0A= >>>>>> Or is the randomness recommendations in TURNbis only for the NONCE= =0A= >>>>>> attribute value part?=0A= >>>>>>=0A= >>>>>> Secondly, I interpret the text to say that compared to STUN, where a= =0A= >>>>>> Nonce can be long lived after the initial Long Term Credential=0A= >>>>>> establishment, in TURN for each allocation one will have to to the= =0A= >>>>>> Allocate, expired nonce->here is your new nonce, resend allocate=0A= >>>>>> using new nonce, success dance.=0A= >>>>>>=0A= >>>>>> I think part of the problem with the above text in TURNbis is that= =0A= >>>>>> the sentences prior to the quoted one appear to be rehashing of the= =0A= >>>>>> STUNbis requirements. Then the quoted part that actually changes=0A= >>>>>> behavior without being clear about it. I think it would be good to= =0A= >>>>>> make it clear what is a change compared to STUNbis.=0A= >>>>>>=0A= >>>>>> J. Section 6:=0A= >>>>>>=0A= >>>>>> Note that, rather than storing the password explicitly, for=0A= >>>>>> security reasons, it may be desirable for the server to store the= key=0A= >>>>>> value, which is a secure hash over the username, realm, and passw= ord=0A= >>>>>> (see [I-D.ietf-tram-stunbis]).=0A= >>>>>>=0A= >>>>>> Why isn't this recommendation stronger. Are there any reasons why a= =0A= >>>>>> server would actually store the plain text password at all?=0A= >>>>>>=0A= >>>>>> K. Section 7.1:=0A= >>>>>>=0A= >>>>>> The client first picks a host transport address. It is RECOMMEND= ED=0A= >>>>>> that the client pick a currently unused transport address, typica= lly=0A= >>>>>> by allowing the underlying OS to pick a currently unused port for= a=0A= >>>>>> new socket.=0A= >>>>>>=0A= >>>>>> I think talk about socket in this context should be skipped as it=0A= >>>>>> otherwise have been eliminated.=0A= >>>>>>=0A= >>>>>> L. Section 7.1:=0A= >>>>>>=0A= >>>>>> The client then picks a transport protocol to use between the clie= nt=0A= >>>>>> and the server. The transport protocol MUST be one of UDP, TCP, = TLS-=0A= >>>>>> over-TCP or DTLS-over-UDP.=0A= >>>>>>=0A= >>>>>> I find it strange that this indicates that one should pick the=0A= >>>>>> transport protocol to use client to server without considering the= =0A= >>>>>> server capabilities. Especially as the client configuration or=0A= >>>>>> server discovery procedures will indicate transport protocol support= .=0A= >>>>>>=0A= >>>>>> Secondly, what is the motivation for the MUST in the second sentence= ?=0A= >>>>>> This is appears to have strange interactions with any future=0A= >>>>>> extensions and have no impact. A client must obvious chose a client= =0A= >>>>>> to server transport protocol it supports, and one that the server=0A= >>>>>> supports or the client hope it will support.=0A= >>>>>>=0A= >>>>>> M. Section 7.1:=0A= >>>>>>=0A= >>>>>> The client also picks a server transport address, which SHOULD be= =0A= >>>>>> done as follows. The client uses one or more procedures describe= d in=0A= >>>>>> [RFC8155] to discover a TURN server and uses the TURN server=0A= >>>>>> resolution mechanism defined in [RFC5928] to get a list of server= =0A= >>>>>> transport addresses that can be tried to create a TURN allocation= .=0A= >>>>>>=0A= >>>>>> 1) So RFC 8155 states that it has no recommendation on server=0A= >>>>>> selection, nor on how to related local configuration to any auto-dis= covery=0A= >>> servers.=0A= >>>>>> To me it appears that the protocol utilizing TURN should consider=0A= >>>>>> what makes sense in their deployments. Thus, does the need for such= =0A= >>>>>> consideration needs to be highlighted somewhere in this specificatio= n.=0A= >>>>>>=0A= >>>>>> 2) The RFC5928 reference should be complemented with an RFC 7350=0A= >>>>>> reference.=0A= >>>>>>=0A= >>>>>> N. Section 7.1:=0A= >>>>>>=0A= >>>>>> Clients MUST NOT include a REQUESTED-ADDRESS-=0A= >>>>>> FAMILY attribute in an Allocate request that contains a RESERVATI= ON-=0A= >>>>>> TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >>>>>>=0A= >>>>>> Considering that this document obsoletes RFC 6156, I think it is bad= =0A= >>>>>> form to reference that document, rather than to move the necessary= =0A= >>>>>> motivation into this document.=0A= >>>>>>=0A= >>>>>> O. Section 7.1:=0A= >>>>>>=0A= >>>>>> If the client wishes to obtain a relayed transport address of a= =0A= >>>>>> specific address type then it includes a REQUESTED-ADDRESS-FAMILY= =0A= >>>>>> attribute in the request.=0A= >>>>>>=0A= >>>>>> I don't find anything describing what the default behavior is if one= =0A= >>>>>> doesn't include the attribute, but the TURN server supports multiple= =0A= >>>>>> address families.=0A= >>>>>>=0A= >>>>>> I see that bullet 7 in Section 7.2 indicates that IPv4 is default.= =0A= >>>>>> Should the text in 7.1 be explicit about this default?=0A= >>>>>>=0A= >>>>>> P. Section 7.2:=0A= >>>>>>=0A= >>>>>> Otherwise, if the attribute is included but=0A= >>>>>> specifies a protocol other that UDP, the server rejects the= =0A= >>>>>> request with a 442 (Unsupported Transport Protocol) error.= =0A= >>>>>>=0A= >>>>>> Assuming that you don't support an extension for that transport=0A= >>>>>> protocol. Should that be made explicit?=0A= >>>>>>=0A= >>>>>> Q. Section 8.3:=0A= >>>>>>=0A= >>>>>> If the client receives a success response to its Refresh request = with=0A= >>>>>> a non-zero lifetime, it updates its copy of the allocation data= =0A= >>>>>> structure with the time-to-expiry value contained in the response= .=0A= >>>>>>=0A= >>>>>> If the client receives a 437 (Allocation Mismatch) error response= to=0A= >>>>>> a request to delete the allocation, then the allocation no longer= =0A= >>>>>> exists and it should consider its request as having effectively= =0A= >>>>>> succeeded.=0A= >>>>>>=0A= >>>>>> So there are no considerations for the client if it receives an=0A= >>>>>> error response to a refresh request when Lifetime was non-zero?=0A= >>>>>>=0A= >>>>>> I am bit surprised by that. I assume that there are certain cases=0A= >>>>>> when the request could be resent, and others where the meaning is=0A= >>>>>> that the allocation is gone.=0A= >>>>>>=0A= >>>>>> R. Section 11.5:=0A= >>>>>>=0A= >>>>>> When the server receives an ICMP packet, the server verifies that= the=0A= >>>>>> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or eith= er=0A= >>>>>> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that= the=0A= >>>>>> IP packet in the ICMP packet payload contains a UDP header. If= =0A= >>>>>> either of these conditions fail, then the ICMP packet is silently= =0A= >>>>>> dropped.=0A= >>>>>>=0A= >>>>>> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter= =0A= >>>>>> Problem are for ICMPv4?=0A= >>>>>>=0A= >>>>>> S. Section 12.5:=0A= >>>>>>=0A= >>>>>> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded= =0A= >>> to=0A= >>>>>> a multiple of four bytes in order to ensure the alignment of=0A= >>>>>> subsequent messages. The padding is not reflected in the length= =0A= >>>>>> field of the ChannelData message, so the actual size of a Channel= Data=0A= >>>>>> message (including padding) is (4 + Length) rounded up to the nea= rest=0A= >>>>>> multiple of 4. Over UDP, the padding is not required but MAY be= =0A= >>>>>> included.=0A= >>>>>>=0A= >>>>>> Are there anywhere written what one may or may not include of the=0A= >>>>>> TURN related messages in a single UDP datagram. Because it is=0A= >>>>>> technically feasible I belive to include two Send Indications in one= =0A= >>>>>> UDP datagram to the server.=0A= >>>>>>=0A= >>>>>> T. Section 13.1:=0A= >>>>>>=0A= >>>>>> Flow Label=0A= >>>>>>=0A= >>>>>> Preferred behavior: The relay sets the Flow label to 0. The r= elay=0A= >>>>>> can choose to set the Flow label to a different value if it=0A= >>>>>> supports the IPv6 Flow Label field [RFC6437].=0A= >>>>>>=0A= >>>>>> Alternate behavior: The relay sets the Flow label to the defau= lt=0A= >>>>>> value for outgoing packets.=0A= >>>>>>=0A= >>>>>> I think this section should be improved in two ways.=0A= >>>>>>=0A= >>>>>> First of all I think it should clarify that each allocation to peer= =0A= >>>>>> flow is its own IPv6 Flow in perspective of the IPv6 Flow label.=0A= >>>>>>=0A= >>>>>> Secondly, I think in the spirit of RFC 6473 the preferred behavior= =0A= >>>>>> should be to set the IPv6 flow label if the implementation is=0A= >>>>>> capable, or leave it to the underlying network stack to actually set= =0A= >>>>>> it. Compared to RFC 7915, the TURN server actually have an=0A= >>>>>> understanding of what are different flows without having examining= =0A= >>> additional protocol layers.=0A= >>>>>> Thirdly, I don't understand what the alternative behavior actually i= s.=0A= >>>>>> This as it is either setting it to 0, or classifying things as flow= =0A= >>>>>> and then provide it with a random flow label. I think the right=0A= >>>>>> alternative behavior is to set it 0.=0A= >>>>>>=0A= >>>>>> U. Section 13. 1,2,3:=0A= >>>>>>=0A= >>>>>> For both preferred and alternate behavior, the DONT-FRAGMENT= =0A= >>>>>> attribute MUST be ignored by the server.=0A= >>>>>>=0A= >>>>>> I don't understand why just because one performs v4<->v6 or v6 to v4= =0A= >>>>>> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT= =0A= >>>>>> attribute. If the client has request to not fragment and the server= =0A= >>>>>> is unable to do that when forwarding to the peer it needs to=0A= >>>>>> generate an ICMP attribute response saying the packet is to big.=0A= >>>>>> Otherwise the relay breaks the Path MTU discovery mechanisms.=0A= >>>>>>=0A= >>>>>> V. Section 13.2:=0A= >>>>>>=0A= >>>>>> Fragmentation:=0A= >>>>>>=0A= >>>>>> If the incoming packet included a Fragment header and the outg= oing=0A= >>>>>> packet size exceeds the outgoing link's MTU, the relay MUST=0A= >>>>>> fragment the outgoing packet into fragments of no more than 12= 80=0A= >>>>>> bytes. The relay sets the fields of the Fragment header as=0A= >>>>>> appropriate for a packet originating from the server.=0A= >>>>>>=0A= >>>>>> Is really the intention here to refragment the packet without=0A= >>>>>> providing any indication that the practical MTU is smaller than what= =0A= >>>>>> the peer or client thinks it is?=0A= >>>>>>=0A= >>>>>> W. Section 14:=0A= >>>>>>=0A= >>>>>> Preferred Behavior: Set the outgoing value to the incoming val= ue,=0A= >>>>>> UNLESS the server is doing Active Queue Management, the incomi= ng=0A= >>>>>> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the ser= ver=0A= >>>>>> wishes to indicate that congestion has been experienced, in wh= ich=0A= >>>>>> case set the outgoing value to CE (=3D0b11).=0A= >>>>>>=0A= >>>>>> First of all do you have any special meaning with all capital UNLESS= ?=0A= >>>>>>=0A= >>>>>> Secondly, I don't know how wise it is to have partial definitions of= =0A= >>>>>> what the ECN behavior is. Maybe simpler to say that that the relay= =0A= >>>>>> is performing AQM it can support the ECN marking behavior as defined= =0A= >>>>>> in RFC 3168.=0A= >>>>>>=0A= >>>>>> X. Section 14:=0A= >>>>>>=0A= >>>>>> How are these IP level fields handled when the transport is TCP or= =0A= >>>>>> TLS/TCP? There there are not necessary a one to one mapping between= =0A= >>>>>> datagrams and TCP packets. And if there are no support then there=0A= >>>>>> are need for clarification of behaviors when using TCP based transpo= rt.=0A= >>>>>>=0A= >>>>>> Y. Section 16.4. DATA=0A= >>>>>>=0A= >>>>>> The DATA attribute is present in all Send and Data indications. = The=0A= >>>>>> value portion of this attribute is variable length and consists o= f=0A= >>>>>> the application data (that is, the data that would immediately fo= llow=0A= >>>>>> the UDP header if the data was been sent directly between the cli= ent=0A= >>>>>> and the peer). If the length of this attribute is not a multiple= of=0A= >>>>>> 4, then padding must be added after this attribute.=0A= >>>>>>=0A= >>>>>> Can you please clarify if one would get all the remaining bytes of= =0A= >>>>>> the IP packet payload or only the number of bytes the UDP length=0A= >>>>>> field indiactes?=0A= >>>>>>=0A= >>>>>> The reason I ask is that there is possibility that there are a=0A= >>>>>> discrepancy between these fields, something the proposal for an=0A= >>>>>> experimental specification for UDP options attempt to utilize.=0A= >>>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >>>>>>=0A= >>>>>> Note, I only want you to clarify what is actually included. I would= =0A= >>>>>> assume using the UDP length field makes sense in this case.=0A= >>>>>>=0A= >>>>>> Z. The use of "relay" in the meaning of "Turn Server". There are=0A= >>>>>> many occurrences of relay in this meaning. Either make it explicit= =0A= >>>>>> to be a synonym or change it to server.=0A= >>>>>>=0A= >>>>>> AA. Section 16.7=0A= >>>>>>=0A= >>>>>> rffu is lacking a definition. I would suggest making it upper case= =0A= >>>>>> and copy the definition from 16.8.=0A= >>>>>>=0A= >>>>>> AB. Section 16.12:=0A= >>>>>>=0A= >>>>>> Rsvd in Format figure does not match definition below which uses=0A= >>> "Reserved".=0A= >>>>>> AC. Section 16.12:=0A= >>>>>>=0A= >>>>>> Reason Phrase (variable). This field is under defined. First of all= =0A= >>>>>> the format of the text string is not defined, which it is in Stunbis= =0A= >>>>>> Error-Code attribute is defined as.=0A= >>>>>>=0A= >>>>>> The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= >>>>>> sequence of less than 128 characters (which can be as long as 509= =0A= >>>>>> bytes when encoding them or 763 bytes when decoding them).=0A= >>>>>>=0A= >>>>>> Secondly, I think it might be worth pointing out the padding here.= =0A= >>>>>> It is not clear if there is any form of string termination and how= =0A= >>>>>> the padding which will be interpreted as NULL characters 0-3=0A= >>>>>> depending on the alignment. I note this later issue appears to be ex= isting in=0A= >>> STUNBis also.=0A= >>>>>> AD. Section 16.2:=0A= >>>>>>=0A= >>>>>> Why isn't the text here say that this attribute may also be used to= =0A= >>>>>> indicate the desired lifetime in allocation requests?=0A= >>>>>>=0A= >>>>>> AE. Section 16.9: DONT-FRAGMENT=0A= >>>>>>=0A= >>>>>> I think it would be good to indicate the use of the attribute in=0A= >>>>>> Allocate Requests also.=0A= >>>>>>=0A= >>>>>> AF. Section 24.2=0A= >>>>>>=0A= >>>>>> [Protocol-Numbers]=0A= >>>>>> "IANA Protocol Numbers Registry", 2005,=0A= >>>>>> .=0A= >>>>>>=0A= >>>>>> This is a normative reference based on how it is used in Section 16.= 8.=0A= >>>>>>=0A= >>>>>> AG. Seciton 18.=0A= >>>>>>=0A= >>>>>> Sometime before the 20 minute lifetime is up, the client refreshe= s=0A= >>>>>> the allocation. This is done using a Refresh request. As before= ,=0A= >>>>>> the client includes the latest username, realm, and nonce values = in=0A= >>>>>> the request. The client also includes the SOFTWARE attribute,=0A= >>>>>> following the recommended practice of always including this attri= bute=0A= >>>>>> in Allocate and Refresh messages. When the server receives the= =0A= >>>>>> Refresh request, it notices that the nonce value has expired, and= so=0A= >>>>>> replies with 438 (Stale Nonce) error given a new nonce value. Th= e=0A= >>>>>> client then reattempts the request, this time with the new nonce= =0A= >>>>>> value. This second attempt is accepted, and the server replies w= ith=0A= >>>>>> a success response. Note that the client did not include a LIFET= IME=0A= >>>>>> attribute in the request, so the server refreshes the allocation = for=0A= >>>>>> the default lifetime of 10 minutes (as can be seen by the LIFETIM= E=0A= >>>>>> attribute in the success response).=0A= >>>>>>=0A= >>>>>> I notice that this part nor the text before appears to discuss the= =0A= >>>>>> permission lifetime that will expire after 5 minutes. Thus, it needs= =0A= >>>>>> to be refreshed prior to the Allocation.=0A= >>>>>>=0A= >>>>>> AH. Section 18.=0A= >>>>>>=0A= >>>>>> I am missing any example having to do with Address Family interactio= ns.=0A= >>>>>>=0A= >>>>>> AI. DTLS Cipher Suits=0A= >>>>>>=0A= >>>>>> Am I understanding it correct that the definition of what DTLS=0A= >>>>>> cipher suit that a TURN Server currently is to support is the ones i= n RFC=0A= >>> 7525?=0A= >>>>>> In that case, I think the wording is a bit weak as the only=0A= >>>>>> reference I find are in Section 2.1:=0A= >>>>>>=0A= >>>>>> If (D)TLS transport is=0A= >>>>>> used between the TURN client and the TURN server, the guidance gi= ven=0A= >>>>>> in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> Cheers=0A= >>>>>>=0A= >>>>>> Magnus Westerlund=0A= >>>>>>=0A= >>>>>> --------------------------------------------------------------------= =0A= >>>>>> -- Network Architecture & Protocols, Ericsson Research=0A= >>>>>> --------------------------------------------------------------------= --=0A= >>>>>> Ericsson AB | Phone +46 10 7148287=0A= >>>>>> Torshamnsgatan 23 | Mobile +46 73 0949079=0A= >>>>>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com= =0A= >>>>>> --------------------------------------------------------------------= =0A= >>>>>> --=0A= >>>>>>=0A= >>>>>>=0A= >>>>>> _______________________________________________=0A= >>>>>> tram mailing list=0A= >>>>>> tram@ietf.org=0A= >>>>>> https://www.ietf.org/mailman/listinfo/tram=0A= >>>>>>=0A= >>> _______________________________________________=0A= >>> tram mailing list=0A= >>> tram@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/tram=0A= =0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Tue Apr 16 01:58:47 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55569120152; Tue, 16 Apr 2019 01:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYF7JIY4B4XW; Tue, 16 Apr 2019 01:58:42 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE92120140; Tue, 16 Apr 2019 01:58:42 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1555404798; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=QD4CmEL0cfiGlWVUrQ58UNVCRDC0JOv2KsGEtL sAzXY=; b=M+TofFb2/g/hCVmbah1GtLOSMxaxtTxhzKq+OjxW hhsoeQVcjd6sl401E3Ul1xOVWlEoRYAjsK5pjH3OfzwgGlg0Gh pVq8K5iqUArDmqvzq84cWgrgDQzgWQZPG7HZYiR8zxucaZ9znk 4q/pGz3aK1PtNRXf2W0rk/vgHE5VkOA= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 177f_101b_c03ab591_0d1a_44c6_bdeb_d881498a4f9a; Tue, 16 Apr 2019 02:53:17 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Apr 2019 02:58:17 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 16 Apr 2019 02:58:17 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 16 Apr 2019 02:58:09 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2997.namprd16.prod.outlook.com (20.178.235.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.18; Tue, 16 Apr 2019 08:58:08 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1813.011; Tue, 16 Apr 2019 08:58:08 +0000 From: "Konda, Tirumaleswar Reddy" To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiP6Y9aIDw Date: Tue, 16 Apr 2019 08:58:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d778c87-9506-4086-6804-08d6c249a56b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2997; x-ms-traffictypediagnostic: BYAPR16MB2997: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(346002)(39860400002)(396003)(32952001)(51444003)(189003)(199004)(13464003)(102836004)(53546011)(6436002)(2906002)(316002)(6506007)(76176011)(486006)(446003)(30864003)(80792005)(11346002)(476003)(186003)(71190400001)(71200400001)(26005)(110136005)(6116002)(66574012)(7696005)(561944003)(99286004)(229853002)(97736004)(74316002)(305945005)(7736002)(3846002)(55016002)(33656002)(966005)(68736007)(105586002)(5660300002)(106356001)(256004)(14444005)(18074004)(66066001)(2201001)(25786009)(52536014)(6306002)(81156014)(86362001)(81166006)(8676002)(53936002)(2501003)(9686003)(478600001)(72206003)(6246003)(53946003)(14454004)(8936002)(151285002)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2997; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sXCH8nsxMUrazMlzODw1r1yq/lmwi9n4AamJJeIowsojyRh43Tuv2QwpgZo7u8BTorx90kTV6s0p9oSgojNjKNDrL+pzFG1PI9+CC59POkDIoWXJYkHu47Ac5Op0EmK6VdYhhVWrAmgpV7D9dSsyYspSpZtj7GcXuCdEE0qAKAj6SvAQAXcDw0SuFAC3x7XeS8UehHcRs+CY4Rw51dBvrDjCoxrpvazXt45hVwDo5BA+/rxrelvDVoy6vXGTkpr5cc5RW2eXQQnx8qnsCUtxalTxGMJdED6C33ltgFajwxuoKb9reNxkKBfUXAvbqsTja1i6vMqz8LE3+Vyv2FipuzloAEOpzHa1cv2vg5+CmIPeASnQVlz9jfZBynco0DLRjgaYmMCCfvRlraNuQU5e21LWsHNA0U0VnS6pVXcl+D0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d778c87-9506-4086-6804-08d6c249a56b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 08:58:08.0973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2997 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6525> : inlines <7053> : streams <1818811> : uri <2832917> Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 16 Apr 2019 08:58:47 -0000 Hi Magnus, Please see inline. > -----Original Message----- > From: tram On Behalf Of Magnus Westerlund > Sent: Friday, April 5, 2019 1:42 PM > To: tram@ietf.org; draft-ietf-tram-turnbis@ietf.org > Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 >=20 >=20 >=20 > Hi, >=20 > One addition. >=20 > Section 16.13. ICMP Attribute >=20 > This attribute is flawed as it lacks a data part to carry values certain = codes have. > I specifically think of ICMPv6 Type =3D 2, Packet Too Big. > That message has a 32-bit unsigned integer carrying the MTU of the Next H= op > Link that causes the ICMP message to be sent. That really should be repli= cated > back to the client. Agreed, will update the attribute. NEW: Error Data: If the ICMPv6 type is 2 (Packet Too Big Message), the Error Data field will be set to the Maximum Transmission Unit of the next-hop link (Section 3.2 of [RFC4443]). For other ICMPv6 and ICMPv4 types, Error Data field MUST be set to zero. >=20 > There is also the question if ICMP messages for Parameter Problem should > included the pointer? For IPv6 to IPv6 translation, the TURN server relays the transport protocol= data to peer without any extension headers (except the fragmentation heade= r, please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#sectio= n-13.2), so ICMPv6 Parameter problem will not happen because of extension headers an= d need not be relayed to the client. Cheers, -Tiru >=20 > I really think there need to be a 32-bit data field with the ICMP attribu= te. >=20 > Cheers >=20 > Magnus >=20 >=20 > On 2019-04-04 16:00, Magnus Westerlund wrote: > > Hi, > > > > I have now finished the AD review. There are a lot of details that I > > think needs fixing or at least feedback on. I also think there are a > > couple of more serious issues here. Especially regarding the handling > > of MTU and fragmentation, as well as IP header fields in address > > family translation and with non UDP transport. We need to conclude on > > these before we go to IETF last call. > > > > My Review comments are: > > > > A. Section 1: "The client can arrange > > for the server to relay packets to and from certain other hosts > > (called peers) and can control aspects of how the relaying is done." > > > > I don't think this is an accurate description of what Turn does. One > > may easily get the impression that the whole packet TURN receives are > > relayed, rather than the transport protocol data part and some of the > > header information are relayed between the client <-> peer, with a > > knowledge of the peer transport address for the client. I think that > > should be clarified in the introduction. > > > > B. Section 2.7: > > > > "Applications using TCP can more or less > > ignore this issue because fragmentation avoidance is now a standard > > part of TCP, but applications using UDP (and thus any application > > using this version of TURN) must handle fragmentation avoidance > > themselves." > > > > Lower case "must", and as the document uses RFC 2119, this must have > > the meaning of "MUST". A reformulation here is likely in order. > > > > C. Section 2.7: > > > > In this approach, the application exploits the > > fact that the IP specification [RFC0791] specifies that IP packets u= p > > to 576 bytes should never need to be fragmented. > > > > As a guideline, sending a maximum of 500 bytes of application data i= n > > a single TURN message (by the client on the client-to-server leg) or > > a UDP datagram (by the peer on the peer-to-server leg) will generall= y > > avoid IP fragmentation. To further reduce the chance of > > fragmentation, it is recommended that the client use ChannelData > > messages when transferring significant volumes of data, since the > > overhead of the ChannelData message is less than Send and Data > > indications. > > > > In that first paragraph I think it is worth discussing the IPv6 > > requirement of supporting a 1280 minimal size. > > > > Secondly, I think recommending only a 500 MTU is way to conservative. > > Those studies I have seen appears to indicate that at least 1220 bytes > > UDP payloads should be be working as well as 500 bytes. See for > > example figure 12 in this: > > https://static.googleusercontent.com/media/research.google.com/sv//pub > > s/archive/46403.pdf > > > > > > D. Section 2.7: > > > > [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that > > uses STUN to discover the path MTU, and so might be a suitable > > approach to be used in conjunction with a TURN server that supports > > the DONT-FRAGMENT attribute. When the client includes the DONT- > > FRAGMENT attribute in a Send indication, this tells the server to se= t > > 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 shoul= d > > 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. > > > > I want to verify that the WG is working on resolving the issues with > > the STUN PMTUD document. I definitely sees the point of the > > recommendation, but only if the WG will conclude on that document in a > > reasonable time frame. > > > > E. Section 3: > > > > Server-Reflexive Transport Address: A transport address on the > > "public side" of a NAT. This address is allocated by the NAT to > > correspond to a specific host transport address. > > > > Shouldn't "public side" be replace with "external side"? That is the > > terminology used by the Behave RFCs. > > > > F. Section 3: > > > > 5-tuple: The combination (client IP address and port, server IP > > address and port, and transport protocol (currently one of UDP, > > TCP, or (D)TLS)) used to communicate between the client and the > > server. > > > > I see some issues that the 5-tuple aggregates the transport protocol > > with the security protocol. I agree from the TURN protocol perspective > > the protocol combination is the important one. However, writing like > > you do here you obfuscate both that when security is in place you have > > a combination, as well as that there are 4 alternatives defined by > > this document. > > > > G. Section 4.1: > > > > The "turn" and "turns" URI schemes are used to designate a TURN > > server (also known as a relay) on Internet hosts accessible using th= e > > TURN protocol. The TURN protocol supports sending messages over UDP= , > > TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be > > used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the > > "turn" scheme MUST be used otherwise. The required part of > > the "turn" URI denotes the TURN server host. The part, if > > present, denotes the port on which the TURN server is awaiting > > connection requests. If it is absent, the default port is 3478 for > > both UDP and TCP. The default port for TURN over TLS and TURN over > > DTLS is 5349. > > > > First, I was wondering if this document needed to update RFC 7065? The > > high level obvious is the reference, but otherwise on the surface it > > doesn't look necessary. My main complaint when reading was that it was > > not obvious what not specifying the transport parameter means. Then I > > saw this in Section 3.1 of RFC 7065: > > > > The , , and components are passed without > > modification to the [RFC5928] algorithm. is set to false i= f > > is equal to "turn", and set to true if is equal to > > "turns" and passed to the [RFC5928] algorithm with the other > > components. > > > > After some digging I figured out that RFC5928 is actually updated by > > RFC > > 7350 that defines the resolution and SRV records for DTLS. > > > > Can you please update the text in Section 4 to also reference RFC 7350 > > so that one doesn't miss this definitions. > > > > H. Section 5: > > > > If the server requires requests to be > > authenticated, then the server's administrator MUST choose a realm > > value that will uniquely identify the username and password > > combination that the client must use, even if the client uses > > multiple servers under different administrations. > > > > Just to verify, TURN does not allow a single server address to host > > multiple realms do it? Each Realm needs its own unique server > > transport address? > > > > I. Section 5: > > > > For each Allocate request, the server SHOULD generate a > > new random nonce when the allocation is first attempted following th= e > > randomness recommendations in [RFC4086] and SHOULD expire the nonce > > at least once every hour during the lifetime of the allocation. > > > > So, I think this text due to its use of RFC 2119 language is a bit > > confusing in its relation to STUNbis. To me it is unclear if the above > > overrides completely what is written in Section 5 of STUNbis: > > > > To indicate that it supports this specification, a server MUST > > prepend the NONCE attribute value with the character string composed > > of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648] > > encoding of the 24 bit STUN Security Features as defined in > > Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes= , > > with bit 0 as the most significant bit of the first byte and bit 23 > > as the least significant bit of the third byte. If no security > > features are used, then a byte array with all 24 bits set to zero > > MUST be encoded instead. For the remainder of this document the ter= m > > "nonce cookie" will refer to the complete 13 character string > > prepended to the NONCE attribute value. > > > > Or is the randomness recommendations in TURNbis only for the NONCE > > attribute value part? > > > > Secondly, I interpret the text to say that compared to STUN, where a > > Nonce can be long lived after the initial Long Term Credential > > establishment, in TURN for each allocation one will have to to the > > Allocate, expired nonce->here is your new nonce, resend allocate using > > new nonce, success dance. > > > > I think part of the problem with the above text in TURNbis is that the > > sentences prior to the quoted one appear to be rehashing of the > > STUNbis requirements. Then the quoted part that actually changes > > behavior without being clear about it. I think it would be good to > > make it clear what is a change compared to STUNbis. > > > > J. Section 6: > > > > Note that, rather than storing the password explicitly, for > > security reasons, it may be desirable for the server to store the ke= y > > value, which is a secure hash over the username, realm, and password > > (see [I-D.ietf-tram-stunbis]). > > > > Why isn't this recommendation stronger. Are there any reasons why a > > server would actually store the plain text password at all? > > > > K. Section 7.1: > > > > The client first picks a host transport address. It is RECOMMENDED > > that the client pick a currently unused transport address, typically > > by allowing the underlying OS to pick a currently unused port for a > > new socket. > > > > I think talk about socket in this context should be skipped as it > > otherwise have been eliminated. > > > > L. Section 7.1: > > > > The client then picks a transport protocol to use between the client > > and the server. The transport protocol MUST be one of UDP, TCP, TLS= - > > over-TCP or DTLS-over-UDP. > > > > I find it strange that this indicates that one should pick the > > transport protocol to use client to server without considering the > > server capabilities. Especially as the client configuration or server > > discovery procedures will indicate transport protocol support. > > > > Secondly, what is the motivation for the MUST in the second sentence? > > This is appears to have strange interactions with any future > > extensions and have no impact. A client must obvious chose a client to > > server transport protocol it supports, and one that the server > > supports or the client hope it will support. > > > > M. Section 7.1: > > > > The client also picks a server transport address, which SHOULD be > > done as follows. The client uses one or more procedures described i= n > > [RFC8155] to discover a TURN server and uses the TURN server > > resolution mechanism defined in [RFC5928] to get a list of server > > transport addresses that can be tried to create a TURN allocation. > > > > 1) So RFC 8155 states that it has no recommendation on server > > selection, nor on how to related local configuration to any auto-discov= ery > servers. > > To me it appears that the protocol utilizing TURN should consider what > > makes sense in their deployments. Thus, does the need for such > > consideration needs to be highlighted somewhere in this specification. > > > > 2) The RFC5928 reference should be complemented with an RFC 7350 > > reference. > > > > N. Section 7.1: > > > > Clients MUST NOT include a REQUESTED-ADDRESS- > > FAMILY attribute in an Allocate request that contains a RESERVATION- > > TOKEN attribute, for the reasons outlined in [RFC6156]. > > > > Considering that this document obsoletes RFC 6156, I think it is bad > > form to reference that document, rather than to move the necessary > > motivation into this document. > > > > O. Section 7.1: > > > > If the client wishes to obtain a relayed transport address of a > > specific address type then it includes a REQUESTED-ADDRESS-FAMILY > > attribute in the request. > > > > I don't find anything describing what the default behavior is if one > > doesn't include the attribute, but the TURN server supports multiple > > address families. > > > > I see that bullet 7 in Section 7.2 indicates that IPv4 is default. > > Should the text in 7.1 be explicit about this default? > > > > P. Section 7.2: > > > > Otherwise, if the attribute is included but > > specifies a protocol other that UDP, the server rejects the > > request with a 442 (Unsupported Transport Protocol) error. > > > > Assuming that you don't support an extension for that transport > > protocol. Should that be made explicit? > > > > Q. Section 8.3: > > > > If the client receives a success response to its Refresh request wit= h > > a non-zero lifetime, it updates its copy of the allocation data > > structure with the time-to-expiry value contained in the response. > > > > If the client receives a 437 (Allocation Mismatch) error response to > > a request to delete the allocation, then the allocation no longer > > exists and it should consider its request as having effectively > > succeeded. > > > > So there are no considerations for the client if it receives an error > > response to a refresh request when Lifetime was non-zero? > > > > I am bit surprised by that. I assume that there are certain cases when > > the request could be resent, and others where the meaning is that the > > allocation is gone. > > > > R. Section 11.5: > > > > When the server receives an ICMP packet, the server verifies that th= e > > type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either > > 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that th= e > > IP packet in the ICMP packet payload contains a UDP header. If > > either of these conditions fail, then the ICMP packet is silently > > dropped. > > > > Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter > > Problem are for ICMPv4? > > > > S. Section 12.5: > > > > Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to > > a multiple of four bytes in order to ensure the alignment of > > subsequent messages. The padding is not reflected in the length > > field of the ChannelData message, so the actual size of a ChannelDat= a > > message (including padding) is (4 + Length) rounded up to the neares= t > > multiple of 4. Over UDP, the padding is not required but MAY be > > included. > > > > Are there anywhere written what one may or may not include of the TURN > > related messages in a single UDP datagram. Because it is technically > > feasible I belive to include two Send Indications in one UDP datagram > > to the server. > > > > T. Section 13.1: > > > > Flow Label > > > > Preferred behavior: The relay sets the Flow label to 0. The rela= y > > can choose to set the Flow label to a different value if it > > supports the IPv6 Flow Label field [RFC6437]. > > > > Alternate behavior: The relay sets the Flow label to the default > > value for outgoing packets. > > > > I think this section should be improved in two ways. > > > > First of all I think it should clarify that each allocation to peer > > flow is its own IPv6 Flow in perspective of the IPv6 Flow label. > > > > Secondly, I think in the spirit of RFC 6473 the preferred behavior > > should be to set the IPv6 flow label if the implementation is capable, > > or leave it to the underlying network stack to actually set it. > > Compared to RFC 7915, the TURN server actually have an understanding > > of what are different flows without having examining additional protoco= l > layers. > > > > Thirdly, I don't understand what the alternative behavior actually is. > > This as it is either setting it to 0, or classifying things as flow > > and then provide it with a random flow label. I think the right > > alternative behavior is to set it 0. > > > > U. Section 13. 1,2,3: > > > > For both preferred and alternate behavior, the DONT-FRAGMENT > > attribute MUST be ignored by the server. > > > > I don't understand why just because one performs v4<->v6 or v6 to v4 > > translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT > > attribute. If the client has request to not fragment and the server is > > unable to do that when forwarding to the peer it needs to generate an > > ICMP attribute response saying the packet is to big. Otherwise the > > relay breaks the Path MTU discovery mechanisms. > > > > V. Section 13.2: > > > > Fragmentation: > > > > If the incoming packet included a Fragment header and the outgoin= g > > packet size exceeds the outgoing link's MTU, the relay MUST > > fragment the outgoing packet into fragments of no more than 1280 > > bytes. The relay sets the fields of the Fragment header as > > appropriate for a packet originating from the server. > > > > Is really the intention here to refragment the packet without > > providing any indication that the practical MTU is smaller than what > > the peer or client thinks it is? > > > > W. Section 14: > > > > Preferred Behavior: Set the outgoing value to the incoming value, > > UNLESS the server is doing Active Queue Management, the incoming > > ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server > > wishes to indicate that congestion has been experienced, in which > > case set the outgoing value to CE (=3D0b11). > > > > First of all do you have any special meaning with all capital UNLESS? > > > > Secondly, I don't know how wise it is to have partial definitions of > > what the ECN behavior is. Maybe simpler to say that that the relay is > > performing AQM it can support the ECN marking behavior as defined in > > RFC 3168. > > > > X. Section 14: > > > > How are these IP level fields handled when the transport is TCP or > > TLS/TCP? There there are not necessary a one to one mapping between > > datagrams and TCP packets. And if there are no support then there are > > need for clarification of behaviors when using TCP based transport. > > > > Y. Section 16.4. DATA > > > > The DATA attribute is present in all Send and Data indications. The > > value portion of this attribute is variable length and consists of > > the application data (that is, the data that would immediately follo= w > > the UDP header if the data was been sent directly between the client > > and the peer). If the length of this attribute is not a multiple of > > 4, then padding must be added after this attribute. > > > > Can you please clarify if one would get all the remaining bytes of the > > IP packet payload or only the number of bytes the UDP length field > > indiactes? > > > > The reason I ask is that there is possibility that there are a > > discrepancy between these fields, something the proposal for an > > experimental specification for UDP options attempt to utilize. > > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > > > > Note, I only want you to clarify what is actually included. I would > > assume using the UDP length field makes sense in this case. > > > > Z. The use of "relay" in the meaning of "Turn Server". There are many > > occurrences of relay in this meaning. Either make it explicit to be a > > synonym or change it to server. > > > > AA. Section 16.7 > > > > rffu is lacking a definition. I would suggest making it upper case and > > copy the definition from 16.8. > > > > AB. Section 16.12: > > > > Rsvd in Format figure does not match definition below which uses "Reser= ved". > > > > AC. Section 16.12: > > > > Reason Phrase (variable). This field is under defined. First of all > > the format of the text string is not defined, which it is in Stunbis > > Error-Code attribute is defined as. > > > > The reason phrase MUST be a UTF-8 [RFC3629] encoded > > sequence of less than 128 characters (which can be as long as 509 > > bytes when encoding them or 763 bytes when decoding them). > > > > Secondly, I think it might be worth pointing out the padding here. It > > is not clear if there is any form of string termination and how the > > padding which will be interpreted as NULL characters 0-3 depending on > > the alignment. I note this later issue appears to be existing in STUNBi= s also. > > > > AD. Section 16.2: > > > > Why isn't the text here say that this attribute may also be used to > > indicate the desired lifetime in allocation requests? > > > > AE. Section 16.9: DONT-FRAGMENT > > > > I think it would be good to indicate the use of the attribute in > > Allocate Requests also. > > > > AF. Section 24.2 > > > > [Protocol-Numbers] > > "IANA Protocol Numbers Registry", 2005, > > . > > > > This is a normative reference based on how it is used in Section 16.8. > > > > AG. Seciton 18. > > > > Sometime before the 20 minute lifetime is up, the client refreshes > > the allocation. This is done using a Refresh request. As before, > > the client includes the latest username, realm, and nonce values in > > the request. The client also includes the SOFTWARE attribute, > > following the recommended practice of always including this attribut= e > > in Allocate and Refresh messages. When the server receives the > > Refresh request, it notices that the nonce value has expired, and so > > replies with 438 (Stale Nonce) error given a new nonce value. The > > client then reattempts the request, this time with the new nonce > > value. This second attempt is accepted, and the server replies with > > a success response. Note that the client did not include a LIFETIME > > attribute in the request, so the server refreshes the allocation for > > the default lifetime of 10 minutes (as can be seen by the LIFETIME > > attribute in the success response). > > > > I notice that this part nor the text before appears to discuss the > > permission lifetime that will expire after 5 minutes. Thus, it needs > > to be refreshed prior to the Allocation. > > > > AH. Section 18. > > > > I am missing any example having to do with Address Family interactions. > > > > AI. DTLS Cipher Suits > > > > Am I understanding it correct that the definition of what DTLS cipher > > suit that a TURN Server currently is to support is the ones in RFC 7525= ? > > > > In that case, I think the wording is a bit weak as the only reference > > I find are in Section 2.1: > > > > If (D)TLS transport is > > used between the TURN client and the TURN server, the guidance given > > in [RFC7525] MUST be followed to avoid attacks on (D)TLS. > > > > > > Cheers > > > > Magnus Westerlund > > > > ---------------------------------------------------------------------- > > Network Architecture & Protocols, Ericsson Research > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > Torshamnsgatan 23 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Apr 16 05:32:40 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5A91201B3; Tue, 16 Apr 2019 05:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXW7ArnUIBt9; Tue, 16 Apr 2019 05:32:34 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130088.outbound.protection.outlook.com [40.107.13.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17C31200C3; Tue, 16 Apr 2019 05:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hv8fQRBVuJ/MPwjwE/x2i1ugbAWrXN9HohGQZUq0+iQ=; b=G0ySd7XKeZ9RNGcndM2q8+xkw1OtzPUVH14ulJQmbef7BeS8hcql+j8nPx5t1TpuxVcqbSLMsuEF6adnis1ytS9rfg8gEzIsDKb/LdSO2rqSIXyZ4vmb6dCsrs5MCy78Y2Yzvnu/aqqEKoAZNfsdIIke4zL+d99PQ3A8iOOx6Vw= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2202.eurprd07.prod.outlook.com (10.168.29.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.8; Tue, 16 Apr 2019 12:32:29 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Tue, 16 Apr 2019 12:32:29 +0000 From: Magnus Westerlund To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Tue, 16 Apr 2019 12:32:29 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 31256873-34d2-4c89-182c-08d6c2679767 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2202; x-ms-traffictypediagnostic: HE1PR0701MB2202: x-ms-exchange-purlcount: 21 x-microsoft-antispam-prvs: x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(376002)(366004)(346002)(189003)(51444003)(199004)(51914003)(13464003)(7736002)(81166006)(99286004)(55016002)(2201001)(71200400001)(53546011)(81156014)(8936002)(316002)(86362001)(68736007)(6306002)(9686003)(102836004)(74316002)(6506007)(2906002)(6116002)(53946003)(305945005)(7696005)(2501003)(26005)(6246003)(76176011)(110136005)(3846002)(8676002)(97736004)(44832011)(186003)(66066001)(66574012)(5660300002)(106356001)(14454004)(966005)(561944003)(476003)(25786009)(71190400001)(53936002)(105586002)(33656002)(478600001)(229853002)(52536014)(14444005)(18074004)(446003)(30864003)(6436002)(256004)(486006)(151285002)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2202; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: M9xU/nmPupQDQkF9vievlIEne3i4rnzkeMsWwP2/NXMUAk4RSonTAwT1Uz6V0GGjbrXpWmX1vroLHbEzqnTrb89+lShWfYHHIrToGRLjM2PzYMl6VuCGrcgsvls34a4CmJDKOZeipwbveIwErGvNOKxvtNXzl3pUMTJKGECsMGxuZETR4dfd9Tnk2tqlr1PComrBUVx/XsbGvoEUjU9OxXR5svsYVZv92qmD7KL+FBTusoS83/I7uz0pocpyFK+CoqmcJxmU2dy/3qL2kfm7uvBwR4lMMv7zULttU/ADABoTCo4UB/zVrRlhIFW5xf/ASYjSA3XCTJ8yxZPgegclho44AwDkHXo+trhwEXR70jRAhlyiWevyPrDyyd9SkFKWJrMR5j+E/UesVT6u2qSlJCuixT/rjydzOqqV0zRQVyA= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 31256873-34d2-4c89-182c-08d6c2679767 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 12:32:29.4998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2202 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 16 Apr 2019 12:32:39 -0000 Hi,=0A= =0A= Thanks for the reply. Sorry about the delay in responding. Comments below.= =0A= =0A= On 2019-04-11 10:27, Konda, Tirumaleswar Reddy wrote:=0A= > Hi Magnus,=0A= >=0A= > Thanks for the detailed review. Please see inline =0A= >=0A= >> -----Original Message-----=0A= >> From: tram On Behalf Of Magnus Westerlund=0A= >> Sent: Thursday, April 4, 2019 7:30 PM=0A= >> To: tram@ietf.org; draft-ietf-tram-turnbis@ietf.org=0A= >> Subject: [tram] AD Evaluation of draft-ietf-tram-turnbis-23=0A= >>=0A= >>=0A= >>=0A= >> Hi,=0A= >>=0A= >> I have now finished the AD review. There are a lot of details that I thi= nk needs=0A= >> fixing or at least feedback on. I also think there are a couple of more = serious=0A= >> issues here. Especially regarding the handling of MTU and fragmentation,= as=0A= >> well as IP header fields in address family translation and with non UDP= =0A= >> transport. We need to conclude on these before we go to IETF last call.= =0A= >>=0A= >> My Review comments are:=0A= >>=0A= >> A. Section 1: "The client can arrange=0A= >> for the server to relay packets to and from certain other hosts=0A= >> (called peers) and can control aspects of how the relaying is done."= =0A= >>=0A= >> I don't think this is an accurate description of what Turn does. One may= easily=0A= >> get the impression that the whole packet TURN receives are relayed, rath= er=0A= >> than the transport protocol data part and some of the header information= are=0A= >> relayed between the client <-> peer, with a knowledge of the peer transp= ort=0A= >> address for the client. I think that should be clarified in the introduc= tion.=0A= > Sure, updated the text as follows:=0A= >=0A= > When a peer sends a packet to the relayed transport address, the server r= elays the transport protocol data from the packet to the client. The client= knows the peer from which the transport protocol data was relayed by the s= erver. When the server receives an ICMP=0A= =0A= Should the last "When" be an "If"?=0A= =0A= > error packet, the server also relays certain layer 3/4 header fields fro= m the ICMP header to the client. When the client sends a packet to the serv= er, the server relays the transport protocol data from the packet to the ap= propriate peer using the relayed transport address as the source.=0A= =0A= "appropriate" appears wrong. The peer is the one the client have=0A= configure for the allocation. So I think a more direct language can be=0A= used.=0A= =0A= Othewise fine with me.=0A= =0A= =0A= >> B. Section 2.7:=0A= >>=0A= >> "Applications using TCP can more or less=0A= >> ignore this issue because fragmentation avoidance is now a standard= =0A= >> part of TCP, but applications using UDP (and thus any application=0A= >> using this version of TURN) must handle fragmentation avoidance=0A= >> themselves."=0A= >>=0A= >> Lower case "must", and as the document uses RFC 2119, this must have the= =0A= >> meaning of "MUST". A reformulation here is likely in order.=0A= > Replaced "must" with "MUST". =0A= =0A= I think it is inappropriate to make this into a MUST statement. There is=0A= no single answer for how the application handles it. The application=0A= needs to handle it or live with the consequences. I think swithing the=0A= "must" to "needs to" is more appropriate.=0A= =0A= =0A= =0A= >> C. Section 2.7:=0A= >>=0A= >> In this approach, the application exploits the=0A= >> fact that the IP specification [RFC0791] specifies that IP packets up= =0A= >> to 576 bytes should never need to be fragmented.=0A= >>=0A= >> As a guideline, sending a maximum of 500 bytes of application data in= =0A= >> a single TURN message (by the client on the client-to-server leg) or= =0A= >> a UDP datagram (by the peer on the peer-to-server leg) will generally= =0A= >> avoid IP fragmentation. To further reduce the chance of=0A= >> fragmentation, it is recommended that the client use ChannelData=0A= >> messages when transferring significant volumes of data, since the=0A= >> overhead of the ChannelData message is less than Send and Data=0A= >> indications.=0A= >>=0A= >> In that first paragraph I think it is worth discussing the IPv6 requirem= ent of=0A= >> supporting a 1280 minimal size.=0A= > Yes. =0A= >=0A= >> Secondly, I think recommending only a 500 MTU is way to conservative.=0A= >> Those studies I have seen appears to indicate that at least 1220 bytes U= DP=0A= >> payloads should be be working as well as 500 bytes. See for example figu= re 12=0A= >> in this:=0A= >> https://static.googleusercontent.com/media/research.google.com/sv//pubs/= arc=0A= >> hive/46403.pdf=0A= > I have updated the text as follows to address your comments:=0A= >=0A= > In this approach, the application MUST assume a=0A= > PMTU of 1280 bytes, as IPv6 requires that every link in the Internet= =0A= > have an MTU of 1280 octets or greater as specified in [RFC8200]. If= =0A= > IPv4 support on legacy or otherwise unusual networks is a=0A= > consideration, the application MAY assume on a PMTU of 576 bytes for= =0A= > IPv4 datagrams, as every IPv4 host must be capable of receiving a=0A= > packet whose length is equal to 576 bytes as discussed in [RFC0791].= =0A= =0A= Yes, I think that is quite good.=0A= =0A= =0A= >> D. Section 2.7:=0A= >>=0A= >> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that=0A= >> uses STUN to discover the path MTU, and so might be a suitable=0A= >> approach to be used in conjunction with a TURN server that supports= =0A= >> the DONT-FRAGMENT attribute. When the client includes the DONT-=0A= >> FRAGMENT attribute in a Send indication, this tells the server to set= =0A= >> the DF bit in the resulting UDP datagram that it sends to the peer.= =0A= >> Since some servers may be unable to set the DF bit, the client should= =0A= >> also include this attribute in the Allocate request -- any server=0A= >> that does not support the DONT-FRAGMENT attribute will indicate this= =0A= >> by rejecting the Allocate request.=0A= >>=0A= >> I want to verify that the WG is working on resolving the issues with the= STUN=0A= >> PMTUD document. I definitely sees the point of the recommendation, but o= nly=0A= >> if the WG will conclude on that document in a reasonable time frame.=0A= > The authors of the ietf-tram-stun-pmtud draft are working on resolving th= e DISCUSS from ISEG review.=0A= =0A= =0A= Great, looking forward to have that Discuss resolved.=0A= =0A= >=0A= >> E. Section 3:=0A= >>=0A= >> Server-Reflexive Transport Address: A transport address on the=0A= >> "public side" of a NAT. This address is allocated by the NAT to= =0A= >> correspond to a specific host transport address.=0A= >>=0A= >> Shouldn't "public side" be replace with "external side"? That is the ter= minology=0A= >> used by the Behave RFCs.=0A= > Okay, replaced "public side" with "external side". =0A= >=0A= >> F. Section 3:=0A= >>=0A= >> 5-tuple: The combination (client IP address and port, server IP=0A= >> address and port, and transport protocol (currently one of UDP,=0A= >> TCP, or (D)TLS)) used to communicate between the client and the=0A= >> server.=0A= >>=0A= >> I see some issues that the 5-tuple aggregates the transport protocol wit= h the=0A= >> security protocol. I agree from the TURN protocol perspective the protoc= ol=0A= >> combination is the important one. However, writing like you do here you= =0A= >> obfuscate both that when security is in place you have a combination, as= well as=0A= >> that there are 4 alternatives defined by this document.=0A= > (D)TLS can be considered as pseudo transport protocol. =0A= =0A= May I suggest that you simple reword it in this way:=0A= =0A= 5-tuple: The combination (client IP address and port, server IP=0A= address and port, and transport protocol (currently one of UDP,=0A= TCP, DTLS/UDP or TLS/TCP)) used to communicate between the client=0A= and the=0A= server. The 5-tuple uniquely identifies this communication=0A= stream. The 5-tuple also uniquely identifies the Allocation on=0A= the server.=0A= =0A= In this specification you are using the words Transport Protocol in a=0A= way that is not the most common understanding of the word. Thus, I think=0A= you should include a definition in section 3 of your usage of "Transport=0A= Protocol".=0A= =0A= Transport Protocol: The protocols above IP that carries TURN Requests,=0A= Responses, and Indications as well as providing identifiable flows using=0A= a 5-tuple. In this specification UDP and TCP is defined as well as their=0A= combination with a security layer using DTLS and TLS respectively.=0A= =0A= =0A= >=0A= >> G. Section 4.1:=0A= >>=0A= >> The "turn" and "turns" URI schemes are used to designate a TURN=0A= >> server (also known as a relay) on Internet hosts accessible using the= =0A= >> TURN protocol. The TURN protocol supports sending messages over UDP,= =0A= >> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be= =0A= >> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and the= =0A= >> "turn" scheme MUST be used otherwise. The required part of=0A= >> the "turn" URI denotes the TURN server host. The part, if=0A= >> present, denotes the port on which the TURN server is awaiting=0A= >> connection requests. If it is absent, the default port is 3478 for= =0A= >> both UDP and TCP. The default port for TURN over TLS and TURN over= =0A= >> DTLS is 5349.=0A= >>=0A= >> First, I was wondering if this document needed to update RFC 7065? The h= igh=0A= >> level obvious is the reference, but otherwise on the surface it doesn't = look=0A= >> necessary. My main complaint when reading was that it was not obvious wh= at=0A= >> not specifying the transport parameter means. Then I saw this in Section= 3.1 of=0A= >> RFC 7065:=0A= >>=0A= >> The , , and components are passed without=0A= >> modification to the [RFC5928] algorithm. is set to false if= =0A= >> is equal to "turn", and set to true if is equal to= =0A= >> "turns" and passed to the [RFC5928] algorithm with the other=0A= >> components.=0A= >>=0A= >> After some digging I figured out that RFC5928 is actually updated by RFC= =0A= >> 7350 that defines the resolution and SRV records for DTLS.=0A= >>=0A= >> Can you please update the text in Section 4 to also reference RFC 7350 s= o that=0A= >> one doesn't miss this definitions.=0A= > Sure, added the following line to Section 4:=0A= > DTLS as a transport protocol for TURN is defined in RFC7350.=0A= Ok.=0A= >=0A= >> H. Section 5:=0A= >>=0A= >> If the server requires requests to be=0A= >> authenticated, then the server's administrator MUST choose a realm=0A= >> value that will uniquely identify the username and password=0A= >> combination that the client must use, even if the client uses=0A= >> multiple servers under different administrations.=0A= >>=0A= >> Just to verify, TURN does not allow a single server address to host mult= iple=0A= >> realms do it? Each Realm needs its own unique server transport address?= =0A= > No, I don't see any such restriction in TURN. For example, in an Enterpr= ise network with multiple realms, the TURN server based on the client subne= t can choose the realm.=0A= =0A= I think this is a not expressed assumption, that realm determination may=0A= be done based on source IP address of the client's request. That is an=0A= assumption that is not generally applicable, but can work for some=0A= combinations of realms. For example an server that has a REALM for an=0A= WebRTC service that is intended to have no restrictions can't be=0A= co-located with anything that has a small scope as that can lead to=0A= selection of the wrong realm.=0A= =0A= What do you think is the best option here. Simple document that there=0A= are no mechanism in the protocol for the client to indicate which REALM=0A= it thinks it belongs to and state that the basic mechanism is using=0A= different server ports for different realms. Or to write even more where=0A= the possibility in source IP address identification of realm is=0A= described but also its limitations?=0A= =0A= =0A= >=0A= >> I. Section 5:=0A= >>=0A= >> For each Allocate request, the server SHOULD generate a=0A= >> new random nonce when the allocation is first attempted following the= =0A= >> randomness recommendations in [RFC4086] and SHOULD expire the nonce= =0A= >> at least once every hour during the lifetime of the allocation.=0A= >>=0A= >> So, I think this text due to its use of RFC 2119 language is a bit confu= sing in its=0A= >> relation to STUNbis. To me it is unclear if the above overrides complete= ly what=0A= >> is written in Section 5 of STUNbis:=0A= >>=0A= >> To indicate that it supports this specification, a server MUST=0A= >> prepend the NONCE attribute value with the character string composed= =0A= >> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]= =0A= >> encoding of the 24 bit STUN Security Features as defined in=0A= >> Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes,= =0A= >> with bit 0 as the most significant bit of the first byte and bit 23= =0A= >> as the least significant bit of the third byte. If no security=0A= >> features are used, then a byte array with all 24 bits set to zero=0A= >> MUST be encoded instead. For the remainder of this document the term= =0A= >> "nonce cookie" will refer to the complete 13 character string=0A= >> prepended to the NONCE attribute value.=0A= >>=0A= >> Or is the randomness recommendations in TURNbis only for the NONCE=0A= >> attribute value part?=0A= > Yes, the randomness recommendations in TURNbis is only for the NONCE attr= ibute value part. =0A= >=0A= >> Secondly, I interpret the text to say that compared to STUN, where a Non= ce can=0A= >> be long lived after the initial Long Term Credential establishment, in T= URN for=0A= >> each allocation one will have to to the Allocate, expired nonce->here is= your=0A= >> new nonce, resend allocate using new nonce, success dance.=0A= >>=0A= >> I think part of the problem with the above text in TURNbis is that the s= entences=0A= >> prior to the quoted one appear to be rehashing of the STUNbis requiremen= ts.=0A= >> Then the quoted part that actually changes behavior without being clear = about=0A= >> it. I think it would be good to make it clear what is a change compared = to=0A= >> STUNbis.=0A= > No changes other than the randomness for the NONCE attribute value part. = Added the following line for clarity:=0A= >=0A= > To indicate that the server supports [I-D.ietf-tram-stunbis], the server= =0A= > prepends the NONCE attribute value with the "nonce cookie"=0A= > (Section 9.2 of [I-D.ietf-tram-stunbis]).=0A= >=0A= > Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section= -18, discusses using the nonce cookie with the STUN security feature for th= e NONCE attribute =0A= > sent in the Allocate response.=0A= =0A= Ok, that clarifies the randomness part.=0A= =0A= =0A= >=0A= >> J. Section 6:=0A= >>=0A= >> Note that, rather than storing the password explicitly, for=0A= >> security reasons, it may be desirable for the server to store the key= =0A= >> value, which is a secure hash over the username, realm, and password= =0A= >> (see [I-D.ietf-tram-stunbis]).=0A= >>=0A= >> Why isn't this recommendation stronger. Are there any reasons why a serv= er=0A= >> would actually store the plain text password at all?=0A= > Good point, no reason to store the plain text password. Updated text as f= ollows:=0A= >=0A= > For security reasons, the server MUST NOT store the=0A= > password explicitly and MUST store the key value, which is a secure=0A= > hash over the username, realm, and password (see Section 16.1.3 in=0A= > [I-D.ietf-tram-stunbis]).=0A= =0A= =0A= Looks okay to me.=0A= =0A= >=0A= >> K. Section 7.1:=0A= >>=0A= >> The client first picks a host transport address. It is RECOMMENDED= =0A= >> that the client pick a currently unused transport address, typically= =0A= >> by allowing the underlying OS to pick a currently unused port for a= =0A= >> new socket.=0A= >>=0A= >> I think talk about socket in this context should be skipped as it otherw= ise have=0A= >> been eliminated.=0A= > The above text is from https://tools.ietf.org/html/rfc5766#section-6.1. I= presume you are proposing the following update:=0A= > =0A= > The client first picks a host transport address. It is RECOMMENDED= =0A= > that the client pick a currently unused transport address, typically= =0A= > by allowing the underlying OS to pick a currently unused port.=0A= =0A= Yes, I see no loss of real information.=0A= =0A= =0A= >=0A= >> L. Section 7.1:=0A= >>=0A= >> The client then picks a transport protocol to use between the client= =0A= >> and the server. The transport protocol MUST be one of UDP, TCP, TLS-= =0A= >> over-TCP or DTLS-over-UDP.=0A= >>=0A= >> I find it strange that this indicates that one should pick the transport= protocol to=0A= >> use client to server without considering the server capabilities. Especi= ally as the=0A= >> client configuration or server discovery procedures will indicate transp= ort=0A= >> protocol support.=0A= > The server may support more than one transport protocol. =0A= =0A= Sorry, should have been clearer. Should there be any references to how=0A= the client can determine the servers capabilities? You have=0A= recommendations about using UDP and a pointer to Section 2.1 for some=0A= discussion of the choices. So that covers giving some guidance to the=0A= protocol choice.=0A= =0A= Also shouldn't this paragraph come before the previous one. I.e. that=0A= you first must pick your transport protocol before you can pick a host=0A= transport address?=0A= =0A= =0A= >=0A= >> Secondly, what is the motivation for the MUST in the second sentence?=0A= >> This is appears to have strange interactions with any future extensions = and=0A= >> have no impact. A client must obvious chose a client to server transport= =0A= >> protocol it supports, and one that the server supports or the client hop= e it will=0A= >> support.=0A= > https://tools.ietf.org/html/rfc5766#section-6.1 has the same text, I have= updated the text as follows:=0A= > The client then picks a transport protocol to use between the client and = the server based on the transport protocols supported by the server. =0A= > The TURN server MUST enable one of the transport protocols, UDP, TCP, TLS= - over-TCP or DTLS-over-UDP.=0A= =0A= If the intention is to move the requirement to the server side for=0A= making it normative to support at least one of the 4 options listed, I=0A= think you need to rewrite it to say:=0A= =0A= A TURN server MUST enable at least one of the transport protocols, UDP, TCP= , TLS- over-TCP or DTLS-over-UDP.=0A= =0A= =0A= =0A= >=0A= >> M. Section 7.1:=0A= >>=0A= >> The client also picks a server transport address, which SHOULD be=0A= >> done as follows. The client uses one or more procedures described in= =0A= >> [RFC8155] to discover a TURN server and uses the TURN server=0A= >> resolution mechanism defined in [RFC5928] to get a list of server=0A= >> transport addresses that can be tried to create a TURN allocation.=0A= >>=0A= >> 1) So RFC 8155 states that it has no recommendation on server selection,= nor=0A= >> on how to related local configuration to any auto-discovery servers.=0A= >> To me it appears that the protocol utilizing TURN should consider what m= akes=0A= >> sense in their deployments. Thus, does the need for such consideration n= eeds to=0A= >> be highlighted somewhere in this specification.=0A= > https://tools.ietf.org/html/rfc8155#section-3 discusses using auto-discov= ery in the absence of local configuration or if the local configuration doe= s not work. https://tools.ietf.org/html/rfc8155#section-9 explains the mech= anisms to authenticate the discovered TURN server. =0A= >=0A= > I am not sure about the additional considerations you are looking in this= specification.=0A= =0A= Let me attempt to formulate the question in another way. As the=0A= Discovery procedure documented in RFC 8155 does not mandate any specific=0A= order or even what mechanisms are actually used / supported, then did=0A= the WG consider to make either a stricter recommendation or some other=0A= considerations to better ensure that TURN clients can discover TURN=0A= servers?=0A= =0A= It is fine to say no.=0A= =0A= =0A= >=0A= >> N. Section 7.1:=0A= >>=0A= >> Clients MUST NOT include a REQUESTED-ADDRESS-=0A= >> FAMILY attribute in an Allocate request that contains a RESERVATION-= =0A= >> TOKEN attribute, for the reasons outlined in [RFC6156].=0A= >>=0A= >> Considering that this document obsoletes RFC 6156, I think it is bad for= m to=0A= >> reference that document, rather than to move the necessary motivation in= to=0A= >> this document.=0A= > Done, updated text as follows:=0A= > Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an Alloc= ate request that contains a RESERVATION-TOKEN attribute, for the reason tha= t server uses the previously reserved transport address corresponding to th= e included token and the client cannot obtain a relayed transport address o= f a specific address type.=0A= =0A= Works for me.=0A= =0A= >=0A= >> O. Section 7.1:=0A= >>=0A= >> If the client wishes to obtain a relayed transport address of a=0A= >> specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A= >> attribute in the request.=0A= >>=0A= >> I don't find anything describing what the default behavior is if one doe= sn't=0A= >> include the attribute, but the TURN server supports multiple address fam= ilies.=0A= >>=0A= >> I see that bullet 7 in Section 7.2 indicates that IPv4 is default.=0A= >> Should the text in 7.1 be explicit about this default?=0A= > The text in Section 7.1 is added for TURN clients not supporting TURNbis = specification to provide backward compatibility. =0A= =0A= But if I understand this correctly, the legacy way is to not include the=0A= REQUESTED-ADDRESS-FAMILY attribute for an IPv4 address. Thus, shouldn't=0A= a sentence be added after the above to state that if the client wants an=0A= IPv4 address it should skip using REQUESTED-ADDRESS-FAMILY attribute to=0A= enable legacy interoperability, or do I missunderstand?=0A= =0A= =0A= >=0A= >> P. Section 7.2:=0A= >>=0A= >> Otherwise, if the attribute is included but=0A= >> specifies a protocol other that UDP, the server rejects the=0A= >> request with a 442 (Unsupported Transport Protocol) error.=0A= >>=0A= >> Assuming that you don't support an extension for that transport protocol= .=0A= >> Should that be made explicit?=0A= > I did not get the above comment. The attribute REQUESTED-TRANSPORT is ori= ginally defined in TURN (see https://tools.ietf.org/html/rfc5766#section-6.= 2), and TURNbis does not update the use of the attribute.=0A= =0A= I am requesting a clarification in the text like this:=0A= =0A= =0A= =0A= Otherwise, if the attribute is included but=0A= specifies a protocol other that UDP that is not supported by the se= rver, then the server rejects the=0A= request with a 442 (Unsupported Transport Protocol) error.=0A= =0A= What I mean with extension above is the case when the TURN server supports = an TURN extension that define for example TCP as server to peer protocol. = =0A= =0A= =0A= =0A= >=0A= >=0A= >> Q. Section 8.3:=0A= >>=0A= >> If the client receives a success response to its Refresh request with= =0A= >> a non-zero lifetime, it updates its copy of the allocation data=0A= >> structure with the time-to-expiry value contained in the response.=0A= >>=0A= >> If the client receives a 437 (Allocation Mismatch) error response to= =0A= >> a request to delete the allocation, then the allocation no longer=0A= >> exists and it should consider its request as having effectively=0A= >> succeeded.=0A= >>=0A= >> So there are no considerations for the client if it receives an error re= sponse to a=0A= >> refresh request when Lifetime was non-zero?=0A= >>=0A= >> I am bit surprised by that. I assume that there are certain cases when t= he=0A= >> request could be resent, and others where the meaning is that the alloca= tion is=0A= >> gone.=0A= > TURNbis does not update the refresh behavior already defined in https://t= ools.ietf.org/html/rfc5766#section-7.3. I will add the following line:=0A= > If the client receives an error response to its request to refresh the al= location, it should consider the allocation no longer exists.=0A= =0A= Isn't that over simplifying cases where one attempts to refresh an=0A= allocation and could actually handle the issue. For example an error=0A= response to the client of 438 (Stale Nonce) where the client can retry=0A= the request with the new Nonce. I also wonder if request time out as=0A= well as 400 (if it can figure out what the issue was) could be=0A= re-attempted prior to allocation expires. But at leat hte 438 appears to=0A= indicate a situation where the client should not give up, and thus=0A= should have some text here.=0A= =0A= >=0A= >> R. Section 11.5:=0A= >>=0A= >> When the server receives an ICMP packet, the server verifies that the= =0A= >> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either= =0A= >> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the= =0A= >> IP packet in the ICMP packet payload contains a UDP header. If=0A= >> either of these conditions fail, then the ICMP packet is silently=0A= >> dropped.=0A= >>=0A= >> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A= >> Problem are for ICMPv4?=0A= > I don't get the above comment, please explain the question with an exampl= e. =0A= =0A= So if a server receives an ICMP for sent packet with ICMPv4 type 12 =0A= (Parameter Problem) then that is relayed to the client according to this=0A= text. But if the server sent a packet with IPv6 towards the peer and=0A= receives an ICMPv6 message with Type 4 (Parameter Problem) that is not=0A= relayed to the client. Why this discrepancy?=0A= =0A= >=0A= >> S. Section 12.5:=0A= >>=0A= >> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded to= =0A= >> a multiple of four bytes in order to ensure the alignment of=0A= >> subsequent messages. The padding is not reflected in the length=0A= >> field of the ChannelData message, so the actual size of a ChannelData= =0A= >> message (including padding) is (4 + Length) rounded up to the nearest= =0A= >> multiple of 4. Over UDP, the padding is not required but MAY be=0A= >> included.=0A= >>=0A= >> Are there anywhere written what one may or may not include of the TURN= =0A= >> related messages in a single UDP datagram. Because it is technically fea= sible I=0A= >> belive to include two Send Indications in one UDP datagram to the server= .=0A= > As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-11.= 2, one send indication in one UDP datagram to the server.=0A= =0A= Okay, the procedure described indicates that only a single Indication=0A= per UDP datagram . I think that is good enough.=0A= =0A= =0A= >=0A= >> T. Section 13.1:=0A= >>=0A= >> Flow Label=0A= >>=0A= >> Preferred behavior: The relay sets the Flow label to 0. The relay= =0A= >> can choose to set the Flow label to a different value if it=0A= >> supports the IPv6 Flow Label field [RFC6437].=0A= >>=0A= >> Alternate behavior: The relay sets the Flow label to the default= =0A= >> value for outgoing packets.=0A= >>=0A= >> I think this section should be improved in two ways.=0A= >>=0A= >> First of all I think it should clarify that each allocation to peer flow= is its own=0A= >> IPv6 Flow in perspective of the IPv6 Flow label.=0A= >>=0A= >> Secondly, I think in the spirit of RFC 6473 the preferred behavior shoul= d be to=0A= >> set the IPv6 flow label if the implementation is capable, or leave it to= the=0A= >> underlying network stack to actually set it. Compared to RFC 7915, the T= URN=0A= >> server actually have an understanding of what are different flows withou= t=0A= >> having examining additional protocol layers.=0A= > Updated text as follows:=0A= >=0A= > Preferred behavior:=0A= > The TURN server can use the relayed transport address, peer transport add= ress and UDP protocol number =0A= > to generate and set the flow label value in the IPv6 packet as discussed = in Section 3 of [RFC6437]. If the TURN server is incapable of =0A= > generating the flow label value from the IPv6 packet's 5-tuple, it sets t= he Flow label to 0. =0A= >=0A= > (Please note the proposed update deviates from the behavior defined https= ://tools.ietf.org/html/rfc6156#section-8.1) =0A= =0A= Good, but I would suggest some tweaks to clarify:=0A= =0A= Preferred behavior:=0A= The TURN server can use the 5-tuple of relayed transport address, peer tran= sport address and UDP protocol number to identify each flow, generate and s= et the flow label value in the IPv6 packet as discussed in Section 3 of [RF= C6437]. If the TURN server is incapable of generating the flow label value = from the IPv6 packet's 5-tuple, it sets the Flow label to 0. =0A= =0A= (Please note the proposed update deviates from the behavior defined https:/= /tools.ietf.org/html/rfc6156#section-8.1) =0A= =0A= =0A= =0A= > =0A= >=0A= >=0A= >> Thirdly, I don't understand what the alternative behavior actually is.= =0A= >> This as it is either setting it to 0, or classifying things as flow and = then provide it=0A= >> with a random flow label. I think the right alternative behavior is to s= et it 0.=0A= > Updated text to say:=0A= >=0A= > Alternate behavior: The relay sets the Flow label to the default= =0A= > value of zero for outgoing packets.=0A= =0A= Ok=0A= =0A= >=0A= >> U. Section 13. 1,2,3:=0A= >>=0A= >> For both preferred and alternate behavior, the DONT-FRAGMENT=0A= >> attribute MUST be ignored by the server.=0A= >>=0A= >> I don't understand why just because one performs v4<->v6 or v6 to v4=0A= >> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A= >> attribute. If the client has request to not fragment and the server is u= nable to=0A= >> do that when forwarding to the peer it needs to generate an ICMP attribu= te=0A= >> response saying the packet is to big. Otherwise the relay breaks the Pat= h MTU=0A= >> discovery mechanisms.=0A= > TURNbis is using the translation algorithms specified in RFC7915. =0A= >=0A= > [a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header t= o not fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#sec= tion-4), DON'T-FRAGMENT attribute can be ignored. =0A= > [b] For IPv6 to IPv4: The translation algorithm in https://tools.ietf.org= /html/rfc7915#section-5 is used. If the IPv6 endpoint wants to discover th= e path MTU, it will send IPv6 packets without Fragment header and DON'T-FRA= GMENT attribute can be ignored.=0A= > [c] For IPv6 to IPv6: If the IPv6 endpoint wants to discover the path MTU= , it will send IPv6 packets without Fragment header and DON'T-FRAGMENT attr= ibute can be ignored.=0A= >=0A= > Please note ignoring the DONT-FRAGMENT attribute is picked from https://t= ools.ietf.org/html/rfc6156#section-8 and discussed in the BEHAVE WG https:/= /mailarchive.ietf.org/arch/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc. =0A= =0A= Thanks for the clarification on the context. I should have read Section=0A= 4 of 7915. Then I would have likely gotten the implication that the IP=0A= header DF or Fragmentation header impacts how things are working.=0A= =0A= However, I find the reasoning behind this choice very strange. I don't=0A= see how you can implement a TURN server that does IPv4 <->IPv6, or IPv6=0A= relaying without having privileged access and where it reads the raw=0A= headers. An implementation based on UDP sockets will not be able to do=0A= the right thing here to my understanding. However, it could follow the=0A= DONT-FRAGMENT attribute to instructing the sending using the Socket to=0A= do the right thing. =0A= =0A= I think there are two directions we can proceed in here.=0A= =0A= 1. Redefine this text to enable usage of DONT-FRAGMENT=0A= =0A= or=0A= =0A= 2. Clarify the scope and implications of Unpriviliged TURN Server doing=0A= translation=0A= =0A= =0A= For the second option I think there are several aspects that I like to=0A= see addressed:=0A= =0A= 2a: Update the sentence I quoted for this issue to make it clear that=0A= you are relying soley on IPv4 DF and IPv6 Fragmentation Header to=0A= control the fragmentation.=0A= =0A= 2b: Clarify that Unpriviliged TURN Severs that do IPv4<-> IPv6=0A= translation will not handle fragmentation well. And include a point to=0A= the last paragraph of Section 2.7 and the use of DONT-FRAGMENT In=0A= Allocate requests to determine support and that these needs to be=0A= rejected by such a server.=0A= =0A= By the way, there must be a typo with a "not" that shouldn't be in this=0A= paragraph in Section 4 of 7915:=0A= =0A= When the IPv4 sender does not set the DF bit, the translator MUST NOT=0A= include the Fragment Header for the non-fragmented IPv6 packets.=0A= =0A= To me it make sense for a IPv4->IPv6 translation where the IPv4 has=0A= DF=3DTRUE to not include the fragmentation header, do you agree?=0A= =0A= IF you agree I can file an errata on this.=0A= =0A= >> V. Section 13.2:=0A= >>=0A= >> Fragmentation:=0A= >>=0A= >> If the incoming packet included a Fragment header and the outgoing= =0A= >> packet size exceeds the outgoing link's MTU, the relay MUST=0A= >> fragment the outgoing packet into fragments of no more than 1280= =0A= >> bytes. The relay sets the fields of the Fragment header as=0A= >> appropriate for a packet originating from the server.=0A= >>=0A= >> Is really the intention here to refragment the packet without providing = any=0A= >> indication that the practical MTU is smaller than what the peer or clien= t thinks=0A= >> it is?=0A= > Yes, TURNbis is following the existing behavior already defined in https:= //tools.ietf.org/html/rfc6156#section-8.1. =0A= Okay.=0A= >=0A= >> W. Section 14:=0A= >>=0A= >> Preferred Behavior: Set the outgoing value to the incoming value,= =0A= >> UNLESS the server is doing Active Queue Management, the incoming= =0A= >> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the server= =0A= >> wishes to indicate that congestion has been experienced, in which= =0A= >> case set the outgoing value to CE (=3D0b11).=0A= >>=0A= >> First of all do you have any special meaning with all capital UNLESS?=0A= >>=0A= >> Secondly, I don't know how wise it is to have partial definitions of wha= t the ECN=0A= >> behavior is. Maybe simpler to say that that the relay is performing AQM = it can=0A= >> support the ECN marking behavior as defined in RFC 3168.=0A= > The above text is same as https://tools.ietf.org/html/rfc5766#section-12,= replaced "UNLESS" with "unless".=0A= =0A= So the UNLESS Is only for emphasis?=0A= =0A= I think the sentence could be formulated so that it is easier to=0A= understand that the text after "... active queue managmenet, ..." is in=0A= case on does AQM. Also I think it is worth clarifying that the TURN=0A= server can operate as defined by RFC 3168. In addition the use of ECT(1)=0A= experiments has been changed so that also needs a reference. So perhaps:=0A= =0A= Preferred Behavior: Set the outgoing value to the incoming value. The= server may perform Active Queue Management, in which case it SHOULD behave= as a ECN aware router [RFC3168] and can mark traffic with Congestion Exper= ienced (CE) instead of dropping the packet. The use of ECT(1) is subject to= experimental usage [RFC8311].=0A= =0A= =0A= =0A= >=0A= >> X. Section 14:=0A= >>=0A= >> How are these IP level fields handled when the transport is TCP or TLS/T= CP?=0A= >> There there are not necessary a one to one mapping between datagrams and= =0A= >> TCP packets. And if there are no support then there are need for clarifi= cation of=0A= >> behaviors when using TCP based transport.=0A= > Section 14 already clarifies that the descriptions in this section do not= apply to TURN messages sent over TCP or TLS transport from the server to t= he client.=0A= =0A= Yes you are right. What are the recommendations for how to set the=0A= fields when the Channel message or Send Indication arrives over=0A= TCP/(TLS) to the server? To me the basis is the alternative behavior=0A= with the exception for the DF bit. However, behaviors for datagrams=0A= orignated by the server and delivered to the server over non datagram=0A= transport will need to have recommendations also for IPv6.=0A= =0A= >=0A= >> Y. Section 16.4. DATA=0A= >>=0A= >> The DATA attribute is present in all Send and Data indications. The= =0A= >> value portion of this attribute is variable length and consists of=0A= >> the application data (that is, the data that would immediately follow= =0A= >> the UDP header if the data was been sent directly between the client= =0A= >> and the peer). If the length of this attribute is not a multiple of= =0A= >> 4, then padding must be added after this attribute.=0A= >>=0A= >> Can you please clarify if one would get all the remaining bytes of the I= P packet=0A= >> payload or only the number of bytes the UDP length field indicates ?=0A= >>=0A= >> The reason I ask is that there is possibility that there are a discrepan= cy between=0A= >> these fields, something the proposal for an experimental specification f= or UDP=0A= >> options attempt to utilize.=0A= >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/=0A= >>=0A= >> Note, I only want you to clarify what is actually included. I would assu= me using=0A= >> the UDP length field makes sense in this case.=0A= > The application data does not include the options discussed in draft-ietf= -tsvwg-udp-options. =0A= > Please clarify the specific update you are looking in this section. =0A= =0A= My intention here was not to bring in UDP options, only to ensure that=0A= the specification text is clear. As UDP options draft points out there=0A= could be a discrepancy between the UDP length and IP length. Thus, I=0A= think there is a point to make it clear that the data includes UDP=0A= length -8 bytes of UDP payload. Possible include a informative reference=0A= for why there might be a discrepancy.=0A= =0A= AC. Section 16.12:=0A= >> Reason Phrase (variable). This field is under defined. First of all the = format of=0A= >> the text string is not defined, which it is in Stunbis Error-Code attrib= ute is=0A= >> defined as.=0A= >>=0A= >> The reason phrase MUST be a UTF-8 [RFC3629] encoded=0A= >> sequence of less than 128 characters (which can be as long as 509=0A= >> bytes when encoding them or 763 bytes when decoding them).=0A= > Thanks, updated section to use UTF-8 encoding. =0A= >=0A= >> Secondly, I think it might be worth pointing out the padding here. It is= not clear=0A= >> if there is any form of string termination and how the padding which wil= l be=0A= >> interpreted as NULL characters 0-3 depending on the alignment. I note th= is=0A= >> later issue appears to be existing in STUNBis also.=0A= > Padding is discussed in STUN for variable length attributes, please see h= ttps://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14. =0A= =0A= Thanks, missed that. I think that is clear.=0A= =0A= =0A= >=0A= >> AD. Section 16.2:=0A= >>=0A= >> Why isn't the text here say that this attribute may also be used to indi= cate the=0A= >> desired lifetime in allocation requests?=0A= > https://tools.ietf.org/html/rfc5766#section-14.2 did not discuss desired = lifetime. Anyways, added the following line:=0A= > The TURN client can include the LIFETIME attribute with the desired lifet= ime in Allocate and Refresh requests.=0A= =0A= Good.=0A= =0A= >=0A= >> AE. Section 16.9: DONT-FRAGMENT=0A= >>=0A= >> I think it would be good to indicate the use of the attribute in Allocat= e Requests=0A= >> also.=0A= > The above point is discussed in Section 7.1:=0A= >=0A= > =0A= > If the client wishes to later use the DONT-FRAGMENT attribute in one= =0A= > or more Send indications on this allocation, then the client SHOULD=0A= > include the DONT-FRAGMENT attribute in the Allocate request. This=0A= > allows the client to test whether this attribute is supported by the= =0A= > server.=0A= > =0A= =0A= Yes, but I think it is inconsistent when the text says:=0A= =0A= This attribute is used by the client to request that the server set=0A= the DF (Don't Fragment) bit in the IP header when relaying the=0A= application data onward to the peer.=0A= =0A= And there the is additional usage of it. When a minor change would=0A= indicate that alternative use also.=0A= =0A= This attribute is used by the client to request that the server set=0A= the DF (Don't Fragment) bit in the IP header when relaying the=0A= application data onward to the peer, and for determining the=0A= capability in Allocate requests.=0A= =0A= =0A= >=0A= >> AF. Section 24.2=0A= >>=0A= >> [Protocol-Numbers]=0A= >> "IANA Protocol Numbers Registry", 2005,=0A= >> .=0A= >>=0A= >> This is a normative reference based on how it is used in Section 16.8.= =0A= > Okay, moved as Normative reference.=0A= Good.=0A= >> AG. Seciton 18.=0A= >>=0A= >> Sometime before the 20 minute lifetime is up, the client refreshes=0A= >> the allocation. This is done using a Refresh request. As before,=0A= >> the client includes the latest username, realm, and nonce values in= =0A= >> the request. The client also includes the SOFTWARE attribute,=0A= >> following the recommended practice of always including this attribute= =0A= >> in Allocate and Refresh messages. When the server receives the=0A= >> Refresh request, it notices that the nonce value has expired, and so= =0A= >> replies with 438 (Stale Nonce) error given a new nonce value. The=0A= >> client then reattempts the request, this time with the new nonce=0A= >> value. This second attempt is accepted, and the server replies with= =0A= >> a success response. Note that the client did not include a LIFETIME= =0A= >> attribute in the request, so the server refreshes the allocation for= =0A= >> the default lifetime of 10 minutes (as can be seen by the LIFETIME=0A= >> attribute in the success response).=0A= >>=0A= >> I notice that this part nor the text before appears to discuss the permi= ssion=0A= >> lifetime that will expire after 5 minutes. Thus, it needs to be refreshe= d prior to=0A= >> the Allocation.=0A= > I have added text to discuss refreshing the channel binding, https://tool= s.ietf.org/html/rfc5766#section-16 did not discuss refreshing the permissio= ns and channel bindings. =0A= Ok.=0A= >=0A= >> AH. Section 18.=0A= >>=0A= >> I am missing any example having to do with Address Family interactions.= =0A= > There was no ask from the WG members to add an example and even https://t= ools.ietf.org/html/rfc6156 did not have an translation example.=0A= Ok, let skip this for now. But, it will be commented on again most=0A= likely by other reviewers.=0A= >=0A= >> AI. DTLS Cipher Suits=0A= >>=0A= >> Am I understanding it correct that the definition of what DTLS cipher su= it that a=0A= >> TURN Server currently is to support is the ones in RFC 7525 ?=0A= > No, the cipher suites and (D)TLS profile is discussed in https://tools.ie= tf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3 and it follows the rec= ommendations in RFC7525. =0A= =0A= Ahaa, of course. But, maybe an explicit reference to STUNbis in section=0A= 2.1 that the transports for TURN and STUN messages are defined there?=0A= =0A= >=0A= >> In that case, I think the wording is a bit weak as the only reference I = find are in=0A= >> Section 2.1:=0A= >>=0A= >> If (D)TLS transport is=0A= >> used between the TURN client and the TURN server, the guidance given= =0A= >> in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A= > RFC7525 provides various recommendations to avoid attacks on (D)TLS.=0A= =0A= It was really the text in STUNbis that I was looking for.=0A= =0A= =0A= Cheers=0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Thu Apr 18 01:19:49 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95E1120130; Thu, 18 Apr 2019 01:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e-Ja5E7oCv7; Thu, 18 Apr 2019 01:19:43 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89FE120041; Thu, 18 Apr 2019 01:19:42 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1555575250; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=RJGM2FbudhcKvpSMtoqu+X2q1YRlX5Wm0/wePK PLLFI=; b=PHoixIMWus5iCL4vgsrsni/MZx4CMgnJmsFGtTEi +AbLIAfhaAO6ALpu44VBxG4zlzd+EHJ26b1fdvGSvOzcrw9N3N cP4x5ZW63W8dY4KOUV0yNpD4v8Eb89/V62A/9Ms/xhb0AcKVUP cLEi3jzT8YkW52we4cn/AFhkGlc9Pto= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1537_d12a_71fdbcf3_d869_4dd5_811a_9542cf247e5d; Thu, 18 Apr 2019 02:14:09 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Apr 2019 02:18:48 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 18 Apr 2019 02:18:48 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 18 Apr 2019 02:18:46 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2549.namprd16.prod.outlook.com (20.177.225.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Thu, 18 Apr 2019 08:18:45 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1813.011; Thu, 18 Apr 2019 08:18:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiP6Y/2G2Q Date: Thu, 18 Apr 2019 08:18:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.205.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c74508b-e02f-4723-29a8-08d6c3d679eb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2549; x-ms-traffictypediagnostic: BYAPR16MB2549: x-ms-exchange-purlcount: 32 x-microsoft-antispam-prvs: x-forefront-prvs: 0011612A55 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(136003)(39860400002)(376002)(13464003)(199004)(189003)(32952001)(15594002)(51444003)(51914003)(9686003)(486006)(6436002)(53946003)(316002)(7696005)(74316002)(256004)(30864003)(110136005)(76176011)(14444005)(53936002)(55016002)(68736007)(25786009)(66574012)(2501003)(18074004)(229853002)(6246003)(66066001)(52536014)(5660300002)(97736004)(71190400001)(6306002)(99286004)(6506007)(305945005)(26005)(72206003)(11346002)(86362001)(8936002)(33656002)(53546011)(446003)(2201001)(71200400001)(5024004)(966005)(2906002)(478600001)(81166006)(81156014)(8676002)(14454004)(476003)(102836004)(6116002)(7736002)(186003)(561944003)(80792005)(3846002)(151285002)(85282002)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2549; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: v2YSoju6xr5nDSpd8g0HbuE/bLAsQg4AqRzH6kyPHR06KbVBZU0WLmAG4ssrZphz0CpyxtVEbaHEYDovO0Efc3kSpklbLXNT7+F4f1IwE4r7CyR2Y9Rf6n2xautmFIGXDPIr7OXoSsHq8JbSbcL7KDTCggkkZqJ50QVcgZsuOLF2eeoKYuY6hJ7O8mfPEVcPgZyBK3bX6D1TdqS772tJFRJP5ITsFALnvxdHNRUeYvudF3R+j19sDwZ0yJ1rjWmxwtaVy3y/zhJRb8fheV5QVGU2kx9bMTb14Bl7mjw0q5WIEnBINb2hYmer97YAYmRwXXKXPmknuEFiSHJzQO0N2oN31juevmzDcOPRBktTS2/0IAIH1yLJMTDeXTKfzeZOC/StVFcTgRcGkUSxR8IGP8EZf7CPaXW+B4y9uOzAeGs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c74508b-e02f-4723-29a8-08d6c3d679eb X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 08:18:45.3895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2549 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6527> : inlines <7056> : streams <1818999> : uri <2834051> Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 18 Apr 2019 08:19:48 -0000 Hi Magnus, Please see inline > -----Original Message----- > From: tram On Behalf Of Magnus Westerlund > Sent: Tuesday, April 16, 2019 6:02 PM > To: Konda, Tirumaleswar Reddy ; > tram@ietf.org; draft-ietf-tram-turnbis@ietf.org > Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is = safe. >=20 > Hi, >=20 > Thanks for the reply. Sorry about the delay in responding. Comments below= . No worries. >=20 > On 2019-04-11 10:27, Konda, Tirumaleswar Reddy wrote: > > Hi Magnus, > > > > Thanks for the detailed review. Please see inline > > > >> -----Original Message----- > >> From: tram On Behalf Of Magnus Westerlund > >> Sent: Thursday, April 4, 2019 7:30 PM > >> To: tram@ietf.org; draft-ietf-tram-turnbis@ietf.org > >> Subject: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 > >> > >> > >> > >> Hi, > >> > >> I have now finished the AD review. There are a lot of details that I > >> think needs fixing or at least feedback on. I also think there are a > >> couple of more serious issues here. Especially regarding the handling > >> of MTU and fragmentation, as well as IP header fields in address > >> family translation and with non UDP transport. We need to conclude on > these before we go to IETF last call. > >> > >> My Review comments are: > >> > >> A. Section 1: "The client can arrange > >> for the server to relay packets to and from certain other hosts > >> (called peers) and can control aspects of how the relaying is done.= " > >> > >> I don't think this is an accurate description of what Turn does. One > >> may easily get the impression that the whole packet TURN receives are > >> relayed, rather than the transport protocol data part and some of the > >> header information are relayed between the client <-> peer, with a > >> knowledge of the peer transport address for the client. I think that s= hould be > clarified in the introduction. > > Sure, updated the text as follows: > > > > When a peer sends a packet to the relayed transport address, the > > server relays the transport protocol data from the packet to the > > client. The client knows the peer from which the transport protocol > > data was relayed by the server. When the server receives an ICMP >=20 > Should the last "When" be an "If"? Yes, fixed. >=20 > > error packet, the server also relays certain layer 3/4 header fields f= rom the > ICMP header to the client. When the client sends a packet to the server, = the > server relays the transport protocol data from the packet to the appropri= ate > peer using the relayed transport address as the source. >=20 > "appropriate" appears wrong. The peer is the one the client have configur= e for > the allocation. So I think a more direct language can be used. "appropriate peer" is used at several places in https://tools.ietf.org/html= /rfc5766.=20 >=20 > Othewise fine with me. >=20 >=20 > >> B. Section 2.7: > >> > >> "Applications using TCP can more or less > >> ignore this issue because fragmentation avoidance is now a standard > >> part of TCP, but applications using UDP (and thus any application > >> using this version of TURN) must handle fragmentation avoidance > >> themselves." > >> > >> Lower case "must", and as the document uses RFC 2119, this must have > >> the meaning of "MUST". A reformulation here is likely in order. > > Replaced "must" with "MUST". >=20 > I think it is inappropriate to make this into a MUST statement. There is = no > single answer for how the application handles it. The application needs t= o > handle it or live with the consequences. I think swithing the "must" to "= needs > to" is more appropriate. Okay, updated.=20 >=20 >=20 >=20 > >> C. Section 2.7: > >> > >> In this approach, the application exploits the > >> fact that the IP specification [RFC0791] specifies that IP packets = up > >> to 576 bytes should never need to be fragmented. > >> > >> As a guideline, sending a maximum of 500 bytes of application data = in > >> a single TURN message (by the client on the client-to-server leg) o= r > >> a UDP datagram (by the peer on the peer-to-server leg) will general= ly > >> avoid IP fragmentation. To further reduce the chance of > >> fragmentation, it is recommended that the client use ChannelData > >> messages when transferring significant volumes of data, since the > >> overhead of the ChannelData message is less than Send and Data > >> indications. > >> > >> In that first paragraph I think it is worth discussing the IPv6 > >> requirement of supporting a 1280 minimal size. > > Yes. > > > >> Secondly, I think recommending only a 500 MTU is way to conservative. > >> Those studies I have seen appears to indicate that at least 1220 > >> bytes UDP payloads should be be working as well as 500 bytes. See for > >> example figure 12 in this: > >> https://static.googleusercontent.com/media/research.google.com/sv//pu > >> bs/arc > >> hive/46403.pdf > > I have updated the text as follows to address your comments: > > > > In this approach, the application MUST assume a > > PMTU of 1280 bytes, as IPv6 requires that every link in the Internet > > have an MTU of 1280 octets or greater as specified in [RFC8200]. If > > IPv4 support on legacy or otherwise unusual networks is a > > consideration, the application MAY assume on a PMTU of 576 bytes for > > IPv4 datagrams, as every IPv4 host must be capable of receiving a > > packet whose length is equal to 576 bytes as discussed in [RFC0791]. >=20 > Yes, I think that is quite good. >=20 >=20 > >> D. Section 2.7: > >> > >> [I-D.ietf-tram-stun-pmtud] is an implementation of [RFC4821] that > >> uses STUN to discover the path MTU, and so might be a suitable > >> approach to be used in conjunction with a TURN server that supports > >> the DONT-FRAGMENT attribute. When the client includes the DONT- > >> FRAGMENT attribute in a Send indication, this tells the server to s= et > >> 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 shou= ld > >> also include this attribute in the Allocate request -- any server > >> that does not support the DONT-FRAGMENT attribute will indicate thi= s > >> by rejecting the Allocate request. > >> > >> I want to verify that the WG is working on resolving the issues with > >> the STUN PMTUD document. I definitely sees the point of the > >> recommendation, but only if the WG will conclude on that document in a > reasonable time frame. > > The authors of the ietf-tram-stun-pmtud draft are working on resolving = the > DISCUSS from ISEG review. >=20 >=20 > Great, looking forward to have that Discuss resolved. Me too :) >=20 > > > >> E. Section 3: > >> > >> Server-Reflexive Transport Address: A transport address on the > >> "public side" of a NAT. This address is allocated by the NAT to > >> correspond to a specific host transport address. > >> > >> Shouldn't "public side" be replace with "external side"? That is the > >> terminology used by the Behave RFCs. > > Okay, replaced "public side" with "external side". > > > >> F. Section 3: > >> > >> 5-tuple: The combination (client IP address and port, server IP > >> address and port, and transport protocol (currently one of UDP, > >> TCP, or (D)TLS)) used to communicate between the client and the > >> server. > >> > >> I see some issues that the 5-tuple aggregates the transport protocol > >> with the security protocol. I agree from the TURN protocol > >> perspective the protocol combination is the important one. However, > >> writing like you do here you obfuscate both that when security is in > >> place you have a combination, as well as that there are 4 alternatives > defined by this document. > > (D)TLS can be considered as pseudo transport protocol. >=20 > May I suggest that you simple reword it in this way: >=20 > 5-tuple: The combination (client IP address and port, server IP > address and port, and transport protocol (currently one of UDP, > TCP, DTLS/UDP or TLS/TCP)) used to communicate between the client a= nd > the > server. The 5-tuple uniquely identifies this communication > stream. The 5-tuple also uniquely identifies the Allocation on > the server. Looks good, updated. >=20 > In this specification you are using the words Transport Protocol in a way= that is > not the most common understanding of the word. Thus, I think you should > include a definition in section 3 of your usage of "Transport Protocol". >=20 > Transport Protocol: The protocols above IP that carries TURN Requests, > Responses, and Indications as well as providing identifiable flows using = a 5- > tuple. In this specification UDP and TCP is defined as well as their comb= ination > with a security layer using DTLS and TLS respectively. Thanks, added above definition. >=20 >=20 > > > >> G. Section 4.1: > >> > >> The "turn" and "turns" URI schemes are used to designate a TURN > >> server (also known as a relay) on Internet hosts accessible using t= he > >> TURN protocol. The TURN protocol supports sending messages over UD= P, > >> TCP, TLS-over-TCP or DTLS-over-UDP. The "turns" URI scheme MUST be > >> used when TURN is run over TLS-over-TCP or in DTLS-over-UDP, and th= e > >> "turn" scheme MUST be used otherwise. The required part of > >> the "turn" URI denotes the TURN server host. The part, if > >> present, denotes the port on which the TURN server is awaiting > >> connection requests. If it is absent, the default port is 3478 for > >> both UDP and TCP. The default port for TURN over TLS and TURN over > >> DTLS is 5349. > >> > >> First, I was wondering if this document needed to update RFC 7065? > >> The high level obvious is the reference, but otherwise on the surface > >> it doesn't look necessary. My main complaint when reading was that it > >> was not obvious what not specifying the transport parameter means. > >> Then I saw this in Section 3.1 of RFC 7065: > >> > >> The , , and components are passed without > >> modification to the [RFC5928] algorithm. is set to false = if > >> is equal to "turn", and set to true if is equal t= o > >> "turns" and passed to the [RFC5928] algorithm with the other > >> components. > >> > >> After some digging I figured out that RFC5928 is actually updated by > >> RFC > >> 7350 that defines the resolution and SRV records for DTLS. > >> > >> Can you please update the text in Section 4 to also reference RFC > >> 7350 so that one doesn't miss this definitions. > > Sure, added the following line to Section 4: > > DTLS as a transport protocol for TURN is defined in RFC7350. > Ok. > > > >> H. Section 5: > >> > >> If the server requires requests to be > >> authenticated, then the server's administrator MUST choose a realm > >> value that will uniquely identify the username and password > >> combination that the client must use, even if the client uses > >> multiple servers under different administrations. > >> > >> Just to verify, TURN does not allow a single server address to host > >> multiple realms do it? Each Realm needs its own unique server transpor= t > address? > > No, I don't see any such restriction in TURN. For example, in an Enter= prise > network with multiple realms, the TURN server based on the client subnet = can > choose the realm. >=20 > I think this is a not expressed assumption, that realm determination may = be > done based on source IP address of the client's request. That is an assum= ption > that is not generally applicable, but can work for some combinations of r= ealms. > For example an server that has a REALM for an WebRTC service that is > intended to have no restrictions can't be co-located with anything that h= as a > small scope as that can lead to selection of the wrong realm. Yes, both assumptions are deployment specific. Enterprise TURN servers are= discussed in https://tools.ietf.org/html/rfc7478.=20 Username and password is not the only way to perform mutual authentication = b/w the TURN client and server, https://tools.ietf.org/html/rfc7635 discuss= es using OAuth and is used by WebRTC (see https://w3c.github.io/webrtc-pc/)= .=20 >=20 > What do you think is the best option here. Simple document that there are= no > mechanism in the protocol for the client to indicate which REALM it think= s it > belongs to and state that the basic mechanism is using different server p= orts > for different realms. Or to write even more where the possibility in sour= ce IP > address identification of realm is described but also its limitations? If different server ports are used for different realms, the client needs t= o learn the server ports and manual configuration may not be a suitable opt= ion. The public TURN server could have different domain names for different= realms, and the client can discover the server port for the TURN server do= main using S-NAPTR. I don't think the draft should discuss deployment spec= ific solutions. >=20 >=20 > > > >> I. Section 5: > >> > >> For each Allocate request, the server SHOULD generate a > >> new random nonce when the allocation is first attempted following t= he > >> randomness recommendations in [RFC4086] and SHOULD expire the > nonce > >> at least once every hour during the lifetime of the allocation. > >> > >> So, I think this text due to its use of RFC 2119 language is a bit > >> confusing in its relation to STUNbis. To me it is unclear if the > >> above overrides completely what is written in Section 5 of STUNbis: > >> > >> To indicate that it supports this specification, a server MUST > >> prepend the NONCE attribute value with the character string compose= d > >> of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648] > >> encoding of the 24 bit STUN Security Features as defined in > >> Section 18.1. The 24 bit Security Feature set is encoded as 3 byte= s, > >> with bit 0 as the most significant bit of the first byte and bit 23 > >> as the least significant bit of the third byte. If no security > >> features are used, then a byte array with all 24 bits set to zero > >> MUST be encoded instead. For the remainder of this document the te= rm > >> "nonce cookie" will refer to the complete 13 character string > >> prepended to the NONCE attribute value. > >> > >> Or is the randomness recommendations in TURNbis only for the NONCE > >> attribute value part? > > Yes, the randomness recommendations in TURNbis is only for the NONCE > attribute value part. > > > >> Secondly, I interpret the text to say that compared to STUN, where a > >> Nonce can be long lived after the initial Long Term Credential > >> establishment, in TURN for each allocation one will have to to the > >> Allocate, expired nonce->here is your new nonce, resend allocate using= new > nonce, success dance. > >> > >> I think part of the problem with the above text in TURNbis is that > >> the sentences prior to the quoted one appear to be rehashing of the ST= UNbis > requirements. > >> Then the quoted part that actually changes behavior without being > >> clear about it. I think it would be good to make it clear what is a > >> change compared to STUNbis. > > No changes other than the randomness for the NONCE attribute value part= . > Added the following line for clarity: > > > > To indicate that the server supports [I-D.ietf-tram-stunbis], the > > server prepends the NONCE attribute value with the "nonce cookie" > > (Section 9.2 of [I-D.ietf-tram-stunbis]). > > > > Please see > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-18, disc= usses > using the nonce cookie with the STUN security feature for the NONCE attri= bute > sent in the Allocate response. >=20 > Ok, that clarifies the randomness part. >=20 >=20 > > > >> J. Section 6: > >> > >> Note that, rather than storing the password explicitly, for > >> security reasons, it may be desirable for the server to store the k= ey > >> value, which is a secure hash over the username, realm, and passwor= d > >> (see [I-D.ietf-tram-stunbis]). > >> > >> Why isn't this recommendation stronger. Are there any reasons why a > >> server would actually store the plain text password at all? > > Good point, no reason to store the plain text password. Updated text as > follows: > > > > For security reasons, the server MUST NOT store the password > > explicitly and MUST store the key value, which is a secure hash over > > the username, realm, and password (see Section 16.1.3 in > > [I-D.ietf-tram-stunbis]). >=20 >=20 > Looks okay to me. >=20 > > > >> K. Section 7.1: > >> > >> The client first picks a host transport address. It is RECOMMENDED > >> that the client pick a currently unused transport address, typicall= y > >> by allowing the underlying OS to pick a currently unused port for a > >> new socket. > >> > >> I think talk about socket in this context should be skipped as it > >> otherwise have been eliminated. > > The above text is from https://tools.ietf.org/html/rfc5766#section-6.1.= I > presume you are proposing the following update: > > > > The client first picks a host transport address. It is RECOMMENDED > > that the client pick a currently unused transport address, typicall= y > > by allowing the underlying OS to pick a currently unused port. >=20 > Yes, I see no loss of real information. Okay, Updated. >=20 >=20 > > > >> L. Section 7.1: > >> > >> The client then picks a transport protocol to use between the client > >> and the server. The transport protocol MUST be one of UDP, TCP, TL= S- > >> over-TCP or DTLS-over-UDP. > >> > >> I find it strange that this indicates that one should pick the > >> transport protocol to use client to server without considering the > >> server capabilities. Especially as the client configuration or server > >> discovery procedures will indicate transport protocol support. > > The server may support more than one transport protocol. >=20 > Sorry, should have been clearer. Should there be any references to how th= e > client can determine the servers capabilities? You have recommendations > about using UDP and a pointer to Section 2.1 for some discussion of the c= hoices. > So that covers giving some guidance to the protocol choice. I have updated the text as follows: The client then picks a transport protocol to use between the client and the server based on the transport protocols supported by the server. The transport protocol MUST be one of UDP, TCP, TLS- over-TCP o= r DTLS-over-UDP. Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that the client pick UDP unless it has a reason to use a different transport. One reason to pick a different transport would be that the client believes, either through configuration or discovery or by experiment, that it is unable to contact any TURN server using UDP. See Section 2.1 for more discussion. The subsequent paragraph in Section 7.1 discusses use of [RFC8155] to disco= very TURN server, and use of [RFC5928] and [RFC7350] to discover server tra= nsport capabilities.=20 >=20 > Also shouldn't this paragraph come before the previous one. I.e. that you= first > must pick your transport protocol before you can pick a host transport ad= dress ? No, middle-boxes may drop UDP traffic to the TURN server, and the client by= experiment will identify the transport protocol permitted to the TURN serv= er and eventually uses the=20 host transport address using which successful response was received from th= e server. >=20 >=20 > > > >> Secondly, what is the motivation for the MUST in the second sentence? > >> This is appears to have strange interactions with any future > >> extensions and have no impact. A client must obvious chose a client > >> to server transport protocol it supports, and one that the server > >> supports or the client hope it will support. > > https://tools.ietf.org/html/rfc5766#section-6.1 has the same text, I ha= ve > updated the text as follows: > > The client then picks a transport protocol to use between the client an= d the > server based on the transport protocols supported by the server. > > The TURN server MUST enable one of the transport protocols, UDP, TCP, T= LS- > over-TCP or DTLS-over-UDP. >=20 > If the intention is to move the requirement to the server side for making= it > normative to support at least one of the 4 options listed, I think you ne= ed to > rewrite it to say: >=20 > A TURN server MUST enable at least one of the transport protocols, UDP, T= CP, > TLS- over-TCP or DTLS-over-UDP. The above point is already discussed in Section 5 as follows: To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP, TLS-over-TCP and DTLS-over-UDP transports. >=20 >=20 >=20 > > > >> M. Section 7.1: > >> > >> The client also picks a server transport address, which SHOULD be > >> done as follows. The client uses one or more procedures described = in > >> [RFC8155] to discover a TURN server and uses the TURN server > >> resolution mechanism defined in [RFC5928] to get a list of server > >> transport addresses that can be tried to create a TURN allocation. > >> > >> 1) So RFC 8155 states that it has no recommendation on server > >> selection, nor on how to related local configuration to any auto-disco= very > servers. > >> To me it appears that the protocol utilizing TURN should consider > >> what makes sense in their deployments. Thus, does the need for such > >> consideration needs to be highlighted somewhere in this specification. > > https://tools.ietf.org/html/rfc8155#section-3 discusses using auto-disc= overy in > the absence of local configuration or if the local configuration does not= work. > https://tools.ietf.org/html/rfc8155#section-9 explains the mechanisms to > authenticate the discovered TURN server. > > > > I am not sure about the additional considerations you are looking in th= is > specification. >=20 > Let me attempt to formulate the question in another way. As the Discovery > procedure documented in RFC 8155 does not mandate any specific order or > even what mechanisms are actually used / supported, then did the WG consi= der > to make either a stricter recommendation or some other considerations to > better ensure that TURN clients can discover TURN servers? >=20 > It is fine to say no. No, it was left to implementation. If local configuration does not work for= a TURN client, RFC8155 explains performing all the discovery mechanisms to= find the TURN server. >=20 >=20 > > > >> N. Section 7.1: > >> > >> Clients MUST NOT include a REQUESTED-ADDRESS- > >> FAMILY attribute in an Allocate request that contains a RESERVATION= - > >> TOKEN attribute, for the reasons outlined in [RFC6156]. > >> > >> Considering that this document obsoletes RFC 6156, I think it is bad > >> form to reference that document, rather than to move the necessary > >> motivation into this document. > > Done, updated text as follows: > > Clients MUST NOT include a REQUESTED-ADDRESS-FAMILY attribute in an > Allocate request that contains a RESERVATION-TOKEN attribute, for the rea= son > that server uses the previously reserved transport address corresponding = to the > included token and the client cannot obtain a relayed transport address o= f a > specific address type. >=20 > Works for me. >=20 > > > >> O. Section 7.1: > >> > >> If the client wishes to obtain a relayed transport address of a > >> specific address type then it includes a REQUESTED-ADDRESS-FAMILY > >> attribute in the request. > >> > >> I don't find anything describing what the default behavior is if one > >> doesn't include the attribute, but the TURN server supports multiple a= ddress > families. > >> > >> I see that bullet 7 in Section 7.2 indicates that IPv4 is default. > >> Should the text in 7.1 be explicit about this default? > > The text in Section 7.1 is added for TURN clients not supporting TURNbi= s > specification to provide backward compatibility. >=20 > But if I understand this correctly, the legacy way is to not include the > REQUESTED-ADDRESS-FAMILY attribute for an IPv4 address.=20 Yes.=20 > Thus, shouldn't a > sentence be added after the above to state that if the client wants an > IPv4 address it should skip using REQUESTED-ADDRESS-FAMILY attribute to > enable legacy interoperability, or do I missunderstand? REQUEST-ADDRESS-FAMILY attribute is initially defined in https://tools.ietf= .org/html/rfc6156 as comprehension-required attribute. If the legacy server= does not understand this attribute, the request will be rejected (420 (Unk= nown Attribute), and if the client wants IPv4 relayed transport address, th= e client will have to retry the request without the REQUEST-ADDRESS-FAMILY = attribute. =20 >=20 >=20 > > > >> P. Section 7.2: > >> > >> Otherwise, if the attribute is included but > >> specifies a protocol other that UDP, the server rejects the > >> request with a 442 (Unsupported Transport Protocol) error. > >> > >> Assuming that you don't support an extension for that transport protoc= ol. > >> Should that be made explicit? > > I did not get the above comment. The attribute REQUESTED-TRANSPORT is > originally defined in TURN (see https://tools.ietf.org/html/rfc5766#secti= on-6.2), > and TURNbis does not update the use of the attribute. >=20 > I am requesting a clarification in the text like this: >=20 >=20 >=20 > Otherwise, if the attribute is included but > specifies a protocol other that UDP that is not supported by the = server, > then the server rejects the > request with a 442 (Unsupported Transport Protocol) error. >=20 > What I mean with extension above is the case when the TURN server support= s > an TURN extension that define for example TCP as server to peer protocol. Works for me, updated draft. >=20 >=20 >=20 > > > > > >> Q. Section 8.3: > >> > >> If the client receives a success response to its Refresh request wi= th > >> a non-zero lifetime, it updates its copy of the allocation data > >> structure with the time-to-expiry value contained in the response. > >> > >> If the client receives a 437 (Allocation Mismatch) error response t= o > >> a request to delete the allocation, then the allocation no longer > >> exists and it should consider its request as having effectively > >> succeeded. > >> > >> So there are no considerations for the client if it receives an error > >> response to a refresh request when Lifetime was non-zero? > >> > >> I am bit surprised by that. I assume that there are certain cases > >> when the request could be resent, and others where the meaning is > >> that the allocation is gone. > > TURNbis does not update the refresh behavior already defined in > https://tools.ietf.org/html/rfc5766#section-7.3. I will add the followin= g line: > > If the client receives an error response to its request to refresh the = allocation, > it should consider the allocation no longer exists. >=20 > Isn't that over simplifying cases where one attempts to refresh an alloca= tion > and could actually handle the issue. For example an error response to the= client > of 438 (Stale Nonce) where the client can retry the request with the new > Nonce. I also wonder if request time out as well as 400 (if it can figure= out what > the issue was) could be re-attempted prior to allocation expires. But at = leat hte > 438 appears to indicate a situation where the client should not give up, = and > thus should have some text here. Good point, Modified the above line follows: If the client receives a 437 (Allocation Mismatch) error response to its re= quest to refresh the allocation, it should consider the allocation no longe= r exists. If the client receives a 438 (Stale Nonce) error to its request t= o refresh the allocation,=20 it should reattempt the request with the new nonce value. >=20 > > > >> R. Section 11.5: > >> > >> When the server receives an ICMP packet, the server verifies that t= he > >> type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either > >> 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that t= he > >> IP packet in the ICMP packet payload contains a UDP header. If > >> either of these conditions fail, then the ICMP packet is silently > >> dropped. > >> > >> Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter > >> Problem are for ICMPv4? > > I don't get the above comment, please explain the question with an exam= ple. >=20 > So if a server receives an ICMP for sent packet with ICMPv4 type 12 > (Parameter Problem) then that is relayed to the client according to this = text. > But if the server sent a packet with IPv6 towards the peer and receives a= n > ICMPv6 message with Type 4 (Parameter Problem) that is not relayed to the > client. Why this discrepancy? Thanks, got the comment. ICMPv4 and ICMPv6 error message (Parameter problem= ) need not be relayed back to the client because IPv6 extension header and = IPv4 option set in the packet from the client will not be relayed to the pe= er (Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#secti= on-14 and https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-13= .2). Removed ICMPv4 12 type. Added the following lines to Section 16.3 to = convey the MTU of the next-hop link: Error Data: This field size is 4 bytes long. If the ICMPv6 type is 2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination Unreachable) and Code is 4 (fragmentation needed and DF set), the Error Data field will be set to the Maximum Transmission Unit of the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of [RFC1191]). For other ICMPv6 types and ICMPv4 types and codes,=20 Error Data field MUST be set to zero. >=20 > > > >> S. Section 12.5: > >> > >> Over TCP and TLS-over-TCP, the ChannelData message MUST be padded > to > >> a multiple of four bytes in order to ensure the alignment of > >> subsequent messages. The padding is not reflected in the length > >> field of the ChannelData message, so the actual size of a ChannelDa= ta > >> message (including padding) is (4 + Length) rounded up to the neare= st > >> multiple of 4. Over UDP, the padding is not required but MAY be > >> included. > >> > >> Are there anywhere written what one may or may not include of the > >> TURN related messages in a single UDP datagram. Because it is > >> technically feasible I belive to include two Send Indications in one U= DP > datagram to the server. > > As per https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-1= 1.2, one > send indication in one UDP datagram to the server. >=20 > Okay, the procedure described indicates that only a single Indication per= UDP > datagram . I think that is good enough. >=20 >=20 > > > >> T. Section 13.1: > >> > >> Flow Label > >> > >> Preferred behavior: The relay sets the Flow label to 0. The rel= ay > >> can choose to set the Flow label to a different value if it > >> supports the IPv6 Flow Label field [RFC6437]. > >> > >> Alternate behavior: The relay sets the Flow label to the default > >> value for outgoing packets. > >> > >> I think this section should be improved in two ways. > >> > >> First of all I think it should clarify that each allocation to peer > >> flow is its own > >> IPv6 Flow in perspective of the IPv6 Flow label. > >> > >> Secondly, I think in the spirit of RFC 6473 the preferred behavior > >> should be to set the IPv6 flow label if the implementation is > >> capable, or leave it to the underlying network stack to actually set > >> it. Compared to RFC 7915, the TURN server actually have an > >> understanding of what are different flows without having examining > additional protocol layers. > > Updated text as follows: > > > > Preferred behavior: > > The TURN server can use the relayed transport address, peer transport > > address and UDP protocol number to generate and set the flow label > > value in the IPv6 packet as discussed in Section 3 of [RFC6437]. If the= TURN > server is incapable of generating the flow label value from the IPv6 pack= et's 5- > tuple, it sets the Flow label to 0. > > > > (Please note the proposed update deviates from the behavior defined > > https://tools.ietf.org/html/rfc6156#section-8.1) >=20 > Good, but I would suggest some tweaks to clarify: >=20 > Preferred behavior: > The TURN server can use the 5-tuple of relayed transport address, peer > transport address and UDP protocol number to identify each flow, generate= and > set the flow label value in the IPv6 packet as discussed in Section 3 of > [RFC6437]. If the TURN server is incapable of generating the flow label v= alue > from the IPv6 packet's 5-tuple, it sets the Flow label to 0. Thanks, Updated draft. >=20 > (Please note the proposed update deviates from the behavior defined > https://tools.ietf.org/html/rfc6156#section-8.1) >=20 >=20 >=20 > > > > > > > >> Thirdly, I don't understand what the alternative behavior actually is. > >> This as it is either setting it to 0, or classifying things as flow > >> and then provide it with a random flow label. I think the right altern= ative > behavior is to set it 0. > > Updated text to say: > > > > Alternate behavior: The relay sets the Flow label to the default > > value of zero for outgoing packets. >=20 > Ok >=20 > > > >> U. Section 13. 1,2,3: > >> > >> For both preferred and alternate behavior, the DONT-FRAGMENT > >> attribute MUST be ignored by the server. > >> > >> I don't understand why just because one performs v4<->v6 or v6 to v4 > >> translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT > >> attribute. If the client has request to not fragment and the server > >> is unable to do that when forwarding to the peer it needs to generate > >> an ICMP attribute response saying the packet is to big. Otherwise the > >> relay breaks the Path MTU discovery mechanisms. > > TURNbis is using the translation algorithms specified in RFC7915. > > > > [a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header= to not > fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#section= -4), > DON'T-FRAGMENT attribute can be ignored. > > [b] For IPv6 to IPv4: The translation algorithm in > https://tools.ietf.org/html/rfc7915#section-5 is used. If the IPv6 endpo= int wants > to discover the path MTU, it will send IPv6 packets without Fragment head= er > and DON'T-FRAGMENT attribute can be ignored. > > [c] For IPv6 to IPv6: If the IPv6 endpoint wants to discover the path M= TU, it > will send IPv6 packets without Fragment header and DON'T-FRAGMENT > attribute can be ignored. > > > > Please note ignoring the DONT-FRAGMENT attribute is picked from > https://tools.ietf.org/html/rfc6156#section-8 and discussed in the BEHAVE= WG > https://mailarchive.ietf.org/arch/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc. >=20 > Thanks for the clarification on the context. I should have read Section > 4 of 7915. Then I would have likely gotten the implication that the IP he= ader DF > or Fragmentation header impacts how things are working. >=20 > However, I find the reasoning behind this choice very strange. I don't se= e how > you can implement a TURN server that does IPv4 <->IPv6, or IPv6 relaying > without having privileged access and where it reads the raw headers. An > implementation based on UDP sockets will not be able to do the right thin= g > here to my understanding. However, it could follow the DONT-FRAGMENT > attribute to instructing the sending using the Socket to do the right thi= ng. As per the discussion in BEHAVE WG, it seems possible to set and get variou= s IP header fields using sockets, see https://mailarchive.ietf.org/arch/msg= /behave/j6FfzgVLuSeHfOWz9zRO5iPCp98 and https://mailarchive.ietf.org/arch/m= sg/behave/3I-DvtVf_4cGcDnIktsWNEtfIYM.=20 >=20 > I think there are two directions we can proceed in here. >=20 > 1. Redefine this text to enable usage of DONT-FRAGMENT I prefer not to change the behavior discussed and finalized for RFC6156 in = BEHAVE WG. >=20 > or >=20 > 2. Clarify the scope and implications of Unpriviliged TURN Server doing > translation >=20 >=20 > For the second option I think there are several aspects that I like to se= e > addressed: >=20 > 2a: Update the sentence I quoted for this issue to make it clear that y= ou are > relying solely on IPv4 DF and IPv6 Fragmentation Header to control the > fragmentation. Added the following line to Packet Translations (Section 13.6). The TURN server solely relies on the DF bit in the IPv4 header and Fragment= ation header in IPv6 header to handle fragmentation and does not rely on th= e DONT-FRAGMENT attribute.=20 >=20 > 2b: Clarify that Unpriviliged TURN Severs that do IPv4<-> IPv6 translat= ion will > not handle fragmentation well. And include a point to the last paragraph = of > Section 2.7 and the use of DONT-FRAGMENT In Allocate requests to determin= e > support and that these needs to be rejected by such a server. Depending on the OS, Unprivileged TURN Severs may or may not handle fragmen= tation (i.e. have access to DF bit). I will add the following line:=20 If the TURN server carrying out packet translation from IPv4-to-IPv6 cannot= get the Don't Fragment (DF) bit in the IPv4 header, it MUST reject the All= ocate request with DONT-FRAGMENT attribute. >=20 > By the way, there must be a typo with a "not" that shouldn't be in this > paragraph in Section 4 of 7915: >=20 > When the IPv4 sender does not set the DF bit, the translator MUST NOT > include the Fragment Header for the non-fragmented IPv6 packets. >=20 > To me it make sense for a IPv4->IPv6 translation where the IPv4 has DF=3D= TRUE > to not include the fragmentation header, do you agree? https://tools.ietf.org/html/rfc7915#section-4.1 says to include the fragmen= t header only when IPv4 header has DF=3D0 and the packet size exceeds the M= TU. >=20 > IF you agree I can file an errata on this. >=20 > >> V. Section 13.2: > >> > >> Fragmentation: > >> > >> If the incoming packet included a Fragment header and the outgoi= ng > >> packet size exceeds the outgoing link's MTU, the relay MUST > >> fragment the outgoing packet into fragments of no more than 1280 > >> bytes. The relay sets the fields of the Fragment header as > >> appropriate for a packet originating from the server. > >> > >> Is really the intention here to refragment the packet without > >> providing any indication that the practical MTU is smaller than what > >> the peer or client thinks it is? > > Yes, TURNbis is following the existing behavior already defined in > https://tools.ietf.org/html/rfc6156#section-8.1. > Okay. > > > >> W. Section 14: > >> > >> Preferred Behavior: Set the outgoing value to the incoming value= , > >> UNLESS the server is doing Active Queue Management, the incoming > >> ECN field is ECT(1) (=3D0b01) or ECT(0) (=3D0b10), and the serve= r > >> wishes to indicate that congestion has been experienced, in whic= h > >> case set the outgoing value to CE (=3D0b11). > >> > >> First of all do you have any special meaning with all capital UNLESS? > >> > >> Secondly, I don't know how wise it is to have partial definitions of > >> what the ECN behavior is. Maybe simpler to say that that the relay is > >> performing AQM it can support the ECN marking behavior as defined in R= FC > 3168. > > The above text is same as https://tools.ietf.org/html/rfc5766#section-1= 2, > replaced "UNLESS" with "unless". >=20 > So the UNLESS Is only for emphasis? >=20 > I think the sentence could be formulated so that it is easier to understa= nd that > the text after "... active queue managmenet, ..." is in case on does AQM.= Also I > think it is worth clarifying that the TURN server can operate as defined = by RFC > 3168. In addition the use of ECT(1) experiments has been changed so that = also > needs a reference. So perhaps: >=20 > Preferred Behavior: Set the outgoing value to the incoming value. T= he > server may perform Active Queue Management, in which case it SHOULD > behave as a ECN aware router [RFC3168] and can mark traffic with Congesti= on > Experienced (CE) instead of dropping the packet. The use of ECT(1) is sub= ject to > experimental usage [RFC8311]. Looks good, updated draft. >=20 >=20 >=20 > > > >> X. Section 14: > >> > >> How are these IP level fields handled when the transport is TCP or TLS= /TCP? > >> There there are not necessary a one to one mapping between datagrams > >> and TCP packets. And if there are no support then there are need for > >> clarification of behaviors when using TCP based transport. > > Section 14 already clarifies that the descriptions in this section do n= ot apply to > TURN messages sent over TCP or TLS transport from the server to the clien= t. >=20 > Yes you are right. What are the recommendations for how to set the fields > when the Channel message or Send Indication arrives over > TCP/(TLS) to the server? To me the basis is the alternative behavior with= the > exception for the DF bit. However, behaviors for datagrams orignated by t= he > server and delivered to the server over non datagram transport will need = to > have recommendations also for IPv6. I am not aware of any standard 1:1 mapping of IP level fields between UDP a= nd TCP, https://tools.ietf.org/html/rfc5766#section-12 does not define the= behavior to set the fields, the topic was discussed in BEHAVE WG https://m= ailarchive.ietf.org/arch/msg/behave/QBZaYgk-x5lZNFpE4qCLiztcg8Y and the dec= ision was to focus only on UDP to UDP case. What specific change are you p= roposing in this Section ? >=20 > > > >> Y. Section 16.4. DATA > >> > >> The DATA attribute is present in all Send and Data indications. Th= e > >> value portion of this attribute is variable length and consists of > >> the application data (that is, the data that would immediately foll= ow > >> the UDP header if the data was been sent directly between the clien= t > >> and the peer). If the length of this attribute is not a multiple o= f > >> 4, then padding must be added after this attribute. > >> > >> Can you please clarify if one would get all the remaining bytes of > >> the IP packet payload or only the number of bytes the UDP length field > indicates ? > >> > >> The reason I ask is that there is possibility that there are a > >> discrepancy between these fields, something the proposal for an > >> experimental specification for UDP options attempt to utilize. > >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ > >> > >> Note, I only want you to clarify what is actually included. I would > >> assume using the UDP length field makes sense in this case. > > The application data does not include the options discussed in draft-ie= tf- > tsvwg-udp-options. > > Please clarify the specific update you are looking in this section. >=20 > My intention here was not to bring in UDP options, only to ensure that th= e > specification text is clear. As UDP options draft points out there could = be a > discrepancy between the UDP length and IP length. Thus, I think there is = a point > to make it clear that the data includes UDP length -8 bytes of UDP payloa= d. > Possible include a informative reference for why there might be a discrep= ancy. The data only includes the application data, and the length of the attribut= e is also based on the application data, and I don't see any discrepancy in= the client to determine the length of the application data.=20 >=20 > AC. Section 16.12: > >> Reason Phrase (variable). This field is under defined. First of all > >> the format of the text string is not defined, which it is in Stunbis > >> Error-Code attribute is defined as. > >> > >> The reason phrase MUST be a UTF-8 [RFC3629] encoded > >> sequence of less than 128 characters (which can be as long as 509 > >> bytes when encoding them or 763 bytes when decoding them). > > Thanks, updated section to use UTF-8 encoding. > > > >> Secondly, I think it might be worth pointing out the padding here. It > >> is not clear if there is any form of string termination and how the > >> padding which will be interpreted as NULL characters 0-3 depending on > >> the alignment. I note this later issue appears to be existing in STUNB= is also. > > Padding is discussed in STUN for variable length attributes, please see > https://tools.ietf.org/html/draft-ietf-tram-stunbis-18#section-14. >=20 > Thanks, missed that. I think that is clear. >=20 >=20 > > > >> AD. Section 16.2: > >> > >> Why isn't the text here say that this attribute may also be used to > >> indicate the desired lifetime in allocation requests? > > https://tools.ietf.org/html/rfc5766#section-14.2 did not discuss desire= d > lifetime. Anyways, added the following line: > > The TURN client can include the LIFETIME attribute with the desired lif= etime > in Allocate and Refresh requests. >=20 > Good. >=20 > > > >> AE. Section 16.9: DONT-FRAGMENT > >> > >> I think it would be good to indicate the use of the attribute in > >> Allocate Requests also. > > The above point is discussed in Section 7.1: > > > > > > If the client wishes to later use the DONT-FRAGMENT attribute in one > > or more Send indications on this allocation, then the client SHOULD > > include the DONT-FRAGMENT attribute in the Allocate request. This > > allows the client to test whether this attribute is supported by the > > server. > > >=20 > Yes, but I think it is inconsistent when the text says: >=20 > This attribute is used by the client to request that the server set > the DF (Don't Fragment) bit in the IP header when relaying the > application data onward to the peer. >=20 > And there the is additional usage of it. When a minor change would indica= te > that alternative use also. >=20 > This attribute is used by the client to request that the server set > the DF (Don't Fragment) bit in the IP header when relaying the > application data onward to the peer, and for determining the capabilit= y in > Allocate requests. Okay, updated. >=20 >=20 > > > >> AF. Section 24.2 > >> > >> [Protocol-Numbers] > >> "IANA Protocol Numbers Registry", 2005, > >> . > >> > >> This is a normative reference based on how it is used in Section 16.8. > > Okay, moved as Normative reference. > Good. > >> AG. Seciton 18. > >> > >> Sometime before the 20 minute lifetime is up, the client refreshes > >> the allocation. This is done using a Refresh request. As before, > >> the client includes the latest username, realm, and nonce values in > >> the request. The client also includes the SOFTWARE attribute, > >> following the recommended practice of always including this attribu= te > >> in Allocate and Refresh messages. When the server receives the > >> Refresh request, it notices that the nonce value has expired, and s= o > >> replies with 438 (Stale Nonce) error given a new nonce value. The > >> client then reattempts the request, this time with the new nonce > >> value. This second attempt is accepted, and the server replies wit= h > >> a success response. Note that the client did not include a LIFETIM= E > >> attribute in the request, so the server refreshes the allocation fo= r > >> the default lifetime of 10 minutes (as can be seen by the LIFETIME > >> attribute in the success response). > >> > >> I notice that this part nor the text before appears to discuss the > >> permission lifetime that will expire after 5 minutes. Thus, it needs > >> to be refreshed prior to the Allocation. > > I have added text to discuss refreshing the channel binding, > https://tools.ietf.org/html/rfc5766#section-16 did not discuss refreshing= the > permissions and channel bindings. > Ok. > > > >> AH. Section 18. > >> > >> I am missing any example having to do with Address Family interactions= . > > There was no ask from the WG members to add an example and even > https://tools.ietf.org/html/rfc6156 did not have an translation example. > Ok, let skip this for now. But, it will be commented on again most likely= by > other reviewers. > > > >> AI. DTLS Cipher Suits > >> > >> Am I understanding it correct that the definition of what DTLS cipher > >> suit that a TURN Server currently is to support is the ones in RFC 752= 5 ? > > No, the cipher suites and (D)TLS profile is discussed in > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3 and = it > follows the recommendations in RFC7525. >=20 > Ahaa, of course. But, maybe an explicit reference to STUNbis in section > 2.1 that the transports for TURN and STUN messages are defined there? >=20 > > > >> In that case, I think the wording is a bit weak as the only reference > >> I find are in Section 2.1: > >> > >> If (D)TLS transport is > >> used between the TURN client and the TURN server, the guidance give= n > >> in [RFC7525] MUST be followed to avoid attacks on (D)TLS. > > RFC7525 provides various recommendations to avoid attacks on (D)TLS. >=20 > It was really the text in STUNbis that I was looking for. Okay, modified the above line as follows: If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] and the guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. Cheers, -Tiru >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Network Architecture & Protocols, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Apr 25 18:46:37 2019 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3F01201CD; Thu, 25 Apr 2019 18:46:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <155624318767.19257.1595832539968795812@ietfa.amsl.com> Date: Thu, 25 Apr 2019 18:46:27 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-turnbis-24.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 26 Apr 2019 01:46:28 -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 WG 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-24.txt Pages : 86 Date : 2019-04-25 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. This document obsoletes RFC 5766 and RFC 6156. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-turnbis-24 https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 26 02:43:39 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFD21202F0 for ; Fri, 26 Apr 2019 02:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHzxLZ_2-Eh6 for ; Fri, 26 Apr 2019 02:43:35 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 617D4120075 for ; Fri, 26 Apr 2019 02:43:34 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1556271458; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Y vDwS+APv7J1oAtXwP90RWt46AHPAMQ7dcw3+Sf/Bc w=; b=Gt5ueuaDmqwZXeT5VZJjHiEgeepbyjQo5cbldUTWRk7S 4608HsBaJ3vofeOzCss1Vv0gsNT4KE9XntLuLZC1cFfavTa1Rn MJNOKhIai65LOq5TfFNqUf+0Sn51Z/gvoZmGL8uxRRRTkZOHyV EGsXhf1wGoNCtwSXwcq2Lse1n+w= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c27_92a8_0be0d1d3_6b9b_46b9_8b24_9ef3f9d2aa05; Fri, 26 Apr 2019 03:37:38 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 03:43:26 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 26 Apr 2019 03:43:26 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 03:43:25 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2887.namprd16.prod.outlook.com (20.178.234.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.14; Fri, 26 Apr 2019 09:43:24 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 09:43:24 +0000 From: "Konda, Tirumaleswar Reddy" To: "tram@ietf.org" CC: Magnus Westerlund Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-24.txt Thread-Index: AQHU+9H4nuDHksfUPUm0woA3nJjgzaZOMO6Q Date: Fri, 26 Apr 2019 09:43:24 +0000 Message-ID: References: <155624318767.19257.1595832539968795812@ietfa.amsl.com> In-Reply-To: <155624318767.19257.1595832539968795812@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.205.191] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 030cb9a0-f554-4807-f7b6-08d6ca2ba05e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2887; x-ms-traffictypediagnostic: BYAPR16MB2887: x-ms-exchange-purlcount: 5 x-microsoft-antispam-prvs: x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(376002)(366004)(396003)(199004)(13464003)(189003)(32952001)(6306002)(229853002)(6436002)(5024004)(33656002)(68736007)(256004)(66574012)(2351001)(186003)(7696005)(71200400001)(97736004)(446003)(11346002)(476003)(71190400001)(53546011)(8676002)(76116006)(5660300002)(486006)(3846002)(966005)(2501003)(76176011)(102836004)(5640700003)(6506007)(26005)(316002)(6916009)(80792005)(99286004)(25786009)(86362001)(73956011)(4326008)(305945005)(6116002)(7736002)(74316002)(53936002)(55016002)(8936002)(6246003)(66476007)(66556008)(1730700003)(64756008)(66446008)(81166006)(81156014)(478600001)(2906002)(9686003)(66066001)(66946007)(52536014)(72206003)(14454004)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2887; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CZ+5NXKsNGklJ5/89ZfXaL6BzQnV5i8YygrA3ACXq1OePl9v4RNlt1rSsw8CIdpFCiwosu1pkmQXpwR/Ox/ccvwXQh+JCkW10Em5I29GQUmp43c82tZChZwTk001JbGBRKeXVq3G+SjfCqsH/DYywa9oPwXlAczqdr0f4OFp+wWt2DRpSOW4ZmNiIjrPbB+yOJWwJ+HeVX2LbzK6Ts3E843hibNRFS2v4nhfjRC9n95v5XwlxLya15+LjHC11v9C9f+2NpXQYOp+ak8456YB2PVLBQPcMEanV86g6b+Z+jh3pjwETQ5ka39FltbBH/iVomTEwy4ok/skOa2IQlQK6YUc/7mGaOfGUCV7usV3S8uCTBGlBPXdexFLshd+oao3fsjcK589VT3i7LZymnrF1/j2ljCE4zcq+Fbgg+XDs6Q= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 030cb9a0-f554-4807-f7b6-08d6ca2ba05e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 09:43:24.1686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2887 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6533> : inlines <7062> : streams <1819769> : uri <2837255> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-24.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 26 Apr 2019 09:43:38 -0000 This revision addresses comments from our AD review. -Tiru > -----Original Message----- > From: tram On Behalf Of internet-drafts@ietf.org > Sent: Friday, April 26, 2019 7:16 AM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-24.txt >=20 > This email originated from outside of the organization. Do not click link= s or > open attachments unless you recognize the sender and know the content is > safe. >=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 WG of the > IETF. >=20 > 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-24.txt > Pages : 86 > Date : 2019-04-25 >=20 > 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. >=20 > 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. >=20 > This document obsoletes RFC 5766 and RFC 6156. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-24 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-24 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-24 >=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 Fri Apr 26 04:37:26 2019 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77F12032A; Fri, 26 Apr 2019 04:37:16 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POK13KdjdX1R; Fri, 26 Apr 2019 04:37:08 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60066.outbound.protection.outlook.com [40.107.6.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051F3120457; Fri, 26 Apr 2019 04:37:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uN280PuTlc0QVj3NTIyhbp3q5f42/oPV2mGz0qHrpZE=; b=LcivMERH7iYxcnFbncxfsTuX80gZMBQO/xhITwIm7zRQovX5lGwgEl+p7zZy6j+eZYhnGWkW1/fbMrpkTFA94iRQAIG4ApIhCVz1u39mEqh2N0itAWbZzpV16nrOgGxn/uTjBf7mUuDAAC/WZRflRRwJn9PH0VivC234k5+2Qwo= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2732.eurprd07.prod.outlook.com (10.168.188.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.5; Fri, 26 Apr 2019 11:37:04 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1856.004; Fri, 26 Apr 2019 11:37:04 +0000 From: Magnus Westerlund To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiPw== Date: Fri, 26 Apr 2019 11:37:04 +0000 Message-ID: References: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [198.24.6.220] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1567fff6-5e65-4057-1654-08d6ca3b81b1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2732; x-ms-traffictypediagnostic: HE1PR0701MB2732: x-ms-exchange-purlcount: 22 x-microsoft-antispam-prvs: x-forefront-prvs: 001968DD50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(136003)(39860400002)(51914003)(15594002)(189003)(199004)(54896002)(86362001)(2201001)(236005)(53946003)(9686003)(55016002)(6306002)(6436002)(18074004)(229853002)(256004)(97736004)(316002)(81156014)(8676002)(53936002)(81166006)(25786009)(6246003)(7736002)(26005)(186003)(14444005)(74316002)(2501003)(68736007)(3846002)(44832011)(966005)(14454004)(486006)(478600001)(6116002)(2906002)(561944003)(33656002)(606006)(8936002)(99286004)(110136005)(7696005)(76176011)(66066001)(52536014)(6506007)(53546011)(5660300002)(102836004)(30864003)(71190400001)(71200400001)(91956017)(76116006)(66476007)(66946007)(73956011)(66446008)(64756008)(66556008)(446003)(476003)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2732; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: AdPpebRx4b5ryttkDHz6P9v8xBsYx6Ni3pZTSUaaCXR9rkHSPX2h1aVcwWsIXUmiIc1R2Lsvlg6jCs3WPrwjdCT9OiXuHgyaVU/3lMKPbU3BbLB4UrtmkBwFMemFTvKpNatlpRymsLNwSsTvOL6IzNglWH2L6HcfKx2GwH6IphOzWhovjDXZ87QSHsnxoDCxKzq7PhXLkBns7EI1Ku2C+xfJOWVE2AwqKxkWeshIlnU8rYfSN56iD9cu9HAH/cEv7SuJmGsFxUCq1u03gDfW1Q8TsWD4vp2g2+n9Fwl4oiKH+V8RehMUUw3OGmLhGnTFpKFHtjMafglW2Mzmh0KSc+hD6vQDjSMkB5qbhLPib6Y0863p4npNcn7denUajpukgO3UGZLagWz9hiO9itpzA6KjvL8k9jZd+fXsghOKYb4= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522C1819EA5B98774BA0869953E0HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1567fff6-5e65-4057-1654-08d6ca3b81b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 11:37:04.5960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2732 Archived-At: Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 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, 26 Apr 2019 11:37:24 -0000 --_000_HE1PR0701MB2522C1819EA5B98774BA0869953E0HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Cutting away what appear settled. On 2019-04-18 10:20, Konda, Tirumaleswar Reddy wrote: error packet, the server also relays certain layer 3/4 header fields from = the ICMP header to the client. When the client sends a packet to the server, th= e server relays the transport protocol data from the packet to the appropriat= e peer using the relayed transport address as the source. "appropriate" appears wrong. The peer is the one the client have configure = for the allocation. So I think a more direct language can be used. "appropriate peer" is used at several places in https://tools.ietf.org/html= /rfc5766. There is now a single occurrence of it in this document. And in that contex= t, it appears that using "intended" or "addressed" peer would work better a= nd be clearer. Othewise fine with me. H. Section 5: If the server requires requests to be authenticated, then the server's administrator MUST choose a realm value that will uniquely identify the username and password combination that the client must use, even if the client uses multiple servers under different administrations. Just to verify, TURN does not allow a single server address to host multiple realms do it? Each Realm needs its own unique server transport address? No, I don't see any such restriction in TURN. For example, in an Enterpris= e network with multiple realms, the TURN server based on the client subnet ca= n choose the realm. I think this is a not expressed assumption, that realm determination may be done based on source IP address of the client's request. That is an assumpt= ion that is not generally applicable, but can work for some combinations of rea= lms. For example an server that has a REALM for an WebRTC service that is intended to have no restrictions can't be co-located with anything that has= a small scope as that can lead to selection of the wrong realm. Yes, both assumptions are deployment specific. Enterprise TURN servers are= discussed in https://tools.ietf.org/html/rfc7478. Username and password is not the only way to perform mutual authentication = b/w the TURN client and server, https://tools.ietf.org/html/rfc7635 discuss= es using OAuth and is used by WebRTC (see https://w3c.github.io/webrtc-pc/)= . What do you think is the best option here. Simple document that there are n= o mechanism in the protocol for the client to indicate which REALM it thinks = it belongs to and state that the basic mechanism is using different server por= ts for different realms. Or to write even more where the possibility in source= IP address identification of realm is described but also its limitations? If different server ports are used for different realms, the client needs t= o learn the server ports and manual configuration may not be a suitable opt= ion. The public TURN server could have different domain names for different= realms, and the client can discover the server port for the TURN server do= main using S-NAPTR. I don't think the draft should discuss deployment spec= ific solutions. So if I understand this correctly your stating that it is up to the server = implementation to figure out what the realm on what ever information is get= s based on the request. From a client implementation perspective it appears= less clear if anything the client will affect the realm response it will r= eceive. I don't think this Section 18 quote is not clear either. Following the procedures of the long-term credential mechanism of STUN [I-D.ietf-tram-stunbis], the server includes an ERROR-CODE attribute with a value of 401 (Unauthorized), a REALM attribute that specifies the authentication realm used by the server (in this case, the server's domain "example.com"), and a nonce value in a NONCE attribute. So I will not persist on this, but I would appreciate some indications on t= hat the server may do more than simply have a single realm for a given serv= er transport address. L. Section 7.1: The client then picks a transport protocol to use between the client and the server. The transport protocol MUST be one of UDP, TCP, TLS- over-TCP or DTLS-over-UDP. I find it strange that this indicates that one should pick the transport protocol to use client to server without considering the server capabilities. Especially as the client configuration or server discovery procedures will indicate transport protocol support. The server may support more than one transport protocol. Sorry, should have been clearer. Should there be any references to how the client can determine the servers capabilities? You have recommendations about using UDP and a pointer to Section 2.1 for some discussion of the cho= ices. So that covers giving some guidance to the protocol choice. I have updated the text as follows: The client then picks a transport protocol to use between the client and the server based on the transport protocols supported by the server. The transport protocol MUST be one of UDP, TCP, TLS- over-TCP o= r DTLS-over-UDP. Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that the client pick UDP unless it has a reason to use a different transport. One reason to pick a different transport would be that the client believes, either through configuration or discovery or by experiment, that it is unable to contact any TURN server using UDP. See Section 2.1 for more discussion. The subsequent paragraph in Section 7.1 discusses use of [RFC8155] to disco= very TURN server, and use of [RFC5928] and [RFC7350] to discover server tra= nsport capabilities. I still think the MUST is unnecessary and problematic. The problem is that = it first of all prevents any future extension to the transport protocols be= used. Isn't the point, that the client picks one of the protocols it suppo= rts? Maybe remove the sentence and simply add something about "that the cli= ent supports" in the prior sentence. Also shouldn't this paragraph come before the previous one. I.e. that you f= irst must pick your transport protocol before you can pick a host transport addr= ess ? No, middle-boxes may drop UDP traffic to the TURN server, and the client by= experiment will identify the transport protocol permitted to the TURN serv= er and eventually uses the host transport address using which successful response was received from th= e server. Ok. Secondly, what is the motivation for the MUST in the second sentence? This is appears to have strange interactions with any future extensions and have no impact. A client must obvious chose a client to server transport protocol it supports, and one that the server supports or the client hope it will support. https://tools.ietf.org/html/rfc5766#section-6.1 has the same text, I have updated the text as follows: The client then picks a transport protocol to use between the client and th= e server based on the transport protocols supported by the server. The TURN server MUST enable one of the transport protocols, UDP, TCP, TLS- over-TCP or DTLS-over-UDP. If the intention is to move the requirement to the server side for making i= t normative to support at least one of the 4 options listed, I think you need= to rewrite it to say: A TURN server MUST enable at least one of the transport protocols, UDP, TCP= , TLS- over-TCP or DTLS-over-UDP. The above point is already discussed in Section 5 as follows: To ensure interoperability, a TURN server MUST support the use of UDP transport between the client and the server, and SHOULD support the use of TCP, TLS-over-TCP and DTLS-over-UDP transports. So, this sentence lays out the implementation requirement on the server sid= e and is very reasonable and likely needed. M. Section 7.1: The client also picks a server transport address, which SHOULD be done as follows. The client uses one or more procedures described in [RFC8155] to discover a TURN server and uses the TURN server resolution mechanism defined in [RFC5928] to get a list of server transport addresses that can be tried to create a TURN allocation. 1) So RFC 8155 states that it has no recommendation on server selection, nor on how to related local configuration to any auto-discovery servers. To me it appears that the protocol utilizing TURN should consider what makes sense in their deployments. Thus, does the need for such consideration needs to be highlighted somewhere in this specification. https://tools.ietf.org/html/rfc8155#section-3 discusses using auto-discover= y in the absence of local configuration or if the local configuration does not w= ork. https://tools.ietf.org/html/rfc8155#section-9 explains the mechanisms to authenticate the discovered TURN server. I am not sure about the additional considerations you are looking in this specification. Let me attempt to formulate the question in another way. As the Discovery procedure documented in RFC 8155 does not mandate any specific order or even what mechanisms are actually used / supported, then did the WG conside= r to make either a stricter recommendation or some other considerations to better ensure that TURN clients can discover TURN servers? It is fine to say no. No, it was left to implementation. If local configuration does not work for= a TURN client, RFC8155 explains performing all the discovery mechanisms to= find the TURN server. Okay, then lets drop this point. O. Section 7.1: If the client wishes to obtain a relayed transport address of a specific address type then it includes a REQUESTED-ADDRESS-FAMILY attribute in the request. I don't find anything describing what the default behavior is if one doesn't include the attribute, but the TURN server supports multiple addres= s families. I see that bullet 7 in Section 7.2 indicates that IPv4 is default. Should the text in 7.1 be explicit about this default? The text in Section 7.1 is added for TURN clients not supporting TURNbis specification to provide backward compatibility. But if I understand this correctly, the legacy way is to not include the REQUESTED-ADDRESS-FAMILY attribute for an IPv4 address. Yes. Thus, shouldn't a sentence be added after the above to state that if the client wants an IPv4 address it should skip using REQUESTED-ADDRESS-FAMILY attribute to enable legacy interoperability, or do I missunderstand? REQUEST-ADDRESS-FAMILY attribute is initially defined in https://tools.ietf= .org/html/rfc6156 as comprehension-required attribute. If the legacy server= does not understand this attribute, the request will be rejected (420 (Unk= nown Attribute), and if the client wants IPv4 relayed transport address, th= e client will have to retry the request without the REQUEST-ADDRESS-FAMILY = attribute. Okay, then I think this issue can be closed. Q. Section 8.3: If the client receives a success response to its Refresh request with a non-zero lifetime, it updates its copy of the allocation data structure with the time-to-expiry value contained in the response. If the client receives a 437 (Allocation Mismatch) error response to a request to delete the allocation, then the allocation no longer exists and it should consider its request as having effectively succeeded. So there are no considerations for the client if it receives an error response to a refresh request when Lifetime was non-zero? I am bit surprised by that. I assume that there are certain cases when the request could be resent, and others where the meaning is that the allocation is gone. TURNbis does not update the refresh behavior already defined in https://tools.ietf.org/html/rfc5766#section-7.3. I will add the following = line: If the client receives an error response to its request to refresh the allo= cation, it should consider the allocation no longer exists. Isn't that over simplifying cases where one attempts to refresh an allocati= on and could actually handle the issue. For example an error response to the c= lient of 438 (Stale Nonce) where the client can retry the request with the new Nonce. I also wonder if request time out as well as 400 (if it can figure o= ut what the issue was) could be re-attempted prior to allocation expires. But at le= at hte 438 appears to indicate a situation where the client should not give up, an= d thus should have some text here. Good point, Modified the above line follows: If the client receives a 437 (Allocation Mismatch) error response to its re= quest to refresh the allocation, it should consider the allocation no longe= r exists. If the client receives a 438 (Stale Nonce) error to its request t= o refresh the allocation, it should reattempt the request with the new nonce value. Good works for me. R. Section 11.5: When the server receives an ICMP packet, the server verifies that the type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet. It also verifies that the IP packet in the ICMP packet payload contains a UDP header. If either of these conditions fail, then the ICMP packet is silently dropped. Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter Problem are for ICMPv4? I don't get the above comment, please explain the question with an example. So if a server receives an ICMP for sent packet with ICMPv4 type 12 (Parameter Problem) then that is relayed to the client according to this te= xt. But if the server sent a packet with IPv6 towards the peer and receives an ICMPv6 message with Type 4 (Parameter Problem) that is not relayed to the client. Why this discrepancy? Thanks, got the comment. ICMPv4 and ICMPv6 error message (Parameter problem= ) need not be relayed back to the client because IPv6 extension header and = IPv4 option set in the packet from the client will not be relayed to the pe= er (Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#secti= on-14 and https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#section-13= .2). Removed ICMPv4 12 type. Added the following lines to Section 16.3 to = convey the MTU of the next-hop link: Error Data: This field size is 4 bytes long. If the ICMPv6 type is 2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination Unreachable) and Code is 4 (fragmentation needed and DF set), the Error Data field will be set to the Maximum Transmission Unit of the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of [RFC1191]). For other ICMPv6 types and ICMPv4 types and codes, Error Data field MUST be set to zero. Thanks, that clarification. Issue resolved. U. Section 13. 1,2,3: For both preferred and alternate behavior, the DONT-FRAGMENT attribute MUST be ignored by the server. I don't understand why just because one performs v4<->v6 or v6 to v4 translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT attribute. If the client has request to not fragment and the server is unable to do that when forwarding to the peer it needs to generate an ICMP attribute response saying the packet is to big. Otherwise the relay breaks the Path MTU discovery mechanisms. TURNbis is using the translation algorithms specified in RFC7915. [a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header to = not fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#section-4= ), DON'T-FRAGMENT attribute can be ignored. [b] For IPv6 to IPv4: The translation algorithm in https://tools.ietf.org/html/rfc7915#section-5 is used. If the IPv6 endpoin= t wants to discover the path MTU, it will send IPv6 packets without Fragment header and DON'T-FRAGMENT attribute can be ignored. [c] For IPv6 to IPv6: If the IPv6 endpoint wants to discover the path MTU, = it will send IPv6 packets without Fragment header and DON'T-FRAGMENT attribute can be ignored. Please note ignoring the DONT-FRAGMENT attribute is picked from https://tools.ietf.org/html/rfc6156#section-8 and discussed in the BEHAVE W= G https://mailarchive.ietf.org/arch/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc. Thanks for the clarification on the context. I should have read Section 4 of 7915. Then I would have likely gotten the implication that the IP head= er DF or Fragmentation header impacts how things are working. However, I find the reasoning behind this choice very strange. I don't see = how you can implement a TURN server that does IPv4 <->IPv6, or IPv6 relaying without having privileged access and where it reads the raw headers. An implementation based on UDP sockets will not be able to do the right thing here to my understanding. However, it could follow the DONT-FRAGMENT attribute to instructing the sending using the Socket to do the right thing= . As per the discussion in BEHAVE WG, it seems possible to set and get variou= s IP header fields using sockets, see https://mailarchive.ietf.org/arch/msg= /behave/j6FfzgVLuSeHfOWz9zRO5iPCp98 and https://mailarchive.ietf.org/arch/m= sg/behave/3I-DvtVf_4cGcDnIktsWNEtfIYM. I think there are two directions we can proceed in here. 1. Redefine this text to enable usage of DONT-FRAGMENT I prefer not to change the behavior discussed and finalized for RFC6156 in = BEHAVE WG. or 2. Clarify the scope and implications of Unpriviliged TURN Server doing translation For the second option I think there are several aspects that I like to see addressed: 2a: Update the sentence I quoted for this issue to make it clear that you= are relying solely on IPv4 DF and IPv6 Fragmentation Header to control the fragmentation. Added the following line to Packet Translations (Section 13.6). The TURN server solely relies on the DF bit in the IPv4 header and Fragment= ation header in IPv6 header to handle fragmentation and does not rely on th= e DONT-FRAGMENT attribute. Thanks, that clarifies that aspect. 2b: Clarify that Unpriviliged TURN Severs that do IPv4<-> IPv6 translatio= n will not handle fragmentation well. And include a point to the last paragraph of Section 2.7 and the use of DONT-FRAGMENT In Allocate requests to determine support and that these needs to be rejected by such a server. Depending on the OS, Unprivileged TURN Severs may or may not handle fragmen= tation (i.e. have access to DF bit). I will add the following line: If the TURN server carrying out packet translation from IPv4-to-IPv6 cannot= get the Don't Fragment (DF) bit in the IPv4 header, it MUST reject the All= ocate request with DONT-FRAGMENT attribute. This is also good. Think these two changs resolve the issue. By the way, there must be a typo with a "not" that shouldn't be in this paragraph in Section 4 of 7915: When the IPv4 sender does not set the DF bit, the translator MUST NOT include the Fragment Header for the non-fragmented IPv6 packets. To me it make sense for a IPv4->IPv6 translation where the IPv4 has DF=3DTR= UE to not include the fragmentation header, do you agree? https://tools.ietf.org/html/rfc7915#section-4.1 says to include the fragmen= t header only when IPv4 header has DF=3D0 and the packet size exceeds the M= TU. Okay, I think I understand the text and that it is not a real issue. X. Section 14: How are these IP level fields handled when the transport is TCP or TLS/TCP? There there are not necessary a one to one mapping between datagrams and TCP packets. And if there are no support then there are need for clarification of behaviors when using TCP based transport. Section 14 already clarifies that the descriptions in this section do not a= pply to TURN messages sent over TCP or TLS transport from the server to the client. Yes you are right. What are the recommendations for how to set the fields when the Channel message or Send Indication arrives over TCP/(TLS) to the server? To me the basis is the alternative behavior with t= he exception for the DF bit. However, behaviors for datagrams orignated by the server and delivered to the server over non datagram transport will need to have recommendations also for IPv6. I am not aware of any standard 1:1 mapping of IP level fields between UDP a= nd TCP, https://tools.ietf.org/html/rfc5766#section-12 does not define the= behavior to set the fields, the topic was discussed in BEHAVE WG https://m= ailarchive.ietf.org/arch/msg/behave/QBZaYgk-x5lZNFpE4qCLiztcg8Y and the dec= ision was to focus only on UDP to UDP case. What specific change are you p= roposing in this Section ? So I am not asking for a 1:1 mapping. What I see as missing is the definiti= on of how shall be set in UDP packets sent out from the TURN server, and ho= w to deal with any information in the incoming packets. I think this is som= ething that should have recommendations as not being obvious for everyone, = but at the same time such a description is not a huge task to define. For UDP packets generated based on Channel or Send Indications arriving at = the TURN server over a TCP Transport I think the following should be done. = Note, this a rough sketch, some adjustment of the language should be done = and formatted like the other options. TTL: Set to default outgoing value. DSCP: Set to value used by TCP connection, unless the server implements a r= emarker. Note, the TCP connection can only use a single DSCP code point so = inter flow differentiation is not possible, see Section 5.1 of RFC 7657. ECN: No mechanism is defined to indicate what ECN value should be used for = outgoing UDP packets for an allocations, therefore the ECN field shall be s= et to Not ECT (=3D0b00). Flow Label: [As discussed earlier based on the resulting UDP flow]. IPv4 Fragmentation: When the server sends a packet to a peer in response to a Send indication containing the DONT-FRAGMENT attribute, then set the DF bit in the outgoing IP header to 1. In all other cases when sending an outgoing packet containing application data (e.g., Data indication, ChannelData message, or DONT-FRAGMENT attribute not included in the Send indication), set the= DF bit in the outgoing IP header to 0. IPv6 Fragmentation: Independent if the TCP traffic arrives over IPv4 or IPv6 the fra= gmentation settings for outgoing IPv6 UDP packets will have to follow what= is defined for IPv4 to IPv6 translation and ignore the DF bit in incoming = packets, and interpret the presence of the DONT-FRAGMENT attribute as DF=3D= 1 in incoming packet, and for all other cases consider DF=3D0 to apply. IPv4 Options Preferred Behavior: The outgoing packet is sent without any IPv4 options. IPv6 Extensions Headers: Set per default for originated IPv6 packets. On Reception of UDP Packets If TTL=3D0 then drop packet, else ignore. DSCP: Ignore, the DSCP value for the Server to Client direction of the TCP = connection should be based on the value used for the client to server. ECN: Ignore. Higher layer protocols attempting to use ECN will not receive = any ECN signal and thus sender should stop sending ECT packets if sent. Flow Label: Ignore, the TCP connection has its own that is related to peer = to server flow. Fragmentation: Any fragmented packets are reassembled in server and then forwarded to the = client over the TCP connection. ICMP messages resulting from sent UDP packets, MUST be forward to client us= ing TURN's mechanism for relevant ICMP types. IPv4 Options are processed by server if possible, else ignored IPv6 Extension headers are processed by server if possible as intended endp= oint, else ignored. Y. Section 16.4. DATA The DATA attribute is present in all Send and Data indications. The value portion of this attribute is variable length and consists of the application data (that is, the data that would immediately follow the UDP header if the data was been sent directly between the client and the peer). If the length of this attribute is not a multiple of 4, then padding must be added after this attribute. Can you please clarify if one would get all the remaining bytes of the IP packet payload or only the number of bytes the UDP length field indicates ? The reason I ask is that there is possibility that there are a discrepancy between these fields, something the proposal for an experimental specification for UDP options attempt to utilize. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ Note, I only want you to clarify what is actually included. I would assume using the UDP length field makes sense in this case. The application data does not include the options discussed in draft-ietf- tsvwg-udp-options. Please clarify the specific update you are looking in this section. My intention here was not to bring in UDP options, only to ensure that the specification text is clear. As UDP options draft points out there could be= a discrepancy between the UDP length and IP length. Thus, I think there is a = point to make it clear that the data includes UDP length -8 bytes of UDP payload. Possible include a informative reference for why there might be a discrepan= cy. The data only includes the application data, and the length of the attribut= e is also based on the application data, and I don't see any discrepancy in= the client to determine the length of the application data. To avoid any future confusion if UDP options gets deployed I think this doc= ument can clarify that the DATA part is what is defined as UDP user data in= the below figure, i.e. the UDP length field - UDP header length amount of = data after the UDP header in the IP packet such that the surplus area never= is included. IP transport payload <-------------------------------------------------> +--------+---------+----------------------+------------------+ | IP Hdr | UDP Hdr | UDP user data | surplus area | +--------+---------+----------------------+------------------+ <------------------------------> UDP Length Figure 3 IP transport payload vs. UDP Length Note, this is to my understanding what is called UDP user data is what the = current OS implementations will give you if you use their interfaces, but i= f the TURN Server is implemented using RAW IP packets this nuance may be mi= ssed. AI. DTLS Cipher Suits Am I understanding it correct that the definition of what DTLS cipher suit that a TURN Server currently is to support is the ones in RFC 7525 ? No, the cipher suites and (D)TLS profile is discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3 and it follows the recommendations in RFC7525. Ahaa, of course. But, maybe an explicit reference to STUNbis in section 2.1 that the transports for TURN and STUN messages are defined there? In that case, I think the wording is a bit weak as the only reference I find are in Section 2.1: If (D)TLS transport is used between the TURN client and the TURN server, the guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. RFC7525 provides various recommendations to avoid attacks on (D)TLS. It was really the text in STUNbis that I was looking for. Okay, modified the above line as follows: If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] and the guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. Looks good to me. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB2522C1819EA5B98774BA0869953E0HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Cutting away what appear settled.

On 2019-04-18 10:20, Konda, Tirumaleswar Red= dy wrote:

 error packet, the server also relay=
s certain layer 3/4 header fields from the=0A=

ICMP header to the client. When the =
client sends a packet to the server, the=0A=
server relays the transport protocol data from the packet to the appropriat=
e=0A=
peer using the relayed transport address as the source.=0A=
=0A=
"appropriate" appears wrong. The peer is the one the client have =
configure for=0A=
the allocation. So I think a more direct language can be used.=0A=

"appropriate peer" is used=
 at several places in https://tools.ietf.org/html/rfc5766.

There is now a single occurrence of it in this document. And in that con= text, it appears that using "intended" or "addressed" p= eer would work better and be clearer. 


=0A=

Othewise fine with me.=0A=
=0A=
=0A=
H. Section 5: 
   If the server requires requests t=
o be=0A=
   authenticated, then the server's administrator MUST choose a realm=0A=
   value that will uniquely identify the username and password=0A=
   combination that the client must use, even if the client uses=0A=
   multiple servers under different administrations.=0A=
=0A=
Just to verify, TURN does not allow a single server address to host=0A=
multiple realms do it? Each Realm needs its own unique server transport=0A=

address?=0A=

No, I don't see any such restriction=
 in TURN.  For example, in an Enterprise=0A=

network with multiple realms, the TU=
RN server based on the client subnet can=0A=
choose the realm.=0A=
=0A=
I think this is a not expressed assumption, that realm determination may be=
=0A=
done based on source IP address of the client's request. That is an assumpt=
ion=0A=
that is not generally applicable, but can work for some combinations of rea=
lms.=0A=
For example an server that has a REALM for an WebRTC service that is=0A=
intended to have no restrictions can't be co-located with anything that has=
 a=0A=
small scope as that can lead to selection of the wrong realm.=0A=

Yes, both assumptions are deployment=
 specific.  Enterprise TURN servers are discussed in https://tools.iet=
f.org/html/rfc7478. =0A=
Username and password is not the only way to perform mutual authentication =
b/w the TURN client and server, https://tools.ietf.org/html/rfc7635 discusses using OAuth and is used by WebRTC (see https://w3c.github.io/=
webrtc-pc/). =0A=
=0A=

What do you think is the best option=
 here. Simple document that there are no=0A=
mechanism in the protocol for the client to indicate which REALM it thinks =
it=0A=
belongs to and state that the basic mechanism is using different server por=
ts=0A=
for different realms. Or to write even more where the possibility in source=
 IP=0A=
address identification of realm is described but also its limitations?=0A=

If different server ports are used f=
or different realms, the client needs to learn the server ports and manual =
configuration may not be a suitable option. The public TURN server could ha=
ve different domain names for different realms, and the client can discover=
 the server port for the TURN server domain using S-NAPTR.  I don't think t=
he draft should discuss deployment specific solutions.

So if I understand this correctly your stating that it is up to the serv= er implementation to figure out what the realm on what ever information is = gets based on the request. From a client implementation perspective it appe= ars less clear if anything the client will affect the realm response it will receive.

I don't think this Section 18 quote is not clear either.

   Following the procedures of the long-term credential mechan= ism of
   STUN [I-D.ietf-tram-stunbis], the server includes an ERROR-COD= E
   attribute with a value of 401 (Unauthorized), a REALM attribut= e that
   specifies the authentication realm used by the server (in this= case,
   the server's domain "example.com"), and a nonce valu= e in a NONCE
   attribute.

So I will not persist on this, but I would appreciate some indications o= n that the server may do more than simply have a single realm for a given s= erver transport address. 




L. Section 7.1:=0A=
=0A=
  The client then picks a transport protocol to use between the client=0A=
   and the server.  The transport protocol MUST be one of UDP, TCP, TLS-=0A=
   over-TCP or DTLS-over-UDP.=0A=
=0A=
I find it strange that this indicates that one should pick the=0A=
transport protocol to use client to server without considering the=0A=
server capabilities. Especially as the client configuration or server=0A=
discovery procedures will indicate transport protocol support.=0A=

The server may support more than one=
 transport protocol.=0A=

Sorry, should have been clearer. Sho=
uld there be any references to how the=0A=
client can determine the servers capabilities? You have recommendations=0A=
about using UDP and a pointer to Section 2.1 for some discussion of the cho=
ices.=0A=
So that covers giving some guidance to the protocol choice.=0A=

I have updated the text as follows:=
=0A=
=0A=
   The client then picks a transport protocol to use between the client=0A=
   and the server based on the transport protocols supported by the=0A=
   server.  The transport protocol MUST be one of UDP, TCP, TLS- over-TCP o=
r DTLS-over-UDP.=0A=
   Since this specification only allows UDP between the server=0A=
   and the peers, it is RECOMMENDED that the client pick UDP unless it=0A=
   has a reason to use a different transport.  One reason to pick a=0A=
   different transport would be that the client believes, either through=0A=
   configuration or discovery or by experiment, that it is unable to=0A=
   contact any TURN server using UDP.  See Section 2.1 for more=0A=
   discussion.=0A=
=0A=
The subsequent paragraph in Section 7.1 discusses use of [RFC8155] to disco=
very TURN server, and use of [RFC5928] and [RFC7350] to discover server tra=
nsport capabilities.

I still think the MUST is unnecessary and problematic. The problem is th= at it first of all prevents any future extension to the transport protocols= be used. Isn't the point, that the client picks one of the protocols it su= pports? Maybe remove the sentence and simply add something about "that the client supports" in the= prior sentence. 

=0A=
=0A=

Also shouldn't this paragraph come b=
efore the previous one. I.e. that you first=0A=
must pick your transport protocol before you can pick a host transport addr=
ess ?=0A=

No, middle-boxes may drop UDP traffi=
c to the TURN server, and the client by experiment will identify the transp=
ort protocol permitted to the TURN server and eventually uses the =0A=
host transport address using which successful response was received from th=
e server.

Ok. 


=0A=
=0A=

=0A=

Secondly, what is the motivation for=
 the MUST in the second sentence?=0A=
This is appears to have strange interactions with any future=0A=
extensions and have no impact. A client must obvious chose a client=0A=
to server transport protocol it supports, and one that the server=0A=
supports or the client hope it will support.=0A=

https://tools.ietf.=
org/html/rfc5766#section-6.1 has the same text, I have=0A=

updated the text as follows:=0A=

The client then picks a transport pr=
otocol to use between the client and the=0A=

server based on the transport protoc=
ols supported by the server.=0A=

The TURN server MUST enable one of t=
he transport protocols, UDP, TCP, TLS-=0A=

over-TCP or DTLS-over-UDP.=0A=
=0A=
If the intention is to move the requirement to the server side for making i=
t=0A=
normative to support at least one of the 4 options listed, I think you need=
 to=0A=
rewrite it to say:=0A=
=0A=
A TURN server MUST enable at least one of the transport protocols, UDP, TCP=
,=0A=
TLS- over-TCP or DTLS-over-UDP.=0A=

The above point is already discussed=
 in Section 5 as follows:=0A=
=0A=
 To ensure interoperability, a TURN server MUST support the use of UDP=0A=
 transport between the client and the server, and SHOULD support the=0A=
 use of TCP, TLS-over-TCP and DTLS-over-UDP transports.


So, this sentence lays out the implementation requirement on the server = side and is very reasonable and likely needed. 



=0A=
=0A=

=0A=
=0A=

M. Section 7.1:=0A=
=0A=
   The client also picks a server transport address, which SHOULD be=0A=
   done as follows.  The client uses one or more procedures described in=0A=
   [RFC8155] to discover a TURN server and uses the TURN server=0A=
   resolution mechanism defined in [RFC5928] to get a list of server=0A=
   transport addresses that can be tried to create a TURN allocation.=0A=
=0A=
1) So RFC 8155 states that it has no recommendation on server=0A=
selection, nor on how to related local configuration to any auto-discovery=
=0A=

servers.=0A=

To me it appears that the protocol u=
tilizing TURN should consider=0A=
what makes sense in their deployments. Thus, does the need for such=0A=
consideration needs to be highlighted somewhere in this specification.=0A=

https://tools.ietf.or=
g/html/rfc8155#section-3 discusses using auto-discovery in=0A=

the absence of local configuration o=
r if the local configuration does not work.=0A=
https://tools.ietf.org/html/rfc8155#section-9 explains t=
he mechanisms to=0A=
authenticate the discovered TURN server.=0A=

I am not sure about the additional c=
onsiderations you are looking in this=0A=

specification.=0A=
=0A=
Let me attempt to formulate the question in another way. As the Discovery=
=0A=
procedure documented in RFC 8155 does not mandate any specific order or=0A=
even what mechanisms are actually used / supported, then did the WG conside=
r=0A=
to make either a stricter recommendation or some other considerations to=0A=
better ensure that TURN clients can discover TURN servers?=0A=
=0A=
It is fine to say no.=0A=

No, it was left to implementation. I=
f local configuration does not work for a TURN client, RFC8155 explains per=
forming all the discovery mechanisms to find the TURN server.


Okay, then lets drop this point. 



O. Section 7.1:=0A=
=0A=
   If the client wishes to obtain a relayed transport address of a=0A=
   specific address type then it includes a REQUESTED-ADDRESS-FAMILY=0A=
   attribute in the request.=0A=
=0A=
I don't find anything describing what the default behavior is if one=0A=
doesn't include the attribute, but the TURN server supports multiple addres=
s=0A=

families.=0A=

I see that bullet 7 in Section 7.2 i=
ndicates that IPv4 is default.=0A=
Should the text in 7.1 be explicit about this default?=0A=

The text in Section 7.1 is added for=
 TURN clients not supporting TURNbis=0A=

specification to provide backward co=
mpatibility.=0A=
=0A=
But if I understand this correctly, the legacy way is to not include the=0A=
REQUESTED-ADDRESS-FAMILY attribute for an IPv4 address. =0A=

Yes. =0A=
=0A=

Thus, shouldn't a=0A=
sentence be added after the above to state that if the client wants an=0A=
IPv4 address it should skip using REQUESTED-ADDRESS-FAMILY attribute to=0A=
enable legacy interoperability, or do I missunderstand?=0A=

REQUEST-ADDRESS-FAMILY attribute is =
initially defined in https://tools.ietf.org/html/rfc6156 as compre=
hension-required attribute. If the legacy server does not understand this a=
ttribute, the request will be rejected (420 (Unknown Attribute), and if the=
 client wants IPv4 relayed transport address, the client will have to retry=
 the request without the REQUEST-ADDRESS-FAMILY attribute.


Okay, then I think this issue can be closed. 


 =0A=
=0A=

=0A=

Q. Section 8.3:=0A=
=0A=
   If the client receives a success response to its Refresh request with=0A=
   a non-zero lifetime, it updates its copy of the allocation data=0A=
   structure with the time-to-expiry value contained in the response.=0A=
=0A=
   If the client receives a 437 (Allocation Mismatch) error response to=0A=
   a request to delete the allocation, then the allocation no longer=0A=
   exists and it should consider its request as having effectively=0A=
   succeeded.=0A=
=0A=
So there are no considerations for the client if it receives an error=0A=
response to a refresh request when Lifetime was non-zero?=0A=
=0A=
I am bit surprised by that. I assume that there are certain cases=0A=
when the request could be resent, and others where the meaning is=0A=
that the allocation is gone.=0A=

TURNbis does not update the refresh =
behavior already defined in=0A=

https://tools.ietf.=
org/html/rfc5766#section-7.3.  I will add the following line:=0A=

If the client receives an error resp=
onse to its request to refresh the allocation,=0A=

it should consider the allocation no=
 longer exists.=0A=
=0A=
Isn't that over simplifying cases where one attempts to refresh an allocati=
on=0A=
and could actually handle the issue. For example an error response to the c=
lient=0A=
of 438 (Stale Nonce)  where the client can retry the request with the new=
=0A=
Nonce. I also wonder if request time out as well as 400 (if it can figure o=
ut what=0A=
the issue was) could be re-attempted prior to allocation expires. But at le=
at hte=0A=
438 appears to indicate a situation where the client should not give up, an=
d=0A=
thus should have some text here.=0A=

Good point, Modified the above line =
follows:=0A=
If the client receives a 437 (Allocation Mismatch) error response to its re=
quest to refresh the allocation, it should consider the allocation no longe=
r exists. If the client receives a 438 (Stale Nonce) error to its request t=
o refresh the allocation, =0A=
it should reattempt the request with the new nonce value.

Good works for me. 


=0A=
=0A=

R. Section 11.5:=0A=
=0A=
   When the server receives an ICMP packet, the server verifies that the=0A=
   type is either 3, 11 or 12 for an ICMPv4 [RFC0792] packet or either=0A=
   1, 2, or 3 for an ICMPv6 [RFC4443] packet.  It also verifies that the=0A=
   IP packet in the ICMP packet payload contains a UDP header.  If=0A=
   either of these conditions fail, then the ICMP packet is silently=0A=
   dropped.=0A=
=0A=
Why is not ICMPv6 Type 4 (Parameter Problem) included when Parameter=0A=
Problem are for ICMPv4?=0A=

I don't get the above comment, pleas=
e explain the question with an example.=0A=

So if a server receives an ICMP for =
sent packet with ICMPv4 type 12=0A=
(Parameter Problem) then that is relayed to the client according to this te=
xt.=0A=
But if the server sent a packet with IPv6 towards the peer and receives an=
=0A=
ICMPv6 message with Type 4 (Parameter Problem) that is not relayed to the=
=0A=
client. Why this discrepancy?=0A=

Thanks, got the comment. ICMPv4 and =
ICMPv6 error message (Parameter problem) need not be relayed back to the cl=
ient because IPv6 extension header and IPv4 option set in the packet from t=
he client will not be relayed to the peer (Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-23#sectio=
n-14 and https://tools.ietf.org/ht=
ml/draft-ietf-tram-turnbis-23#section-13.2).  Removed ICMPv4 12 type. A=
dded the following lines to Section 16.3 to convey the MTU of the next-hop =
link:=0A=
=0A=
   Error Data:  This field size is 4 bytes long.  If the ICMPv6 type is=0A=
      2 (Packet Too Big Message) or ICMPv4 type is 3 ( Destination=0A=
      Unreachable) and Code is 4 (fragmentation needed and DF set), the=0A=
      Error Data field will be set to the Maximum Transmission Unit of=0A=
      the next-hop link (Section 3.2 of [RFC4443]) and Section 4 of=0A=
      [RFC1191]).  For other ICMPv6 types and ICMPv4 types and codes, =0A=
     Error Data field MUST be set to zero.


Thanks, that clarification. Issue resolved. 



=0A=

U. Section 13. 1,2,3:=0A=
=0A=
      For both preferred and alternate behavior, the DONT-FRAGMENT=0A=
      attribute MUST be ignored by the server.=0A=
=0A=
I don't understand why just because one performs v4<->v6 or v6 to v4=
=0A=
translation or v6 to v6 relaying now can ignore the DONT-FRAGEMENT=0A=
attribute. If the client has request to not fragment and the server=0A=
is unable to do that when forwarding to the peer it needs to generate=0A=
an ICMP attribute response saying the packet is to big. Otherwise the=0A=
relay breaks the Path MTU discovery mechanisms.=0A=

TURNbis is using the translation alg=
orithms specified in RFC7915.=0A=
=0A=
[a] For IPv4 to IPv6: The translator uses the DF bit in the IPv4 header to =
not=0A=

fragment the IPv6 packet (see https://tools.ietf.org/html/rfc7915#section-4),=0A=
DON'T-FRAGMENT attribute can be ignored.=0A=

[b] For IPv6 to IPv4: The translatio=
n algorithm in=0A=

https://tools.ietf.or=
g/html/rfc7915#section-5 is used.  If the IPv6 endpoint wants=0A=
to discover the path MTU, it will send IPv6 packets without Fragment header=
=0A=
and DON'T-FRAGMENT attribute can be ignored.=0A=

[c] For IPv6 to IPv6: If the IPv6 en=
dpoint wants to discover the path MTU, it=0A=

will send IPv6 packets without Fragm=
ent header and DON'T-FRAGMENT=0A=
attribute can be ignored.=0A=

Please note ignoring the DONT-FRAGME=
NT attribute is picked from=0A=

https://tools.ietf.or=
g/html/rfc6156#section-8 and discussed in the BEHAVE WG=0A=
https://mailarchive.ietf.org/arch=
/msg/behave/oabu0VtUMBE-X3-vhgjdSFCboxc.=0A=
=0A=
Thanks for the clarification on the context. I should have read Section=0A=
4 of 7915. Then I would have likely gotten the implication that the IP head=
er DF=0A=
or Fragmentation header impacts how things are working.=0A=
=0A=
However, I find the reasoning behind this choice very strange. I don't see =
how=0A=
you can implement a TURN server that does IPv4 <->IPv6, or IPv6 relay=
ing=0A=
without having privileged access and where it reads the raw headers. An=0A=
implementation based on UDP sockets will not be able to do the right thing=
=0A=
here to my understanding. However, it could follow the DONT-FRAGMENT=0A=
attribute to instructing the sending using the Socket to do the right thing=
.=0A=

As per the discussion in BEHAVE WG, =
it seems possible to set and get various IP header fields using sockets, se=
e https://mailarchive.ietf.org/ar=
ch/msg/behave/j6FfzgVLuSeHfOWz9zRO5iPCp98 and https://mailarchive.ietf.org/arch/msg/behave/3I-DvtVf_4cGc=
DnIktsWNEtfIYM. =0A=
=0A=

I think there are two directions we =
can proceed in here.=0A=
=0A=
1. Redefine this text to enable usage of DONT-FRAGMENT=0A=

I prefer not to change the behavior =
discussed and finalized for RFC6156 in BEHAVE WG.=0A=
=0A=

or=0A=
=0A=
2. Clarify the scope and implications of Unpriviliged TURN Server doing=0A=
translation=0A=
=0A=
=0A=
For the second option I think there are several aspects that I like to see=
=0A=
addressed:=0A=
=0A=
  2a: Update the sentence I quoted for this issue to make it clear that you=
 are=0A=
relying solely on IPv4 DF and IPv6 Fragmentation Header to control the=0A=
fragmentation.=0A=

Added the following line to Packet T=
ranslations (Section 13.6).=0A=
The TURN server solely relies on the DF bit in the IPv4 header and Fragment=
ation header in IPv6 header to handle fragmentation and does not rely on th=
e DONT-FRAGMENT attribute.


Thanks, that clarifies that aspect. 

=0A=
=0A=

  2b: Clarify that Unpriviliged TURN=
 Severs that do IPv4<-> IPv6 translation will=0A=
not handle fragmentation well. And include a point to the last paragraph of=
=0A=
Section 2.7 and the use of DONT-FRAGMENT In Allocate requests to determine=
=0A=
support and that these needs to be rejected by such a server.=0A=

Depending on the OS, Unprivileged TU=
RN Severs may or may not handle fragmentation (i.e. have access to DF bit).=
  I will add the following line: =0A=
If the TURN server carrying out packet translation from IPv4-to-IPv6 cannot=
 get the Don't Fragment (DF) bit in the IPv4 header, it MUST reject the All=
ocate request with DONT-FRAGMENT attribute.

This is also good. Think these two changs resolve the issue. 

=0A=
=0A=

By the way, there must be a typo wit=
h a "not" that shouldn't be in this=0A=
paragraph in Section 4 of 7915:=0A=
=0A=
   When the IPv4 sender does not set the DF bit, the translator MUST NOT=0A=
   include the Fragment Header for the non-fragmented IPv6 packets.=0A=
=0A=
To me it make sense for a IPv4->IPv6 translation where the IPv4 has DF=
=3DTRUE=0A=
to not include the fragmentation header, do you agree?=0A=

https://tools.ietf.=
org/html/rfc7915#section-4.1 says to include the fragment header only w=
hen IPv4 header has DF=3D0 and the packet size exceeds the MTU.=0A=

Okay, I think I understand the text and that it is not a real issue. 


=0A=
=0A=

=0A=
=0A=

X. Section 14:=0A=
=0A=
How are these IP level fields handled when the transport is TCP or TLS/TCP?=
=0A=
There there are not necessary a one to one mapping between datagrams=0A=
and TCP packets. And if there are no support then there are need for=0A=
clarification of behaviors when using TCP based transport.=0A=

Section 14 already clarifies that th=
e descriptions in this section do not apply to=0A=

TURN messages sent over TCP or TLS t=
ransport from the server to the client.=0A=
=0A=
Yes you are right. What are the recommendations for how to set the fields=
=0A=
when the Channel message or Send Indication arrives over=0A=
TCP/(TLS) to the server? To me the basis is the alternative behavior with t=
he=0A=
exception for the DF bit. However, behaviors for datagrams orignated by the=
=0A=
server and delivered to the server over non datagram transport will need to=
=0A=
have recommendations also for IPv6.=0A=

I am not aware of any standard 1:1 m=
apping of IP level fields between UDP and TCP,  https://too=
ls.ietf.org/html/rfc5766#section-12 does not define the behavior to set=
 the fields, the topic was discussed in BEHAVE WG https://mailarchive.ietf.org/arch/msg/behave/QBZaYgk-x5lZN=
FpE4qCLiztcg8Y and the decision was to focus only on UDP to UDP case.  =
What specific change are you proposing in this Section ?

So I am not asking for a 1:1 mapping. What I see as missing is the defin= ition of how shall be set in UDP packets sent out from the TURN server, and= how to deal with any information in the incoming packets. I think this is = something that should have recommendations as not being obvious for everyone, but at the same time such a description= is not a huge task to define.

For UDP packets generated based on Channel or Send Indications arriving = at the TURN server over a TCP Transport I think the following should be don= e.  Note, this a rough sketch, some adjustment of the language should = be done and formatted like the other options.

TTL: Set to default outgoing value.

DSCP: Set to value used by TCP connection, unless the server implements = a remarker. Note, the TCP connection can only use a single DSCP code point = so inter flow differentiation is not possible, see Section 5.1 of RFC 7657.

ECN: No mechanism is defined to indicate what ECN value should be used f= or outgoing UDP packets for an allocations, therefore the ECN field shall b= e set to Not ECT (=3D0b00).

Flow Label:

     [As discussed earlier based on the resulting UD= P flow].

IPv4 Fragmentation: 

      When the server sends a packet to a peer in=0A=
      response to a Send indication containing the DONT-FRAGMENT=0A=
      attribute, then set the DF bit in the outgoing IP header to 1.  In=0A=
      all other cases when sending an outgoing packet containing=0A=
      application data (e.g., Data indication, ChannelData message, or=0A=
      DONT-FRAGMENT attribute not included in the Send indication), set the=
 DF bit=0A=
      in the outgoing IP header to 0. =0A=

IPv6 Fragmentation:

           Independent= if the TCP traffic arrives over IPv4 or IPv6 the fragmentation settings fo= r outgoing  IPv6 UDP packets will have to follow what is defined for I= Pv4 to IPv6 translation and ignore the DF bit in incoming packets, and inte= rpret the presence of the DONT-FRAGMENT attribute as DF=3D1 in incoming packet, and for all o= ther cases consider DF=3D0 to apply.

 

 IPv4 Options=0A=
=0A=
      Preferred Behavior: The outgoing packet is sent without any IPv4=0A=
      options.=0A=
=0A=
=0A=
IPv6 Extensions Headers:=0A=
=0A=
      Set per default for originated IPv6 packets. =0A=
=0A=
On Reception of UDP Packets=0A=
=0A=
If TTL=3D0 then drop packet, else ignore. =0A=
=0A=
DSCP: Ignore, the DSCP value for the Server to Client direction of the TCP =
connection should be based on the value =0A=
used for the client to server. =0A=
=0A=
ECN: Ignore. Higher layer protocols attempting to use ECN will not receive =
any ECN signal and thus sender =0A=
should stop sending ECT packets if sent. =0A=
=0A=
Flow Label: Ignore, the TCP connection has its own that is related to peer =
to server flow. =0A=
=0A=
Fragmentation: =0A=
=0A=
Any fragmented packets are reassembled in server and then forwarded to the =
client over the TCP connection. =0A=
ICMP messages resulting from sent UDP packets, MUST be forward to client us=
ing TURN's mechanism for relevant ICMP types.=0A=
=0A=
IPv4 Options are processed by server if possible, else ignored=0A=
IPv6 Extension headers are processed by server if possible as intended endp=
oint, else ignored. =0A=
=0A=
=0A=
=0A=

=0A=
=0A=

Y. Section 16.4.  DATA=0A=
=0A=
   The DATA attribute is present in all Send and Data indications.  The=0A=
   value portion of this attribute is variable length and consists of=0A=
   the application data (that is, the data that would immediately follow=0A=
   the UDP header if the data was been sent directly between the client=0A=
   and the peer).  If the length of this attribute is not a multiple of=0A=
   4, then padding must be added after this attribute.=0A=
=0A=
Can you please clarify if one would get all the remaining bytes of=0A=
the IP packet payload or only the number of bytes the UDP length field=0A=

indicates ?=0A=

The reason I ask is that there is po=
ssibility that there are a=0A=
discrepancy between these fields, something the proposal for an=0A=
experimental specification for UDP options attempt to utilize.=0A=
https://datatracker.ietf.org/doc/draft-ietf=
-tsvwg-udp-options/=0A=
=0A=
Note, I only want you to clarify what is actually included. I would=0A=
assume using the UDP length field makes sense in this case.=0A=

The application data does not includ=
e the options discussed in draft-ietf-=0A=

tsvwg-udp-options.=0A=

Please clarify the specific update y=
ou are looking in this section.=0A=

My intention here was not to bring i=
n UDP options, only to ensure that the=0A=
specification text is clear. As UDP options draft points out there could be=
 a=0A=
discrepancy between the UDP length and IP length. Thus, I think there is a =
point=0A=
to make it clear that the data includes UDP length -8 bytes of UDP payload.=
=0A=
Possible include a informative reference for why there might be a discrepan=
cy.=0A=

The data only includes the applicati=
on data, and the length of the attribute is also based on the application d=
ata, and I don't see any discrepancy in the client to determine the length =
of the application data.

To avoid any future confusion if UDP options gets deployed I think this = document can clarify that the DATA part is what is defined as UDP user data= in the below figure, i.e. the UDP length field - UDP header length amount = of data after the UDP header in the IP packet such that the surplus area never is included. 

                             IP transport payload=0A=
                <------------------------------------------------->=
=0A=
      +--------+---------+----------------------+----------=
--------+=0A=
      | IP Hdr | UDP Hdr |     UDP user data    |   surplus area   |=0A=
      +--------+---------+----------------------+----------=
--------+=0A=
                <------------------------------>=0A=
                           UDP Length=0A=
=0A=
               Figure 3 IP transport payload vs. UDP Length=0A=

Note, this is to my understanding what is called UDP user data is what t= he current OS implementations will give you if you use their interfaces, bu= t if the TURN Server is implemented using RAW IP packets this nuance may be= missed. 

=0A=
=0A=
=0A=

AI. DTLS Cipher Suits=0A=
=0A=
Am I understanding it correct that the definition of what DTLS cipher=0A=
suit that a TURN Server currently is to support is the ones in RFC 7525 ?=
=0A=

No, the cipher suites and (D)TLS pro=
file is discussed in=0A=

https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3 =
and it=0A=
follows the recommendations in RFC7525.=0A=
=0A=
Ahaa, of course. But, maybe an explicit reference to STUNbis in section=0A=
2.1 that the transports for TURN and STUN messages are defined there?=0A=
=0A=

In that case, I think the wording is=
 a bit weak as the only reference=0A=
I find are in Section 2.1:=0A=
=0A=
If (D)TLS transport is=0A=
   used between the TURN client and the TURN server, the guidance given=0A=
   in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A=

RFC7525 provides various recommendat=
ions to avoid attacks on (D)TLS.=0A=

It was really the text in STUNbis th=
at I was looking for.=0A=

Okay, modified the above line as fol=
lows:=0A=
=0A=
   If (D)TLS transport is=0A=
   used between the TURN client and the TURN server, the cipher suites=0A=
   discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] and the guidance=
=0A=
   given in [RFC7525] MUST be followed to avoid attacks on (D)TLS.=0A=
=0A=

Looks good to me. 


Cheers

=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522C1819EA5B98774BA0869953E0HE1PR0701MB2522_--


From nobody Sun Apr 28 02:46:52 2019
Return-Path: 
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C951B1200A1; Sun, 28 Apr 2019 02:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.291
X-Spam-Level: 
X-Spam-Status: No, score=-4.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U1-sj6pqk2J; Sun, 28 Apr 2019 02:46:45 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A9812004F; Sun, 28 Apr 2019 02:46:44 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1556444432; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=+ H9621+ipJ/ZLuz677gWPjvkQybG2Rtf/c48JP4I80 k=; b=gOC8rNa2d3qjlKTtlOHQjl84VTzpspbiynmzFAmYP7QO yMbQLYGtPoYSxdWrsUvY7YXEmtvWDiMeD+3VY4GdiEFfXMJxg+ XMKdrgXpjo168gXnkCciTcQSQG8mNMsA9OvVvGJ9e6ixvnJxzC yIbFwkKWXKwFP9zN0V43h8+Wjng=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0bba_2e72_7ff72e8b_6963_429b_9ed1_7c671377a2f7; Sun, 28 Apr 2019 03:40:31 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 28 Apr 2019 03:46:31 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sun, 28 Apr 2019 03:46:31 -0600
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 28 Apr 2019 03:46:30 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2935.namprd16.prod.outlook.com (20.178.235.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Sun, 28 Apr 2019 09:46:27 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.010; Sun, 28 Apr 2019 09:46:27 +0000
From: "Konda, Tirumaleswar Reddy" 
To: Magnus Westerlund , "tram@ietf.org" , "draft-ietf-tram-turnbis@ietf.org" 
Thread-Topic: [tram] AD Evaluation of draft-ietf-tram-turnbis-23
Thread-Index: AQHU6u6miufFCL2QUEG5nrdQuPpiP6ZQDE6g
Date: Sun, 28 Apr 2019 09:46:27 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; 
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9292c33f-3e8d-469e-93cf-08d6cbbe627c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2935; 
x-ms-traffictypediagnostic: BYAPR16MB2935:
x-ms-exchange-purlcount: 26
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0021920B5A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(136003)(39850400004)(15594002)(189003)(32952001)(199004)(51914003)(229853002)(2201001)(2501003)(316002)(99286004)(93886005)(7696005)(80792005)(6436002)(30864003)(97736004)(110136005)(14454004)(66066001)(86362001)(5660300002)(72206003)(966005)(476003)(53936002)(478600001)(186003)(446003)(11346002)(53546011)(52536014)(561944003)(53946003)(6506007)(8676002)(6246003)(81166006)(8936002)(54896002)(236005)(9686003)(6306002)(26005)(256004)(486006)(9326002)(76116006)(71190400001)(74316002)(71200400001)(7736002)(76176011)(55016002)(606006)(66446008)(66476007)(2906002)(14444005)(5024004)(3846002)(73956011)(68736007)(66556008)(64756008)(790700001)(33656002)(66946007)(6116002)(18074004)(25786009)(81156014)(102836004)(85282002)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2935; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: wce0DqJVn3FH1f55uYlbmRXWoOGJZgpGui5eBeE9T0wzFi+CJUfVc+wTg6QoRIllb9m7/tKgMZhLEdlIrL20kcxKu9FTnWxtE38B6noH320njGY99aaJGwY4SNGFga3Tv+CcHysd+/UK3gmlKTH2Zl13qFLXIj545EYHNlfioLuur7u+xPly9nZm6L5aEwKiGbtPtMdw9rrxxjRmkhIfsAlJjjI1w7HjvodtOtf+7TXV+WVfkrZvrpJmRiuO8diJJTll4pRjITQm7IqVc7WQ1y5y2xhr4jda9tYeBowclLp3fbLOQd4KIy8EGijYafjT7yKjQCkXoQERpPQKqCMNeUn37bxZK0RBxmQ5fjDnHMZu9WscYvIgAM8mx++HF7DMIHNaDl4L0nBJvNRlyyBpa2rwARAPLQLjOqP/HGuGKGc=
Content-Type: multipart/alternative; boundary="_000_BYAPR16MB2790F74A7D46937AD59A0363EA380BYAPR16MB2790namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9292c33f-3e8d-469e-93cf-08d6cbbe627c
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2019 09:46:27.3798 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2935
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6534> : inlines <7062> : streams <1819960> : uri <2838025>
Archived-At: 
Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Apr 2019 09:46:50 -0000

--_000_BYAPR16MB2790F74A7D46937AD59A0363EA380BYAPR16MB2790namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgTWFnbnVzLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBbVFJdDQoNCkZyb206IE1hZ251cyBXZXN0
ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpTZW50OiBGcmlkYXksIEFw
cmlsIDI2LCAyMDE5IDU6MDcgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1
bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgdHJhbUBpZXRmLm9yZzsgZHJhZnQtaWV0
Zi10cmFtLXR1cm5iaXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHJhbV0gQUQgRXZhbHVhdGlv
biBvZiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yMw0KDQoNCkNBVVRJT046IEV4dGVybmFsIGVt
YWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJl
Y29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkhpLA0KDQpDdXR0aW5nIGF3YXkgd2hhdCBh
cHBlYXIgc2V0dGxlZC4NCg0KT24gMjAxOS0wNC0xOCAxMDoyMCwgS29uZGEsIFRpcnVtYWxlc3dh
ciBSZWRkeSB3cm90ZToNCg0KDQoNCiBlcnJvciBwYWNrZXQsIHRoZSBzZXJ2ZXIgYWxzbyByZWxh
eXMgY2VydGFpbiBsYXllciAzLzQgaGVhZGVyIGZpZWxkcyBmcm9tIHRoZQ0KDQpJQ01QIGhlYWRl
ciB0byB0aGUgY2xpZW50LiBXaGVuIHRoZSBjbGllbnQgc2VuZHMgYSBwYWNrZXQgdG8gdGhlIHNl
cnZlciwgdGhlDQoNCnNlcnZlciByZWxheXMgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBkYXRhIGZy
b20gdGhlIHBhY2tldCB0byB0aGUgYXBwcm9wcmlhdGUNCg0KcGVlciB1c2luZyB0aGUgcmVsYXll
ZCB0cmFuc3BvcnQgYWRkcmVzcyBhcyB0aGUgc291cmNlLg0KDQoNCg0KImFwcHJvcHJpYXRlIiBh
cHBlYXJzIHdyb25nLiBUaGUgcGVlciBpcyB0aGUgb25lIHRoZSBjbGllbnQgaGF2ZSBjb25maWd1
cmUgZm9yDQoNCnRoZSBhbGxvY2F0aW9uLiBTbyBJIHRoaW5rIGEgbW9yZSBkaXJlY3QgbGFuZ3Vh
Z2UgY2FuIGJlIHVzZWQuDQoNCiJhcHByb3ByaWF0ZSBwZWVyIiBpcyB1c2VkIGF0IHNldmVyYWwg
cGxhY2VzIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2Lg0KDQpUaGVyZSBp
cyBub3cgYSBzaW5nbGUgb2NjdXJyZW5jZSBvZiBpdCBpbiB0aGlzIGRvY3VtZW50LiBBbmQgaW4g
dGhhdCBjb250ZXh0LCBpdCBhcHBlYXJzIHRoYXQgdXNpbmcgImludGVuZGVkIiBvciAiYWRkcmVz
c2VkIiBwZWVyIHdvdWxkIHdvcmsgYmV0dGVyIGFuZCBiZSBjbGVhcmVyLg0KDQpbVFJdIE9rYXks
IHJlcGxhY2VkIHdpdGgg4oCcaW50ZW5kZWQgcGVlcuKAnS4NCg0KDQoNCk90aGV3aXNlIGZpbmUg
d2l0aCBtZS4NCg0KDQoNCg0KSC4gU2VjdGlvbiA1Og0KDQogICBJZiB0aGUgc2VydmVyIHJlcXVp
cmVzIHJlcXVlc3RzIHRvIGJlDQoNCiAgIGF1dGhlbnRpY2F0ZWQsIHRoZW4gdGhlIHNlcnZlcidz
IGFkbWluaXN0cmF0b3IgTVVTVCBjaG9vc2UgYSByZWFsbQ0KDQogICB2YWx1ZSB0aGF0IHdpbGwg
dW5pcXVlbHkgaWRlbnRpZnkgdGhlIHVzZXJuYW1lIGFuZCBwYXNzd29yZA0KDQogICBjb21iaW5h
dGlvbiB0aGF0IHRoZSBjbGllbnQgbXVzdCB1c2UsIGV2ZW4gaWYgdGhlIGNsaWVudCB1c2VzDQoN
CiAgIG11bHRpcGxlIHNlcnZlcnMgdW5kZXIgZGlmZmVyZW50IGFkbWluaXN0cmF0aW9ucy4NCg0K
DQoNCkp1c3QgdG8gdmVyaWZ5LCBUVVJOIGRvZXMgbm90IGFsbG93IGEgc2luZ2xlIHNlcnZlciBh
ZGRyZXNzIHRvIGhvc3QNCg0KbXVsdGlwbGUgcmVhbG1zIGRvIGl0PyBFYWNoIFJlYWxtIG5lZWRz
IGl0cyBvd24gdW5pcXVlIHNlcnZlciB0cmFuc3BvcnQNCg0KYWRkcmVzcz8NCg0KTm8sIEkgZG9u
J3Qgc2VlIGFueSBzdWNoIHJlc3RyaWN0aW9uIGluIFRVUk4uICBGb3IgZXhhbXBsZSwgaW4gYW4g
RW50ZXJwcmlzZQ0KDQpuZXR3b3JrIHdpdGggbXVsdGlwbGUgcmVhbG1zLCB0aGUgVFVSTiBzZXJ2
ZXIgYmFzZWQgb24gdGhlIGNsaWVudCBzdWJuZXQgY2FuDQoNCmNob29zZSB0aGUgcmVhbG0uDQoN
Cg0KDQpJIHRoaW5rIHRoaXMgaXMgYSBub3QgZXhwcmVzc2VkIGFzc3VtcHRpb24sIHRoYXQgcmVh
bG0gZGV0ZXJtaW5hdGlvbiBtYXkgYmUNCg0KZG9uZSBiYXNlZCBvbiBzb3VyY2UgSVAgYWRkcmVz
cyBvZiB0aGUgY2xpZW50J3MgcmVxdWVzdC4gVGhhdCBpcyBhbiBhc3N1bXB0aW9uDQoNCnRoYXQg
aXMgbm90IGdlbmVyYWxseSBhcHBsaWNhYmxlLCBidXQgY2FuIHdvcmsgZm9yIHNvbWUgY29tYmlu
YXRpb25zIG9mIHJlYWxtcy4NCg0KRm9yIGV4YW1wbGUgYW4gc2VydmVyIHRoYXQgaGFzIGEgUkVB
TE0gZm9yIGFuIFdlYlJUQyBzZXJ2aWNlIHRoYXQgaXMNCg0KaW50ZW5kZWQgdG8gaGF2ZSBubyBy
ZXN0cmljdGlvbnMgY2FuJ3QgYmUgY28tbG9jYXRlZCB3aXRoIGFueXRoaW5nIHRoYXQgaGFzIGEN
Cg0Kc21hbGwgc2NvcGUgYXMgdGhhdCBjYW4gbGVhZCB0byBzZWxlY3Rpb24gb2YgdGhlIHdyb25n
IHJlYWxtLg0KDQpZZXMsIGJvdGggYXNzdW1wdGlvbnMgYXJlIGRlcGxveW1lbnQgc3BlY2lmaWMu
ICBFbnRlcnByaXNlIFRVUk4gc2VydmVycyBhcmUgZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM3NDc4Lg0KDQpVc2VybmFtZSBhbmQgcGFzc3dvcmQgaXMgbm90IHRo
ZSBvbmx5IHdheSB0byBwZXJmb3JtIG11dHVhbCBhdXRoZW50aWNhdGlvbiBiL3cgdGhlIFRVUk4g
Y2xpZW50IGFuZCBzZXJ2ZXIsIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjM1IGRp
c2N1c3NlcyB1c2luZyBPQXV0aCBhbmQgaXMgdXNlZCBieSBXZWJSVEMgKHNlZSBodHRwczovL3cz
Yy5naXRodWIuaW8vd2VicnRjLXBjLykuDQoNCg0KDQpXaGF0IGRvIHlvdSB0aGluayBpcyB0aGUg
YmVzdCBvcHRpb24gaGVyZS4gU2ltcGxlIGRvY3VtZW50IHRoYXQgdGhlcmUgYXJlIG5vDQoNCm1l
Y2hhbmlzbSBpbiB0aGUgcHJvdG9jb2wgZm9yIHRoZSBjbGllbnQgdG8gaW5kaWNhdGUgd2hpY2gg
UkVBTE0gaXQgdGhpbmtzIGl0DQoNCmJlbG9uZ3MgdG8gYW5kIHN0YXRlIHRoYXQgdGhlIGJhc2lj
IG1lY2hhbmlzbSBpcyB1c2luZyBkaWZmZXJlbnQgc2VydmVyIHBvcnRzDQoNCmZvciBkaWZmZXJl
bnQgcmVhbG1zLiBPciB0byB3cml0ZSBldmVuIG1vcmUgd2hlcmUgdGhlIHBvc3NpYmlsaXR5IGlu
IHNvdXJjZSBJUA0KDQphZGRyZXNzIGlkZW50aWZpY2F0aW9uIG9mIHJlYWxtIGlzIGRlc2NyaWJl
ZCBidXQgYWxzbyBpdHMgbGltaXRhdGlvbnM/DQoNCklmIGRpZmZlcmVudCBzZXJ2ZXIgcG9ydHMg
YXJlIHVzZWQgZm9yIGRpZmZlcmVudCByZWFsbXMsIHRoZSBjbGllbnQgbmVlZHMgdG8gbGVhcm4g
dGhlIHNlcnZlciBwb3J0cyBhbmQgbWFudWFsIGNvbmZpZ3VyYXRpb24gbWF5IG5vdCBiZSBhIHN1
aXRhYmxlIG9wdGlvbi4gVGhlIHB1YmxpYyBUVVJOIHNlcnZlciBjb3VsZCBoYXZlIGRpZmZlcmVu
dCBkb21haW4gbmFtZXMgZm9yIGRpZmZlcmVudCByZWFsbXMsIGFuZCB0aGUgY2xpZW50IGNhbiBk
aXNjb3ZlciB0aGUgc2VydmVyIHBvcnQgZm9yIHRoZSBUVVJOIHNlcnZlciBkb21haW4gdXNpbmcg
Uy1OQVBUUi4gIEkgZG9uJ3QgdGhpbmsgdGhlIGRyYWZ0IHNob3VsZCBkaXNjdXNzIGRlcGxveW1l
bnQgc3BlY2lmaWMgc29sdXRpb25zLg0KDQpTbyBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0
bHkgeW91ciBzdGF0aW5nIHRoYXQgaXQgaXMgdXAgdG8gdGhlIHNlcnZlciBpbXBsZW1lbnRhdGlv
biB0byBmaWd1cmUgb3V0IHdoYXQgdGhlIHJlYWxtIG9uIHdoYXQgZXZlciBpbmZvcm1hdGlvbiBp
cyBnZXRzIGJhc2VkIG9uIHRoZSByZXF1ZXN0LiBGcm9tIGEgY2xpZW50IGltcGxlbWVudGF0aW9u
IHBlcnNwZWN0aXZlIGl0IGFwcGVhcnMgbGVzcyBjbGVhciBpZiBhbnl0aGluZyB0aGUgY2xpZW50
IHdpbGwgYWZmZWN0IHRoZSByZWFsbSByZXNwb25zZSBpdCB3aWxsIHJlY2VpdmUuDQoNCltUUl0g
VGhlIGNsaWVudCBjYW5ub3QgYWZmZWN0IHRoZSByZWFsbSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2
ZXIsIHNpbWlsYXIgdG8gSFRUUCBhdXRoZW50aWNhdGlvbiB1c2luZyByZWFsbSAocGxlYXNlIHNl
ZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzNSkuDQoNCkkgZG9uJ3QgdGhpbmsg
dGhpcyBTZWN0aW9uIDE4IHF1b3RlIGlzIG5vdCBjbGVhciBlaXRoZXIuDQoNCiAgIEZvbGxvd2lu
ZyB0aGUgcHJvY2VkdXJlcyBvZiB0aGUgbG9uZy10ZXJtIGNyZWRlbnRpYWwgbWVjaGFuaXNtIG9m
DQogICBTVFVOIFtJLUQuaWV0Zi10cmFtLXN0dW5iaXNdLCB0aGUgc2VydmVyIGluY2x1ZGVzIGFu
IEVSUk9SLUNPREUNCiAgIGF0dHJpYnV0ZSB3aXRoIGEgdmFsdWUgb2YgNDAxIChVbmF1dGhvcml6
ZWQpLCBhIFJFQUxNIGF0dHJpYnV0ZSB0aGF0DQogICBzcGVjaWZpZXMgdGhlIGF1dGhlbnRpY2F0
aW9uIHJlYWxtIHVzZWQgYnkgdGhlIHNlcnZlciAoaW4gdGhpcyBjYXNlLA0KICAgdGhlIHNlcnZl
cidzIGRvbWFpbiAiZXhhbXBsZS5jb20iKSwgYW5kIGEgbm9uY2UgdmFsdWUgaW4gYSBOT05DRQ0K
ICAgYXR0cmlidXRlLg0KDQpTbyBJIHdpbGwgbm90IHBlcnNpc3Qgb24gdGhpcywgYnV0IEkgd291
bGQgYXBwcmVjaWF0ZSBzb21lIGluZGljYXRpb25zIG9uIHRoYXQgdGhlIHNlcnZlciBtYXkgZG8g
bW9yZSB0aGFuIHNpbXBseSBoYXZlIGEgc2luZ2xlIHJlYWxtIGZvciBhIGdpdmVuIHNlcnZlciB0
cmFuc3BvcnQgYWRkcmVzcy4NCg0KTC4gU2VjdGlvbiA3LjE6DQoNCg0KDQogIFRoZSBjbGllbnQg
dGhlbiBwaWNrcyBhIHRyYW5zcG9ydCBwcm90b2NvbCB0byB1c2UgYmV0d2VlbiB0aGUgY2xpZW50
DQoNCiAgIGFuZCB0aGUgc2VydmVyLiAgVGhlIHRyYW5zcG9ydCBwcm90b2NvbCBNVVNUIGJlIG9u
ZSBvZiBVRFAsIFRDUCwgVExTLQ0KDQogICBvdmVyLVRDUCBvciBEVExTLW92ZXItVURQLg0KDQoN
Cg0KSSBmaW5kIGl0IHN0cmFuZ2UgdGhhdCB0aGlzIGluZGljYXRlcyB0aGF0IG9uZSBzaG91bGQg
cGljayB0aGUNCg0KdHJhbnNwb3J0IHByb3RvY29sIHRvIHVzZSBjbGllbnQgdG8gc2VydmVyIHdp
dGhvdXQgY29uc2lkZXJpbmcgdGhlDQoNCnNlcnZlciBjYXBhYmlsaXRpZXMuIEVzcGVjaWFsbHkg
YXMgdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIG9yIHNlcnZlcg0KDQpkaXNjb3ZlcnkgcHJvY2Vk
dXJlcyB3aWxsIGluZGljYXRlIHRyYW5zcG9ydCBwcm90b2NvbCBzdXBwb3J0Lg0KDQpUaGUgc2Vy
dmVyIG1heSBzdXBwb3J0IG1vcmUgdGhhbiBvbmUgdHJhbnNwb3J0IHByb3RvY29sLg0KDQpTb3Jy
eSwgc2hvdWxkIGhhdmUgYmVlbiBjbGVhcmVyLiBTaG91bGQgdGhlcmUgYmUgYW55IHJlZmVyZW5j
ZXMgdG8gaG93IHRoZQ0KDQpjbGllbnQgY2FuIGRldGVybWluZSB0aGUgc2VydmVycyBjYXBhYmls
aXRpZXM/IFlvdSBoYXZlIHJlY29tbWVuZGF0aW9ucw0KDQphYm91dCB1c2luZyBVRFAgYW5kIGEg
cG9pbnRlciB0byBTZWN0aW9uIDIuMSBmb3Igc29tZSBkaXNjdXNzaW9uIG9mIHRoZSBjaG9pY2Vz
Lg0KDQpTbyB0aGF0IGNvdmVycyBnaXZpbmcgc29tZSBndWlkYW5jZSB0byB0aGUgcHJvdG9jb2wg
Y2hvaWNlLg0KDQpJIGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQoNCg0KICAg
VGhlIGNsaWVudCB0aGVuIHBpY2tzIGEgdHJhbnNwb3J0IHByb3RvY29sIHRvIHVzZSBiZXR3ZWVu
IHRoZSBjbGllbnQNCg0KICAgYW5kIHRoZSBzZXJ2ZXIgYmFzZWQgb24gdGhlIHRyYW5zcG9ydCBw
cm90b2NvbHMgc3VwcG9ydGVkIGJ5IHRoZQ0KDQogICBzZXJ2ZXIuICBUaGUgdHJhbnNwb3J0IHBy
b3RvY29sIE1VU1QgYmUgb25lIG9mIFVEUCwgVENQLCBUTFMtIG92ZXItVENQIG9yIERUTFMtb3Zl
ci1VRFAuDQoNCiAgIFNpbmNlIHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGFsbG93cyBVRFAgYmV0
d2VlbiB0aGUgc2VydmVyDQoNCiAgIGFuZCB0aGUgcGVlcnMsIGl0IGlzIFJFQ09NTUVOREVEIHRo
YXQgdGhlIGNsaWVudCBwaWNrIFVEUCB1bmxlc3MgaXQNCg0KICAgaGFzIGEgcmVhc29uIHRvIHVz
ZSBhIGRpZmZlcmVudCB0cmFuc3BvcnQuICBPbmUgcmVhc29uIHRvIHBpY2sgYQ0KDQogICBkaWZm
ZXJlbnQgdHJhbnNwb3J0IHdvdWxkIGJlIHRoYXQgdGhlIGNsaWVudCBiZWxpZXZlcywgZWl0aGVy
IHRocm91Z2gNCg0KICAgY29uZmlndXJhdGlvbiBvciBkaXNjb3Zlcnkgb3IgYnkgZXhwZXJpbWVu
dCwgdGhhdCBpdCBpcyB1bmFibGUgdG8NCg0KICAgY29udGFjdCBhbnkgVFVSTiBzZXJ2ZXIgdXNp
bmcgVURQLiAgU2VlIFNlY3Rpb24gMi4xIGZvciBtb3JlDQoNCiAgIGRpc2N1c3Npb24uDQoNCg0K
DQpUaGUgc3Vic2VxdWVudCBwYXJhZ3JhcGggaW4gU2VjdGlvbiA3LjEgZGlzY3Vzc2VzIHVzZSBv
ZiBbUkZDODE1NV0gdG8gZGlzY292ZXJ5IFRVUk4gc2VydmVyLCBhbmQgdXNlIG9mIFtSRkM1OTI4
XSBhbmQgW1JGQzczNTBdIHRvIGRpc2NvdmVyIHNlcnZlciB0cmFuc3BvcnQgY2FwYWJpbGl0aWVz
Lg0KDQpJIHN0aWxsIHRoaW5rIHRoZSBNVVNUIGlzIHVubmVjZXNzYXJ5IGFuZCBwcm9ibGVtYXRp
Yy4gVGhlIHByb2JsZW0gaXMgdGhhdCBpdCBmaXJzdCBvZiBhbGwgcHJldmVudHMgYW55IGZ1dHVy
ZSBleHRlbnNpb24gdG8gdGhlIHRyYW5zcG9ydCBwcm90b2NvbHMgYmUgdXNlZC4gSXNuJ3QgdGhl
IHBvaW50LCB0aGF0IHRoZSBjbGllbnQgcGlja3Mgb25lIG9mIHRoZSBwcm90b2NvbHMgaXQgc3Vw
cG9ydHM/DQoNCltUUl0gWWVzLg0KDQpNYXliZSByZW1vdmUgdGhlIHNlbnRlbmNlIGFuZCBzaW1w
bHkgYWRkIHNvbWV0aGluZyBhYm91dCAidGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIiBpbiB0aGUg
cHJpb3Igc2VudGVuY2UuDQoNCltUUl0gV29ya3MgZm9yIG1lLCByZW1vdmVkIHRoZSBzZW50ZW5j
ZSB3aXRoIE1VU1QgYW5kIG1vZGlmaWVkIHRoZSBmaXJzdCBsaW5lIGluIHRoZSBwYXJhZ3JhcGgg
YXMgZm9sbG93czoNCg0KVGhlIGNsaWVudCB0aGVuIHBpY2tzIGEgdHJhbnNwb3J0IHByb3RvY29s
IHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0byB1c2UgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0
aGUgc2VydmVyIGJhc2VkIG9uIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1cHBvcnRlZCBieSB0
aGUgc2VydmVyLg0KDQpBbHNvIHNob3VsZG4ndCB0aGlzIHBhcmFncmFwaCBjb21lIGJlZm9yZSB0
aGUgcHJldmlvdXMgb25lLiBJLmUuIHRoYXQgeW91IGZpcnN0DQoNCm11c3QgcGljayB5b3VyIHRy
YW5zcG9ydCBwcm90b2NvbCBiZWZvcmUgeW91IGNhbiBwaWNrIGEgaG9zdCB0cmFuc3BvcnQgYWRk
cmVzcyA/DQoNCk5vLCBtaWRkbGUtYm94ZXMgbWF5IGRyb3AgVURQIHRyYWZmaWMgdG8gdGhlIFRV
Uk4gc2VydmVyLCBhbmQgdGhlIGNsaWVudCBieSBleHBlcmltZW50IHdpbGwgaWRlbnRpZnkgdGhl
IHRyYW5zcG9ydCBwcm90b2NvbCBwZXJtaXR0ZWQgdG8gdGhlIFRVUk4gc2VydmVyIGFuZCBldmVu
dHVhbGx5IHVzZXMgdGhlDQoNCmhvc3QgdHJhbnNwb3J0IGFkZHJlc3MgdXNpbmcgd2hpY2ggc3Vj
Y2Vzc2Z1bCByZXNwb25zZSB3YXMgcmVjZWl2ZWQgZnJvbSB0aGUgc2VydmVyLg0KDQpPay4NCg0K
DQoNCg0KDQoNCg0KDQoNClNlY29uZGx5LCB3aGF0IGlzIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUg
TVVTVCBpbiB0aGUgc2Vjb25kIHNlbnRlbmNlPw0KDQpUaGlzIGlzIGFwcGVhcnMgdG8gaGF2ZSBz
dHJhbmdlIGludGVyYWN0aW9ucyB3aXRoIGFueSBmdXR1cmUNCg0KZXh0ZW5zaW9ucyBhbmQgaGF2
ZSBubyBpbXBhY3QuIEEgY2xpZW50IG11c3Qgb2J2aW91cyBjaG9zZSBhIGNsaWVudA0KDQp0byBz
ZXJ2ZXIgdHJhbnNwb3J0IHByb3RvY29sIGl0IHN1cHBvcnRzLCBhbmQgb25lIHRoYXQgdGhlIHNl
cnZlcg0KDQpzdXBwb3J0cyBvciB0aGUgY2xpZW50IGhvcGUgaXQgd2lsbCBzdXBwb3J0Lg0KDQpo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NiNzZWN0aW9uLTYuMSBoYXMgdGhlIHNh
bWUgdGV4dCwgSSBoYXZlDQoNCnVwZGF0ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCg0KVGhlIGNs
aWVudCB0aGVuIHBpY2tzIGEgdHJhbnNwb3J0IHByb3RvY29sIHRvIHVzZSBiZXR3ZWVuIHRoZSBj
bGllbnQgYW5kIHRoZQ0KDQpzZXJ2ZXIgYmFzZWQgb24gdGhlIHRyYW5zcG9ydCBwcm90b2NvbHMg
c3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIuDQoNClRoZSBUVVJOIHNlcnZlciBNVVNUIGVuYWJsZSBv
bmUgb2YgdGhlIHRyYW5zcG9ydCBwcm90b2NvbHMsIFVEUCwgVENQLCBUTFMtDQoNCm92ZXItVENQ
IG9yIERUTFMtb3Zlci1VRFAuDQoNCg0KDQpJZiB0aGUgaW50ZW50aW9uIGlzIHRvIG1vdmUgdGhl
IHJlcXVpcmVtZW50IHRvIHRoZSBzZXJ2ZXIgc2lkZSBmb3IgbWFraW5nIGl0DQoNCm5vcm1hdGl2
ZSB0byBzdXBwb3J0IGF0IGxlYXN0IG9uZSBvZiB0aGUgNCBvcHRpb25zIGxpc3RlZCwgSSB0aGlu
ayB5b3UgbmVlZCB0bw0KDQpyZXdyaXRlIGl0IHRvIHNheToNCg0KDQoNCkEgVFVSTiBzZXJ2ZXIg
TVVTVCBlbmFibGUgYXQgbGVhc3Qgb25lIG9mIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzLCBVRFAs
IFRDUCwNCg0KVExTLSBvdmVyLVRDUCBvciBEVExTLW92ZXItVURQLg0KDQpUaGUgYWJvdmUgcG9p
bnQgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA1IGFzIGZvbGxvd3M6DQoNCg0KDQog
VG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHksIGEgVFVSTiBzZXJ2ZXIgTVVTVCBzdXBwb3J0IHRo
ZSB1c2Ugb2YgVURQDQoNCiB0cmFuc3BvcnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2Vy
dmVyLCBhbmQgU0hPVUxEIHN1cHBvcnQgdGhlDQoNCiB1c2Ugb2YgVENQLCBUTFMtb3Zlci1UQ1Ag
YW5kIERUTFMtb3Zlci1VRFAgdHJhbnNwb3J0cy4NCg0KDQoNClNvLCB0aGlzIHNlbnRlbmNlIGxh
eXMgb3V0IHRoZSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudCBvbiB0aGUgc2VydmVyIHNpZGUg
YW5kIGlzIHZlcnkgcmVhc29uYWJsZSBhbmQgbGlrZWx5IG5lZWRlZC4NCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KTS4gU2VjdGlvbiA3LjE6DQoNCg0KDQogICBUaGUgY2xpZW50IGFsc28gcGlj
a3MgYSBzZXJ2ZXIgdHJhbnNwb3J0IGFkZHJlc3MsIHdoaWNoIFNIT1VMRCBiZQ0KDQogICBkb25l
IGFzIGZvbGxvd3MuICBUaGUgY2xpZW50IHVzZXMgb25lIG9yIG1vcmUgcHJvY2VkdXJlcyBkZXNj
cmliZWQgaW4NCg0KICAgW1JGQzgxNTVdIHRvIGRpc2NvdmVyIGEgVFVSTiBzZXJ2ZXIgYW5kIHVz
ZXMgdGhlIFRVUk4gc2VydmVyDQoNCiAgIHJlc29sdXRpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4g
W1JGQzU5MjhdIHRvIGdldCBhIGxpc3Qgb2Ygc2VydmVyDQoNCiAgIHRyYW5zcG9ydCBhZGRyZXNz
ZXMgdGhhdCBjYW4gYmUgdHJpZWQgdG8gY3JlYXRlIGEgVFVSTiBhbGxvY2F0aW9uLg0KDQoNCg0K
MSkgU28gUkZDIDgxNTUgc3RhdGVzIHRoYXQgaXQgaGFzIG5vIHJlY29tbWVuZGF0aW9uIG9uIHNl
cnZlcg0KDQpzZWxlY3Rpb24sIG5vciBvbiBob3cgdG8gcmVsYXRlZCBsb2NhbCBjb25maWd1cmF0
aW9uIHRvIGFueSBhdXRvLWRpc2NvdmVyeQ0KDQpzZXJ2ZXJzLg0KDQpUbyBtZSBpdCBhcHBlYXJz
IHRoYXQgdGhlIHByb3RvY29sIHV0aWxpemluZyBUVVJOIHNob3VsZCBjb25zaWRlcg0KDQp3aGF0
IG1ha2VzIHNlbnNlIGluIHRoZWlyIGRlcGxveW1lbnRzLiBUaHVzLCBkb2VzIHRoZSBuZWVkIGZv
ciBzdWNoDQoNCmNvbnNpZGVyYXRpb24gbmVlZHMgdG8gYmUgaGlnaGxpZ2h0ZWQgc29tZXdoZXJl
IGluIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
YzgxNTUjc2VjdGlvbi0zIGRpc2N1c3NlcyB1c2luZyBhdXRvLWRpc2NvdmVyeSBpbg0KDQp0aGUg
YWJzZW5jZSBvZiBsb2NhbCBjb25maWd1cmF0aW9uIG9yIGlmIHRoZSBsb2NhbCBjb25maWd1cmF0
aW9uIGRvZXMgbm90IHdvcmsuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTU1
I3NlY3Rpb24tOSBleHBsYWlucyB0aGUgbWVjaGFuaXNtcyB0bw0KDQphdXRoZW50aWNhdGUgdGhl
IGRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIuDQoNCkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGFkZGl0
aW9uYWwgY29uc2lkZXJhdGlvbnMgeW91IGFyZSBsb29raW5nIGluIHRoaXMNCg0Kc3BlY2lmaWNh
dGlvbi4NCg0KDQoNCkxldCBtZSBhdHRlbXB0IHRvIGZvcm11bGF0ZSB0aGUgcXVlc3Rpb24gaW4g
YW5vdGhlciB3YXkuIEFzIHRoZSBEaXNjb3ZlcnkNCg0KcHJvY2VkdXJlIGRvY3VtZW50ZWQgaW4g
UkZDIDgxNTUgZG9lcyBub3QgbWFuZGF0ZSBhbnkgc3BlY2lmaWMgb3JkZXIgb3INCg0KZXZlbiB3
aGF0IG1lY2hhbmlzbXMgYXJlIGFjdHVhbGx5IHVzZWQgLyBzdXBwb3J0ZWQsIHRoZW4gZGlkIHRo
ZSBXRyBjb25zaWRlcg0KDQp0byBtYWtlIGVpdGhlciBhIHN0cmljdGVyIHJlY29tbWVuZGF0aW9u
IG9yIHNvbWUgb3RoZXIgY29uc2lkZXJhdGlvbnMgdG8NCg0KYmV0dGVyIGVuc3VyZSB0aGF0IFRV
Uk4gY2xpZW50cyBjYW4gZGlzY292ZXIgVFVSTiBzZXJ2ZXJzPw0KDQoNCg0KSXQgaXMgZmluZSB0
byBzYXkgbm8uDQoNCk5vLCBpdCB3YXMgbGVmdCB0byBpbXBsZW1lbnRhdGlvbi4gSWYgbG9jYWwg
Y29uZmlndXJhdGlvbiBkb2VzIG5vdCB3b3JrIGZvciBhIFRVUk4gY2xpZW50LCBSRkM4MTU1IGV4
cGxhaW5zIHBlcmZvcm1pbmcgYWxsIHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNtcyB0byBmaW5kIHRo
ZSBUVVJOIHNlcnZlci4NCg0KDQoNCk9rYXksIHRoZW4gbGV0cyBkcm9wIHRoaXMgcG9pbnQuDQoN
Cg0KDQoNCg0KTy4gU2VjdGlvbiA3LjE6DQoNCg0KDQogICBJZiB0aGUgY2xpZW50IHdpc2hlcyB0
byBvYnRhaW4gYSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIG9mIGENCg0KICAgc3BlY2lmaWMg
YWRkcmVzcyB0eXBlIHRoZW4gaXQgaW5jbHVkZXMgYSBSRVFVRVNURUQtQUREUkVTUy1GQU1JTFkN
Cg0KICAgYXR0cmlidXRlIGluIHRoZSByZXF1ZXN0Lg0KDQoNCg0KSSBkb24ndCBmaW5kIGFueXRo
aW5nIGRlc2NyaWJpbmcgd2hhdCB0aGUgZGVmYXVsdCBiZWhhdmlvciBpcyBpZiBvbmUNCg0KZG9l
c24ndCBpbmNsdWRlIHRoZSBhdHRyaWJ1dGUsIGJ1dCB0aGUgVFVSTiBzZXJ2ZXIgc3VwcG9ydHMg
bXVsdGlwbGUgYWRkcmVzcw0KDQpmYW1pbGllcy4NCg0KSSBzZWUgdGhhdCBidWxsZXQgNyBpbiBT
ZWN0aW9uIDcuMiBpbmRpY2F0ZXMgdGhhdCBJUHY0IGlzIGRlZmF1bHQuDQoNClNob3VsZCB0aGUg
dGV4dCBpbiA3LjEgYmUgZXhwbGljaXQgYWJvdXQgdGhpcyBkZWZhdWx0Pw0KDQpUaGUgdGV4dCBp
biBTZWN0aW9uIDcuMSBpcyBhZGRlZCBmb3IgVFVSTiBjbGllbnRzIG5vdCBzdXBwb3J0aW5nIFRV
Uk5iaXMNCg0Kc3BlY2lmaWNhdGlvbiB0byBwcm92aWRlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHku
DQoNCg0KDQpCdXQgaWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgbGVnYWN5IHdh
eSBpcyB0byBub3QgaW5jbHVkZSB0aGUNCg0KUkVRVUVTVEVELUFERFJFU1MtRkFNSUxZIGF0dHJp
YnV0ZSBmb3IgYW4gSVB2NCBhZGRyZXNzLg0KDQpZZXMuDQoNCg0KDQpUaHVzLCBzaG91bGRuJ3Qg
YQ0KDQpzZW50ZW5jZSBiZSBhZGRlZCBhZnRlciB0aGUgYWJvdmUgdG8gc3RhdGUgdGhhdCBpZiB0
aGUgY2xpZW50IHdhbnRzIGFuDQoNCklQdjQgYWRkcmVzcyBpdCBzaG91bGQgc2tpcCB1c2luZyBS
RVFVRVNURUQtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlIHRvDQoNCmVuYWJsZSBsZWdhY3kgaW50
ZXJvcGVyYWJpbGl0eSwgb3IgZG8gSSBtaXNzdW5kZXJzdGFuZD8NCg0KUkVRVUVTVC1BRERSRVNT
LUZBTUlMWSBhdHRyaWJ1dGUgaXMgaW5pdGlhbGx5IGRlZmluZWQgaW4gaHR0cHM6Ly90b29scy5p
ZXRmLm9yZy9odG1sL3JmYzYxNTYgYXMgY29tcHJlaGVuc2lvbi1yZXF1aXJlZCBhdHRyaWJ1dGUu
IElmIHRoZSBsZWdhY3kgc2VydmVyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhpcyBhdHRyaWJ1dGUs
IHRoZSByZXF1ZXN0IHdpbGwgYmUgcmVqZWN0ZWQgKDQyMCAoVW5rbm93biBBdHRyaWJ1dGUpLCBh
bmQgaWYgdGhlIGNsaWVudCB3YW50cyBJUHY0IHJlbGF5ZWQgdHJhbnNwb3J0IGFkZHJlc3MsIHRo
ZSBjbGllbnQgd2lsbCBoYXZlIHRvIHJldHJ5IHRoZSByZXF1ZXN0IHdpdGhvdXQgdGhlIFJFUVVF
U1QtQUREUkVTUy1GQU1JTFkgYXR0cmlidXRlLg0KDQoNCg0KT2theSwgdGhlbiBJIHRoaW5rIHRo
aXMgaXNzdWUgY2FuIGJlIGNsb3NlZC4NCg0KDQoNCg0KDQoNCg0KDQoNClEuIFNlY3Rpb24gOC4z
Og0KDQoNCg0KICAgSWYgdGhlIGNsaWVudCByZWNlaXZlcyBhIHN1Y2Nlc3MgcmVzcG9uc2UgdG8g
aXRzIFJlZnJlc2ggcmVxdWVzdCB3aXRoDQoNCiAgIGEgbm9uLXplcm8gbGlmZXRpbWUsIGl0IHVw
ZGF0ZXMgaXRzIGNvcHkgb2YgdGhlIGFsbG9jYXRpb24gZGF0YQ0KDQogICBzdHJ1Y3R1cmUgd2l0
aCB0aGUgdGltZS10by1leHBpcnkgdmFsdWUgY29udGFpbmVkIGluIHRoZSByZXNwb25zZS4NCg0K
DQoNCiAgIElmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSA0MzcgKEFsbG9jYXRpb24gTWlzbWF0Y2gp
IGVycm9yIHJlc3BvbnNlIHRvDQoNCiAgIGEgcmVxdWVzdCB0byBkZWxldGUgdGhlIGFsbG9jYXRp
b24sIHRoZW4gdGhlIGFsbG9jYXRpb24gbm8gbG9uZ2VyDQoNCiAgIGV4aXN0cyBhbmQgaXQgc2hv
dWxkIGNvbnNpZGVyIGl0cyByZXF1ZXN0IGFzIGhhdmluZyBlZmZlY3RpdmVseQ0KDQogICBzdWNj
ZWVkZWQuDQoNCg0KDQpTbyB0aGVyZSBhcmUgbm8gY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBjbGll
bnQgaWYgaXQgcmVjZWl2ZXMgYW4gZXJyb3INCg0KcmVzcG9uc2UgdG8gYSByZWZyZXNoIHJlcXVl
c3Qgd2hlbiBMaWZldGltZSB3YXMgbm9uLXplcm8/DQoNCg0KDQpJIGFtIGJpdCBzdXJwcmlzZWQg
YnkgdGhhdC4gSSBhc3N1bWUgdGhhdCB0aGVyZSBhcmUgY2VydGFpbiBjYXNlcw0KDQp3aGVuIHRo
ZSByZXF1ZXN0IGNvdWxkIGJlIHJlc2VudCwgYW5kIG90aGVycyB3aGVyZSB0aGUgbWVhbmluZyBp
cw0KDQp0aGF0IHRoZSBhbGxvY2F0aW9uIGlzIGdvbmUuDQoNClRVUk5iaXMgZG9lcyBub3QgdXBk
YXRlIHRoZSByZWZyZXNoIGJlaGF2aW9yIGFscmVhZHkgZGVmaW5lZCBpbg0KDQpodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvcmZjNTc2NiNzZWN0aW9uLTcuMy4gIEkgd2lsbCBhZGQgdGhlIGZv
bGxvd2luZyBsaW5lOg0KDQpJZiB0aGUgY2xpZW50IHJlY2VpdmVzIGFuIGVycm9yIHJlc3BvbnNl
IHRvIGl0cyByZXF1ZXN0IHRvIHJlZnJlc2ggdGhlIGFsbG9jYXRpb24sDQoNCml0IHNob3VsZCBj
b25zaWRlciB0aGUgYWxsb2NhdGlvbiBubyBsb25nZXIgZXhpc3RzLg0KDQoNCg0KSXNuJ3QgdGhh
dCBvdmVyIHNpbXBsaWZ5aW5nIGNhc2VzIHdoZXJlIG9uZSBhdHRlbXB0cyB0byByZWZyZXNoIGFu
IGFsbG9jYXRpb24NCg0KYW5kIGNvdWxkIGFjdHVhbGx5IGhhbmRsZSB0aGUgaXNzdWUuIEZvciBl
eGFtcGxlIGFuIGVycm9yIHJlc3BvbnNlIHRvIHRoZSBjbGllbnQNCg0Kb2YgNDM4IChTdGFsZSBO
b25jZSkgIHdoZXJlIHRoZSBjbGllbnQgY2FuIHJldHJ5IHRoZSByZXF1ZXN0IHdpdGggdGhlIG5l
dw0KDQpOb25jZS4gSSBhbHNvIHdvbmRlciBpZiByZXF1ZXN0IHRpbWUgb3V0IGFzIHdlbGwgYXMg
NDAwIChpZiBpdCBjYW4gZmlndXJlIG91dCB3aGF0DQoNCnRoZSBpc3N1ZSB3YXMpIGNvdWxkIGJl
IHJlLWF0dGVtcHRlZCBwcmlvciB0byBhbGxvY2F0aW9uIGV4cGlyZXMuIEJ1dCBhdCBsZWF0IGh0
ZQ0KDQo0MzggYXBwZWFycyB0byBpbmRpY2F0ZSBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgY2xpZW50
IHNob3VsZCBub3QgZ2l2ZSB1cCwgYW5kDQoNCnRodXMgc2hvdWxkIGhhdmUgc29tZSB0ZXh0IGhl
cmUuDQoNCkdvb2QgcG9pbnQsIE1vZGlmaWVkIHRoZSBhYm92ZSBsaW5lIGZvbGxvd3M6DQoNCklm
IHRoZSBjbGllbnQgcmVjZWl2ZXMgYSA0MzcgKEFsbG9jYXRpb24gTWlzbWF0Y2gpIGVycm9yIHJl
c3BvbnNlIHRvIGl0cyByZXF1ZXN0IHRvIHJlZnJlc2ggdGhlIGFsbG9jYXRpb24sIGl0IHNob3Vs
ZCBjb25zaWRlciB0aGUgYWxsb2NhdGlvbiBubyBsb25nZXIgZXhpc3RzLiBJZiB0aGUgY2xpZW50
IHJlY2VpdmVzIGEgNDM4IChTdGFsZSBOb25jZSkgZXJyb3IgdG8gaXRzIHJlcXVlc3QgdG8gcmVm
cmVzaCB0aGUgYWxsb2NhdGlvbiwNCg0KaXQgc2hvdWxkIHJlYXR0ZW1wdCB0aGUgcmVxdWVzdCB3
aXRoIHRoZSBuZXcgbm9uY2UgdmFsdWUuDQoNCkdvb2Qgd29ya3MgZm9yIG1lLg0KDQoNCg0KDQoN
ClIuIFNlY3Rpb24gMTEuNToNCg0KDQoNCiAgIFdoZW4gdGhlIHNlcnZlciByZWNlaXZlcyBhbiBJ
Q01QIHBhY2tldCwgdGhlIHNlcnZlciB2ZXJpZmllcyB0aGF0IHRoZQ0KDQogICB0eXBlIGlzIGVp
dGhlciAzLCAxMSBvciAxMiBmb3IgYW4gSUNNUHY0IFtSRkMwNzkyXSBwYWNrZXQgb3IgZWl0aGVy
DQoNCiAgIDEsIDIsIG9yIDMgZm9yIGFuIElDTVB2NiBbUkZDNDQ0M10gcGFja2V0LiAgSXQgYWxz
byB2ZXJpZmllcyB0aGF0IHRoZQ0KDQogICBJUCBwYWNrZXQgaW4gdGhlIElDTVAgcGFja2V0IHBh
eWxvYWQgY29udGFpbnMgYSBVRFAgaGVhZGVyLiAgSWYNCg0KICAgZWl0aGVyIG9mIHRoZXNlIGNv
bmRpdGlvbnMgZmFpbCwgdGhlbiB0aGUgSUNNUCBwYWNrZXQgaXMgc2lsZW50bHkNCg0KICAgZHJv
cHBlZC4NCg0KDQoNCldoeSBpcyBub3QgSUNNUHY2IFR5cGUgNCAoUGFyYW1ldGVyIFByb2JsZW0p
IGluY2x1ZGVkIHdoZW4gUGFyYW1ldGVyDQoNClByb2JsZW0gYXJlIGZvciBJQ01QdjQ/DQoNCkkg
ZG9uJ3QgZ2V0IHRoZSBhYm92ZSBjb21tZW50LCBwbGVhc2UgZXhwbGFpbiB0aGUgcXVlc3Rpb24g
d2l0aCBhbiBleGFtcGxlLg0KDQpTbyBpZiBhIHNlcnZlciByZWNlaXZlcyBhbiBJQ01QIGZvciBz
ZW50IHBhY2tldCB3aXRoIElDTVB2NCB0eXBlIDEyDQoNCihQYXJhbWV0ZXIgUHJvYmxlbSkgdGhl
biB0aGF0IGlzIHJlbGF5ZWQgdG8gdGhlIGNsaWVudCBhY2NvcmRpbmcgdG8gdGhpcyB0ZXh0Lg0K
DQpCdXQgaWYgdGhlIHNlcnZlciBzZW50IGEgcGFja2V0IHdpdGggSVB2NiB0b3dhcmRzIHRoZSBw
ZWVyIGFuZCByZWNlaXZlcyBhbg0KDQpJQ01QdjYgbWVzc2FnZSB3aXRoIFR5cGUgNCAoUGFyYW1l
dGVyIFByb2JsZW0pIHRoYXQgaXMgbm90IHJlbGF5ZWQgdG8gdGhlDQoNCmNsaWVudC4gV2h5IHRo
aXMgZGlzY3JlcGFuY3k/DQoNClRoYW5rcywgZ290IHRoZSBjb21tZW50LiBJQ01QdjQgYW5kIElD
TVB2NiBlcnJvciBtZXNzYWdlIChQYXJhbWV0ZXIgcHJvYmxlbSkgbmVlZCBub3QgYmUgcmVsYXll
ZCBiYWNrIHRvIHRoZSBjbGllbnQgYmVjYXVzZSBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgYW5kIElQ
djQgb3B0aW9uIHNldCBpbiB0aGUgcGFja2V0IGZyb20gdGhlIGNsaWVudCB3aWxsIG5vdCBiZSBy
ZWxheWVkIHRvIHRoZSBwZWVyIChQbGVhc2Ugc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yMyNzZWN0aW9uLTE0IGFuZCBodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjMjc2VjdGlvbi0xMy4yKS4g
IFJlbW92ZWQgSUNNUHY0IDEyIHR5cGUuIEFkZGVkIHRoZSBmb2xsb3dpbmcgbGluZXMgdG8gU2Vj
dGlvbiAxNi4zIHRvIGNvbnZleSB0aGUgTVRVIG9mIHRoZSBuZXh0LWhvcCBsaW5rOg0KDQoNCg0K
ICAgRXJyb3IgRGF0YTogIFRoaXMgZmllbGQgc2l6ZSBpcyA0IGJ5dGVzIGxvbmcuICBJZiB0aGUg
SUNNUHY2IHR5cGUgaXMNCg0KICAgICAgMiAoUGFja2V0IFRvbyBCaWcgTWVzc2FnZSkgb3IgSUNN
UHY0IHR5cGUgaXMgMyAoIERlc3RpbmF0aW9uDQoNCiAgICAgIFVucmVhY2hhYmxlKSBhbmQgQ29k
ZSBpcyA0IChmcmFnbWVudGF0aW9uIG5lZWRlZCBhbmQgREYgc2V0KSwgdGhlDQoNCiAgICAgIEVy
cm9yIERhdGEgZmllbGQgd2lsbCBiZSBzZXQgdG8gdGhlIE1heGltdW0gVHJhbnNtaXNzaW9uIFVu
aXQgb2YNCg0KICAgICAgdGhlIG5leHQtaG9wIGxpbmsgKFNlY3Rpb24gMy4yIG9mIFtSRkM0NDQz
XSkgYW5kIFNlY3Rpb24gNCBvZg0KDQogICAgICBbUkZDMTE5MV0pLiAgRm9yIG90aGVyIElDTVB2
NiB0eXBlcyBhbmQgSUNNUHY0IHR5cGVzIGFuZCBjb2RlcywNCg0KICAgICBFcnJvciBEYXRhIGZp
ZWxkIE1VU1QgYmUgc2V0IHRvIHplcm8uDQoNCg0KDQpUaGFua3MsIHRoYXQgY2xhcmlmaWNhdGlv
bi4gSXNzdWUgcmVzb2x2ZWQuDQoNCg0KDQoNCg0KDQoNClUuIFNlY3Rpb24gMTMuIDEsMiwzOg0K
DQoNCg0KICAgICAgRm9yIGJvdGggcHJlZmVycmVkIGFuZCBhbHRlcm5hdGUgYmVoYXZpb3IsIHRo
ZSBET05ULUZSQUdNRU5UDQoNCiAgICAgIGF0dHJpYnV0ZSBNVVNUIGJlIGlnbm9yZWQgYnkgdGhl
IHNlcnZlci4NCg0KDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkganVzdCBiZWNhdXNlIG9uZSBw
ZXJmb3JtcyB2NDwtPnY2IG9yIHY2IHRvIHY0DQoNCnRyYW5zbGF0aW9uIG9yIHY2IHRvIHY2IHJl
bGF5aW5nIG5vdyBjYW4gaWdub3JlIHRoZSBET05ULUZSQUdFTUVOVA0KDQphdHRyaWJ1dGUuIElm
IHRoZSBjbGllbnQgaGFzIHJlcXVlc3QgdG8gbm90IGZyYWdtZW50IGFuZCB0aGUgc2VydmVyDQoN
CmlzIHVuYWJsZSB0byBkbyB0aGF0IHdoZW4gZm9yd2FyZGluZyB0byB0aGUgcGVlciBpdCBuZWVk
cyB0byBnZW5lcmF0ZQ0KDQphbiBJQ01QIGF0dHJpYnV0ZSByZXNwb25zZSBzYXlpbmcgdGhlIHBh
Y2tldCBpcyB0byBiaWcuIE90aGVyd2lzZSB0aGUNCg0KcmVsYXkgYnJlYWtzIHRoZSBQYXRoIE1U
VSBkaXNjb3ZlcnkgbWVjaGFuaXNtcy4NCg0KVFVSTmJpcyBpcyB1c2luZyB0aGUgdHJhbnNsYXRp
b24gYWxnb3JpdGhtcyBzcGVjaWZpZWQgaW4gUkZDNzkxNS4NCg0KDQoNClthXSBGb3IgSVB2NCB0
byBJUHY2OiBUaGUgdHJhbnNsYXRvciB1c2VzIHRoZSBERiBiaXQgaW4gdGhlIElQdjQgaGVhZGVy
IHRvIG5vdA0KDQpmcmFnbWVudCB0aGUgSVB2NiBwYWNrZXQgKHNlZSBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzkxNSNzZWN0aW9uLTQpLA0KDQpET04nVC1GUkFHTUVOVCBhdHRyaWJ1
dGUgY2FuIGJlIGlnbm9yZWQuDQoNCltiXSBGb3IgSVB2NiB0byBJUHY0OiBUaGUgdHJhbnNsYXRp
b24gYWxnb3JpdGhtIGluDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTE1I3Nl
Y3Rpb24tNSBpcyB1c2VkLiAgSWYgdGhlIElQdjYgZW5kcG9pbnQgd2FudHMNCg0KdG8gZGlzY292
ZXIgdGhlIHBhdGggTVRVLCBpdCB3aWxsIHNlbmQgSVB2NiBwYWNrZXRzIHdpdGhvdXQgRnJhZ21l
bnQgaGVhZGVyDQoNCmFuZCBET04nVC1GUkFHTUVOVCBhdHRyaWJ1dGUgY2FuIGJlIGlnbm9yZWQu
DQoNCltjXSBGb3IgSVB2NiB0byBJUHY2OiBJZiB0aGUgSVB2NiBlbmRwb2ludCB3YW50cyB0byBk
aXNjb3ZlciB0aGUgcGF0aCBNVFUsIGl0DQoNCndpbGwgc2VuZCBJUHY2IHBhY2tldHMgd2l0aG91
dCBGcmFnbWVudCBoZWFkZXIgYW5kIERPTidULUZSQUdNRU5UDQoNCmF0dHJpYnV0ZSBjYW4gYmUg
aWdub3JlZC4NCg0KUGxlYXNlIG5vdGUgaWdub3JpbmcgdGhlIERPTlQtRlJBR01FTlQgYXR0cmli
dXRlIGlzIHBpY2tlZCBmcm9tDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTU2
I3NlY3Rpb24tOCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBCRUhBVkUgV0cNCg0KaHR0cHM6Ly9tYWls
YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iZWhhdmUvb2FidTBWdFVNQkUtWDMtdmhnamRTRkNi
b3hjLg0KDQoNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbiBvbiB0aGUgY29udGV4dC4g
SSBzaG91bGQgaGF2ZSByZWFkIFNlY3Rpb24NCg0KNCBvZiA3OTE1LiBUaGVuIEkgd291bGQgaGF2
ZSBsaWtlbHkgZ290dGVuIHRoZSBpbXBsaWNhdGlvbiB0aGF0IHRoZSBJUCBoZWFkZXIgREYNCg0K
b3IgRnJhZ21lbnRhdGlvbiBoZWFkZXIgaW1wYWN0cyBob3cgdGhpbmdzIGFyZSB3b3JraW5nLg0K
DQoNCg0KSG93ZXZlciwgSSBmaW5kIHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgY2hvaWNlIHZl
cnkgc3RyYW5nZS4gSSBkb24ndCBzZWUgaG93DQoNCnlvdSBjYW4gaW1wbGVtZW50IGEgVFVSTiBz
ZXJ2ZXIgdGhhdCBkb2VzIElQdjQgPC0+SVB2Niwgb3IgSVB2NiByZWxheWluZw0KDQp3aXRob3V0
IGhhdmluZyBwcml2aWxlZ2VkIGFjY2VzcyBhbmQgd2hlcmUgaXQgcmVhZHMgdGhlIHJhdyBoZWFk
ZXJzLiBBbg0KDQppbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiBVRFAgc29ja2V0cyB3aWxsIG5vdCBi
ZSBhYmxlIHRvIGRvIHRoZSByaWdodCB0aGluZw0KDQpoZXJlIHRvIG15IHVuZGVyc3RhbmRpbmcu
IEhvd2V2ZXIsIGl0IGNvdWxkIGZvbGxvdyB0aGUgRE9OVC1GUkFHTUVOVA0KDQphdHRyaWJ1dGUg
dG8gaW5zdHJ1Y3RpbmcgdGhlIHNlbmRpbmcgdXNpbmcgdGhlIFNvY2tldCB0byBkbyB0aGUgcmln
aHQgdGhpbmcuDQoNCkFzIHBlciB0aGUgZGlzY3Vzc2lvbiBpbiBCRUhBVkUgV0csIGl0IHNlZW1z
IHBvc3NpYmxlIHRvIHNldCBhbmQgZ2V0IHZhcmlvdXMgSVAgaGVhZGVyIGZpZWxkcyB1c2luZyBz
b2NrZXRzLCBzZWUgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iZWhhdmUv
ajZGZnpnVkx1U2VIZk9Xejl6Uk81aVBDcDk4IGFuZCBodHRwczovL21haWxhcmNoaXZlLmlldGYu
b3JnL2FyY2gvbXNnL2JlaGF2ZS8zSS1EdnRWZl80Y0djRG5Ja3RzV05FdGZJWU0uDQoNCg0KDQpJ
IHRoaW5rIHRoZXJlIGFyZSB0d28gZGlyZWN0aW9ucyB3ZSBjYW4gcHJvY2VlZCBpbiBoZXJlLg0K
DQoNCg0KMS4gUmVkZWZpbmUgdGhpcyB0ZXh0IHRvIGVuYWJsZSB1c2FnZSBvZiBET05ULUZSQUdN
RU5UDQoNCkkgcHJlZmVyIG5vdCB0byBjaGFuZ2UgdGhlIGJlaGF2aW9yIGRpc2N1c3NlZCBhbmQg
ZmluYWxpemVkIGZvciBSRkM2MTU2IGluIEJFSEFWRSBXRy4NCg0KDQoNCm9yDQoNCg0KDQoyLiBD
bGFyaWZ5IHRoZSBzY29wZSBhbmQgaW1wbGljYXRpb25zIG9mIFVucHJpdmlsaWdlZCBUVVJOIFNl
cnZlciBkb2luZw0KDQp0cmFuc2xhdGlvbg0KDQoNCg0KDQoNCkZvciB0aGUgc2Vjb25kIG9wdGlv
biBJIHRoaW5rIHRoZXJlIGFyZSBzZXZlcmFsIGFzcGVjdHMgdGhhdCBJIGxpa2UgdG8gc2VlDQoN
CmFkZHJlc3NlZDoNCg0KDQoNCiAgMmE6IFVwZGF0ZSB0aGUgc2VudGVuY2UgSSBxdW90ZWQgZm9y
IHRoaXMgaXNzdWUgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHlvdSBhcmUNCg0KcmVseWluZyBzb2xl
bHkgb24gSVB2NCBERiBhbmQgSVB2NiBGcmFnbWVudGF0aW9uIEhlYWRlciB0byBjb250cm9sIHRo
ZQ0KDQpmcmFnbWVudGF0aW9uLg0KDQpBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gUGFja2V0
IFRyYW5zbGF0aW9ucyAoU2VjdGlvbiAxMy42KS4NCg0KVGhlIFRVUk4gc2VydmVyIHNvbGVseSBy
ZWxpZXMgb24gdGhlIERGIGJpdCBpbiB0aGUgSVB2NCBoZWFkZXIgYW5kIEZyYWdtZW50YXRpb24g
aGVhZGVyIGluIElQdjYgaGVhZGVyIHRvIGhhbmRsZSBmcmFnbWVudGF0aW9uIGFuZCBkb2VzIG5v
dCByZWx5IG9uIHRoZSBET05ULUZSQUdNRU5UIGF0dHJpYnV0ZS4NCg0KDQoNClRoYW5rcywgdGhh
dCBjbGFyaWZpZXMgdGhhdCBhc3BlY3QuDQoNCg0KDQoNCg0KICAyYjogQ2xhcmlmeSB0aGF0IFVu
cHJpdmlsaWdlZCBUVVJOIFNldmVycyB0aGF0IGRvIElQdjQ8LT4gSVB2NiB0cmFuc2xhdGlvbiB3
aWxsDQoNCm5vdCBoYW5kbGUgZnJhZ21lbnRhdGlvbiB3ZWxsLiBBbmQgaW5jbHVkZSBhIHBvaW50
IHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZg0KDQpTZWN0aW9uIDIuNyBhbmQgdGhlIHVzZSBvZiBE
T05ULUZSQUdNRU5UIEluIEFsbG9jYXRlIHJlcXVlc3RzIHRvIGRldGVybWluZQ0KDQpzdXBwb3J0
IGFuZCB0aGF0IHRoZXNlIG5lZWRzIHRvIGJlIHJlamVjdGVkIGJ5IHN1Y2ggYSBzZXJ2ZXIuDQoN
CkRlcGVuZGluZyBvbiB0aGUgT1MsIFVucHJpdmlsZWdlZCBUVVJOIFNldmVycyBtYXkgb3IgbWF5
IG5vdCBoYW5kbGUgZnJhZ21lbnRhdGlvbiAoaS5lLiBoYXZlIGFjY2VzcyB0byBERiBiaXQpLiAg
SSB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIGxpbmU6DQoNCklmIHRoZSBUVVJOIHNlcnZlciBjYXJy
eWluZyBvdXQgcGFja2V0IHRyYW5zbGF0aW9uIGZyb20gSVB2NC10by1JUHY2IGNhbm5vdCBnZXQg
dGhlIERvbid0IEZyYWdtZW50IChERikgYml0IGluIHRoZSBJUHY0IGhlYWRlciwgaXQgTVVTVCBy
ZWplY3QgdGhlIEFsbG9jYXRlIHJlcXVlc3Qgd2l0aCBET05ULUZSQUdNRU5UIGF0dHJpYnV0ZS4N
Cg0KVGhpcyBpcyBhbHNvIGdvb2QuIFRoaW5rIHRoZXNlIHR3byBjaGFuZ3MgcmVzb2x2ZSB0aGUg
aXNzdWUuDQoNCg0KDQoNCg0KQnkgdGhlIHdheSwgdGhlcmUgbXVzdCBiZSBhIHR5cG8gd2l0aCBh
ICJub3QiIHRoYXQgc2hvdWxkbid0IGJlIGluIHRoaXMNCg0KcGFyYWdyYXBoIGluIFNlY3Rpb24g
NCBvZiA3OTE1Og0KDQoNCg0KICAgV2hlbiB0aGUgSVB2NCBzZW5kZXIgZG9lcyBub3Qgc2V0IHRo
ZSBERiBiaXQsIHRoZSB0cmFuc2xhdG9yIE1VU1QgTk9UDQoNCiAgIGluY2x1ZGUgdGhlIEZyYWdt
ZW50IEhlYWRlciBmb3IgdGhlIG5vbi1mcmFnbWVudGVkIElQdjYgcGFja2V0cy4NCg0KDQoNClRv
IG1lIGl0IG1ha2Ugc2Vuc2UgZm9yIGEgSVB2NC0+SVB2NiB0cmFuc2xhdGlvbiB3aGVyZSB0aGUg
SVB2NCBoYXMgREY9VFJVRQ0KDQp0byBub3QgaW5jbHVkZSB0aGUgZnJhZ21lbnRhdGlvbiBoZWFk
ZXIsIGRvIHlvdSBhZ3JlZT8NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5MTUj
c2VjdGlvbi00LjEgc2F5cyB0byBpbmNsdWRlIHRoZSBmcmFnbWVudCBoZWFkZXIgb25seSB3aGVu
IElQdjQgaGVhZGVyIGhhcyBERj0wIGFuZCB0aGUgcGFja2V0IHNpemUgZXhjZWVkcyB0aGUgTVRV
Lg0KDQpPa2F5LCBJIHRoaW5rIEkgdW5kZXJzdGFuZCB0aGUgdGV4dCBhbmQgdGhhdCBpdCBpcyBu
b3QgYSByZWFsIGlzc3VlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClguIFNlY3Rpb24gMTQ6DQoN
Cg0KDQpIb3cgYXJlIHRoZXNlIElQIGxldmVsIGZpZWxkcyBoYW5kbGVkIHdoZW4gdGhlIHRyYW5z
cG9ydCBpcyBUQ1Agb3IgVExTL1RDUD8NCg0KVGhlcmUgdGhlcmUgYXJlIG5vdCBuZWNlc3Nhcnkg
YSBvbmUgdG8gb25lIG1hcHBpbmcgYmV0d2VlbiBkYXRhZ3JhbXMNCg0KYW5kIFRDUCBwYWNrZXRz
LiBBbmQgaWYgdGhlcmUgYXJlIG5vIHN1cHBvcnQgdGhlbiB0aGVyZSBhcmUgbmVlZCBmb3INCg0K
Y2xhcmlmaWNhdGlvbiBvZiBiZWhhdmlvcnMgd2hlbiB1c2luZyBUQ1AgYmFzZWQgdHJhbnNwb3J0
Lg0KDQpTZWN0aW9uIDE0IGFscmVhZHkgY2xhcmlmaWVzIHRoYXQgdGhlIGRlc2NyaXB0aW9ucyBp
biB0aGlzIHNlY3Rpb24gZG8gbm90IGFwcGx5IHRvDQoNClRVUk4gbWVzc2FnZXMgc2VudCBvdmVy
IFRDUCBvciBUTFMgdHJhbnNwb3J0IGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50Lg0KDQoN
Cg0KWWVzIHlvdSBhcmUgcmlnaHQuIFdoYXQgYXJlIHRoZSByZWNvbW1lbmRhdGlvbnMgZm9yIGhv
dyB0byBzZXQgdGhlIGZpZWxkcw0KDQp3aGVuIHRoZSBDaGFubmVsIG1lc3NhZ2Ugb3IgU2VuZCBJ
bmRpY2F0aW9uIGFycml2ZXMgb3Zlcg0KDQpUQ1AvKFRMUykgdG8gdGhlIHNlcnZlcj8gVG8gbWUg
dGhlIGJhc2lzIGlzIHRoZSBhbHRlcm5hdGl2ZSBiZWhhdmlvciB3aXRoIHRoZQ0KDQpleGNlcHRp
b24gZm9yIHRoZSBERiBiaXQuIEhvd2V2ZXIsIGJlaGF2aW9ycyBmb3IgZGF0YWdyYW1zIG9yaWdu
YXRlZCBieSB0aGUNCg0Kc2VydmVyIGFuZCBkZWxpdmVyZWQgdG8gdGhlIHNlcnZlciBvdmVyIG5v
biBkYXRhZ3JhbSB0cmFuc3BvcnQgd2lsbCBuZWVkIHRvDQoNCmhhdmUgcmVjb21tZW5kYXRpb25z
IGFsc28gZm9yIElQdjYuDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBzdGFuZGFyZCAxOjEgbWFw
cGluZyBvZiBJUCBsZXZlbCBmaWVsZHMgYmV0d2VlbiBVRFAgYW5kIFRDUCwgIGh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24tMTIgZG9lcyBub3QgZGVmaW5lIHRoZSBi
ZWhhdmlvciB0byBzZXQgdGhlIGZpZWxkcywgdGhlIHRvcGljIHdhcyBkaXNjdXNzZWQgaW4gQkVI
QVZFIFdHIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYmVoYXZlL1FCWmFZ
Z2steDVsWk5GcEU0cUNMaXp0Y2c4WSBhbmQgdGhlIGRlY2lzaW9uIHdhcyB0byBmb2N1cyBvbmx5
IG9uIFVEUCB0byBVRFAgY2FzZS4gIFdoYXQgc3BlY2lmaWMgY2hhbmdlIGFyZSB5b3UgcHJvcG9z
aW5nIGluIHRoaXMgU2VjdGlvbiA/DQoNClNvIEkgYW0gbm90IGFza2luZyBmb3IgYSAxOjEgbWFw
cGluZy4gV2hhdCBJIHNlZSBhcyBtaXNzaW5nIGlzIHRoZSBkZWZpbml0aW9uIG9mIGhvdyBzaGFs
bCBiZSBzZXQgaW4gVURQIHBhY2tldHMgc2VudCBvdXQgZnJvbSB0aGUgVFVSTiBzZXJ2ZXIsIGFu
ZCBob3cgdG8gZGVhbCB3aXRoIGFueSBpbmZvcm1hdGlvbiBpbiB0aGUgaW5jb21pbmcgcGFja2V0
cy4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIHJlY29tbWVuZGF0
aW9ucyBhcyBub3QgYmVpbmcgb2J2aW91cyBmb3IgZXZlcnlvbmUsIGJ1dCBhdCB0aGUgc2FtZSB0
aW1lIHN1Y2ggYSBkZXNjcmlwdGlvbiBpcyBub3QgYSBodWdlIHRhc2sgdG8gZGVmaW5lLg0KDQpb
VFJdIE9rYXksIHdpbGwgYWRkIGEgbmV3IHNlY3Rpb24gKElQIEhlYWRlciBGaWVsZHMgZm9yIFRD
UC10by1VRFAgdHJhbnNsYXRpb24pLg0KDQpGb3IgVURQIHBhY2tldHMgZ2VuZXJhdGVkIGJhc2Vk
IG9uIENoYW5uZWwgb3IgU2VuZCBJbmRpY2F0aW9ucyBhcnJpdmluZyBhdCB0aGUgVFVSTiBzZXJ2
ZXIgb3ZlciBhIFRDUCBUcmFuc3BvcnQgSSB0aGluayB0aGUgZm9sbG93aW5nIHNob3VsZCBiZSBk
b25lLiAgTm90ZSwgdGhpcyBhIHJvdWdoIHNrZXRjaCwgc29tZSBhZGp1c3RtZW50IG9mIHRoZSBs
YW5ndWFnZSBzaG91bGQgYmUgZG9uZSBhbmQgZm9ybWF0dGVkIGxpa2UgdGhlIG90aGVyIG9wdGlv
bnMuDQoNClRUTDogU2V0IHRvIGRlZmF1bHQgb3V0Z29pbmcgdmFsdWUuDQoNCkRTQ1A6IFNldCB0
byB2YWx1ZSB1c2VkIGJ5IFRDUCBjb25uZWN0aW9uLCB1bmxlc3MgdGhlIHNlcnZlciBpbXBsZW1l
bnRzIGEgcmVtYXJrZXIuIE5vdGUsIHRoZSBUQ1AgY29ubmVjdGlvbiBjYW4gb25seSB1c2UgYSBz
aW5nbGUgRFNDUCBjb2RlIHBvaW50IHNvIGludGVyIGZsb3cgZGlmZmVyZW50aWF0aW9uIGlzIG5v
dCBwb3NzaWJsZSwgc2VlIFNlY3Rpb24gNS4xIG9mIFJGQyA3NjU3Lg0KDQpbVFJdIFRUTCBhbmQg
RFNDUCBleHBsYW5hdGlvbiBsb29rcyBnb29kLCB3aWxsIHVwZGF0ZSBkcmFmdC4NCg0KRUNOOiBO
byBtZWNoYW5pc20gaXMgZGVmaW5lZCB0byBpbmRpY2F0ZSB3aGF0IEVDTiB2YWx1ZSBzaG91bGQg
YmUgdXNlZCBmb3Igb3V0Z29pbmcgVURQIHBhY2tldHMgZm9yIGFuIGFsbG9jYXRpb25zLCB0aGVy
ZWZvcmUgdGhlIEVDTiBmaWVsZCBzaGFsbCBiZSBzZXQgdG8gTm90IEVDVCAoPTBiMDApLg0KDQpb
VFJdIEkgdGhpbmsgeW91IG1lYW4gdGhlIGZvbGxvd2luZzoNCg0KRHVlIHRvIHRoZSBsYWNrIG9m
IGZlZWRiYWNrIG1lY2hhbmlzbXMgaW4gVURQLCBTZXQgdGhlIG91dGdvaW5nIHZhbHVlIHRvIE5v
dC1FQ1QgKD0wYjAwKS4NCg0KRmxvdyBMYWJlbDoNCg0KICAgICBbQXMgZGlzY3Vzc2VkIGVhcmxp
ZXIgYmFzZWQgb24gdGhlIHJlc3VsdGluZyBVRFAgZmxvd10uDQoNCltUUl0gRmxvdyBMYWJlbCBp
cyBhbHJlYWR5IGRpc2N1c3NlZCBpbiBJUHY0LXRvLUlQdjYgYW5kIElQdjYtdG8tSVB2NiB0cmFu
c2xhdGlvbnMgKHNlY3Rpb25zIDEzLiAxIGFuZCAxMy4yKSwgYW5kIG5vdCBzcGVjaWZpYyB0byBU
Q1AtdG8tVURQIHRyYW5zbGF0aW9uLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi10cmFtLXR1cm5iaXMtMjQjc2VjdGlvbi0xNCAoSVAgaGVhZGVyIGZpZWxkcykgZG9lcyBu
b3QgZGlzY3VzcyBGbG93IGxhYmVsLg0KDQpJUHY0IEZyYWdtZW50YXRpb246DQoNCiAgICAgIFdo
ZW4gdGhlIHNlcnZlciBzZW5kcyBhIHBhY2tldCB0byBhIHBlZXIgaW4NCg0KICAgICAgcmVzcG9u
c2UgdG8gYSBTZW5kIGluZGljYXRpb24gY29udGFpbmluZyB0aGUgRE9OVC1GUkFHTUVOVA0KDQog
ICAgICBhdHRyaWJ1dGUsIHRoZW4gc2V0IHRoZSBERiBiaXQgaW4gdGhlIG91dGdvaW5nIElQIGhl
YWRlciB0byAxLiAgSW4NCg0KICAgICAgYWxsIG90aGVyIGNhc2VzIHdoZW4gc2VuZGluZyBhbiBv
dXRnb2luZyBwYWNrZXQgY29udGFpbmluZw0KDQogICAgICBhcHBsaWNhdGlvbiBkYXRhIChlLmcu
LCBEYXRhIGluZGljYXRpb24sIENoYW5uZWxEYXRhIG1lc3NhZ2UsIG9yDQoNCiAgICAgIERPTlQt
RlJBR01FTlQgYXR0cmlidXRlIG5vdCBpbmNsdWRlZCBpbiB0aGUgU2VuZCBpbmRpY2F0aW9uKSwg
c2V0IHRoZSBERiBiaXQNCg0KICAgICAgaW4gdGhlIG91dGdvaW5nIElQIGhlYWRlciB0byAwLg0K
DQoNCg0KW1RSXSBXaHkgbm90IHVzZSB0aGUgc2FtZSBiZWhhdmlvciBhcyBVRFAtdG8tVURQIHRy
YW5zbGF0aW9uIGZvciBJUHY0IGZyYWdtZW50YXRpb24gPw0KDQoNCg0KV2UgY2FuIHJlLXVzZSB0
aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAgIElQdjQgRnJhZ21lbnRhdGlvbiBmaWVsZHMNCg0KICAg
ICAgUHJlZmVycmVkIEJlaGF2aW9yOiBXaGVuIHRoZSBzZXJ2ZXIgc2VuZHMgYSBwYWNrZXQgdG8g
YSBwZWVyIGluDQogICAgICByZXNwb25zZSB0byBhIFNlbmQgaW5kaWNhdGlvbiBjb250YWluaW5n
IHRoZSBET05ULUZSQUdNRU5UDQogICAgICBhdHRyaWJ1dGUsIHRoZW4gc2V0IHRoZSBERiBiaXQg
aW4gdGhlIG91dGdvaW5nIElQIGhlYWRlciB0byAxLiAgSW4NCiAgICAgIGFsbCBvdGhlciBjYXNl
cyB3aGVuIHNlbmRpbmcgYW4gb3V0Z29pbmcgcGFja2V0IGNvbnRhaW5pbmcNCiAgICAgIGFwcGxp
Y2F0aW9uIGRhdGEgKGUuZy4sIERhdGEgaW5kaWNhdGlvbiwgQ2hhbm5lbERhdGEgbWVzc2FnZSwg
b3INCiAgICAgIERPTlQtRlJBR01FTlQgYXR0cmlidXRlIG5vdCBpbmNsdWRlZCBpbiB0aGUgU2Vu
ZCBpbmRpY2F0aW9uKSwgY29weQ0KICAgICAgdGhlIERGIGJpdCBmcm9tIHRoZSBERiBiaXQgb2Yg
dGhlIGluY29taW5nIHBhY2tldCB0aGF0IGNvbnRhaW5lZA0KICAgICAgdGhlIGFwcGxpY2F0aW9u
IGRhdGEuDQoNCiAgICAgIFNldCB0aGUgb3RoZXIgZnJhZ21lbnRhdGlvbiBmaWVsZHMgKElkZW50
aWZpY2F0aW9uLCBNb3JlDQogICAgICBGcmFnbWVudHMsIEZyYWdtZW50IE9mZnNldCkgYXMgYXBw
cm9wcmlhdGUgZm9yIGEgcGFja2V0DQogICAgICBvcmlnaW5hdGluZyBmcm9tIHRoZSBzZXJ2ZXIu
DQoNCiAgICAgIEFsdGVybmF0ZSBCZWhhdmlvcjogQXMgZGVzY3JpYmVkIGluIHRoZSBQcmVmZXJy
ZWQgQmVoYXZpb3IsIGV4Y2VwdA0KICAgICAgYWx3YXlzIGFzc3VtZSB0aGUgaW5jb21pbmcgREYg
Yml0IGlzIDAuDQoNCiAgICAgIEluIGJvdGggdGhlIFByZWZlcnJlZCBhbmQgQWx0ZXJuYXRlIEJl
aGF2aW9ycywgdGhlIHJlc3VsdGluZw0KICAgICAgcGFja2V0IG1heSBiZSB0b28gbGFyZ2UgZm9y
IHRoZSBvdXRnb2luZyBsaW5rLiAgSWYgdGhpcyBpcyB0aGUNCiAgICAgIGNhc2UsIHRoZW4gdGhl
IG5vcm1hbCBmcmFnbWVudGF0aW9uIHJ1bGVzIGFwcGx5IFtSRkMxMTIyXS4NCg0KDQoNCklQdjYg
RnJhZ21lbnRhdGlvbjoNCg0KICAgICAgICAgICBJbmRlcGVuZGVudCBpZiB0aGUgVENQIHRyYWZm
aWMgYXJyaXZlcyBvdmVyIElQdjQgb3IgSVB2NiB0aGUgZnJhZ21lbnRhdGlvbiBzZXR0aW5ncyBm
b3Igb3V0Z29pbmcgIElQdjYgVURQIHBhY2tldHMgd2lsbCBoYXZlIHRvIGZvbGxvdyB3aGF0IGlz
IGRlZmluZWQgZm9yIElQdjQgdG8gSVB2NiB0cmFuc2xhdGlvbiBhbmQgaWdub3JlIHRoZSBERiBi
aXQgaW4gaW5jb21pbmcgcGFja2V0cywgYW5kIGludGVycHJldCB0aGUgcHJlc2VuY2Ugb2YgdGhl
IERPTlQtRlJBR01FTlQgYXR0cmlidXRlIGFzIERGPTEgaW4gaW5jb21pbmcgcGFja2V0LCBhbmQg
Zm9yIGFsbCBvdGhlciBjYXNlcyBjb25zaWRlciBERj0wIHRvIGFwcGx5Lg0KDQogW1RSXSBUaGUg
YmVoYXZpb3IgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gSVB2NC10by1JUHY2IGFuZCBJUHY2LXRv
LUlQdjYgdHJhbnNsYXRpb25zIGluIHRoZSBkcmFmdC4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI0I3NlY3Rpb24tMTQgKElQIGhlYWRlciBmaWVs
ZHMpIHNlY3Rpb24gZG9lcyBub3QgZGlzY3VzcyBJUHY2IGZyYWdtZW50YXRpb24uDQoNCiBJUHY0
IE9wdGlvbnMNCg0KDQoNCiAgICAgIFByZWZlcnJlZCBCZWhhdmlvcjogVGhlIG91dGdvaW5nIHBh
Y2tldCBpcyBzZW50IHdpdGhvdXQgYW55IElQdjQNCg0KICAgICAgb3B0aW9ucy4NCg0KDQoNCiBb
VFJdIEkgd2lsbCBhZGQgSVB2NCBvcHRpb25zLg0KDQoNCg0KSVB2NiBFeHRlbnNpb25zIEhlYWRl
cnM6DQoNCg0KDQogICAgICBTZXQgcGVyIGRlZmF1bHQgZm9yIG9yaWdpbmF0ZWQgSVB2NiBwYWNr
ZXRzLg0KDQoNCg0KW1RSXSBUaGUgYmVoYXZpb3IgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gSVB2
Ni10by1JUHY2IHRyYW5zbGF0aW9ucywgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWlldGYtdHJhbS10dXJuYmlzLTI0I3NlY3Rpb24tMTQgKElQIGhlYWRlciBmaWVsZHMpc2VjdGlv
biBkb2VzIG5vdCBkaXNjdXNzIGV4dGVuc2lvbiBoZWFkZXJzLg0KDQoNCg0KDQoNCg0KDQpPbiBS
ZWNlcHRpb24gb2YgVURQIFBhY2tldHMNCg0KDQoNCklmIFRUTD0wIHRoZW4gZHJvcCBwYWNrZXQs
IGVsc2UgaWdub3JlLg0KDQoNCg0KRFNDUDogSWdub3JlLCB0aGUgRFNDUCB2YWx1ZSBmb3IgdGhl
IFNlcnZlciB0byBDbGllbnQgZGlyZWN0aW9uIG9mIHRoZSBUQ1AgY29ubmVjdGlvbiBzaG91bGQg
YmUgYmFzZWQgb24gdGhlIHZhbHVlDQoNCnVzZWQgZm9yIHRoZSBjbGllbnQgdG8gc2VydmVyLg0K
DQoNCg0KW1RSXSBCb3RoIFRUTCBhbmQgRFNDUCBleHBsYW5hdGlvbiBsb29rcyBnb29kLCB3aWxs
IHVwZGF0ZSBkcmFmdC4NCg0KDQoNCkVDTjogSWdub3JlLiBIaWdoZXIgbGF5ZXIgcHJvdG9jb2xz
IGF0dGVtcHRpbmcgdG8gdXNlIEVDTiB3aWxsIG5vdCByZWNlaXZlIGFueSBFQ04gc2lnbmFsIGFu
ZCB0aHVzIHNlbmRlcg0KDQpzaG91bGQgc3RvcCBzZW5kaW5nIEVDVCBwYWNrZXRzIGlmIHNlbnQu
DQoNCg0KDQpbVFJdIEkgdGhpbmsgeW91IG1lYW4g4oCcU2V0IHRoZSBvdXRnb2luZyB2YWx1ZSB0
byBOb3QtRUNUICg9MGIwMCku4oCdDQoNCg0KDQpGbG93IExhYmVsOiBJZ25vcmUsIHRoZSBUQ1Ag
Y29ubmVjdGlvbiBoYXMgaXRzIG93biB0aGF0IGlzIHJlbGF0ZWQgdG8gcGVlciB0byBzZXJ2ZXIg
Zmxvdy4NCg0KW1RSXSBGbG93IExhYmVsIGlzIGFscmVhZHkgZGlzY3Vzc2VkIGluIElQdjQtdG8t
SVB2NiBhbmQgSVB2Ni10by1JUHY2IHRyYW5zbGF0aW9ucyAoc2VjdGlvbnMgMTMuIDEgYW5kIDEz
LjIpLCBhbmQgbm90IHNwZWNpZmljIHRvIFVEUC10by1UQ1AgdHJhbnNsYXRpb24gYmV0d2VlbiB0
aGUgcGVlciBhbmQgdGhlIGNsaWVudC4NCg0KRnJhZ21lbnRhdGlvbjoNCg0KDQoNCkFueSBmcmFn
bWVudGVkIHBhY2tldHMgYXJlIHJlYXNzZW1ibGVkIGluIHNlcnZlciBhbmQgdGhlbiBmb3J3YXJk
ZWQgdG8gdGhlIGNsaWVudCBvdmVyIHRoZSBUQ1AgY29ubmVjdGlvbi4NCg0KSUNNUCBtZXNzYWdl
cyByZXN1bHRpbmcgZnJvbSBzZW50IFVEUCBwYWNrZXRzLCBNVVNUIGJlIGZvcndhcmQgdG8gY2xp
ZW50IHVzaW5nIFRVUk4ncyBtZWNoYW5pc20gZm9yIHJlbGV2YW50IElDTVAgdHlwZXMuDQoNCg0K
DQpJUHY0IE9wdGlvbnMgYXJlIHByb2Nlc3NlZCBieSBzZXJ2ZXIgaWYgcG9zc2libGUsIGVsc2Ug
aWdub3JlZA0KDQoNCg0KW1RSXSBMZXTigJlzIHVzZSB0aGUgc2FtZSBiZWhhdmlvciBhcyBVRFAt
dG8tVURQIHRyYW5zbGF0aW9uIGZvciBJUHY0IG9wdGlvbnMuDQoNCg0KDQpJUHY2IEV4dGVuc2lv
biBoZWFkZXJzIGFyZSBwcm9jZXNzZWQgYnkgc2VydmVyIGlmIHBvc3NpYmxlIGFzIGludGVuZGVk
IGVuZHBvaW50LCBlbHNlIGlnbm9yZWQuDQoNCg0KDQpbVFJdIFRoZSBJUHY2IEV4dGVuc2lvbiBi
ZWhhdmlvciBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiBJUHY2LXRvLUlQdjYgdHJhbnNsYXRpb24u
DQoNCg0KDQoNCg0KDQoNClkuIFNlY3Rpb24gMTYuNC4gIERBVEENCg0KDQoNCiAgIFRoZSBEQVRB
IGF0dHJpYnV0ZSBpcyBwcmVzZW50IGluIGFsbCBTZW5kIGFuZCBEYXRhIGluZGljYXRpb25zLiAg
VGhlDQoNCiAgIHZhbHVlIHBvcnRpb24gb2YgdGhpcyBhdHRyaWJ1dGUgaXMgdmFyaWFibGUgbGVu
Z3RoIGFuZCBjb25zaXN0cyBvZg0KDQogICB0aGUgYXBwbGljYXRpb24gZGF0YSAodGhhdCBpcywg
dGhlIGRhdGEgdGhhdCB3b3VsZCBpbW1lZGlhdGVseSBmb2xsb3cNCg0KICAgdGhlIFVEUCBoZWFk
ZXIgaWYgdGhlIGRhdGEgd2FzIGJlZW4gc2VudCBkaXJlY3RseSBiZXR3ZWVuIHRoZSBjbGllbnQN
Cg0KICAgYW5kIHRoZSBwZWVyKS4gIElmIHRoZSBsZW5ndGggb2YgdGhpcyBhdHRyaWJ1dGUgaXMg
bm90IGEgbXVsdGlwbGUgb2YNCg0KICAgNCwgdGhlbiBwYWRkaW5nIG11c3QgYmUgYWRkZWQgYWZ0
ZXIgdGhpcyBhdHRyaWJ1dGUuDQoNCg0KDQpDYW4geW91IHBsZWFzZSBjbGFyaWZ5IGlmIG9uZSB3
b3VsZCBnZXQgYWxsIHRoZSByZW1haW5pbmcgYnl0ZXMgb2YNCg0KdGhlIElQIHBhY2tldCBwYXls
b2FkIG9yIG9ubHkgdGhlIG51bWJlciBvZiBieXRlcyB0aGUgVURQIGxlbmd0aCBmaWVsZA0KDQpp
bmRpY2F0ZXMgPw0KDQpUaGUgcmVhc29uIEkgYXNrIGlzIHRoYXQgdGhlcmUgaXMgcG9zc2liaWxp
dHkgdGhhdCB0aGVyZSBhcmUgYQ0KDQpkaXNjcmVwYW5jeSBiZXR3ZWVuIHRoZXNlIGZpZWxkcywg
c29tZXRoaW5nIHRoZSBwcm9wb3NhbCBmb3IgYW4NCg0KZXhwZXJpbWVudGFsIHNwZWNpZmljYXRp
b24gZm9yIFVEUCBvcHRpb25zIGF0dGVtcHQgdG8gdXRpbGl6ZS4NCg0KaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy8NCg0KDQoNCk5v
dGUsIEkgb25seSB3YW50IHlvdSB0byBjbGFyaWZ5IHdoYXQgaXMgYWN0dWFsbHkgaW5jbHVkZWQu
IEkgd291bGQNCg0KYXNzdW1lIHVzaW5nIHRoZSBVRFAgbGVuZ3RoIGZpZWxkIG1ha2VzIHNlbnNl
IGluIHRoaXMgY2FzZS4NCg0KVGhlIGFwcGxpY2F0aW9uIGRhdGEgZG9lcyBub3QgaW5jbHVkZSB0
aGUgb3B0aW9ucyBkaXNjdXNzZWQgaW4gZHJhZnQtaWV0Zi0NCg0KdHN2d2ctdWRwLW9wdGlvbnMu
DQoNClBsZWFzZSBjbGFyaWZ5IHRoZSBzcGVjaWZpYyB1cGRhdGUgeW91IGFyZSBsb29raW5nIGlu
IHRoaXMgc2VjdGlvbi4NCg0KTXkgaW50ZW50aW9uIGhlcmUgd2FzIG5vdCB0byBicmluZyBpbiBV
RFAgb3B0aW9ucywgb25seSB0byBlbnN1cmUgdGhhdCB0aGUNCg0Kc3BlY2lmaWNhdGlvbiB0ZXh0
IGlzIGNsZWFyLiBBcyBVRFAgb3B0aW9ucyBkcmFmdCBwb2ludHMgb3V0IHRoZXJlIGNvdWxkIGJl
IGENCg0KZGlzY3JlcGFuY3kgYmV0d2VlbiB0aGUgVURQIGxlbmd0aCBhbmQgSVAgbGVuZ3RoLiBU
aHVzLCBJIHRoaW5rIHRoZXJlIGlzIGEgcG9pbnQNCg0KdG8gbWFrZSBpdCBjbGVhciB0aGF0IHRo
ZSBkYXRhIGluY2x1ZGVzIFVEUCBsZW5ndGggLTggYnl0ZXMgb2YgVURQIHBheWxvYWQuDQoNClBv
c3NpYmxlIGluY2x1ZGUgYSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgZm9yIHdoeSB0aGVyZSBtaWdo
dCBiZSBhIGRpc2NyZXBhbmN5Lg0KDQpUaGUgZGF0YSBvbmx5IGluY2x1ZGVzIHRoZSBhcHBsaWNh
dGlvbiBkYXRhLCBhbmQgdGhlIGxlbmd0aCBvZiB0aGUgYXR0cmlidXRlIGlzIGFsc28gYmFzZWQg
b24gdGhlIGFwcGxpY2F0aW9uIGRhdGEsIGFuZCBJIGRvbid0IHNlZSBhbnkgZGlzY3JlcGFuY3kg
aW4gdGhlIGNsaWVudCB0byBkZXRlcm1pbmUgdGhlIGxlbmd0aCBvZiB0aGUgYXBwbGljYXRpb24g
ZGF0YS4NCg0KVG8gYXZvaWQgYW55IGZ1dHVyZSBjb25mdXNpb24gaWYgVURQIG9wdGlvbnMgZ2V0
cyBkZXBsb3llZCBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgY2FuIGNsYXJpZnkgdGhhdCB0aGUgREFU
QSBwYXJ0IGlzIHdoYXQgaXMgZGVmaW5lZCBhcyBVRFAgdXNlciBkYXRhIGluIHRoZSBiZWxvdyBm
aWd1cmUsIGkuZS4gdGhlIFVEUCBsZW5ndGggZmllbGQgLSBVRFAgaGVhZGVyIGxlbmd0aCBhbW91
bnQgb2YgZGF0YSBhZnRlciB0aGUgVURQIGhlYWRlciBpbiB0aGUgSVAgcGFja2V0IHN1Y2ggdGhh
dCB0aGUgc3VycGx1cyBhcmVhIG5ldmVyIGlzIGluY2x1ZGVkLg0KDQogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIElQIHRyYW5zcG9ydCBwYXlsb2FkDQoNCiAgICAgICAgICAgICAgICA8LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCg0KICAgICAg
Ky0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0t
LS0tLSsNCg0KICAgICAgfCBJUCBIZHIgfCBVRFAgSGRyIHwgICAgIFVEUCB1c2VyIGRhdGEgICAg
fCAgIHN1cnBsdXMgYXJlYSAgIHwNCg0KICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tLSstLS0tLS0t
LS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgIDwt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+DQoNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFVEUCBMZW5ndGgNCg0KDQoNCiAgICAgICAgICAgICAgIEZpZ3VyZSAzIElQIHRyYW5zcG9y
dCBwYXlsb2FkIHZzLiBVRFAgTGVuZ3RoDQoNCk5vdGUsIHRoaXMgaXMgdG8gbXkgdW5kZXJzdGFu
ZGluZyB3aGF0IGlzIGNhbGxlZCBVRFAgdXNlciBkYXRhIGlzIHdoYXQgdGhlIGN1cnJlbnQgT1Mg
aW1wbGVtZW50YXRpb25zIHdpbGwgZ2l2ZSB5b3UgaWYgeW91IHVzZSB0aGVpciBpbnRlcmZhY2Vz
LCBidXQgaWYgdGhlIFRVUk4gU2VydmVyIGlzIGltcGxlbWVudGVkIHVzaW5nIFJBVyBJUCBwYWNr
ZXRzIHRoaXMgbnVhbmNlIG1heSBiZSBtaXNzZWQuDQoNCltUUl0gVGhhbmtzIGZvciB0aGUgZXhw
bGFuYXRpb24sIEkgd2lsbCBhZGQgdGhlIGZvbGxvd2luZyB0aGUgbGluZSB0byBhdm9pZCBmdXR1
cmUgY29uZnVzaW9uOg0KDQpUaGUgYXBwbGljYXRpb24gZGF0YSBpcyBlcXVpdmFsZW50IHRvIHRo
ZSAiVURQIHVzZXIgZGF0YSIgYW5kIGRvZXMgbm90IGluY2x1ZGUgdGhlICJzdXJwbHVzIGFyZWEi
IGRlZmluZWQgaW4gU2VjdGlvbiA0IG9mIGRyYWZ0LWlldGYtdHN2d2ctdWRwLW9wdGlvbnMuDQoN
CkNoZWVycywNCg0KLVRpcnUNCg0KDQoNCkFJLiBEVExTIENpcGhlciBTdWl0cw0KDQoNCg0KQW0g
SSB1bmRlcnN0YW5kaW5nIGl0IGNvcnJlY3QgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiB3aGF0IERU
TFMgY2lwaGVyDQoNCnN1aXQgdGhhdCBhIFRVUk4gU2VydmVyIGN1cnJlbnRseSBpcyB0byBzdXBw
b3J0IGlzIHRoZSBvbmVzIGluIFJGQyA3NTI1ID8NCg0KTm8sIHRoZSBjaXBoZXIgc3VpdGVzIGFu
ZCAoRClUTFMgcHJvZmlsZSBpcyBkaXNjdXNzZWQgaW4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tNi4yLjMgYW5kIGl0DQoN
CmZvbGxvd3MgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiBSRkM3NTI1Lg0KDQoNCg0KQWhhYSwgb2Yg
Y291cnNlLiBCdXQsIG1heWJlIGFuIGV4cGxpY2l0IHJlZmVyZW5jZSB0byBTVFVOYmlzIGluIHNl
Y3Rpb24NCg0KMi4xIHRoYXQgdGhlIHRyYW5zcG9ydHMgZm9yIFRVUk4gYW5kIFNUVU4gbWVzc2Fn
ZXMgYXJlIGRlZmluZWQgdGhlcmU/DQoNCg0KDQpJbiB0aGF0IGNhc2UsIEkgdGhpbmsgdGhlIHdv
cmRpbmcgaXMgYSBiaXQgd2VhayBhcyB0aGUgb25seSByZWZlcmVuY2UNCg0KSSBmaW5kIGFyZSBp
biBTZWN0aW9uIDIuMToNCg0KDQoNCklmIChEKVRMUyB0cmFuc3BvcnQgaXMNCg0KICAgdXNlZCBi
ZXR3ZWVuIHRoZSBUVVJOIGNsaWVudCBhbmQgdGhlIFRVUk4gc2VydmVyLCB0aGUgZ3VpZGFuY2Ug
Z2l2ZW4NCg0KICAgaW4gW1JGQzc1MjVdIE1VU1QgYmUgZm9sbG93ZWQgdG8gYXZvaWQgYXR0YWNr
cyBvbiAoRClUTFMuDQoNClJGQzc1MjUgcHJvdmlkZXMgdmFyaW91cyByZWNvbW1lbmRhdGlvbnMg
dG8gYXZvaWQgYXR0YWNrcyBvbiAoRClUTFMuDQoNCkl0IHdhcyByZWFsbHkgdGhlIHRleHQgaW4g
U1RVTmJpcyB0aGF0IEkgd2FzIGxvb2tpbmcgZm9yLg0KDQpPa2F5LCBtb2RpZmllZCB0aGUgYWJv
dmUgbGluZSBhcyBmb2xsb3dzOg0KDQoNCg0KICAgSWYgKEQpVExTIHRyYW5zcG9ydCBpcw0KDQog
ICB1c2VkIGJldHdlZW4gdGhlIFRVUk4gY2xpZW50IGFuZCB0aGUgVFVSTiBzZXJ2ZXIsIHRoZSBj
aXBoZXIgc3VpdGVzDQoNCiAgIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDYuMi4zIG9mIFtJLUQuaWV0
Zi10cmFtLXN0dW5iaXNdIGFuZCB0aGUgZ3VpZGFuY2UNCg0KICAgZ2l2ZW4gaW4gW1JGQzc1MjVd
IE1VU1QgYmUgZm9sbG93ZWQgdG8gYXZvaWQgYXR0YWNrcyBvbiAoRClUTFMuDQoNCg0KDQpMb29r
cyBnb29kIHRvIG1lLg0KDQoNCg0KQ2hlZXJzDQoNCg0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQoN
Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KDQpOZXR3b3JrIEFyY2hpdGVjdHVyZSAmIFByb3RvY29scywgRXJp
Y3Nzb24gUmVzZWFyY2gNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpFcmljc3NvbiBBQiAgICAgICAgICAg
ICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCg0KVG9yc2hhbW5zZ2F0YW4gMjMgICAgICAg
ICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQoNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRl
biB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPG1haWx0bzptYWdudXMu
d2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg==

--_000_BYAPR16MB2790F74A7D46937AD59A0363EA380BYAPR16MB2790namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh
W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg
MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy
IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg
MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt
YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN
Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7
fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm
b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6Ymxh
Y2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t
c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow
aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv
cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41
aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl
Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv
IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv
Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh
eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv
bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9
IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs
YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQiPkhpIE1hZ251cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y
OndpbmRvd3RleHQiPlBsZWFzZSBzZWUgaW5saW5lIFtUUl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7
cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj
b2xvcjp3aW5kb3d0ZXh0Ij4gTWFnbnVzIFdlc3Rlcmx1bmQgJmx0O21hZ251cy53ZXN0ZXJsdW5k
QGVyaWNzc29uLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEFwcmlsIDI2LCAy
MDE5IDU6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0
O1RpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20mZ3Q7OyB0cmFtQGlldGYub3JnOyBk
cmFmdC1pZXRmLXRyYW0tdHVybmJpc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog
W3RyYW1dIEFEIEV2YWx1YXRpb24gb2YgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjM8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIg
Ym9yZGVyPSIxIiBjZWxscGFkZGluZz0iMCIgc3R5bGU9ImJhY2tncm91bmQ6I0YzRkYzMztib3Jk
ZXI6c29saWQgIzlCOUE4NyAxLjVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRl
cjpub25lO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHA+PHN0cm9uZz48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiM5QjhCM0UiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojOUI4QjNFIj46PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIEV4dGVybmFsIGVt
YWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJl
Y29nbml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXYgY2xh
c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4N
CjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3V0dGluZyBhd2F5IHdoYXQgYXBwZWFy
IHNldHRsZWQuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiAyMDE5LTA0LTE4IDEwOjIwLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IHdy
b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1
LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+IGVycm9yIHBhY2tldCwgdGhlIHNlcnZl
ciBhbHNvIHJlbGF5cyBjZXJ0YWluIGxheWVyIDMvNCBoZWFkZXIgZmllbGRzIGZyb20gdGhlPG86
cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SUNNUCBoZWFkZXIgdG8gdGhlIGNs
aWVudC4gV2hlbiB0aGUgY2xpZW50IHNlbmRzIGEgcGFja2V0IHRvIHRoZSBzZXJ2ZXIsIHRoZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZlciByZWxheXMgdGhlIHRyYW5zcG9ydCBwcm90b2Nv
bCBkYXRhIGZyb20gdGhlIHBhY2tldCB0byB0aGUgYXBwcm9wcmlhdGU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5wZWVyIHVzaW5nIHRoZSByZWxheWVkIHRyYW5zcG9ydCBhZGRyZXNzIGFzIHRoZSBz
b3VyY2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw
cmU+JnF1b3Q7YXBwcm9wcmlhdGUmcXVvdDsgYXBwZWFycyB3cm9uZy4gVGhlIHBlZXIgaXMgdGhl
IG9uZSB0aGUgY2xpZW50IGhhdmUgY29uZmlndXJlIGZvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PnRoZSBhbGxvY2F0aW9uLiBTbyBJIHRoaW5rIGEgbW9yZSBkaXJlY3QgbGFuZ3VhZ2UgY2FuIGJl
IHVzZWQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+JnF1b3Q7YXBwcm9w
cmlhdGUgcGVlciZxdW90OyBpcyB1c2VkIGF0IHNldmVyYWwgcGxhY2VzIGluIDxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2Ij5odHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNTc2NjwvYT4uIDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5U
aGVyZSBpcyBub3cgYSBzaW5nbGUgb2NjdXJyZW5jZSBvZiBpdCBpbiB0aGlzIGRvY3VtZW50LiBB
bmQgaW4gdGhhdCBjb250ZXh0LCBpdCBhcHBlYXJzIHRoYXQgdXNpbmcgJnF1b3Q7aW50ZW5kZWQm
cXVvdDsgb3IgJnF1b3Q7YWRkcmVzc2VkJnF1b3Q7IHBlZXIgd291bGQgd29yayBiZXR0ZXIgYW5k
IGJlIGNsZWFyZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gT2theSwgcmVwbGFjZWQgd2l0
aCDigJxpbnRlbmRlZCBwZWVy4oCdLiA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPk90aGV3aXNlIGZpbmUgd2l0aCBtZS48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SC4gU2VjdGlvbiA1
OiA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgdGhlIHNl
cnZlciByZXF1aXJlcyByZXF1ZXN0cyB0byBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyBhdXRoZW50aWNhdGVkLCB0aGVuIHRoZSBzZXJ2ZXIncyBhZG1pbmlzdHJhdG9yIE1V
U1QgY2hvb3NlIGEgcmVhbG08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdmFs
dWUgdGhhdCB3aWxsIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZSB1c2VybmFtZSBhbmQgcGFzc3dvcmQ8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY29tYmluYXRpb24gdGhhdCB0aGUg
Y2xpZW50IG11c3QgdXNlLCBldmVuIGlmIHRoZSBjbGllbnQgdXNlczxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBtdWx0aXBsZSBzZXJ2ZXJzIHVuZGVyIGRpZmZlcmVudCBhZG1p
bmlzdHJhdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+SnVzdCB0byB2ZXJpZnksIFRVUk4gZG9lcyBub3QgYWxsb3cgYSBzaW5nbGUgc2Vy
dmVyIGFkZHJlc3MgdG8gaG9zdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm11bHRpcGxlIHJlYWxt
cyBkbyBpdD8gRWFjaCBSZWFsbSBuZWVkcyBpdHMgb3duIHVuaXF1ZSBzZXJ2ZXIgdHJhbnNwb3J0
PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+YWRk
cmVzcz88bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk5vLCBJIGRvbid0IHNlZSBhbnkgc3VjaCBy
ZXN0cmljdGlvbiBpbiBUVVJOLiZuYnNwOyBGb3IgZXhhbXBsZSwgaW4gYW4gRW50ZXJwcmlzZTxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPm5ldHdvcmsgd2l0aCBtdWx0aXBs
ZSByZWFsbXMsIHRoZSBUVVJOIHNlcnZlciBiYXNlZCBvbiB0aGUgY2xpZW50IHN1Ym5ldCBjYW48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jaG9vc2UgdGhlIHJlYWxtLjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgdGhpbmsgdGhpcyBpcyBhIG5v
dCBleHByZXNzZWQgYXNzdW1wdGlvbiwgdGhhdCByZWFsbSBkZXRlcm1pbmF0aW9uIG1heSBiZTxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRvbmUgYmFzZWQgb24gc291cmNlIElQIGFkZHJlc3Mgb2Yg
dGhlIGNsaWVudCdzIHJlcXVlc3QuIFRoYXQgaXMgYW4gYXNzdW1wdGlvbjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPnRoYXQgaXMgbm90IGdlbmVyYWxseSBhcHBsaWNhYmxlLCBidXQgY2FuIHdvcmsg
Zm9yIHNvbWUgY29tYmluYXRpb25zIG9mIHJlYWxtcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5G
b3IgZXhhbXBsZSBhbiBzZXJ2ZXIgdGhhdCBoYXMgYSBSRUFMTSBmb3IgYW4gV2ViUlRDIHNlcnZp
Y2UgdGhhdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmludGVuZGVkIHRvIGhhdmUgbm8gcmVz
dHJpY3Rpb25zIGNhbid0IGJlIGNvLWxvY2F0ZWQgd2l0aCBhbnl0aGluZyB0aGF0IGhhcyBhPG86
cD48L286cD48L3ByZT4NCjxwcmU+c21hbGwgc2NvcGUgYXMgdGhhdCBjYW4gbGVhZCB0byBzZWxl
Y3Rpb24gb2YgdGhlIHdyb25nIHJlYWxtLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8cHJlPlllcywgYm90aCBhc3N1bXB0aW9ucyBhcmUgZGVwbG95bWVudCBzcGVjaWZpYy4mbmJz
cDsgRW50ZXJwcmlzZSBUVVJOIHNlcnZlcnMgYXJlIGRpc2N1c3NlZCBpbiA8YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzQ3OCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzc0Nzg8L2E+LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Vc2VybmFtZSBhbmQgcGFz
c3dvcmQgaXMgbm90IHRoZSBvbmx5IHdheSB0byBwZXJmb3JtIG11dHVhbCBhdXRoZW50aWNhdGlv
biBiL3cgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIsIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM3NjM1Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYz
NTwvYT4gZGlzY3Vzc2VzIHVzaW5nIE9BdXRoIGFuZCBpcyB1c2VkIGJ5IFdlYlJUQyAoc2VlIDxh
IGhyZWY9Imh0dHBzOi8vdzNjLmdpdGh1Yi5pby93ZWJydGMtcGMvIj5odHRwczovL3czYy5naXRo
dWIuaW8vd2VicnRjLXBjLzwvYT4pLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPldoYXQgZG8geW91IHRoaW5rIGlzIHRoZSBiZXN0IG9wdGlv
biBoZXJlLiBTaW1wbGUgZG9jdW1lbnQgdGhhdCB0aGVyZSBhcmUgbm88bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT5tZWNoYW5pc20gaW4gdGhlIHByb3RvY29sIGZvciB0aGUgY2xpZW50IHRvIGluZGlj
YXRlIHdoaWNoIFJFQUxNIGl0IHRoaW5rcyBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmJlbG9u
Z3MgdG8gYW5kIHN0YXRlIHRoYXQgdGhlIGJhc2ljIG1lY2hhbmlzbSBpcyB1c2luZyBkaWZmZXJl
bnQgc2VydmVyIHBvcnRzPG86cD48L286cD48L3ByZT4NCjxwcmU+Zm9yIGRpZmZlcmVudCByZWFs
bXMuIE9yIHRvIHdyaXRlIGV2ZW4gbW9yZSB3aGVyZSB0aGUgcG9zc2liaWxpdHkgaW4gc291cmNl
IElQPG86cD48L286cD48L3ByZT4NCjxwcmU+YWRkcmVzcyBpZGVudGlmaWNhdGlvbiBvZiByZWFs
bSBpcyBkZXNjcmliZWQgYnV0IGFsc28gaXRzIGxpbWl0YXRpb25zPzxvOnA+PC9vOnA+PC9wcmU+
DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPklmIGRpZmZlcmVudCBzZXJ2ZXIgcG9ydHMgYXJlIHVzZWQg
Zm9yIGRpZmZlcmVudCByZWFsbXMsIHRoZSBjbGllbnQgbmVlZHMgdG8gbGVhcm4gdGhlIHNlcnZl
ciBwb3J0cyBhbmQgbWFudWFsIGNvbmZpZ3VyYXRpb24gbWF5IG5vdCBiZSBhIHN1aXRhYmxlIG9w
dGlvbi4gVGhlIHB1YmxpYyBUVVJOIHNlcnZlciBjb3VsZCBoYXZlIGRpZmZlcmVudCBkb21haW4g
bmFtZXMgZm9yIGRpZmZlcmVudCByZWFsbXMsIGFuZCB0aGUgY2xpZW50IGNhbiBkaXNjb3ZlciB0
aGUgc2VydmVyIHBvcnQgZm9yIHRoZSBUVVJOIHNlcnZlciBkb21haW4gdXNpbmcgUy1OQVBUUi4m
bmJzcDsgSSBkb24ndCB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGRpc2N1c3MgZGVwbG95bWVudCBz
cGVjaWZpYyBzb2x1dGlvbnMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPlNv
IGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSB5b3VyIHN0YXRpbmcgdGhhdCBpdCBpcyB1
cCB0byB0aGUgc2VydmVyIGltcGxlbWVudGF0aW9uIHRvIGZpZ3VyZSBvdXQgd2hhdCB0aGUgcmVh
bG0gb24gd2hhdCBldmVyIGluZm9ybWF0aW9uIGlzIGdldHMgYmFzZWQgb24gdGhlIHJlcXVlc3Qu
IEZyb20gYSBjbGllbnQgaW1wbGVtZW50YXRpb24gcGVyc3BlY3RpdmUgaXQgYXBwZWFycyBsZXNz
IGNsZWFyIGlmIGFueXRoaW5nIHRoZSBjbGllbnQNCiB3aWxsIGFmZmVjdCB0aGUgcmVhbG0gcmVz
cG9uc2UgaXQgd2lsbCByZWNlaXZlLiA8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gVGhlIGNsaWVu
dCBjYW5ub3QgYWZmZWN0IHRoZSByZWFsbSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2ZXIsIHNpbWls
YXIgdG8gSFRUUCBhdXRoZW50aWNhdGlvbiB1c2luZyByZWFsbSAocGxlYXNlIHNlZQ0KPGEgaHJl
Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyMzUiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9yZmM3MjM1PC9hPikuPG86cD48L286cD48L3A+DQo8cD5JIGRvbid0IHRoaW5r
IHRoaXMgU2VjdGlvbiAxOCBxdW90ZSBpcyBub3QgY2xlYXIgZWl0aGVyLiA8bzpwPjwvbzpwPjwv
cD4NCjxwPiZuYnNwOyZuYnNwOyBGb2xsb3dpbmcgdGhlIHByb2NlZHVyZXMgb2YgdGhlIGxvbmct
dGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbSBvZjxicj4NCiZuYnNwOyZuYnNwOyBTVFVOIFtJLUQu
aWV0Zi10cmFtLXN0dW5iaXNdLCB0aGUgc2VydmVyIGluY2x1ZGVzIGFuIEVSUk9SLUNPREU8YnI+
DQombmJzcDsmbmJzcDsgYXR0cmlidXRlIHdpdGggYSB2YWx1ZSBvZiA0MDEgKFVuYXV0aG9yaXpl
ZCksIGEgUkVBTE0gYXR0cmlidXRlIHRoYXQ8YnI+DQombmJzcDsmbmJzcDsgc3BlY2lmaWVzIHRo
ZSBhdXRoZW50aWNhdGlvbiByZWFsbSB1c2VkIGJ5IHRoZSBzZXJ2ZXIgKGluIHRoaXMgY2FzZSw8
YnI+DQombmJzcDsmbmJzcDsgdGhlIHNlcnZlcidzIGRvbWFpbiAmcXVvdDtleGFtcGxlLmNvbSZx
dW90OyksIGFuZCBhIG5vbmNlIHZhbHVlIGluIGEgTk9OQ0U8YnI+DQombmJzcDsmbmJzcDsgYXR0
cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0KPHA+U28gSSB3aWxsIG5vdCBwZXJzaXN0IG9uIHRoaXMs
IGJ1dCBJIHdvdWxkIGFwcHJlY2lhdGUgc29tZSBpbmRpY2F0aW9ucyBvbiB0aGF0IHRoZSBzZXJ2
ZXIgbWF5IGRvIG1vcmUgdGhhbiBzaW1wbHkgaGF2ZSBhIHNpbmdsZSByZWFsbSBmb3IgYSBnaXZl
biBzZXJ2ZXIgdHJhbnNwb3J0IGFkZHJlc3MuDQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy
ZT5MLiBTZWN0aW9uIDcuMTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4mbmJzcDsgVGhlIGNsaWVudCB0aGVuIHBpY2tzIGEgdHJhbnNwb3J0IHBy
b3RvY29sIHRvIHVzZSBiZXR3ZWVuIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgYW5kIHRoZSBzZXJ2ZXIuJm5ic3A7IFRoZSB0cmFuc3BvcnQgcHJvdG9jb2wg
TVVTVCBiZSBvbmUgb2YgVURQLCBUQ1AsIFRMUy08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsgb3Zlci1UQ1Agb3IgRFRMUy1vdmVyLVVEUC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIGZpbmQgaXQgc3RyYW5nZSB0aGF0IHRo
aXMgaW5kaWNhdGVzIHRoYXQgb25lIHNob3VsZCBwaWNrIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPnRyYW5zcG9ydCBwcm90b2NvbCB0byB1c2UgY2xpZW50IHRvIHNlcnZlciB3aXRob3V0IGNv
bnNpZGVyaW5nIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZlciBjYXBhYmlsaXRpZXMu
IEVzcGVjaWFsbHkgYXMgdGhlIGNsaWVudCBjb25maWd1cmF0aW9uIG9yIHNlcnZlcjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPmRpc2NvdmVyeSBwcm9jZWR1cmVzIHdpbGwgaW5kaWNhdGUgdHJhbnNw
b3J0IHByb3RvY29sIHN1cHBvcnQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+VGhlIHNlcnZlciBtYXkgc3VwcG9ydCBtb3JlIHRoYW4gb25lIHRyYW5zcG9ydCBwcm90b2Nv
bC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Tb3JyeSwgc2hvdWxkIGhh
dmUgYmVlbiBjbGVhcmVyLiBTaG91bGQgdGhlcmUgYmUgYW55IHJlZmVyZW5jZXMgdG8gaG93IHRo
ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNsaWVudCBjYW4gZGV0ZXJtaW5lIHRoZSBzZXJ2ZXJz
IGNhcGFiaWxpdGllcz8gWW91IGhhdmUgcmVjb21tZW5kYXRpb25zPG86cD48L286cD48L3ByZT4N
CjxwcmU+YWJvdXQgdXNpbmcgVURQIGFuZCBhIHBvaW50ZXIgdG8gU2VjdGlvbiAyLjEgZm9yIHNv
bWUgZGlzY3Vzc2lvbiBvZiB0aGUgY2hvaWNlcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TbyB0
aGF0IGNvdmVycyBnaXZpbmcgc29tZSBndWlkYW5jZSB0byB0aGUgcHJvdG9jb2wgY2hvaWNlLjxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkkgaGF2ZSB1cGRhdGVkIHRoZSB0
ZXh0IGFzIGZvbGxvd3M6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBjbGllbnQgdGhlbiBwaWNrcyBhIHRyYW5zcG9y
dCBwcm90b2NvbCB0byB1c2UgYmV0d2VlbiB0aGUgY2xpZW50PG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGFuZCB0aGUgc2VydmVyIGJhc2VkIG9uIHRoZSB0cmFuc3BvcnQgcHJv
dG9jb2xzIHN1cHBvcnRlZCBieSB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgc2VydmVyLiZuYnNwOyBUaGUgdHJhbnNwb3J0IHByb3RvY29sIE1VU1QgYmUgb25lIG9mIFVE
UCwgVENQLCBUTFMtIG92ZXItVENQIG9yIERUTFMtb3Zlci1VRFAuPG86cD48L286cD48L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7IFNpbmNlIHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGFsbG93cyBV
RFAgYmV0d2VlbiB0aGUgc2VydmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IGFuZCB0aGUgcGVlcnMsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIGNsaWVudCBwaWNrIFVE
UCB1bmxlc3MgaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaGFzIGEgcmVh
c29uIHRvIHVzZSBhIGRpZmZlcmVudCB0cmFuc3BvcnQuJm5ic3A7IE9uZSByZWFzb24gdG8gcGlj
ayBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudCB0cmFuc3Bv
cnQgd291bGQgYmUgdGhhdCB0aGUgY2xpZW50IGJlbGlldmVzLCBlaXRoZXIgdGhyb3VnaDxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9uIG9yIGRpc2NvdmVy
eSBvciBieSBleHBlcmltZW50LCB0aGF0IGl0IGlzIHVuYWJsZSB0bzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBjb250YWN0IGFueSBUVVJOIHNlcnZlciB1c2luZyBVRFAuJm5i
c3A7IFNlZSBTZWN0aW9uIDIuMSBmb3IgbW9yZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPlRoZSBzdWJzZXF1ZW50IHBhcmFncmFwaCBpbiBTZWN0aW9uIDcuMSBk
aXNjdXNzZXMgdXNlIG9mIFtSRkM4MTU1XSB0byBkaXNjb3ZlcnkgVFVSTiBzZXJ2ZXIsIGFuZCB1
c2Ugb2YgW1JGQzU5MjhdIGFuZCBbUkZDNzM1MF0gdG8gZGlzY292ZXIgc2VydmVyIHRyYW5zcG9y
dCBjYXBhYmlsaXRpZXMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5JIHN0
aWxsIHRoaW5rIHRoZSBNVVNUIGlzIHVubmVjZXNzYXJ5IGFuZCBwcm9ibGVtYXRpYy4gVGhlIHBy
b2JsZW0gaXMgdGhhdCBpdCBmaXJzdCBvZiBhbGwgcHJldmVudHMgYW55IGZ1dHVyZSBleHRlbnNp
b24gdG8gdGhlIHRyYW5zcG9ydCBwcm90b2NvbHMgYmUgdXNlZC4gSXNuJ3QgdGhlIHBvaW50LCB0
aGF0IHRoZSBjbGllbnQgcGlja3Mgb25lIG9mIHRoZSBwcm90b2NvbHMgaXQgc3VwcG9ydHM/DQo8
bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gWWVzLjxvOnA+PC9vOnA+PC9wPg0KPHA+TWF5YmUgcmVt
b3ZlIHRoZSBzZW50ZW5jZSBhbmQgc2ltcGx5IGFkZCBzb21ldGhpbmcgYWJvdXQgJnF1b3Q7dGhh
dCB0aGUgY2xpZW50IHN1cHBvcnRzJnF1b3Q7IGluIHRoZSBwcmlvciBzZW50ZW5jZS4NCjxvOnA+
PC9vOnA+PC9wPg0KPHA+W1RSXSBXb3JrcyBmb3IgbWUsIHJlbW92ZWQgdGhlIHNlbnRlbmNlIHdp
dGggTVVTVCBhbmQgbW9kaWZpZWQgdGhlIGZpcnN0IGxpbmUgaW4gdGhlIHBhcmFncmFwaCBhcyBm
b2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlIGNsaWVudCB0aGVuIHBpY2tzIGEgdHJhbnNw
b3J0IHByb3RvY29sIHRoYXQgdGhlIGNsaWVudCBzdXBwb3J0cyB0byB1c2UgYmV0d2VlbiB0aGUg
Y2xpZW50IGFuZCB0aGUgc2VydmVyIGJhc2VkIG9uIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2xzIHN1
cHBvcnRlZCBieSB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+QWxzbyBzaG91
bGRuJ3QgdGhpcyBwYXJhZ3JhcGggY29tZSBiZWZvcmUgdGhlIHByZXZpb3VzIG9uZS4gSS5lLiB0
aGF0IHlvdSBmaXJzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm11c3QgcGljayB5b3VyIHRyYW5z
cG9ydCBwcm90b2NvbCBiZWZvcmUgeW91IGNhbiBwaWNrIGEgaG9zdCB0cmFuc3BvcnQgYWRkcmVz
cyA/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Tm8sIG1pZGRsZS1ib3hl
cyBtYXkgZHJvcCBVRFAgdHJhZmZpYyB0byB0aGUgVFVSTiBzZXJ2ZXIsIGFuZCB0aGUgY2xpZW50
IGJ5IGV4cGVyaW1lbnQgd2lsbCBpZGVudGlmeSB0aGUgdHJhbnNwb3J0IHByb3RvY29sIHBlcm1p
dHRlZCB0byB0aGUgVFVSTiBzZXJ2ZXIgYW5kIGV2ZW50dWFsbHkgdXNlcyB0aGUgPG86cD48L286
cD48L3ByZT4NCjxwcmU+aG9zdCB0cmFuc3BvcnQgYWRkcmVzcyB1c2luZyB3aGljaCBzdWNjZXNz
ZnVsIHJlc3BvbnNlIHdhcyByZWNlaXZlZCBmcm9tIHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwPk9rLiA8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl
PlNlY29uZGx5LCB3aGF0IGlzIHRoZSBtb3RpdmF0aW9uIGZvciB0aGUgTVVTVCBpbiB0aGUgc2Vj
b25kIHNlbnRlbmNlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgaXMgYXBwZWFycyB0byBo
YXZlIHN0cmFuZ2UgaW50ZXJhY3Rpb25zIHdpdGggYW55IGZ1dHVyZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmV4dGVuc2lvbnMgYW5kIGhhdmUgbm8gaW1wYWN0LiBBIGNsaWVudCBtdXN0IG9idmlv
dXMgY2hvc2UgYSBjbGllbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byBzZXJ2ZXIgdHJhbnNw
b3J0IHByb3RvY29sIGl0IHN1cHBvcnRzLCBhbmQgb25lIHRoYXQgdGhlIHNlcnZlcjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPnN1cHBvcnRzIG9yIHRoZSBjbGllbnQgaG9wZSBpdCB3aWxsIHN1cHBv
cnQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjYjc2VjdGlvbi02LjEiPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24tNi4xPC9hPiBoYXMgdGhlIHNhbWUgdGV4dCwg
SSBoYXZlPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+dXBkYXRlZCB0aGUg
dGV4dCBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+VGhlIGNsaWVudCB0aGVu
IHBpY2tzIGEgdHJhbnNwb3J0IHByb3RvY29sIHRvIHVzZSBiZXR3ZWVuIHRoZSBjbGllbnQgYW5k
IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPnNlcnZlciBiYXNlZCBv
biB0aGUgdHJhbnNwb3J0IHByb3RvY29scyBzdXBwb3J0ZWQgYnkgdGhlIHNlcnZlci48bzpwPjwv
bzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPlRoZSBUVVJOIHNlcnZlciBNVVNUIGVuYWJsZSBvbmUgb2YgdGhl
IHRyYW5zcG9ydCBwcm90b2NvbHMsIFVEUCwgVENQLCBUTFMtPG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwcmU+b3Zlci1UQ1Agb3IgRFRMUy1vdmVyLVVEUC48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JZiB0aGUgaW50ZW50aW9u
IGlzIHRvIG1vdmUgdGhlIHJlcXVpcmVtZW50IHRvIHRoZSBzZXJ2ZXIgc2lkZSBmb3IgbWFraW5n
IGl0PG86cD48L286cD48L3ByZT4NCjxwcmU+bm9ybWF0aXZlIHRvIHN1cHBvcnQgYXQgbGVhc3Qg
b25lIG9mIHRoZSA0IG9wdGlvbnMgbGlzdGVkLCBJIHRoaW5rIHlvdSBuZWVkIHRvPG86cD48L286
cD48L3ByZT4NCjxwcmU+cmV3cml0ZSBpdCB0byBzYXk6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QSBUVVJOIHNlcnZlciBNVVNUIGVuYWJsZSBh
dCBsZWFzdCBvbmUgb2YgdGhlIHRyYW5zcG9ydCBwcm90b2NvbHMsIFVEUCwgVENQLDxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPlRMUy0gb3Zlci1UQ1Agb3IgRFRMUy1vdmVyLVVEUC48bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5UaGUgYWJvdmUgcG9pbnQgaXMgYWxyZWFkeSBk
aXNjdXNzZWQgaW4gU2VjdGlvbiA1IGFzIGZvbGxvd3M6PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IFRvIGVuc3VyZSBpbnRlcm9wZXJhYmlsaXR5
LCBhIFRVUk4gc2VydmVyIE1VU1Qgc3VwcG9ydCB0aGUgdXNlIG9mIFVEUDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPiB0cmFuc3BvcnQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLCBh
bmQgU0hPVUxEIHN1cHBvcnQgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+IHVzZSBvZiBUQ1As
IFRMUy1vdmVyLVRDUCBhbmQgRFRMUy1vdmVyLVVEUCB0cmFuc3BvcnRzLjxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlNvLCB0aGlz
IHNlbnRlbmNlIGxheXMgb3V0IHRoZSBpbXBsZW1lbnRhdGlvbiByZXF1aXJlbWVudCBvbiB0aGUg
c2VydmVyIHNpZGUgYW5kIGlzIHZlcnkgcmVhc29uYWJsZSBhbmQgbGlrZWx5IG5lZWRlZC4NCjxv
OnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5NLiBTZWN0aW9uIDcuMTo8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhl
IGNsaWVudCBhbHNvIHBpY2tzIGEgc2VydmVyIHRyYW5zcG9ydCBhZGRyZXNzLCB3aGljaCBTSE9V
TEQgYmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZG9uZSBhcyBmb2xsb3dz
LiZuYnNwOyBUaGUgY2xpZW50IHVzZXMgb25lIG9yIG1vcmUgcHJvY2VkdXJlcyBkZXNjcmliZWQg
aW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgW1JGQzgxNTVdIHRvIGRpc2Nv
dmVyIGEgVFVSTiBzZXJ2ZXIgYW5kIHVzZXMgdGhlIFRVUk4gc2VydmVyPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHJlc29sdXRpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4gW1JG
QzU5MjhdIHRvIGdldCBhIGxpc3Qgb2Ygc2VydmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IHRyYW5zcG9ydCBhZGRyZXNzZXMgdGhhdCBjYW4gYmUgdHJpZWQgdG8gY3JlYXRl
IGEgVFVSTiBhbGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPjEpIFNvIFJGQyA4MTU1IHN0YXRlcyB0aGF0IGl0IGhhcyBubyByZWNv
bW1lbmRhdGlvbiBvbiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZWxlY3Rpb24sIG5v
ciBvbiBob3cgdG8gcmVsYXRlZCBsb2NhbCBjb25maWd1cmF0aW9uIHRvIGFueSBhdXRvLWRpc2Nv
dmVyeTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJl
PnNlcnZlcnMuPG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlRvIG1lIGl0IGFwcGVhcnMgdGhh
dCB0aGUgcHJvdG9jb2wgdXRpbGl6aW5nIFRVUk4gc2hvdWxkIGNvbnNpZGVyPG86cD48L286cD48
L3ByZT4NCjxwcmU+d2hhdCBtYWtlcyBzZW5zZSBpbiB0aGVpciBkZXBsb3ltZW50cy4gVGh1cywg
ZG9lcyB0aGUgbmVlZCBmb3Igc3VjaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNvbnNpZGVyYXRp
b24gbmVlZHMgdG8gYmUgaGlnaGxpZ2h0ZWQgc29tZXdoZXJlIGluIHRoaXMgc3BlY2lmaWNhdGlv
bi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODE1NSNzZWN0aW9uLTMiPmh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9yZmM4MTU1I3NlY3Rpb24tMzwvYT4gZGlzY3Vzc2VzIHVzaW5nIGF1dG8tZGlz
Y292ZXJ5IGluPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+dGhlIGFic2Vu
Y2Ugb2YgbG9jYWwgY29uZmlndXJhdGlvbiBvciBpZiB0aGUgbG9jYWwgY29uZmlndXJhdGlvbiBk
b2VzIG5vdCB3b3JrLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTU1I3NlY3Rpb24tOSI+aHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzgxNTUjc2VjdGlvbi05PC9hPiBleHBsYWlucyB0aGUgbWVjaGFuaXNtcyB0bzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmF1dGhlbnRpY2F0ZSB0aGUgZGlzY292ZXJlZCBUVVJOIHNl
cnZlci48bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGFk
ZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgeW91IGFyZSBsb29raW5nIGluIHRoaXM8bzpwPjwvbzpw
PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5zcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkxldCBtZSBhdHRlbXB0IHRv
IGZvcm11bGF0ZSB0aGUgcXVlc3Rpb24gaW4gYW5vdGhlciB3YXkuIEFzIHRoZSBEaXNjb3Zlcnk8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcm9jZWR1cmUgZG9jdW1lbnRlZCBpbiBSRkMgODE1NSBk
b2VzIG5vdCBtYW5kYXRlIGFueSBzcGVjaWZpYyBvcmRlciBvcjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmV2ZW4gd2hhdCBtZWNoYW5pc21zIGFyZSBhY3R1YWxseSB1c2VkIC8gc3VwcG9ydGVkLCB0
aGVuIGRpZCB0aGUgV0cgY29uc2lkZXI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byBtYWtlIGVp
dGhlciBhIHN0cmljdGVyIHJlY29tbWVuZGF0aW9uIG9yIHNvbWUgb3RoZXIgY29uc2lkZXJhdGlv
bnMgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5iZXR0ZXIgZW5zdXJlIHRoYXQgVFVSTiBjbGll
bnRzIGNhbiBkaXNjb3ZlciBUVVJOIHNlcnZlcnM/PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SXQgaXMgZmluZSB0byBzYXkgbm8uPG86cD48L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Tm8sIGl0IHdhcyBsZWZ0IHRvIGltcGxlbWVu
dGF0aW9uLiBJZiBsb2NhbCBjb25maWd1cmF0aW9uIGRvZXMgbm90IHdvcmsgZm9yIGEgVFVSTiBj
bGllbnQsIFJGQzgxNTUgZXhwbGFpbnMgcGVyZm9ybWluZyBhbGwgdGhlIGRpc2NvdmVyeSBtZWNo
YW5pc21zIHRvIGZpbmQgdGhlIFRVUk4gc2VydmVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr
cXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPk9rYXksIHRoZW4gbGV0cyBkcm9w
IHRoaXMgcG9pbnQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT5PLiBTZWN0aW9uIDcuMTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgSWYgdGhlIGNsaWVudCB3aXNoZXMgdG8gb2J0
YWluIGEgcmVsYXllZCB0cmFuc3BvcnQgYWRkcmVzcyBvZiBhPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljIGFkZHJlc3MgdHlwZSB0aGVuIGl0IGluY2x1ZGVzIGEg
UkVRVUVTVEVELUFERFJFU1MtRkFNSUxZPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGF0dHJpYnV0ZSBpbiB0aGUgcmVxdWVzdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIGRvbid0IGZpbmQgYW55dGhpbmcgZGVzY3JpYmlu
ZyB3aGF0IHRoZSBkZWZhdWx0IGJlaGF2aW9yIGlzIGlmIG9uZTxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPmRvZXNuJ3QgaW5jbHVkZSB0aGUgYXR0cmlidXRlLCBidXQgdGhlIFRVUk4gc2VydmVyIHN1
cHBvcnRzIG11bHRpcGxlIGFkZHJlc3M8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PC9ibG9ja3F1b3RlPg0KPHByZT5mYW1pbGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
SSBzZWUgdGhhdCBidWxsZXQgNyBpbiBTZWN0aW9uIDcuMiBpbmRpY2F0ZXMgdGhhdCBJUHY0IGlz
IGRlZmF1bHQuPG86cD48L286cD48L3ByZT4NCjxwcmU+U2hvdWxkIHRoZSB0ZXh0IGluIDcuMSBi
ZSBleHBsaWNpdCBhYm91dCB0aGlzIGRlZmF1bHQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjxwcmU+VGhlIHRleHQgaW4gU2VjdGlvbiA3LjEgaXMgYWRkZWQgZm9yIFRVUk4gY2xp
ZW50cyBub3Qgc3VwcG9ydGluZyBUVVJOYmlzPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwcmU+c3BlY2lmaWNhdGlvbiB0byBwcm92aWRlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHku
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QnV0
IGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgdGhlIGxlZ2FjeSB3YXkgaXMgdG8gbm90
IGluY2x1ZGUgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+UkVRVUVTVEVELUFERFJFU1MtRkFN
SUxZIGF0dHJpYnV0ZSBmb3IgYW4gSVB2NCBhZGRyZXNzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZT5ZZXMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwcmU+VGh1cywgc2hvdWxkbid0IGE8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT5zZW50ZW5jZSBiZSBhZGRlZCBhZnRlciB0aGUgYWJvdmUgdG8gc3RhdGUgdGhhdCBpZiB0
aGUgY2xpZW50IHdhbnRzIGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+SVB2NCBhZGRyZXNzIGl0
IHNob3VsZCBza2lwIHVzaW5nIFJFUVVFU1RFRC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgdG88
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lbmFibGUgbGVnYWN5IGludGVyb3BlcmFiaWxpdHksIG9y
IGRvIEkgbWlzc3VuZGVyc3RhbmQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+UkVRVUVTVC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUgaXMgaW5pdGlhbGx5IGRlZmluZWQg
aW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYxNTYiPmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTU2PC9hPiBhcyBjb21wcmVoZW5zaW9uLXJlcXVpcmVk
IGF0dHJpYnV0ZS4gSWYgdGhlIGxlZ2FjeSBzZXJ2ZXIgZG9lcyBub3QgdW5kZXJzdGFuZCB0aGlz
IGF0dHJpYnV0ZSwgdGhlIHJlcXVlc3Qgd2lsbCBiZSByZWplY3RlZCAoNDIwIChVbmtub3duIEF0
dHJpYnV0ZSksIGFuZCBpZiB0aGUgY2xpZW50IHdhbnRzIElQdjQgcmVsYXllZCB0cmFuc3BvcnQg
YWRkcmVzcywgdGhlIGNsaWVudCB3aWxsIGhhdmUgdG8gcmV0cnkgdGhlIHJlcXVlc3Qgd2l0aG91
dCB0aGUgUkVRVUVTVC1BRERSRVNTLUZBTUlMWSBhdHRyaWJ1dGUuPG86cD48L286cD48L3ByZT4N
CjwvYmxvY2txdW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+T2theSwgdGhlbiBJ
IHRoaW5rIHRoaXMgaXNzdWUgY2FuIGJlIGNsb3NlZC4gPG86cD48L286cD48L3A+DQo8cD48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
cmU+US4gU2VjdGlvbiA4LjM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSBzdWNj
ZXNzIHJlc3BvbnNlIHRvIGl0cyBSZWZyZXNoIHJlcXVlc3Qgd2l0aDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOyZuYnNwOyBhIG5vbi16ZXJvIGxpZmV0aW1lLCBpdCB1cGRhdGVzIGl0cyBj
b3B5IG9mIHRoZSBhbGxvY2F0aW9uIGRhdGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm
bmJzcDsgc3RydWN0dXJlIHdpdGggdGhlIHRpbWUtdG8tZXhwaXJ5IHZhbHVlIGNvbnRhaW5lZCBp
biB0aGUgcmVzcG9uc2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSA0MzcgKEFs
bG9jYXRpb24gTWlzbWF0Y2gpIGVycm9yIHJlc3BvbnNlIHRvPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGEgcmVxdWVzdCB0byBkZWxldGUgdGhlIGFsbG9jYXRpb24sIHRoZW4g
dGhlIGFsbG9jYXRpb24gbm8gbG9uZ2VyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i
c3A7IGV4aXN0cyBhbmQgaXQgc2hvdWxkIGNvbnNpZGVyIGl0cyByZXF1ZXN0IGFzIGhhdmluZyBl
ZmZlY3RpdmVseTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzdWNjZWVkZWQu
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U28g
dGhlcmUgYXJlIG5vIGNvbnNpZGVyYXRpb25zIGZvciB0aGUgY2xpZW50IGlmIGl0IHJlY2VpdmVz
IGFuIGVycm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+cmVzcG9uc2UgdG8gYSByZWZyZXNoIHJl
cXVlc3Qgd2hlbiBMaWZldGltZSB3YXMgbm9uLXplcm8/PG86cD48L286cD48L3ByZT4NCjxwcmU+
PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBhbSBiaXQgc3VycHJpc2VkIGJ5IHRoYXQu
IEkgYXNzdW1lIHRoYXQgdGhlcmUgYXJlIGNlcnRhaW4gY2FzZXM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT53aGVuIHRoZSByZXF1ZXN0IGNvdWxkIGJlIHJlc2VudCwgYW5kIG90aGVycyB3aGVyZSB0
aGUgbWVhbmluZyBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgdGhlIGFsbG9jYXRpb24g
aXMgZ29uZS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5UVVJOYmlzIGRv
ZXMgbm90IHVwZGF0ZSB0aGUgcmVmcmVzaCBiZWhhdmlvciBhbHJlYWR5IGRlZmluZWQgaW48bzpw
PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNTc2NiNzZWN0aW9uLTcuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzU3NjYjc2VjdGlvbi03LjM8L2E+LiZuYnNwOyBJIHdpbGwgYWRkIHRoZSBmb2xs
b3dpbmcgbGluZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPklmIHRoZSBjbGllbnQgcmVjZWl2
ZXMgYW4gZXJyb3IgcmVzcG9uc2UgdG8gaXRzIHJlcXVlc3QgdG8gcmVmcmVzaCB0aGUgYWxsb2Nh
dGlvbiw8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5pdCBzaG91bGQgY29u
c2lkZXIgdGhlIGFsbG9jYXRpb24gbm8gbG9uZ2VyIGV4aXN0cy48bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Jc24ndCB0aGF0IG92ZXIgc2ltcGxp
ZnlpbmcgY2FzZXMgd2hlcmUgb25lIGF0dGVtcHRzIHRvIHJlZnJlc2ggYW4gYWxsb2NhdGlvbjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFuZCBjb3VsZCBhY3R1YWxseSBoYW5kbGUgdGhlIGlzc3Vl
LiBGb3IgZXhhbXBsZSBhbiBlcnJvciByZXNwb25zZSB0byB0aGUgY2xpZW50PG86cD48L286cD48
L3ByZT4NCjxwcmU+b2YgNDM4IChTdGFsZSBOb25jZSkmbmJzcDsgd2hlcmUgdGhlIGNsaWVudCBj
YW4gcmV0cnkgdGhlIHJlcXVlc3Qgd2l0aCB0aGUgbmV3PG86cD48L286cD48L3ByZT4NCjxwcmU+
Tm9uY2UuIEkgYWxzbyB3b25kZXIgaWYgcmVxdWVzdCB0aW1lIG91dCBhcyB3ZWxsIGFzIDQwMCAo
aWYgaXQgY2FuIGZpZ3VyZSBvdXQgd2hhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBpc3N1
ZSB3YXMpIGNvdWxkIGJlIHJlLWF0dGVtcHRlZCBwcmlvciB0byBhbGxvY2F0aW9uIGV4cGlyZXMu
IEJ1dCBhdCBsZWF0IGh0ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjQzOCBhcHBlYXJzIHRvIGlu
ZGljYXRlIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBjbGllbnQgc2hvdWxkIG5vdCBnaXZlIHVwLCBh
bmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aHVzIHNob3VsZCBoYXZlIHNvbWUgdGV4dCBoZXJl
LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkdvb2QgcG9pbnQsIE1vZGlm
aWVkIHRoZSBhYm92ZSBsaW5lIGZvbGxvd3M6PG86cD48L286cD48L3ByZT4NCjxwcmU+SWYgdGhl
IGNsaWVudCByZWNlaXZlcyBhIDQzNyAoQWxsb2NhdGlvbiBNaXNtYXRjaCkgZXJyb3IgcmVzcG9u
c2UgdG8gaXRzIHJlcXVlc3QgdG8gcmVmcmVzaCB0aGUgYWxsb2NhdGlvbiwgaXQgc2hvdWxkIGNv
bnNpZGVyIHRoZSBhbGxvY2F0aW9uIG5vIGxvbmdlciBleGlzdHMuIElmIHRoZSBjbGllbnQgcmVj
ZWl2ZXMgYSA0MzggKFN0YWxlIE5vbmNlKSBlcnJvciB0byBpdHMgcmVxdWVzdCB0byByZWZyZXNo
IHRoZSBhbGxvY2F0aW9uLCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pdCBzaG91bGQgcmVhdHRl
bXB0IHRoZSByZXF1ZXN0IHdpdGggdGhlIG5ldyBub25jZSB2YWx1ZS48bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHA+R29vZCB3b3JrcyBmb3IgbWUuIDxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cHJlPlIuIFNlY3Rpb24gMTEuNTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgV2hlbiB0aGUgc2VydmVy
IHJlY2VpdmVzIGFuIElDTVAgcGFja2V0LCB0aGUgc2VydmVyIHZlcmlmaWVzIHRoYXQgdGhlPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHR5cGUgaXMgZWl0aGVyIDMsIDExIG9y
IDEyIGZvciBhbiBJQ01QdjQgW1JGQzA3OTJdIHBhY2tldCBvciBlaXRoZXI8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgMSwgMiwgb3IgMyBmb3IgYW4gSUNNUHY2IFtSRkM0NDQz
XSBwYWNrZXQuJm5ic3A7IEl0IGFsc28gdmVyaWZpZXMgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsgSVAgcGFja2V0IGluIHRoZSBJQ01QIHBhY2tldCBwYXlsb2Fk
IGNvbnRhaW5zIGEgVURQIGhlYWRlci4mbmJzcDsgSWY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m
bmJzcDsmbmJzcDsgZWl0aGVyIG9mIHRoZXNlIGNvbmRpdGlvbnMgZmFpbCwgdGhlbiB0aGUgSUNN
UCBwYWNrZXQgaXMgc2lsZW50bHk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
ZHJvcHBlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0K
PHByZT5XaHkgaXMgbm90IElDTVB2NiBUeXBlIDQgKFBhcmFtZXRlciBQcm9ibGVtKSBpbmNsdWRl
ZCB3aGVuIFBhcmFtZXRlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlByb2JsZW0gYXJlIGZvciBJ
Q01QdjQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSBkb24ndCBnZXQg
dGhlIGFib3ZlIGNvbW1lbnQsIHBsZWFzZSBleHBsYWluIHRoZSBxdWVzdGlvbiB3aXRoIGFuIGV4
YW1wbGUuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+U28gaWYgYSBzZXJ2
ZXIgcmVjZWl2ZXMgYW4gSUNNUCBmb3Igc2VudCBwYWNrZXQgd2l0aCBJQ01QdjQgdHlwZSAxMjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPihQYXJhbWV0ZXIgUHJvYmxlbSkgdGhlbiB0aGF0IGlzIHJl
bGF5ZWQgdG8gdGhlIGNsaWVudCBhY2NvcmRpbmcgdG8gdGhpcyB0ZXh0LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkJ1dCBpZiB0aGUgc2VydmVyIHNlbnQgYSBwYWNrZXQgd2l0aCBJUHY2IHRvd2Fy
ZHMgdGhlIHBlZXIgYW5kIHJlY2VpdmVzIGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+SUNNUHY2
IG1lc3NhZ2Ugd2l0aCBUeXBlIDQgKFBhcmFtZXRlciBQcm9ibGVtKSB0aGF0IGlzIG5vdCByZWxh
eWVkIHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNsaWVudC4gV2h5IHRoaXMgZGlzY3Jl
cGFuY3k/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+VGhhbmtzLCBnb3Qg
dGhlIGNvbW1lbnQuIElDTVB2NCBhbmQgSUNNUHY2IGVycm9yIG1lc3NhZ2UgKFBhcmFtZXRlciBw
cm9ibGVtKSBuZWVkIG5vdCBiZSByZWxheWVkIGJhY2sgdG8gdGhlIGNsaWVudCBiZWNhdXNlIElQ
djYgZXh0ZW5zaW9uIGhlYWRlciBhbmQgSVB2NCBvcHRpb24gc2V0IGluIHRoZSBwYWNrZXQgZnJv
bSB0aGUgY2xpZW50IHdpbGwgbm90IGJlIHJlbGF5ZWQgdG8gdGhlIHBlZXIgKFBsZWFzZSBzZWUg
PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJu
YmlzLTIzI3NlY3Rpb24tMTQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LXRyYW0tdHVybmJpcy0yMyNzZWN0aW9uLTE0PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTIzI3NlY3Rpb24tMTMuMiI+
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTIzI3Nl
Y3Rpb24tMTMuMjwvYT4pLiZuYnNwOyBSZW1vdmVkIElDTVB2NCAxMiB0eXBlLiBBZGRlZCB0aGUg
Zm9sbG93aW5nIGxpbmVzIHRvIFNlY3Rpb24gMTYuMyB0byBjb252ZXkgdGhlIE1UVSBvZiB0aGUg
bmV4dC1ob3AgbGluazo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRXJyb3IgRGF0YTombmJzcDsgVGhpcyBmaWVsZCBzaXpl
IGlzIDQgYnl0ZXMgbG9uZy4mbmJzcDsgSWYgdGhlIElDTVB2NiB0eXBlIGlzPG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIgKFBhY2tldCBUb28g
QmlnIE1lc3NhZ2UpIG9yIElDTVB2NCB0eXBlIGlzIDMgKCBEZXN0aW5hdGlvbjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVbnJlYWNoYWJsZSkg
YW5kIENvZGUgaXMgNCAoZnJhZ21lbnRhdGlvbiBuZWVkZWQgYW5kIERGIHNldCksIHRoZTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFcnJvciBE
YXRhIGZpZWxkIHdpbGwgYmUgc2V0IHRvIHRoZSBNYXhpbXVtIFRyYW5zbWlzc2lvbiBVbml0IG9m
PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo
ZSBuZXh0LWhvcCBsaW5rIChTZWN0aW9uIDMuMiBvZiBbUkZDNDQ0M10pIGFuZCBTZWN0aW9uIDQg
b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
W1JGQzExOTFdKS4mbmJzcDsgRm9yIG90aGVyIElDTVB2NiB0eXBlcyBhbmQgSUNNUHY0IHR5cGVz
IGFuZCBjb2RlcywgPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7RXJyb3IgRGF0YSBmaWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvLjxvOnA+PC9vOnA+
PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPlRoYW5r
cywgdGhhdCBjbGFyaWZpY2F0aW9uLiBJc3N1ZSByZXNvbHZlZC4gPG86cD48L286cD48L3A+DQo8
cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cHJlPlUuIFNlY3Rpb24gMTMuIDEsMiwzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGb3Ig
Ym90aCBwcmVmZXJyZWQgYW5kIGFsdGVybmF0ZSBiZWhhdmlvciwgdGhlIERPTlQtRlJBR01FTlQ8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXR0
cmlidXRlIE1VU1QgYmUgaWdub3JlZCBieSB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkg
anVzdCBiZWNhdXNlIG9uZSBwZXJmb3JtcyB2NCZsdDstJmd0O3Y2IG9yIHY2IHRvIHY0PG86cD48
L286cD48L3ByZT4NCjxwcmU+dHJhbnNsYXRpb24gb3IgdjYgdG8gdjYgcmVsYXlpbmcgbm93IGNh
biBpZ25vcmUgdGhlIERPTlQtRlJBR0VNRU5UPG86cD48L286cD48L3ByZT4NCjxwcmU+YXR0cmli
dXRlLiBJZiB0aGUgY2xpZW50IGhhcyByZXF1ZXN0IHRvIG5vdCBmcmFnbWVudCBhbmQgdGhlIHNl
cnZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmlzIHVuYWJsZSB0byBkbyB0aGF0IHdoZW4gZm9y
d2FyZGluZyB0byB0aGUgcGVlciBpdCBuZWVkcyB0byBnZW5lcmF0ZTxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmFuIElDTVAgYXR0cmlidXRlIHJlc3BvbnNlIHNheWluZyB0aGUgcGFja2V0IGlzIHRv
IGJpZy4gT3RoZXJ3aXNlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJlbGF5IGJyZWFrcyB0
aGUgUGF0aCBNVFUgZGlzY292ZXJ5IG1lY2hhbmlzbXMuPG86cD48L286cD48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+VFVSTmJpcyBpcyB1c2luZyB0aGUgdHJhbnNsYXRpb24gYWxnb3JpdGht
cyBzcGVjaWZpZWQgaW4gUkZDNzkxNS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5bYV0gRm9yIElQdjQgdG8gSVB2NjogVGhlIHRyYW5zbGF0b3Ig
dXNlcyB0aGUgREYgYml0IGluIHRoZSBJUHY0IGhlYWRlciB0byBub3Q8bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT5mcmFnbWVudCB0aGUgSVB2NiBwYWNrZXQgKHNlZSA8YSBo
cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkxNSNzZWN0aW9uLTQiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTE1I3NlY3Rpb24tNDwvYT4pLDxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPkRPTidULUZSQUdNRU5UIGF0dHJpYnV0ZSBjYW4gYmUgaWdub3JlZC48bzpw
PjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu
LWJvdHRvbTo1LjBwdCI+DQo8cHJlPltiXSBGb3IgSVB2NiB0byBJUHY0OiBUaGUgdHJhbnNsYXRp
b24gYWxnb3JpdGhtIGluPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PGEg
aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5MTUjc2VjdGlvbi01Ij5odHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkxNSNzZWN0aW9uLTU8L2E+IGlzIHVzZWQuJm5i
c3A7IElmIHRoZSBJUHY2IGVuZHBvaW50IHdhbnRzPG86cD48L286cD48L3ByZT4NCjxwcmU+dG8g
ZGlzY292ZXIgdGhlIHBhdGggTVRVLCBpdCB3aWxsIHNlbmQgSVB2NiBwYWNrZXRzIHdpdGhvdXQg
RnJhZ21lbnQgaGVhZGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+YW5kIERPTidULUZSQUdNRU5U
IGF0dHJpYnV0ZSBjYW4gYmUgaWdub3JlZC48bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPltjXSBG
b3IgSVB2NiB0byBJUHY2OiBJZiB0aGUgSVB2NiBlbmRwb2ludCB3YW50cyB0byBkaXNjb3ZlciB0
aGUgcGF0aCBNVFUsIGl0PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+d2ls
bCBzZW5kIElQdjYgcGFja2V0cyB3aXRob3V0IEZyYWdtZW50IGhlYWRlciBhbmQgRE9OJ1QtRlJB
R01FTlQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hdHRyaWJ1dGUgY2FuIGJlIGlnbm9yZWQuPG86
cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHByZT5QbGVhc2Ugbm90ZSBpZ25vcmluZyB0aGUgRE9OVC1GUkFH
TUVOVCBhdHRyaWJ1dGUgaXMgcGlja2VkIGZyb208bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHByZT48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjE1NiNz
ZWN0aW9uLTgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MTU2I3NlY3Rpb24tODwv
YT4gYW5kIGRpc2N1c3NlZCBpbiB0aGUgQkVIQVZFIFdHPG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iZWhhdmUvb2Fi
dTBWdFVNQkUtWDMtdmhnamRTRkNib3hjIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy
Y2gvbXNnL2JlaGF2ZS9vYWJ1MFZ0VU1CRS1YMy12aGdqZFNGQ2JveGM8L2E+LjxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyBmb3IgdGhl
IGNsYXJpZmljYXRpb24gb24gdGhlIGNvbnRleHQuIEkgc2hvdWxkIGhhdmUgcmVhZCBTZWN0aW9u
PG86cD48L286cD48L3ByZT4NCjxwcmU+NCBvZiA3OTE1LiBUaGVuIEkgd291bGQgaGF2ZSBsaWtl
bHkgZ290dGVuIHRoZSBpbXBsaWNhdGlvbiB0aGF0IHRoZSBJUCBoZWFkZXIgREY8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5vciBGcmFnbWVudGF0aW9uIGhlYWRlciBpbXBhY3RzIGhvdyB0aGluZ3Mg
YXJlIHdvcmtpbmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By
ZT4NCjxwcmU+SG93ZXZlciwgSSBmaW5kIHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgY2hvaWNl
IHZlcnkgc3RyYW5nZS4gSSBkb24ndCBzZWUgaG93PG86cD48L286cD48L3ByZT4NCjxwcmU+eW91
IGNhbiBpbXBsZW1lbnQgYSBUVVJOIHNlcnZlciB0aGF0IGRvZXMgSVB2NCAmbHQ7LSZndDtJUHY2
LCBvciBJUHY2IHJlbGF5aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+d2l0aG91dCBoYXZpbmcg
cHJpdmlsZWdlZCBhY2Nlc3MgYW5kIHdoZXJlIGl0IHJlYWRzIHRoZSByYXcgaGVhZGVycy4gQW48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiBVRFAgc29ja2V0
cyB3aWxsIG5vdCBiZSBhYmxlIHRvIGRvIHRoZSByaWdodCB0aGluZzxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPmhlcmUgdG8gbXkgdW5kZXJzdGFuZGluZy4gSG93ZXZlciwgaXQgY291bGQgZm9sbG93
IHRoZSBET05ULUZSQUdNRU5UPG86cD48L286cD48L3ByZT4NCjxwcmU+YXR0cmlidXRlIHRvIGlu
c3RydWN0aW5nIHRoZSBzZW5kaW5nIHVzaW5nIHRoZSBTb2NrZXQgdG8gZG8gdGhlIHJpZ2h0IHRo
aW5nLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkFzIHBlciB0aGUgZGlz
Y3Vzc2lvbiBpbiBCRUhBVkUgV0csIGl0IHNlZW1zIHBvc3NpYmxlIHRvIHNldCBhbmQgZ2V0IHZh
cmlvdXMgSVAgaGVhZGVyIGZpZWxkcyB1c2luZyBzb2NrZXRzLCBzZWUgPGEgaHJlZj0iaHR0cHM6
Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9iZWhhdmUvajZGZnpnVkx1U2VIZk9Xejl6
Uk81aVBDcDk4Ij5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2JlaGF2ZS9q
NkZmemdWTHVTZUhmT1d6OXpSTzVpUENwOTg8L2E+IGFuZCA8YSBocmVmPSJodHRwczovL21haWxh
cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2JlaGF2ZS8zSS1EdnRWZl80Y0djRG5Ja3RzV05FdGZJ
WU0iPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYmVoYXZlLzNJLUR2dFZm
XzRjR2NEbklrdHNXTkV0ZklZTTwvYT4uIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSB0aGluayB0aGVyZSBhcmUgdHdvIGRpcmVjdGlvbnMg
d2UgY2FuIHByb2NlZWQgaW4gaGVyZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4xLiBSZWRlZmluZSB0aGlzIHRleHQgdG8gZW5hYmxlIHVzYWdl
IG9mIERPTlQtRlJBR01FTlQ8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5J
IHByZWZlciBub3QgdG8gY2hhbmdlIHRoZSBiZWhhdmlvciBkaXNjdXNzZWQgYW5kIGZpbmFsaXpl
ZCBmb3IgUkZDNjE1NiBpbiBCRUhBVkUgV0cuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5vcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjIuIENsYXJpZnkgdGhlIHNjb3BlIGFuZCBpbXBsaWNh
dGlvbnMgb2YgVW5wcml2aWxpZ2VkIFRVUk4gU2VydmVyIGRvaW5nPG86cD48L286cD48L3ByZT4N
CjxwcmU+dHJhbnNsYXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Gb3IgdGhlIHNlY29u
ZCBvcHRpb24gSSB0aGluayB0aGVyZSBhcmUgc2V2ZXJhbCBhc3BlY3RzIHRoYXQgSSBsaWtlIHRv
IHNlZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFkZHJlc3NlZDo8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgMmE6IFVwZGF0ZSB0aGUg
c2VudGVuY2UgSSBxdW90ZWQgZm9yIHRoaXMgaXNzdWUgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHlv
dSBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWx5aW5nIHNvbGVseSBvbiBJUHY0IERGIGFu
ZCBJUHY2IEZyYWdtZW50YXRpb24gSGVhZGVyIHRvIGNvbnRyb2wgdGhlPG86cD48L286cD48L3By
ZT4NCjxwcmU+ZnJhZ21lbnRhdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K
PHByZT5BZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgdG8gUGFja2V0IFRyYW5zbGF0aW9ucyAoU2Vj
dGlvbiAxMy42KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgVFVSTiBzZXJ2ZXIgc29sZWx5
IHJlbGllcyBvbiB0aGUgREYgYml0IGluIHRoZSBJUHY0IGhlYWRlciBhbmQgRnJhZ21lbnRhdGlv
biBoZWFkZXIgaW4gSVB2NiBoZWFkZXIgdG8gaGFuZGxlIGZyYWdtZW50YXRpb24gYW5kIGRvZXMg
bm90IHJlbHkgb24gdGhlIERPTlQtRlJBR01FTlQgYXR0cmlidXRlLiA8bzpwPjwvbzpwPjwvcHJl
Pg0KPC9ibG9ja3F1b3RlPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5UaGFua3MsIHRo
YXQgY2xhcmlmaWVzIHRoYXQgYXNwZWN0LiA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiZu
YnNwOyAyYjogQ2xhcmlmeSB0aGF0IFVucHJpdmlsaWdlZCBUVVJOIFNldmVycyB0aGF0IGRvIElQ
djQmbHQ7LSZndDsgSVB2NiB0cmFuc2xhdGlvbiB3aWxsPG86cD48L286cD48L3ByZT4NCjxwcmU+
bm90IGhhbmRsZSBmcmFnbWVudGF0aW9uIHdlbGwuIEFuZCBpbmNsdWRlIGEgcG9pbnQgdG8gdGhl
IGxhc3QgcGFyYWdyYXBoIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VjdGlvbiAyLjcgYW5k
IHRoZSB1c2Ugb2YgRE9OVC1GUkFHTUVOVCBJbiBBbGxvY2F0ZSByZXF1ZXN0cyB0byBkZXRlcm1p
bmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdXBwb3J0IGFuZCB0aGF0IHRoZXNlIG5lZWRzIHRv
IGJlIHJlamVjdGVkIGJ5IHN1Y2ggYSBzZXJ2ZXIuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjxwcmU+RGVwZW5kaW5nIG9uIHRoZSBPUywgVW5wcml2aWxlZ2VkIFRVUk4gU2V2ZXJz
IG1heSBvciBtYXkgbm90IGhhbmRsZSBmcmFnbWVudGF0aW9uIChpLmUuIGhhdmUgYWNjZXNzIHRv
IERGIGJpdCkuJm5ic3A7IEkgd2lsbCBhZGQgdGhlIGZvbGxvd2luZyBsaW5lOiA8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT5JZiB0aGUgVFVSTiBzZXJ2ZXIgY2Fycnlpbmcgb3V0IHBhY2tldCB0cmFu
c2xhdGlvbiBmcm9tIElQdjQtdG8tSVB2NiBjYW5ub3QgZ2V0IHRoZSBEb24ndCBGcmFnbWVudCAo
REYpIGJpdCBpbiB0aGUgSVB2NCBoZWFkZXIsIGl0IE1VU1QgcmVqZWN0IHRoZSBBbGxvY2F0ZSBy
ZXF1ZXN0IHdpdGggRE9OVC1GUkFHTUVOVCBhdHRyaWJ1dGUuPG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwPlRoaXMgaXMgYWxzbyBnb29kLiBUaGluayB0aGVzZSB0d28gY2hhbmdz
IHJlc29sdmUgdGhlIGlzc3VlLiA8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkJ5IHRoZSB3
YXksIHRoZXJlIG11c3QgYmUgYSB0eXBvIHdpdGggYSAmcXVvdDtub3QmcXVvdDsgdGhhdCBzaG91
bGRuJ3QgYmUgaW4gdGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcmFncmFwaCBpbiBTZWN0
aW9uIDQgb2YgNzkxNTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgV2hlbiB0aGUgSVB2NCBzZW5kZXIgZG9lcyBub3Qgc2V0
IHRoZSBERiBiaXQsIHRoZSB0cmFuc2xhdG9yIE1VU1QgTk9UPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGluY2x1ZGUgdGhlIEZyYWdtZW50IEhlYWRlciBmb3IgdGhlIG5vbi1m
cmFnbWVudGVkIElQdjYgcGFja2V0cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5UbyBtZSBpdCBtYWtlIHNlbnNlIGZvciBhIElQdjQtJmd0O0lQ
djYgdHJhbnNsYXRpb24gd2hlcmUgdGhlIElQdjQgaGFzIERGPVRSVUU8bzpwPjwvbzpwPjwvcHJl
Pg0KPHByZT50byBub3QgaW5jbHVkZSB0aGUgZnJhZ21lbnRhdGlvbiBoZWFkZXIsIGRvIHlvdSBh
Z3JlZT88bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48YSBocmVmPSJodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzkxNSNzZWN0aW9uLTQuMSI+aHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzc5MTUjc2VjdGlvbi00LjE8L2E+IHNheXMgdG8gaW5jbHVkZSB0
aGUgZnJhZ21lbnQgaGVhZGVyIG9ubHkgd2hlbiBJUHY0IGhlYWRlciBoYXMgREY9MCBhbmQgdGhl
IHBhY2tldCBzaXplIGV4Y2VlZHMgdGhlIE1UVS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHA+T2theSwgSSB0aGluayBJIHVuZGVyc3RhbmQgdGhlIHRleHQgYW5kIHRoYXQgaXQg
aXMgbm90IGEgcmVhbCBpc3N1ZS4gPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5YLiBTZWN0aW9uIDE0OjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhvdyBhcmUgdGhlc2UgSVAgbGV2
ZWwgZmllbGRzIGhhbmRsZWQgd2hlbiB0aGUgdHJhbnNwb3J0IGlzIFRDUCBvciBUTFMvVENQPzxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZXJlIHRoZXJlIGFyZSBub3QgbmVjZXNzYXJ5IGEgb25l
IHRvIG9uZSBtYXBwaW5nIGJldHdlZW4gZGF0YWdyYW1zPG86cD48L286cD48L3ByZT4NCjxwcmU+
YW5kIFRDUCBwYWNrZXRzLiBBbmQgaWYgdGhlcmUgYXJlIG5vIHN1cHBvcnQgdGhlbiB0aGVyZSBh
cmUgbmVlZCBmb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jbGFyaWZpY2F0aW9uIG9mIGJlaGF2
aW9ycyB3aGVuIHVzaW5nIFRDUCBiYXNlZCB0cmFuc3BvcnQuPG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwcmU+U2VjdGlvbiAxNCBhbHJlYWR5IGNsYXJpZmllcyB0aGF0IHRoZSBk
ZXNjcmlwdGlvbnMgaW4gdGhpcyBzZWN0aW9uIGRvIG5vdCBhcHBseSB0bzxvOnA+PC9vOnA+PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPlRVUk4gbWVzc2FnZXMgc2VudCBvdmVyIFRDUCBvciBU
TFMgdHJhbnNwb3J0IGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlllcyB5b3UgYXJlIHJpZ2h0
LiBXaGF0IGFyZSB0aGUgcmVjb21tZW5kYXRpb25zIGZvciBob3cgdG8gc2V0IHRoZSBmaWVsZHM8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aGVuIHRoZSBDaGFubmVsIG1lc3NhZ2Ugb3IgU2VuZCBJ
bmRpY2F0aW9uIGFycml2ZXMgb3ZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRDUC8oVExTKSB0
byB0aGUgc2VydmVyPyBUbyBtZSB0aGUgYmFzaXMgaXMgdGhlIGFsdGVybmF0aXZlIGJlaGF2aW9y
IHdpdGggdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+ZXhjZXB0aW9uIGZvciB0aGUgREYgYml0
LiBIb3dldmVyLCBiZWhhdmlvcnMgZm9yIGRhdGFncmFtcyBvcmlnbmF0ZWQgYnkgdGhlPG86cD48
L286cD48L3ByZT4NCjxwcmU+c2VydmVyIGFuZCBkZWxpdmVyZWQgdG8gdGhlIHNlcnZlciBvdmVy
IG5vbiBkYXRhZ3JhbSB0cmFuc3BvcnQgd2lsbCBuZWVkIHRvPG86cD48L286cD48L3ByZT4NCjxw
cmU+aGF2ZSByZWNvbW1lbmRhdGlvbnMgYWxzbyBmb3IgSVB2Ni48bzpwPjwvbzpwPjwvcHJlPg0K
PC9ibG9ja3F1b3RlPg0KPHByZT5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgc3RhbmRhcmQgMToxIG1h
cHBpbmcgb2YgSVAgbGV2ZWwgZmllbGRzIGJldHdlZW4gVURQIGFuZCBUQ1AsICZuYnNwOzxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24tMTIiPmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzY2I3NlY3Rpb24tMTI8L2E+IGRvZXMgbm90IGRl
ZmluZSB0aGUgYmVoYXZpb3IgdG8gc2V0IHRoZSBmaWVsZHMsIHRoZSB0b3BpYyB3YXMgZGlzY3Vz
c2VkIGluIEJFSEFWRSBXRyA8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy
Y2gvbXNnL2JlaGF2ZS9RQlphWWdrLXg1bFpORnBFNHFDTGl6dGNnOFkiPmh0dHBzOi8vbWFpbGFy
Y2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvYmVoYXZlL1FCWmFZZ2steDVsWk5GcEU0cUNMaXp0Y2c4
WTwvYT4gYW5kIHRoZSBkZWNpc2lvbiB3YXMgdG8gZm9jdXMgb25seSBvbiBVRFAgdG8gVURQIGNh
c2UuJm5ic3A7IFdoYXQgc3BlY2lmaWMgY2hhbmdlIGFyZSB5b3UgcHJvcG9zaW5nIGluIHRoaXMg
U2VjdGlvbiA/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPlNvIEkgYW0gbm90
IGFza2luZyBmb3IgYSAxOjEgbWFwcGluZy4gV2hhdCBJIHNlZSBhcyBtaXNzaW5nIGlzIHRoZSBk
ZWZpbml0aW9uIG9mIGhvdyBzaGFsbCBiZSBzZXQgaW4gVURQIHBhY2tldHMgc2VudCBvdXQgZnJv
bSB0aGUgVFVSTiBzZXJ2ZXIsIGFuZCBob3cgdG8gZGVhbCB3aXRoIGFueSBpbmZvcm1hdGlvbiBp
biB0aGUgaW5jb21pbmcgcGFja2V0cy4gSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IHNo
b3VsZCBoYXZlIHJlY29tbWVuZGF0aW9ucw0KIGFzIG5vdCBiZWluZyBvYnZpb3VzIGZvciBldmVy
eW9uZSwgYnV0IGF0IHRoZSBzYW1lIHRpbWUgc3VjaCBhIGRlc2NyaXB0aW9uIGlzIG5vdCBhIGh1
Z2UgdGFzayB0byBkZWZpbmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gT2theSwgd2lsbCBh
ZGQgYSBuZXcgc2VjdGlvbiAoSVAgSGVhZGVyIEZpZWxkcyBmb3IgVENQLXRvLVVEUCB0cmFuc2xh
dGlvbikuPG86cD48L286cD48L3A+DQo8cD5Gb3IgVURQIHBhY2tldHMgZ2VuZXJhdGVkIGJhc2Vk
IG9uIENoYW5uZWwgb3IgU2VuZCBJbmRpY2F0aW9ucyBhcnJpdmluZyBhdCB0aGUgVFVSTiBzZXJ2
ZXIgb3ZlciBhIFRDUCBUcmFuc3BvcnQgSSB0aGluayB0aGUgZm9sbG93aW5nIHNob3VsZCBiZSBk
b25lLiZuYnNwOyBOb3RlLCB0aGlzIGEgcm91Z2ggc2tldGNoLCBzb21lIGFkanVzdG1lbnQgb2Yg
dGhlIGxhbmd1YWdlIHNob3VsZCBiZSBkb25lIGFuZCBmb3JtYXR0ZWQgbGlrZSB0aGUgb3RoZXIN
CiBvcHRpb25zLiA8bzpwPjwvbzpwPjwvcD4NCjxwPlRUTDogU2V0IHRvIGRlZmF1bHQgb3V0Z29p
bmcgdmFsdWUuIDxvOnA+PC9vOnA+PC9wPg0KPHA+RFNDUDogU2V0IHRvIHZhbHVlIHVzZWQgYnkg
VENQIGNvbm5lY3Rpb24sIHVubGVzcyB0aGUgc2VydmVyIGltcGxlbWVudHMgYSByZW1hcmtlci4g
Tm90ZSwgdGhlIFRDUCBjb25uZWN0aW9uIGNhbiBvbmx5IHVzZSBhIHNpbmdsZSBEU0NQIGNvZGUg
cG9pbnQgc28gaW50ZXIgZmxvdyBkaWZmZXJlbnRpYXRpb24gaXMgbm90IHBvc3NpYmxlLCBzZWUg
U2VjdGlvbiA1LjEgb2YgUkZDIDc2NTcuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gVFRMIGFu
ZCBEU0NQIGV4cGxhbmF0aW9uIGxvb2tzIGdvb2QsIHdpbGwgdXBkYXRlIGRyYWZ0LjxvOnA+PC9v
OnA+PC9wPg0KPHA+RUNOOiBObyBtZWNoYW5pc20gaXMgZGVmaW5lZCB0byBpbmRpY2F0ZSB3aGF0
IEVDTiB2YWx1ZSBzaG91bGQgYmUgdXNlZCBmb3Igb3V0Z29pbmcgVURQIHBhY2tldHMgZm9yIGFu
IGFsbG9jYXRpb25zLCB0aGVyZWZvcmUgdGhlIEVDTiBmaWVsZCBzaGFsbCBiZSBzZXQgdG8gTm90
IEVDVCAoPTBiMDApLg0KPG86cD48L286cD48L3A+DQo8cD5bVFJdIEkgdGhpbmsgeW91IG1lYW4g
dGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxwPkR1ZSB0byB0aGUgbGFjayBvZiBmZWVk
YmFjayBtZWNoYW5pc21zIGluIFVEUCwgU2V0IHRoZSBvdXRnb2luZyB2YWx1ZSB0byBOb3QtRUNU
ICg9MGIwMCkuPG86cD48L286cD48L3A+DQo8cD5GbG93IExhYmVsOjxvOnA+PC9vOnA+PC9wPg0K
PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtBcyBkaXNjdXNzZWQgZWFybGllciBiYXNlZCBv
biB0aGUgcmVzdWx0aW5nIFVEUCBmbG93XS4gPG86cD48L286cD48L3A+DQo8cD5bVFJdIEZsb3cg
TGFiZWwgaXMgYWxyZWFkeSBkaXNjdXNzZWQgaW4gSVB2NC10by1JUHY2IGFuZCBJUHY2LXRvLUlQ
djYgdHJhbnNsYXRpb25zIChzZWN0aW9ucyAxMy4gMSBhbmQgMTMuMiksIGFuZCBub3Qgc3BlY2lm
aWMgdG8gVENQLXRvLVVEUCB0cmFuc2xhdGlvbi4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNCNzZWN0aW9uLTE0Ij5odHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjQjc2VjdGlvbi0x
NDwvYT4gKElQIGhlYWRlciBmaWVsZHMpIGRvZXMgbm90IGRpc2N1c3MgRmxvdyBsYWJlbC48bzpw
PjwvbzpwPjwvcD4NCjxwPklQdjQgRnJhZ21lbnRhdGlvbjogPG86cD48L286cD48L3A+DQo8cHJl
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1doZW4gdGhlIHNlcnZlciBzZW5k
cyBhIHBhY2tldCB0byBhIHBlZXIgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVzcG9uc2UgdG8gYSBTZW5kIGluZGljYXRpb24gY29udGFp
bmluZyB0aGUgRE9OVC1GUkFHTUVOVDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBhdHRyaWJ1dGUsIHRoZW4gc2V0IHRoZSBERiBiaXQgaW4gdGhl
IG91dGdvaW5nIElQIGhlYWRlciB0byAxLiZuYnNwOyBJbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbGwgb3RoZXIgY2FzZXMgd2hlbiBzZW5k
aW5nIGFuIG91dGdvaW5nIHBhY2tldCBjb250YWluaW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uIGRhdGEgKGUuZy4sIERh
dGEgaW5kaWNhdGlvbiwgQ2hhbm5lbERhdGEgbWVzc2FnZSwgb3I8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRE9OVC1GUkFHTUVOVCBhdHRyaWJ1
dGUgbm90IGluY2x1ZGVkIGluIHRoZSBTZW5kIGluZGljYXRpb24pLCBzZXQgdGhlIERGIGJpdDxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0
aGUgb3V0Z29pbmcgSVAgaGVhZGVyIHRvIDAuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPltUUl0gV2h5IG5vdCB1c2UgdGhlIHNhbWUgYmVoYXZp
b3IgYXMgVURQLXRvLVVEUCB0cmFuc2xhdGlvbiBmb3IgSVB2NCBmcmFnbWVudGF0aW9uID8gPG86
cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2UgY2Fu
IHJlLXVzZSB0aGUgZm9sbG93aW5nIHRleHQ6PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi
PiZuYnNwOyZuYnNwOyBJUHY0IEZyYWdtZW50YXRpb24gZmllbGRzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFByZWZlcnJl
ZCBCZWhhdmlvcjogV2hlbiB0aGUgc2VydmVyIHNlbmRzIGEgcGFja2V0IHRvIGEgcGVlciBpbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y
OndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXNwb25zZSB0byBh
IFNlbmQgaW5kaWNhdGlvbiBjb250YWluaW5nIHRoZSBET05ULUZSQUdNRU5UPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4
dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF0dHJpYnV0ZSwgdGhlbiBzZXQgdGhl
IERGIGJpdCBpbiB0aGUgb3V0Z29pbmcgSVAgaGVhZGVyIHRvIDEuJm5ic3A7IEluPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2luZG93
dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFsbCBvdGhlciBjYXNlcyB3aGVu
IHNlbmRpbmcgYW4gb3V0Z29pbmcgcGFja2V0IGNvbnRhaW5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbGljYXRpb24gZGF0YSAoZS5nLiwgRGF0YSBp
bmRpY2F0aW9uLCBDaGFubmVsRGF0YSBtZXNzYWdlLCBvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBET05ULUZSQUdNRU5UIGF0dHJpYnV0ZSBub3QgaW5jbHVk
ZWQgaW4gdGhlIFNlbmQgaW5kaWNhdGlvbiksIGNvcHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIERGIGJpdCBmcm9tIHRoZSBERiBiaXQgb2YgdGhlIGlu
Y29taW5nIHBhY2tldCB0aGF0IGNvbnRhaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB0aGUgYXBwbGljYXRpb24gZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2V0IHRoZSBv
dGhlciBmcmFnbWVudGF0aW9uIGZpZWxkcyAoSWRlbnRpZmljYXRpb24sIE1vcmU8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0
ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnJhZ21lbnRzLCBGcmFnbWVudCBP
ZmZzZXQpIGFzIGFwcHJvcHJpYXRlIGZvciBhIHBhY2tldDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBvcmlnaW5hdGluZyBmcm9tIHRoZSBzZXJ2ZXIuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6d2lu
ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IEFsdGVybmF0ZSBCZWhhdmlvcjogQXMgZGVzY3JpYmVkIGluIHRoZSBQcmVmZXJyZWQgQmVo
YXZpb3IsIGV4Y2VwdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBhbHdheXMgYXNzdW1lIHRoZSBpbmNvbWluZyBERiBiaXQgaXMgMC48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
Oztjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gYm90
aCB0aGUgUHJlZmVycmVkIGFuZCBBbHRlcm5hdGUgQmVoYXZpb3JzLCB0aGUgcmVzdWx0aW5nPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6
d2luZG93dGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhY2tldCBtYXkgYmUg
dG9vIGxhcmdlIGZvciB0aGUgb3V0Z29pbmcgbGluay4mbmJzcDsgSWYgdGhpcyBpcyB0aGU8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjp3
aW5kb3d0ZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FzZSwgdGhlbiB0aGUg
bm9ybWFsIGZyYWdtZW50YXRpb24gcnVsZXMgYXBwbHkgW1JGQzExMjJdLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwPklQdjYgRnJhZ21lbnRh
dGlvbjo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbmRlcGVuZGVudCBpZiB0aGUgVENQIHRyYWZm
aWMgYXJyaXZlcyBvdmVyIElQdjQgb3IgSVB2NiB0aGUgZnJhZ21lbnRhdGlvbiBzZXR0aW5ncyBm
b3Igb3V0Z29pbmcmbmJzcDsgSVB2NiBVRFAgcGFja2V0cyB3aWxsIGhhdmUgdG8gZm9sbG93IHdo
YXQgaXMgZGVmaW5lZCBmb3IgSVB2NCB0byBJUHY2IHRyYW5zbGF0aW9uIGFuZCBpZ25vcmUgdGhl
IERGIGJpdCBpbiBpbmNvbWluZyBwYWNrZXRzLCBhbmQgaW50ZXJwcmV0IHRoZSBwcmVzZW5jZQ0K
IG9mIHRoZSBET05ULUZSQUdNRU5UIGF0dHJpYnV0ZSBhcyBERj0xIGluIGluY29taW5nIHBhY2tl
dCwgYW5kIGZvciBhbGwgb3RoZXIgY2FzZXMgY29uc2lkZXIgREY9MCB0byBhcHBseS4NCjxvOnA+
PC9vOnA+PC9wPg0KPHA+Jm5ic3A7W1RSXSBUaGUgYmVoYXZpb3IgaXMgYWxyZWFkeSBkaXNjdXNz
ZWQgaW4gSVB2NC10by1JUHY2IGFuZCBJUHY2LXRvLUlQdjYgdHJhbnNsYXRpb25zIGluIHRoZSBk
cmFmdC4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy
YW0tdHVybmJpcy0yNCNzZWN0aW9uLTE0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjQjc2VjdGlvbi0xNDwvYT4gKElQIGhlYWRlciBmaWVsZHMp
IHNlY3Rpb24gZG9lcyBub3QgZGlzY3VzcyBJUHY2IGZyYWdtZW50YXRpb24uDQo8bzpwPjwvbzpw
PjwvcD4NCjxwcmU+Jm5ic3A7SVB2NCBPcHRpb25zPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IFByZWZlcnJlZCBCZWhhdmlvcjogVGhlIG91dGdvaW5nIHBhY2tldCBpcyBzZW50IHdpdGhvdXQg
YW55IElQdjQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgb3B0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHA+Jm5ic3A7W1RSXSBJIHdpbGwgYWRkIElQdjQgb3B0aW9ucy4gPG86cD48L286cD48
L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklQdjYgRXh0ZW5zaW9ucyBI
ZWFkZXJzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8
cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZXQgcGVyIGRlZmF1bHQgZm9yIG9y
aWdpbmF0ZWQgSVB2NiBwYWNrZXRzLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5bVFJdIFRoZSBiZWhhdmlvciBpcyBhbHJlYWR5IGRpc2N1c3Nl
ZCBpbiBJUHY2LXRvLUlQdjYgdHJhbnNsYXRpb25zLCA8YSBocmVmPSJodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjQjc2VjdGlvbi0xNCI+aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI0I3NlY3Rpb24t
MTQ8L2E+IChJUCBoZWFkZXIgZmllbGRzKXNlY3Rpb24gZG9lcyBub3QgZGlzY3VzcyBleHRlbnNp
b24gaGVhZGVycy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl
Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5PbiBSZWNlcHRpb24gb2YgVURQIFBhY2tldHM8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JZiBUVEw9MCB0aGVuIGRyb3AgcGFj
a2V0LCBlbHNlIGlnbm9yZS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+RFNDUDogSWdub3JlLCB0aGUgRFNDUCB2YWx1ZSBmb3IgdGhlIFNlcnZl
ciB0byBDbGllbnQgZGlyZWN0aW9uIG9mIHRoZSBUQ1AgY29ubmVjdGlvbiBzaG91bGQgYmUgYmFz
ZWQgb24gdGhlIHZhbHVlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVzZWQgZm9yIHRoZSBjbGll
bnQgdG8gc2VydmVyLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5bVFJdIEJvdGggVFRMIGFuZCBEU0NQIGV4cGxhbmF0aW9uIGxvb2tzIGdvb2Qs
IHdpbGwgdXBkYXRlIGRyYWZ0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wcmU+DQo8cHJlPkVDTjogSWdub3JlLiBIaWdoZXIgbGF5ZXIgcHJvdG9jb2xzIGF0dGVt
cHRpbmcgdG8gdXNlIEVDTiB3aWxsIG5vdCByZWNlaXZlIGFueSBFQ04gc2lnbmFsIGFuZCB0aHVz
IHNlbmRlciA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zaG91bGQgc3RvcCBzZW5kaW5nIEVDVCBw
YWNrZXRzIGlmIHNlbnQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPltUUl0gSSB0aGluayB5b3UgbWVhbiDigJxTZXQgdGhlIG91dGdvaW5nIHZh
bHVlIHRvIE5vdC1FQ1QgKD0wYjAwKS7igJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu
YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5GbG93IExhYmVsOiBJZ25vcmUsIHRoZSBUQ1AgY29ubmVj
dGlvbiBoYXMgaXRzIG93biB0aGF0IGlzIHJlbGF0ZWQgdG8gcGVlciB0byBzZXJ2ZXIgZmxvdy4g
PG86cD48L286cD48L3ByZT4NCjxwPltUUl0gRmxvdyBMYWJlbCBpcyBhbHJlYWR5IGRpc2N1c3Nl
ZCBpbiBJUHY0LXRvLUlQdjYgYW5kIElQdjYtdG8tSVB2NiB0cmFuc2xhdGlvbnMgKHNlY3Rpb25z
IDEzLiAxIGFuZCAxMy4yKSwgYW5kIG5vdCBzcGVjaWZpYyB0byBVRFAtdG8tVENQIHRyYW5zbGF0
aW9uIGJldHdlZW4gdGhlIHBlZXIgYW5kIHRoZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8cHJl
PkZyYWdtZW50YXRpb246IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPkFueSBmcmFnbWVudGVkIHBhY2tldHMgYXJlIHJlYXNzZW1ibGVkIGluIHNl
cnZlciBhbmQgdGhlbiBmb3J3YXJkZWQgdG8gdGhlIGNsaWVudCBvdmVyIHRoZSBUQ1AgY29ubmVj
dGlvbi4gPG86cD48L286cD48L3ByZT4NCjxwcmU+SUNNUCBtZXNzYWdlcyByZXN1bHRpbmcgZnJv
bSBzZW50IFVEUCBwYWNrZXRzLCBNVVNUIGJlIGZvcndhcmQgdG8gY2xpZW50IHVzaW5nIFRVUk4n
cyBtZWNoYW5pc20gZm9yIHJlbGV2YW50IElDTVAgdHlwZXMuPG86cD48L286cD48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SVB2NCBPcHRpb25zIGFyZSBwcm9jZXNz
ZWQgYnkgc2VydmVyIGlmIHBvc3NpYmxlLCBlbHNlIGlnbm9yZWQ8bzpwPjwvbzpwPjwvcHJlPg0K
PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5bVFJdIExldOKAmXMgdXNlIHRoZSBz
YW1lIGJlaGF2aW9yIGFzIFVEUC10by1VRFAgdHJhbnNsYXRpb24gZm9yIElQdjQgb3B0aW9ucy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JUHY2
IEV4dGVuc2lvbiBoZWFkZXJzIGFyZSBwcm9jZXNzZWQgYnkgc2VydmVyIGlmIHBvc3NpYmxlIGFz
IGludGVuZGVkIGVuZHBvaW50LCBlbHNlIGlnbm9yZWQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPltUUl0gPC9z
cGFuPlRoZSBJUHY2IEV4dGVuc2lvbiBiZWhhdmlvciBpcyBhbHJlYWR5IGRpc2N1c3NlZCBpbiBJ
UHY2LXRvLUlQdjYgdHJhbnNsYXRpb24uPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu
ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJz
cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+
WS4gU2VjdGlvbiAxNi40LiZuYnNwOyBEQVRBPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBEQVRBIGF0dHJpYnV0ZSBp
cyBwcmVzZW50IGluIGFsbCBTZW5kIGFuZCBEYXRhIGluZGljYXRpb25zLiZuYnNwOyBUaGU8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdmFsdWUgcG9ydGlvbiBvZiB0aGlzIGF0
dHJpYnV0ZSBpcyB2YXJpYWJsZSBsZW5ndGggYW5kIGNvbnNpc3RzIG9mPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRoZSBhcHBsaWNhdGlvbiBkYXRhICh0aGF0IGlzLCB0aGUg
ZGF0YSB0aGF0IHdvdWxkIGltbWVkaWF0ZWx5IGZvbGxvdzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PiZuYnNwOyZuYnNwOyB0aGUgVURQIGhlYWRlciBpZiB0aGUgZGF0YSB3YXMgYmVlbiBzZW50IGRp
cmVjdGx5IGJldHdlZW4gdGhlIGNsaWVudDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu
YnNwOyBhbmQgdGhlIHBlZXIpLiZuYnNwOyBJZiB0aGUgbGVuZ3RoIG9mIHRoaXMgYXR0cmlidXRl
IGlzIG5vdCBhIG11bHRpcGxlIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IDQsIHRoZW4gcGFkZGluZyBtdXN0IGJlIGFkZGVkIGFmdGVyIHRoaXMgYXR0cmlidXRlLjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNhbiB5b3Ug
cGxlYXNlIGNsYXJpZnkgaWYgb25lIHdvdWxkIGdldCBhbGwgdGhlIHJlbWFpbmluZyBieXRlcyBv
ZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBJUCBwYWNrZXQgcGF5bG9hZCBvciBvbmx5IHRo
ZSBudW1iZXIgb2YgYnl0ZXMgdGhlIFVEUCBsZW5ndGggZmllbGQ8bzpwPjwvbzpwPjwvcHJlPg0K
PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5pbmRpY2F0ZXMgPzxvOnA+PC9vOnA+
PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT5UaGUgcmVhc29uIEkgYXNrIGlzIHRoYXQgdGhlcmUgaXMgcG9zc2li
aWxpdHkgdGhhdCB0aGVyZSBhcmUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRpc2NyZXBhbmN5
IGJldHdlZW4gdGhlc2UgZmllbGRzLCBzb21ldGhpbmcgdGhlIHByb3Bvc2FsIGZvciBhbjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGVyaW1lbnRhbCBzcGVjaWZpY2F0aW9uIGZvciBVRFAgb3B0
aW9ucyBhdHRlbXB0IHRvIHV0aWxpemUuPG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0i
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0
aW9ucy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHN2d2ct
dWRwLW9wdGlvbnMvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wcmU+DQo8cHJlPk5vdGUsIEkgb25seSB3YW50IHlvdSB0byBjbGFyaWZ5IHdoYXQgaXMgYWN0
dWFsbHkgaW5jbHVkZWQuIEkgd291bGQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hc3N1bWUgdXNp
bmcgdGhlIFVEUCBsZW5ndGggZmllbGQgbWFrZXMgc2Vuc2UgaW4gdGhpcyBjYXNlLjxvOnA+PC9v
OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPlRoZSBhcHBsaWNhdGlvbiBkYXRhIGRvZXMg
bm90IGluY2x1ZGUgdGhlIG9wdGlvbnMgZGlzY3Vzc2VkIGluIGRyYWZ0LWlldGYtPG86cD48L286
cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+dHN2d2ctdWRwLW9wdGlvbnMuPG86cD48L286
cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHByZT5QbGVhc2UgY2xhcmlmeSB0aGUgc3BlY2lmaWMgdXBkYXRlIHlvdSBh
cmUgbG9va2luZyBpbiB0aGlzIHNlY3Rpb24uPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90
ZT4NCjxwcmU+TXkgaW50ZW50aW9uIGhlcmUgd2FzIG5vdCB0byBicmluZyBpbiBVRFAgb3B0aW9u
cywgb25seSB0byBlbnN1cmUgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zcGVjaWZp
Y2F0aW9uIHRleHQgaXMgY2xlYXIuIEFzIFVEUCBvcHRpb25zIGRyYWZ0IHBvaW50cyBvdXQgdGhl
cmUgY291bGQgYmUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRpc2NyZXBhbmN5IGJldHdlZW4g
dGhlIFVEUCBsZW5ndGggYW5kIElQIGxlbmd0aC4gVGh1cywgSSB0aGluayB0aGVyZSBpcyBhIHBv
aW50PG86cD48L286cD48L3ByZT4NCjxwcmU+dG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBkYXRh
IGluY2x1ZGVzIFVEUCBsZW5ndGggLTggYnl0ZXMgb2YgVURQIHBheWxvYWQuPG86cD48L286cD48
L3ByZT4NCjxwcmU+UG9zc2libGUgaW5jbHVkZSBhIGluZm9ybWF0aXZlIHJlZmVyZW5jZSBmb3Ig
d2h5IHRoZXJlIG1pZ2h0IGJlIGEgZGlzY3JlcGFuY3kuPG86cD48L286cD48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxwcmU+VGhlIGRhdGEgb25seSBpbmNsdWRlcyB0aGUgYXBwbGljYXRpb24gZGF0
YSwgYW5kIHRoZSBsZW5ndGggb2YgdGhlIGF0dHJpYnV0ZSBpcyBhbHNvIGJhc2VkIG9uIHRoZSBh
cHBsaWNhdGlvbiBkYXRhLCBhbmQgSSBkb24ndCBzZWUgYW55IGRpc2NyZXBhbmN5IGluIHRoZSBj
bGllbnQgdG8gZGV0ZXJtaW5lIHRoZSBsZW5ndGggb2YgdGhlIGFwcGxpY2F0aW9uIGRhdGEuIDxv
OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5UbyBhdm9pZCBhbnkgZnV0dXJlIGNv
bmZ1c2lvbiBpZiBVRFAgb3B0aW9ucyBnZXRzIGRlcGxveWVkIEkgdGhpbmsgdGhpcyBkb2N1bWVu
dCBjYW4gY2xhcmlmeSB0aGF0IHRoZSBEQVRBIHBhcnQgaXMgd2hhdCBpcyBkZWZpbmVkIGFzIFVE
UCB1c2VyIGRhdGEgaW4gdGhlIGJlbG93IGZpZ3VyZSwgaS5lLiB0aGUgVURQIGxlbmd0aCBmaWVs
ZCAtIFVEUCBoZWFkZXIgbGVuZ3RoIGFtb3VudCBvZiBkYXRhIGFmdGVyIHRoZSBVRFAgaGVhZGVy
IGluDQogdGhlIElQIHBhY2tldCBzdWNoIHRoYXQgdGhlIHN1cnBsdXMgYXJlYSBuZXZlciBpcyBp
bmNsdWRlZC4gPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lQIHRyYW5zcG9ydCBwYXlsb2FkPG86
cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZs
dDstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0Ozxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz
Oy0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0t
LS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgSVAgSGRyIHwgVURQIEhkciB8Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFVEUCB1c2VyIGRhdGEmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBzdXJw
bHVzIGFyZWEmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmbmJzcDsmIzQzOy0tLS0tLS0tJiM0MzstLS0tLS0tLS0mIzQzOy0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDstLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mZ3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVEUCBMZW5ndGg8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgRmlndXJlIDMgSVAgdHJhbnNwb3J0IHBheWxvYWQgdnMuIFVEUCBMZW5n
dGg8bzpwPjwvbzpwPjwvcHJlPg0KPHA+Tm90ZSwgdGhpcyBpcyB0byBteSB1bmRlcnN0YW5kaW5n
IHdoYXQgaXMgY2FsbGVkIFVEUCB1c2VyIGRhdGEgaXMgd2hhdCB0aGUgY3VycmVudCBPUyBpbXBs
ZW1lbnRhdGlvbnMgd2lsbCBnaXZlIHlvdSBpZiB5b3UgdXNlIHRoZWlyIGludGVyZmFjZXMsIGJ1
dCBpZiB0aGUgVFVSTiBTZXJ2ZXIgaXMgaW1wbGVtZW50ZWQgdXNpbmcgUkFXIElQIHBhY2tldHMg
dGhpcyBudWFuY2UgbWF5IGJlIG1pc3NlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+W1RSXSBUaGFu
a3MgZm9yIHRoZSBleHBsYW5hdGlvbiwgSSB3aWxsIGFkZCB0aGUgZm9sbG93aW5nIHRoZSBsaW5l
IHRvIGF2b2lkIGZ1dHVyZSBjb25mdXNpb246PG86cD48L286cD48L3A+DQo8cD5UaGUgYXBwbGlj
YXRpb24gZGF0YSBpcyBlcXVpdmFsZW50IHRvIHRoZSAmcXVvdDtVRFAgdXNlciBkYXRhJnF1b3Q7
IGFuZCBkb2VzIG5vdCBpbmNsdWRlIHRoZSAmcXVvdDtzdXJwbHVzIGFyZWEmcXVvdDsgZGVmaW5l
ZCBpbiBTZWN0aW9uIDQgb2YgZHJhZnQtaWV0Zi10c3Z3Zy11ZHAtb3B0aW9ucy48bzpwPjwvbzpw
PjwvcD4NCjxwPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwPi1UaXJ1PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+QUkuIERUTFMgQ2lw
aGVyIFN1aXRzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+QW0gSSB1bmRlcnN0YW5kaW5nIGl0IGNvcnJlY3QgdGhhdCB0aGUgZGVmaW5pdGlvbiBv
ZiB3aGF0IERUTFMgY2lwaGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+c3VpdCB0aGF0IGEgVFVS
TiBTZXJ2ZXIgY3VycmVudGx5IGlzIHRvIHN1cHBvcnQgaXMgdGhlIG9uZXMgaW4gUkZDIDc1MjUg
PzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPk5vLCB0aGUgY2lwaGVyIHN1
aXRlcyBhbmQgKEQpVExTIHByb2ZpbGUgaXMgZGlzY3Vzc2VkIGluPG86cD48L286cD48L3ByZT4N
CjwvYmxvY2txdW90ZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tNi4yLjMiPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMi4zPC9h
PiBhbmQgaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mb2xsb3dzIHRoZSByZWNvbW1lbmRhdGlv
bnMgaW4gUkZDNzUyNS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5BaGFhLCBvZiBjb3Vyc2UuIEJ1dCwgbWF5YmUgYW4gZXhwbGljaXQgcmVmZXJl
bmNlIHRvIFNUVU5iaXMgaW4gc2VjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjIuMSB0aGF0
IHRoZSB0cmFuc3BvcnRzIGZvciBUVVJOIGFuZCBTVFVOIG1lc3NhZ2VzIGFyZSBkZWZpbmVkIHRo
ZXJlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PHByZT5JbiB0aGF0IGNhc2UsIEkgdGhpbmsgdGhlIHdvcmRpbmcgaXMgYSBiaXQgd2VhayBhcyB0
aGUgb25seSByZWZlcmVuY2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIGZpbmQgYXJlIGluIFNl
Y3Rpb24gMi4xOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+
DQo8cHJlPklmIChEKVRMUyB0cmFuc3BvcnQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsgdXNlZCBiZXR3ZWVuIHRoZSBUVVJOIGNsaWVudCBhbmQgdGhlIFRVUk4gc2VydmVy
LCB0aGUgZ3VpZGFuY2UgZ2l2ZW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
aW4gW1JGQzc1MjVdIE1VU1QgYmUgZm9sbG93ZWQgdG8gYXZvaWQgYXR0YWNrcyBvbiAoRClUTFMu
PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+UkZDNzUyNSBwcm92aWRlcyB2
YXJpb3VzIHJlY29tbWVuZGF0aW9ucyB0byBhdm9pZCBhdHRhY2tzIG9uIChEKVRMUy48bzpwPjwv
bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5JdCB3YXMgcmVhbGx5IHRoZSB0ZXh0IGlu
IFNUVU5iaXMgdGhhdCBJIHdhcyBsb29raW5nIGZvci48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHByZT5Pa2F5LCBtb2RpZmllZCB0aGUgYWJvdmUgbGluZSBhcyBmb2xsb3dzOjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyBJZiAoRClUTFMgdHJhbnNwb3J0IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i
c3A7Jm5ic3A7IHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBjbGllbnQgYW5kIHRoZSBUVVJOIHNlcnZl
ciwgdGhlIGNpcGhlciBzdWl0ZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg
ZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjMgb2YgW0ktRC5pZXRmLXRyYW0tc3R1bmJpc10gYW5k
IHRoZSBndWlkYW5jZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBnaXZlbiBp
biBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZCB0byBhdm9pZCBhdHRhY2tzIG9uIChEKVRMUy48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1
b3RlPg0KPHA+TG9va3MgZ29vZCB0byBtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHA+Q2hlZXJzPG86cD48L286cD48L3A+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPk1hZ251cyBXZXN0ZXJsdW5kIDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT5OZXR3b3JrIEFyY2hpdGVjdHVyZSAmYW1wOyBQcm90b2NvbHMsIEVy
aWNzc29uIFJlc2VhcmNoPG86cD48L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkVyaWNzc29uIEFCJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IHwgUGhvbmUmbmJzcDsgJiM0Mzs0NiAxMCA3MTQ4Mjg3PG86cD48L286cD48
L3ByZT4NCjxwcmU+VG9yc2hhbW5zZ2F0YW4gMjMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBNb2JpbGUgJiM0Mzs0NiA3MyAwOTQ5
MDc5PG86cD48L286cD48L3ByZT4NCjxwcmU+U0UtMTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwg
bWFpbHRvOiA8YSBocmVmPSJtYWlsdG86bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tIj5t
YWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb208L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_BYAPR16MB2790F74A7D46937AD59A0363EA380BYAPR16MB2790namp_--