Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 14 Apr 2006 14:02:44 -0400

Penn,

I think it stems from the underlying requirement that before
establishing communications (signaling) to a peer, one needs to know who
they are talking to.  The two general options are:

1) through the use of some type of PKI that anyone can trace back
through to some certificate chain to a trusted root certificate
authority, or

2) through bi-lateral agreements between peers (and associated
out-of-band exchange of symmetric keying material).

In the former case, there will be arguments over who gets to be the
root, and what happens if there are multiple roots.  (Just like with
ENUM :)

In the latter case, billions of customers are proxied by hundreds of
thousands of organizations.  But, if there are hundreds of "transit L5
providers" that are willing and able to be the "truested third party"
between proxy A and B, who both have bilateral agreements to transit C,
but not directly to each other, then a workable solution is possible.
The hundreds of L5 transit providers in turn may come to some bilateral
agrements with each other to reach universal reachability. 

You can guess at who the transit L5 players will be. :)

The market will decide which case is more efficient from a business
standpoint.  There may end up being a mixture of both.

Mike

> -----Original Message-----
> From: Pfautz, Penn L, NEO [mailto:[email-masked]] 
> Sent: Friday, April 14, 2006 1:34 PM
> To: [email-masked]
> Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 
> 
> Hmm... Maybe my mind is already on the weekend but how does 
> all this authorization and authentication fit in with the 
> scaling concerns people keep expressing? Are we driving back 
> to a bilateral process? 
> 
> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Friday, April 14, 2006 1:27 PM
> To: 'Michael Hammer (mhammer)'; [email-masked]
> Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 
> 
> Hi Michael, comments inline...
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Friday, April 14, 2006 7:50 AM
> > To: Hadriel Kaplan; [email-masked]
> > Subject: RE: [Speermint] SPEERMINT Routing Architecture 
> Message Flows
> > 
> > I think we want this exchange to be between peers.  Registration is
> more
> > subordinate to superior.  You don't normally see SIP Proxies
> registering
> > to their client phones.
> 
> Nor do they generate such register requests anyway.  They'd 
> have to have a UA component to do it, and act as a registrar 
> on the other side, and registration is not the semantics you 
> want anyway.
>  
> > In both cases, there is an authentication and authorization, so the
> key
> > mangement issues will be there in both cases.  I don't see 
> that as a 
> > discriminating factor.
> 
> Indeed, that's why I said the sub/notify did not resolve my confusion.
> In
> either method the auth problems are not solved, assuming you 
> meant the Subscribe would be challenged as the auth 
> mechanism.  If you just meant the xml contents would be used 
> to provide some auth mechanism, then that's different.
> 
> 
> > In passing some type of session key to the requestor, I saw a more 
> > general need to pass parameter values regarding the interconnection 
> > scheme.  Suggesting XML bodies to do that was simply making the 
> > mechanism more general.  While we are still in the stages 
> of trying to 
> > figure out what information needs to be exchanged between peers, 
> > generality seems useful.
> 
> Agreed, as I said I assumed sub/notify would be proposed for 
> policy exchanges at some point in this WG.  It was the 
> proposed proxy-proxy authentication idea in the draft that 
> confuses me.
> 
> -hadriel
> 
> 
> 
> _______________________________________________
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 14 Apr 2006 14:42:58 -0400

Yup, agreed - but even in the bi-lat case one could use mutual-TLS instead
of digest/challenge, and just have the certs be created/rooted by one of the
sides. (e.g., the transit provider) 
 
Or one could accept self-signed certs, and use a pre-shared password for
challenge/response but without sending extraneous messages to do so.  For
example, just proxy-challenge the initial Invite request using something
like AKA. (though it would require some changes to enable a proxy to do
challenge/response)  

The advantage then is for the duration of the TLS session you do not need to
re-auth at a higher layer.  And for a tiered bi-lat relationship model
you're probably going to want to keep these "connections" alive all the
time.

-hadriel

> Sent: Friday, April 14, 2006 2:03 PM
> To: Pfautz, Penn L, NEO; [email-masked]