Re: [Spud] SPUD magic number

[Toerless Eckert <[e-mail]>]

In STUN/ICE there is also a checksum that can be checked. That
gives 32 bit for extraction from HW for CMDs, and then
another 32 bits of checksum to be done in SW, so that you
ultimately only had 1/2^64 for false positives. Unless somebody
explains me why not, i would recommend such a checksum for
SPUD cmd != 0 packets as well.

The 1/2^64 certainty + parsing of packets should then be good enough
to protect any middlebox action that could happen on cmd = 0 packets,
because for any middlebox action that needs a really high certainty
that it is really SPUD traffic, the cmd != 0 packets could be
used to learn the tube ID, and later on the packet cmd = 0
recognition could be based on the 96 bits of cookie + tun-ID.

Cheers
    Toerless

On Fri, Apr 10, 2015 at 07:12:47AM +0000, Pal Martinsen (palmarti) 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. 
> 
> It allowed us to quickly get a linux router with netfiletr/iptables up and running with the following rule:
> 
> -A PREROUTING -p udp ???match u32 --u32 "0>>22&0x3C@8=0xd80000d8" -j NFQUEUE --queue-num 0
> 
> See https://github.com/iptube/TubeNode for a quick and dirty implementation.
> 
> >From a client perspective lessons learned from implementing ICE and STUN where RTP, STUN and vide variety of other packets might be multiplexed on the same port was that having a simple isSPUD function is really useful..
> 
> In the spud prototype it is defined like this:
> 
> bool spud_is_spud(const uint8_t *payload, size_t length)
> {
>     if (length < sizeof(spud_header)) {
>         return false;
>     }
>     return (memcmp(payload, (void *)SpudMagicCookie, SPUD_MAGIC_COOKIE_SIZE) == 0);
> }
> 
> .-.
> Pål-Erik
> 
> > Thanks,
> > Tom
> > 
> > _______________________________________________
> > Spud mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/spud
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud