[VOIPSEC] TLS and Firewalls

[Michael Sandee]

Hi Brian,

So in this scenario we have different types metadata, no problem. 
Quality of Service can be set on a per IP packet basis using Type of 
Service [1] and Precedence [2], this can be differentiated for voice 
(real-time), signalling (reliability), video... etc ... yes we are still 
using a packet switched network... And Layer 2 QoS can be supported by 
utilising the IEEE 802.1p standard.

STUN [3] is both a firewall and user-agent issue, however it deals with 
NAT and also works through Double NAT, so it should work with a regular 
firewall. Ever wondered why user-agents report STUN as supported. Snom 
keeps breaking and repairing STUN in every release cycle :)

Regards,

Michael

[1] Service Mapping - Internet Protocol Type of Service mappings
http://www.faqs.org/rfcs/rfc795.html
[2] Internet Protocol
http://www.faqs.org/rfcs/rfc791.html
[3] Simple Traversal of User Datagram Protocol Through Network Address 
Translators
http://www.faqs.org/rfcs/rfc3489.html

Brian Rosen wrote:

>Consider a conference with voice, video and IM streams, plus floor control.
>You now have 5 separate streams coming on the SAME PORT.  You cannot have
>separate QoS treatment, you cannot have separate bandwidth management, and
>you cannot have separate priority.
>
>And, to be careful, STUN works with all devices, it doesn't work with all
>firewalls.
>
>Brian
>
>  
>
>>-----Original Message-----
>>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>>Behalf Of Michael Sandee
>>Sent: Wednesday, February 09, 2005 2:15 PM
>>Cc: Voipsec at voipsa.org
>>Subject: Re: [VOIPSEC] TLS and Firewalls
>>
>>Brian,
>>
>>RTP and the problems surrounding firewalls, NAT/PAT have been around for
>>quite a few years, being it H323, SIP or...
>>Trying to globally solve this is a nice goal to set, but (apparently)
>>impossible to accomplish. There are workarounds like STUN which work
>>with _some_ devices.
>>
>>If one protocol comes forward which has some distinct advantages over
>>the alternatives, it cannot be considered a "Not Invented Here"
>>protocol. The advantages are not only a single port, but also trunking
>>and some other features which are very useful in a practical pbx
>>environment.
>>
>>Can you please elaborate on why exactly IAX is bad for choosing a single
>>port as transport?
>>
>>Michael
>>
>>Brian Rosen wrote:
>>
>>    
>>
>>>Ultimately, this is the problem with IAX.  It's a special protocol,
>>>promulgated by a small group, without a rigorous process.
>>>
>>>It's not in the general interest of the Internet Community (whatever that
>>>is) to have multiple ways to do the same thing.  SIP is the way the IETF
>>>decided to do session management, including voice, video and text
>>>      
>>>
>>(although
>>    
>>
>>>there are other IM protocols).  IETF is not the only game in town, of
>>>course.
>>>
>>>I think that, actually, the IAX one port idea is a bad way to handle
>>>signaling and multiple media streams related to the same session.  The
>>>      
>>>
>>fact
>>    
>>
>>>that it makes it easier on the firewalls is not enough to overcome the
>>>limitations it has.  We're better off working to make SIP and firewalls
>>>      
>>>
>>work
>>    
>>
>>>better together.
>>>
>>>Brian
>>>
>>>
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>>>>Behalf Of Diana Cionoiu
>>>>Sent: Wednesday, February 09, 2005 12:09 PM
>>>>To: Alexander
>>>>Cc: Voipsec at voipsa.org
>>>>Subject: Re: [VOIPSEC] TLS and Firewalls
>>>>
>>>>If you find any RFC avaibile for IAX let me know. Until now we have
>>>>implement IAX based on what we have been able to learn from other people
>>>>code. The problem with IAX secure is that of course there is no standard
>>>>and we have to get all developers from different projects together and
>>>>"maybe" we are lucky enough to convince them to make it work right.
>>>>>From my experience each project has his own IAX version.
>>>>
>>>>Diana
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>>one port. The problem with IAX is that are no devices around. We hope
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>that
>>>>
>>>>
>>>>        
>>>>
>>>>> There are some devices with IAX support, and the trend is, there
>>>>> will be more soon. Just few of them:
>>>>>
>>>>> http://www.iaxtalk.com/
>>>>> http://www.digium.com/index.php?menu=iaxy
>>>>> http://www.farfon.com/
>>>>>
>>>>>Regards,
>>>>>/Al
>>>>>
>>>>>_______________________________________________
>>>>>Voipsec mailing list
>>>>>Voipsec at voipsa.org
>>>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>_______________________________________________
>>>>Voipsec mailing list
>>>>Voipsec at voipsa.org
>>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>
>>>
>>>_______________________________________________
>>>Voipsec mailing list
>>>Voipsec at voipsa.org
>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>Voipsec mailing list
>>Voipsec at voipsa.org
>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>
>>    
>>
>
>
>
>
>  
>