Subject: Re: [tram] STUN MTU constraints (was Re: Review of draft-ietf-tram-stunbis-04)

From: Brandon Williams <[email-masked]>
Date: Tue, 5 Apr 2016 10:19:50 -0400

Hi all,

I haven't seen any responses to this question so I'm going to convert it 
into a proposal.

My sense is that the group sees little enough problem with 
fragmentation, and particularly little enough risk the the PMTU is 576 
bytes, that the MUST language about MTU limitations can be removed. I 
propose that we completely remove the following statement from stunbis.

    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.

I think this reflects the outcome of a previous discussion. Are there 
any objections to this change?

--Brandon

On 01/27/2016 01:23 PM, Brandon Williams wrote:
> On 01/26/2016 10:41 PM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>> 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.
>>
>
> 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
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Brandon Williams <[email-masked]>
Date: Tue, 5 Apr 2016 10:49:28 -0400

Justin,

The thread on the list doesn't have too many people involved, but 
everyone who responded seems generally supportive. Do you intend to 
publish the draft and try to get some progress in the ice wg? And if so, 
should we be discussing here whether to relax the ICV length 
requirements to allow specific STUN usages to support ICV truncation?

I had earlier proposed that we continue to say that MESSAGE-INTEGRITY 
has a 20 byte HMAC by default and MESSAGE-INTEGRITY-SHA256 has a 32 byte 
HMAC by default, but that in each case, a specific STUN usage is allowed 
to define an alternative truncated HMAC length.

What do you think? Should we make this change now to support a future 
discussion in ice about connectivity check size?

--Brandon

On 01/28/2016 08:14 PM, Justin Uberti wrote:
>
>
> On Wed, Jan 27, 2016 at 4:32 PM, Martin Thomson
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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)
>
> 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.
>
>     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]
>     <mailto:[email-masked]>> wrote:
>      > 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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_presentation_d_10AGaMWifWoDaG9i-5FFKDnsw9LgA-5F5deb8ZXHLJJpadBE_edit-23slide-3Did.gc34db0b92-5F0-5F23&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=qeyGFuuIwO4N-UT7z9-mfx9BkPE7TULAzYL-2AYaD8s&s=oEfUHEijH5ckh2vZ2xDbmWubzkZPqw2QsJyi0UvdakQ&e=>
>      >
>      > 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] <mailto:[email-masked]>> wrote:
>      >>
>      >>
>      >> > On 27 Jan 2016, at 14:39, Simon Perreault <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      >> >
>      >> > Le 2016-01-26 22:41, Marc Petit-Huguenin a écrit :
>      >> >>> 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.
>      >> >
>      >> > 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. :)
>      >>
>      >> 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
>      >> >
>      >> > [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=qeyGFuuIwO4N-UT7z9-mfx9BkPE7TULAzYL-2AYaD8s&s=1HoFEZQl8d_uIr6sp3CV1UiUoysmADjEdiXIeLOALks&e=>
>      >>
>      >> [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=qeyGFuuIwO4N-UT7z9-mfx9BkPE7TULAzYL-2AYaD8s&s=1HoFEZQl8d_uIr6sp3CV1UiUoysmADjEdiXIeLOALks&e=>
>      >
>      >
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=qeyGFuuIwO4N-UT7z9-mfx9BkPE7TULAzYL-2AYaD8s&s=1HoFEZQl8d_uIr6sp3CV1UiUoysmADjEdiXIeLOALks&e=>
>      >
>
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 7 Apr 2016 10:07:01 -0600

On 04/05/2016 08:49 AM, Brandon Williams wrote:
> publish the draft and try to get some progress in the ice wg? And if
> so, should we be discussing here whether to relax the ICV length
> has a 20 byte HMAC by default and MESSAGE-INTEGRITY-SHA256 has a 32
> byte HMAC by default, but that in each case, a specific STUN usage is
> allowed to define an alternative truncated HMAC length.
> 

I think that having each usage deciding for itself a smaller size for either MI or MI-2 may be fine, but that stunbis should still provide some guidance, e.g. if truncating is done on LSB or MSB, or a minimal size for each MI, or if it needs to be a multiple of a power of 2, etc...  Advice from security people would be welcome there.

The next major update for stunbis is scheduled for end of May, so it would be great to get a clear consensus before that.

Thanks.

>> something as close to STUN as possible.  But none of these changes
>> is at all compatible.
>> 
>> 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)
>> 
>> 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 
>> 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.
>> 
>> 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.
>> 
>> include base64 encoded binary so that you can boost the entropy of
>> the reduced sized ufrags by a third.
>> 
>>> 
>>> 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)
>>> 
>>>>> 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
>>>> .-. Pål-Erik
>>>>> Thanks, Simon

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

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