Subject: Re: TLS for peering (was RE: Comments (RE:[speermint]requirementsdraft submitted))

From: Cullen Jennings <[email-masked]>
Date: Sat, 1 Jul 2006 20:58:49 -0700

On Jun 30, 2006, at 10:36 AM, Daryl Malas wrote:

> --Should TCP/TLS be a MUST requirement for peering authentication, or
> can it be a SHOULD requirement (made up of multiple potential methods)
> for peering?
>
> If this is the right question being argued, what is the problem in
> compromising on allowing it to be an acceptable alternative for  
> securing
> a peering relationship?

I think this is sort of the wrong question. TLS is a solution to a  
problem. The questions is, what are the problems. Then we can discuss  
what possible techniques that might be used to solve the problem.

When SP A sends a call to SP B, (and I'm talking at the SIP level  
here not the IP level), do you have a requirements for B to know the  
call came from A? possibly for billing related reasons?

Let's say SP A peers with both SP B and SP C. When A decides to route  
a call to B, do you  have requirements to guarantee that C can not  
intercept the request and end up taking the call even though it was  
meant to go to B?

I suspect you will end up with your security threats deriving the  
need for the two peers to be able to authenticate each other.

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Rohan Mahy" <[email-masked]>
Date: Tue, 4 Jul 2006 11:02:18 -0700

Hi Andy,

I'm back from vacation with answers to your questions (inline).

On 6/30/06, Andrew Newton <[email-masked]> wrote:
> Rohan,
>
> I am not a liberty to give specific numbers, but I can assure you
> that your assumptions are wrong.  We have a lot of very expensive
> equipment that would fall over if it did all signaling over TLS or
> even just TCP.  And we have done the tests and measurements, and a
> $2000 rack mount server cannot handle the load.

I want to make sure that we are talking about dozens or hundreds of
simultaneous connections for peering, and not the load necessary to
handle all your user agents registering as described in
draft-ietf-sip-outbound.

> And since you are asking for "real requirements", I'd like to know
> what your "real requirements" are for specifying TLS for signaling.
> Specifically, I'd like to know the following:
>
> 1) Why is it you are advocating security of the signaling but not the
> media?  What requirement determines that signaling is important to
> secure but media is not important to secure?

I would love to have secure media, but the issues here are priority and scope.

In the PSTN, neither media nor signaling is encrypted.  However
trusted signaling begins at the Central Office and is exchanged among
switches over trunks with generally much better physical security than
"last-mile" access links.  I can easily tap the phone of almost anyone
in my town from a nearby pole or manhole.  Its been like this for
decades and except for celebrities or individuals specifically
targeted for attack, this lack of media security has been a non-issue
for the most part in the PSTN. If we take this running network as any
indication of priority, signaling protection is more important than
media protection.

The attacks that are possible against protected signaling and
unprotected media (media hijacking, media recording) are a strict
subset of those possible against unprotected signaling (identity
spoofing, toll-fraud, etc..).  The attacks on unprotected signaling
involve significant financial motivations, while there is very poor
positive financial motivation for attacks on the media alone.

Second, the scope of this group is to define a practical peering
convention that can be used over the public Internet.  The group is
not scoped with defining or limiting every aspect of behavior within
the two administrative domains that are peering.  Just like I feel it
is inappropriate to mandate a specific codec, I feel it is
unreasonable for this group to mandate that all endpoints that may
ever be involved in a peered session need to support media encryption.

Third, as demonstrated in the raiarea meeting in Dallas, there still
is no consensus around a single secure media transport and keying
mechanism.

Finally, I assert that TLS for signaling is easy and inexpensive
compared to the alternatives, and that the cost is wholly at the point
of interconnection between the peers.

> 2) Why do you believe TLS offers better authentication than any other
> method, especially given that there is no global trust anchor?

TLS is the only documented mechanism that provides the UAC or SIP
proxy with a way to verify the identity of the next (SIP) hop.

Regarding the trust anchor issue, the TLS client and server can use
local authorization policy to decide if the root of a particular cert
chain is acceptable.  This is no different from the authorization
policy you need for IPsec.

> 3) What requirement makes TLS more secure than a dedicated link?

If I have multiple dedicated links to different providers, my SIP
proxy can only tell if traffic is coming from "inside" my walled
garden or outside. I am completely vulnerable to one provider claiming
to be another, unless I manually configure source IP addresses for all
my peers.  Practical deployment experience has shown this to be a
gigantic administrative PITA and to frequently be misconfigured to
provide an avenue of attack.

TLS can distinguish between provider A and provider B whether you are
using a dedicated link or the big-I Internet.  Also, I believe that it
is the charter of this group  to describe a mechanism that works over
the Internet.

> 4) What requirement makes TLS more secure than IPSec?

IPsec is typically implemented as virtual private links with private
addressing.  This has exactly the same problems of administrative
drudgery and the danger of misconfiguration as the dedicated link
case.

> 5) Given that providers interconnect today without TLS, what
> requirement is not met by the current interconnection methods that
> TLS will provide?

Providers do not have *widespread* interconnection and do the little
interconnect they do in a non-interoperable, frequently undocumented,
and ad-hoc fashion.  The requirement is widespread interoperable
peering and is the reason this group exists.

> Don't get me wrong.  I think all vendors should support TLS, and I
> think providers and carriers should be able to have it at their
> disposal when doing interconnection, but it is only one of many options.

At issue here in speermint is what mechanism is used between two peers
that are compliant to the speermint peering convention.  If you want
to setup a private club to do private peering, you can do that however
you'd like.

thanks,
-rohan

---

From: Andrew Newton <[email-masked]>
Date: Wed, 5 Jul 2006 21:52:51 -0400

> handle all your user agents registering as described in

I'm aware of the difference.  It still won't work.

> positive financial motivation for attacks on the media alone.

Let me summarize the point you just made: "It isn't secure on the  
PSTN, therefore we needn't do it either."  That's hardly a  
requirement developed against the analysis of a threat.

I believe that most people would want both the signaling and media  
secured (if they knew the difference between the two), but if they  
had to have one they would opt for secure media.

And if you are worried about toll fraud, the "last mile" access link  
should be a significant worry.  There is no point in burdening the  
peering points with over-the-top security when the system can be  
easily gamed at the end points.

> ever be involved in a peered session need to support media encryption.

I guess this a matter of perspectives.  You see secure media as  
"limiting" and specifying codecs as "limiting" (something that most  
voip peering exchanges do), but you don't consider mandating TLS as  
limiting, though A LOT of equipment out there doesn't support it.

> is no consensus around a single secure media transport and keying

But like a lot of things about setting a voip interconnection, such  
as settlements, there are ways to do it.

> of interconnection between the peers.

Where is the citation for this?  Also, I'd like to understand how you  
have done the cost benefit analysis for all cases?  If there are two  
ITSPs with POPs in the same co-lo facility, running an ethernet cable  
is certainly easier and less expensive than upgrading equipment to  
support TLS.

> proxy with a way to verify the identity of the next (SIP) hop.

Aren't you describing a property that is more an artifact of a chain  
of trust and not specifically TLS?

> policy you need for IPsec.

So it is no better?

> is the charter of this group  to describe a mechanism that works over

I disagree.  Not all networks are setup in the manner you just  
described.

> drudgery and the danger of misconfiguration as the dedicated link

Again, you seem to be assuming a network topology where there is a  
single proxy.  Additionally, it isn't that hard to administer.

> peering and is the reason this group exists.

We just added one today.  The process is not as ad-hoc as you might  
think, once the contract is signed.

> to setup a private club to do private peering, you can do that however

So this is "public" peering where we are worried about toll fraud (as  
you described above)?  Exactly what problem do you think you are  
solving?  TLS will not solve the problem that settlement terms must  
be agreed upon and a contract must be signed before an  
interconnection can be made.  If you are talking about public peering  
as we see with SMTP and Internet email, then what problem is TLS  
solving?  And why hasn't TLS solved the problems with see with  
Internet email, where most MTA implementations do support TLS?

In another message in this thread, you mentioned that the use of TLS  
is to be persistent connections with peers.  For public peering,  
especially in the style of Internet email, just how many persistent  
connections are we talking about?

What is your definition of public peering and what properties does it  
have and not have that differentiate it from the private peering you  
feel is out of scope of this working group?

-andy

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 6 Jul 2006 10:05:52 -0700

> I'm aware of the difference.  It still won't work.

That's quite an assertion for me to just believe without any data.
What would you consider to be a valid test to demonstrate that it
works or doesn't work?

> requirement developed against the analysis of a threat.

That's hardly an accurate summary of my previous two sentences.
Reread my last sentence:
>> The attacks on unprotected signaling
>> positive financial motivation for attacks on the media alone
The fact that the PSTN does not secure media is merely a reaction to
that reality.

> had to have one they would opt for secure media.

I disagree, but its really irrelevant since secure media depends on
the existence of secure signaling.

> easily gamed at the end points.

the "last mile" is completely out of scope of speermint.  Each
provider can decide how they are going to offer services and secure
that service.  We can't do anything about that here.

> limiting, though A LOT of equipment out there doesn't support it.

A LOT of equipment out there DOES support TLS (more than half the
implementations at SIPit).  Since this equipment only needs to be
added at the point of interconnection, it does not require the carrier
to re-architect their entire network as changing codecs or adding
secure media might.

> as settlements, there are ways to do it.

Andy, I am disturbed by your comment.  You are a WG chair.  You know
the necessity of consensus.  "A way" to do it is not sufficient. Are
you interested in making a positive contribution to speermint to meet
its chartered goals and milestones within the scope established by the
charter?

> is certainly easier and less expensive than upgrading equipment to

What if the ITSPs are NOT in the same co-lo?  We are looking for a
general solution here.
I believe supporting and running TLS will be cheaper than using IPsec
VPNs (including administrative overhead) and cheaper in most cases
than sending calls over the PSTN.

If you come to a private agreement to exchange traffic over an
ethernet cable, I'm not going to stop you, but you probably don't need
speermint to do that.

> of trust and not specifically TLS?

No.

> > policy you need for IPsec.

No, for TLS the policy is configured with the application where it is
useful, only in one place.  When you use IPsec you need to configure
your authorization policy in your VPN boxes AND a bunch of IP
addresses in several places.

> I disagree.  Not all networks are setup in the manner you just

Please elaborate.

> single proxy.  Additionally, it isn't that hard to administer.

Your problem with TLS performance seems to be with the total number of
connections, although you are objecting with pretty vacuous comments.
I am willing to bet that 1000 TLS connections is easier to configure
that either 1000 proxies or 1000 source address filters plus the
requisite IPsec SAs.

> think, once the contract is signed.

Congratulations.  How long would it take you personally to setup 1000 of them?

> interconnection can be made.

Several others on this thread have mentioned belonging to one or more
clubs, federations, or clearing houses where you sign an agreement
only with the "hubs".

> If you are talking about public peering
> solving?

TLS offers next and previous hop authentication with which you can
make an authorization decision.  This property is useful whether you
are doing settlement-based peering, no-cost peering by prior
arrangement, peering through members of a closed community or club, or
fully open public peering.

> And why hasn't TLS solved the problems with see with

Because there is no strong binding to sender identity and because
hop-by-hop authentication is not used universally, it is very
difficult to have effective whitelists.  The dkim WG is trying to
provide one very useful tool to provide this property among consenting
MTAs.

> connections are we talking about?

I gave an example in an earlier thread of 10,000 carrier I am willling
to peer with and 1000 simultaneous connections.

> feel is out of scope of this working group?

To be clear, I feel the authorization decision about whether to peer
or not is local policy.  This means you can peer using
settlement-based peering, no-cost peering by prior arrangement,
peering through members of a closed community or club, or fully open
public peering.  What is not in scope is peering designed specifically
for a piece of wire or some other kind of private network.  The IETF
designs protocols for the Internet.  These protocols are often useful
on private networks as well, but we design for the Internet first.

thanks,
-rohan

---

From: Andrew Newton <[email-masked]>
Date: Thu, 06 Jul 2006 14:43:07 -0400

> clubs, federations, or clearing houses where you sign an agreement

So a commercial peering exchange meets your definition of public peering?

I'm quite familiar with a number of them.  Of the ones for which I am 
familiar, most define the list of codecs that must be supported, many 
require peering at layer 2, some utilize tunneling for security, and 
none use TLS.  So from my perspective, you are advocating the opposite 
of what is happening in the industry.

-andy

---

From: Tim Dwight <[email-masked]>
Date: Thu, 06 Jul 2006 14:06:49 -0500

Sorry to butt in but can you (or others ) address the issue of federation
members signing agreements "with the hub" (but not with each other) vs the
hub enabling connectivity between "federation members" and leaving it to
them to sign commercial agreements and take whatever related measures are
necessary to exchange L5 traffic?  In your experience how is this usually
handled?   I've heard it described both ways.

Tim

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]] 
> Sent: Thursday, July 06, 2006 1:43 PM
> To: Rohan Mahy
> Cc: [email-masked]
> Subject: Re: TLS for peering (was RE: Comments 
> (RE:[speermint]requirementsdraft submitted))
> 
> Rohan Mahy wrote:
> >> > At issue here in speermint is what mechanism is used between two 
> >> > peers that are compliant to the speermint peering 
> convention.  If 
> >> > you want to setup a private club to do private peering, 
> you can do 
> >> > that however you'd like.
> >>
> I'm quite familiar with a number of them.  Of the ones for 
> which I am familiar, most define the list of codecs that must 
> be supported, many require peering at layer 2, some utilize 
> tunneling for security, and none use TLS.  So from my 
> perspective, you are advocating the opposite of what is 
> happening in the industry.
> 
> -andy
> 
>

---

From: Andrew Newton <[email-masked]>
Date: Thu, 06 Jul 2006 15:25:02 -0400

> handled?   I've heard it described both ways.

All of the commercial entities for which I am familiar require signing 
an agreement with the "hub" and not with the other peers.  In fact, some 
of them attempt to obfuscate the identity of the peers from each other.

The e.164 DUNDI context is an example of the latter (it isn't 
commercial, btw).  You sign an agreement with one of the peers and you 
are in the club.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Jul 2006 15:38:41 -0400

However the vast majority of agreements both in teleco interconnection and
IP data peering are bi-lateral though the may use neutral points to L2
interconnect. 

Hub and spoke agreement as Andy points out are designed to advantage the hub
at the expense of its spokes.

> Sent: Thursday, July 06, 2006 3:25 PM
> To: [email-masked]
> Cc: [email-masked]
> (RE:[speermint]requirementsdraftsubmitted))
> 
> Tim Dwight wrote:

---

From: Tim Dwight <[email-masked]>
Date: Thu, 06 Jul 2006 14:55:04 -0500

Richard said:

> However the vast majority of agreements both in teleco 
> interconnection and IP data peering are bi-lateral though the 
> may use neutral points to L2 interconnect. 

Yes, that's my experience as well.  This notion of federations is relatively
new, and I wondered whether it followed the same model.  Andy's input
suggests that it does not.  

I wonder, though, if you stretch the bounds a bit, whether this would
change.  In its support of VoIP/MMS/etc., peering, the GSM Association is
(from what I understand) similar;  do its members only peer / sign
agreements with, some "hub" entity representing the GSMA, or do they peer /
sign bilateral agreements with, each other?

> Hub and spoke agreement as Andy points out are designed to advantage the
hub at the expense of its spokes.

Whether or not that is the design intent, I agree it would seem to be the
effect.

Tim

> > > members signing agreements "with the hub" (but not with each other) 
> > > vs the hub enabling connectivity between "federation members" and
leaving 
> > > it to them to sign commercial agreements and take whatever related 
> > > measures are necessary to exchange L5 traffic?  In your experience how
is this
> > > usually handled?   I've heard it described both ways.
> > 
> > an agreement with the "hub" and not with the other peers.  In fact, 
> > some of them attempt to obfuscate the identity of the peers from each
other.
> > The e.164 DUNDI context is an example of the latter (it isn't
commercial, btw).
> > You sign an agreement with one of the peers and you 
> > are in the club.
> > 
> > -andy
> > 
> >

---

From: Andrew Newton <[email-masked]>
Date: Thu, 06 Jul 2006 15:57:38 -0400

> IP data peering are bi-lateral though the may use neutral points to L2

I agree that the majority of interconnections are bi-lateral as you have 
described.  However, most of these are also agreements for voip transit 
and not peering.  For hub and spoke model (federations, exchanges, or 
whatever you want to call them), the agreements are generally about 
peering and not transit.  Neither are an absolute because there is some 
mixing and matching going on.

> at the expense of its spokes.

That's an interesting characterization, but please do not attribute it 
to me.

-andy

---

From: Peter Thermos <[email-masked]>
Date: Thu, 06 Jul 2006 16:15:55 -0400

See inline comments, 

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Thursday, July 06, 2006 1:06 PM
To: Andrew Newton
Cc: Khan, Sohel Q [CTO]; [email-masked]; Uzelac, Adam
Subject: Re: TLS for peering (was RE:
Comments(RE:[speermint]requirementsdraft submitted))

> > trusted signaling begins at the Central Office and is exchanged 
> > among switches over trunks with generally much better physical 
> > security than "last-mile" access links.  I can easily tap the phone 
> > of almost anyone in my town from a nearby pole or manhole.  Its been 
> > like this for decades and except for celebrities or individuals 
> > specifically targeted for attack, this lack of media security has 
> > been a non-issue for the most part in the PSTN. If we take this 
> > running network as any indication of priority, signaling protection 
> > is more important than media protection.
> >

It depends the environment you are referring to. 
There are scenarios for which an attacker can eavesdrop in to media 
streams without having the need to manipulate the signaling by affecting 
the underlying layers of the protocol stack (e.g. ARP spoofing). 

> PSTN, therefore we needn't do it either."  That's hardly a requirement 
> developed against the analysis of a threat.

The fundamental difference in realizing attacks in PSTN and IP is
*ACCESSIBILITY*.

How many residential connections do we know that can generate Q.931 messages
to affect the PSTN?
Unless you own a DMS switch and paying 100k/month for PSTN access you won't
be able to do much.

At the same time how feasible is for an attacker to generate traffic against
an SBC or other 
network elements that support a VoIP infrastructure?

>> positive financial motivation for attacks on the media alone

Not sure how we define financial motivation. In some cases financial gain is
not the objective.

>> secured (if they knew the difference between the two), but if they had 
>> to have one they would opt for secure media.

>I disagree, but its really irrelevant since secure media depends on the
existence of secure signaling.

It depends what is the motivation of the attacker. 
But I'm not sure if the group wants to address media protection from a
peering perspective. Signaling protection can be mandated between
intermediate hops but media protection should be left up to the end points.
The peering nodes should hand off the RTP stream as is.

Peter

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Jul 2006 16:19:24 -0400

> Sent: Thursday, July 06, 2006 3:58 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]

I only meant that in your context where the hub attempts to "obfuscate the
identity of the peers from each other."  

IMHO this is one of the silliest ideas federations can engage in. It
provides no real advantage to the peers except that they are kept in the
dark like mushrooms.

The counter argument that peers must be keep from each other so they wont
poach on each others territory is simply not proven by fact. Anyone can find
out who is the underlying carrier for a particular TN. That is why every
country has SIPD databases.

IMHO if VOIP service providers had any smarts they would give their
customers SIP URI's and creatively promotes their use. Nothing will create
customer "stickieness" more that SIP URI adoption.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Jul 2006 16:12:24 -0400

> From: Tim Dwight [mailto:[email-masked]]
> Sent: Thursday, July 06, 2006 3:55 PM
> To: [email-masked]; 'Andrew Newton'
> Cc: [email-masked]
> Subject: RE: TLS for peering (was RE: Comments

Every "federation model" that attempts to interject itself into the private
arrangements between two capitalistic service providers has generally proven
to be a failure or at best a modest little business. The classic federation
hubs simple act as aggregators for smaller players that don't have the clout
to engage in bi-lateral agreements.  

That does not mean you don't need trusted neutral 3rd parties in
interconnection cases. First you need to L2 connect in places like Equinix
or Telehouse, AM-SIX, LINX etc etc. Second you typically choose a settlement
partner to sort through your CDR's,  lastly you need some one to maintain
your trusted routing, number translation data between partners and make sure
its corrected for LNP conditions . I could name some companies here.... :-)

> sign bilateral agreements with, each other?

They first sign bilateral agreements and from what I remember the 600 GSM-A
members have some 28,000 bilateral agreements among themselves though they
do use shared interconnection facilities ..the GRX as points like AM-SIX.

> Whether or not that is the design intent, I agree it would seem to be the

OH it's the specific design intent.... much like mushroom feeding.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Jul 2006 16:25:22 -0400

> From: Peter Thermos [mailto:[email-masked]]
> Sent: Thursday, July 06, 2006 4:16 PM
> To: 'Rohan Mahy'; 'Andrew Newton'
> Cc: 'Khan, Sohel Q [CTO]'; [email-masked]; 'Uzelac, Adam'
> Subject: RE: TLS for peering (was RE:
> Comments(RE:[speermint]requirementsdraftsubmitted))
> 
> 
> > >

IF you never saw the signaling how are you going to find the media much less
attack it, unless you are on the pole somewhere.

> How many residential connections do we know that can generate Q.931

I know a lot that spoof the ANI signaling  quite well.

> Unless you own a DMS switch and paying 100k/month for PSTN access you

I'm not sure of that. I can do a hell of a DoS attack with pair of wire
clippers.

> network elements that support a VoIP infrastructure?

If you don't know where it is how do you attack it. Which is BTW why the GSM
model works well.

---

From: Peter Thermos <[email-masked]>
Date: Fri, 07 Jul 2006 01:25:52 -0400

> > streams without having the need to manipulate the signaling by 
> > affecting the underlying layers of the protocol stack (e.g. 
> ARP spoofing).
> 
> 
> IF you never saw the signaling how are you going to find the 
> media much less attack it, unless you are on the pole somewhere.

Although there is a difference between "seeing the the signaling" the
initial statement was "without having the need to manipulate the signaling"
which is different. 
It is also feasible to identify whether two endpoints communicate using SIP
through various methods (e.g. portscanning, sniffing traffic). In addition
an attacker can collect RTP traffic if they have access to a segment of the
network.

But this is an end point concern. Not a concern of a peering realm where
traffic has propagated from the end points already towards the core of the
network. 
I believe Rohan's point is focusing on the peering relationship rather on
the attacks that may occur on the endpoints as it was mentioned by another
colleague.

> > How many residential connections do we know that can generate Q.931 
> > messages to affect the PSTN?
> 

Although I'm not sure this is the right place to start enumerating proper
PSTN and VoIP security practices but normally, the ANI is set by the
originating central office, based
on the number of the calling line. Unless, you route through a VoIP provider
or through a PBX using primary rate ISDN where the Caller ID is determined
by the originating PBX.

This is not the same as generating traffic from the traditional sense of
network attack to compomise network elements or disrupt services.
 
> I'm not sure of that. I can do a hell of a DoS attack with 

Unless the other end of the clippers is connected to something more capable
than a dialpad, I'm not clear as to what you are alluding to.

> If you don't know where it is how do you attack it. Which is 

I'm not sure what exactly you are refering to but typically SBC's and in
some implementations Proxies are reachable from the Internet and thus
discovery is as simple as a portscan. 
Unless these network elements operate within anIP-VPN where they are not
accessible from the Internet.

---

From: "Rohan Mahy" <[email-masked]>
Date: Fri, 7 Jul 2006 13:41:40 -0700

Hi Andy,

> So a commercial peering exchange meets your definition of public peering?

I did not introduce the term public peering in this thread.  You did.
I documented a strawman model that I feel is technically compatible
with a broad spectrum of peering models from fee-based bilateral
settlement to wide open peering.

> of what is happening in the industry.

If the industry was successfully solving the peering problem, there
would have been no groundswell of demand to form this WG.  Indeed, the
majority of calls between two IP providers still goes over the PSTN.

If there was a predominant approach that was working I suspect someone
would have written a whitepaper or draft documenting the approach.
This has also not happened.

Finally, our role in this WG is necessarily more limited in scope than
any one commercial peering exchange.  This group needs to offer a
technical solution to a broader range of "users" than a single type of
commercial peering exchange.

thanks,
-rohan

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 21 Jul 2006 14:56:07 +0200

Hi Rohan!

Do you have quantitative data about SIP proxies which use TLS? Call 
setup delay due to TLS handshake? call throughput decrease due to TLS 
encoding/decoding compared to UDP/TCP?

regards
klaus

Rohan Mahy wrote:
> Andy,
> 
> What you've described are a bunch of hacks that service providers use
> because they don't peer over the Internet or because they can't rely
> on the other guy to support TLS.  The combination of hacks is much,
> much more expensive in terms of both capital equipment and
> operationally than just using TLS.
> 
> A $2000 rack mount server can encrypt and decrypt a phenominal volume
> of TLS traffic.  Hardware crypto accellerators are available that
> increase this volume and decrease initial TLS handshake latencies by
> another couple of orders of magnitude.
> 
> I'm willing to bet a few beers that the amount of data that is
> encrypted using TLS exceeds the total volume of PSTN signaling traffic
> on a daily basis.
> 
> To those who have a problem with TLS, I ask them to provide some
> quantitative data or real requirements rather than rhetoric and FUD.
> 
> thanks,
> -rohan
> 
> 
> 
> 
> 
> On 6/28/06, Andrew Newton <[email-masked]> wrote:
>>
>> On Jun 28, 2006, at 2:48 PM, Richard Shockey wrote:
>> > how do you propose to establish a trust relationship between SIP
>> > domain
>> > boundaries without TLS?
>>
>> There are other methods: security lower in the stack, private
>> connections, address ACLs...  the things that providers use today.
>>
>> > If you cannot establish a trust relationship between interconnecting
>> > partners then what is the purpose of this whole exercise?
>>
>> To answer the second part of that sentence: I don't know; I've been
>> asking that question for quite some time.
>>
>> -andy
>>