[tram] Opsdir last call review of draft-ietf-tram-stun-pmtud-10

Éric Vyncke <evyncke@cisco.com> Fri, 21 September 2018 18:03 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke <evyncke@cisco.com>
To: ops-dir@ietf.org
Cc: tram@ietf.org, ietf@ietf.org, draft-ietf-tram-stun-pmtud.all@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153755303365.7406.5279013276562593248@ietfa.amsl.com>
Date: Fri, 21 Sep 2018 11:03:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/IY0MKkHu9OFZf8anYpBGp3_4R0o>
Subject: [tram] Opsdir last call review of draft-ietf-tram-stun-pmtud-10

Reviewer: Éric Vyncke
Review result: Serious Issues

Reviewer: Eric Vyncke
Review result: Serious issue
Document reviewed: draft-ietf-tram-stun-pmtud-10

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This draft proposes two specific methods (Simple & Complex) for a UDP/STUN
based Packetization Layer Path MTU Discovery (RFC 4821) but sending probes of
increasing sizes and detecting errors or loss.

Please note that I am  not a STUN expert. I found the document sometimes a
little unclear.

I see several serious issues:
1)      This draft does not address IPv6 at all (while STUN RFC 5389 has IPv6
parts). Section 4.1 DF does not exist in IPv6 ! 4.1.3 there is no
‘fragmentation needed’ in IPv6 but well ‘Packet too big’ (same issues apply for
section 4.2) 2)      Little is said on how to address section 4.1.1 “Client
knows that the Server supports the protocols before sending the probes.” Is
there a *fallback mechanism* when the Client wrongly assumed that the Server
supports this specification? 3)      Is this only a one-way path MTU detection?
What about asymmetric routing where packets from Server to Client take a
different path (hence a different path MTU)? Or is I misread the draft, then I
would suggest to rename client/server to initiator/responder ?

There are also a couple of minor issues:
1)      How will this protocol be supported/affected if there is a (awful)
middle-box (NAT, Firewall) inspecting the STUN payload? 2)      The draft is
unclear whether the Simple method has to be executed before transmitted data
UDP packets 3)      What about a mcast “Server”? The draft should at least
mention that the Server must by unicast/anycast 4)      Section 4.2.5 How is
the checksum computed?

I hope that this will help to produce a better document because a solid
specification will be helpful.

Regards

-éric

[tram] Opsdir last call review of draft-ietf-tram… Éric Vyncke