Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stun-pmtud-20
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-10-26
|
20 | Martin Duke | Shepherding AD changed to Martin Duke |
2021-09-29
|
20 | (System) | Document has expired |
2021-09-29
|
20 | (System) | Removed all action holders (IESG state changed) |
2021-09-29
|
20 | (System) | IESG state changed to Dead from I-D Exists |
2021-07-20
|
20 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
2021-07-20
|
20 | Martin Duke | IESG state changed to I-D Exists from Dead |
2021-07-20
|
20 | Martin Duke | Tag Revised I-D Needed - Issue raised by IESG set. |
2021-07-20
|
20 | Martin Duke | IETF WG state changed to Held by WG from Submitted to IESG for Publication |
2021-03-28
|
20 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-20.txt |
2021-03-28
|
20 | (System) | New version approved |
2021-03-28
|
20 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2021-03-28
|
20 | Marc Petit-Huguenin | Uploaded new revision |
2021-03-10
|
19 | Amy Vezza | Shepherding AD changed to Zaheduzzaman Sarker |
2021-03-06
|
19 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-19.txt |
2021-03-06
|
19 | (System) | New version approved |
2021-03-06
|
19 | (System) | Request for posting confirmation emailed to previous authors: Felipe Garrido , Gonzalo Salgueiro , Marc Petit-Huguenin , tram-chairs@ietf.org |
2021-03-06
|
19 | Marc Petit-Huguenin | Uploaded new revision |
2021-02-20
|
18 | (System) | Document has expired |
2021-02-20
|
18 | (System) | IESG state changed to Dead from I-D Exists |
2020-08-19
|
18 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-18.txt |
2020-08-19
|
18 | (System) | New version accepted (logged-in submitter: Felipe Garrido) |
2020-08-19
|
18 | Felipe Garrido | Uploaded new revision |
2020-07-06
|
17 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-17.txt |
2020-07-06
|
17 | (System) | New version accepted (logged-in submitter: Felipe Garrido) |
2020-07-06
|
17 | Felipe Garrido | Uploaded new revision |
2020-03-20
|
16 | Magnus Westerlund | Magnus Westerlund decided to send this document back to the WG until the necessary changes has been implemented and achieved WG consensus. For motivation of … Magnus Westerlund decided to send this document back to the WG until the necessary changes has been implemented and achieved WG consensus. For motivation of this decision see https://mailarchive.ietf.org/arch/msg/tram/nXawotkC0DbAbGP9PGNXeMM8eN4/ |
2020-03-20
|
16 | Magnus Westerlund | IESG state changed to I-D Exists from IESG Evaluation::AD Followup |
2020-03-04
|
16 | Magnus Westerlund | [Ballot discuss] The relationship to draft-ietf-tsvwg-datagram-plpmtud needs to be addressed. Will be furthered discussed with WG. |
2020-03-04
|
16 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Discuss from Yes |
2020-03-02
|
16 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-16.txt |
2020-03-02
|
16 | (System) | New version accepted (logged-in submitter: Felipe Garrido) |
2020-03-02
|
16 | Felipe Garrido | Uploaded new revision |
2020-01-02
|
15 | Magnus Westerlund | Waiting for Gorry Fairhurst to sign off on the changes that are underlying to Mirja's discsuss. Hopefully they are addressed and Mirja will be able … Waiting for Gorry Fairhurst to sign off on the changes that are underlying to Mirja's discsuss. Hopefully they are addressed and Mirja will be able to clear. |
2019-12-20
|
15 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund |
2019-12-17
|
15 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-15.txt |
2019-12-17
|
15 | (System) | New version accepted (logged-in submitter: Felipe Garrido) |
2019-12-17
|
15 | Felipe Garrido | Uploaded new revision |
2019-11-04
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-11-04
|
14 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-14.txt |
2019-11-04
|
14 | (System) | New version accepted (logged-in submitter: Felipe Garrido) |
2019-11-04
|
14 | Felipe Garrido | Uploaded new revision |
2019-09-27
|
13 | Magnus Westerlund | Authors still have not addressed Mirja's discuss and a new version is required for that. |
2019-09-27
|
13 | Magnus Westerlund | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2019-09-24
|
13 | Adam Roach | [Ballot comment] Thanks for addressing my DISCUSS. I'm keeping the one substantive comment below, as it is still applicable to the -13 version of the … [Ballot comment] Thanks for addressing my DISCUSS. I'm keeping the one substantive comment below, as it is still applicable to the -13 version of the document. In the general case, STUN servers aren't aware of the signaling protocol that is in use. For example, when a TURN server is use with RTP and RTCP with a session set up via SIP, there is no requirement that the TURN server itself have any inherent knowledge of SIP or RTP or RTCP. From that perspective, the following text in section 4.2 is a bit confusing and/or problematic: Some application layer protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. It seems odd that I would have to teach my TURN server about the protocols I'm using it with just so that it can identify the packets. This behavior, combined with the requirement that all behavior be symmetrical ("As a result of the fact that all endpoints implementing this specification are both clients and servers") leads me to believe that perhaps the use cases that drove this mechanism are tightly scoped to direct peer-to-peer uses of ICE, while the other common uses of STUN (e.g., public TURN servers used for symmetric NAT traversal) were given no consideration. If that was intentional, then I think the abstract and introduction need to clearly describe the scenarios the mechanism was defined for; and, more importantly, clarify that it does not work for the general case, including STUN servers used for NAT traversal. I suspect that, once this mechanism begins to be deployed, the foregoing limitations will cause operational difficulties, which may in turn suggest changes to the mechanism that is currently defined. |
2019-09-24
|
13 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2019-09-16
|
13 | Suresh Krishnan | [Ballot comment] Thanks for addressing my DISCUSS point. |
2019-09-16
|
13 | Suresh Krishnan | [Ballot Position Update] Position for Suresh Krishnan has been changed to No Objection from Discuss |
2019-09-10
|
13 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-13.txt |
2019-09-10
|
13 | (System) | New version approved |
2019-09-10
|
13 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin , Felipe Garrido |
2019-09-10
|
13 | Felipe Garrido | Uploaded new revision |
2019-09-09
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-09-09
|
12 | Felipe Garrido | New version available: draft-ietf-tram-stun-pmtud-12.txt |
2019-09-09
|
12 | (System) | New version approved |
2019-09-09
|
12 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin , Felipe Garrido |
2019-09-09
|
12 | Felipe Garrido | Uploaded new revision |
2019-08-28
|
11 | Magnus Westerlund | Reviewed changes. They do not yet address the discuss points of Adam, Mirja and Suresh. Authors need to do more work to resolve these. |
2019-08-28
|
11 | Magnus Westerlund | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup |
2019-08-01
|
11 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss point! I'll retain the note that I supported Adam's Discuss, for clarity, but trim the old comments. |
2019-08-01
|
11 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-08-01
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-01
|
11 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-08-01
|
11 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stun-pmtud-11.txt |
2019-08-01
|
11 | (System) | New version approved |
2019-08-01
|
11 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , tram-chairs@ietf.org, Marc Petit-Huguenin |
2019-08-01
|
11 | Gonzalo Salgueiro | Uploaded new revision |
2019-03-27
|
10 | Amy Vezza | Shepherding AD changed to Magnus Westerlund |
2018-09-29
|
10 | Gorry Fairhurst | Request for Telechat review by TSVART Completed: On the Right Track. Reviewer: Gorry Fairhurst. Sent review to list. |
2018-09-27
|
10 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from Waiting for AD Go-Ahead::AD Followup |
2018-09-27
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-09-27
|
10 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Gorry Fairhurst |
2018-09-27
|
10 | Magnus Westerlund | Request for Telechat review by TSVART is assigned to Gorry Fairhurst |
2018-09-27
|
10 | Alexey Melnikov | [Ballot comment] I am looking forward to the resolution of procedural DISCUSS raised by Adam. |
2018-09-27
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-09-26
|
10 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4528 IMPORTANT S 4.2.6. > It could have been possible to use the checksum generated … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4528 IMPORTANT S 4.2.6. > 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. > > 4.2.6. Using Sequence Numbers as Packet Identifiers I don't understand how as an endpoint I know which method I use. S 4.2.6. > > 4.2.6. Using Sequence Numbers as Packet Identifiers > > When using sequence numbers, a small header similar to the TURN > ChannelData header is added in front of all packets that are not a > STUN Probe Indication or Request. The sequence number is how would this interact with ICE, where you send Binding Indidcations. COMMENTS S 2. > Probing mechanism (as described in Section 4.2). The selection of > which Probing Mechanism to use is dependent on performance and > security and complexity trade-offs. > > If the Simple Probing mechanism is chosen, then the Client initiates > Probe transactions, as shown in Figure 1, which increase in size Why does this use probe and not binding-request? Then you wouldn't have a constraint on knowing the other side supported it. S 2. > security and complexity trade-offs. > > If the Simple Probing mechanism is chosen, then the Client initiates > Probe transactions, as shown in Figure 1, which increase in size > until transactions timeout, indicating that the Path MTU has been > exceeded. It then uses that information to update the Path MTU. Most of the MTU mechanisms I know of start big and go small. See, for instance: https://tools.ietf.org/html/rfc4821#section-7.2 S 4.1.2. > [RFC5389]. > > The server then creates a Probe Response. The server MUST add the > FINGERPRINT attribute so the STUN messages are disambiguated from the > other protocol packets. The server then sends the response to the > client. I note that this doesn't let you measure PMTU in the opposite direction. S 4.1.3. > client. > > 4.1.3. Receiving a Probe Response > > A client receiving a Probe Response MUST process it as specified in > [RFC5389]. If a response is received this is interpreted as a Probe 5389 doesn't describe Probe, so you should lay out what this means. S 6.2. > > 6.2. PMTUD-SUPPORTED > > The PMTUD-SUPPORTED attribute indicates that its sender supports this > specification. This attribute has no value part and thus the > attribute length field is 0. When is this useful? Only when you want to use simple probing? S 7. > The Simple Probing mechanism may be used without authentication > because this usage by itself cannot trigger an amplification attack > as the Probe Response is smaller than the Probe Request. An > unauthenticated Simple Probing mechanism cannot be used in > conjunction with the Implicit Probing Support Signaling mechanism in > order to prevent amplification attacks. I don't understand this last sentence. It can't be used? Doesn't the previous sentence imply you can? |
2018-09-26
|
10 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-09-26
|
10 | Alvaro Retana | [Ballot comment] I support Adam's DISCUSS, and believe that Ben's proposed alternative ("re-describe PADDING in this draft") is a viable way forward. |
2018-09-26
|
10 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-09-26
|
10 | Ben Campbell | [Ballot comment] I support Adam's DISCUSS. I will go a bit further to say that, even if a new IETF LC occurs, I would be … [Ballot comment] I support Adam's DISCUSS. I will go a bit further to say that, even if a new IETF LC occurs, I would be skeptical that the dependency on PADDING in a standards track protocol is appropriate unless people are willing to argue that RFC 5780 has become mature enough that it could reasonably be promoted to standards track. Another alternative might be to re-describe PADDING in this draft, as it is used in the context of the draft. I don't normally love that sort of duplication, but it might be appropriate here. Other comments: §2: "It is not intended as a replacement for [RFC4821]": I find this comment confusing. Are other sections in the document intended to replace some or all of 4821? §4: "The probing mechanism is used to discover the Path MTU in one direction only...": Can this mechanism not be used bidirectionally, with reciprocal client-server roles? §4.1.2: "The server MUST add the FINGERPRINT attribute...": Is this a new requirement for PMTUD, or a generic STUN requirement? If the latter, it should not be stated normatively. (Same comment for §4.2.1) §4.2.1: "If the authentication mechanism permits it, then the Indication MUST be authenticated": Is that intended to imply it's okay to use authentication mechanisms that don't allow this? |
2018-09-26
|
10 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-09-25
|
10 | Suresh Krishnan | [Ballot discuss] Section 4.1.x and 4.2.x Please specify how this simple probing mechanism will work with IPv6. It shouldn't be too difficult to do (cleanup … [Ballot discuss] Section 4.1.x and 4.2.x Please specify how this simple probing mechanism will work with IPv6. It shouldn't be too difficult to do (cleanup references to the DF bit, use Type 2 "Packet Too Big" to identify failures etc.). Similar treatment will be required for the complete probing mechanism as well. |
2018-09-25
|
10 | Suresh Krishnan | [Ballot Position Update] New position, Discuss, has been recorded for Suresh Krishnan |
2018-09-25
|
10 | Benjamin Kaduk | [Ballot discuss] I was going to report the same thing as Adam, but will just say that I support his Discuss. I also have one … [Ballot discuss] I was going to report the same thing as Adam, but will just say that I support his Discuss. I also have one other (also minor and easy to resolve) Discuss point: Section 4.2.6 needs to state what the Length field is measuring the length of. |
2018-09-25
|
10 | Benjamin Kaduk | [Ballot comment] I understand that this document inherently has to be incomplete and "vague", since the procedure specified within is only meaningful in the context … [Ballot comment] I understand that this document inherently has to be incomplete and "vague", since the procedure specified within is only meaningful in the context of a STUN usage or other protocol. But in general it seems like there could be greater clarity even within the constraints that we must work under. My points are probably less interesting than the ones Adam raised already, though. The only general observation in this space that I can offer is that some parts of the text read as if only the Probe packets are going to be monitored for the report (but this is clearly not the case given the document as a whole). Section 4.2 The Complete Probing mechanism is implemented by sending one or more Probe Indications with a PADDING attribute over UDP with the DF bit set in the IP header followed by a Report Request to the same server. A router on the path to the server can reject this Indication with an ICMP message or drop it. nit: I don't think "this" is the right word; perhaps "each" would be better. Section 4.2.3 A server supporting this specification will keep the identifiers of all packets received in a chronologically ordered list. The packets that are to be associated to a list are selected according to Section 5.2 of [RFC4821]. [...] 4821 doesn't talk about "list"s at all, and in fact the indicated section seems to be talking more about where to store a PMTU value after it has been determined, rather than what packets to be considering for a report. So I'm pretty confused about what this sentence is trying to say. Section 4.2.4 nit: I think that all instances of "the Probe Indication" should be replaced with "a Probe Indication", in this section. Section 4.2.5 When using a checksum as a packet identifier, the client calculates the checksum for each packet sent over UDP that is not a STUN Probe Indication or Request and keeps this checksum in a chronologically ordered list. The client also keeps the checksum of the STUN Probe Indication or Request sent in that same chronologically ordered list. The algorithm used to calculate the checksum is similar to the algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]). (editorial) It's pretty confusing to start out with the split between STUN and non-STUN messages, only later to clarify that this is because the FINGERPRINT is used for STUN messages. So maybe: When using a checksum as a packet identifier, the client keeps a chronologically ordered list of the packets it transmits, along with an associated checksum value. For STUN Probe Indication or Request packets, the associated checksum value is the FINGERPRINT value from the packet; for other packets a checksum value is computed using a similar algorithm to the FINGERPRINT calculation. Section 4.2.6 When using sequence numbers, a small header similar to the TURN ChannelData header [...] Probably want an informative reference for this header. Section 6.2 6.2. PMTUD-SUPPORTED The PMTUD-SUPPORTED attribute indicates that its sender supports this specification. This attribute has no value part and thus the attribute length field is 0. "this specification" is not sufficiently detailed to interoperate, so I think this needs to be qualified as more like "supports this mechanism, as incorporated into the STUN usage or protocol being used". Section 7 The contents of the PADDING do not seem to be specified anywhere, so it could in theory be used as a side channel to convey other information, which has some potential privacy considerations. Nowadays we tend to ask for the value of the padding bytes to be deterministic (but validation remains optional); I forget if there are STUN-specific considerations that would discourage just setting them all to zero. |
2018-09-25
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-09-25
|
10 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-09-25
|
10 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2018-09-24
|
10 | Spencer Dawkins | Last call announcement was generated |
2018-09-24
|
10 | Adam Roach | [Ballot discuss] This seems like an interesting technique that warrants collection of operational experience. From a process perspective, I think we have a bit of … [Ballot discuss] This seems like an interesting technique that warrants collection of operational experience. From a process perspective, I think we have a bit of an issue, unless I've overlooked something relevant. This is proposed as a Standards-Track document, but it relies on the use of the PADDING attribute defined in RFC 5780. RFC 5780 is Experimental, so this is a formal downref. And RFC 5780 does not appear in the downref registry [1], nor did the IETF last call [2] include a request that the IETF community consider allowing such a refernce. From a practical perspective, the mechanism described in this document seems like the kind of thing that it would be useful to gather operational experience with prior to putting it on the standards track. I have some operational concerns (described below) that I think could be either proven out or dispelled by experimental deployment of the technology. My recommendation is to recategorize this mechanism as experimental, adding some text about the desire to gather operational experience. For avoidance of doubt: My DISCUSS is only on the process issue, and I'll happily clear regardless of how this issue is rationalized (e.g., either by running IETF last call again, by reclassifying this mechanism as experimental, or perhaps some novel solution that I may not have thought of). Everything else is merely a recommendation. ____ [1] https://datatracker.ietf.org/doc/downref/ [2] https://www.ietf.org/mail-archive/web/tram/current/msg02609.html |
2018-09-24
|
10 | Adam Roach | [Ballot comment] In the general case, STUN servers aren't aware of the signaling protocol that is in use. For example, when a TURN server is … [Ballot comment] In the general case, STUN servers aren't aware of the signaling protocol that is in use. For example, when a TURN server is use with RTP and RTCP with a session set up via SIP, there is no requirement that the TURN server itself have any inherent knowledge of SIP or RTP or RTCP. From that perspective, the following text in section 4.2 is a bit confusing and/or problematic: Some application layer protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. It seems odd that I would have to teach my TURN server about the protocols I'm using it with just so that it can identify the packets. This behavior, combined with the requirement that all behavior be symmetrical ("As a result of the fact that all endpoints implementing this specification are both clients and servers") leads me to believe that perhaps the use cases that drove this mechanism are tightly scoped to direct peer-to-peer uses of ICE, while the other common uses of STUN (e.g., public TURN servers used for symmetric NAT traversal) were given no consideration. If that was intentional, then I think the abstract and introduction need to clearly describe the scenarios the mechanism was defined for; and, more importantly, clarify that it does not work for the general case, including STUN servers used for NAT traversal. I suspect that, once this mechanism begins to be deployed, the foregoing limitations will cause operational difficulties, which may in turn suggest changes to the mechanism that is currently defined, hence my suggestion above to recharacterize the mechanism as experimental. --------------------------------------------------------------------------- §4: > The Probing mechanism is used to discover the Path MTU in one > direction only, from the client to the server. Nit: "...only: from..." > Two Probing mechanisms are described, a Simple Probing mechanism and Nit: "...described: a Simple..." > a more complete mechanism that can converge quicker and find an Nit: "...converge more quickly..." > appropriate PMTU in the presence of congestion. Additionally, the Nit: Please expand "PMTU" on first use. --------------------------------------------------------------------------- §4.2.5: > algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the > payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]). The location of the citation in here implies that the XOR'ing described is part of V.42. Given that 0x53545554E is ASCII for "STUN," I'm pretty sure that's not part of the underlying CRC. Would suggest reworking as: algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 calculated per the algorithm defined in [ITU.V42.2002], such has subsequently been XOR'ed with 32-bit value 0x5354554e). |
2018-09-24
|
10 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2018-09-21
|
10 | Éric Vyncke | Request for Last Call review by OPSDIR Completed: Serious Issues. Reviewer: Éric Vyncke. Sent review to list. |
2018-09-21
|
10 | Magnus Westerlund | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
2018-09-21
|
10 | Mirja Kühlewind | [Ballot discuss] [Updated because I forgot one point] Based on the transport review provided by Gorry (Thanks!), please clarify the applicability (as you claim the … [Ballot discuss] [Updated because I forgot one point] Based on the transport review provided by Gorry (Thanks!), please clarify the applicability (as you claim the "usage is not limited to STUN-based protocols") and the relation to draft-ietf-tsvwg-datagram-plpmtud. Further, more discussion on impact of reordering, loss, and congestion control is probably needed (also see Gorry's review). This document should also consider IPv6 (rfc8201). Regarding sec 4.2.5, as mentioned by Gorry, it is probably not possible to use the UPD checksum because it might change on the path. And finally, I have two questions on sec 4.2.6.: 1) I don't quite understand how the identifier "shim" is used. I guess this would be needed on all UDP packet and it should be negotiated/indicated between the client and the server. How is that done? 2) Also why does the sequence number needs to be "monotonically incremented by one for each packet sent". I think all you need is a unique number. So you actually don't need a sequence number but that an easy implementation to get a unique number. I would like to see this clarified because adding a sequence number might not always be the best choice. |
2018-09-21
|
10 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2018-09-21
|
10 | Mirja Kühlewind | [Ballot discuss] Based on the transport review provided by Gorry (Thanks!), please clarify the applicability (as you claim the "usage is not limited to STUN-based … [Ballot discuss] Based on the transport review provided by Gorry (Thanks!), please clarify the applicability (as you claim the "usage is not limited to STUN-based protocols") and the relation to draft-ietf-tsvwg-datagram-plpmtud. Further, more discussion on impact of reordering, loss, and congestion control is probably needed (also see Gorry's review). Regarding sec 4.2.5, as mentioned by Gorry, it is probably not possible to use the UPD checksum because it might change on the path. And finally, I have two questions on sec 4.2.6.: 1) I don't quite understand how the identifier "shim" is used. I guess this would be needed on all UDP packet and it should be negotiated/indicated between the client and the server. How is that done? 2) Also why does the sequence number needs to be "monotonically incremented by one for each packet sent". I think all you need is a unique number. So you actually don't need a sequence number but that an easy implementation to get a unique number. I would like to see this clarifed because adding a sequence number might not always be the best choice. |
2018-09-21
|
10 | Mirja Kühlewind | Ballot discuss text updated for Mirja Kühlewind |
2018-09-20
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2018-09-20
|
10 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2018-09-20
|
10 | Mirja Kühlewind | [Ballot discuss] [This is not my final ballot position; this doc is still under review] Questions on sec 4.2.6.: 1) I don't quite understand how … [Ballot discuss] [This is not my final ballot position; this doc is still under review] Questions on sec 4.2.6.: 1) I don't quite understand how the identifier "shim" is used. I guess this would be needed on all UDP packet and it should be negotiated/indicated between the client and the server. How is that done? 2) Also why does the sequence number needs to be "monotonically incremented by one for each packet sent". I think all you need is a unique number. So you actually don't need a sequence number but that an easy implementation to get a unique number. I would like to see this clarifed because adding a sequence number might not always be the best choice. |
2018-09-20
|
10 | Mirja Kühlewind | [Ballot comment] Sec 4.2.2 says: "If the Probe Indication identifier cannot be found in the Report Response, this is interpreted as a Probe Failure, … [Ballot comment] Sec 4.2.2 says: "If the Probe Indication identifier cannot be found in the Report Response, this is interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5. If the Probe Indication identifier cannot be found in the Report Response but identifiers for other packets sent before or after the Probe Indication can all be found, this is interpreted as a Probe Failure as defined in [RFC4821] Section 7.5" However, RFC4821 seems to only see the second case as an failure. |
2018-09-20
|
10 | Mirja Kühlewind | [Ballot Position Update] New position, Discuss, has been recorded for Mirja Kühlewind |
2018-09-19
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-09-18
|
10 | Amy Vezza | Placed on agenda for telechat - 2018-09-27 |
2018-09-17
|
10 | Spencer Dawkins | Ballot has been issued |
2018-09-17
|
10 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
2018-09-17
|
10 | Spencer Dawkins | Created "Approve" ballot |
2018-09-17
|
10 | Spencer Dawkins | Ballot writeup was changed |
2018-09-17
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-09-17
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-09-17
|
10 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-10.txt |
2018-09-17
|
10 | (System) | New version approved |
2018-09-17
|
10 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2018-09-17
|
10 | Marc Petit-Huguenin | Uploaded new revision |
2018-09-14
|
09 | Spencer Dawkins | This state update is only to let the shepherd and authors know that they authors CAN revise the ID now, if that's the right thing … This state update is only to let the shepherd and authors know that they authors CAN revise the ID now, if that's the right thing to do. Please let me know when this draft is ready for balloting by the IESG. And thanks for all your work to date. |
2018-09-14
|
09 | Spencer Dawkins | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup |
2018-09-12
|
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Carl Wallace. |
2018-09-12
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-09-10
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-09-10
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tram-stun-pmtud-09. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tram-stun-pmtud-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the STUN Methods registry on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ two, new methods will be registered as follows: Value: [ TBD-at-Registration ] Name: Probe Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Name: Report Reference: [ RFC-to-be ] Second, in the STUN Attributes registry also on the Session Traversal Utilities for NAT (STUN) Parameters registry page located at: https://www.iana.org/assignments/stun-parameters/ two, new attributes will be registered as follows: Value: [ TBD-at-Registration ] Name: IDENTIFIERS Reference: [ RFC-to-be ] Value: [ TBD-at-Registration ] Name: PMTUD-SUPPORTED Reference: [ RFC-to-be ] IANA Question -> Are these new STUN Attributes to come from the comprehension-required range of Attributes or the comprehension-optional range? The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-09-05
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Éric Vyncke |
2018-09-05
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Éric Vyncke |
2018-09-03
|
09 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Jana Iyengar |
2018-09-03
|
09 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Jana Iyengar |
2018-09-03
|
09 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
2018-08-30
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2018-08-30
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2018-08-29
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-08-29
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-08-29
|
09 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-08-29
|
09 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-09-12): From: The IESG To: IETF-Announce CC: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , tasveren@rbbn.com, … The following Last Call announcement was sent out (ends 2018-09-12): From: The IESG To: IETF-Announce CC: tram-chairs@ietf.org, tram@ietf.org, Tolga Asveren , tasveren@rbbn.com, spencerdawkins.ietf@gmail.com, Gonzalo Camarillo , draft-ietf-tram-stun-pmtud@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)) to Proposed Standard The IESG has received a request from the TURN Revised and Modernized WG (tram) to consider the following document: - 'Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-09-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a Session Traversal Utilities for NAT (STUN) Usage for Path MTU Discovery (PMTUD) between a client and a server. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-08-29
|
09 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-08-29
|
09 | Spencer Dawkins | Last call was requested |
2018-08-29
|
09 | Spencer Dawkins | Last call announcement was generated |
2018-08-29
|
09 | Spencer Dawkins | Ballot approval text was generated |
2018-08-29
|
09 | Spencer Dawkins | Ballot writeup was generated |
2018-08-29
|
09 | Spencer Dawkins | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-08-25
|
09 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-09.txt |
2018-08-25
|
09 | (System) | New version approved |
2018-08-25
|
09 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2018-08-25
|
09 | Marc Petit-Huguenin | Uploaded new revision |
2018-05-14
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-05-14
|
08 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-08.txt |
2018-05-14
|
08 | (System) | New version approved |
2018-05-14
|
08 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2018-05-14
|
08 | Marc Petit-Huguenin | Uploaded new revision |
2018-05-08
|
07 | Spencer Dawkins | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-04-20
|
07 | Spencer Dawkins | IESG state changed to AD Evaluation from Publication Requested |
2018-04-20
|
07 | Gonzalo Camarillo | PROTO write up for draft-ietf-tram-stun-pmtud-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this … PROTO write up for draft-ietf-tram-stun-pmtud-07 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, as indicated on the front page of the draft. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes a Session Traversal Utilities for NAT (STUN) Usage for Path MTU Discovery (PMTUD) between a client and a server. Working Group Summary: The working group had a strong consensus around this draft. Document Quality: The document quality is satisfactory. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tolga Asveren is the document shepherd. Spencer Dawkins and Mirja Kuhlewind are the responsible Area directors. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed version 06 of the draft, provided comments. They have been discussed and satisfactorily addressed by version 07 of the draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been sufficient discussions in the past about this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The draft has sections pertaining to security and those are sufficiently reviewed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. All draft authors also acknowledged that they are not aware of any IPR associated with this draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no remaining issues with nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section lists the new STUN Methods and new STUN attributes defined by this draft. They need to be added to IANA "STUN Parameters Registry". (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2018-04-20
|
07 | Gonzalo Camarillo | Responsible AD changed to Spencer Dawkins |
2018-04-20
|
07 | Gonzalo Camarillo | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-04-20
|
07 | Gonzalo Camarillo | IESG state changed to Publication Requested |
2018-04-20
|
07 | Gonzalo Camarillo | IESG process started in state Publication Requested |
2018-04-20
|
07 | Gonzalo Camarillo | Changed consensus to Yes from Unknown |
2018-04-20
|
07 | Gonzalo Camarillo | Intended Status changed to Proposed Standard from None |
2018-04-20
|
07 | Gonzalo Camarillo | Changed document writeup |
2018-04-20
|
07 | Gonzalo Camarillo | Notification list changed to Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Tolga Asveren <tasveren@rbbn.com> from Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> |
2018-04-20
|
07 | Gonzalo Camarillo | Document shepherd changed to Tolga Asveren |
2018-03-03
|
07 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-07.txt |
2018-03-03
|
07 | (System) | New version approved |
2018-03-03
|
07 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2018-03-03
|
07 | Marc Petit-Huguenin | Uploaded new revision |
2017-09-01
|
06 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-06.txt |
2017-09-01
|
06 | (System) | New version approved |
2017-09-01
|
06 | (System) | Request for posting confirmation emailed to previous authors: Gonzalo Salgueiro , Marc Petit-Huguenin |
2017-09-01
|
06 | Marc Petit-Huguenin | Uploaded new revision |
2017-08-24
|
05 | (System) | Document has expired |
2017-03-28
|
05 | Simon Perreault | Notification list changed to Gonzalo Camarillo <gonzalo.camarillo@ericsson.com> |
2017-03-28
|
05 | Simon Perreault | Document shepherd changed to Gonzalo Camarillo |
2017-03-28
|
05 | Simon Perreault | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-02-20
|
05 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stun-pmtud-05.txt |
2017-02-20
|
05 | (System) | New version approved |
2017-02-20
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Gonzalo Salgueiro" , "Marc Petit-Huguenin" |
2017-02-20
|
05 | Gonzalo Salgueiro | Uploaded new revision |
2017-02-16
|
04 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-04.txt |
2017-02-16
|
04 | (System) | New version approved |
2017-02-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: "Gonzalo Salgueiro" , "Marc Petit-Huguenin" |
2017-02-16
|
04 | Marc Petit-Huguenin | Uploaded new revision |
2016-10-27
|
03 | Marc Petit-Huguenin | New version available: draft-ietf-tram-stun-pmtud-03.txt |
2016-10-27
|
03 | (System) | New version approved |
2016-10-27
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Gonzalo Salgueiro" , "Marc Petit-Huguenin" |
2016-10-27
|
02 | Marc Petit-Huguenin | Uploaded new revision |
2016-07-25
|
02 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stun-pmtud-02.txt |
2016-01-26
|
01 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stun-pmtud-01.txt |
2015-11-05
|
00 | Simon Perreault | This document now replaces draft-petithuguenin-tram-stun-pmtud instead of None |
2015-11-05
|
00 | Gonzalo Salgueiro | New version available: draft-ietf-tram-stun-pmtud-00.txt |