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

[Brian Rosen]

Have a look at:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements
-02.txt

Section 2. discusses the issues
Section 7. has the normative text

This issue was discussed at length in geopriv, the working group that deals
with location.  It was agreed that the SIP conveyance spec would say S/MIME
preferred, TLS acceptable when intermediaries must route based on location.
That is the emergency case.

Brian

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaronf at personeta.com]
> Sent: Thursday, February 10, 2005 5:14 PM
> To: Brian Rosen; 'Brian Raymond'; 'Srinivasa Rao Addepalli'; 'Thomas
> Howe'; 'Michael Sandee'
> Cc: 'VoIPsec'
> Subject: Re: [low-priority] RE: [VOIPSEC] TLS and Firewalls
> 
> 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
> 
>