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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Jun 2006 20:08:51 +0100

Given that writing a requirement in RFC 3261 (standards track) that all SIP implementations must support TLS has not resulted in its universal deployment and use, why should writing it into a SPEERMINT BCP result in any wider deployment and use (BCP is what the milestone in the charter currently indicates)? 

[And if there is a rational answer to the above question - it would be worth identifying if this means we should be taking that back into SIP rather than documenting it in SPEERMINT]

I guess that this raises a more general issue. Is this BCP (and other SPEERMINT work) meant to be focussed on trying to change the world, or should it be focussed on solving immediate problems with getting SIP networks to connect. 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.
	
regards

Keith

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: 28 June 2006 19:43
> To: [email-masked]
> Cc: [email-masked]; 'Khan, Sohel Q [CTO]'; 'Uzelac, Adam'
> Subject: Re: TLS for peering (was RE: Comments
> (RE:[speermint]requirementsdraft submitted))
> 
> 
> 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
> 
> On Jun 28, 2006, at 2:28 PM, Richard Shockey wrote:
> 
> >
> >
> > 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>
> >
> >> -----Original Message-----
> >> 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))
> >>
> >> 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
> >
> >
> > _______________________________________________
> > 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: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Jun 2006 21:07:55 +0100

I was using REQUIRED as in the RFC 2119 sense - I just forgot to capitalise it.

regards

Keith

> From: Richard Shockey [mailto:[email-masked]]
> Sent: 28 June 2006 20:41
> To: 'Andrew Newton'
> 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]
> > Cc: 'Khan, Sohel Q [CTO]'; 'Daryl Malas'; 'Uzelac, Adam';
> > [email-masked]
> > 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
> 
>