[Stox] AD Evaluation of draft-ietf-stox-7248bis-05

"Ben Campbell" <ben@nostrum.com> Tue, 22 September 2015 03:25 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FCF1A879A; Mon, 21 Sep 2015 20:25:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level:
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sZ0M4BqOeNa; Mon, 21 Sep 2015 20:25:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102BB1A8798; Mon, 21 Sep 2015 20:25:13 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t8M3P10r041907 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 21 Sep 2015 22:25:11 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: draft-ietf-stox-7248bis.all@ietf.org, stox@ietf.org
Date: Mon, 21 Sep 2015 22:25:01 -0500
Message-ID: <CC605F0B-9B8E-4FE0-9DEC-79A3E1162ED5@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/sP3VbStoYS_BVcnA_wj-o3pd_YU>
Subject: [Stox] AD Evaluation of draft-ietf-stox-7248bis-05
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2015 03:25:18 -0000

Hi,

This is my AD evaluation of draft-ietf-stox-7248bis-05

Summary:

This is not quite ready for IETF last call. There are a number of SIP 
errors in the examples, and I think we need some more text to discuss a 
potential privacy issue. There's some questionable use of 2119 keywords, 
and a few other comments.  Details follow.

Thanks!

Ben.

-- Privacy:

I'm concerned that a naive implementation of the gateway could allow an 
XMPP user to see presence information for a SIP user that they were not 
authorized to see. The issue is that SIP allows a presentity to send 
different presence information to different subscribers. For example, if 
alice@xmpp.example.com and bob@xmpp.example.com both subscribe to 
sip:carol@sip.example.net, what if Carol wants to tell Alice that she is 
available, but Bob that she is not? (This is allowed in SIP.) Can we be 
sure the gateway won't take presence intended for Alice and also send it 
to Bob?

I think this is an issue, since if I understand things correctly, an 
XMPP presentity typically sends one presence stanza to her server, and 
that server distributes it among her subscribers. I _think_ this can 
work as long as we make sure the gateway sends each presence stanza 
directly to the subscriber that was targeted by the SIP Notify, and 
never mixes them up. But I think we need some text to describe the issue 
and give guidance on how to do the Right Thing.

-- 2119 Keywords.

There's quite a number of 2119 keywords used to describe existing 
normative SIP and XMPP behavior. Those should be written in descriptive 
language, or very clearly attribute the authoritative source. (There are 
a few attributed keywords, but many are not.)

-- section 4, 1st bullet:

"Instead of forwarding a SUBSCRIBE message to the SIP user, the Presence 
Server and SIP User Agent would interact via the ’presence.winfo’ 
event package"

This is only true if the presentity has not already setup policy to 
allow the subscriber to subscribe. Typically, this happens on the 
initial subscription, and future subscriptions may not require the 
presence.winfo interaction.

"The SIP User Agent would then authorize the subscription through..,"

Typically, the user agent persistently authorizes the _subscriber_. 
(Remembering that in SIP the subscription is ephemeral. )

-- Example 2:
The "To" tag should not exist on the first request in a dialog. The tag 
value is learned from the SIP Response (200 OK in this example). The UAC 
does not know the tag value at the time of the initial SUBSCRIBE 
request. (Note that this repeats in later examples)

-- Example 3:
The From and To values are swapped. Remember that a SIP _response_ uses 
the exact same From and To as in the request. (Except for adding the To 
tag in a response to a request that did not contain one.) (Note that 
this repeats in later examples.)

-- Example 4:

The Request-URI should match the Contact header field value from the 
SUBSCRIBE. (Technically, from the last message from the peer, but 
assuming you don't have them change contacts mid-stream, it's the same.) 
You also might want to consider whether the aforementioned contact 
values are useful examples. (Repeats in later examples)

-- 5.2.3

The flow and message details are missing the final SIP NOTIFY request.

-- Example 8:

The request-URI should match the peers Contact field value.

-- Table 1:
- I think this could use some more text around what happens if you have 
multiple XMPP resources, or a SIP presentity sends multiple tuples. The 
note discusses how to map the resource identifier to the tuple id, but 
not much about what it means to have multiple of either.

- I don't think it's correct to try to map CSeq. That's an artifact of 
the SIP state machine that seems
meaningless to the XMPP side. (Same for table 2)

-- 6.2, note 5:

The NOTIFY with a subscription state of "terminated" tears down the SIP 
subscription. Is that the intent? Why would the unavailability of the 
contact end the SIP subscription?

-- note 7:

Do you expect a SIP Presence UA to do something useful with the <show/> 
element ? Most will probably ignore it.

-- 9, 2nd paragraph:

"an XMPP-to-SIP gateway ought to be associated only with a single domain 
or trust realm"

Is this intended to discourage multi-tenant gateways? Does the existence 
of draft-ietf-xmpp-dna change that?

"... whenever an XMPP-to-SIP gateway seeks to refresh an XMPP user’s 
long-lived subscription to a SIP user’s presence, it MUST first send 
an XMPP <presence/> stanza of type "probe" ..."

I would have liked to see that discussed in the relevant procedures 
section(s).

-- Editorial Comments and nits:

-- 5.2.2, 2nd paragraph:

Technically, RFC 6665 doesn’t talk about “presence” subscriptions,
  but it does give the rules for SIP-events subscriptions in general. 
Should the citation be to 3856?

-- 5.3.1:
The flow leaves out the SIP responses. That's okay if it's on purpose, 
but it would be good to mention you are doing so. (especially since the 
previous examples showed them.)

- 2nd paragraph after example 10: "Request-URI or To header"
Shouldn't this just be the Request-URI?

-2nd paragraph after example 11:
This also needs a NOTIFY. You mention one in the following paragraph for 
the declined case, but you need one in either case.

-- 5.3.2, 1st bullet:
"will seem strange to the XMPPcontact"

Does the contact's human typically get notified of this?

- 2nd bullet:
This description is confusing. You aren’t maintaining the SIP 
subscription, just the xmpp subscription.

-- 2nd bullet, sub-item 2:

Do I understand this to mean the XMPP gateway infers availability of the 
SIP user from the SIP user’s subscription? That should come from a 
reciprocal subscription. Just because a SIP user subscribes to someone 
else's presence doesn't mean that user is available. Just because he 
doesn't doesn't mean he is not.

Also, how does this violate the SIP semantic?

-- 6.2:
7 and 8 seem mostly redundant—and there doesn’t seem to be a 
citation for 8 in the table.

-- 7:

This is about polling, right? It seems like polling and subscribing are 
just two ways to request presence info.