[low-priority] RE: [VOIPSEC] TLS and Firewalls

Thu Feb 10 16:13:42 CST 2005

Hey, this is strange: the specification
(http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pidf-lo-03.txt) goes
on an on (Section 4) about encrypting the PIDF document (naturally, using
S/MIME) and says nothing about transport-level security, a.k.a. TLS. They
even mention the possibility of encrypting the Location Object in a way that
some intermediaries would be able to read and reseal the information.

Sounds to me like a conflict between privacy concerns and the need to
actually use this information - for emergency treatment in this case.

    Yaron

----- Original Message ----- 
From: "Brian Rosen" <br at brianrosen.net>
To: "'Brian Raymond'" <Brian.Raymond at dataline.com>; "'Srinivasa Rao
Addepalli'" <srao at intoto.com>; "'Thomas Howe'" <howethomas at aol.com>;
"'Michael Sandee'" <ms at zeelandnet.nl>
Cc: "'VoIPsec'" <Voipsec at voipsa.org>
Sent: Thursday, February 10, 2005 22:35
Subject: [low-priority] RE: [VOIPSEC] TLS and Firewalls

> 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