Subject: [martini] draft-kaplan-martini-mixing-problems: solution requirements?

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Dec 2009 22:53:08 -0800

To have a productive Virtual Interim meeting on January 7, 2010, we
expect that all attendees will have read the problem statement document
as well as the solution proposals.   With this email, I'd like to kick
off discussion on the problem statement document.  If you have comments
on this document (or the solution proposals), please send your thoughts
to the list.

Since a very important step in solving any problem is understanding the problem as well as the solution requirements, this draft is quite important.  So I'd like to thank Hadriel for submitting this draft, and agreeing to present it at the Virtual Interim. 

As part of the problem statement discussion at the Virtual Interim, we will talk about currently deployed solutions (Section 3) as well as some of the issues with current solutions described in Sections 4, 5 and 6. 

Currently, these sections articulate the issues, but don't make recommendations as to which of the issues a potential solution needs to solve.  Some of the issues are indicated as open in the solution
proposals (e.g. open question on PAU/Wildcard syntax in
draft-kaplan-martini-shaken-implicit-registrations) so this is not just a rhetorical question. 

Here's a list of the Issues described in Sections 4, 5 & 6. 

4.1.  Explicit Indication of Multiple AOR Registration
4.2-4.4: Usage of P-Associated URI
        a. Inclusion of PAU
        b. Avoidance of SIP Response fragmentation
           1. Non-wildcard mitigation
           2. Support for Wildcard syntax
           3. Compatibility of Wildcard syntax with TEL URI
        c. Defined behavior of IP-PBX on PAU mismatch
5.1   Retaining Target Info
5.2   Contact-URI handling
        a.  Request-URI
        b.  Route Header
5.3   Routing for explicit/implicitly registered AOR
6.1   Avoidance of authorization policy mismatch
6.2.  Avoidance of PAU mismatch
6.3.  Trust domain clarification

Question for the WG:  are solutions to these issues REQUIRED, RECOMMENDED, OPTIONAL or IRRELEVANT in a potential solution?

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Dec 2009 17:36:57 -0600

On 12/28/09 12:53 AM, Bernard Aboba wrote:
> Currently, these sections articulate the issues, but don't make 
> recommendations as to which of the issues a potential solution needs 
> to solve.  Some of the issues are indicated as open in the solution 

I think this is REQUIRED.

>         c. Defined behavior of IP-PBX on PAU mismatch

I don't think we want to rely on PAU behavior to make a multiple 
registration solution work. The definition in RFC3455 is pretty well 
constrained to an exhaustive enumeration of identities, which is not 
appropriate for the kind of use cases MARTINI is discussing. Even more 
importantly, it was meant for something rather different than MARTINI's 
problem space: multiple identities that semantically mean *exactly* the 
same *user*. Not billing entity, but actual *user*.

So, I think all the PAU issues are IRRELEVANT with regards to PAU itself.

However, I think we need to carefully consider the semantic issues that 
are implied by these sections. Things like:

    * Who designates which URIs the request is attempting to register?
      For example, if a company has a single PBX and decides to split
      its users between two different PBXes (say, at different sites) --
      does it need to get the SSP to reprovision the URIs associated
      with its implicit registrations? Or would it make more sense for
      the request to indicate which URIs it was attempting to register?
      This would allow the company to move URIs around between its own
      PBXes without a provisioning action at the SSP.

    * How does the UAC know which URIs have just been registered? If
      they don't match what it expects, how does it react? Note that
      this problem goes away if we allow the user to designate which
      URIs they're attempting to register in the request. Granted, it
      pushes the responsibility of verifying the URIs onto the SSP
      equipment, but at least it can send an error response if the
      requestor is not authorized to use the specified URIs.

    * Response size is a real concern, since there's no way to switch
      from UDP to TCP at the UAS side when responses are too large for
      the MTU. On the other hand, the requestor can always elect to use
      TCP if the request is too large. This, again, points to having the
      requestor indicate the URIs to be used instead of the responder.

Which is to say: I think the implicit model currently under discussion 
in the problems and implicit-registration drafts is going about the 
issue backwards. I believe that there are a number of reasons it makes 
much more sense to have an explicit model in which the PBX tells the SSP 
which URIs it is attempting to register, and the SSP accepts or denies 
the request based on authorization policy.

> 5.1   Retaining Target Info

I think retaining all the information that the PBX used to indicate 
itself -- the "Contact" header field in Hadriel's drafts -- is REQUIRED. 
Clearly, we also need the ability to tell which extension is being 
addressed (i.e., this is REQUIRED as well).

I'm less concerned about the mechanisms used to convey this information. 
Ideally, it would be as consistent with normal handling as is possible 
-- meaning that the Request URI is semantically the information the PBX 
used to indicate itself (again, the "Contact" header field in Hadriel's 
proposals).

When you think about how currently-deployed multiline SIP phones handle 
this situation, they'll usually use the user portion of the Contact 
header field to keep track of which of its several identities a request 
is associated with. For example, a phone may register the AOR 
"sip:[email-masked]" with a Contact of "sip:[email-masked]", and 
register "sip:[email-masked]" with a Contact of 
"sip:[email-masked]". That's kind of nice, because it lets the end 
device correlate information according to its own local scheme.

If we go with a scheme that allows the requestor to indicate which URIs 
it is requesting for, we might also include some kind of transform to go 
with each of the URIs. For example, we could define a syntax whereby a 
MARTINI request ends up associating a range-of-URI indicator like 
"sip:214329{wildcard pattern meaning 4 [email-masked]" with 
"sip:pbx-110-{pattern meaning put those 4 digits [email-masked]".

> 5.3   Routing for explicit/implicitly registered AOR

I think we need to be able to do this without middleboxes, and without 
violating SIP's rules about being authoritative for the requests that a 
proxy retargets. The strawman proposal I describe above does not exhibit 
the problem described in 5.3. Of course, neither does any well-designed 
solution. I think the stuff in the field that includes the SSP's domain 
in the R-URI bound for the PBX is simply poorly designed and 
insufficiently thought out.

In other words, the issue in 5.3 is one of poorly-engineered 
implementations, and therefore IRRELEVANT.

> 6.1   Avoidance of authorization policy mismatch

IRRELEVANT. I don't think we need to codify the type of authorization 
described in this section, as such policies necessarily limit the 
flexibility of SIP PBX implementations. It is quite useful to include 
state information in the Contact header field that can be extracted in 
future requests. if the SSP policy doesn't allow this kind of valid use 
of Contact URIs, then we've lost a rather elegant mechanism.

> 6.2.  Avoidance of PAU mismatch

IRRELEVANT, for the reasons I enumerate under 4.2-4.4, above.

> 6.3.  Trust domain clarification

I think this isn't just IRRELEVANT -- I think it's out of scope for the 
working group.

/a