[VOIPSEC] TLS and Firewalls
Brian Rosen
br at brianrosen.net
Thu Feb 10 10:21:57 CST 2005
Yes, I think that's the right model; the firewall is a B2BUA.
That also aids its "statefull inspection" characteristic; since it actually
will transition the B2BUA states, it can determine if the remote party is
correctly following state changes, etc. It's a bit unusual for a firewall
to have such an active role, but then again, most protocols don't have any
way for secure versions to pass firewalls where SIP does.
Brian
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Thomas Howe
> Sent: Thursday, February 10, 2005 10: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
>
More information about the Voipsec
mailing list