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

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Wed, 28 Jun 2006 11:05:59 -0500

So, what do u recommended ?
Keep TLS optional?
Any other method?

Sohel 

-----Original Message-----
From: "Daryl Malas" <[email-masked]>
To: "Uzelac, Adam" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 6/28/06 10:29 AM
Subject: RE: TLS for peering (was RE: Comments (RE: [speermint]requirementsdraft submitted))

I agree with Adam's assessment.  Requiring TLS is simply not realistic
at this point.  I believe it has the potential of becoming a more common
practice in the future, but not right now.

--Daryl

On Tue, 2006-06-27 at 21:47 -0400, Uzelac, Adam wrote:
> TLS is becoming more and more a subject when the topic of SIP
> interconnections arises for me professionally.  This shows growing
> momentum indeed.  With that said, I can not agree with TLS as a
> steadfast requirement.  Economics and scale are my major concerns.  TLS
> adds cost, server load, and there are fail-over issues to consider as
> well.  For the person that designs an interconnect, I believe weighing
> the cost against the benefit of the different models a useful exercise.
> Mandating TLS, even if all parties involved in a peering arrangement
> feel somehow "safe and secure" due to underlying security mechanisms
> (L2/L3VPNs, etc), seems a little harsh.  
> 
> Adam
> 
> -----Original Message-----
> From: Medhavi Bhatia [mailto:[email-masked]] 
> Sent: Tuesday, June 27, 2006 8:44 PM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: Re: TLS for peering (was RE: Comments (RE: [speermint]
> requirementsdraft submitted))
> 
> I am not a provider yet, but I think we dont need to mess with TLS/TCP.
> As I understand one of the goals is to prevent the calls from failing
> due to "peering only" reasons. This means that things like codecs which
> are not negotiated by the peers need to be mandated at a minimal level.
> TCP/TLS can be negotiated between the peers themselves so it is a
> non-issue. Also as I still understand doing a high volume calls with TLS
> is still expensive. Mandating TLS in cases where the caller or callee
> dont require it doesnt seem to add any value.
> 
> -Medhavi.
> 
> On 6/27/06, Reinaldo Penno <[email-masked]> wrote:
> >
> > TLS for _all_ scenarios? Even in private peerings, physically secure 
> > peerings, etc?
> >
> > Isn't that the same as requiring IPsec for all layer 3 peering? But 
> > since Layer 5 peering might be more distributed, the number of TLS 
> > sessions would be huge.
> >
> > It would be good to hear the provider's opinion on this...
> >
> > Thanks,
> >
> > Reinaldo
> >
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Tuesday, June 27, 2006 2:12 PM
> > > To: 'Jean-Francois Mule'; Reinaldo Penno
> > > Cc: [email-masked]
> > > Subject: RE: Comments (RE: [speermint] requirements draft submitted)
> > >
> > > >
> > > > "3.4.  Security requirements
> > > >
> > > >    All SIP messages MUST be sent over TLS [RFC3546] to provide
> > > >    transport-layer security as defined in RFC 3261,"
> > > >
> > > > Giving the fact that we can have security through physical
> > > segregation,
> > > > intra-federation/provider calls, etc, the "MUST" here seems too 
> > > > generic.
> > >
> > > I tend to differ on this: it is not because you have lower layer 
> > > security (presumably hop by hop security associations) that you 
> > > should relax the end-to-end transport security requirements.
> > > Rohan's well written draft is also in favor of mandatory support of
> > TLS,
> > > and so is the SIP Forum's IP PBX to VSP (here is a working link:
> > >
> > http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_In
> > te
> > > rop-sibley-final.pdf).
> > > May be the requirement should be rewritten to put the MUST on SIP 
> > > entities involved in L5 peering.
> > >
> > > <brian>I'm in favor of requiring TLS.  I'd say MUST in a heartbeat.
> > >
> > > Brian
> >
> > _______________________________________________
> > Speermint mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/speermint
> >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 14:28:56 -0400

TLS is a core part of the SIP specification. Saying its not realistic is
just plain bovine effluent.

You are not going to interconnect at the most basic level unless there is a
level of trust between the domains. So how do you plan on authenticating the
domain?

This was the absolute conclusion of the SIP Forum when we came up with the
SIP Connect specification for PBX to SP interconnection.

SP to SP interconnection is not that much different.

http://data.memberclicks.com/bbattach/130808/sf-draft-twg-IP_PBX_SP_Interop-
sibley-final.pdf 

<sigh> 

> From: Khan, Sohel Q [CTO] [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 12:06 PM
> To: Daryl Malas; Uzelac, Adam
> Cc: [email-masked]
> Subject: RE: TLS for peering (was RE: Comments
> (RE:[speermint]requirementsdraft submitted))
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jun 2006 14:43:08 -0400

While we are at it, why don't we make signed DNS zones and DNSSEC  
TSIG mandatory too.  That way we can have many things in an RFC that  
are flat out ignored.

I agree with Adam and Daryl.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 14:48:25 -0400

Really Andy ...  

how do you propose to establish a trust relationship between SIP domain
boundaries without TLS? 

If you cannot establish a trust relationship between interconnecting
partners then what is the purpose of this whole exercise?

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 2:43 PM
> To: [email-masked]
> Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam';
> [email-masked]
> Subject: Re: TLS for peering (was RE: Comments

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jun 2006 15:05:58 -0400

> how do you propose to establish a trust relationship between SIP  

There are other methods: security lower in the stack, private  
connections, address ACLs...  the things that providers use today.

> 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

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 15:40:56 -0400

Well the one thing we all seem to agree on is that without some trust
relationship between interconnecting partners at their domain boundaries
this whole exercise is a vast waste of time and electrons.

Now then I think Keith has a point.

"If the former, then by all means specify TLS. If the latter, then it should
probably identify that security solutions are required, and then make sure
that sufficient guidance is given on the mechanisms currently available,
including TLS, but probably also addressing IPsec."

Required ..I's say security solutions are mandated as in MUST.

There _are_ certainly more than one mechanism, besides TLS that can be used
to establish security & trust at the boundaries. So ..those techniques MUST
be deliberately specified along with the risks associated with them.

That said there are many of us that are getting very very tired of the
constant whining about this or that aspect of 3261 that for one reason or
another some developer or service provider doesn't like. Some of us just
went through 6 months of this discussion to reach consensus on the
SIPConnect with TLS support since it was the obvious choice.

TLS support IS mandated in 3261 so IMHO get with the program.
	
I've yet to see real concrete data on why its such a problem to implement or
support in high volume SIP transaction systems. Lots of http based Ecommerce
seems to rely on per transaction secure connections so I just don't get what
the problem is here.	

> Sent: Wednesday, June 28, 2006 3:06 PM
> To: [email-masked]

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 28 Jun 2006 16:17:10 -0400

Hello Richard,

I guess you put the answer in the email itself. Adam and others talked
about cost vs. benefit. 

Speaking out of experience, these 'e-commerce' sites you mention have
stacks and stacks of SSL accelerators and/or offpath SSL decryption
engines. It definitely increases the equipment cost, management, real
state and operation of the solution.

Also, if you have looked long enough on RFCs, many, many things that are
mandated never see the light of the day because they lack consensus, are
complex, never factored service provider's opinion, etc, etc. 

Layer 3 peering has been going on for decades without IPsec. 

I believe we are not saying TLS is evil. We are saying 'MUST' is not the
right word. 

Regards,

Reinaldo

> From: Richard Shockey [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 12:41 PM
> To: 'Andrew Newton'
> Cc: [email-masked]; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'
> Subject: RE: TLS for peering (was RE:
> Comments(RE:[speermint]requirementsdraft submitted))
> 
> 
> 
> I've yet to see real concrete data on why its such a problem to
implement
> or
> seems to rely on per transaction secure connections so I just don't
get
> what

---

From: Daryl Malas <[email-masked]>
Date: Wed, 28 Jun 2006 15:24:03 -0600

...I simply said REQUIRING it would be unrealistic...I didn't say
including it as an optional method is unrealistic.  There are multiple
ways to authenticate peers as described in Penno's message flows draft.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 17:35:31 -0400

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 4:17 PM
> To: [email-masked]; Andrew Newton
> Cc: [email-masked]; Khan, Sohel Q [CTO]; Uzelac, Adam

Like duh? So what?

There is real money involved here. Are you saying in inter carrier SIP
communications, transaction security, fraud avoidance and UA identity
management/control across domain boundaries are not worth the security cost?

Voice communications alone is a 300 Billion US business world wide? What's a
few CPU cycles compared to that.

> complex, never factored service provider's opinion, etc, etc.

Been there done that. You could say that for about 60% of the Security Area
RFC's, IPv6, DNSSEC, IDN, PKI, Public ENUM in e164.arpa, etal 

> Layer 3 peering has been going on for decades without IPsec.

Yes but that has been for best efforts IP traffic. 

The entire premise of speermint at its core is the supposition that though
all bits are created equal on the Internet it seems that some SIP bits are
more equal than others.

If you don't believe that, this WG has no reason for existence. 

Since some traffic between SIP interconnection partners ( notice I never say
peering ) may involve PSTN termination charges or use bandwidth in high
volume priority access mode, there must be a reasonable level of trust
between interconnecting partners. There has to be the capability of the
terminating service provider trusting the first who the originating provider
is and second trusting the calling party identity provided to them for
billing purposes if nothing else. Therefore the security methodology
mandated is critical.

> I believe we are not saying TLS is evil. We are saying 'MUST' is not the

Well again 3261 said MUST for a very very good reason. I would still require
MUST support TLS in any SPEERMENT standard or BCP. However I accept that
other trust/security methodologies can work but they had better be well
documented along with the possible security threats associated with each
proposed method.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 28 Jun 2006 18:01:45 -0400

Richard,

If you are so confident that TLS will become the standard for peering,
there is nothing to fear, just say that it should be used in the absence
of other methods. 

If your prediction is correct, providers will actually require and use
it, vendors will implement TLS, and it will become ubiquitous.  

Shoving down the throats of people an operational requirement that will
increase the cost of a deployment is not the way to go. IETF is about
running code and consensus.

More comments inline...

> Sent: Wednesday, June 28, 2006 2:36 PM
> To: Reinaldo Penno; 'Andrew Newton'
[[Reinaldo]] 

I'm sorry, but you first argument was quite simple and my answer was
pointing out that e-commerce sites use special hardware. 

> management/control across domain boundaries are not worth the security

It is not for you and me to decide. We should provide the necessary
alternatives and the market will lean one way or another. 

> 
> Voice communications alone is a 300 Billion US business world wide?
What's
> a
[[Reinaldo]] 

That's a logical fallacy. In the end SIP is just a protocol like HTTP,
DNS and others that run over IP. And what _actually_ needs strict QoS is
_media_ and not SIP signaling. 

Are you going to suggest secure RTP as well between every single call on
the planet? 

> Since some traffic between SIP interconnection partners ( notice I
never
> say
> > > "If the former, then by all means specify TLS. If the latter, then
it
> > > should
> > > probably identify that security solutions are required, and then
make
> > sure
> > > There _are_ certainly more than one mechanism, besides TLS that
can be
> > > used
> > > to establish security & trust at the boundaries. So ..those
techniques
> > > MUST
> > > constant whining about this or that aspect of 3261 that for one
reason
> > or
> > > another some developer or service provider doesn't like. Some of
us
> > just
> > > > > how do you propose to establish a trust relationship between
SIP
> > > > > domain

---

From: "Uzelac, Adam" <[email-masked]>
Date: Wed, 28 Jun 2006 18:00:02 -0400

I agree with Richard's wording below. 

"...any proposed BCP in SPEERMINT for intercarrier interconnection using
SIP MUST support a trust/security model....you MUST support TLS as one
of the supported models."  

I also believe that a trust/security model must be in place, and I have
written as much in this forum.  

Adam

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 5:49 PM
To: 'Daryl Malas'
Cc: 'Khan, Sohel Q [CTO]'; Uzelac, Adam; [email-masked]
Subject: RE: TLS for peering (was RE:

> From: Daryl Malas [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 5:24 PM
> To: [email-masked]
> Cc: 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'; [email-masked]

> ways to authenticate peers as described in Penno's message flows
draft.

Ah .. you are heading into a semantic trap here. 

My position is any proposed BCP in SPEERMINT for intercarrier
interconnection ( did I say peering here :-) using SIP MUST support a
trust/security model.  I'm not saying you should be REQUIRED to use TLS
at all times but only that you MUST support TLS as one of the supported
models.

It is my opinion based on many years of personal experience in the IETF
that you that you will not get anything through the IESG to an RFC
unless something like the above position is incorporated into the
drafts.

> > TLS is a core part of the SIP specification. Saying its not 
> > realistic is just plain bovine effluent.
> >
> > You are not going to interconnect at the most basic level unless 
> > there
> is a
> > level of trust between the domains. So how do you plan on 
> > authenticating
> the
> > domain?
> >
> > This was the absolute conclusion of the SIP Forum when we came up 
> > with
> the
> > > I agree with Adam's assessment.  Requiring TLS is simply not 
> > > realistic at this point.  I believe it has the potential of 
> > > becoming a more
> common
> > > > interconnections arises for me professionally.  This shows 
> > > > growing momentum indeed.  With that said, I can not agree with 
> > > > TLS as a steadfast requirement.  Economics and scale are my
major concerns.
> TLS
> > > > adds cost, server load, and there are fail-over issues to 
> > > > consider
> as
> > > > Mandating TLS, even if all parties involved in a peering 
> > > > arrangement feel somehow "safe and secure" due to underlying 
> > > > security mechanisms (L2/L3VPNs, etc), seems a little harsh.
> > > >
> > > > Adam
> > > >
> > > > due to "peering only" reasons. This means that things like 
> > > > codecs
> which
> > > > TCP/TLS can be negotiated between the peers themselves so it is 
> > > > a non-issue. Also as I still understand doing a high volume 
> > > > calls with
> TLS
> > > > > Isn't that the same as requiring IPsec for all layer 3
peering?
> But
> > > > > since Layer 5 peering might be more distributed, the number of

> > > > > TLS sessions would be huge.
> > > > >
> > > > > > > intra-federation/provider calls, etc, the "MUST" here 
> > > > > > > seems
> too
> > > > > > > generic.
> > > > > >
> > > > > > I tend to differ on this: it is not because you have lower 
> > > > > > layer security (presumably hop by hop security associations)

> > > > > > that you should relax the end-to-end transport security
requirements.
> > > > > > Rohan's well written draft is also in favor of mandatory 
> > > > > > support
> of
> > > > > TLS,
> > > > > > May be the requirement should be rewritten to put the MUST 
> > > > > > on
> SIP

---

From: Andrew Newton <[email-masked]>
Date: Wed, 28 Jun 2006 18:01:42 -0400

On Jun 28, 2006, at 5:35 PM, Richard Shockey wrote:

> Like duh? So what?
>
> There is real money involved here.

There's real money involved in many aspects of Internet operations.   
Life would certainly be better if the gTLD providers did the right  
thing by offering secure protocols too, but you don't see them  
stampeding to do so.

The other thing I don't like about the magical TLS pixie dust is that  
it does not take into account the fact that there is no root trust  
anchor.  Some CAs will sell anybody a cert for $25, some give them  
away for FREE.  What's the point of all that additional TLS  
infrastructure if it can be easily circumvented by a trust path that  
leads back to a money order purchased at a gas station.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 17:49:01 -0400

My position is any proposed BCP in SPEERMINT for intercarrier
interconnection ( did I say peering here :-) using SIP MUST support a
trust/security model.  I'm not saying you should be REQUIRED to use TLS at
all times but only that you MUST support TLS as one of the supported models.

It is my opinion based on many years of personal experience in the IETF that
you that you will not get anything through the IESG to an RFC unless
something like the above position is incorporated into the drafts.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 28 Jun 2006 18:20:40 -0400

The following security 'models' come to mind:

1 - TLS
2 - IPSec
3 - Physical security
4 - Access lists
5 - Registrations 
6 - others? 

TLS just like the other methods has pros and cons that should be
weighted by the persons that will actually use it.

I hope we can agree with that.

Regards,

Reinaldo

> Sent: Wednesday, June 28, 2006 2:49 PM
> To: 'Daryl Malas'
> Comments(RE:[speermint]requirementsdraftsubmitted))
> 
> 
> 
> that
realistic
> is
there
with
> realistic
> > > > at this point.  I believe it has the potential of becoming a
more
> > > > > interconnections arises for me professionally.  This shows
growing
> > > > > steadfast requirement.  Economics and scale are my major
concerns.
consider
> arrangement
codecs
> > which
> > > > > are not negotiated by the peers need to be mandated at a
minimal
> > level.
> > > > > non-issue. Also as I still understand doing a high volume
calls
> > > > > > TLS for _all_ scenarios? Even in private peerings,
physically
> > secure
peering?
seems
> layer
> > > > > > > security (presumably hop by hop security associations)
that
> you
on

---

From: Daryl Malas <[email-masked]>
Date: Wed, 28 Jun 2006 17:35:36 -0600

I 100% agree with your statement below.  Thanks for clarifying...I
apparently stepped in the semantic trap...it's sticky I might add. ;-)

Thanks...--Daryl

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 21:29:14 -0400

> From: Uzelac, Adam [mailto:[email-masked]]
> Sent: Wednesday, June 28, 2006 6:00 PM
> To: [email-masked]; Daryl Malas
> Cc: Khan, Sohel Q [CTO]; [email-masked]

Thank you. This is my point exactly.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 21:37:20 -0400

> Sent: Wednesday, June 28, 2006 6:02 PM

My point is that in SIP communications TLS IS a standard directly required
in 3261. That cannot be avoided..if you say you support SIP by definition
you MUST support TLS.

> it, vendors will implement TLS, and it will become ubiquitous.

I did not say there were not other trust models only that you cannot side
step the requirement to support TLS.

> running code and consensus.

So you choose to pick and choose what points in the SIP standard you want?
How do you propose to implement interoperability? You are the violation of
consensus. Follow the standard as agreed to by the SIP WG and approved by
the IETF otherwise you are in noncompliance.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 21:51:40 -0400

An excellent point Andy ..now we are making progress here.

But is this a discussion over what is the root CA authority between service
providers should it be?

"To be a CA or not to be a CA that is the question"  Bill Shakespeare 

That is a reasonable point of discussion on how or to whom anchors the trust
between the domain boundaries. Which is my ultimate point.

All other discussions are moot points unless the trust model is clear.

My personal view is that so long as two consenting service providers can
agree on the CA the boundary trust relationship can be established.

Why should SIP interconnection be any different from traditional network
interconnection which is a matrix of bi-lateral agreements?  Look at the
GSM? 600 members and 32000 bilateral agreements covering each and every
detail including neutral settlement clearing houses.

My point is that TLS MUST be supported and it is up to service providers to
decide who they mutually agree to be their trusted CA.

 

  _____  

From: Andrew Newton [mailto:[email-masked]] 
Sent: Wednesday, June 28, 2006 6:02 PM
To: [email-masked]
Cc: 'Reinaldo Penno'; [email-masked]; 'Khan, Sohel Q [CTO]'; 'Uzelac,
Adam'
Subject: Re: TLS for peering (was RE:
Comments(RE:[speermint]requirementsdraft submitted))

Like duh? So what?

There's real money involved in many aspects of Internet operations. Life
would certainly be better if the gTLD providers did the right thing by
offering secure protocols too, but you don't see them stampeding to do so.

The other thing I don't like about the magical TLS pixie dust is that it
does not take into account the fact that there is no root trust anchor. Some
CAs will sell anybody a cert for $25, some give them away for FREE. What's
the point of all that additional TLS infrastructure if it can be easily
circumvented by a trust path that leads back to a money order purchased at a
gas station.

-andy

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Jun 2006 22:06:11 -0400

> Sent: Wednesday, June 28, 2006 6:21 PM

But it cannot be deprecated. It MUST be supported. Its part of the core SIP
standard you cannot side step this issue. 

> I hope we can agree with that.

This is exactly where we begin to make progress. Define the reasonable
security/trust models including TLS that we can find consensus on, the
smaller the list the better.

This is really the core problem in spearmint. What is the ultimate
trust/security model that service providers can rely on to accept traffic
across domain boundaries. 

Are you really BT or Sprint or FT or Cablevision etc. Or are you really IBM
or Ford or Bombardier or Sony for that matter. Can I bill you for your
traffic? How do I know you are who you say you are.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 29 Jun 2006 09:53:08 +0200

> written as much in this forum.

Count me in too.

>the IETF otherwise you are in noncompliance.
 
and

>My point is that TLS MUST be supported and it is up to service providers to decide who they mutually agree to be >their trusted CA.
 
-sta

---

From: Andrew Newton <[email-masked]>
Date: Thu, 29 Jun 2006 11:01:18 -0400

> decide who they mutually agree to be their trusted CA.

So a mechanism MUST be supported even though the bits to get it to work 
will not be specified?  Haven't you ever wondered why SMTPS has never 
succeeded in solving the spam problem?

What's wrong with just saying that service providers MUST mutually agree 
upon security and authorization mechanisms?

-andy

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 12:26:08 -0400

Richard,

Until very recently there was consensus around TLS: nobody implemented
it.

- "But hey, isn't it a MUST on the RFC?" one would ask. Yes, but there
was no interoperability problem at all. People just did not use it.

It took years for TLS to gain momentum and I can guarantee that it is
_not_ because the RFC 3261says it MUST, but because users saw security
advantages on it in certain deployments.

All I'm saying is that we must provide alternatives so that small ISPs
that do not have tons of money as you it, ISPs that do not care about
TLS and others can interoperate. 

Regards,

Reinaldo

> Sent: Wednesday, June 28, 2006 6:37 PM

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 12:38:15 -0400

No, it will not be deprecated. TLS must be supported as one of the
options, but mandating its use is another issue.

There are many ways to establish trust.

> Sent: Wednesday, June 28, 2006 7:06 PM
> To: Reinaldo Penno; 'Daryl Malas'
> But it cannot be deprecated. It MUST be supported. Its part of the
core
> Are you really BT or Sprint or FT or Cablevision etc. Or are you
really
> IBM

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Jun 2006 17:05:23 -0700

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

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Jun 2006 17:20:43 -0700

> running code and consensus.

Can you prove to this group that TLS would cost more than using IPsec?
 than using a private walled garden network?  Can you describe a model
where this begins to look expensive compared to all the other various
boxes SPs are installing.  Where are your requirements?

> Are you going to suggest secure RTP as well between every single call on

I certainly won't.  The attack isn't as relevant as the attack on the
signaling channel.

thanks,
-rohan

---

From: Benjamin Black <[email-masked]>
Date: Thu, 29 Jun 2006 17:29:32 -0700

rohan,

i don't think it is sufficient to simply make tls a requirement.   
what is the problem you are trying to solve using tls?  given that,  
what are the specific features/options of tls that minimally solve  
that problem?  for example, eNULL encryption may not be appropriate,  
but is available if the entirety of the specification is "must use tls".

all this talk of what the performance impact of tls may or may not be  
presumes specifics of requirements, design, and implementation that i  
have not seen clearly articulated in this thread.

thanks,
ben

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 20:40:36 -0400

Rohan,

I'm okay with TLS as long as there are alternatives, but you email seems
contradictory. You complain of rhetoric, but

(1) " much, much more expensive in terms of both capital equipment and
operationally than just using TLS ", 

(2) " A $2000 rack mount server can encrypt and decrypt a phenominal
volume
of TLS traffic", 

(3) " by another couple of orders of magnitude", 

Can you provide quantitative data instead of, you know...rhetoric?

I'll be very interested on reading some serious data on (1) above and
the number of TLS _connections per second_ on a $2000 rack server.

As for the beers, are you saying the number of TLS _connections per
second_ on the Internet today is greater than the number of calls in the
PSTN? Worldwide? That would be an interesting bet. Have any numbers on
that?

Thanks,

Reinaldo

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Thursday, June 29, 2006 5:05 PM
> To: Andrew Newton
> Cc: Khan, Sohel Q [CTO]; [email-masked]; Uzelac, Adam

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 20:48:16 -0400

Rohan,

There is no need to resort to these kinds of personal statements. The
burden of the proof does not need to be on me. 

As with any scientific discussion, I'm validating the other side. What
I'm hearing is that people say TLS is faster, securer, cheaper...than
_any_ alternative.

What is wrong in trying to validate that? Or asking where is the data to
prove that? 

Thanks,

Reinaldo 

> Sent: Thursday, June 29, 2006 5:21 PM
> To: Reinaldo Penno
> Cc: [email-masked]; Andrew Newton; Khan, Sohel Q [CTO];
> [email-masked]; Uzelac, Adam

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Jun 2006 21:02:18 -0400

> From: Benjamin Black [mailto:[email-masked]]
> Sent: Thursday, June 29, 2006 8:30 PM
> To: Rohan Mahy
> what is the problem you are trying to solve using tls? 

Face the music  you will support TLS whether you like it or not. This is SIP
101. It will not be a requirement that you use it but I can tell you I'd
never give my voice traffic to any service provider that did not accept a
TLS connection at their point of interconnection.

Hello here... SIP signaling security, preventing MIM attacks, trust
relationships between domain bountries do you want a longer list of why you
need SIP security?

This whole thread is highlighting the central problem this list seems to
have has which is unwillingness to confront the central issues of security
and trust relationships between service providers and what protocols are
REQUIRED to create those trust relationships.

OK if you are a GSM network you figured this out already ..create a totally
private internet with completely private points of interconnection and
within a the great wall of GSM you have security.

It works ..is that the model you want?  

Brother Rohan is spot on here. CPU cycles are cheep considering what the
requirements for security here are.

I just don't get it why does everyone so dislikes TLS..its simple proven to
scale and it works.

Frankly I think the chairs need to step in here and drive a little consensus
that without a robust security/trust model defined ASAP for speermint all
other discussions are futile and a waste of time.

 given that,

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 21:14:13 -0400

IMO TLS must be supported but we should spell out the alternatives.

> Sent: Thursday, June 29, 2006 6:02 PM
> To: 'Benjamin Black'; 'Rohan Mahy'
> Cc: 'Khan, Sohel Q [CTO]'; [email-masked]; 'Uzelac, Adam'
> Face the music  you will support TLS whether you like it or not. This
is
> relationships between domain bountries do you want a longer list of
why
> I just don't get it why does everyone so dislikes TLS..its simple
proven
> to
SIP

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Jun 2006 21:15:16 -0400

Right on Brother Rohan .. protection of the 5060 signaling channel is much
more important than the RTP media stream. 

> Sent: Thursday, June 29, 2006 8:21 PM
> To: Reinaldo Penno

Well here is my requirement you cannot have interconnection between service
providers without securing and authenticating the source of the SIP 5060
signaling data.

We know TLS works. That is why it is in the SIP standard. That is why it
MUST be supported.

The burden of proof is now on you and others to describe what other
security/trust models you want supported and the risks associated with them.
And those methods should either match or exceed the capabilities of TLS.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 21:39:26 -0400

I did not know there was some kind strange brotherhood going on here
but...

> Sent: Thursday, June 29, 2006 6:15 PM
> To: 'Rohan Mahy'; Reinaldo Penno
> Cc: 'Andrew Newton'; 'Khan, Sohel Q [CTO]'; [email-masked];
'Uzelac,
[[Reinaldo]] 

huh? There are plenty of VoIP peering today without TLS. They seem to be
working. Are they not?

The concept of securing and trust is the one that matters between
service providers. If they think physical security is okay, then that is
good enough for them. 

[[Reinaldo]] 

Not really. They only need to be alternatives for people that when peer
do not need TLS. There are many small enterprises; small carriers that
do not want, cannot afford Tor do not have the expertise to deal with
LS. This is true especially outside the US. There is life outside the
rich and powerful providers.

> >
> > > Are you going to suggest secure RTP as well between every single
call

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 29 Jun 2006 21:52:35 -0400

> Sent: Thursday, June 29, 2006 9:39 PM
> To: [email-masked]; Rohan Mahy
> Cc: Andrew Newton; Khan, Sohel Q [CTO]; [email-masked]; Uzelac, Adam

You never heard of the SIP Mafia?

---

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 29 Jun 2006 21:56:12 -0400

Sorry Don Shockley....I will have you TLS ready by next week...I promise
(:-)

> Sent: Thursday, June 29, 2006 6:53 PM
> To: Reinaldo Penno; 'Rohan Mahy'
'Uzelac,

---

From: Benjamin Black <[email-masked]>
Date: Thu, 29 Jun 2006 19:10:16 -0700

richard,

i agree 100%.  this is really important.  so important, in fact, that  
the requirements should be clearly stated so the problem is actually  
solved.  tls _can_ be an extremely powerful tool, but simply  
requiring its use is insufficient to achieve the goals of this  
working group, imo.

thanks,
ben

On Jun 29, 2006, at 6:02 PM, Richard Shockey wrote:

> why you
> proven to

---

From: Paul Erkkila <[email-masked]>
Date: Fri, 30 Jun 2006 13:57:24 +0000

From a customer point of view, I'm sure they would rather we kept our 
signaling protected, AND kept their calls private. Fraud charge handling 
and billing problems (sadly) are almost expected by customers these 
days, this is aggravation for sure; but not a customer loss for the most 
part. Having their intimate chats with kids/mom/dog (or other bits) 
recorded and punted around the internet is a lost customer, loss of face 
for the provider, and probably ends up with lawyers involved.

	So protecting signaling certainly helps protect the bearer(s), but I 
don't think I would put it MUCH higher then the data, maybe just a wee 
bit higher ;). Most customers pay for the service after all, not the 
implementation.

	As far as my input into the requirement for TLS as a method of 
establishing trust between peers, I agree with it as long as there are 
other allowable methods.

	-pee

---

From: Paul Erkkila <[email-masked]>
Date: Fri, 30 Jun 2006 14:04:06 +0000

> quantitative data or real requirements rather than rhetoric and FUD.

	Here's a single point of data for you.

	Number of devices in our voip network that handle TLS connections with 
their current hardware and software configurations:

	 => 0.

	I'm not defending anyone so don't bother with the "pick a different 
vendor(s)" replies =). There has been limited demand for TCP/TLS to the 
equipment vendors, so consequently there has been limited development 
into supporting it (everyone is *working on it*). It could be a 
reasonable BCP from this group helps accelerate that process.

	-pee

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 30 Jun 2006 10:14:34 -0400

> encrypted using TLS exceeds the total volume of PSTN signaling traffic

A pretty good bet if I do say so. Its tough to break out per transactions
but the underlying supposition is that there is a heck of a lot of TLS going
on.

Well the numbers are huge no matter how you count them. Basic stats are that
on the basis of 162M US access lines in 2004 generated 422.4 Billion access
minutes of which 81 B of those were toll calls. Due to LNP and other network
issues everyone of those requires a form of SS7 dip. ( FCC )

Ecommerce stats are now 

Total Worldwide eCommerce Revenues, 2004 (B2B & B2C)
Region 	Total
North America 	$3.5 trillion
Asia Pacific 	$1.6 trillion
Western Europe 	$1.5 trillion
Latin America 	$81.8 billion
Rest of World 	$68.6 billion

Source: Forrester Research

Payment Types In The US, 2005 - 2010

Volume ($ trillion) 	2005 	2010
Paper 	$3.4 (50%) 	$3.6 (36%)
Cards 	$2.7 (39%) 	$4.3 (49%)
Electronic 	$0.7 (11%) 	$1.3 (15%)
Total 	$6.8 (100%) 	$8.7 (100%)

Source: The Nilson Report

---

From: Andrew Newton <[email-masked]>
Date: Fri, 30 Jun 2006 10:30:42 -0400

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.

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?
2) Why do you believe TLS offers better authentication than any other  
method, especially given that there is no global trust anchor?
3) What requirement makes TLS more secure than a dedicated link?
4) What requirement makes TLS more secure than IPSec?
5) Given that providers interconnect today without TLS, what  
requirement is not met by the current interconnection methods that  
TLS will provide?

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.

-andy

---

From: David Meyer <[email-masked]>
Date: Fri, 30 Jun 2006 07:47:42 -0700

> other discussions are futile and a waste of time.

	Thanks for the prompting Richard. FYI, one of the things
	we've been discussing to address this is a "speermint
	security considerations" document, on the theory that
	rather that thrashing around as we've been doing, we'll
	have a concrete piece of work that we can discuss. 

	--dmm

---

From: "Rohan Mahy" <[email-masked]>
Date: Fri, 30 Jun 2006 08:40:32 -0700

Andy,

I am just leaving for a short vacation, but I will commit to answering
your questions before the meeting in Montreal.  I think these are good
questions and I want to take the time to answer them properly.

So that we can make apples to apples comparisons, it would be useful
to start with an order of magnitude number of calls per day.  This
does not need to be Sunrocket's (or any other carrier's) actual
current or expected peering traffic, but it should be plausible.

thanks,
-rohan

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 08:42:22 -0700

I have been involved with several TLS implementations for SIP  
including writing most the code for one and also some deployments.  
Sorry, I am not fully up to speed on this discussion of if I say  
something that has already been well covered, my apologies - there  
have been a few transaction on the topic :-)  I'm don't know what  
this WG should choose but let me provide some information that might  
help....

Do vendors implement it?
I don't have the exact numbers but I think at the last SIPit there  
was something like over 50 vendors that had TLS - we can get more  
details if needed. Every major vendor I am aware of has it on a proxy  
that would be used in this type of situations. It's actually pretty  
easy to support - don't confuse it with sips which is somewhat harder  
to support. Most proxies use some SSL library such as openssl or  
BSAFE. Given a library like that, it tends to add less than a 1000  
lines of code to the proxy.

Do people use it?
Microsoft has a popular presence server known as LCS. LCS  uses TLS  
for it's peering.  If you do a bit of googling around you will find  
there are a lot of things that choose to interoperate with LCS.  
Enterprise that deploys LCS can peer with AOL, Yahoo, and MSN. Again  
over TLS. It's a pretty good example of some running code. Don't  
underestimate the size of this deployment and keep in mind it is  
already peering with three of the very largest IM providers. I forget  
when this all first deployed but it's been years.

Is it Expensive?
Your average proxy running on some intel or sun box will do something  
like a few thousand sip transactions per second then it hits the CPU  
limit. Every proxy I have seen, the performance bottleneck has been  
CPU. Now if you compute the bandwidth for this amount of SIP traffic,  
then look at how much CPU is required to AES encrypt that much  
traffic, you will realize - the encryption time is going to make  
pretty much no difference to the number of transaction per second  
this box can do. If you talk to SIP implementers, the hard part of  
TLS is keeping open tens of thousands of connections form a proxy to  
a UA. This is not what you are talking about here - Here we are  
talking about keeping open 100s to 1000s of connections from one  
proxy to another. These are long lived connections - they can be set  
up quickly and stay up for very long time. A small amount of data  
flows over them (by small, I mean less than few Mbps). I expect the  
expense to be very low in terms of implementation effort, hardware  
required to run this, and operation effort to run them. Don't confuse  
the issues of proxy doing TLS to many UA connected to it with the  
proxy doing TLS to the other proxies it connects to.

What does it provide?
It provides some integrity and confidentiality protection, yawn,  
yawn, yawn - not clear that this helps your threat models much but is  
definitely of some use. But let's get on to the next thing. TLS lets  
you authenticate that you connected to the proxy you meant to connect  
to. I expect this might be very important for the threat models you  
are interested in. The reason in MUST implement in proxies is that  
this is the *only* way SIP provides for one proxy to know that it  
connected to the correct next proxy. If you need to know who you are  
connecting to, you probably want to think seriously about TLS.

It also provides a way of  using certificates to delegate certain  
authorization decisions. Let me give an example. Lets say a bunch of  
organization A, B, C agree to peer and form so peering consortium,  
call it PeersAreUs. Everyone that joins PeersAreUs has to sing some  
sort of contract about behavior. They do enum look ups to some enum  
root at PeersAreUs. Now  when a new organization D joins PeersAreUs,  
how do A,B,C find out they are authorized. One possibility is having  
PeersAreUs issue some sort of cert to D. Now A looks up a number in  
enum, gets routed to D, and D presents a certificate that lets A know  
that D is a valid member of PeersAreUs. This sounds sort of  
interesting to me from a operation expense point of view. Note that  
A, B, and C did not need to do anything when D joined and PeersAreUs  
did not have to run some large proxy that could deal with all the  
traffic of all it's members. I imagine you can find other ways to  
achieve this too, but hey, this one is already MUST implement in 3261  
and widely implemented in deployed devices.

Is IPsec an alternative?
Possibly for some threat models and not for others. The inter-sting  
thing about IPsec is how will you key it? Given the scope of work in  
this WG, I would expect this group to describe that if IPsec is  
chosen. Setting up manual key associations between from one proxy to  
thousands of others sounds like an very expensive solution from an  
operations point of view so I would guess that something other than  
manual configuration would be chosen. Once you go down that path you  
run into questions of how the proxy knows it connected to the correct  
domain. I'm willing to believe that there might be solutions to this  
but not clear to me what they are or that anyone has implemented them.

Are there other alternatives?
The answer to this is always yes but I encourage the group to figure  
out what the threats, list the alternative solutions, and focus on  
saying which concrete proposal looks best instead of saying I don't  
like proposal X. This is going to be an exercise in picking the thing  
you hate least not having some silver bullet that is perfect in every  
way.

Should this group mandate TLS use?
Heck if I know :-) I think you are a ways from saying all the things  
you need to accomplish in securing a peer so it makes it a little  
hard to say if any given solution would meet all the needs.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 30 Jun 2006 12:47:49 -0400

On Jun 30, 2006, at 12:00 PM, Cullen Jennings wrote:
> My real concern is IETF is acting as if we will move to TCP,  
> deployments are acting as if this is not possible. This mismatch  
> seems like a growing problem for us and I am concerned about it. I  
> think that this speermint WG has operators that are connected with  
> the real issues so this seems as good a place as any to discuss this.

For us the UDP vs. TCP issue is much more important on the registrar  
part of the network thanks to the ever cursed NAT.  But even with  
peering, UDP is better performance wise.  Persistent TCP connections  
also tend to cause problems with load balancing and fault tolerance  
schemes, which is a big issue.

I do agree that TCP is important and strategies will need to be  
developed to better handle it.

-andy

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Jun 2006 09:00:17 -0700

> $2000 rack mount server cannot handle the load.

Andy, this gets to another topic which is possible even more or  
important than this TLS or not questions. the questions is TCP or UDP  
for proxy to proxy.

I have a growing concern of a theory vs. practice mismatch here. I  
don't know if you saw the recent thread on MMUSIC but Magnus  
constructed a very plausible SDP message that could occur in real  
world that is over 10k long (that would be 10k bytes in practice but  
10,000 octets in theory :-).  Many of the deployments I am aware of  
use UDP and say there are some serious problems with TCP. I believe  
this but as much as possible would like to understand what they are.  
On the other hand, the IETF is more and more defining stuff in SIP  
that is pushing the size of SIP packets to the point where it is  
questionable if they will work on UDP given the fragmentation issues.  
Some of the concerns I have see about TCP have been based on the  
ideas each transaction would form a new TCP connection - this clearly  
won't work so let's base the conversation on long lived TCP  
connections between peering proxies.

Cullen (BTW, all these emails sent with my individual contributor hat  
on)

PS - note TLS can be run on TCP or over UDP with DTLS so the TLS or  
not question is separate from the UDP/TCP question

PPS - just to head off the inevitable rat hole ahead ... Yes, I know  
about SCTP. On this thread I'm interested in what are the problems  
with deploying TCP and not really interested in all the great things  
SCTP can provide - we can get to that later.

---

From: Daryl Malas <[email-masked]>
Date: Fri, 30 Jun 2006 11:36:09 -0600

Okay, we have gone round and round on this topic....I have become lost
in the discussion and want to make sure we are still arguing the same
question.  Is the question we are arguing, still:

--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?

Why does it have to be the only option?

I still assert, it should be included in the requirements document as a
one of several methods (one of the methods is required -- but not all)
for providing security in a peering topology.  This being said...it
would be to the detriment of a provider not willing to peer with another
provider if that provider only supports TLS (yet they would be compliant
with the requirements).  I can say we (Level 3) would seriously consider
implementing it (if we hadn't already) and supporting it based on the
opportunity.  But, before an opportunity presents itself, TCP/TLS
creates a lot of (arguably) unnecessary overhead.

--Daryl