Subject: Re: [Sip] re: Path as WG item

From: "James M. Polk" <[email-masked]>
Date: Mon, 04 Mar 2002 17:55:34 -0600

How about:

[email-masked] *registers* with whichever domain that UA is in locally with
the full "[email-masked]" 

If User1 is in example.com's domain, nothing gets redirected, everybody's happy

If User1's UA is in another domain, then this registration is to that non-local
domain, which replies with a temporary "[email-masked]" (or
whatever non-local domain example you want) 

Upon temporary acceptance to that registration (acknowledgement) back to
User1's UA (now knowing it's in a non-local domain) 

User1's UA transmits a Redirect Registration back to his/her home domain
Registrar Server (which is now known to be elsewhere) with the roaming temp
address of "[email-masked]" for logically where that UA is now
and wants to be reached at

 From here, either User1's domain Registrar Server sends User1's UA an ACK to
convey this is OK (authenticating the UA with its local domain), or can ACK
this temp Redirect to foreign.com's Registrar Server to have any suggested or
required authentication with that domain directly between locally trusted
hosts. 

Either way, User1's UA needs to have an acknowledgement that this mobility has
been accepted by that UA's local domain (therefore trusting that all subsequent
calls to [email-masked] will be correctly redirected and the sessions
completed)

This adds steps to the mobility process, but should:
        - keep User1's original address as the beginning of the temp address;
        - have User1's UA some level of trust future sessions should come
through to this new domain;
        - keep a simple awareness of communications between the two domains
through this addressing scheme;
        - keeps all new INVITES going to User1's original domain where it now
knows (with an easy step) where to redirect that INVITE to
        - creates an almost 3-way handshake between both Registrar Servers and
the roaming UA

just a thought.....

At 02:59 PM 3/2/2002 -0800, Rohan Mahy wrote:
>
>Juha,
>
>Assume:
>
>REGISTER sip:home.org SIP/2.0
>To: sip:[email-masked]
>From: sip:[email-masked]
>
>Are you suggesting:
>
>1) Contact: <sip:[email-masked]?Route=xyz.com;lr>
>
>2) Contact: <sip:[email-masked]>  with an additional registration to xyz.com
>(if so, what credentials would I use to authenticate my request?)
>
>3) something else
>
>thanks,
>-rohan
>
>
>
><jdr>
> > Path fills two needs, and you have omitted the second one. The second
> > one is so that INCOMING calls to me, can be routed from my home proxy
> > through an intermediate proxy that needs to be visited. I think this is
> > well within the scope of an extension to REGISTER, and I know of no
> > other alternative to solve it. This is needed for any kind of
> > visiting/roaming network where a local proxy needs to be visited for
> > incoming calls.
></jdr>
>
>no i have not omitted that one.  i proposed that if i'm visiting in a
>network xyz.com, then my home proxy can route incoming calls to the
>proxy of xyz.com that in turn knows where to forward the message within
>that network.
>
>-- juha
>
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 5 Mar 2002 11:20:49 -0600

I believe you're suggesting that the visited registrar would assign a temporary identity, then do a third-party registration back to the user's home registrar applying the temporary identity as a Contact: for the user's public identity.

This approach was discussed in a 3GPP CN1 meeting about a year ago (Miguel and I spent a long time trying to find an alternative to Path before loose routing made Path actually work). The problem we noted is that this approach requires an entirely new authentication mechanism -- you can't do it readily with something like Digest.

Here's the problem. UA sends REGISTER to Visited. How does Visited get keying information to authenticate UA? Visited then sends a 3rd-party REGISTER on to Home. How does Visited get keying material to authenticate to Home?

We could presume a coupling at the AAA layer, or some such, but it's more triggerwork than anybody really wanted to think about.

A very similar approach we discussed would be to have the Visited proxy do the same temporary-identity thing, change the Contact in the REGISTER to have the temporary identity as its value, then pass the REGISTER on to Home. This actually works for some authentication models, but I think it violates the message-integrity protection of enhanced digest.

Of course, both of these techniques sahre one moderately annoying flaw -- they require the visited proxy to be registration-stateful and persistently maintain the mapping between the temporary and mobile identities. This makes it hard to build high-capacity proxy clusters, as one suddenly requires some sort of behind-the-scenes state replication.

--
Dean

----- Original Message ----- 
  From: James M. Polk 
  To: Rohan Mahy ; [email-masked] 
  Sent: Monday, March 04, 2002 5:55 PM
  Subject: Re: [Sip] re: Path as WG item

  How about:

  [email-masked] *registers* with whichever domain that UA is in locally with the full "[email-masked]" 

  If User1's UA is in another domain, then this registration is to that non-local domain, which replies with a temporary "[email-masked]" (or whatever non-local domain example you want) 

  Upon temporary acceptance to that registration (acknowledgement) back to User1's UA (now knowing it's in a non-local domain) 

  User1's UA transmits a Redirect Registration back to his/her home domain Registrar Server (which is now known to be elsewhere) with the roaming temp address of "[email-masked]" for logically where that UA is now and wants to be reached at

  From here, either User1's domain Registrar Server sends User1's UA an ACK to convey this is OK (authenticating the UA with its local domain), or can ACK this temp Redirect to foreign.com's Registrar Server to have any suggested or required authentication with that domain directly between locally trusted hosts. 

  Either way, User1's UA needs to have an acknowledgement that this mobility has been accepted by that UA's local domain (therefore trusting that all subsequent calls to [email-masked] will be correctly redirected and the sessions completed)

  This adds steps to the mobility process, but should:
          - keep User1's original address as the beginning of the temp address;
          - have User1's UA some level of trust future sessions should come through to this new domain;
          - keep a simple awareness of communications between the two domains through this addressing scheme;
          - keeps all new INVITES going to User1's original domain where it now knows (with an easy step) where to redirect that INVITE to
          - creates an almost 3-way handshake between both Registrar Servers and the roaming UA

  just a thought.....

  *************************************
  "People generally demand more respect for their own rights than they are willing to allow for others"

  James M. Polk
  Consulting Engineer
  Office of the CTO

  Cisco Systems