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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 09 May 2018 03:32 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 9E79212711A; Tue, 8 May 2018 20:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuAurtA_5Lef; Tue, 8 May 2018 20:32:01 -0700 (PDT)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 D96ED12DB71; Tue, 8 May 2018 20:32:00 -0700 (PDT)
Received: by mail-yb0-x22b.google.com with SMTP id l9-v6so11892297ybm.8; Tue, 08 May 2018 20:32:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hKSL258Qsy0DEvwEe44w63nanpwoasck1RXLBErLpq4=; b=pe4V1WuXPnrwox4lmLX5uRgfEXUcXIeVrELtCIq/IOXwMAfIWUrjONBBxQOqt8mPec KyPxVT2fjXm1nh5osVQHo/QjjQMpRpZiFvCU/JxnMXd8kUMbaXaexEFVUC8OkO6Kf8lw eAd0jSLsqUa978kjEe2IZHmtc/ITbewwHPe2T2XoOrpl2kCdqrRsYP7UcDelmKImo9TR CFrXe5gcQwrFfepPFG8NkHzBHw4+WyP3xlxafHL3WBdNVA+/TK/cjRAvLkvhyaPJSY8d riPMXKI6drUz3QRING0Vtrd/XMaH++SUDqTtEaPEJLydzyvLfuLhFquUNAdkexNCozQB 0BaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hKSL258Qsy0DEvwEe44w63nanpwoasck1RXLBErLpq4=; b=piiC/KiAlGBVviPx4T+khHpD4Rwv93mwswG06Gfd8KSgv5LyR7DGr55onLjawCfTJy XFXeNDl+ZFnhUqNIdcSGqIQeDvmEnJ88bUP/eyQ9h2Ter4C/018DDyNR6q866YIyAGgd wP7eeZw6VQzNf0js7FhRo6bkELVDC7VJmAwS7gVX5dxcnl6iyIdizP9K2Li08DzDG3FO vxzJfDZMwEGriJK6jlqGysZOZOY5OvgBAtZCb6fg5Tvddjr1WSj7znydnG4tI8OcRIr2 X0aSMEEc+7WJqy0yFLnmOoXgQsk5n6wXhUCQC1WyZ2KCtc0GtAkLGHRiVQBbn0MVKX4C igXQ==
X-Gm-Message-State: ALKqPwcuL69pm13L84yJdvj6CtYoFz1iRvv00vrNf8vqCiYu6uyidSOw LKE9DXN4NgfOv8FuE9o8BWl0XtJCADCYgQvoM6eN2A==
X-Google-Smtp-Source: AB8JxZq3NXUdaxP45aZQbYe+56FDtS1eQjtNNWzAgZK/LwSPl7Aq6wc+/NDiKbWdWrGKpMXG5tpPnTgho42LoFCsoA0=
X-Received: by 2002:a5b:acf:: with SMTP id a15-v6mr5684099ybr.44.1525836719468; Tue, 08 May 2018 20:31:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Tue, 8 May 2018 20:31:58 -0700 (PDT)
In-Reply-To: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com>
References: <152421676370.10784.8969648253452773656.idtracker@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 8 May 2018 22:31:58 -0500
Message-ID: <CAKKJt-ffi8CVqeWGsf8x9HDX7fEOKYztuPNZ90HhcpjMZ3ApYA@mail.gmail.com>
To: draft-ietf-tram-stun-pmtud@ietf.org
Cc: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren <tasveren@rbbn.com>
Content-Type: multipart/alternative; boundary="000000000000a63689056bbd8b39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/TcVgLv0Sye6u-u6XMui_nI8JeCU>
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: Wed, 09 May 2018 03:32:03 -0000

Dear Authors,

On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo <
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/


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?