Subject: [Speermint] Categorization of Federations

From: "Uzelac, Adam" <[email-masked]>
Date: Mon, 14 Jan 2008 11:50:32 -0500

In the next release of the VoIP use-case ID for SPEERMINT, there is
going to be an effort to consolidate the Federation section of the
document into the agreed upon categorizations of Static/On-Demand, and
the subsequent subdivision of direct and indirect.  I am of the camp
that Federations should fall into the Static/Direct categorization,
while an argument can also be made to have Federations in the
On-Demand/Direct scenario. 

I would like to get a feel from the list on this topic.  Please comment.

Adam Uzelac
Director, Converged Network Arch and Planning
Global Crossing
585-563-4359

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

---

From: "Daryl Malas" <[email-masked]>
Date: Thu, 17 Jan 2008 15:24:36 -0700

Adam,

The definition of a Federation is directly polarized to the concept of
On-demand, please see below:

4.2.3. On-demand Peering
SSPs are said to peer on-demand when they are able to exchange traffic
without any pre-association prior to the origination of a real-time
transaction (like a SIP message) between the domains.

[...without any pre-association prior...]

5. Federations
A federation is a group of SSPs which agree to receive calls from each
other via SIP, and who agree on a set of administrative rules for such
calls (settlement, abuse-handling, ...) and the specific rules for the
technical details of the peering.

I can add some verbiage to Section 5 to indicate Federations may only
peer in a static manner if it will clear up confusion.

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 19 Jan 2008 00:48:50 +0100

Daryl, Adam,

> On-demand, please see below:

I think it's orthogonal.

There are federations where the member know each other in advance
and can set up the peering well before the first call comes in,
and I can imagine federations where members discover on demand that
a specific call can be passed towards a fellow federation peer.

Here is an example for the latter: 

Let's say PBX vendor X sells nice SIP enabled PBXs which can be
configured to do ENUM queries towards some ENUM tree. Furthermore, X
acts as X.509 certification authority (incl. revocation management) for
the SIP TLS certs of its customers' installation.

A simple federation could be the set of all PBX installations from
vendor X which do ENUM lookups into a common tree and which accept
incoming SIP calls if the TLS handshake shows the both side posses
a valid cert as signed by the vendor X CA. (who guarantees that
these are serious, non-spammy, well connected, corporate customers)

Whenever a new PBX with these features is installed, then all the
others need not do anything. No new configurations are needed there.
The peering with this new federation member is completely ad-hoc
with the first call.

(For all I know, the phonegnome system is close to such a setup.)

> peer in a static manner if it will clear up confusion.

I don't agree.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: "Daryl Malas" <[email-masked]>
Date: Fri, 18 Jan 2008 17:22:48 -0700

Otmar,

I think the LUF/LRF and components of the SED can be dynamic, but the
peering relationships in a federation are still static.

--Daryl
-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Friday, January 18, 2008 4:49 PM
To: Daryl Malas
Cc: [email-masked]; Uzelac, Adam
Subject: Re: [Speermint] Categorization of Federations

Daryl, Adam,

I think it's orthogonal.

There are federations where the member know each other in advance and
can set up the peering well before the first call comes in, and I can
imagine federations where members discover on demand that a specific
call can be passed towards a fellow federation peer.

A simple federation could be the set of all PBX installations from
vendor X which do ENUM lookups into a common tree and which accept
incoming SIP calls if the TLS handshake shows the both side posses a
valid cert as signed by the vendor X CA. (who guarantees that these are
serious, non-spammy, well connected, corporate customers)

Whenever a new PBX with these features is installed, then all the others
need not do anything. No new configurations are needed there.
The peering with this new federation member is completely ad-hoc with
the first call.

I don't agree.

/ol
--
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 // nic.at
Internet Verwaltungs- und Betriebsgesellschaft m.b.H //
http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 19 Jan 2008 14:39:36 +0100

Daryl,

> peering relationships in a federation are still static.

The current definition of static peering is:

| 4.2.5. Static Peering
| 
|    SSPs are said to peer statically when pre-association between
|    providers is required for the initiation of any real-time
|    transactions (like a SIP message).

I don't see how this applies to the given example. The peering partners
don't know about each other until the first call between them. There is
no pre-association.

/ol

---

From: "Daryl Malas" <[email-masked]>
Date: Mon, 21 Jan 2008 08:23:06 -0700

Otmar,

I was more looking at this:

5. Federations

To me, this indicates pre-association.

--Daryl

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
Sent: Saturday, January 19, 2008 6:40 AM
To: Daryl Malas
Cc: [email-masked]; Uzelac, Adam
Subject: Re: [Speermint] Categorization of Federations

Daryl,

| 4.2.5. Static Peering
| 

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 21 Jan 2008 17:27:55 +0100

> To me, this indicates pre-association.

"pre-association" in the sense of the active participation in such 
a setup, yes. But not necessarily pre-association with every peering
partner. 

In the example I gave all setup/pre-association happens between the
enterprise installing such a PBX and the vendor (e.g. configuring the
ENUM setup, applying for the X.509 cert, signing terms-of-use statements
regarding that service, retrieving revocation lists, complaints on
incoming SPIT, ...). 

Which point of the federation definition isn't fulfilled by this example?

Maybe the crucial point is that I contend that it's not necessary for
the group of SSPs to sign mutual agreements, but instead that it can
be sufficient that each members signs the group's charta.

/ol

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 22 Jan 2008 09:37:42 -0500

A concern I have with regards to this discussion isn't so much the
technical merits, but more the fact that the use-case draft is chartered
to capture current practices in the industry.  With that in mind, most
of the Federation deployments that I am aware of falls inline with
Daryl's train of thought - a Federation is On-demand/static.

-AU 

> Sent: Friday, January 18, 2008 6:49 PM
> To: Daryl Malas
> Cc: Uzelac, Adam; [email-masked]
> There are federations where the member know each other in 
> advance and can set up the peering well before the first call 
> comes in, and I can imagine federations where members 
> discover on demand that a specific call can be passed towards 
> a fellow federation peer.
> 
> Let's say PBX vendor X sells nice SIP enabled PBXs which can 
> be configured to do ENUM queries towards some ENUM tree. 
> Furthermore, X acts as X.509 certification authority (incl. 
> revocation management) for the SIP TLS certs of its 
> customers' installation.
> 
> A simple federation could be the set of all PBX installations 
> from vendor X which do ENUM lookups into a common tree and 
> which accept incoming SIP calls if the TLS handshake shows 
> the both side posses a valid cert as signed by the vendor X 
> CA. (who guarantees that these are serious, non-spammy, well 
> connected, corporate customers)
> 
> Whenever a new PBX with these features is installed, then all 
> the others need not do anything. No new configurations are 
> needed there.
> The peering with this new federation member is completely 
> ad-hoc with the first call.
> 
> // Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 
> 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft 
> m.b.H // http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg
>

---

From: "Uzelac, Adam" <[email-masked]>
Date: Tue, 22 Jan 2008 10:50:13 -0500

Sorry - Daryl is correct.  Static/direct.   

> From: Daryl Malas [mailto:[email-masked]] 
> Sent: Tuesday, January 22, 2008 10:34 AM
> To: Uzelac, Adam
> Cc: Otmar Lendl; [email-masked]
> I think you meant to say "a Federation peers statically", not 
> on-demand.  Is this correct?
> 
> --Daryl
> 
> On 1/22/08, Uzelac, Adam <[email-masked]> wrote:
> > technical merits, but more the fact that the use-case draft is 
> > chartered to capture current practices in the industry.  
> With that in 
> > mind, most of the Federation deployments that I am aware of falls 
> > inline with Daryl's train of thought - a Federation is 
> On-demand/static.
> >
> > -AU
> >
> > > and can set up the peering well before the first call 
> comes in, and 
> > > I can imagine federations where members discover on demand that a 
> > > specific call can be passed towards a fellow federation peer.
> > >
> > > configured to do ENUM queries towards some ENUM tree.
> > > revocation management) for the SIP TLS certs of its customers' 
> > > installation.
> > >
> > > valid cert as signed by the vendor X CA. (who guarantees 
> that these 
> > > are serious, non-spammy, well connected, corporate customers)
> > >
> > > 933 // nic.at Internet Verwaltungs- und 
> Betriebsgesellschaft m.b.H

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 22 Jan 2008 08:59:22 -0700

Adam,

I do not agree with one thing.  I think federated peers must peer
statically, but it can occur direct or indirectly.

--Daryl

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 22 Jan 2008 17:32:11 +0100

> a specific call can be passed towards a fellow federation peer.

Daryl and I had a chat yesterday evening trying to find out where
exactly our disagreement is, and it seems to be that we categorize the same
setup differently.

e.g. "on-demand":

| 4.2.4. On-demand Peering
| 
|   SSPs are said to peer on-demand when they are able to exchange
|   traffic without any pre-association prior to the origination of a
|   real-time transaction (like a SIP message) between the domains. Any
|   information that needs to be exchanged between domains in support
|   of peering can be learned through a dynamic protocol mechanism. On-
|   demand peering can occur as direct, indirect, or assisted.

The example I wrote can be interpreted in two ways:

a) it is "static", as members of the federation manually associate
towards the federation before a call can be passed. The federation rules
are not learned through a dynamic protocol mechanism. Thus there is
"some pre-association".

b) it is "on-demand", as a call towards a specific federation member
does not need any further pre-association beyond the generic "joining
the federation" operation.

In other words, association towards the federation is static, towards
individual peers can be on-demand. Do we now call this peering "static"
or "on-demand"?

This is where we seem to disagree (Daryl, please correct me if I got
that wrong).

Let me propose a litmus question to sort this out:

   A federation implements internally on-demand peerings if old
   federation members do not have to change their configuration whenever
   a new SSP joins this federation.

Does this make sense?

/ol

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 23 Jan 2008 13:34:40 -0500

But how does the on-demand peering happens internally in federation? If
a SSP joins the federation and wants to have direct connection to
another member SSP, today BCP is to have pre-association with the member
peer. I think this is categorized to static direct peering, right? 

This is awesome if a SSP can setup an on-demand direct peering to
members in federation, but I don't see how easily to setup a protected
channel on demand without using some methods like what you suggested to
learn the certificate from the federation facilitator.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, January 22, 2008 11:32 AM
To: Daryl Malas; Uzelac, Adam; [email-masked]
Subject: Re: [Speermint] Categorization of Federations

On 2008/01/19 00:01, Otmar Lendl <[email-masked]> wrote:
> > The definition of a Federation is directly polarized to the concept 
> > of On-demand, please see below:
> 
> I think it's orthogonal.
> 

Daryl and I had a chat yesterday evening trying to find out where
exactly our disagreement is, and it seems to be that we categorize the
same setup differently.

e.g. "on-demand":

Does this make sense?

/ol

---

From: "Daryl Malas" <[email-masked]>
Date: Wed, 23 Jan 2008 11:42:46 -0700

Yiu,

I agree with you regarding today's BCP.  In response to Otmar and my
disagreement.  I would assert if a new member joins a federation and is
not compatible with the "direct/static" set of guidelines, the
Federation would be required to updated the minimum set of rules require
to peer within the federation.  This still requires/describes
pre-association, which violates the "on-demand" premise.  Also, why
would I join a federation if I did not know how or if I could peer to
any of the federated peers?

--Daryl

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Tuesday, January 22, 2008 11:32 AM
To: Daryl Malas; Uzelac, Adam; [email-masked]
Subject: Re: [Speermint] Categorization of Federations

e.g. "on-demand":

Does this make sense?

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 23 Jan 2008 22:19:08 +0100

> peer. I think this is categorized to static direct peering, right? 

I'm not _quite_ sure whether I really know what you mean exactly
by "pre-association". Can you give details on what happens at that
stage?

Otherwise, yes: if SSPs need to do something extra to enable peerings
to a specific federation peer, than I agree that we should call it
"static" and "direct" peering.

> learn the certificate from the federation facilitator.

In my examples is it not necessary that federation facilitator
distributes the key of each members to all members. It just needs
to sign the key of each individual member.

You can then build such a federation quite trivially with OpenSER,
see http://www.openser.org/docs/tls-1.3.x.html by setting

tls_ca_list="/mycerts/certs/fed-ca-cert.pem"
tls_verify_client=1
tls_require_client_certificate=1

This tells OpenSer only to allow TLS connects from clients whose key
was signed by the federation's CA. This is very basic X.509 stuff.

A full description on how to implement such federations using OpenSer
(and my domain-policy drafts as federation discovery) can be found at
http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downloaddata=46

Have a look.

/ol

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 29 Jan 2008 08:19:31 -0700

I would like to suggest some updated wording for "Static Peering" in the
terminology draft to clear up some confusion.  I tried to keep it
simple, but would like to get your comments.

4.2.4. Static Peering
SSPs are said to peer statically when pre-association between providers
is required for the initiation of any real-time transactions (like a SIP
message).  Static peering can occur as direct or indirect.  An example
of static peering is a federation.  Each of the peers within the
federation must first agree on a common set of rules and guidelines for
peering, thus pre-associating with each other prior to initiating
session requests.

Thanks...--Daryl 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 2:19 PM
To: Lee, Yiu
Cc: [email-masked]
Subject: Re: [Speermint] Categorization of Federations

On 2008/01/23 19:01, "Lee, Yiu" <[email-masked]> wrote:
> But how does the on-demand peering happens internally in federation? 
> If a SSP joins the federation and wants to have direct connection to 
> another member SSP, today BCP is to have pre-association with the 
> member peer. I think this is categorized to static direct peering,
right?

I'm not _quite_ sure whether I really know what you mean exactly by
"pre-association". Can you give details on what happens at that stage?

Otherwise, yes: if SSPs need to do something extra to enable peerings to
a specific federation peer, than I agree that we should call it "static"
and "direct" peering.

> channel on demand without using some methods like what you suggested 
> to learn the certificate from the federation facilitator.

In my examples is it not necessary that federation facilitator
distributes the key of each members to all members. It just needs to
sign the key of each individual member.

You can then build such a federation quite trivially with OpenSER, see
http://www.openser.org/docs/tls-1.3.x.html by setting

This tells OpenSer only to allow TLS connects from clients whose key was
signed by the federation's CA. This is very basic X.509 stuff.

A full description on how to implement such federations using OpenSer
(and my domain-policy drafts as federation discovery) can be found at
http://www.enum.at/typo3conf/ext/nf_downloads/pi1/passdownload.php?downl
oaddata=46

Have a look.

/ol

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 29 Jan 2008 16:27:51 -0500

As long as the rest of the team agrees that Federation is one kind of
"Static Peering", I am ok for this description.  

Thanks,
Yiu

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2008 10:20 AM
To: Otmar Lendl; Lee, Yiu
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

4.2.4. Static Peering

Thanks...--Daryl 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Wednesday, January 23, 2008 2:19 PM
To: Lee, Yiu
Cc: [email-masked]
Subject: Re: [Speermint] Categorization of Federations

right?

Have a look.

/ol

---

From: "Daryl Malas" <[email-masked]>
Date: Tue, 29 Jan 2008 14:30:13 -0700

I am not sure I understand what you mean.  Can you please explain?  The
definition still indicates static peering can be both direct and
indirect.

Thanks...--Daryl 

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2008 2:28 PM
To: Daryl Malas; Otmar Lendl
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

Thanks,
Yiu

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Tuesday, January 29, 2008 10:20 AM
To: Otmar Lendl; Lee, Yiu
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

4.2.4. Static Peering

Thanks...--Daryl 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Wednesday, January 23, 2008 2:19 PM
To: Lee, Yiu
Cc: [email-masked]
Subject: Re: [Speermint] Categorization of Federations

right?

Have a look.

/ol

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 29 Jan 2008 16:34:33 -0500

Yes. I know it can be Direct and Indirect. Adam and I agree with you
that Federation is Static Peering. I just wonder is there any people
thinking that Federation can be built on "On-demand" peering. That's it.

Thanks,
Yiu

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]] 
Sent: Tuesday, January 29, 2008 4:30 PM
To: Lee, Yiu; Otmar Lendl
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

Thanks...--Daryl 

-----Original Message-----
From: Lee, Yiu [mailto:[email-masked]]
Sent: Tuesday, January 29, 2008 2:28 PM
To: Daryl Malas; Otmar Lendl
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

Thanks,
Yiu

-----Original Message-----
From: Daryl Malas [mailto:[email-masked]]
Sent: Tuesday, January 29, 2008 10:20 AM
To: Otmar Lendl; Lee, Yiu
Cc: [email-masked]
Subject: RE: [Speermint] Categorization of Federations

4.2.4. Static Peering

Thanks...--Daryl 

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]]
Sent: Wednesday, January 23, 2008 2:19 PM
To: Lee, Yiu
Cc: [email-masked]
Subject: Re: [Speermint] Categorization of Federations

right?

Have a look.

/ol