Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 14 May 2018 11:05 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
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 2ED2B12DA13 for <tram@ietfa.amsl.com>; Mon, 14 May 2018 04:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable 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 yjK42mSVDWii for <tram@ietfa.amsl.com>; Mon, 14 May 2018 04:05:49 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B9E9812DA14 for <tram@ietf.org>; Mon, 14 May 2018 04:05:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1526295946; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=53WfdODGraLZ8+q7zU+iqj3ewI+wTTPRbSZG27+Dl0Y=; b=NLubmd/C/wpiPnBjKTE0IOqNZUktw4CaABWmMuNIl7iedw03h5Y3ghi3zuq8kiCZ eUOf5/VOLiE8HEcfS5ptyFrphofucAfU8fOHc/8BWKDiYeqEGqG3FwA+taS1U307 PsZ87RBItq4LUbOlSLtLSmgMqOaAVHdNyXG2Umd1rIM=;
X-AuditID: c1b4fb2d-a6b079c00000050d-8a-5af96d8a0d78
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A7.E4.01293.A8D69FA5; Mon, 14 May 2018 13:05:46 +0200 (CEST)
Received: from [147.214.19.74] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.382.0; Mon, 14 May 2018 13:04:43 +0200
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, <draft-ietf-tram-stun-pmtud@ietf.org>
CC: <tram-chairs@ietf.org>, <tram@ietf.org>, Tolga Asveren <tasveren@rbbn.com>
References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com> <CAKKJt-ffi8CVqeWGsf8x9HDX7fEOKYztuPNZ90HhcpjMZ3ApYA@mail.gmail.com>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <c214c0aa-008c-5348-dc9f-3cec377cdb68@ericsson.com>
Date: Mon, 14 May 2018 13:04:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-ffi8CVqeWGsf8x9HDX7fEOKYztuPNZ90HhcpjMZ3ApYA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM2K7mW5X7s8ogwkrJC0Oz1OwWDZlD7PF +uXf2C2W/1zJZvFh7QU2B1aPnbPusnssWfKTyWPPnEmMAcxRXDYpqTmZZalF+nYJXBnr5y1k Lmgyq5jW9Z2xgXGFdhcjJ4eEgInEuZ4Opi5GLg4hgSOMEh9XvWSEcFYzSvxccRrI4eAQFgiT +HmwFqRBRCBFYsqqW0wgNrOAn8Ty/UehmqcwSpw/1cIOkmATsJDYcus+C4jNK2AvsfrdZ0YQ m0VAVeLJzx5WEFtUIEbix9EuqBpBiZMzn4DZnAKBEn/27GAD2cssoCmxfpc+xC5xiVtP5kPt lZdo3jqbGcQWEtCWWP6shWUCo+AsJJNmIXTPQtI9C0n3AkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBoX5wy2/dHYyrXzseYhTgYFTi4T0f/jNKiDWxrLgy9xCjBAezkgjvbiOgEG9K YmVValF+fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYy953qLF69ZxNWf +v/DzvOmrx99jrWKUKrY+PDx453RYnfWn+K+tFurP7bjhrfb2iPRh86/u+06IWeCmwiHb1Zj aZ+I2fGmX+qN0tX8Omefe3Iz/Hm9VJBl+hzN8qK1v3Mnrp25aJLF6YPaqssNyjLZrHsTt+me FOoMWr1qlmlRdzv3lXNxVpuUWIozEg21mIuKEwHY/zc+cQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/fRS4KKAehb4L_23fvJ2SEOD7wOM>
Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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." <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: Mon, 14 May 2018 11:05:51 -0000

Authors,

could you please look at Spencer's AD review below and address his
comments? Thanks!

Cheers,

Gonzalo

On 09/05/2018 5:31 AM, Spencer Dawkins at IETF wrote:
> Dear Authors,
> 
> On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo
> <gonzalo.camarillo@ericsson.com <mailto:gonzalo.camarillo@ericsson.com>>
> wrote:
> 
>     Gonzalo Camarillo has requested publication of
>     draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the
>     TRAM working group.
> 
>     Please verify the document's state at
>     https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/
>     <https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/>
> 
> 
> This document was fairly clear to me. I did have some questions I'd like
> to work through before requesting Last Call, but none of them are
> showstoppers - they shouldn't even slow the show down much.
> 
> Thanks,
> 
> Spencer
> 
> I've been wrong before, but I'm thinking that 
> 
>   Not all UDP-based protocols implement the Path MTU discovery
>    mechanism described in [RFC4821]. 
> 
> is an understatement - I'm thinking of several widely used UDP-based
> protocols that try to use heuristics including just pick a low MTU size,
> or switch to TCP transport, or some other workaround. This statement
> seems to say that most UDP-based protocols do RFC 4821. Is it fair to
> say that many UDP-based protocols don't do RFC 4821 PMTU discovery?
> 
> For this section,
> 
> 3.  Terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].  When these
>    words are not in ALL CAPS (such as "must" or "Must"), they have their
>    usual English meanings, and are not to be interpreted as RFC 2119 key
>    words.
> 
> you might consider replacing it with the corresponding paragraph in
> https://tools.ietf.org/html/rfc8174 - I'm seeing an increasing number of
> comments on IESG ballots suggesting this, and it's likely that the new
> BCP text will more familiar to most readers over time.
> 
> This may be a dumb question, but in this text, 
> 
>    Implementations supporting this specification MUST implement the
>    server side of both the Simple Probing mechanism (Section 4.1) and
>    the Complete Probing mechanism (Section 4.2).
> 
>    Implementations supporting this specification MUST implement the
>    client side of the Complete Probing mechanism.  They MAY implement
>    the client side of the Simple Probing mechanism.
> 
> does this mean "Server implementations" and "Client implementations"? 
> 
> I'm a bit confused about this text:
> 
>    Some application layer protocols may already have a way of
>    identifying each individual UDP packet, in which case these
>    identifiers SHOULD be used in the IDENTIFIERS attribute of the Report
>    Response.  While there are other possible packet identification
>    schemes, this document describes two different ways to identify a
>    specific packet.
> 
>    In the first packet identification mechanism, the server computes a
>    checksum over each packet received and sends back to the sender the
>    list of checksums ordered chronologically.  The client compares this
>    list to its own list of checksums.
> 
>    In the second packet identification mechanism, the client prepends
>    the UDP data with a header that provides a sequence number.  The
>    server sends back the chronologically ordered list of sequence
>    numbers received that the client then compares with its own list.
> 
> It wasn't clear to me from this text whether these two packet
> identification mechanism are descriptions of what applications do if
> they DON'T already have a way of identifying packets. If that's what's
> intended, perhaps
> 
>   Some application layer protocols may already have a way of
>    identifying each individual UDP packet, in which case these
>    identifiers SHOULD be used in the IDENTIFIERS attribute of the Report
>    Response.  While there are other possible packet identification
>    schemes, this document describes two different ways to identify a
>    specific packet, when no application layer protocol-specific
> identification
>                  
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    mechanism is available. 
>    ^^^^^^^^^^^^^^^^^^^^^^
> ?
> 
> When I read this text,
> 
>   Then the client waits half the RTO, if it is known, or 250 ms after
>    sending the last Probe Indication and then sends the Report Request
>    to the server over UDP.
> 
> I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is
> this different from 
> 
>   Then the client waits half the RTO after
>    sending the last Probe Indication and then sends the Report Request
>    to the server over UDP.
> 
> or am I missing your point?
> 
> In this text, 
> 
>   The algorithm used to calculate the checksum is similar to the
>    algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the
>    payload XOR'ed with the 32-bit value 0x5354554e).
> 
> is there a reference you could provide for the "algorithm used for the
> FINGERPRINT attribute" here? I'm pretty sure I could find the right one,
> but googling for "STUN FINGERPRINT checksum" is a lot less helpful than
> I expected, and making sure that you understand what something is
> "similar to" seems important if that's going to be helpful information
> for implementers.
> 
> If using authentication in 
> 
>   UDP-based protocols that want to use any of these mechanisms,
>    including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities
>    MUST ensure that it cannot be used to launch an amplification attack.
>    For example, using authentication can ensure this.
> 
> is only one way to ensure prevention of amplification attacks, is there
> any guidance or reference you could point to that would help
> implementers evaluate other approaches? 
> 
> Actually, after reading 
> 
>   The Probe Request or Indication that are used to implicitly signal
>    probing support in the reverse direction MUST be authenticated to
>    prevent amplification attacks.
> 
> I wonder why authentication isn't a MUST for UDP-based protocols using
> STUN-PMTUD, but that's just me wondering ...
> 
> I was a bit confused by 
> 
>   This specification defines two new STUN methods and two new STUN
>    attributes.  IANA added these new protocol elements to the "STUN
>    Parameters Registry" created by [RFC5389].
> 
> because they haven't been added to the registry yet, right?