[VOIPSEC] Re: Voipsec Digest, Vol 2, Issue 6
Christopher A. Martin
chris at infravast.com
Thu Feb 10 14:22:18 CST 2005
Inline for all threads
> Send Voipsec mailing list submissions to
> Voipsec at voipsa.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> or, via email, send a message with subject or body 'help' to
> Voipsec-request at voipsa.org
>
> You can reach the person managing the list at
> Voipsec-owner at voipsa.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Voipsec digest..."
>
>
> Today's Topics:
>
> 1. Re: TLS and Firewalls (Per Cederqvist)
> 2. RE: Solutions in addressing SPIT (Spam overInternetTelephony)
> (ranjith.mukundan at wipro.com)
> 3. RE: TLS and Firewalls (Srinivasa Rao Addepalli)
> 4. RE: TLS and Firewalls (Brian Rosen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 10 Feb 2005 18:35:04 +0100
> From: Per Cederqvist <ceder at ingate.com>
> Subject: Re: [VOIPSEC] TLS and Firewalls
> To: "Thomas Howe" <howethomas at aol.com>
> Cc: Voipsec at voipsa.org
> Message-ID: <x365102u9j.fsf at rapture.ingate.se>
> Content-Type: text/plain; charset=us-ascii
Hi Per, it's been a long time, :)
WRT your comments below, to date, no ALG firewall vendor supports TLS. I
am sure that it can be done but the overhead is what these types of
vendors are trying to avoid so they do implement the SIP server. That is
one of the benefits that I like best about products such as yours.
>
> The firewall does not have to be a B2BUA. Please remember that TLS is
> used hop-by-hop in SIP. It is enough that the firewall contains a SIP
> server with support for TLS, and that it arranges to stay in the
> signaling path. That way, the firewall will also be able to look
> inside the SDP to figure out what ports to open for the media streams.
>
> Yours,
> Per Cederqvist
>
> "Thomas Howe" <howethomas at aol.com> wrote:
>
>> 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,
As far as I know TLS is only useful for the signaling path and not the
media (thats the reason for sRTP). But as I stated above, honestly the
B2BUA type vendors have developed to this level of functionality whereas
the ALG vendors still have some work to do in order to enable this type of
functionality.
Chris
I am still following this thread down below...
>>
>> 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
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 10 Feb 2005 23:27:05 +0530
> From: <ranjith.mukundan at wipro.com>
> Subject: RE: [VOIPSEC] Solutions in addressing SPIT (Spam
> overInternetTelephony)
> To: <Voipsec at voipsa.org>, <dan.frommer at gmail.com>, <mmani at avaya.com>
> Message-ID:
> <4A1C269FD5174048BBD18DD770D3437BDEE403 at blr-ec-msg01.wipro.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> sorry, looks like the attachement referred to in my mail below got
> moderated/bounced off.
>
> you can get the slide from
> http://home.ripway.com/2005-2/258282/VoIP%20Security/VoIP-Spam-Ctrl-SIP-Summit-Media-Servers.zip
>
> cheers,
> -- ranjith..
> ps: i shall mail the complete presentation to folks who have requested for
> it separately as it may not be relevant to this list.
>
> ________________________________
>
> From: Dan Frommer [mailto:dan.frommer at gmail.com]
> Sent: Thu 2/10/2005 9:27 PM
> To: Ranjith Mukundan (WT01 - TELECOM SOLUTIONS)
> Subject: Re: [VOIPSEC] Solutions in addressing SPIT (Spam
> overInternetTelephony)
>
>
> Ranjith,
>
> For some reason did not get the attached slide. Could you please re-send
> it or send me a pointer?
>
> Thanks,
> Dan
>
> ________________________________
>
> From: Voipsec-bounces at voipsa.org on behalf of ranjith.mukundan at wipro.com
> Sent: Thu 2/10/2005 8:32 PM
> To: mteicher at icsalabs.com; Voipsec at voipsa.org
> Subject: RE: [VOIPSEC] Solutions in addressing SPIT (Spam
> overInternetTelephony)
>
>
>
>
> though not a general evaluation, this I-D
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-spam-01.txt
> <http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-spam-01.txt>
> describes some of the key problems & evalutes potential solutions, in a
> SIP based voip network.
>
>
> however, this I-D does not discuss nor analyse mechnisms involving voice
> printing and use of User modifiable "Reachability Codes" in conjunction
> with the network (Server/Proxy) assigned Calling Party Number or URIs that
> vastly improves the probability of the Spam prevention and avoidance to a
> large extent.
>
>
> The "Voice Printing and User Modifiable Reachability Code" mechanism for
> Spam prevenation and avoidance is Presented in the context of an IP
> (Multi)Media Server in the attached Slide (where content is a little too
> cryptic) that I had Presented at the recently concluded SIP Summit in HI.
> We are working on a paper, along with a few other Orgs, describing this
> mechanism in detail that you may find useful. Also, I believe, a variant
> of the "User Modifiable Reachability Code" mechanism (but without the
> Voice Printing capability as Presented in the Attached Slide) is being
> deployed/trialed by a voip service provider (who apparently is also a
> large telco) in the APAC.
>
>
> cheers,
> -- ranjith..
>
>
>
> ________________________________
>
> From: Voipsec-bounces at voipsa.org on behalf of Teicher, Mark
> Sent: Thu 2/10/2005 6:17 PM
> To: Voipsec at voipsa.org
> Subject: [VOIPSEC] Solutions in addressing SPIT (Spam over
> InternetTelephony)
>
>
>
> Has anyone on this list evaluated viable solutions that address SPIT
> (Spam over Internet Telephony) for their environments ?
>
> /thx
> /mht
>
> ***********************************************************************
> This message is intended only for the use of the intended recipient and
> may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you
> are not the intended recipient, you are hereby notified that any use,
> dissemination, disclosure or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> destroy all copies of this message and its attachments and notify us
> immediately.
> ***********************************************************************
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
>
>
>
>
>
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any attachments
> to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential or
> privileged information. If
> you are not the intended recipient, please notify the sender at Wipro or
> Mailadmin at wipro.com immediately
> and destroy all copies of this message and any attachments.
>
> ------------------------------
>
> Message: 3
> Date: Thu, 10 Feb 2005 10:28:25 -0800
> From: "Srinivasa Rao Addepalli" <srao at intoto.com>
> Subject: RE: [VOIPSEC] TLS and Firewalls
> To: "'Thomas Howe'" <howethomas at aol.com>, "'Michael Sandee'"
> <ms at zeelandnet.nl>
> Cc: Voipsec at voipsa.org
> Message-ID: <200502101828.j1AISTPg013768 at angel.intoto.com>
> Content-Type: text/plain; charset="US-ASCII"
>
>
> 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
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 10 Feb 2005 13:46:03 -0500
> From: "Brian Rosen" <br at brianrosen.net>
> Subject: RE: [VOIPSEC] TLS and Firewalls
> To: "'Per Cederqvist'" <ceder at ingate.com>, "'Thomas Howe'"
> <howethomas at aol.com>
> Cc: Voipsec at voipsa.org
> Message-ID: <mailman.2.1108062927.13016.voipsec_voipsa.org at voipsa.org>
> Content-Type: text/plain; charset="us-ascii"
>
> It's possible to make the firewall a proxy server, but then it couldn't
> modify a lot of the headers. That may be okay. Remember that there
> really
> isn't a precise definition of a B2BUA other than it appears to be a User
> Agent to both sides. You can make them appear to be transparent to both
> ends. Proxy servers, if you follow the rules, are visible. If the
> firewall
> was a proxy server, it would have to add a VIA header, for example. To be
> really picky, you really would have to make the firewall-as-proxy-server
> BE
> in the path. That means it has an address, and the routing mechanisms
> cause
> the SIP messages to be sent to it. Again, that may be okay for some.
>
> Brian
>
>> -----Original Message-----
>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
>> Behalf Of Per Cederqvist
>> Sent: Thursday, February 10, 2005 12:35 PM
>> To: Thomas Howe
>> Cc: Voipsec at voipsa.org
>> Subject: Re: [VOIPSEC] TLS and Firewalls
>>
>> The firewall does not have to be a B2BUA. Please remember that TLS is
>> used hop-by-hop in SIP. It is enough that the firewall contains a SIP
>> server with support for TLS, and that it arranges to stay in the
>> signaling path. That way, the firewall will also be able to look
>> inside the SDP to figure out what ports to open for the media streams.
>>
>> Yours,
>> Per Cederqvist
>>
>> "Thomas Howe" <howethomas at aol.com> wrote:
>>
>> > 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
>
>
> End of Voipsec Digest, Vol 2, Issue 6
> *************************************
>
More information about the Voipsec
mailing list