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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 4 Jul 2006 09:46:29 -0400

TLS must be supported.  No question.

The question is when and where it is used.  There are times when IPSEC
might provide a better solution.  I don't want to argue the details as
that is a network design issue that can be very situation specific.
This is an academic argument in many ways.

Mike

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]] 
> Sent: Thursday, June 29, 2006 9:14 PM
> To: [email-masked]; Benjamin Black; Rohan Mahy
> Cc: Khan, Sohel Q [CTO]; [email-masked]; Uzelac, Adam
> Subject: RE: TLS for peering (was 
> RE:Comments(RE:[speermint]requirementsdraftsubmitted))
> 
> IMO TLS must be supported but we should spell out the alternatives.
> 
> > -----Original Message-----
> > From: Richard Shockey [mailto:[email-masked]]
> > Sent: Thursday, June 29, 2006 6:02 PM
> > To: 'Benjamin Black'; 'Rohan Mahy'
> > Cc: 'Khan, Sohel Q [CTO]'; [email-masked]; 'Uzelac, Adam'
> > Subject: RE: TLS for peering (was RE:
> > Comments(RE:[speermint]requirementsdraftsubmitted))
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Benjamin Black [mailto:[email-masked]]
> > > Sent: Thursday, June 29, 2006 8:30 PM
> > > To: Rohan Mahy
> > > Cc: Khan, Sohel Q [CTO]; [email-masked]; Uzelac, Adam
> > > Subject: Re: TLS for peering (was RE:
> > > Comments(RE:[speermint]requirementsdraft submitted))
> > >
> > > 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?
> > 
> > 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,
> > > 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
> > >
> > > On Jun 29, 2006, at 5:05 PM, 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
> > 
> > 
> > _______________________________________________
> > 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: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Jul 2006 10:38:07 -0400

> > Unless you own a DMS switch and paying 100k/month for PSTN 
> access you 
> > won't be able to do much.
> 
> 
> I'm not sure of that. I can do a hell of a DoS attack with 
> pair of wire
> clippers.

Yeah, but you know kids these days just don't like to play outside like
they used to.  Why not sit at home playing Xbox 360 on one screen and
DoSing on the other, all while eating a nice snack in the comfort of
central air conditioning.  ;-)

Jason

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Sat, 8 Jul 2006 11:10:58 -0500

This is not a joke but a story: once upon a time there were two  VoIP
networks X and Y.
The X and Y implemented all kind of security mechanism at the end
points/access interfaces so that "DoS Kids" cannot attack those
networks. VoIP X and Y peer with each other. One sunny day, one of the
SIP proxies in VoIP network X "gone crazy" and started to send thousands
of SIP INVITE to the peering proxy of network Y.  The network Y got
crippled not by the new "DoS Kids" in town, but his friendly and trusted
neighbor's grown up proxy!

Sohel Khan
 
-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Friday, July 07, 2006 9:38 AM
To: [email-masked]; [email-masked]; Rohan Mahy;
Andrew Newton

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

Jason

---

From: "Khan, Sohel Q [CTO]" <[email-masked]>
Date: Sat, 8 Jul 2006 11:30:31 -0500

-----Original Message-----
From: McCandless, Kevin [mailto:[email-masked]] 
Sent: Thursday, July 06, 2006 4:31 PM
To: [email-masked]; [email-masked]; Andrew Newton
Cc: [email-masked]
Subject: RE: TLS for peering (was

<K>  GSM association is a good example.  How federation evolve from here
remains to be seen.  But I do have to agree with Andy that bilateral
agreements will define a new member into a federation and that will
include financial and technical expectations.  

We would want to keep financial agreement issues outside SPEERMINT.
Operation Function (OF) may perform parameter and data exchange of the
billing, charging, accounting.