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

[Hadriel Kaplan]

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".  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).

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

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) 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?  What about if the PSTN was a loopback cable?
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?  

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

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 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.  Some of them have to do with NAT issues, some of
them have to do with security issues, some of them have to do with legal
compliance issues, and some of them have to do with fixing 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.  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. 


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


> 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.  But had the SBC done its normal thing, the call would have succeeded.

-hadriel