Re: [Spud] SPUD magic number

[Tom Herbert <[e-mail]>]

On Fri, Apr 10, 2015 at 12:12 AM, Pal Martinsen (palmarti)
<[e-mail]> wrote:
>
>> On 10 Apr 2015, at 04:35, Tom Herbert <[e-mail]> wrote:
>>
>> Hi,
>>
>> The SPUD magic number seems like a good idea and in fact I anticipate
>> that we'll want to adopt this technique in other UDP encapsulation
>> protocols.
>>
> +1
>
> STUN (RFC5389) also uses this trick in section 6 (https://tools.ietf.org/html/rfc5389#section-6)
>
>> I believe the magic number could be applied in two different ways:
>>
>> 1) A middlebox must match both the UDP destination port and the magic
>> number before accepting the packet is SPUD protocol. In this case ,
>> the magic number is used to distinguish SPUD from other arbitrary uses
>> of a SPUD assigned port.
>> 2) A middlebox matches the magic number in any UDP packet regardless
>> of destination port and declares it to be SPUD. This is nice because
>> we would not need to configure SPUD ports on middleboxes, but
>> increases the chances of misinterpreting something which is not SPUD
>> at all (a larger magic number size might be warranted).
>>
>> What is the intended use for this in the SPUD prototype protocol?
>>
> This was actually the first bet we implemented (https://github.com/iptube/SPUDlib). Mostly due to your 2) bullet point.
>
32 bits seems a little light to me for this usage #2, especially if
when some application packet inadvertently matches the magic number
packet is dropped when it would have otherwise been accepted if magic
numbers weren't being checked. 64 bits might be safer.

For UDP encapsulations (GUE, Geneve, VXLAN, etc), we probably would
the magic number to be optional since we'll already have a port number
to identify the protocol (at the client) and might not need middlebox
support within a data center. To make the magic number optional, we
need a way to distinguish the magic number from a valid encapsulation
header. I was thinking to set the first byte of magic number to 0xff
and declaring that indicates an invalid header for the encapsulation
protocol. 0xff works nicely since most of the new UDP encapsulations
have a version number in the first byte and haven't got past version
zero, so this gives forward compatibility.

Tom