Last Call Review of draft-ietf-tram-stun-pmtud-10

Request Review of draft-ietf-tram-stun-pmtud
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-09-12
Requested 2018-08-29
Authors Marc Petit-Huguenin, Gonzalo Salgueiro, Felipe Garrido
Draft last updated 2018-09-21
Completed reviews Genart Last Call review of -09 by Roni Even (diff)
Secdir Last Call review of -09 by Carl Wallace (diff)
Opsdir Last Call review of -10 by Éric Vyncke (diff)
Genart Telechat review of -10 by Roni Even (diff)
Tsvart Telechat review of -10 by Gorry Fairhurst (diff)
Assignment Reviewer Éric Vyncke 
State Completed
Review review-ietf-tram-stun-pmtud-10-opsdir-lc-vyncke-2018-09-21
Reviewed rev. 10 (document currently at 18)
Review result Serious Issues
Review completed: 2018-09-21


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


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.