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

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

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.

Also, I think the registration is more specific, whereas the Subscribe
is more general and extensible.

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.

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.

Mike

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Thursday, April 13, 2006 10:32 PM
> To: Michael Hammer (mhammer); [email-masked]
> Subject: RE: [Speermint] SPEERMINT Routing Architecture Message Flows 
> 
> I was confused by the registration as well but it must be for 
> different reasons because doing subscribe/notify doesn't 
> solve my confusion.  :)  It has benefits for other things, 
> and was what I was assuming would be used for some policy 
> exchanges ultimately, but not the piece I was confused with 
> this draft.
> 
> In the draft it says it's used for mutual proxy 
> authentication.  For a typical register challenge method to 
> do that, they have to have shared/known passwords and 
> usernames. (are we assuming that?)  If a "key" is exchanged 
> in the register to be used as the password, as shown in the 
> draft I think, it does nothing; a man-in-the-middle has a 
> view of those keys and can use them, and there's no 
> authentication scheme for one proxy to believe the key of the 
> other anyway. (unless "key" means a nonce?) 
> 
> Regardless, why not just use mutually-authenticated TLS?  The 
> details of how to believe the certs of each side though are 
> still being discussed in the sip mailing list I think. (I 
> haven't been following it) 
> 
> -hadriel
> 
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, April 13, 2006 2:09 PM
> > To: [email-masked]; Reinaldo Penno; [email-masked]
> > Subject: RE: [Speermint] SPEERMINT Routing Architecture 
> Message Flows
> > 
> > To the authors of draft-penno-message-flows-00.txt,
> > 
> > One part of this that didn't seem quite right to me was the use of 
> > mutual Registrations between Proxy 1 or domain A and Proxy 
> 2 of domain 
> > B.  (e.g., Do you intend to do some type of Contact routing?)
> > 
> > Could I ask by way of suggestion why you don't use mutual 
> > Subscribe/Notify?  That would require the same authentication and 
> > authorization to the requesting domain and would likely be 
> much richer 
> > in terms of XML documents that could be supplied to the 
> other domain 
> > in a Notify.  An event package per federation type could be 
> defined, 
> > for example.
> > 
> > What do you think?
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Henry Sinnreich [mailto:[email-masked]]
> > > Sent: Thursday, April 13, 2006 12:55 PM
> > > To: 'Reinaldo Penno'; [email-masked]
> > > Subject: RE: [Speermint] SPEERMINT Routing Architecture Message 
> > > Flows
> > >
> > > The call flows shown are pretty much as would be expected 
> from the 
> > > trapezoid model in RFC 3261 using well defined SIP proxy behavior 
> > > (lengthy section in RFC 3261).
> > >
> > > Why use B2BUA that have no defined behavior at all?
> > >
> > > Is it possible to standardize undefined behavior?
> > >
> > > Thanks, Henry
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Reinaldo Penno [mailto:[email-masked]]
> > > Sent: Wednesday, April 12, 2006 3:27 PM
> > > To: [email-masked]
> > > Subject: [Speermint] SPEERMINT Routing Architecture Message Flows
> > >
> > > Hello,
> > >
> > > We wrote a draft to help frame our discussions.
> > >
> > > Thanks,
> > >
> > > Reinaldo
> > >
> > >
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.
> > >
> > >
> > > 	Title		: SPEERMINT Routing Architecture Message Flows
> > > 	Author(s)	: R. Penno, et al.
> > > 	Filename	: draft-penno-message-flows-00.txt
> > > 	Pages		: 19
> > > 	Date		: 2006-4-12
> > >
> > > This draft describes the message flows associated with 
> the SPEERMINT 
> > > routing architecture. We show message flows in several peering 
> > > scenarios.
> > >
> > >
> > > A URL for this Internet-Draft is:
> > > 
> http://www.ietf.org/internet-drafts/draft-penno-message-flows-00.txt
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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 13:27:25 -0400

Hi Michael, comments inline...

> Sent: Friday, April 14, 2006 7:50 AM
> To: Hadriel Kaplan; [email-masked]

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.
 
> mangement issues will be there in both cases.  I don't see that as a

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.

> figure out what information needs to be exchanged between peers,

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

---

From: "Pfautz, Penn L, NEO" <[email-masked]>
Date: Fri, 14 Apr 2006 13:34:15 -0400

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 

> subordinate to superior.  You don't normally see SIP Proxies
registering

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.
 
> mangement issues will be there in both cases.  I don't see that as a

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.

-hadriel

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 14 Apr 2006 13:39:21 -0400

Case 1

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

 

-hadriel