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 revision | No specific revision (document currently at 20) | |
Type | Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2018-09-12 | |
Requested | 2018-08-29 | |
Authors | Marc Petit-Huguenin , Gonzalo Salgueiro | |
I-D 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 | |
Request | Last Call review on draft-ietf-tram-stun-pmtud by Ops Directorate Assigned | |
Reviewed revision | 10 (document currently at 20) | |
Result | Serious Issues | |
Completed | 2018-09-21 |
review-ietf-tram-stun-pmtud-10-opsdir-lc-vyncke-2018-09-21-00
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