Subject: [tram] Mirja Kühlewind's Yes on draft-ietf-tram-stunbis-16: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 16 Apr 2018 12:29:18 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-stunbis-16: Yes

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-stunbis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) Maybe it would make sense to refer informationally to
draft-ietf-tram-stun-pmtud in section 6.1?

2)  sec 6.2.2: This sentence seems to assume that only one request is sent per
TCP connection/each request sends out after a new SYN: "However, for a
request/response transaction, if the client has not
   received a response by Ti seconds after it sent the SYN to establish
   the connection, it considers the transaction to have timed out.“
i don’t think that assumption would be correct. Maybe rephrase this sentence…?

3) Also section 6.2.2: Should the client send keep-alives if a connection is
hold open but currently not used? If not, I guess further recommendation is
needed to address the case where a transmission fails because an existing idle
TCP connection was used that doesn’t work anymore. In this case, I'd say the
recommendation would be to send a RST and try to open a new TCP connection.

4) Should section 9.2 maybe provide further guidance on the lifetime of the
(server-selected) nonce?

5) I'm sure, I just missed something but how does a server know if a first
request intends to use the Long-Term Credential Mechanism or not (see 9.2.3.1.
and 9.2.4 I guess). Or is this pre-configured?

6) Section 6.3 says that this doc only specifies the procedures for the new
spec in this document and subsequently says: "It checks [...] that the magic
cookie field has the correct value..." However, given this spec obsoletes
RFC5389, I think that section 11 should provide more guidance on how to handle
"old" STUN messages. Or is the intention that an upgraded STUN server does not
handle old requests anymore? If so that should be spelled out as well.

7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy
value." Should the dummy value be further specified? Also it looks like there
was a compile problem on page 39. Is there text missing?

8) sec 17.6: Isn't "stuns  5349/upd" used for DTLS? If so, it should be
registered!

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Apr 2018 01:11:36 -0500

> 8) sec 17.6: Isn't "stuns  5349/upd" used for DTLS? If so, it should be

Just because I had the same question and chased it down: it was 
(re-)registered by RFC 7350, and so does not need updating.

/a

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 22 Apr 2018 11:39:40 -0700

Hi Mirja,

Thanks for the review, please see my responses inline.

> draft-ietf-tram-stunbis-16: Yes
[...]

Done, here's the new last paragraph:

   STUN provides no ability to handle the case where the request is
   under the MTU but the response would be larger than the MTU.  It is
   not envisioned that this limitation will be an issue for STUN.  The
   MTU limitation is a SHOULD, and not a MUST, to account for cases
   where STUN itself is being used to probe for MTU characteristics
   [RFC5780].  See also [I-D.ietf-tram-stun-pmtud] for a framework that
   use STUN to add Path MTU Discovery to protocols that lack one.
   Outside of this or similar applications, the MTU constraint MUST be
   followed.

> i don’t think that assumption would be correct. Maybe rephrase this sentence…?

Right,  the Ti timer should start when the unique request per transaction is sent, not when the connection is established.  Here's the new text:

   Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
   itself, and there are no retransmissions at the STUN protocol level.
   However, for a request/response transaction, if the client has not
   received a response by Ti seconds after it sent the request message,
   it considers the transaction to have timed out.  Ti SHOULD be
   configurable and SHOULD have a default of 39.5s.  This value has been
   chosen to equalize the TCP and UDP timeouts for the default initial
   RTO.

> recommendation would be to send a RST and try to open a new TCP connection.

I feel that keep-alives recommendations are dependent on the specificity of a STUN Usage, and should be left to the document specifying it.  For example in the TURN case there is probably enough frequent messages with the allocation and permission refresh to not mandate any kind of keep-alive. OTOH for Basic STUN Usage (NAT discovery) a client will probably immediately close the TCP connection after retrieving the NAt transport address.

So I added TCP keep-alive to the list of what STUN Usages should discuss (Section 13):

   o  The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP.

I also added the following paragraph to section 6.2.2:

   The details of an eventual keep-alive mechanism are left to each STUN
   Usage.  In any case if a transaction fails because an idle TCP
   connection doesn't work anymore the client SHOULD send a RST and try
   to open a new TCP connection.

and I updated the Basic Usage to follow our own recommendations:

   [...]
   ALTERNATE-SERVER mechanism for the same reason.  It MUST support UDP
   and TCP.  It MAY support STUN over TCP/TLS or   ALTERNATE-SERVER mechanism for the same reason.  It MUST support UDP
   and TCP.  It MAY support STUN over TCP/TLS or STUN over UDP/DTLS;
   however, DTLS and TLS provide minimal security benefits in this basic
   mode of operation.  It does not require a keep-alive mechanism as a
   TCP or TLS-over-TLS connection is closed after the end of the Binding
   transaction.  It MAY utilize the FINGERPRINT mechanism but MUST NOT
 STUN over UDP/DTLS;
   however, DTLS and TLS provide minimal security benefits in this basic
   mode of operation.  It does not require a keep-alive mechanism as a
   TCP or TLS-over-TLS connection is closed after the end of the Binding
   transaction.  It MAY utilize the FINGERPRINT mechanism but MUST NOT
   [...]

> 4) Should section 9.2 maybe provide further guidance on the lifetime of the

I added this in the Security Considerations Section:

   Implementations and deployments of a STUN usage using the Long-Term
   Credential Mechanism (Section 9.2) MUST follow the recommendations in
   Section 5 of [RFC7616].

> and 9.2.4 I guess). Or is this pre-configured?

Each STUN Usage defines what authentication mechanism it uses (see bullet point 3 of section 13), so a server implementing a specific Usage knows what to do with the first request.

> handle old requests anymore? If so that should be spelled out as well.

STUNBis still contains the processing of "classic" STUN (aka RFC5389), which is what "old" STUN messages are (not RFC5389 messages).

> was a compile problem on page 39. Is there text missing?

Already responded to that point in Dale Worley review:

"[...] the input is up to and including the attribute *preceding* the MESSAGE-INTEGRITY attribute.  The message attribute is only counted when calculating the length in the header [...]
[...] the content of the MESSAGE-INTEGRITY is not used when computing the hash, so the content itself is irrelevant."

The text says:

  The text used as input to HMAC is the STUN message, up to and
  including the attribute preceding the MESSAGE-INTEGRITY-SHA256
  attribute.  

> 8) sec 17.6: Isn't "stuns  5349/upd" used for DTLS? If so, it should be

Answered by Adam Roach.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 23 Apr 2018 11:51:32 +0200

Thanks!

> Am 22.04.2018 um 20:39 schrieb Marc Petit-Huguenin <[email-masked]>:
> 
> Hi Mirja,
>