user notification protocol nikolai leung, qualcomm incorporated...
TRANSCRIPT
User Notification Protocol
Nikolai Leung, QUALCOMM Incorporated [email protected] (703) 346-8351
Notice: QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.
History
Presented x31-20051024-016 in October meetings
Comments at October meetings Investigate reducing overhead of
SUBSCRIBE-NOTIFY method Investigate using PUBLISH method
Also specify a solution that does not rely on IMS
General UNP Architecture
Serving Network
Home Network
AT/MS
AN/BS
PDSN
PrepaidServer
Notification Server(NS)
OtherNotificationApplication
HoliningRedirectServer
General UNP Architecture 2
Notification Server (NS) in the home network Simplify security between NS and network
applications that trigger notifications Do not standardize interfaces between
the NS and network applications that trigger notifications Co-locate network applications with NS or
provide secure proprietary interfaces to the NS
Protocol Proposal v2 Not invent a new protocol Use SIP-MESSAGE Method (RFC 3428)
Extension to SIP that allows transfer of Instant Messages.
Prepaid balance/notification is sent to the terminal in a SIP MESSAGE
Avoid overhead of SUBSCRIBE-NOTIFY method
More appropriate than PUBLISH method Establishes soft state in terminal, terminal acts as
server/compositor
SIP-MESSAGE Method
Terminal NS
MESSAGE
200 OK
PrepaidBalance Low
Proxy
MESSAGE
200 OK
UNP over IMS
Serving Network
Home NetworkAT/MS
AN/BS
PDSN
PrepaidServer
Notification Server(NS)
OtherNotificationApplication
HoliningRedirectServer
S-CSCFP-CSCF
P-CSCF can alsoreside in the home
network when he AT/MS is roaming
Leverage IMS for architecture, security, and accounting
NS is an Application Server in the home network that sends the SIP MESSAGE through the IMS network to the terminal
UNP for Non-IMS Network NS acts as combined SIP registrar/AS
Terminal registers current IP address with NS only for IP-reachability
Serving Network
Home Network
AT/MS
AN/BS
PDSN
PrepaidServer
Notification Server(NS)
OtherNotificationApplication
HoliningRedirectServer
UNP Registration for IMS 3rd party registration with NS by SIP registrar
based on User Service Profile in the HSS Registration with NS indicates that the AT/MS
expects notifications and is reachable
PDSN NotificationServer
AT/MS
SIPRegistrar
IMS Register
HSS
Request UserService Profile
IncludesNS address
Event thatcauses IMSregistration
3rd Party Registration for AT/MS
Operator addsNS address toUser Service
Profile
UNP Registration for non-IMS AT/MS registers directly with NS to provide
IP address information AT/MS procedure identical to IMS procedure
PDSN NotificationServer
AT/MS
SIP Register
Provisionedwith FQDN of
NS
IP addressassignment
User Notification Delivery
NotificationServer
AT/MS
P-CSCF S-CSCF
MESSAGEMESSAGE
PrepaidServer
LowPrepaidBalance
200 OK
“SendNotification”
I-CSCF
MESSAGEMESSAGE
200 OK200 OK
200 OK
IMS: NS sends SIP MESSAGE to SIP-URI of terminal
NotificationServer
AT/MS
MESSAGE
PrepaidServer
LowPrepaidBalance
200 OK
“Send Notification”
Non-IMS: NS sends SIP MESSAGE directly to the IP address of the AT/MS
Delayed Delivery over IMS Undelivered messages can be queued until terminal re-
registersNotificationServer
AT/MS
SIPRegistrar
S-CSCF
MESSAGEMESSAGE
PrepaidServer
LowPrepaidBalance
200 OK
“SendNotification”
I-CSCF
MESSAGE
200 OK200 OK
MESSAGE
AT/MS isnot-
registered/
reachable
REGISTER3rd Party Registration
Notification isqueued
Terminal isnow reachable
Not Found
Delayed Delivery over non-IMS Undelivered messages can be queued
until terminal re-registersNotificationServer
AT/MS
MESSAGE
PrepaidServer
LowPrepaidBalance
“Send Notification”
200 OK
MESSAGE
AT/MSis
not-registered
/reachable
REGISTER
Notification isqueued since
no ack
Terminal isnow reachable
Security for UNP over IMS Hop-by-hop security provided by IMS
AT/MS to P-CSCF Authentication: HTTP Digest authentication using
AKA Encapsulation: IPSec
P-CSCF to S-CSCF: relies on IMS inter- and intra-domain security
Security between the NS and S-CSCF: Rely on IMS intra-domain security
Security between the NS and network applications requesting notifications (e.g Prepaid server) is assumed but outside of scope
Security for UNP over IMS2
Tying it together The NS ensures that notification requests
come from a trusted network application E.g., Prepaid balance notification can only be
requested by the prepaid server The S-CSCF inserts P-Asserted-Identity Tag =
“3GPP2 Notification Server” only on SIP MESSAGE from the NS
AT/MS displays messages with “3GPP2 Notification Server” tag as authenticated system message
UNP Security for Non-IMS Establish secure tunnel directly between
NS and Terminal TLS
PSK – Pre-provisioned in the R-UIM GBA – For further study because of concerns
about long-term bootstrapped key in terminal Expect TLS/TCP session to time out between
notifications Re-establish TCP and TLS sessions before sending
notification AKA+IPSec
Can use UDP to avoid need for TCP state Not desirable because NS needs interface to HSS
UNP Interaction with NFCC
IMS: UNP to Leverage IMS solution UNP SIP MESSAGE traverses the same
pinhole established between the AT/MS and P-CSCF for IMS
Non-IMS For further study pending NFCC design Expect NS to open pinhole before
sending SIP MESSAGE
Accounting The operator may not want to charge for non-billable
traffic (e.g. unsolicited notifications) from the NS In IMS the S-CSCF generates detailed billing records for
SIP MESSAGE messages between the AT/MS and NS The AAA can use this to determine how to bill traffic
Non-IMS: After a message exchange, the NS sends a report to the AAA indicating how many bytes are exchanged with the NS
The NS counts how many bytes it exchanges with the AT/MS This count should include any overhead bytes the PDSN would
count AAA adjusts prepaid balance based on this report from the
NS Before cutting off access, PDSN goes back to AAA to see adjusted
balance Rely on same intra-domain security to ensure that
AAA can trust accounting reports from NS NS can trust that notification requests from network applications
will send valid non-billable traffic
Content of SIP MESSAGE
Content-type: Application/vnd.3gpp2.ns
MESSAGE content structure Define simple XML schema Or Define Binary Coded Data
Next Steps Division of work in 3GPP2
MMD develop UNP Protocol since approach is SIP MESSAGE-based
TSG-S WG 4 develop security model for Non-IMS solution
PDS provide input on non-IMS solution PDS provide input on structure of SIP
MESSAGE contents Register vnd.3gpp2.ns MIME type with
IANA