[tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Mirja Kühlewind via Datatracker <noreply@ietf.org> Wed, 10 July 2019 15:55 UTC
Return-Path: <noreply@ietf.org>
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 A751012023E; Wed, 10 Jul 2019 08:55:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams <brandon.williams@akamai.com>, tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <156277411459.15353.13243689830942672102.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 08:55:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/KVoFCcd3ncc6jTMIt4S8Or21AB4>
Subject: [tram] Mirja Kühlewind's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 15:55:15 -0000
Mirja Kühlewind has entered the following ballot position for draft-ietf-tram-turnbis-27: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- One quick discussion which probably is only an oversight and therefore should be easy got fix: I'm bit confused about the requirement on using authentication. This draft says in section 5 (as RFC5766 does): "The server MUST demand that all requests from the client be authenticated using this mechanism, or that a equally strong or stronger mechanism for client authentication is used." However, RFC 8155 which is even now cited in this draft, updates RFC5766 and relaxes this requirement. Later in the section 7.2. this draft says: "The server SHOULD require that the request be authenticated." I assume the requirement in section 5 is an oversight? I also recommend to only specify this requirement normatively in one place. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some other technical comments/questions: 1) Sec 3.7: "or use UDP fragmentation [I-D.ietf-tsvwg-udp-options]." I believe the possibility to use UDP fragmentation was brought up by the TSV-ART review (Thanks Joe!). However, I would like to mention that this can only be used if supported by both endpoints and that should probably also be remarked here. The next sentence in the draft indicated this by saying "until UDP fragmentation support is available", however, this actually seem to be editorially a bit misplaced there and could explain more. See also this text in draft-ietf-tsvwg-udp-options: "FRAG needs to be used with extreme care because it will present incorrect datagram boundaries to a legacy receiver, unless encoded as LITE data (see Section 5.8)." Also note that draft-ietf-tsvwg-udp-options is still under development and we don't have much deployment experience with it yet. And further, in the same section. There is also draft-ietf-tsvwg-datagram-plpmtud on "Packetization Layer Path MTU Discovery for Datagram Transports". Please also be aware that there is an extensive TSV-ART for draft-ietf-tram-stun-pmtud. Both might impact the final content of this section. 2) sec 11.5: "When the server receives an ICMP packet, the server verifies that the type is either 3 or 11 for an ICMPv4 [RFC0792] packet or either 1, 2, or 3 for an ICMPv6 [RFC4443] packet." Restricting to a set of known types, doesn't seem to support future extensibility very well... 3) sec 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." Not exactly sure why this is useful...? Is this to align with STUN and therefore make processing somehow easier? Is that really needed. And exception should be easy to implement and should save some bytes which is the as I understood it the whole purpose of channels, no? 4) 12.6: "Note that if the Length field in the ChannelData message is 0, then there will be no data in the UDP datagram, but the UDP datagram is still formed and sent." Can you maybe add some more text and explain why this is useful? 5) sec 15: RFC6824 will soon be obsoleted by draft-ietf-mptcp-rfc6824bis and please s/TCP multi-path/Multipath TCP/. 6) Just a thought looking at section 14 and 16: It could have been nice to provide an ECN feedback field from the server to the client in case a ECN marked packet is received from the peer... however, I guess that future work at this point in the process... 7) sec 18.13: Maybe I missed this because I reviewed this doc over 3 days, but is only the ICMP Attribute send to the client or is the actual ICMP packets or as much as possible of that packet includes as well? 8) sec 23: "Response: TURN will no longer be needed once there are no longer any NATs. Unfortunately, as of the date of publication of this document, it no longer seems very likely that NATs will go away any time soon. However, the need for TURN will also decrease as the number of NATs with the mapping property of Endpoint-Independent Mapping [RFC4787] increases." Yes... so you don't think that IPv6 will be any help here? Editorial comments: 1) Sec 6: "The relayed transport address MUST be unique across all allocations, so it can be used to uniquely identify the allocation. Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can be used to uniquely identify the allocation, [...]" These two sentences seem quite redundant. The first one was added in this draft. The second one was already there in RFC5766. 2) sec 7.1: "Since this specification only allows UDP between the server and the peers, it is RECOMMENDED that [...]" Wordings ("only allows") seems weird to me given use of other proposals is at least to some extend discussed. Nits: sec 7.1.: s/the client pick a currently unused transport address/the client picks a currently unused transport address/
- [tram] Mirja Kühlewind's Discuss on draft-ietf-tr… Mirja Kühlewind via Datatracker
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Mirja Kuehlewind
- Re: [tram] Mirja Kühlewind's Discuss on draft-iet… Konda, Tirumaleswar Reddy