[VOIPSEC] Legal (lawful) interception
Albert
caruabertu at gmail.com
Thu May 11 08:37:36 CDT 2006
This came my way:
http://www.telestrategies.com/ISS_SPR06/
p.s. google finds 63,900 entries for the search criteria "voip legal
interception"
2006/5/10, Voipsec-request at voipsa.org <Voipsec-request at voipsa.org>:
> 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: mid-span decrypt (Jim Donovan)
> 2. Re: CALEA Enforcement (Bipin_Mistry at 3com.com)
> 3. Network Capacity During Emergencies (Jonathan Zar)
> 4. Re: Network Capacity During Emergencies (Philip Walenta)
> 5. Re: CALEA Enforcement (Geoff Devine)
> 6. Virus/Worms/Trojan attack against VoIP (Gupta, Sachin)
> 7. Re: Virus/Worms/Trojan attack against VoIP (gary madsen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 May 2006 07:54:37 -0400
> From: "Jim Donovan" <jdonovan at covergence.com>
> Subject: Re: [VOIPSEC] mid-span decrypt
> To: <Voipsec at voipsa.org>
> Message-ID:
> <0D1719326D64BD4E9F92A0C120237678CEF55A at eserv.covergence.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Bill -
>
> The media (voip, video, IM chat, etc.) recording functions of the
> Covergence appliance are typically only activated based on demand (using
> policy or dial prefix). For example, if the network operator received a
> court order to target a particular individual, a policy could be
> activated that would target only that individual. The policy
> mechanism is also granular enough to only record calls that (for
> example) are between a U.S. subscriber and PSTN or VOIP subscriber
> outside of the U.S.
>
> You are correct in your assumption that the appliance must be part of
> the call setup for this feature to be used. Given that the product is
> typically used to provide SIP firewall, encryption, and other session
> control features at the edge of carrier and enterprise networks, the
> appliance is already in the call setup path for other purposes besides
> call recording. For example, a typical application of the product
> would be to provide TLS and SRTP encryption over the untrusted public
> network and then remove this encryption once the call enters the trusted
> private network. If you would like more info, please drop me a note.
>
> Thanks,
> Jim
> jdonovan at covergence.com
>
> ------------------------------
>
> Message: 4
> Date: Tue, 09 May 2006 17:32:12 -0400
> From: Bill Flanagan <flanagan at flanagan-consulting.com>
> Subject: [VOIPSEC] mid-span decrypt
> To: Voipsec at voipsa.org
> Message-ID: <44610A5C.4010305 at flanagan-consulting.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jim,
> Is you appliance intended to carry every conversation of an ISP? or
> just when presented with a court order?
>
> Am I correct in inferring that the appliance must be part of the call
> setup to capture the key(s) by acting as man in the middle?
>
> Bill
>
> >
> >------------------------------
> >
> >Message: 4
> >Date: Mon, 8 May 2006 06:23:21 -0400
> >From: "Jim Donovan" <jdonovan at covergence.com>
> >Subject: Re: [VOIPSEC] CALEA Enforcement
> >To: <Voipsec at voipsa.org>
> >Message-ID:
> > <0D1719326D64BD4E9F92A0C120237678CEF104 at eserv.covergence.com>
> >Content-Type: text/plain; charset="us-ascii"
> >
> >Hi Sachin -
> >
> >The CALEA requirements you mention in your note are one of the reasons
> >why Covergence has developed mid-stream encryption / decryption
> >capabilities as well as extensive call recording capabilities. The
> >mid-stream encryption / decryption capabilities allow you to run SIP
> >TLS and/or SRTP in your network and our appliance will remove the
> >encryption, capture the bidirectional RTP packets, and if necessary,
> >re-encrypt for transmission to the next hop in the network. Our
> >appliance has dedicated hardware to ensure that the integrity of the
> >media is not impaired as a result of this process. The captured RTP
> >streams are then coupled with an accounting record. This information
> >can be stored on our appliance or swept out to third-party database.
> >The stored media recording and associated call record allows the
> >captured media to be accessed by law enforcement personnel or network
> >technicians for the purpose of troubleshooting call quality. Whether
> >or not an individual call is recorded is done based on a finely
> >granular policy that allows the network operator and law enforcement
> personnel to
> >determine who, what, and when to record.
> >
> >Thanks,
> >Jim
> >www.covergence.com
> >jdonovan at covergence.com
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 May 2006 09:05:17 -0400
> From: Bipin_Mistry at 3com.com
> Subject: Re: [VOIPSEC] CALEA Enforcement
> To: Olivier GRALL <olivier.grall at neotip.com>
> Cc: Voipsec-bounces at voipsa.org, Voipsec at voipsa.org
> Message-ID:
> <OF7151B7C7.B5B347FA-ON8525716A.0047A24B-8525716A.0047E42B at 3com.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> I still trying to get my head round the latest CALEA enforcement
> requirements - which from what I can tell the latest document hasn't been
> published. But I do have a question.
>
> Is there a requirements at this moment to intercept internal LAN calls -
> i.e. VoIP calls within the LAN infrastructure or is it purely the
> requirement to intercept at the point of de-marc i.e. LAN to WAN or LAN to
> PSTN.
>
> Bipin
>
>
>
> Olivier GRALL <olivier.grall at neotip.com>
> Sent by: Voipsec-bounces at voipsa.org
> 05/10/2006 06:14 AM
>
> To
> Voipsec at voipsa.org
> cc
>
> Subject
> Re: [VOIPSEC] CALEA Enforcement
>
>
>
>
>
>
> With ICE methodology, an optimized path for RTP/RTCP streams is decided
> by SIP UA even if there is a NATed access to the VoIP service.
> In most cases, this results in an exchange of RTP/RTCP packets directly
> between 2 UA perhaps through NAT boxes. In other cases , the media
> packets need to be relayed by a dedicated server (TURN) which won't have
> any connectivity to a LIU (Legal Interception Unit).
>
> So a solution may be to force the relay of media packets through a
> server with LIF or LIU connectivity. This can be done changing SDP
> offers/answers in a border element (SBC) speaking SIP. This media relay
> may have a fixed IP address. If the VoIP service provider activates
> this when a legal interception is needed, then all the media traffic
> will come from the media relay. I think if the person under surveillance
> used to have a look at the network flow then he can detect that the call
> is different than before legal interception activation.
>
> Olivier GRALL.
> NeoTIP SA.
>
>
> Gupta, Sachin a ?crit :
>
> > Please see comments inline
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Olivier GRALL
> >Sent: Tuesday, May 09, 2006 5:38 AM
> >To: Karthik Srinivasan
> >Cc: Voipsec at voipsa.org
> >Subject: Re: [VOIPSEC] CALEA Enforcement
> >
> >Skype partners for SkypeIn or SkypeOut are VoIP providers. So, they
> should be included.
> >
> >Skype is clearly a problem to legal interception functions. But it is not
> alone. Beyond that, a simple call between two IP addresses won't be on the
> responsibility of a Telecom Service provider. But it can be the Internet
> Service provider responsibility. Then, a solution is that the ISP watch
> for all the traffic looking for VoIP signalizations. If the ISP can
> identify Skype traffic then it can forbid it. But I think it is hard to
> identify clearly Skype traffic. For the moment, I think an ISP can't
> verify all the traffic on its network.
> >
> >For VoIP Service provider, there is another issue. For instance, for SIP,
> if ICE methodology is deployed then media packets won't be available to be
> duplicated in most cases. And if we modify the media packets usual way
> then a detection of the interception is possible.
> >
> >[Sachin] : Can you elaborate more on this
> >
> >
> >Olivier GRALL
> >NeoTIP SA
> >
> >Karthik Srinivasan a ?crit :
> >
> >
> >
> >>Ok.. Just read the note better. It does include VoIP providers. So, I
> guess Vonage gets included. How about Skype? Does SkypeIn/SkypeOut
> contribute to being a VoIP provider with interconnects?
> >>
> >> Has anyone done a study on financial ramifications of such regulatory
> deployments? Can such deployments be built in a way as to leading to
> improved services?
> >>
> >> -- Karthik
> >>
> >>Karthik Srinivasan <karsrini1973 at yahoo.com> wrote:
> >> The order has targeted the telecom carriers. But what about providers
> like Vonage or services like Skype. If someone is "on the wall" as far as
> the law is concerned, they may as well use these services and escape any
> intercept.
> >>
> >>Geoff Devine <gdevine at cedarpointcom.com> wrote:
> >> If you look at standards bodies like 3GPP and TISPAN, the EU is
> >>certainly treating lawful intercept as a core requirement for VoIP
> >>networks. The US requirement that all service providers offer the
> >>equivalent of J-STD-025 call content and call detail also exists in
> >>ETSI documents. Class 5 offices have been required to support lawful
> >>intercept for years. That requirement is now being pushed to edge
> >>devices like media gateways, CMTSs, DSLAMs, and edge routers. Not only
> >>is it feasible, but it's already implemented in North America for all
> >>the voice over cable deployments (approaching 3 million VoIP lines and
> >>growing exponentially).
> >>
> >>PacketCable uses an SDESCRIPTIONS-like key exchange where the media
> >>keying is passed in the clear within the SDP. Call signaling is
> >>encrypted between the client device and the walled garden. It's more
> >>secure than today's telephone network since you have to be at the cable
> >>head end (inside the walled garden) to see decrypted signaling traffic.
> >>With a butt set, I can listen in on any analog phone line by tapping in
> >>anywhere on the copper loop.
> >>
> >>Geoff Devine
> >>Chief Architect
> >>Cedar Point Communications
> >>
> >>----------------------------------------------------------------------
> >>
> >>Date: Sat, 6 May 2006 14:29:53 +0200
> >>From: "Voiceline"
> >>
> >>Subject: Re: [VOIPSEC] CALEA Enforcement
> >>To: "Gupta, Sachin" ,
> >>Message-ID: <000f01c67108$c70d1c00$0b01a8c0 at patrick>
> >>Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> >>reply-type=original
> >>
> >>The fourth order: "call-identifying information" and "call content
> >>information"
> >>Call content information is taking it to fare in my opinion (Not even
> >>getting in to the "protecting subscriber privacy" issue), the ISP would
> >>have to store all the content of all calls, not feasible in any
> >>practical sense.
> >>The EU is seemingly not taking it that fare, only call-identifying
> >>information is on the table, "at the moment"...
> >>
> >>
> >>/Patrick
> >>
> >>----- Original Message -----
> >>From: "Gupta, Sachin"
> >>To:
> >>Sent: Friday, May 05, 2006 10:33 PM
> >>Subject: [VOIPSEC] CALEA Enforcement
> >>
> >>
> >>
> >>
> >>
> >>
> >>>I came across an article which mentions the enforcement of CALEA .
> >>>
> >>>
> >>>
> >>>
> >>Would
> >>
> >>
> >>
> >>
> >>>this mean no end-to-end security ?
> >>>How would any kind of legal intercept be possible if there is
> >>>
> >>>
> >>>
> >>>
> >>end-to-end
> >>
> >>
> >>
> >>
> >>>security ?
> >>>
> >>>http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-265221A1.pdf
> >>>
> >>>Sachin
> >>>
> >>>
> >>>
> >>>
> >>
> >>_______________________________________________
> >>Voipsec mailing list
> >>Voipsec at voipsa.org
> >>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >>
> >>
> >>---------------------------------
> >> How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call
> rates.
> >>
> >>
> >>---------------------------------
> >>Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great
> rates starting at 1¢/min.
> >>_______________________________________________
> >>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: 3
> Date: Wed, 10 May 2006 07:08:32 -0700
> From: "Jonathan Zar" <jonathan.zar at voipsa.org>
> Subject: [VOIPSEC] Network Capacity During Emergencies
> To: <voipsec at voipsa.org>
> Message-ID: <000e01c6743b$3934ec60$6601a8c0 at c400>
> Content-Type: text/plain; charset="us-ascii"
>
>
> I'd like to invite comment on the VOIPSEC list on what happens to VOIP
> traffic during significant emergencies.
>
> Are you seeing VOIP added to business continuity planning ?
>
> In multinational operations with significant VOIP trunking, what happens if
> there is a sudden spike in the VOIP traffic ?
>
> What would you recommend to your customers in the event data remains up when
> other forms of communication fail ?
>
> Finally, do you see overflow planning to allow employees to use alternative
> VOIP systems in the event they are stranded and unable to get to approved
> communication ?
>
> An emergency might include a major natural disaster, pandemic or selective
> infrastructure failure.
>
> Your voice of experience either from practice, planning or statistical
> analysis and modeling is invited on this thread.
>
> Best Regards,
>
> Jonathan Zar
> Tel: +1 (510) 275-1480
> Fax: +1 (510) 275-1481
> Cell: +1 (408) 209-0199
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 10 May 2006 10:10:25 -0500
> From: "Philip Walenta" <pwalenta at wi.rr.com>
> Subject: Re: [VOIPSEC] Network Capacity During Emergencies
> To: <jonathan.zar at voipsa.org>, <voipsec at voipsa.org>
> Message-ID: <01a101c67443$de5aa0b0$0232a8c0 at walentawk1>
> Content-Type: text/plain; charset="us-ascii"
>
> Some of the large deployments I've done have had a fair amount of fault
> tolerance built in.
>
> Unfortunately not all. Rest of my comments inline below.
>
> Philip Walenta
> 262.951.1941
> pwalenta at wi.rr.com
>
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org
> > [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Jonathan Zar
> > Sent: Wednesday, May 10, 2006 9:09 AM
> > To: voipsec at voipsa.org
> > Subject: [VOIPSEC] Network Capacity During Emergencies
> >
> >
> > I'd like to invite comment on the VOIPSEC list on what
> > happens to VOIP traffic during significant emergencies.
> >
> > Are you seeing VOIP added to business continuity planning ?
>
> I've had two clients that as part of the system install/evaluation go
> through a complete plan and even went through significant disaster testing
> where just about every type of single and multiple failure occurred (single
> core outage, multiple data center outage).
> >
> > In multinational operations with significant VOIP trunking,
> > what happens if there is a sudden spike in the VOIP traffic ?
> >
> Overflow trunking was built in, so that if all VoIP allowed bandwith was
> used, it overflowed to PSTN based services.
>
> > What would you recommend to your customers in the event data
> > remains up when other forms of communication fail ?
>
> I've actually had this particular scneario happen only once, and that was
> due to the voice traffic not being routed properly in the first place
> (client had several networks consisting of frame, VPN and MPLS, and voice
> traffic wasn't being routed properly, so when a disaster hit, the voice
> traffic was misrouted virtually everywhere). But what I've seen most
> clients do is ensure there are published cell phone lists, and a few analog
> lines spread among the buildings. Not necessarily the most practical thing,
> but it's at least better than nothing.
>
> >
> > Finally, do you see overflow planning to allow employees to
> > use alternative VOIP systems in the event they are stranded
> > and unable to get to approved communication ?
>
> Had only one client go down the path this far, only because they've kept
> near-perfect records of disasters and phone system usage. Essentially, they
> had several "crash carts" waiting to be deployed in the event of this
> significant of a failure because they knew the exact size of any given
> system, and had complete backups and drives which could be restored on a
> moments notice.
>
> >
> > An emergency might include a major natural disaster, pandemic
> > or selective infrastructure failure.
> >
> > Your voice of experience either from practice, planning or
> > statistical analysis and modeling is invited on this thread.
>
> As far as general advice - most of the time it isn't the voip system itself
> causing or having a problem - it's the network. I cannot stress enough to
> anyone I design or deploy a system for - build the network right, QoS,
> security, routing, DHCP/DNS, load-balancing. I would say at least 90% of
> the time there's been some issue during an outage, it's a network
> configuration causing the issue. My biggest thing is eliminating
> spanning-tree wherever possible. Even with the advent of 802.1w (rapid
> spanning-tree), I find that a routing table/protocol that already has active
> multiple paths converges faster (when properly configured) than 802.1w. In
> essence, layer 3 is still faster and more reliable than layer two in my
> experience. I actually know of one company that is almost 100% layer 3,
> where each closet switch (no matter the size of the closet) is L3 connected
> to at least two different upstream devices - and they've not had a single
> issue no matter what has gone on.
>
> The one other thing I recommend is know your traffic. Both network based,
> and PSTN trunk based. Capacity planning is another thing I've seen
> seriously lacking in many facilities. The network is built right, but not
> monitored correctly - usually a major outage or two which might have been
> forseeable cures this. But I *hate* eagle-eye hindsight.
>
> Hope this helps.
>
> >
> > Best Regards,
> >
> > Jonathan Zar
> > Tel: +1 (510) 275-1480
> > Fax: +1 (510) 275-1481
> > Cell: +1 (408) 209-0199
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 10 May 2006 13:51:15 -0400
> From: "Geoff Devine" <gdevine at cedarpointcom.com>
> Subject: Re: [VOIPSEC] CALEA Enforcement
> To: <Voipsec at voipsa.org>
> Message-ID:
> <9CDE330E7358724EA30D93598D24DE4A01D15040 at exchange.cedarpointcom.com>
> Content-Type: text/plain; charset="us-ascii"
>
> The only way to make lawful intercept undetectable is to _ALWAYS_ run
> the media through a session border controller. You can call an SBC a
> TURN Server if you like and put the intercept function there.
>
> PacketCable islands solve the problem in a slightly different way.
> Rather than require an SBC in their network, they make the ingress &
> egress points on their network deal with the problem. The cable
> operator owns their own CMTSs (the cable access network device) and
> Media Gateways. They have the CMTS and MG sniff intercepted RTP flows
> and redirect a copy of the flow to a lawful intercept delivery function.
> If the RTP stream is encrypted, the soft switch relays the keying
> information to the delivery function on another interface. End to end
> key exchange uses an SDESCRIPTIONS-like method where the keys are
> embedded in the SDP of the call signaling. The call signaling is made
> private using transport mode IPSec.
>
> In that architecture, once you have SIP peering relationships between a
> PacketCable island and some other network, you pretty much have to put
> an SBC on the border to get lawful intercept. Otherwise, you can defeat
> the lawful intercept via a call redirection mechanism like call
> forwarding or call transfer.
>
> Geoff Devine
> Chief Architect
> Cedar Point Communications
>
> *****************************************************************
> Date: Wed, 10 May 2006 12:14:19 +0200
> From: Olivier GRALL <olivier.grall at neotip.com>
> Subject: Re: [VOIPSEC] CALEA Enforcement
> To: Voipsec at voipsa.org
> Message-ID: <4461BCFB.20200 at neotip.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> With ICE methodology, an optimized path for RTP/RTCP streams is decided
> by SIP UA even if there is a NATed access to the VoIP service.
> In most cases, this results in an exchange of RTP/RTCP packets directly
> between 2 UA perhaps through NAT boxes. In other cases , the media
> packets need to be relayed by a dedicated server (TURN) which won't have
>
> any connectivity to a LIU (Legal Interception Unit).
>
> So a solution may be to force the relay of media packets through a
> server with LIF or LIU connectivity. This can be done changing SDP
> offers/answers in a border element (SBC) speaking SIP. This media relay
>
> may have a fixed IP address. If the VoIP service provider activates
> this when a legal interception is needed, then all the media traffic
> will come from the media relay. I think if the person under surveillance
>
> used to have a look at the network flow then he can detect that the call
>
> is different than before legal interception activation.
>
> Olivier GRALL.
> NeoTIP SA.
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Wed, 10 May 2006 16:31:35 -0500
> From: "Gupta, Sachin" <s-gupta2 at ti.com>
> Subject: [VOIPSEC] Virus/Worms/Trojan attack against VoIP
> To: <Voipsec at voipsa.org>
> Message-ID:
> <772F5D89C5E0734B8A86D85DFC6A2024034172D4 at dlee03.ent.ti.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> Is anybody aware of the possibility of virus attack on a Resedential
> Gateway / IP Phone, running of a well known Operating system, with Voice
> capabilities ?
> This kind of attack can even remove or change the digital certificates .
> Soft phones may not fall in this category as they run on PCs which may
> have antivirus installed.
>
> Is this a theoritical attack or anything like this has happened before?
>
>
> Sachin
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 10 May 2006 16:45:29 -0500
> From: "gary madsen" <gmads.seclists at gmail.com>
> Subject: Re: [VOIPSEC] Virus/Worms/Trojan attack against VoIP
> To: "Gupta, Sachin" <s-gupta2 at ti.com>
> Cc: Voipsec at voipsa.org
> Message-ID:
> <84789390605101445i4c5dfccco10cca9be62417686 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> A few come to mind related to Cisco. Any VoIP vendor is prone to worm
> attacks though if the underlying OS is vulnerable. Cisco is just good
> about documenting these issues.
>
> http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801ae3dc.shtml
> http://www.ciac.org/ciac/bulletins/l-120.shtml
> http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00800941e4.shtml
>
> Cheers,
> Gary
>
> On 5/10/06, Gupta, Sachin <s-gupta2 at ti.com> wrote:
> > Hi,
> >
> > Is anybody aware of the possibility of virus attack on a Resedential
> > Gateway / IP Phone, running of a well known Operating system, with Voice
> > capabilities ?
> > This kind of attack can even remove or change the digital certificates .
> > Soft phones may not fall in this category as they run on PCs which may
> > have antivirus installed.
> >
> > Is this a theoritical attack or anything like this has happened before?
> >
> >
> > Sachin
> > _______________________________________________
> > 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 17, Issue 14
> ***************************************
>
More information about the Voipsec
mailing list