Subject: [martini] Evaluation of issues solved by martini-up

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jan 2010 17:13:26 +0100

Section 9 of draft-roach-martini-up-00 describes the issues (from mixing-problems) solved by the proposal. Most of these issues can be solved using a REGISTER-based approach - see my interleaved remarks.

"No Explicit Indicator:  The mechanism in this document cannot be
      confused with the normal registration mechanism defined in RFC
      3261, as it does not attempt to overload REGISTER to convey bulk
      dynamic routing information."
[JRE] That is why we propose some explicit indication.

"Undefined Behavior on PAU Mismatch:  By shifting the task of
      specifying the AORs being registered from the server to the
      client, there is no opportunity for mismatch.  Policy errors may
      arise when the client attempts to register for AORs other than
      those it is authorized to register; however, procedures for
      detecting and addressing these conditions are provided."
[JRE] Ensuring a matching set of AORs is a provisioning issue, and does not need to be part of the dynamic update mechanism.

"REGISTER Response Growth:  By shifting the task of specifying the
      AORs being registered from the server to the client, normal
      response size is maintained.  Circumstances under which a UDP
      response is required, but size precludes sending a response, are
      precluded."
[JRE] I would agree with removing it from the response, but I doubt the need to include it in the request - see previous point.

"Illegal Wildcarding Syntax:  By defining a wildcarding syntax outside
      the strictures of SIP, the issue of valid SIP syntax is
      sidestepped."
[JRE] Can be avoided - see previous two points.

"Loss of Target Info:  Because the binding from AOR to Contact URI is
      under complete control of the requestor, and because the model of
      proxy/registrar routing defined in RFC 3261 is maintained, the
      system exhibits the same properties as it would if each user were
      registered individually.  Target information is preserved."
[JRE] Indeed, and any REGISTER-based proposal would likewise need to preserve the information.

"Request-URI vs. Loose-Route Mismatches:  As before: because the
      binding from AOR to Contact URI is under complete control of the
      requestor, and because the model of proxy/registrar routing
      defined in RFC 3261 is maintained, the system exhibits the same
      properties as it would if each user were registered individually.
      Loose routing and Request-URI handling are kept consistent with
      proxy/registrar handling described in RFC 3261, so no mismatches
      can arise."
[JRE] I am not sure that we necessarily need all properties to the same as if each user were registered separately, but it is certainly important that an inbound request correctly identify the target AOR. So I don't see this as being different from the previous point.

"Authorization Policy Mismatches:  Because the binding from AOR to
      Contact URI is under control of the publisher, it can ensure that
      the Contact URI associated with an AOR matches the Contact URIs it
      uses for outgoing calls.  This eliminates the authorization policy
      mismatches described."
[JRE] Any proposal that allows one contact URI per AOR would get around this problem.

"P-Asserted-Identity Mismatches:  Because the information published by
      this mechanism inherently mimics individual registration for each
      of the associated AORs, the expectation that each of these AORs
      can be used as a P-Asserted-Identity is preserved, avoiding any
      implementation confusion regarding valid values for this field."
[JRE] Ditto.

"Trust Domain Mismatches for Privacy/Identity:  The MARTINI working
      group appears to be reaching rough consensus that this issue is
      out of scope and out of charter for solutions it is responsible
      for considering.  It is not analyzed with respect to the proposed
      solution."

John

---

From: <[email-masked]>
Date: Mon, 25 Jan 2010 17:35:42 +0100

> [JRE] I would agree with removing it from the response, but I 
> doubt the need to include it in the request - see previous point.
> 

You may remove it from the interface between the SSP's edge proxy and
the PBX but not between the registrar and the SSP's edge proxy.
Otherwise you rule out the "untrusted model" as the edge proxy will be
unable to assert identities in this case.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 25 Jan 2010 11:02:47 -0600

(as co-chair)

To John,

Thanks for walking through these points - it's helpful.

(as individual)

To all, but especially to Adam,

I've heard two assertions offlist that I wanted to bring on-list before 
tomorrow's call, so that people have a chance to check their own 
products/networks, think, and perform other active verbs, before we talk...

Someone pointed out to me that using SBCs to drop traffic that doesn't 
correspond to an active registration is a fairly widespread practice for 
providers who support small PBXs today. If this is the case, we would be 
creating a dependency that this filtering change if we use a solution based 
on PUBLISH, Dean's proposed RUPDATE, etc.

Someone pointed out to me that carriers special-case avalanche restart 
procedures for REGISTER. Again, this would have to change if we adopt a 
solution based on PUBLISH, Dean's proposed RUPDATE, etc.

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 12:31:36 -0600

> [JRE] Any proposal that allows one contact URI per AOR would get around this problem.

Yes, it would. And, as you point out, it solves other problems as well. 
In fact, this one property itself makes the majority of the problems in 
the mixing-problems draft pretty much disappear.

While I still think we have problems with using REGISTER for multiple 
users (see Dean's message regarding the security properties of doing 
so), simply taking the approach in martini-shaken and adding the regex 
approach from martini-up goes a long way towards making the entire set 
of issues far more tractable.

/a

---

From: Richard Shockey <[email-masked]>
Date: Mon, 25 Jan 2010 14:09:50 -0500

On 1/25/2010 1:31 PM, Adam Roach wrote:
> Yes, it would. And, as you point out, it solves other problems as 
> well. In fact, this one property itself makes the majority of the 
> problems in the mixing-problems draft pretty much disappear.
>

But would it deploy?  This IMHO is the larger issue with the regex 
concept in PUBLISH ( though it has considerable merit) is that it will 
probably break other provisioning systems in existing SSP networks.

Everyone ...myself included would have supported the PUBLISH method if 
it had been proposed 6 years ago..but we didnt know what was going to 
actually happen as smaller PBX systems connected to SSP's.

The Option-Tag in shaken has the simple elegance of actually making the 
semantics of the implicit REGISGTER  message actually match what is in 
the field now and reduce well known interoperability problems that have 
arisen from a lack of a "explicit" tag informing the  SSP proxy what 
this message is actually trying do.

I do not accept the argument that Ben and others made that if you have 
to open up the code base of SSP proxy's to accept the Option Tag you 
might as well just do PUBLISH. I'm convinced that it is not that simple 
at all especially if the requirement is new code to implement the regex.

But I will leave it to representatives of SSP's to comment on that 
directly, because in the final analysis its the SSP that will have to 
live with the MARTINI solution.

I still wish folks would understand the underlying business issues that 
have driven folks to this point in the discussion.

-- 
Richard Shockey
Shockey Consulting
Chairman of Board SIP Forum
Voice +1 703 593 2683
Skype etc : rshockey101

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 13:27:48 -0600

On 1/25/10 1:09 PM, Richard Shockey wrote:
>
> I still wish folks would understand the underlying business issues 
> that have driven folks to this point in the discussion.
>

I fully understand how we got here. But MARTINI was not set up to 
endorse a pre-existing practice as-is. I'm sure there are organizations 
in this space that would be happy to rubber stamp vendor solutions 
without proper technical vetting. We're not that.

I'm going to assume that the fact this landed in the IETF's lap is an 
indication that the interested parties are seeking some level of IETF 
imprimatur that the resulting technique is consistent with the remainder 
of the protocol, and free of major security errors.

The deployed techniques don't qualify. The approaches simply have 
fundamental flaws that are too profound to paper over with an option 
tag. I can appreciate the expedience of addressing foundation problems 
by caulking the cracks in the walls, but also recognize that you've done 
nothing to solve the underlying problems when you do so.

You're effectively arguing that we need to ratify hodgepodge solutions 
developed in the field or risk being ignored on this topic. I think 
we're better off risking being ignored if the only other option is 
blindly ratifying broken protocol extensions. Being ignored on this 
topic may yield irrelevance on this one topic; ratifying broken 
solutions leads to permanent irrelevance on all topics from now on.

/a

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 13:52:56 -0600

On 01/25/2010 01:09 PM, Richard Shockey wrote:
> might as well just do PUBLISH.

Don't get hung up on martini-up's proposal to use PUBLISH. While it does 
solve a very real class of problems, that one relatively minor aspect of 
the draft is not the most important mechanism it proposes. The majority 
of the problems it solves involve the explicit signaling of AORs in the 
request, the definition of a mechanism that enables "one contact URI per 
AOR," and the congruence with previous uses of REGISTER by employing 
"contact routing" instead of "domain routing."

/a

---

From: Richard Shockey <[email-masked]>
Date: Mon, 25 Jan 2010 17:17:52 -0500

> endorse a pre-existing practice as-is. I'm sure there are 
> organizations in this space that would be happy to rubber stamp vendor 
> solutions without proper technical vetting. We're not that.

This is not a vendor specific solution. I did not think that existing 
3GPP or TISPAN documented practice on implicit registration would 
qualify as rubber stamping.  That remark is frankly a bit insulting even 
considering its source.

> imprimatur that the resulting technique is consistent with the 
> remainder of the protocol, and free of major security errors.

To be blunt we needed the Option Tag which requires a RFC.  The use of 
this methodology is IMHO consistent with 3261 and others on this list 
also believe that as well.  In thousands of field deployments there have 
been no reported security issues .. confusion ..yes certainly .  My 
principal concern at this moment is can the regex actually do what it is 
proposed to do and could be reasonably adopted by the relevant vendors 
and SSP that would use that even you are admiting that a REGISTER 
procedure properly defined would work.

It is perfectly fair and reasonable to ask if a proposed IETF solution 
will actually deploy. In SIP and countless other instances there have 
been RFC adopted and no deployments due to a lack of proper 
understanding of actual operational conditions especially OSS/BSS issues 
those RFC's address.

>
> The deployed techniques don't qualify.

I beg to differ. There is nothing wrong with the IETF adopting existing 
practice based on real  field experience or incorporating it into the 
over all architecture if it can be demonstrated to work correctly. As it 
is now it does work but not as well as it should. Thats why we are 
having this excersise.   You refuse to admit the possibility that a 
radical solution could be ignored. Humm sort of like health care reform?

> The approaches simply have fundamental flaws that are too profound to 
> paper over with an option tag. I can appreciate the expedience of 
> addressing foundation problems by caulking the cracks in the walls, 
> but also recognize that you've done nothing to solve the underlying 
> problems when you do so.

I just view the issue differently there is a problem in the field that 
needs to be fixed and fixed fast..there is a much larger issue of data 
provisioning in SIP networks that the IETF SIP community is not 
addressing correctly,  hence this problem and many more to come. I 
certainly agree there is a much larger problem here that all of us have 
essentially created but is this the right time to tackle that meta problem.

> solutions leads to permanent irrelevance on all topics from now on.

Well again I totally reject your contention that its "broken" or that 
shaken would some how "break" SIP that is just rhetoric.  What we have 
now is some what cracked certainly but if the cure is worse than the 
disease than we haven't solved anything.

---

From: David Hancock <[email-masked]>
Date: Mon, 25 Jan 2010 16:57:42 -0700

Spencer,

Regarding your second question below on avalanche restarts...

One of the reasons SIP Service Providers prefer a registration-based approach is that it is built on a well-proven SIP mechanism that has been tuned to support millions of users. From the SSP's perspective it's much less risky to reuse an existing mechanism that's had the benefit of years of incremental improvements in real-world deployments, than to go with a new & unproven mechanism -- especially when the new mechanism basically does the same thing (binds AoRs to location). 

For example, our PacketCable specifications mandate some "value add" procedures for registering endpoints (including registering IP-PBXs) to support the following:
 - minimize network overload when a large number of endpoints need to register simultaneously (avalanche restart)
 - minimize the service outage when a component in the registered service-route/path fails (e.g., the currently assigned edge-proxy fails)

RFC3261 is pretty light on these procedures. Here's a sample of text from section 10.2.7...

------ RFC3261 section 10.2.7 ------

   If the transaction layer returns a timeout error because the REGISTER
   yielded no response, the UAC SHOULD NOT immediately re-attempt a
   registration to the same registrar.

      An immediate re-attempt is likely to also timeout.  Waiting some
      reasonable time interval for the conditions causing the timeout to
      be corrected reduces unnecessary load on the network.  No specific
      interval is mandated.

------ RFC3261 section 10.2.7 ------

The following is a sample of additional endpoint procedures mandated in PacketCable specs to support avalanche restart and to minimize service interruption on SP network failure.

Protect network from avalanche restart:
PacketCable specifies that when repeated initial registration attempts fail (say due to no response, or on failure response 4xx (except 401, etc), 5xx, 6xx response), the endpoint must implement an exponential backoff delay using an algorithm similar to that specified in section 4.5 of the Outbound RFC. The Service Provider can configure the base-time and max-time values so they're tuned to meet the specific needs of the network. The SP network can also send a Retry-After header to override these backoff delay intervals, if needed. 

Minimize service outage:
A PacketCable SIP endpoint is configured with the FQDN of the edge-proxy in the SP network that it must use to gain access to the network. The endpoint resolves this FQDN to multiple IP addresses via DNS, and selects one of the IP addresses to establish a TLS session and register with the network (the network authenticates the REGISTER request, etc). All SIP messages between the network and SIP endpoint are sent over the established TLS session. If the endpoint receives a failure on a subsequent registration refresh attempt (4xx (except 401), 5xx, 6xx, Timer-F) it releases all resources associated with the existing (now failed) registration, and attempts to register again via a new edge-proxy IP address, using the backoff procedure described above. 

Additional registration procedures are mandated for the core network components (e.g., spreading the registration load across multiple S-CSCFs, etc). Plus, local operator policy may dictate additional special procedures to support these use-cases. These procedures would obviously not apply as specified to a PUBLISH-based approach. Since we haven't described the mechanism in detail, it's not clear to me if/how these procedures would apply if the martini-up solution is carried in a REGISTER request, instead of PUBLISH. 

Thanks
David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Spencer Dawkins
> Sent: Monday, January 25, 2010 10:03 AM
> To: Elwell, John; [email-masked]
> Subject: Re: [martini] Evaluation of issues solved by martini-up
> 
> (as co-chair)
> 
> To John,
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Adam Roach <[email-masked]>
Date: Mon, 25 Jan 2010 18:02:43 -0600

On 1/25/10 4:17 PM, Richard Shockey wrote:
>> organizations in this space that would be happy to rubber stamp 
>> vendor solutions without proper technical vetting. We're not that.
>
> qualify as rubber stamping.

How is showing up at the IETF with a solution and refusing to compromise 
on any of the details of that solution while seeking an RFC number 
anything but that? Regardless of the pedigree of the solution (and we've 
tried to explain how this proposal differs materially from 3GPP implicit 
registration, so that hardly applies anyway), it's asking for an 
endorsement without accepting input. You can call it whatever you want 
-- ratification, rubber stamping, blind publication -- but it's not my 
understanding of how the IETF works.

> To be blunt we needed the Option Tag which requires a RFC.

The _reason_ an option tag requires an RFC is to ensure that the 
corresponding solution has had proper review by experts inside the IETF. 
I've been at this long enough and have contributed enough to this 
protocol overall that I am bold enough to consider myself in that 
category. I don't claim to be any kind of final authority on the topic, 
but you'll notice other people who have the proper credentials to hold 
themselves out as experts as well are objecting to the solution brought 
to us also, most of them for the same reasons -- or at least a subset of 
the reasons -- that I've pointed out myself.

> I beg to differ. There is nothing wrong with the IETF adopting 
> existing practice based on real  field experience or incorporating it 
> into the over all architecture if it can be demonstrated to work 
> correctly.

It works correctly in certain architectures. It breaks in others. It has 
some rather severe security shortcomings that Dean has gone through the 
trouble of detailing. These won't show up in most walled gardens, but 
they can cause real problems in public networks. It creates an 
alternative system to name resolution other than DNS, which runs counter 
to stated IAB and ICANN positions on the topic. It pretty much destroys 
any chance of getting GRUUs to work through PBXes, which eliminates 
entire classes of cross-domain services. This list is not exhaustive: 
there are a host of issues -- technical, architectural, and political -- 
that make the solution that was brought to the IETF inadvisable. Just 
because it works in certain architectures under certain circumstances 
does not mean that we can sign off on it for general use on the Internet.

And, frankly, if the IETF used "working existing practice" as its sole 
criteria, we would have slapped an RFC number on CU-SeeMe's audio-video 
protocol back in 1994 and called it a day.

/a