Last Call Review of draft-ietf-tram-stun-pmtud-10
review-ietf-tram-stun-pmtud-10-opsdir-lc-vyncke-2018-09-21-00

Request Review of draft-ietf-tram-stun-pmtud
Requested rev. no specific revision
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-09-12
Requested 2018-08-29
Other Reviews Genart Last Call review of -09 by Roni Even (diff)
Secdir Last Call review of -09 by Carl Wallace (diff)
Genart Telechat review of -10 by Roni Even
Tsvart Telechat review of -10 by Gorry Fairhurst
Review State Completed
Reviewer Éric Vyncke
Review review-ietf-tram-stun-pmtud-10-opsdir-lc-vyncke-2018-09-21
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/PgAFiFkHwliJDkY3NZC-k5MgSog
Reviewed rev. 10
Review result Serious Issues
Draft last updated 2018-09-21
Review completed: 2018-09-21

Review
review-ietf-tram-stun-pmtud-10-opsdir-lc-vyncke-2018-09-21

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