[Nice] Filtering out stun/non-application packets

[Youness Alaoui]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Olivier Crête wrote:
> On Mon, 2010-02-08 at 10:54 -0600, Tom Kaminski wrote: 
>> I'm using the libnice-0.0.10 library and after a stream component is
>> connected, I get some packets on the recv callback that I assume are
>> STUN packets.  Obviously I do not want to pass these to my application
>> so I need a good way to filter them out.  What is the recommended way
>> to do this?  Here are some options:
>>
>> 1. Identify the UDP packet as a stun packet, let everything else
>> through.  I tried to do this, but for some reason the packet I'm
>> receiving doesn't match the signature of a STUN packet.  I'm getting a
>> 32 byte packet, but it doesn't contain the magic cookie field of
>> 0x2112A442 according to the RFC.  Not sure what kind of packet this
>> is.
>>
>> 2. Identify the UDP packet as a application data packet, only let
>> these through.  This would require a magic cookie field to be added to
>> my application packets.  I'd rather not do this, but I could if
>> necessary.
>>
>> 3. A combination of both 1 & 2.
>>
>> In the unit tests, it looks for a specific signature in the expected
>> payload to determine if it is a application data packet (method 2).
>> Is this the recommended approach?
> 
> The right answer is 2. On the public Internet, there is no way to
> guarantee that the packet you are getting is what you are expecting. So
> your application should already validate packets.
> 
> The easy way to do that is by having a signature or some kind of
> checksum (if it doesn't pass, drop the packet). But you can do some
> heuristics like is done with RTP/RTCP.
> 
> 

You can forget about the first option, libnice will never give you the
STUN packets it receives, *unless* they are invalid STUN packets, that
libnice wasn't able to parse.
That could happen though, for example, a slow network could cause
libnice to retransmit a STUN request (thinking the first one was lost),
which causes two STUN responses to be received, but only one is handled
by libnice, the second one being considered 'unmatched' (since it
already processed the response for that particular STUN transaction ID).
This could lead libnice into considering that STUN packet as invalid,
which would throw it back to the application.

But even then, like Olivier said, you can't guarantee what you receive..
what if someone decides to spam all your ports with invalid data (UDP
port scanner) ? You definitely need a way to validate your own
application packets.


> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Nice mailing list
> Nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktwcOIACgkQqvxLNLvrsxxEBACaA6RDw3isFqmNQ3WSw6oV5ize
ckQAnRS1SxWAq9XNmOWN7fI4n10ut/PY
=JDuC
-----END PGP SIGNATURE-----