Subject: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Aug 2006 13:55:54 -0500 (CDT) (envelope-from [email-masked])

During the last IETF meeting, I discussed the motivations for the 
FINGERPRINT attribute, which was added in rfc3489bis-04. The basic 
problem statement is that there are now several usages of STUN which 
multiplex STUN and some kind of application data (the keepalive usage, 
which is utilized by sip-outbound, and the connectivity check, used by 
ICE). STUN-04 discusses how an agent can demux STUN from application 
data on the same port. The magic cookie provides a simple way that often 
works, but I was worried about high-rate application protocols with 
sufficiently randomized data that you would still have collisions - 
i.e., cases where the magic cookie appears in the data stream in the 
exact same position.

So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN 
message. If the STUN server gets a packet and the magic cookie is there, 
it can double check the FINGERPRINT to verify that this is a STUN packet.

During the meeting, there was general agreement that something like this 
would be useful. However, it was suggested that a 32 bit CRC would be 
sufficiently effective and much simpler, which I agreed. There was also 
a suggestion at the microphone (I cannot recall who suggested it) for a 
different solution, which I'll call the "SLIP-style" solution.

In this solution, when the client is about to send a data packet on the 
same IP/port as the STUN is running, it looks to see if the data has the 
magic cookie in bits 32-63. If it does, it takes the UDP datagram and 
encapsultes it as an attribute into a STUN message, "Send". This arrives 
at the STUN server, which decapsulates it, and treats that packet as if 
it had been sent as non-stun encapsulated. There is already such a Send 
message in TURN; it would basically be moved into STUN itself.

So, the issue is: which mechanism to use - fingerprint or slip-style?

I've thought about this a bit, and have come up with the following 
pros/cons:

SLIP-Style
----------

PRO: only add packet overhead when there is a collision, as opposed to 
every stun message

PRO: CPU cost of performing an enapsulation is cheaper than performing a 
CRC computation

CON: may complicate QoS reservation mechanisms, since the packet size 
for data packets is now less predicable and dependent on the contents of 
the data

CON: might push the size of large UDP packets over the path MTU; i.e., 
path MTU computations done by the application would be invalid since the 
effective MTU is reduced by the size of the STUN encapsulation overhead

CON: will 'hide' select data packets in a stun enapsulation, totally 
messing up any on-path tools (things like RTP voice quality measurement 
devices) that are sniffing for application data packets. Note that this 
is not actually a problem for RTP since RTP will never conflict with 
STUN. However, it can happen for SIP if it is compressed with sigcomp.

CON: If you accidentially use something like the keepalive usage with a 
server which doesn't support stun (this is a big thread on the sip 
list), but correctly discards stun packets, with the slip-like 
encapsulation, actual data packets will be lost.

CON: requires the client to monitor every data packet for the cookie. 
Thus, the CPU cost is proportional to the data transmit rate. With the 
fingerprint, the CPU cost of the CRC computation is proportional to the 
stun data rate.

Fingerprint
-----------

PRO: Allows easier implementation for stun clients; STUN sender and 
application can share a socket without talking to each other

PRO: predictable packet sizes and data rates (good for QoS reservations)

PRO: doesn't impact path MTU computations

PRO: CRC computation cost is uniform and predictable - function of the 
stun rate and not the data rate

PRO: doesn't interfere with or touch the application data stream

My proposal, as you might guess, is to go with a fingerprint mechanism, 
and in particular a 32 bit CRC.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Aug 2006 17:08:43 -0500 (CDT) (envelope-from [email-masked])

Jonathan Rosenberg wrote:
My proposal, as you might guess, is to go with a fingerprint mechanism, 
and in particular a 32 bit CRC.

I think either mechanism works, and will happily go along with either.

However, I'd like to reiterate a point that someone else raised at the 
microphone when we were discussing the issue of SHA-1 versus CRC-32: you 
probably don't want to use a standard CRC-32 straight up, on the off 
chance that the multiplexed protocol *also* uses CRC-32, and happens to 
put it in the same place as one would expect the fingerprint.

I believe the suggestion was to take the output of some standard CRC-32 
operation and XOR it with a 32-bit value (e.g. 0x5354554e -- "STUN" in 
ASCII).

/a

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 21 Aug 2006 08:39:55 -0500 (CDT) (envelope-from [email-masked])

Hi Jonathan,

I haven't been following all the details of this, but I wondered whether 
this secondary check of whether it's a STUN packet could be done based on 
comparing the length of the overall STUN packet and the sum of the lengths 
of all the attributes.  If by skipping over the lengths of all the 
attributes you don't arrive at the end of the packet, then it's not a STUN 
packet.

In essence you have a number of 16-bit values (the attribute lengths) that 
must (notionally) add up to the message length.  That may well give you 
similar entropy to the FINGERPRINT attribute, but doesn't require any 
additional parameters.

Pete.

P.S. BTW - Is it time to call it "Session Traversal Underneath NAT"?  It 
doesn't seem so simple anymore! :-)

--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                        for XML to C++ data binding visit
                        http://www.tech-know-ware.com/lmx
                        (or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Jonathan Rosenberg" <jdrosen@xxxxxxxxx>

To: "Behave" <ietf-behave@xxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 17, 2006 7:55 PM
Subject: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation

SLIP-Style
----------

Fingerprint
-----------

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

---

From: Philip Matthews <[email-masked]>
Date: Wed, 23 Aug 2006 14:39:46 -0500 (CDT) (envelope-from [email-masked])

I would like to point out that there is a third approach that we  
could take.

In this approach, we add a "pre-header" before the start of the real  
STUN
header which allows an implementation to reliably distinguish STUN  
packets
from packets of the other protocol. The format of the "pre-header"  
depends

on the other protocol that we are multiplexing STUN with.

For example, if we are multiplexing STUN with SIP, then we might add
a four-byte pre-header of "XXXX" before the start of the real STUN  
header,

since a SIP message can never start with these four characters.

Though conceptually the pre-header format needs to vary with the other
protocol that we want to multiplex STUN with, it seems likely that
we could find a "default pre-header" that would work for most other  
protocols.

Here are what I see as the pros and cons of this approach:

PRO: Can rapidly detect STUN packets from other packets with 100%
reliability.

PRO: The packets of the "other" protocol are never modified.

CON: When we want to multiplex STUN with another protocol,
we may need to define and standardize a new "pre-header" if the
default pre-header is not sufficient to distinguish the two protocols.

CON: There could conceivably be protocols where there is no pre-header
format which fits the bill. (This seems unlikely to occur in practice,
since it would seem to imply that almost any garbage packet is a well- 
formed

message in the other  protocol).

- Philip

PS. I believe it was Greg Daley that suggested the SLIP-style approach.

On 17-Aug-06, at 14:55 , Jonathan Rosenberg wrote:

data on the same port. The magic cookie provides a simple way that  
often

So, the FINGERPRINT as defined in -04 was a SHA-1 hash over the STUN
message. If the STUN server gets a packet and the magic cookie is  
there,
it can double check the FINGERPRINT to verify that this is a STUN  
packet.

During the meeting, there was general agreement that something like  
this

would be useful. However, it was suggested that a 32 bit CRC would be
sufficiently effective and much simpler, which I agreed. There was  
also
a suggestion at the microphone (I cannot recall who suggested it)  
for a

In this solution, when the client is about to send a data packet on  
the
same IP/port as the STUN is running, it looks to see if the data  
has the

magic cookie in bits 32-63. If it does, it takes the UDP datagram and
encapsultes it as an attribute into a STUN message, "Send". This  
arrives
at the STUN server, which decapsulates it, and treats that packet  
as if
it had been sent as non-stun encapsulated. There is already such a  
Send

SLIP-Style
----------

PRO: CPU cost of performing an enapsulation is cheaper than  
performing a

CRC computation

CON: may complicate QoS reservation mechanisms, since the packet size
for data packets is now less predicable and dependent on the  
contents of

the data

CON: might push the size of large UDP packets over the path MTU; i.e.,
path MTU computations done by the application would be invalid  
since the
effective MTU is reduced by the size of the STUN encapsulation  
overhead

CON: will 'hide' select data packets in a stun enapsulation, totally
messing up any on-path tools (things like RTP voice quality  
measurement
devices) that are sniffing for application data packets. Note that  
this

CON: If you accidentially use something like the keepalive usage  
with a

CON: requires the client to monitor every data packet for the cookie.
Thus, the CPU cost is proportional to the data transmit rate. With the
fingerprint, the CPU cost of the CRC computation is proportional to  
the

stun data rate.

Fingerprint
-----------

PRO: predictable packet sizes and data rates (good for QoS  
reservations)

My proposal, as you might guess, is to go with a fingerprint  
mechanism,

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ  
07054-2711

Cisco Systems

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Aug 2006 19:13:32 -0500 (CDT) (envelope-from [email-masked])

As individual contributor:

I believe we already have the scheme you're describing.  

STUN messages all start with the binary digits 0b00 (first two digits are
zero).  From rfc3489bis:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |0 0|     STUN Message Type     |         Message Length        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Magic Cookie                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Transaction ID
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

SIP requests start with Method, which is required to be uppercase, and SIP
responses start with the string "SIP/2.0", which is also required to be
uppercase.  Uppercase letters are in the binary range 1000001 ("A", decimal
65) through 1011010 ("Z", decimal 90), which start with the binary sequence
0b10, which is distinguishable from STUN's binary sequence 0b00.  Even if an
implementation were to send their SIP requests using method names starting
with lowercase "a" (1100001) through "z" (1111010), those start with 0b11,
which can still be differentiated from SIP packets.

-d

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Philip Matthews
> Sent: Wednesday, August 23, 2006 12:39 PM
> To: Jonathan Rosenberg
> Cc: Behave; Eric Cooper
> Subject: Re: [Ietf-behave] STUN issue: CRC vs. SLIP-like encapsulation
>