[SIPForum-techwg] IP PBX / SP Interop Draft Version 5 proposed edits

[Rohan Mahy]

Hi,

On Mar 3, 2006, at 22:16, Hadriel Kaplan wrote:
> My apologies for the length of this email.  :(
> I'm trying to be clear because I'm not sure we disagree totally.
>
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan at ekabal.com]
>> Please motivate this statement.  Under what circumstances can a 
>> service
>> provider or enterprise intermediary safely modify the SIP body when 
>> any of
>> the conditions I mentioned are satisfied?  (For example, if an 
>> Identity
>> header is present, modifying the body or the contact will cause a UAS
>> supporting Identity to reject the request.)
>
> Sorry, I think we may be crossing signals - I wasn't saying identity or
> S/MIME would *work* if an intermediary modified things.  Obviously 
> there is
> no condition under which any hop can modify those and have it "work".

OK, glad we agree on that point.

> My real problem is for the last 2 conditions: "all the c= lines 
> containing
> public IP Addresses" and the candidate lines one - changing contacts 
> and
> body contents will work under those conditions (safely) and does every 
> day
> (well not done for ice since no one does ice).

Would you be satisfied if the draft said a SIP intermediary (SIP proxy 
or B2BUA) MUST NOT modify IP addresses or port numbers in the body of a 
SIP message meeting one of these 2 last conditions?  (As opposed to the 
entire body?)

> Perhaps I'm reading into your phrasing too deeply, but it seemed as if 
> you
> were implying intermediaries cannot reject messages meeting the other
> constraints.

No, intermediaries are allowed to reject messages for a variety of 
reasons.  Its modifying and then forwarding that is problematic.

> For the identity and S/MIME cases, I would fully agree
> intermediaries MUST reject such messages if they would otherwise 
> modify the
> contact or body.  Would you agree with that wording?

No.  Providing guidance to reject these messages out-of-hand definitely 
conflicts with our charter (and IETF documents).  We simply cannot 
recommend that.  Generally speaking, a proxy or B2BUA really should 
just forward these messages along.  If a User Agent wants to reject the 
request because it cannot decipher a required body part, there is a 
response code in RFC 3261 for that. As for codec filtering, the whole 
purpose of this spec is to allow a PBX to contact the PSTN through an 
SP gateway. The service provider can trivially restrict which codecs to 
use at the gateway itself and can monitor the actual codecs used.  We 
are not concerned with policing some pre-paid 3G mobile user here.

I have one last comment on codec filtering.  Either the UA is willing 
to cooperate with the SP or it isn't.  In the case the UA is 
cooperating, it will use "legal" codecs.  If the UA is not willing to 
cooperate, it can freely collude with another UA to lie about its 
codecs in the SDP.  If the call isn't going through at least one 
endpoint trusted by the SP, the only way to test for this is by 
policing the actual media stream.  In other words, codec filtering is 
unnecessary in the cooperating case and ineffective in the 
non-cooperating case.

> Part of that confusion may be because it's also not clear what you 
> mean by a
> "SIP Intermediary", and where it is in the network.  Is a B2BUA an
> intermediary?  (I assumed so)

yes.  that was my intent.

> If the SIP request goes to a media gateway,
> then PSTN to another media gateway, then SIP to the final user - are 
> the
> media gateways intermediaries?

no

> What about if the PSTN was a loopback cable?

no

> Or what if a SIP request goes to a "PBX" which controls a phone using 
> some
> proprietary protocol, and one day the proprietary protocol is changed 
> to SIP
> - does the "PBX" now become an intermediary?

no
We are concerned with a particular SIP request from the time it leaves 
the Enterprise until it arrives at the UAS the represents the 
Request-URI.

>> The charter of this group _*REQUIRES*_ us to "do no harm" and protect
>> interoperability of current and *planned* IETF work.
>
> I didn't see those words on the website, but it's certainly laudable.
> Wouldn't rejecting messages which contain elements which are not 
> supported
> be compliant with that?

No.  There are Megabytes of discussion on the SIP and SIPPING mailing 
list that boil down to the consensus that SIP intermediaries should be 
as transparent as possible with respect to the "real" UAC and UAS.  If 
you don't understand an optional extension, get out of the way.  If the 
"real" UAS doesn't understand, it can reject the message itself.

> I'm not suggesting we say intermediaries MUST change anything, or even 
> MAY.
> But this is an interop spec for specific services, with listed goals 
> of:
> "-Define a reference architecture that sets forth the common network
> elements necessary for service provider to IP PBX peering.
> -Specify the basic protocols (and protocol extensions) that must be
> supported by each element of the reference architecture.
> -Specify the exact RFCs or other existing standards associated with 
> these
> protocols that must or should be supported by each element of the 
> reference
> architecture."
>
> So it sounds like the goal is to define what services, and what's 
> needed for
> those services to work.  Not also a list of all other services and 
> what's
> needed for those to work.

The service is delivering calls between an Enterprise and a SP PSTN 
gateway. Codec filtering is not one of those required services.

One of the requirements is that each side present IP addresses which 
are publicly accessible.

>>  The IETF already
>> recommends stronger language damning the practice of body 
>> modification.
>
> But that's the rub.  Some devices MUST modify the contact header, and 
> the
> body for a lot of reasons.

Lets take these one-by-one.

> Some of them have to do with NAT issues,

If a previous SIP element bothered to use public address in a c= line, 
use ICE, Identity, or S/MIME, the nodes before you have indicated a 
high degree of competency and standards awareness and are implicitly 
agreeing to handle the NAT issues on their own.  THEY DO NOT NEED YOUR 
HELP, thank you very much.   You cannot possibly make things better.  
If someone sends your SBC private addresses, I do not object to you 
modifying the message.  My language does not prevent that.

> some of them have to do with security issues,

The whole purpose of SMIME and Identity are to provide better security. 
  If I bothered to include SMIME or Identity in my message, you can't 
make the security better.

> some of them have to do with legal compliance issues,

Neither Identity nor multipart/signed prevents a Service Provider from 
satisfactorily complying with any legal requirement that has ever been 
mentioned on the SIP or SIPPING mailing list.

As for SMIME encryption, many jurisdictions including the US only 
require the SP to provide information that they have.  In these areas, 
there is no legal requirement to prevent two user agents from 
exchanging SMIME encrypted messages that you cannot read.  In other 
jurisdictions, I do not object to a B2BUA responding with a 493 
Undecipherable if it cannot read an SMIME *encrypted* message that it 
is legally required to read. My proposed language does not prevent 
that.

> and some of them have to do with fixing interoperability issues.

The whole purpose of this document is to fix interoperability issues.

> (there are other reasons, but those are the obvious ones)  Again,
> it's not that they want to do it - they have to.  Telling them not to 
> is
> like telling firewall vendors to stop making their NATs symmetric and 
> go
> conical instead.

Please re-read the terminology section in RFC 3489.  It should only 
take about 3 minutes.  Now that you have done that, I will point out 
that there is NO SECURITY BENEFIT to running a symmetric type NAT or 
firewall compared to a port-restricted cone, however there is a huge 
INTEROPERABILITY BENEFIT to running as a port-restricted cone.  A 
datagram still has to originate from the inside to the exact address 
and port.  Many vendors have realized this and have changed their 
implementation.

> Or telling home gateway vendors to stop NATing at all,
> because the IETF doesn't like it and they could use IPv6 for more 
> addresses
> instead.

whatever.

>> My proposal is much more specific and implicitly allows body 
>> modification
>> in every case I can imagine where it is even remotely useful.
>
> It is a common misconception that intermediaries only modify message 
> bodies
> to fix NAT traversal issues.  That may be true in the enterprise 
> space, but
> is completely false in the service provider space.  The top 3 or 4 SBC
> vendors are deployed in more than 500 service providers combined.  At 
> least
> 50% of that is for non-NAT-traversal applications, including enterprise
> access.  I can't speak for the others, but we're able to modify or not
> modify message bodies based on the operator's configuration wishes, 
> and the
> number of them that don't wish to or don't have to modify bodies is 
> very
> small.  And the reasons are not due to technical limitations of SBCs.

I believe I also addressed all the other reasons you mentioned in this 
email.

>> Please
>> consider this when accusing me of causing an interoperability problem.
>
> I am not accusing you of anything, nor did I mean it in a nasty tone. 
> (sorry
> if it came off that way - email has that problem)  What I was doing was
> saying I disagree with adding that section because it defines 
> behavior, for
> an undefined box type, for conditions which do not occur in the defined
> services of the spec.
>
> I believe it will cause interop problems - in the sense that it implies
> certain mechanisms will be supported and work (S/MIME, identity) when 
> they
> will not.  They'll be "interoperable" in the sense that they will 
> follow
> IETF rules to be rejected, but not work from a consumer's service
> perspective. (maybe you meant the former, I meant the latter)
>
> They will also cause interop problems in the sense that were an 
> intermediary
> to follow the rule and not modify in those conditions, the service 
> will fail
> in some cases.  For example, if a request from a sip-connect compliant
> enterprise has candidate lines, and gets forwarded through the service
> provider to a home user who's NAT traversal is being fixed by the 
> service
> provider's SBC, then if the SBC does not change the SDP IP info (which 
> was
> public and correct and has candidate lines), the call will fail almost 
> every
> time.

This is an excellent example.  Fortunately your analysis is incorrect.  
The SDP provided by peer A has ICE candidate lines.  The SDP provided 
by peer B does not.  An SBC following my proposed rules would modify 
the SDP provided by peer B to have public IP addresses and would leave 
SDP A alone.  A working audio path would follow.

> But had the SBC done its normal thing, the call would have succeeded.

If the SBC modified candidate lines, its quite likely that the call 
would fail.  If you'd like I can probably dig up a trace of such a 
case.

thanks,
-rohan