Subject: [BEHAVE] Size limit of Data attribute in RFC 5766

From: Todd Herman <[email-masked]>
Date: Thu, 13 Dec 2012 16:51:04 +0000

WARNING: contains banned part

Subject: Size limit of Data attribute in RFC 5766
From: Todd Herman <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Date: Thu, 13 Dec 2012 16:51:04 +0000

When sending a Send or Data indication I must include the Data attribute.  Is there a size limit to this attribute value?  I believe there is a size limit to an overall STUN message so I assume that still applies. Could anyone clarify this for me please?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Dec 2012 10:26:40 -0800

> When sending a Send or Data indication I must include the Data attribute.

> Is there a size limit to this attribute value?  

STUN (RFC5389) says:

   All STUN messages sent over UDP SHOULD be less than the path MTU, if
   known.  If the path MTU is unknown, messages SHOULD be the smaller of
   576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
   IPv6 [RFC2460].  This value corresponds to the overall size of the IP
   packet.  Consequently, for IPv4, the actual STUN message would need
   to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte
   UDP header, assuming no IP options are used).  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 [BEHAVE-NAT].  Outside of
   this or similar applications, the MTU constraint MUST be followed.

> I believe there is a size limit to an overall STUN message so I assume 
> that still applies. Could anyone clarify this for me please?

Exceeding the path MTU will cause the UDP packet to be fragmented.  
Fragmented packets are dropped by some NATs and by some firewalls,
more so if the fragment arrives before the header (which can be
caused by the sender transmitting them out of order, or by the
network changing the packet order).

Most protocols try hard to stay well below 1500 bytes to accommodate
tunneling (such as TURN's tunneling, GRE, PPPoE, L2TP, etc.).  So,
the additional header of TURN is not typically a problem in practice.

It is possible to determine the path MTU between the TURN client
and TURN server by using the idea described in Marc Petit-Huguenin's
http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud.  
That technique does not rely on receiving ICMP packet-too-big errors, 
which are sometimes filtered or rate limited.

-d