RE: [reSIProcate] updates to stun code
This is great - thanks Bruce! I'm working on refactoring how Stun messages
are used in resip. Ie. Stun message flow to follow a similar path as
SipMessages throughout the stack. After that I may start looking at adding
some of the features you guys have already worked on, and this will be a
great reference.
Scott
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Bruce
Lowekamp
Sent: Thursday, June 08, 2006 5:05 PM
To: resiprocate
Cc: David A. Bryan; Jason Fischl; Tiffany Broadbent
Subject: [reSIProcate] updates to stun code
This past semester Tiffany Broadbent did some work using STUN (starting with
0.96 from Vovida/sourceforge) for her MS project, and a major part of that
was trying to incorporate some of the new features in 3489bis into the code.
We had hoped to finish the changes, but haven't been able to make progress
on it recently, and since I understand people are now looking at how to
improve the STUN support in resip, I thought I should post this here, since
it's an evolution of the same code that's in resip. (we didn't try to
reintegrate it into resip, though, so it's probably not a drop-in).
Here is a list of changes. Many are of more interest to people trying to run
stun stand-alone, but quite a few should be interesting to resip, as well:
1) Test program for STUN client and server
-stuntest.cxx, can run either client or server depending on the
command line flags set
2) Clearer client output
-now prints:
>./stuntest -c 1.1.1.2 -i 192.168.0.2
STUN client version 0.96
Primary: Independent Mapping, Independent Filter, random port, will hairpin
Return value is 0x000002 -----MAPPED ADDRESS-------
1.1.1.1:60103
3) TLS support
-added a TLS client that reads in openssl certificates and keys and
creates a connection to a known TLS server, assumed to be running on the
same IP address as the UDP STUN server.
-all TLS client/server functionality is moved to tlsConnection.cxx
and included in the stun files
4) Shared Secret Request support
-with TLS connectivity valid Shared Secret messages can be
constructed
-username and password needed for the MESSAGE-INTEGRITY attribute can
now be created
-TLS server sets an expiration timer of 30 minutes on each
username-password pair
-credentials are added to and checked by a list maintained by the
server
-*NOTE the keys for the hash used to generate parts of the username
and password are still hardcoded
5) Message Integrity support
-the MESSAGE-INTEGRITY can now be correctly constructed using the
username and password generated from the Shared Secret Request
-the hash of the message is compared to the MESSAGE-INTEGRITY
attribute and, if invalid, is dropped
6) Error message handling
-Error messages are sent and displayed and responded to more
thoroughly
-messages related to usernames and passwords prompt a regeneration of
the username and password and a retransmission of the request; all other
error messages end the client session and return control to the user so they
may remedy the error
7) Client security
-client tracks outstanding messages via their transaction IDs and if
an incoming message's transaction ID does not match one in the client's list
of outstanding IDs it is dropped
8) Revised RFC compatibility
-added the NONCE, REALM, and ALTERNATE-SERVER attributes
- added the "magic cookie" value
-the first two bytes of a message are set to 0b00 to identify it as
compatible with the revised guidelines
I believe that NONCE and REALM are included, but their functionality isn't
implemented.
The code is currently at:
http://www.cs.wm.edu/~lowekamp/tmp/stunWM.zip
It will be there for awhile, at least until the features are available from
somewhere else.
All modifications are provided under the same Vovida license as the
original.
Bruce
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel