[VOIPSEC] TLS and Firewalls
Brian Raymond
Brian.Raymond at dataline.com
Thu Feb 10 15:49:10 CST 2005
You are correct about the signaling, I should have said "generally a
secondary concern".
I agree about not using a "transparent proxy" since as we've both said, it
would cause problems with the standard. The closest comparison I can make
for what a transparent proxy is would be the use of say Squid in transparent
mode. I haven't heard the term outside of the HTTP proxy space aside from
some things that do in fact mangle SDP or H.225/H.245.
I also agree and hope I wasn't implying that you would be terminating the
media since that shouldn't have to happen.
- Brian
On 2/10/05 3:35 PM, "Brian Rosen" <br at brianrosen.net> wrote:
> Yeah, I expect you are getting déjà vu all over again.
> Maybe the difference is that this time, we do in fact have more customers
> asking their firewall vendors to support their VoIP systems.
>
> It is NOT true that the signaling is less important than the media. Depends
> on the threat model.
>
> One of the things I need to keep reminding people is that emergency calls
> (9-1-1/1-1-2) carry location IN THE SIGNALING. They use the PIDF-LO object
> defined in IETF geopriv. This true for SIP and H.323, and IXP will need a
> similar capability.
>
> The specifications REQUIRE that you encrypt the location data. Since
> location is needed to route an emergency call, we need to use hop by hop
> security (TLS), and in fact the specs say that.
>
> If the endpoint attempts to use TLS and the firewall blocks the call from
> completing, people can die. Woah Nelly, tel:1-800-lawsuitsRus
>
> I'm confused about this:
>> Transparent proxies might be something to consider but if you are indeed
>> terminating connections (which is required for looking inside TLS
>> connections) then you would need to rewrite the SDP messages with the
>> address of the termination point. That in itself will cause possible
>> problems with SIP and violate the protocol. SIP can do proxy routing,
>> which
>> is within the bounds of the standard and I would think a much more viable
>> approach to solve this problem.
> I don't understand why you need to terminate the media connections.
> If you used a B2BUA, you would not, for the B2BUA's purpose, need to rewrite
> SDP. You would not need to change the address/port of the endpoint; you
> simply pass them through. One of the clever parts of SIP is that the
> signaling addresses don't have to be the same as the media addresses.
>
> I'm not sure what anyone means by a "transparent proxy". AFAIK, there isn't
> any such thing. If you are a proxy, you behave as RFC3261 says to behave,
> which means, among other things, you add a VIA. That's not transparent. A
> proxy definitely WOULD NOT terminate media.
>
> I think we're in agreement that you end up terminating the TLS, so you need
> to be either a proxy of some sort or a B2BUA.
>
> Brian
>
>
>> -----Original Message-----
>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>> Behalf Of Brian Raymond
>> Sent: Thursday, February 10, 2005 2:40 PM
>> To: Srinivasa Rao Addepalli; Thomas Howe; Michael Sandee
>> Cc: VoIPsec
>> Subject: Re: [VOIPSEC] TLS and Firewalls
>>
>> I have a long history with more legacy protocols, H.320, H.323 etc. so I'm
>> reliving a lot of the same things with SIP that people attempted to
>> address
>> with H.323. In this case the mention of ALGs on firewalls brings back a
>> lot
>> of memories.
>>
>> One thing to consider when using the firewall as an ALG for traffic (be it
>> a
>> B2BUA, proxy) is the amount of overhead it needs to deal with for both SDP
>> parsing and TLS termination if that is being utilized. In the end though
>> just as in H.323 the data that is most important to keep confidential is
>> the
>> RTP data itself, the signaling was a secondary concern but never as
>> important. H.323 has H.235 to solve that problem and it is effective at
>> what
>> it does, albeit not widely implemented. There isn't really a way around
>> this
>> problem but I think more research needs to be done to determine the best
>> way
>> to maintain a good security profile without demanding too much in the way
>> of
>> hardware resources.
>>
>> Transparent proxies might be something to consider but if you are indeed
>> terminating connections (which is required for looking inside TLS
>> connections) then you would need to rewrite the SDP messages with the
>> address of the termination point. That in itself will cause possible
>> problems with SIP and violate the protocol. SIP can do proxy routing,
>> which
>> is within the bounds of the standard and I would think a much more viable
>> approach to solve this problem.
>>
>> - Brian
>>
>>
>>
>> On 2/10/05 1:28 PM, "Srinivasa Rao Addepalli" <srao at intoto.com> wrote:
>>
>>>
>>> I agree with you. TLS is one reason, which I feel future firewall
>>> implementations would need to implement proxies. Also, if you observe
>> the
>>> type of bugs that are being found in SIP implementations, it is not
>> entirely
>>> possible to detect and stop them, if firewalls do packet based
>> inspection.
>>> Application firewalls, i.e. proxies is one way to detect and protect
>>> internal SIP devices. Proxies need not be B2BUA and IMO, firewall
>>> implementers go with transparent proxies. Transparent proxies have
>> similar
>>> capabilities as normal proxies in terms of terminating client
>> connections
>>> and making new connections, without SIP peers knowing about it.
>>>
>>> Srini
>>>
>>> -----Original Message-----
>>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>>> Behalf Of Thomas Howe
>>> Sent: Thursday, February 10, 2005 7:00 AM
>>> To: Michael Sandee
>>> Cc: Voipsec at voipsa.org
>>> Subject: Re: [VOIPSEC] TLS and Firewalls
>>>
>>> Hi Michael -
>>>
>>> Yes, you are certainly right on that point. It is very useful to look
>>> at real world practice when working on the standards. I have to side
>>> with Brian though, and feel that as cumbersome as the standards bodies
>>> are, they are the only real way to solve the long term problem. And more
>>> than that, they have clearly identified SIP as the protocol for handling
>>> session management, and the industry is cleary behind it now.
>>>
>>> Here's my question about SIP, firewalls and architectures - please tell
>>> me where I'm right/wrong/inbetween....
>>>
>>> Given that SIP signalling uses TLS for security, doesn't that sort of
>>> imply that most firewalls will be using some sort of back to back user
>>> agent, instead of packet inspection? I mean, how will the firewall be
>>> able to decrypt the streams appropriately without being a terminating
>>> point for the call?
>>>
>>>
>>> Tom
>>>
>>>
>>>
>>> Michael Sandee wrote on 2/9/2005, 4:28 PM:
>>>
>>>> Hi Thomas,
>>>>
>>>> I accept your comments in general, however they are not true for IAX.
>>>> But I know this is nearly impossible to know without looking at the
>>>> protocol in detail. Dispite earlier comment a RFC is still in the
>> works,
>>>> and given the dozen of standards and extensions of earlier VoIP
>>>> protocols it might be better to first analyse a protocol in _practice_
>>>> before filing it as RFC.
>>>>
>>>> Ein Reich, Ein Protocol... or "One Protocol to rule them all"... I
>> think
>>>> we are not looking at IAX as a replacement of any existing protocol,
>> but
>>>> it has, as earlier pointed out, clear advantages over other protocols
>> to
>>>> deal with _current_ problems.
>>>>
>>>> The IAX protocol has a mechanism to hand off calls between 2 endpoints,
>>>> but this can be disabled on a call by call basis. Two endpoints behind
>>>> NAT naturally cannot communicate with each other in a direct path, so
>>>> this will proceed through a central/public gateway (This is usually
>> only
>>>> an issue with Internet Telephony, or very large Internetworks).
>>>>
>>>> For scalability this is ideal, because the entire call can be offloaded
>>>> to a different server, perhaps after authentication to one of the
>>>> frontends. In relation to SIP this can be done for the control channel
>>>> by using 302 Moved signalling, possibly a similar mechanism exists for
>>>> H323.
>>>>
>>>> Billing between VoIP/IP endpoints is something which is not important
>>>> (for us). These are free calls and only interesting for statistics.
>>>> However there is an extension to the protocol to actually handle this.
>>>>
>>>> Billing is usually done on the PSTN gateways.
>>>>
>>>> Regarding the security relation this might be interesting:
>>>> Given that you cannot do billing on your speech detection system, IVR,
>>>> or whatever.
>>>> Given that it is a blackbox speech processor.
>>>> Would you expose it to a direct media path to the user?
>>>>
>>>> [IAX ENDPOINT] - IP Network - [IAX GATEWAY] - SIP/H323/MGCP/SCCP/IAX -
>>>> [BACKEND SPEECH PROCESSING]
>>>> You will have a frontend either way, but it might be your security
>> rules
>>>> are different than mine.
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>>> Thomas Howe wrote:
>>>>
>>>>> Michael -
>>>>>
>>>>> Let me weigh in on that one. A single port for transport has some
>>>>> serious scaling and implementation issues. A single port makes an
>>>>> assumption that the media and control signalling are both going to the
>>>>> same place. Maybe that might be an OK assumption for an IP phone, but
>>>>> what about any large scale device? Would you really have all the media
>>>>> flow through the control processor, then out again into the media
>>>>> processor? That becomes very cumbersome, very quickly.
>>>>>
>>>>> It also has a problem with disaggregation. If you wanted to add an
>>>>> speech detection system into your network, how would that work? Would
>>>>> you put one into every IP phone? Or maybe you could come up with a
>> call
>>>>> control scheme that would hand off the call to another system. Well,
>> if
>>>>> you completely handed off the call, how would you do billing and
>>>>> authorization? Or, if you didn't, can you imagine the convoluted call
>>>>> control ladders to get that done? And if you could, then try to scale
>>>>> that puppy, and you could get a discount price on Tylonol for your
>>>>> headache.
>>>>>
>>>>> It would be so much simpler to send the RTP somewhere else for a
>> while,
>>>>> thus requiring a separate port for it. (Of course, two if you count
>>>> RTCP).
>>>>>
>>>>> This help any?
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>>
>>>>> Michael Sandee wrote on 2/9/2005, 2:15 PM:
>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
More information about the Voipsec
mailing list