S20-20040209-007a__(QC) all-IP NAM correction - 3GPP2

tukwilagleefulInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

87 εμφανίσεις

Seoul, Korea

S20
-
20040209
-
007a



1

1
.
Introduction

1

The existing 3GPP2 All
-
IP Network Archit
ecture Model (NAM) [1] summarizes

2

the network entities and associate
d reference points that comprise

the
3

cdma
2000

All
-
IP network. T
he All
-
IP NAM consists of

the cdma2000 Access
4

Network and the
All
-
I
P Core Network. The All
-
IP Core Network
may be further
5

decomposed

into the Multimedia Domain (MMD) and the Legacy MS Domain
6

(LMSD).

A subset of the

MMD is
a collection of
functional
entities that provide
7

specific service capabilities (e.g., geo
-
location
and presence), and
is
referred to
8

as the
service capability subsystem

[2]
. The entities that comprise the serv
ice
9

capability subsystem are

various application servers

(
e.g.,
OSA

and SIP
10

Application S
ervers)
,
OSA Service Capability Server (SCS), Position S
erver,
AAA,
11

CSCF

and Databases
.
Problems

are identified

in the
existing

representation of
12

the MMD service capability subsystem

with regards

to the
SIP and OSA
13

functional entities and
associated
reference points
. C
orrections

to
pertinent

14

text and diagrams

are proposed.
T
he
se

changes

pertain

not only

to
the All
-
IP
15

NAM
, but are also relevant to

portions of
the MMD

specifications

[2],[3].


16


17

2.
Proposal Detail

18

Figure 1 illustrates the
service capability subsystem

in
the
MMD portion of the
19

all
-
IP NAM
.


20


21

Figure 1


Service Capability Subsystem of All
-
IP NAM

22




23

Seoul, Korea

S20
-
20040209
-
007a



2

2.1

Allowable

Configurations of the SIP Application Server

1

In the
MMD,

SIP Application Servers
may host and execute
application
se
rvices,
2

and

control

or impact
the SIP session

on behalf of those

services
.
The SIP
3

Application Server and the CSCF
share a
n

implicit
trust relationship,
as shown

4

by Figure 1 and described in [2].
Since

security services
(such as
5

authentication, authorization, privacy, integrity)
are not provided ov
er the
6

11/Sh and 12/ISC interfaces
,
in practice
only

implicitly
trusted SIP Application
7

Server
s

would be

permitted

to directly

interact

with
the
core network
elements
8

CSCF and AAA
. F
or example
, these
may be
SIP Appli
cation Servers

hosted in
9

the mobile ope
rator’
s
network
, or reside
externally in a 3
rd
-
party

network and
10

connected to the
operator’s network

over a VPN.
From this standpoint
,
a
11

potential security gap may exist in accordance with
the

description of Type B
12

Application Servers (i.e.,

SIP
Ap
plicati
on Servers) given in

Secti
on 3.1.4 of
[1]
.
13

In particular, it is stated in that section:

14

“Type B Application Servers are hosted on equipment in the WNO network,
15

in the Internet

or in a private network capable of communicating in SIP
16

and offering both servi
ce control and content. …”

17

Certainly

a mobile operator can allow an operational configuration whereby the
18

SIP Application Server is located in the Internet
, if it is willing to accept the
19

associated

security risks.
Such

security risks

may be

unacceptable

in practical
20

service deployment
. It is
therefore
proposed
that
the
existing description of

the
21

Type B Application Server
be modified,
for example
by
stating

the potential
22

security risks

associated with the Internet configuration option
, and that a
23

secure i
nterface may be necessary as result
. Alternatively,
indication can be
24

made

that
the Type A (i.e., OSA Applicatio
n Server) application server can
be
25

used to
host

non
-
trusted SIP applications, due to the security services provided
26

by the OSA framework.

27

2.2

OSA Service Capability Server Functionality

28

The Open Service Access (
OSA
) enables applications to make use of network
29

functionality in the creation and implementation of value
-
adde
d
30

application/end user services.
Network function
ality offered to applicat
ions are

31

defined in terms of a set of Service Capability Features
(SCFs)
in the

OSA API,
32

which are supported by Service Capability Servers (SCS
s
).
The OSA
API, or
33

interfaces,

comprise
a number of
interface classes

and associated methods
,

34

and

are divided
into two types: Framework interfaces and Network interfaces.
35

The OSA consists of three parts

[4]
:

36

1.

Applications. Examples include call control, messaging,
presence,
37

location and
charging. These applications are implemented in one or
38

more OSA Application
Servers

39

2.

Framework. The Framework provides applications with basic
40

mechanisms
that enable them to make use of the service capabilities in
41

the network.

Examp
les of F
ramework functions are a
uthentication and
42

service d
iscovery. Before an application can use
the network
43

functionality made available through Service Capability Features,
44

authentication between the app
lication and the Framework is required
.

45

Seoul, Korea

S20
-
20040209
-
007a



3

After authentication, the discovery function enables the application to
1

find out which network service capa
bility features are provided by the
2

SCSs
.

The Framework also enables the
features

offered by the SCS to be
3

registered an
d subsequently discovered by

requesting application
s
.

4

3.

Service Capability Servers (SCS). After the Framework functions have
5

been perform
ed, applications can
then
directly invoke the underlying
6

network capabilities represented by the SCS.
The network service
7

capability features are accessed by the methods defined in the OSA
8

Network interfaces.


9

As described above,
the SCS does not
provide

s
ervice
mediation

functionality for

10

controlling application

access

to
service c
apabilities in the network. Tho
se
11

control/management mechanisms,
such as authentication, authorization,
12

service discovery, and service agreement establishm
ent are provided in OS
A by
13

the Framework
. The SCS provides network functionality to the OMA
14

applications only after the Framework procedures
ha
ve been completed.

15

Without the Framework, supported OSA Application Servers would be limited to
16

only those implicitly trusted by the
network, i.e., 3
rd
-
party applications hosted
17

in non
-
trusted networks

would be disallowed
.
Therefore to eliminate the
18

omission

and
ensure
technical accuracy

it is proposed that
the OSA SCS
19

function in
the All
-
IP NAM be replaced by a composite entity
encomp
assing

the
20

SCS and

Framework functions
. For lack of a bette
r term

this composite entity
21

is

referred to
herein
as the

OSA Network Function
”, as

shown

in Figure 2

22

below

(a typical instantiation of the OSA Network Function is commonly
23

referred to as an OSA
Gateway; however, the latter is a physical network entity).


24


25

In conjunction

with the above proposed architecture change, a number of
26

related diagrammatic
al and text changes are proposed for
the all
-
IP NAM
Rev.
27

3.0 document
, including
:


28

Seoul, Korea

S20
-
20040209
-
007a



4



All diagrams
showi
ng the OSA Service Capability Server

should be
1

replaced by the OSA Network Function
;

2



Description text for OSA Application Server
(
under Application Se
rver),
3

and OSA
-
SCS in Section 2.1
.1, Network Entities
;

4



Description text for AAA interfaces to OSA entities
;

5



Introductory text of the OSA Framework, for
Section 2.1.1;

6



Description text of interfaces to the CSCF
;

7



Description text for Reference Points 8/OSA
-
API;

8



Description text for Re
ference Points 11
/
Sh
;

9



Description text for Reference Points 12/ISC

10

The propose
d changes

to both the SIP Applica
tion Server and OSA aspects are
11

detail
ed in

S20
-
20040209
-
007
b (the original all
-
IP NAM Rev 3.0 document, with
12

revision marks shown for proposed changes).

13

3.
Summary

14

This contribution
proposes
corrections to
two
problems

in

the
3GPP2 All
-
IP
15

NAM

pertaining to

the service
capability subsyste
m of the MMD. The first is the
16

existing
text description of the SIP Application Server
,

indicating it m
ay reside
17

in the Internet. It is

proposed that the existing description of the Type
B
18

Application Server be modified, for example by stating the potential security
19

risks associated with t
he Internet configuration
, and that a secure interface
20

may be necessary as result. Alternatively, indication can be made that the Type
21

A (i.e., OSA Appl
ication Server) application server can
be used to
host non
-
22

trusted SIP applications, due to the security services provided by the OSA
23

framework
.
The second is the omission of the OSA Framework in the
24

architecture. The Framework performs a number of impor
tant control and
25

management

functions
, such as authentication, authorization, discovery and
26

service agreement establishment,

in
granting application access to network
27

capabilities
.

Without the Framework, supported OSA
applications

would be
28

reduc
ed
in prac
tice
to only those implicitl
y trusted by the network, i.e.,
3
rd
-
29

party applications hosted in
non
-
trusted networks

would be disallowed
.

The
30

proposed changes in this contribution are also relevant to
parts 000 and 002 of
31

the 3GPP2 MMD
specifications
.

32

4
. Re
ferences

33

[1]

3GPP2
S.R0037
-
0
, “
IP Network Architecture Model for cdma2000 Spread Spectrum
34

Systems
”,
Version 3
.0,
August 2003
.

35

[2]

3GPP2
X.S
0013.0
00
,

IP Network for cdma2000 Spread Spectrum Systems 3GPP2
36

All
-
IP Core Network Enhancements for Multimedia Do
main (MMD) Overview (Part
-
0
0
0)
”.

37

[3]

3GPP2
X.S
0013.002
,

All
-
IP Core Network Multimedia Domain, IP Multimedia
38

Subsystem
-

Stage 2
”.

39

Seoul, Korea

S20
-
20040209
-
007a



5

[4] 3GPP TS 23.127, “3
rd

Generation Partnership Project; Technical Specification Group
1

Services and System Aspects; Virtual

Home Environment/Open Service Access (Release
2

6)
, Version 6.0.0, December 2002.

3