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

[Spencer Dawkins at IETF <[e-mail]>]

So, having been nudged on this one ...

On Sun, Sep 30, 2018 at 4:19 PM Adam Roach <[e-mail]> 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).
>
>
>