Subject: Re: [tram] Review of draft-ietf-tram-stunbis-04

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 26 Jan 2016 19:41:15 -0800

Thanks for the review, and sorry for the delay in processing it.  See inline.

On 09/03/2015 08:16 AM, Brandon Williams wrote:
> I have reviewed the STUN changes proposed in stunbis-04. Sorry for
> the long delay since Prague -- hope I don't have to return my star
> :-)
> 
> First, I've got a small number of substance comments.
> 
> s 6.1 This section still says "MTU constraint MUST be followed"
> language. I'm pretty sure that we decided to relax this constraint in
> Dallas, but I don't see it in the minutes. It seems to be implied by
> the decision about removing the SCTP requirement.

My recollection was that the relaxation was linked to the introduction of the SCTP transport in STUN (which permitted safe fragmentation).  Now that SCTP is gone, I am not sure that this decision stands alone.

> 
> s 9.2.3 The third bullet states 'If the NONCE attribute starts with
> the value "obMayJos2" but the PASSWORD-ALGORITHMS attribute is not
> present ... the server MUST generate an error response'. However, I
> don't see a way for the server to determine whether it's safe to
> require this when sending the PASSWORD-ALGORITHMS attribute. Maybe
> the third bullet's requirement can only be safely applied if
> MI-SHA256 is present.

We are not sure we understand your point, but this section has been heavily rewritten following Jonathan review, so please check that your comment is still valid.

> 
> s 14.4/14.5 There has been some discussion in mmusic about trying to
> compress ICE connectivity checks. Justin presented on this. IIRC, one
> of his proposals was to shrink the size of the ICV. It would be good
> to follow up on this and perhaps update stunbis to allow ICV's that
> are shorter.

Here's the conclusions (from MMUSIC minutes) of the discussion about that in Prague:

"Next steps: We need to discuss more on the approach and get back. Look further into what we can do with ufrag, etc. How much can we reduce packet size safely?"

I do not think that there is consensus enough to take any action at this point.

> 
> s 14.10 States "... is present only in responses." This is
> incorrect.

Fixed.

> 
> The rest of my comments are nits.
> 
> s 9.1.2 "... from an external indication what is the message
> integrity algorithm supported by both agents." I suggest "... from an
> external indication which message integrity algorithm is supported by
> both agents."

Done,

> 
> s 9.1.3 In the paragraph that starts "If these checks pass, ...", it
> might be useful to explicitly state that only one of MI-SHA256 or MI
> will be included, not both. It's probably obvious to most readers
> though.

Added text.

> 
> s 9.2.3 There is what appears to be a random URL in the text of the
> first bullet.

Fixed.

> 
> s 11 The text seems to describe backward compatibility with RFC3489,
> but the section title is "Backwards Compatibility with RFC 5389".

We made a reference to the backward compatibility section of RFC 5389 (section 12), which is RFC 3489.  The section is this document is about the backward compatibility to RFC 5389.

> 
> s 13 I think this section should also include TURN in the list of
> defined STUN usages. Maybe there are others. Alternatively, change
> the wording to indicate it's not a complete list.

There is, in fact, more STUN Usages missing besides TURN, so we thought that trying to keep an updated list is pointless, so we dropped the whole paragraph. 

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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Jan 2016 08:39:22 -0500

> I do not think that there is consensus enough to take any action at this point.

I am seizing this opportunity to restart discussion on this topic. I
think we've discussed many possibilities, and what is needed at this
moment is an actual concrete text proposal. I don't think it's
necessarily up to the draft editors to come up with such a proposal, but
rather up to the working group as a whole.

Discuss. :)

Thanks,
Simon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Wed, 27 Jan 2016 14:18:44 +0000

> On 27 Jan 2016, at 14:39, Simon Perreault <[email-masked]> wrote:
> 

I think limiting the size to a reasonable value is fine. A smaller limit to UFRAG and so on is simple and nice. 

I do not think putting much effort into saving a few bytes is worth it at this point in time. Let us save that for later if we want to tackle ICEv2 with a different connectivity check format. 

.-.
Pål-Erik

> 
> Thanks,
> Simon
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Wed, 27 Jan 2016 13:23:35 -0500

On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

IIRC, in Dallas we discussed MTU constraints in the context of both the 
SCTP requirement and the ORIGIN draft. The point was made that both 
small MTUs and fragment delivery failure are rare and that the existing 
requirements language is unnecessary. This was the foundation for 
removing the SCTP language and for removing some size constraint 
language from the ORIGIN draft. My understanding of the discussion was 
also that the group agreed to relax the existing RFC5389 constraint, at 
least for request/response message types.

This really just applies to the following text:

    If the path MTU is unknown for UDP, messages SHOULD be the smaller of
    576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
    IPv6 [RFC2460].
    <snip/>
    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].  Outside of this or similar applications, the MTU
    constraint MUST be followed.

IOW, if you don't know the PMTU, an allocation request MUST be smaller 
than 576 bytes for IPv4. My sense of the room in Dallas was that we 
agreed this is an unnecessary restriction, at least for the 
request/response message types.

So, what do others think/remember? Should we keep the existing 
requirement (in which case I think it will be important to consider this 
limitation whenever new attribute types are created)? Am I remembering 
correctly that we already decided to loosen the requirement and it just 
didn't make it into the notes for the meeting?

--Brandon

---

From: Justin Uberti <[email-masked]>
Date: Wed, 27 Jan 2016 10:25:35 -0800

ufrag already has a 4-byte lower bound, so we can't really reduce that
further.

Here is my concrete proposal:
https://docs.google.com/presentation/d/10AGaMWifWoDaG9i_FKDnsw9LgA_5deb8ZXHLJJpadBE/edit#slide=id.gc34db0b92_0_23

Basically:
- truncate M-I
- allow special case for 8-byte USERNAME
- remove tiebreaker, fingerprint, priority attributes

Possibly:
- combine ICE-CONTROLLING and USERNAME
- put M-I into transaction ID (for REQUEST; RESPONSE would still need to
have an attribute)

On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

> >> "Next steps: We need to discuss more on the approach and get back. Look
> further into what we can do with ufrag, etc. How much can we reduce packet
> size safely?"
> >>
> I do not think putting much effort into saving a few bytes is worth it at
> this point in time. Let us save that for later if we want to tackle ICEv2
> with a different connectivity check format.
>
> .-.
> Pål-Erik
>
> >
> > Thanks,
> > Simon
> >

---

From: Brandon Williams <[email-masked]>
Date: Wed, 27 Jan 2016 14:06:07 -0500

Thanks Marc. I sent a separate message about the MTU requirements, since 
I think it seems to be a broader issue to me.

There are some responses to other items below. All the rest looks good 
to me.

--Brandon

> We are not sure we understand your point, but this section has been heavily rewritten following Jonathan review, so please check that your comment is still valid.

The new text (bullets 3 and 4) looks good to me.

My concern was about supporting clients that don't support 
PASSWORD-ALGORITHMS. I see that you split the third bullet into two 
bullets and no longer require the server to send an error if 
PASSWORD-ALGORITHMS is not present, which satisfies the concern about 
clients that just don't support the functionality.

> I do not think that there is consensus enough to take any action at this point.

Since the subject of shorter HMAC values has come up, I don't see any 
harm in stating that 16 and 32 bytes are the recommended values, but 
that a specific STUN usage MAY use a truncated HMAC. If the STUN usage 
does not explicitly allow truncated HMAC values, then the HMAC lengths 
MUST be 16 and 32.

That said, I don't feel strongly about and certainly understand if you 
want to see a well defined and accepted use case before changing 
requirements.

> We made a reference to the backward compatibility section of RFC 5389 (section 12), which is RFC 3489.  The section is this document is about the backward compatibility to RFC 5389.

Both section 12 of 5389 and this section of stunbis describe backward 
compatibility with 3489. What in the section is about backward 
compatibility with 5389 STUN?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2016 11:32:10 +1100

I think that this is a fine way to shave this down if we want
something as close to STUN as possible.  But none of these changes is
at all compatible.

The alternative is to look at what we need and to change the
connectivity check entirely so that it is maximally compact.

For all of these, we need to clearly signal that the compact form is
acceptable, so maybe we can find a way to trim this right down:

a demux octet (1)
a transaction ID (12-16)
a target ufrag (4)
a source ufrag (4)
an integrity value (8-16)

As Justin implies below, we might not need the same aggressive
optimization for responses, because the main driver for reducing
packet size is reducing the check interval without driving the data
rate too high.  If too many checks are successful, the responses can
be rate limited to reduce the data rate, but in that case you have
consent, so the only concern there is congestion.

Other possible tweak is to say that the ufrag attributes in SDP
include base64 encoded binary so that you can boost the entropy of the
reduced sized ufrags by a third.

Of course, you don't want to use SHA1 for M-I for any of this.

On 28 January 2016 at 05:25, Justin Uberti <[email-masked]> wrote:
> On Wed, Jan 27, 2016 at 6:18 AM, Pal Martinsen (palmarti)
> <[email-masked]> wrote:
>>
>>

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Thu, 28 Jan 2016 11:32:17 +0000

> On 28 Jan 2016, at 01:32, Martin Thomson <[email-masked]> wrote:
> 

I think coming up with a compact form is useful for future extensions. If QUIK, SPUD, Giga, etc. could carry that information as well we could potentially have even much more efficient connectivity checks. But that discussion should probably happen in the ICE wg? (Anyone care to write up improved ICE connectivity checks draft?)

> consent, so the only concern there is congestion.
Good point. And if congestion happens it would be good to notice.

> reduced sized ufrags by a third.
+1. So this is really something a sgnalling protocol supporting ICE must support.

.-.
Pål-Erik

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 28 Jan 2016 11:08:01 -0800

Inline.

On 01/27/2016 11:06 AM, Brandon Williams wrote:
> Thanks Marc. I sent a separate message about the MTU requirements,
> since I think it seems to be a broader issue to me.
> 
> There are some responses to other items below. All the rest looks
> good to me.
> 
> --Brandon
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>> 
> 
>>> s 9.2.3 The third bullet states 'If the NONCE attribute starts
>>> with the value "obMayJos2" but the PASSWORD-ALGORITHMS attribute
>>> is not present ... the server MUST generate an error response'.
>>> However, I don't see a way for the server to determine whether
>>> it's safe to require this when sending the PASSWORD-ALGORITHMS
>>> attribute. Maybe the third bullet's requirement can only be
>>> safely applied if MI-SHA256 is present.
>> 
>> We are not sure we understand your point, but this section has been
>> heavily rewritten following Jonathan review, so please check that
>> your comment is still valid.
>> 
> 
>>> s 14.4/14.5 There has been some discussion in mmusic about trying
>>> to compress ICE connectivity checks. Justin presented on this.
>>> IIRC, one of his proposals was to shrink the size of the ICV. It
>>> would be good to follow up on this and perhaps update stunbis to
>>> allow ICV's that are shorter.
>> 
>> "Next steps: We need to discuss more on the approach and get back.
>> Look further into what we can do with ufrag, etc. How much can we
>> reduce packet size safely?"
>> 
> that a specific STUN usage MAY use a truncated HMAC. If the STUN
> usage does not explicitly allow truncated HMAC values, then the HMAC
> lengths MUST be 16 and 32.
> 
> That said, I don't feel strongly about and certainly understand if
> you want to see a well defined and accepted use case before changing
> requirements.

There is a dedicated thread on that subject, we will follow the consensus that the WG will reach.

> 
>>> 
>>> s 11 The text seems to describe backward compatibility with
>>> RFC3489, but the section title is "Backwards Compatibility with
>>> RFC 5389".
>> 
>> We made a reference to the backward compatibility section of RFC
>> 5389 (section 12), which is RFC 3489.  The section is this document
>> is about the backward compatibility to RFC 5389.
>> 
> 

OK, you are right, changed to RFC 3489.

- -- 
Marc Petit-Huguenin

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Jan 2016 15:23:00 -0500

Le 2016-01-28 06:32, Pal Martinsen (palmarti) a écrit :
> But that discussion should probably happen in the ICE wg?
> (Anyone care to write up improved ICE connectivity checks draft?)

My 2 cents...

If ICE-bis decides to use something completely unlike STUN for
connectivity checks, then yeah, and don't call it STUN, call it "ICE
connectivity check protocol" or whatever. But if we're aiming for some
similarity, or even compatibility, then it's STUN, and STUN belongs here.

Simon

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jan 2016 09:41:13 +1100

> similarity, or even compatibility, then it's STUN, and STUN belongs here.

Ultimately the chairs need to decide this, but I think that since we
are here discussing it now, then this is a fine venue.  It's not like
it's a different set of people.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2016 17:14:09 -0800

On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson <[email-masked]>
wrote:

> So that's 32 bytes, assuming the smallest values mentioned here, and
assuming we round to multiples of 4.

My proposal ends up with a 32-byte STUN message; the remaining areas for
optimization are:
- unnecessary(?) magic-cookie; 4 bytes
- T + L for USERNAME attributes; 4 bytes, but needed to support
variable-size ufrags

If you get rid of these things, I think you would end up with:
- 4 bytes for demux + length + meta
- 12 bytes for combined TID + integrity
- 8 bytes for lfrag/rfrag combo

= 24 bytes, which is slightly better, but maybe not enough to define a new
format.

> Look

---

From: Martin Thomson <[email-masked]>
Date: Fri, 29 Jan 2016 13:42:15 +1100

> = 24 bytes, which is slightly better, but maybe not enough to define a new

I think that you just did just that: this is a new format.

Your savings here are gained by reducing TID+integrity.  I'm a little
concerned about how aggressively you are reducing the transaction ID
space, since the packet no longer includes enough fresh entropy for
the integrity to help prevent an off-path attacker from spoofing a
packet.

But now we're arguing about savings that won't mean much since the
per-packet overheads will dominate.  I'd say that 32 bytes or 24 is
pretty good.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jan 2016 22:40:39 -0800

> the integrity to help prevent an off-path attacker from spoofing a

Not sure I follow. It's protected by a keyed HMAC, so even if the unique
data in the packet is low (4 bytes of random TID value, perhaps), it's
unclear how an off-path attacker could generate the right HMAC.

> per-packet overheads will dominate.  I'd say that 32 bytes or 24 is

With 32 bytes we can keep the overall STUN heritage, and just tweak the
details. Lower than that, we're defining our own demux mechanisms,
extension framework, etc.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 1 Feb 2016 11:06:31 +1100

> unclear how an off-path attacker could generate the right HMAC.

I'm assuming here that the off-path attacker is in possession of the
ufrag and pwd.  The point here is to demonstrate that you are both on
path and have that information.  If the TID is only 4 octets, then the
space you need to guess within is very small.  Maybe 2^31 is enough
that the flood of spoofed packets you send might not be successful,
but it's low enough that it almost seems worth trying.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 31 Jan 2016 16:41:22 -0800

I now see what you have in mind.

However, sending ~4B packets (requiring 4B HMAC calculations and 240GB of
traffic) seems like a heavy cost for unclear gain.