Subject: [midcom] RE: midcom digest, Vol 1 #688 - 1 msg

From: "john Holdsworth" <[email-masked]>
Date: Tue, 27 May 2003 10:12:37 +0100

If only that was the only question about Stun!!. While a lot of soft and
Hardphones do send and receive on the same port (both signalling and media
streams (although different port numbers for signalling and media of
course). Many sip phones do not.

There are significant security benefits by having traffic source and sink on
the same port, no to mention simpler network design.

The RFC (3261) is wide open to interpretation on this issue. Some phones
within the same SIP session use different transmit ports (e.g. when the SIP
re try timeout occurs the phone transmits from a new port!), some use
different ports for registration than for signalling etc etc. We have done
some extensive testing of SIP phones and would be glad to share what we've
found out. However its not documented in a form suitable for public
distribution, and would be best shared face to face.

The big issue for STUN is that it won't work with most (95%+?) of corporate
NATs and firewalls which translate ports on a symmetric basis. That is if
any of the source or destination details change a new NAT mapping is
employed. This makes STUN useless.

When the  STUN server is sent the discovery message it reports a port on the
public side of the NAT. Since the destination SIP client has a different
address than the STUN server, the public side NAT port mapping changes when
the media or signalling packet is sent to the actual Destination.

We are producing a signalling and media proxy which avoids this issue by
focussing all the traffic through it. This also provides a place to enforce
quality, charge and perform legal intercept.

Also if the phone transmits and receives media on the same port, we can
avoid the need to alter the corporate NAT/Firewall at all and offer public
service. This technique also offers enhanced security as well. We call this
Automatic Channel Mapping.

Please down load the "Solving the Firewall and NAT Traversal Issues for
Multimedia over IP Services" White paper from our website
(www.newport-networks.com), which contains a review of all the known
Nat/Firewall traversal methods.

Also please feel free to contact myself on +441291635830 or +44778606104 if
I can help

Regards JH

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 26 May 2003 17:00
To: [email-masked]
Subject: midcom digest, Vol 1 #688 - 1 msg

Send midcom mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/midcom
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of midcom digest..."

Today's Topics:

   1. On STUN (Ines Feki)

--__--__--

Message: 1
From: "Ines Feki" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>, <[email-masked]>
Date: Mon, 26 May 2003 10:57:05 +0200
Organization: France Telecom R&D
Subject: [midcom] On STUN

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01C32375.8BA4B940
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I have some questions about STUN :

I would like to know why and how STUN does not adress outgoing =
communications as mentionned in the Section 14.1 of the RFC.

Once the client knows its public adress returned by the STUN Server, can =
it use it to send UDP communications ?
Am I right or wrong ?

Can somebody explain me=20
Many thanks and
Best regards,

_______________________________________________________________________
Ines Feki

Trainee                                                                  =
Phone : Office +33 (0) 2 31 75 91 86=20
France Telecom R&D                   =20
42, Rue des Coutures  =20
14066 Caen FRANCE             =20
www.francetelecom.com
_______________________________________________________________________
------=_NextPart_000_0061_01C32375.8BA4B940
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DVerdana size=3D1>Hello,</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1>I have some questions about STUN =
:</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1>I would like to know why and how STUN =
does not=20
adress outgoing communications as mentionned in the Section 14.1 of the=20
RFC.</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1>Once the client&nbsp;knows&nbsp;its =
public adress=20
returned by the STUN Server, can it use it to send UDP communications=20
?</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1>Am I right or wrong ?</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT><FONT face=3DVerdana=20
size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1>Can somebody explain me </FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1>Many thanks and</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1>Best regards,</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D1></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana=20
size=3D1>________________________________________________________________=
_______<BR>Ines=20
Feki</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DVerdana=20
size=3D1>Trainee&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; Phone : Office +33 (0) 2 31 75 91 86 <BR>France =
Telecom=20
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1>42, Rue des Coutures&nbsp;&nbsp; =
<BR>14066 Caen=20
FRANCE&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
</FONT></DIV>
<DIV><FONT face=3DVerdana size=3D1><A=20
href=3D"http://www.francetelecom.com">www.francetelecom.com</A><BR>______=
_________________________________________________________________</FONT><=
/DIV></BODY></HTML>

------=_NextPart_000_0061_01C32375.8BA4B940--

--__--__--

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

End of midcom Digest

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 May 2003 13:44:12 -0400

> distribution, and would be best shared face to face.

This is an RTP/SDP issue, not a SIP issue per se. The specifications 
only mandate a destiantion port, not a source port.

> employed. This makes STUN useless.

The RFC is clear on this point. STUN does not help with these 
symmetric NATs. STUN can help discover that this NAT is present. Its 
main benefit is that when it does work, its very effective and very 
cheap for everyone involved.

To cover all of the NAT cases, you will want to also use a protocol 
like TURN, which allows for a relay-type of box. The ICE protocol 
(http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt) 
talks about how STUN, TURN and other mechanisms all get used together 
to fall into the optimal solution for any particular network 
configuration.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com