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

From: "McCandless, Kevin" <[email-masked]>
Date: Thu, 6 Jul 2006 16:31:25 -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?
> 
> <K> What happens is a new member signs an agreement with a hub.  The
new
> member now submits IR21 orders to gain signaling access to other
members
> within the hub.  The member must also complete GSM association forms
> such as AA14 and these are sent to the member network that the new
> member wants to signal with.  Such things as financial clearing and
> rates are agreed upon before any active signaling takes place.

Thanks Kevin, this is helpful.

So, in addition to providing L2/L3 connectivity, the GSMA or some agent
acting on its behalf facilitates (by providing the blank forms and
forwarding them after they've been filled out by the new member, to the
appropriate members) a set of bilateral agreements?  Is that an accurate
summary?

<K> Correct

Sounds like, at scale, we morph into a model very reminiscent of the
PSTN
(and L3 peering on the Internet).  In your view is GSMA an anomaly, or
does
it illustrate the state to which peering federations naturally evolve?

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

tim

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Jul 2006 10:38:59 -0400

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

And I can tell you from speaking with several operators about this that
many of them in fact want to know who the other carrier is.  This is
sometimes for business reasons, such as developing a billing/comp
agreement.  This is other times in a desire to reduce fraud and be able
to traceback and/or troubleshoot sessions.  I am not taking into account
legal agreements, which is surely out of scope.  Mainly I wanted to
point out that some of these operators very much desire to know who they
connect to and aren't looking to hide their numbers.

All that being said, some operator use cases have been described where
an operator just wants a relationship with an aggregrator/federation/hub
and to have them mind all the session terminations (as Kevin McCandless
briefly described).  In this case they may not necessarily care who the
session terminates with.  That's another flavor with different business
requirements.  

So perhaps this points out that there may be a place for both models...

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 7 Jul 2006 10:43:27 -0400

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

This is a good point.  The ease and low cost of generating attacks or
other 'bad' traffic is trivially low on the net and the information on
how to do so is quickly and widely distributed.

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

A good suggestion you have raised for consideration -> let the end point
/ UAs worry about the RTP stream.  Certainly there are PSTN end user
devices that will be paired at both ends to provide media security and
there'd be nothing to discourage UAs (perhaps most easily realized in
software-based clients) from employing end-to-end media encryption.  But
I suspect we'll see a variety of options here.

We seem to have general consensus that, at the very least, signaling
traffic should or must in some manner be secured/encrypted.  There may
be some confusion about the difference between mandatory-to-implement
and mandatory-to-use.  TLS is already mandatory-to-implement in the SIP
standard (for proxies, which is what matters in a speermint context). 

We will need to focus on the issue of the circumstances under which
using TLS is meaningful and appropriate. Saying that TLS is
mandatory-to-use could be problematic as there could be situations where
other methods may be more appropriate and some of that has been touched
upon in this long and continuing thread.  ;-)

Jason