Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

From: "Malas, Daryl" <[email-masked]>
Date: Tue, 30 May 2006 13:44:59 -0600

In addition to your comments below, I think peering will likely occur in
one of the following methods or all of them (this includes the
capabilities described in the Peering Architecture Draft:

+---------+
                                                           |         |
+--------+         +--------+           +------------+    /|Domain C | 
|        |		 |        |          /              \  / |
|
|Domain A| Private |Domain B| Public  |    Internet    |/  +---------+
|        |=========|        |=========|                |\
|        |  Peer   |        |  Peer    \              /  \ +---------+
+--------+         +--------+           +------------+    \|         |
    ||
|Domain D |	
    =======================================================|         |	
				Private Peer
+---------+

As far as PBX interconnect goes...

I don't think SPEERMINT should design a tie-line replacement
architecture.  IMO, it is out of scope.  I know this becomes somewhat
blurry, as more SIP PBX's are a conglomeration of multiple SIP
capabilities (e.g. UA, UAS, Proxy, etc.), some of which are described in
the architecture.  However, the SIP Forum is already addressing many of
those concerns in SIP Forum drafts such as:
sf-draft-twg-IP_PBX_SP_Interop-sibley-v5.pdf.

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

On 2006/05/30 19:05, "Livingood, Jason"
<[email-masked]> wrote:
> > I believe this discussion has gone over the edge.
> > 
> > The reason SPEERMINT exists is that CARRIERS want to peer.
> 
> Perhaps a fair assessment, but I suspect we all would like it to
> progress beyond that.  
>  
> > Email is an inappropriate metaphor for carrier peering.
> 
> Perhaps but I don't think we can conclude that as yet.  There are most
> definitely differences though.  I see no reason not to try to take
some
> of the simplicity and ubiquity of that model and trying to apply it to
a
> new application where it makes sense.

My take is that we need a system that

* allows selective peering. If we require that everybody can talk
  directly to everybody else, we don't get carrier opt-in.

* supports branching off into private interconnects.

  Ideally, all the existing private peering fabrics should fit
  into the speermint umbrella.

* scales to wide adoption, both for SIP URIs / domains as well as
  peering operators.

  Nothing in the protocol should preclude that it is used e.g.
  to get VoIP-enabled PBX systems to peer with each other.

  (Whether a carrier wants to peer with a PBX is his choice. 
  The protocol shouldn't dictate a peering policy. The contrary:
  the protocol must support all possible peering policies.)

* gives BCPs on how to do the nitty-gritty SIP details
  (caller-ID, privacy, ...)

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Tue, 30 May 2006 16:01:46 -0400

I am absolutely certain that these kinds of arrangements will be seen "in
the wild".  Two thoughts strike me:
1) If Domain A is paying Domain B a lot for this kind of service, it may
need a software update so it can do it itself
2) The route advertisement from B towards A gets REALLY tricky.  The reason
is that there is no convenient way to express it.  It's not "*" (I can get
you to any domain).  It's "I can get you to any domain that accepts
connections from the Internet".  It's the terminating network that decides
if it will allow traffic from some other domain, and "Domain B" below,
doesn't know what the rules for Domain C are.

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol

---

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 30 May 2006 16:02:57 -0400

I guess we should work on updating both draft (Architecture and Call
flows). There are lots of new material to include.

> Sent: Tuesday, May 30, 2006 12:45 PM

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Tue, 30 May 2006 16:19:53 -0400

Sorry, sent too soon...
This is the kind of thing that makes we wonder why anyone wants to look
at this in terms of route advertisement where A doesn't know the
destination is C and just looks at what B says it can reach. I can
imagine that A knows the ultimate destination is C and then seeks a
route to C, which would eliminate the contradictions Brian raises.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

I am absolutely certain that these kinds of arrangements will be seen
"in
the wild".  Two thoughts strike me:
1) If Domain A is paying Domain B a lot for this kind of service, it may
need a software update so it can do it itself
2) The route advertisement from B towards A gets REALLY tricky.  The
reason
is that there is no convenient way to express it.  It's not "*" (I can
get
you to any domain).  It's "I can get you to any domain that accepts
connections from the Internet".  It's the terminating network that
decides
if it will allow traffic from some other domain, and "Domain B" below,
doesn't know what the rules for Domain C are.

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 30 May 2006 17:02:52 -0400

Perhaps we are misinterpreting the figure.  I am interpreting C as accepting
calls over the Internet from any domain (that is, not limited to specific
peers).  I'm not just thinking that the peering fabric is the Internet; of
course any connection between peers can traverse the Internet.  I assume A
knows it wants a route to C.  ENUM is out of scope.  The Route Advertisement
is what domains B tells A it can get to, so that A knows B can get to C.

Contradiction 1 is that if C is known to accept connections from any domain,
then B is not adding value.  It can't be a secret only known to B that C
accepts any connections.

Contradiction 2 is that B can't tell A that it can reach all possible C's.
A specific C, maybe, but then you are back to Contradiction 1.

Let's be more concrete.  Suppose there is an enterprise with a SIP PBX.
Suppose it starts out by purchasing VoIP termination services from a carrier
and sends all its traffic there, and to start, only accepts traffic from its
carrier.   Now, suppose that at some point the enterprise gets comfortable
and starts allowing traffic from the Internet direct to its PBX.  Suppose,
just to get it off the table, that there is public ENUM, so number services
are not an issue.

This enterprise is now a "C".  How does B tell A that it can get to C?  How
does it know that?

Generally, C freely "advertises" its "route" by simply putting an SRV record
in its public DNS.  What is the way A "seeks a route to C" by any mechanism
short of just trying DNS.  What I'm getting at is that B can't make a
definitive list of all the C's out there, and there is no wildcard that
works.   

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol

---

From: "Patrick Melampy" <[email-masked]>
Date: Tue, 30 May 2006 21:49:29 -0400

B's value (which you seem to completely be disregarding) isn't solely that
he can forward SIP messages directly to C -- more importantly, C trust's B
that B will only forward TRUSTED communication to C. Thus the chain of
identity asserted, trusted communication, can only work when untrusted
networks and proxies are either excluded, or clearly identified as
untrusted.

Speaking of enterprises...I bet very few will connect their IP PBX to the
public internet. I suspect they will connect these types of systems only to
proxies and sources of inbound communications requests that they trust.

This group needs to be focused on developing schemes for "connecting" these
proxies into trusted chains. I believe that an advertisement mechanism
(subscribe/notify) can meet this requirement.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 5:03 PM
To: 'Pfautz, Penn L, GBLAM'; 'Malas, Daryl'; 'Otmar Lendl';
[email-masked]

Brian

-----Original Message-----
From: Pfautz, Penn L, GBLAM [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:20 PM
To: Brian Rosen; Malas, Daryl; Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Sorry, sent too soon...

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 4:02 PM
To: 'Malas, Daryl'; 'Otmar Lendl'; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Brian

-----Original Message-----
From: Malas, Daryl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:45 PM
To: Otmar Lendl; [email-masked]
Subject: RE: [Speermint] Updated Draft: SPEERMINT Peering Architecture

+---------+
                                                           |         |

My two cents...

--Daryl M.

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 11:51 AM
To: [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

some
a

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 31 May 2006 08:14:50 +0200

> networks and proxies are either excluded, or clearly identified as

Correct.

> public internet. 

You've got to distinuish "public internet" on layer 3 from open SIP
proxy on the Internet. Right now, some of the enum.at registrars are
happily selling VoIP-based PBX installations to enterprises which
peer with each other automatically based on User-ENUM and open SIP URIs.

>                  I suspect they will connect these types of systems only to

That's one of the examples of my "federation" draft. E.g. take the
MPAA as a typical industry association: If they run a X.509
certification authority (incl. revocation lists) which signs the
TLS certs of the PBXs of member organizations then all the
telephone systems of Hollywood can peer with each other over the
open Internet in a secure fashion.

Whatever Speermint comes up with: such a scenario must IMHO be supported.

> (subscribe/notify) can meet this requirement.

As mentioned before, (subscribe/notify) is very nice for manually
configured relationsships. I don't see how you implement
the guild example from above with that concept. 

Please elaborate.

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 31 May 2006 07:46:08 -0400

Oh, I really expect to see most connections through carriers for quite a
while.  I do wonder if "trust" is something transit networks can actually
help with.

I believe in identity, and identity has to be asserted by someone.  One
reasonable source of trusted identity is the originating carrier.  That is
an enduring value; if a carrier does little more than provide a reliable
identity, that will help avoid SPIT.

However, it seems hard to me for a transit network to provide a trust chain
stronger than a direct connections.  Maybe this is wrapped up in what you
call "trusted communications".  What is the assertion that B is making about
A that C cares about?

One of the things that we have to face is that most of us WILL accept a call
from someone we don't know.  We balance the risk of being annoyed or
offended against the risk of discovering something new that we like.  A
business, as an example, doesn't want to miss a call from a new customer, so
it always accepts calls directed to its general sales line from anyone.  

We have to deal with identity, which is one of the trust characteristics an
originator provides to a terminator.  What else are we trusting?

Brian

-----Original Message-----
From: Otmar Lendl [mailto:[email-masked]] 
Sent: Wednesday, May 31, 2006 2:15 AM
To: Patrick Melampy
Cc: 'Brian Rosen'; [email-masked]
Subject: Re: [Speermint] Updated Draft: SPEERMINT Peering Architecture

Correct.

Please elaborate.

/ol

---

From: Duane <[email-masked]>
Date: Wed, 31 May 2006 08:16:03 -0400

> it always accepts calls directed to its general sales line from anyone.  

I think things won't be as bad as they are now, if in future people can 
run a small pbx to filter their calls, so rather then cold calls being 
automated in a fashion they are now telemarketers will need to listed to 
menu options before being connected to a person (this particular method 
drops most cold calls I've found, since the system answers and waits for 
  input but the telemarketer doesn't hit it in time so the system 
trashes the call.

I liked the X.509 certs on TLS connections idea as well, and in the case 
of CID being in enum you could also do a reverse lookup and/or some 
other record type to determine where calls are supposed to come from (I 
hate to say it - "SPF style").

Although if some kind of CID verification is establish at this point in 
time things might not get out of hand like they have with email.

-- 

Best regards,
  Duane