Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 19 Nov 2018 14:56:40 -0600

So, having been nudged on this one ...

On Sun, Sep 30, 2018 at 4:19 PM Adam Roach <[email-masked]> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-tram-stun-pmtud-10: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/
>
>
>
> ----------------------------------------------------------------------
> 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.
>

I don't think I've seen a specific response to Adam's point here, which I
believe is that one of (at least) three things should happen -

- a second Last Call, explicitly calling out this downref, OR

- approval as an Experimental RFC, which makes the downref issue go away, OR

- (and this didn't happen in this thread, but in some conversation, I
remember that) Adam wondered if reusing the PADDING attribute was the right
thing to do (and that was a question, not a concern, but relevant here,
since if this document defined its own attribute, the downref would also go
away).

Any thoughts on this?

Thanks,

Spencer

> ____
> [1] https://datatracker.ietf.org/doc/downref/
> [2] https://www.ietf.org/mail-archive/web/tram/current/msg02609.html
>
>
> ----------------------------------------------------------------------
> 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).
>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 23 Nov 2018 13:27:46 +0000

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.

running IETF last call again, by reclassifying this mechanism as experimental,

I don't think I've seen a specific response to Adam's point here, which I believe is that one of (at least) three things should happen -

- (and this didn't happen in this thread, but in some conversation, I remember that) Adam wondered if reusing the PADDING attribute was the right thing to do (and that was a question, not a concern, but relevant here, since if this document defined its own attribute, the downref would also go away).

Any thoughts on this?

Spencer, Adam,

I see an easy fourth option:

- Pull the definition of PADDING into this document. Declare that we've gathered sufficient experience with PADDING that it now warrants being elevated to Standards Track. That is, it's been proven to work.

I’m fine with whatever, for the record.

Simon