Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT)
Adam Roach <adam@nostrum.com> Fri, 01 March 2019 21:47 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECE1130F2C; Fri, 1 Mar 2019 13:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.669
X-Spam-Level:
X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
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 vSpRLRz9Lq5I; Fri, 1 Mar 2019 13:47:09 -0800 (PST)
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 15984130F3F; Fri, 1 Mar 2019 13:47:09 -0800 (PST)
Received: from Orochi.local (rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x21Lkxca015596 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 1 Mar 2019 15:47:01 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551476823; bh=6Kw04wI6EPGkMnVpXVIq6UOQExZAM7a5AdXzExTIq3E=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=oDtZDCNS2WnjUd7xucRh6qjI5NzIGvKYKWLd3LFbBbGA6gIcv2IgLTKq1V2yfhYOB 6Em/EH6pxIKwGxLw7/vf5otEz7zf/rrOADZf8HKYBCZQOBI9FGWM9/LfyofSrZ/011 N94uT6/svghn7HP6jEVKAJZlsFkLknBbpt0rxlpQ=
X-Authentication-Warning: raven.nostrum.com: Host rrcs-24-173-40-58.sw.biz.rr.com [24.173.40.58] claimed to be Orochi.local
To: Christer Holmberg <christer.holmberg@ericsson.com>, The IESG <iesg@ietf.org>
Cc: "draft-ietf-sipcore-sip-push@ietf.org" <draft-ietf-sipcore-sip-push@ietf.org>, Brian Rosen <br@brianrosen.net>, "sipcore-chairs@ietf.org" <sipcore-chairs@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>
References: <155146051337.6186.9467252084775433080.idtracker@ietfa.amsl.com> <HE1PR07MB31616FC1F5E8B496C5C14A9F93760@HE1PR07MB3161.eurprd07.prod.outlook.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <377b379d-3747-3748-694d-2c3fa621483b@nostrum.com>
Date: Fri, 01 Mar 2019 15:46:59 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB31616FC1F5E8B496C5C14A9F93760@HE1PR07MB3161.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------9D7DCED0AAB74BEBDD290DFC"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/NMLWcJOyidroruXOljNeMB872vw>
Subject: Re: [sipcore] Adam Roach's No Objection on draft-ietf-sipcore-sip-push-26: (with COMMENT)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2019 21:47:23 -0000
HI! I apologize if it was unclear from my preamble, but the original comments were only included because I wanted the document ballot to retain them for historical purposes. No reply was necessary. /a On 3/1/19 15:31, Christer Holmberg wrote: > > Hi Adam, > > > Thank You! > > > Your issues have been addressed. In this reply I more or less > copy/paste what I said in my previous reply to your review, and give > some extra details on how issues were solved. > > > ---------------------------------------------------------------------- > > COMMENT: > ---------------------------------------------------------------------- > > >It's nice that this document has considered the impact of inbound mid-dialog > >messages in long-lived dialogs. However, it appears to have a major > hole in it: > >handing of outbound messages for the purpose of maintaining > soft-state in those > >dialogs isn't handled correctly. > > > >In particular: networks that deploy this mechanism will cause SUBSCRIBE > >dialogs to time out and be destroyed while they are still in use. > >Additionally, if RFC 4028 (session timers) is negotiated, then INVITE > dialogs > >will suffer the same fate. > > > >I can think of a couple of ways for these situations to be handled, > but they > >need explicit text in the document. > > > >One approach would be to specify that the User Agent selects its > requested > >"Expires" value in its registration to be the smallest value before > its set of > >subscriptions and session timers needs to be refreshed. This would > cause a push > >notification to happen to prevent registration timeout, and the > client could > >refresh the other soft state at that time. Complications arise if the > registrar > >responds with a 483 (Interval too Brief), and we'd need to find a > solution for > >that. > > > >Another approach would be for the clients to refresh all soft state > whenever > >they send a registration, and set the timeout for that soft state to > be equal to > >or greater than the registration timeout. A complication could arise > if the > >notifier or the peer in an invite dialog shortens the requested time, > and we'd > >need to find a solution for that. > > > >A third approach would be getting the proxy involved in some way -- > either by > >requiring it to observe subscription and session timer timeouts and > requiring it > >to send push notifications prior to their expiration, or by an explicit > >communication between the UA and the proxy that indicates when the > next push > >notification should be scheduled. If the latter approach is taken, I > would > >suggest that it needs to be taken for REGISTER messages as well. > > > >I really don't think this mechanism is feasibly deployable without a > solution to > >this problem. > > This has been addressed, and the text in section 4.1.1 now says: > "This specification does not define a mechanism to explicitly request > push notifications from the SIP network for usages other than > triggering binding-refresh REGISTER requests (e.g., for sending > periodic subscription-refresh SUBSCRIBE requests [RFC6665]), nor does > it describe how to distinguish push notifications associated with > such usages from the push notifications used to trigger binding- > refresh REGISTER requests. If a SIP UA wants to use push > notifications for other usages, the UA can perform actions associated > with such usages (in addition to sending a binding-refresh REGISTER > request) whenever it receives a push notification by using the same > refresh interval that is used for the binding-refreshes." > > > --------------------------------------------------------------------------- > > §4.1: > > > For privacy and security reasons, the UA MUST NOT include the SIP URI > > parameters defined in this document in non-REGISTER request, to > > prevent the PNS information associated with the UA from reaching the > > remote peer. > > > >This seems to ignore the availability of Contact URI parameters via > RFC 3680 > >subscriptions. This would seem to impose a requirement on Registrars > to strip > >this information before making it available to any other party (which, in > >turn, requires that the system have explicit Registrar *and* Proxy > support). > >As far as I can tell, the system so far has not required explicit > proxy support > >(and there's certainly no mechanism built-in that ensures that a > proxy has any > >special handling regarding this mechanism). > > > >If the PNS information is sensitive, and cannot be allowed to leak out to > >other users, then we need some way to ensure the registrar has provided > >positive confirmation that it will not do so before allowing it to > come into > >possession of them. > > This has been addressed, and the text now says: > "For privacy and security reasons, a UA MUST NOT insert the SIP URI > parameters (except for the pn-purr parameter) defined in this > specification in non-REGISTER request in order to prevent the PNS > information associated with the UA from reaching the remote peer. > For example, the UA MUST NOT insert the pn-prid SIP URI parameter in > the Contact header field URI of an INVITE request. REGISTER > requests will not reach the remote peer, as they will be terminated > by the registrar of the UA. However, the registrar MUST still > ensure that the parameters are not sent to other users, e.g., using > the SIP event package for registrations mechanism [RFC3680]. See > Section 13 for more information." > Section 13 (Security Considerations) contains the following text: > "Operators MUST ensure that the PNS-related SIP URI parameters > conveyed by a user in the Contact URI of a REGISTER request are not > sent to other users, or to non-trusted network entities. One way to > convey contact information is by using the the SIP event package > for registrations mechanism [RFC3680]. [RFC3680] defines generic > security considerations for the SIP event package for > registrations. As the PNS-related SIP URI parameters conveyed in > the REGISTER request contain sensitive information, operators that > support the event package MUST ensure that event package > subscriptions are properly authenticated and authorized, and that > the SIP URI parameters are not inserted in event notifications sent > to other users, or to non-trusted network entities." > > --------------------------------------------------------------------------- > > §4.2: > > > The UA can do so by only including the pn-provider > > SIP URI parameter in the SIP Contact header field URI of the REGISTER > > request, but without including the pn-prid SIP URI parameter. > > > >Unless I'm mistaken, this is a barrier to interoperation. > > > >It's not 100% clear, but I suspect the intended implication is that the > >pn-provider parameter here will contain a single value? The syntax of the > >parameter certainly seems to imply that. This seems to be a pretty big > >problem, since it presupposes that the client will know which PNSes > the Proxy > >supports. Consider, for example, an iOS client that can use any of > RFC 8030, > >FCM, and APN (cf > https://firebase.google.com/docs/cloud-messaging/ios/client). > >If the client doesn't know a priori what the proxy supports (and this > entire > >section only makes sense if that's true), then it won't know which of > those > >three services to indicate in its REGISTER request. If it guesses > wrong, this > >mechanism simply fails. > > > >I think you need a different discovery mechanism here -- either have > one that > >has the client offering multiple PNS protocols and the proxy > responding with > >one, or have one in which the proxy indicates all of its supported > services in > >a response, and the client chooses one to use in its next REGISTER > message. > > This has been addressed in section 4.1.5 (Query Network PNS > Capabilities). The UA can now > choose to not include the pn-provider parameter, in which case the > network will return all > PNS protocols supported. > > --------------------------------------------------------------------------- > > >Figure 1: > > > >This diagram includes both a ladder diagram and an example REGISTER > message. > >While both of these are useful at this point in the document, neither > of them is > >an "Architecture," and they're really two different things. I suggest > breaking > >this into two Figures, entitled "Typical Information Flow" and > "Example REGISTER > >Message" (or similar), respectively. > > This has been addressed as suggested in Section 1 (Introduction). > > --------------------------------------------------------------------------- > * > §4.1: > > > As long as the UA wants to receive push notifications (requested by > > the proxy), the UA MUST include a pn-provider, pn-prid and a pn-param > > (if required for the specific PNS provider) SIP URI parameter in each > > binding-refresh REGISTER request. > > > >Please be clear that these parameters appear in the Contact URI. > > Eventhough the text above does no longer exist, it has now been > generally clarified that the parameters appear in the Contact URI. > > (I did note a bug in section 4.1.2. I says "UA MUST include", but it > shall be "UA MUST NOT include") > > --------------------------------------------------------------------------- > > §5.2: > > > In order to request push notifications towards a SIP UA that will > > trigger the UA to send binding-refresh SIP REGISTER requests, the SIP > > proxy needs to have information about when a registration will > > expire. The proxy needs to be able to retrieve the information from > > the registrar using some mechanism. Such mechanisms are outside the > > scope of this document, but could be implemented e.g., using the > > SIPregistration event package mechanism [RFC3680]. > > > >Nit: "SIP registration" > > Has been fixed. > > >This mechanism seems to be predicated on an architecture in which the > proxy must > >be on the traffic path. Although it's problematic from a "what > proxies are > >expected to do" perspective, it seems like the proxy could glean this > >information from the 200 response to the REGISTER request. (I mean, > the proxy is > >already reading parameters out of the contact header field, so the > behavior of > >acting on registration information is already assumed). The proxy > would, of > >course, need to run its own timers, but that seems to be a pretty minor > >requirement, given everything else involved here. > > When I previously replied to your COMMENT, I said the following: > > "One way to implement the "retrieve the information from the > registrar" could of course be using own timers. > But, I don't think we should specify such behavior. > > Also, in some cases the proxy might be co-located with the "home > proxy", or some other network node, > where the interface with the registrar already exists." > > No changes were done based on the comment. > > --------------------------------------------------------------------------- > > §5.3.1: > > >This is a major comment, and one that has a sufficient impact on > interop that I > >had a long debate with myself about whether it should be a DISCUSS. > Please take > >it very seriously. > > > > Otherwise, if the pn-provider SIP URI parameter identifies a type of > > PNS that the proxy does not support, or if the REGISTER request does > > not contain all additional information required for the specific type > > of PNS, the proxy MUST either forward the request (e.g., if the proxy > > knows that another proxy that will receive the REGISTER request > > supports the type of PNS)... > > > >How would the proxy know this? > > In the previous reply, I said "local configuration". > > It has been clarified in the text, and the text in section 5.6.1.1 now > says: > > "If the proxy knows (by means of local configuration)" > >Features like suppressing PNS behavior when a "sip.pns" feature > capability is > >present in the REGISTER imply that the various nodes in the network > discover > >capabilities of their neighbors automatically (which is consistent > with the way > >SIP does features), while this provision seems to require provisioned > knowledge. > >This is going to be operationally very confusing. > > > >At the very least, the document needs to call out how this "knowledge" is > >obtained. In the more general sense, since a client cannot rely on > the proxy > >supporting *any* kind of PNS, the use of 555 in the way specified > here is at > >best an optimization -- and, since the configured information can > conflict with > >actual reality, it's an optimization that can actually break things > unless > >extreme care is exercised. (e.g., if the proxy is configured to > "know" that the > >next proxy cannot provide push service, but this knowledge is wrong, > then the > >network is unnecessarily broken.) > > > >My rather strong recommendation is to remove this code, and let the > client rely > >on the lack of indication of support in the response indicate that > the feature > >is not supported. > > In my previous reply I said: > > "I would like to keep the code, because there are cases where one > wants the register to be rejected > (rather than accepted, but without indication of supported PNS) if the > PNS is not supported. > > Also, there are already deployments of 555, so I'd prefer to keep it, > as it doesn't break anything." > > The 555 response code has been kept, and regarding the proxy knowing > it was clarified that it is based on local configuration (see above). > > --------------------------------------------------------------------------- > > §5.3.1: > > > o if the proxy received a 'sip.pnsreg' media feature tag in the > > REGISTER request, the proxy SHOULD include a 'sip.pnsreg' feature- > > capability indicator with an indicator value bigger than 120 in > > the response, unless the proxy always want to request push > > > >Nit: "...wants..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §5.3.2: > > > If the contact of the REGISTER request does not match > > the Request-URI of the SIP request to be forwarded, or if the contact > > was not present in the REGISTER response, the proxy MUST reject the > > SIP request with a 404 (Not Found) response. > > > >This seems to be a very strong requirement ("MUST") when, e.g., many > or most > >networks may want to return a 480 instead of a 404. I think what you want to say > >is something like "...MUST reject the SIP request. Response codes of > either > >404 (Not Found) or 480 (Temporarily Unavailable) are RECOMMENDED, but > other > >appropriate codes may be used as well." > > This has been addressed with the following text: > > "It is RECOMMENDED that the proxy sends either a 404 (Not > Found) response or a 480 (Temporarily Unavailable) response to the > SIP request, but other response codes can be used as well." > > --------------------------------------------------------------------------- > > §5.3.2: > > > The reason the proxy needs to wait for the REGISTER response before > > forwarding the SIP request is to make sure that the REGISTER request > > has been accepted by the registrar, and that the UA which initiated > > > >Nit: "...the UA that initiated..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §5.3.2: > > > In case of non-2xx response to the REGISTER request, the proxy MUST > > reject the SIP request with a 404 (Not Found) response. > > > > If the push notification request fails (see PNS-specific > > documentation for details), the proxy MUST reject the SIP request > > with a 480 (Temporarily Unavailable) response. > > > > If the proxy does not receive the REGISTER request from the UA within > > a given time after the proxy has requested the push notification, the > > proxy MUST reject the request with a 480 (Temporarily Unavailable) > > response. The time value is set based on local policy. > > > >As above, this seems way too restrictive in terms of mandating > specific error > >codes. It may well be the case that a network would want to treat these > >situations identically from the perspective of the calling party. > > Has been addressed (see above). > > --------------------------------------------------------------------------- > > §5.3.2: > > > Otherwise the > > proxy MUST reject the SIP request with a 480 (Temporarily > > Unavailable) response. > > > >Same comment as above. > > Has been addressed (see above). > > --------------------------------------------------------------------------- > > §6.1.1: > > > When the UA sends in initial request for a dialog, or a 2xx response > > > >Nit: "...sends an initial request..." > > Has been fixed. > > > purr' SIP URI parameter in the Contact header of the request or > > > >Nit: "...Contact header field..." > > Has been fixed. > > > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > > > >Nit: "...given dialog..." > > Has been fixed. > > > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > > header of the request or response for each dialog in which the UA is > > > >Nit: "...Contact header field..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §6.1.1: > > > The UA MUST include a parameter value identical to the the > > last 'sip.pnspurr' feature-capability indicator that it received in a > > REGISTER response. > > > >This is incredibly confusing, as the "sip.pnspurr" indicator has not been > >mentioned in the document so far. Please revise as something along > the lines of: > > > > The UA MUST include a parameter value identical to the the last > > 'sip.pnspurr' feature-capability indicator (see Section 6.2.1) that it > > received in a REGISTER response. > > > >Alternately, reverse the order of sections 6.1 and 6.2 so that the PURR > >concept is properly introduced before protocol procedures are defined > for it. > > This has been addressed, by adding a reference to Section 6.2.1. > > --------------------------------------------------------------------------- > * > §6.1.1: > > > NOTE: As the 'pn-purr' SIP URI parameter only applies to a give > > dialog, the UA needs to include a 'pn-purr' parameter in the Contact > > header of the request or response for each dialog in which the UA is > > willing to receive push notifications triggered by incoming mid- > > dialog requests. > > > >Similar to the above, this is a very confusing introduction of the > "pn-purr" URI > >parameter. > > I realized this has been fixed in the wrong section. I will fix that > by adding a reference to Section 6.2.1. > > Note, though, that the first occurrence of 'pn-purr' SIP URI parameter > is in the first paragraph of section 6.1.1, so I will add the > reference there. > > --------------------------------------------------------------------------- > > §6.2.2: > > > Contact header field with a PURR value that the proxy has generated > > Section 6.2.2, the proxy MUST add a Record-Route header to the > > request, to insert itself in the dialog route [RFC3261]. > > > >This "Section 6.2.2" makes the sentence impossible to read. Is it > intended to be > >in parentheses? > > Has been fixed. > > --------------------------------------------------------------------------- > > §6.2.3: > > > As described in Section 5.3.2, while waiting for the push > > notification request to succeed, and the associated REGISTER request > > to arrive from the SIP UA, the proxy needs to take into consideration > > that the transaction associated with the NOTIFY request will > > eventually time out at the sender of the request (UAC), and the > > sender will consider the transaction a failure. > > > >I think this needs some discussion about the impact of the error > codes selected > >by the proxy on the dialog and its usages. For example: > > > >* If the proxy sends a 404 to prevent a transaction timeout, it will > destroy the > > dialog and all of its usages > > > >* If the proxy sends a 480 to prevent a transaction timeout, it will > destroy the > > usage, but not other usages in the dialog (if any) > > > >* If the proxy sends a 504 to prevent a transaction timeout, it will > keep the > > dialog and the usage alive, and allow the client to re-try at a > later time. > > Simply allowing the transaction to time out will have the same > effect, albeit > > with more message retransmissions. > > > > Pointing to RFC 5057 might be useful here. > > This has been addressed. The text in Section 6.2.3 now says: > > "When a proxy sends an error response to a mid-dialog request > (e.g., due to a transaction time out), the proxy SHOULD select a > response code that only impacts the transaction associated with the > request ([RFC5079])." > > --------------------------------------------------------------------------- > > §8.7: > > > Parameter value characters that are not part of pvalue needs to be > > escaped, as defined in RFC 3261. > > > >Nit: "...need to be escaped..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §9: > > > When a new value is registered to the PNS Sub-registry, a reference > > to a specification which describes the usage of the PNS associated > > > >Nit: "...specification that describes..." > > Has been fixed. > > --------------------------------------------------------------------------- > > §§10-12: > > >Nit: It seems like these should all be subsections of section 9. > > In my previous reply I said: > > "The idea was that the PNS registrations are in separate main > sections, as they could even be in a separate document." > > No changes were done based on this comment. > > --------------------------------------------------------------------------- > > §10: > > > The Topic consists of the Bundle ID, which uniquelly identifies an > > appliciation, and a service value that identifies a service > > > >Nit: "uniquely" > >Nit: "application" > > This has been fixed. > > --------------------------------------------------------------------------- > > §10: > > > Example: pn-param = DEF123GHIJ.com.yourcompany.yourexampleapp.voip > > > >Please use an RFC 2026 domain for this example; e.g.: > > > > Example: pn-param = DEF123GHIJ.com.example.yourexampleapp.voip > > Has been fixed. > > --------------------------------------------------------------------------- > > §11: > > > [RFC8292] defines a mechanism which allows a proxy to identity itself > > > > Nit: "...mechanism that allows..." > > Has been fixed. > > --------------------------------------------------------------------------- > > Regards, > > Christer >
- [sipcore] Adam Roach's No Objection on draft-ietf… Adam Roach
- Re: [sipcore] Adam Roach's No Objection on draft-… Christer Holmberg
- Re: [sipcore] Adam Roach's No Objection on draft-… Adam Roach
- Re: [sipcore] Adam Roach's No Objection on draft-… Christer Holmberg