Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Tue, 04 August 2020 09:05 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 36E053A0B1A for <tram@ietfa.amsl.com>; Tue, 4 Aug 2020 02:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.945
X-Spam-Level:
X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1O3Mb-dYJ-Wl for <tram@ietfa.amsl.com>; Tue, 4 Aug 2020 02:04:58 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0173A0C87 for <tram@ietf.org>; Tue, 4 Aug 2020 02:04:57 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 586DC1B0019B; Tue, 4 Aug 2020 10:04:52 +0100 (BST)
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>, "tram@ietf.org" <tram@ietf.org>
Cc: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
References: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> <860e8240-ce51-5407-4187-92478262f87c@erg.abdn.ac.uk> <179FB260-1FAC-419B-B5F4-86F850177C97@cisco.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <04b71d3e-1c79-cdc1-5b20-906732ffa768@erg.abdn.ac.uk>
Date: Tue, 4 Aug 2020 10:04:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <179FB260-1FAC-419B-B5F4-86F850177C97@cisco.com>
Content-Type: multipart/alternative; boundary="------------07C3490C1BAB4774FDF77084"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/FdbuZyrRubXQKAqVv3Zifsu9kKA>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.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." <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: Tue, 04 Aug 2020 09:05:01 -0000

On 03/08/2020 14:39, Felipe Garrido (fegarrid) wrote:
>
> Hi Gorry,
>
> Thank you for the comments. Responses are in-line.
>
> Thanks,
>
> -Felipe
>
> *From: *tram <tram-bounces@ietf.org> on behalf of Gorry Fairhurst 
> <gorry@erg.abdn.ac.uk>
> *Date: *Tuesday, July 14, 2020 at 9:24 AM
> *To: *"tram@ietf.org" <tram@ietf.org>
> *Cc: *"gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
> *Subject: *[tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
>
> I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last 
> comments, and saw some changes and I have a few comments. These 
> comments are sent to the TRAM mailing list,
>
> Gorry
>
> ---
>
> Section 2 does not discuss the frequency of the probe. This is a 
> congestion control case, and the method needs to assert some 
> guidance/requirements on the probing. Do probe packets count against 
> cwnd when using this method?
>
> In section 4.1.
> I think this is misleading, and not a feature of the simple method:
> “   Note: Routers can be configured to clear the DF bit or ignore the DF
>    bit which can be difficult or impossible to detect if reassembly
>    occurs prior to receiving the packet, rendering PLPMTUD inaccurate.
> “
> - I wouldn’t call this inaccurate? If the path contains a link-layer 
> (or tunnel or anything) that fragments and reassembles - then the path 
> MTU is whatever size that assembly is performed to. It has always been 
> this way, if links fragment and reassemble, IP uses the reassembled size.
>
> --
> Updated the Note as follows.
>
> “   Note: Routers can be configured to clear the DF bit or ignore the DF
>    bit which can be difficult or impossible to detect if reassembly
>    occurs prior to receiving the packet.”
>
>
Sure. I'd actually suggest /might be configured/ to /can be 
configured/... I'm not sure any RFC should do this according to the spec.
>
> In section 4.2.2.  Receiving an ICMP Packet
> This ID currently recommends “ Validation SHOULD be performed on the ICMP
>    packet as specified in [RFC8085].”
> - Since this is a method above UDP, I think this implicitly also 
> checks the UDP port information, hence this recommendation actually is 
> an unavoidable consequence when using a normal stack - if you have one 
> that forwards ICMP to the socket.
>
> This becomes a requirement (or is always true) in dplpmtud:
> - “Any received PTB message MUST be validated before it is used to 
> update the PLPMTU discovery information”.
> - Should this be a requirement in this spec, to avoid off-path attack?
>
> -- 
> I agree. Updating to,
>
> “ Validation MUST be performed on the ICMP  packet as specified in 
> [RFC8085].”
>
OK, or refer to the DPLPMTUD Spec - where the details are explain?
>
>
> In section 4.2.5
> “It could have been possible to use the checksum generated in the UDP
>    checksum for this, but this value is generally not accessible to
>    applications.  Also, sometimes the checksum is not calculated or is
>    off-loaded to network hardware.“
> - I do not agree this could be used (even if the checksum was returned 
> to user space), and think it suggests something that isn’t possible. 
> The UDP checksum includes the pseudo header information, including the 
> ports. Wouldn’t this make the method very fragile in the face of NAPT?
>
> --
> Removing this paragraph in its entirety.
>
Thanks
>
> In section 5:
> I don’t yet see changes in this version to section 5.
> “The PMTUD mechanism described in this document is intended to be used
>    by any UDP-based protocols that do not have built-in PMTUD
>    capabilities, irrespective of whether those UDP-based protocols are
>    STUN-based or not.  So the manner in which a specific protocol
>    discovers that it is safe to send PMTUD probes is largely dependent
>    on the details of that specific protocol, with the exception of the
>    Implicit Mechanism described below, which applies to any protocol."
>
> - Please see comments made in the previous last call.
>
> --
> Can you be more specific on what comments were not addressed?
>
> In section 7:
>
> This has added a section that is a cross-reference of which sections 
> contain information that relates to DPLPMTUD.
>
> I see a mapping of requirements in section 7.1 to refer to the 
> described method  with STUN. This seems like a useful addition (and 
> appropriate). Currently this doesn’t really have enough detail to 
> clearly see how the two sets of text relate, one might have to read 
> both to figure out the details, and if that’s the case, maybe it 
> should be explained up front. That could be helpful.
>
> --
> agreed. Can you provide the additional text that would satisfy your 
> comment?
>
> However, this does not resolve the last call questions raised about 
> the method, and it seems to require someone to read both documents, 
> which really  isn't that easy.
>
> --
> The addition of Section 7 does require that both drafts be read. As 
> such, we’re moving I-D.ietf-tsvwg-datagram-plpmtud to a normative 
> reference.
>
>
That sounds good.


> Section 7.1.  Probe loss recovery -  I think understand that the 
> probes themselves do not need to be recovered, but the text in section 
> 7.1 does not quite say this.
> --
> Agreed. Updating to the following
> Probe loss recovery: This requirement is fulfilled by requiring that 
> the PADDING bits MUST be set to zero as discussed in Section 4.1.1 and 
> Section 4.2.1 of this document. No retransmission is required as there 
> is no user data being transmitted in the probe.
>
>
/being/is being/
>
> Section 7.1. Section 7 doesn’t describe the implications of probing on 
> flow control control. I’m not sure the current text is enough:
> - Do probe packets count as credit to an upper layer protocol using 
> this method?
>
> ---
> Can you provide additional clarification on the request?
>
DPLPMTUD contains guidance on flow control and congestion control (added 
during the WGLC),see (10) in section 3.
>
> *---*
>
I hope this helps,

Gorry

> On 06/07/2020 15:02, Magnus Westerlund wrote:
>
>     Hi,
>
>     Gorry did have feedback on this document, and they have done some attempt
>
>     to define a DPLPMTUD mapping for their mechanism. I looked at it briefly and
>
>     think it is horrible terse with just requirements to combine sections. Which
>
>     unfortunately requires one to sit and cross reference the two documents.
>
>     I would appreciate any feedback from any of you have and if there appear some
>
>     glaring  failures or problems with things they declare out of scope etc.
>
>     Privately or publicly to the TRAM mailing list (tram@ietf.org  <mailto:tram@ietf.org>).
>
>     Cheers
>
>     Magnus
>
>     On Mon, 2020-07-06 at 06:04 -0700,internet-drafts@ietf.org  <mailto:internet-drafts@ietf.org>  wrote:
>
>         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           : Packetization Layer Path MTU Discovery (PLMTUD) For
>
>         UDP Transports Using Session Traversal Utilities for NAT (STUN)
>
>                  Authors         : Marc Petit-Huguenin
>
>                                    Gonzalo Salgueiro
>
>                                    Felipe Garrido
>
>             Filename        : draft-ietf-tram-stun-pmtud-17.txt
>
>             Pages           : 23
>
>             Date            : 2020-07-06
>
>         Abstract:
>
>             The datagram exchanged between two Internet endpoints have to go
>
>             through a series of physical and virtual links that may have
>
>             different limits on the upper size of the datagram they can transmit
>
>             without fragmentation.  Because fragmentation is considered harmful,
>
>             most transports and protocols are designed with a mechanism that
>
>             permits dynamic measurement of the maximum size of a datagram.  This
>
>             mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD).
>
>             But the UDP transport and some of the protocols that use UDP were
>
>             designed without that feature.  The Session Traversal Utilities for
>
>             NAT (STUN) Usage described in this document permits retrofitting an
>
>             existing UDP-based protocol with such a feature.  Similarly, a new
>
>             UDP-based protocol could simply reuse the mechanism described in this
>
>             document.
>
>         The IETF datatracker status page for this draft is:
>
>         https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/
>
>         There are also htmlized versions available at:
>
>         https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17
>
>         https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17
>
>         A diff from the previous version is available at:
>
>         https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-17
>
>         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/
>
>         _______________________________________________
>
>         I-D-Announce mailing list
>
>         I-D-Announce@ietf.org  <mailto:I-D-Announce@ietf.org>
>
>         https://www.ietf.org/mailman/listinfo/i-d-announce
>
>         Internet-Draft directories:http://www.ietf.org/shadow.html
>
>         orftp://ftp.ietf.org/ietf/1shadow-sites.txt
>