(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2008/0220740 A1
`(43) Pub. Date:
`Sep. 11, 2008
`Shatzkamer et al.
`
`US 20080220740A1
`
`(54) BLACKLISTING OF UNLICENSED MOBILE
`ACCESS (UMA) USERS VIA AAA POLICY
`DATABASE
`
`(75) Inventors:
`
`Kevin Shatzkamer, San Francisco,
`CA (U S); Anand K. OsWal,
`Sunnyvale, CA (U S); Casey Yoon,
`Fremont, CA (US); Mark Grayson,
`Maidenhead (GB)
`
`Correspondence Address:
`Trellis Intellectual Property Law Group, PC
`1900 EMBARCADERO ROAD, SUITE 109
`PALO ALTO, CA 94303 (US)
`
`(73) Assignee:
`
`Cisco Technology, Inc., San Jose,
`CA (US)
`
`(21) App1.No.:
`
`11/716,267
`
`(22) Filed:
`
`Mar. 9, 2007
`
`Publication Classi?cation
`
`(51) Int. Cl.
`(2006.01)
`H04M 1/66
`(52) US. Cl. ...................................................... .. 455/411
`(57)
`ABSTRACT
`
`In one embodiment, While being connected to the network, a
`security issue may be detected and associated With the device.
`The device may be placed on a blacklist for the security issue.
`The blacklist is a list that is used to deny service for the device
`When it attempts to connect. Thus, the device is disconnected
`from the netWork. Identi?cation information for the device is
`added to the blacklist at the authentication server. If the device
`attempts to reconnect to the netWork, the request is received at
`the authentication server. The authentication server can then
`check the blacklist and deny the request for access to the
`netWork if the identi?cation information is on the blacklist.
`This denial is determined Without sending the request to the
`HLR. Accordingly, the HLR is protected in that requests from
`a device that may be considered a security issue are not sent to
`the HLR.
`
`402/‘ receives a request for access
`
`408 \
`
`Send the request
`to the HLR
`
`Blacklisted?
`
`Yes
`
`406%
`
`Determine that the request for
`access should be denied and
`sends a response to access
`device
`
`Samsung, Exh. 1008, p. 1
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 1 0f 7
`
`US 2008/0220740 A1
`
`108
`
`/ HLR
`
`102
`
`/ AAA server
`
`110
`
`Network
`
`Access
`
`device
`
`06
`
`Fig. 1
`
`104
`
`Mobile node
`
`Samsung, Exh. 1008, p. 2
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 2 0f 7
`
`US 2008/0220740 A1
`
`Receive a request for access to
`202w
`a network from a mobile node
`
`Send the request to an HLR for
`204 f
`authenticating the mobile node .
`
`l
`
`206% Receive a response from HLR
`
`l
`
`Send a response to the access
`208% gateway indicating whether or
`not the mobile node has been .
`authenticated
`
`Fig. 2
`
`Samsung, Exh. 1008, p. 3
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 3 0f 7
`
`US 2008/0220740 A1
`
`302/\
`
`Receive an indication of a
`security issue
`
`Yes
`
`304
`
`No
`
`V
`
`v
`
`Add identi?er for the mobile node
`to the blacklist
`@306
`
`308/‘ I
`
`L09 the Security event
`
`Fig. 3
`
`Samsung, Exh. 1008, p. 4
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 4 0f 7
`
`US 2008/0220740 A1
`
`402/‘ recelves a request for access
`
`Blacklisted?
`
`Yes i
`
`Determine that the request for
`406% access should be denied and
`sends a response to access
`‘
`device
`
`408 \
`
`Send the request
`to the HLR
`
`Fig. 4
`
`Samsung, Exh. 1008, p. 5
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 5 0f 7
`
`US 2008/0220740 A1
`
`\
`
`zwow
`
`ow_>_ ‘
`
`\
`
`v81 wEQE 55.2052 wn5<m
`
`
`
`
`
`
`new @2232 uwmzcmm
`
`2: N2
`\ \
`
`VII 502mm
`
`52
`
`m .mE
`
`8m 0%?
`
`0z<0 83w
`
`
`
`_| 52: wwmoow 6E2 @586
`
`wow
`
`2522
`
`one:
`
`Samsung, Exh. 1008, p. 6
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 6 0f 7
`
`US 2008/0220740 A1
`
`N8
`\
`
`o: \
`
`8m .
`
`
`_| | | | M>__|_
`_ _ _ xl | 0mm I I \_
`_ 1 lowed _
`
`Q:
`
`\ Q:
`
`5: 52
`
`
`hwzww
`
`zwoo 0E
`
`<1 lam
`
`
`
`go my:
`
`991
`
`
`
`ECCB 0; 30mm
`
`2502
`
`28:
`
`wow
`
`Samsung, Exh. 1008, p. 7
`
`

`
`Patent Application Publication
`
`Sep. 11, 2008 Sheet 7 0f 7
`
`US 2008/0220740 A1
`
`Now
`
`Samsung, Exh. 1008, p. 8
`
`

`
`US 2008/0220740 A1
`
`Sep. 11,2008
`
`BLACKLISTING OF UNLICENSED MOBILE
`ACCESS (UMA) USERS VIA AAA POLICY
`DATABASE
`
`TECHNICAL FIELD
`
`[0001] Particular embodiments generally relate to network
`ing and security.
`
`BACKGROUND
`
`[0002] Mobile nodes may access data networks by connect
`ing to an access device. A secure tunnel within Internet Pro
`tocol (IP) is established to communicate with the mobile
`node. Before establishing the secure tunnel, the mobile node
`is authenticated through an authentication, authorization, and
`accounting (AAA) domain to a home location register (HLR).
`The HLR is a central database that includes details of each
`mobile node and subscriber that is authorized to use the
`network.
`[0003] When a malicious attack is detected from the mobile
`node, the access device may terminate the session with the
`mobile node. In this case, the secure tunnel may be brought
`down. This disconnects the mobile node from the network.
`However, the mobile node can immediately attempt to recon
`nect to the network. This may occur because the mobile node
`is acting maliciously or may be inadvertent due to a virus. The
`mobile node may be authenticated again by the HLR through
`the AAA domain. Allowing a potentially malicious mobile
`node to reconnect to the network is not desirable. This
`exposes the HLR to a potential Denial of Service (DoS) attack
`as a malicious device/application, such as a virus or worm,
`continues to cause multiple queries to the HLR. The HLR is
`one of the most valuable nodes in a network. One reason is
`because the HLR maintains the subscriber’s personal infor
`mation. Allowing requests to contact the HLR exposes the
`HLR to potential DoS attacks. Also, requests to the HLR are
`expensive to process and thus having malicious requests con
`tact the HLR may cause unnecessary expenses to be incurred
`for a service provider.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0004] FIG. 1 shows an example of a system for providing
`a blacklist.
`[0005] FIG. 2 depicts an example of a method for authen
`ticating a mobile node.
`[0006] FIG. 3 depicts an example of a method for process
`ing security issues.
`[0007] FIG. 4 depicts an example of a method for process
`ing the subsequent request.
`[0008] FIG. 5 is an example ofa UMA network
`[0009] FIG. 6 shows another example of another network
`that can be used for providing a blacklist.
`[0010] FIG. 7 shows a more detailed example of an access
`gateway and a AAA server.
`
`DESCRIPTION OF EXAMPLE EMBODIMENTS
`
`Overview
`[0011] In one embodiment, an authentication server
`receives a request for access to a network from a device. The
`authentication server sends a request to a home location reg
`ister (HLR). The HLR may facilitate authentication of the
`device. The authentication server receives a response from
`the HLR that indicates if the device is authenticated to access
`
`the network and the device may be granted access to the
`network if it is authenticated. For example, a secure tunnel
`may be established between the device and an access device.
`[0012] While being connected to the network, a security
`issue may be detected and associated with the device. For
`example, it may be determined that the device is misbehav
`ing. In some cases, the device may be placed on a blacklist for
`the security issue. The blacklist is a list that is used to deny
`service for the device when it attempts to connect. Optionally
`the period of time for which the device is denied service is
`included in the blacklist. Thus, the device is disconnected
`from the network; e. g., the authentication server may trigger
`the secure tunnel to be brought down. Identi?cation informa
`tion for the device is added to the blacklist at the authentica
`tion server. If the device attempts to reconnect to the network,
`the request is received at the authentication server. The
`authentication server can then check the blacklist and deny
`the request for access to the network if the identi?cation
`information for the device is on the blacklist. This denial is
`determined without sending the request to the HLR. Accord
`ingly, the HLR is protected in that requests from a device that
`may be considered a security issue are not sent to the HLR.
`Further, requests sent to the HLR may be expensive and thus
`the expense is saved by not sending requests for devices that
`have been blacklisted.
`
`Example Embodiments
`
`[0013] FIG. 1 shows an example of a system for providing
`a blacklist. As shown, the system includes aAAA server 102,
`a mobile node 104, an access device 106, a home location
`register (HLR) 108, and a network 110.
`[0014] Mobile node 104 may be any device that wants to
`connect to network 110 through access device 106. For
`example, mobile node 104 may be a cellular telephone, laptop
`computer, personal digital assistant (PDA), BlackberryTM
`device, portable e-mail device, pocket PC, personal com
`puter, etc. Although a mobile node is described, it will be
`understood that other nodes may be used, such as nodes that
`are ?xed or not mobile (e.g., a VoIP telephone, set-top box,
`personal computer, etc.).
`[0015] Mobile node 104 may be associated with identi?ca
`tion information. For example, mobile node 104 may include
`an interface to a Subscriber Identity Module (SIM) card that
`includes the storage of an international mobile subscriber
`identify (IMSI), allowing the mobile node 104 to be associ
`ated with an IMSI. The IMSI is a unique number that is
`associated with network mobile phone users and is stored in
`a subscriber identity module (SIM) card for mobile node 104.
`The IMSI may be sent by mobile node 104 to a network and
`is used to acquire details of the mobile node/user from HLR
`108. Although an IMSI is described, it will be understood that
`other identi?ers for mobile node 104 may be appreciated.
`Also, it will be understood that mobile node 104 may not have
`a SIM card but may use other methods for identi?cation.
`[0016] Access device 106 is any device that controls access
`to network 110. For example, access device 106 may be a
`security gateway in UMA/GAN, packet data gateway (PDG)
`de?ned in 3GPP Interworking-WLAN (I-WLAN), packet
`data interworking function (PDIF) de?ned in 3GPP2, etc.
`[0017] Access device 106 is con?gured to establish a secure
`connection with mobile node 104. In one embodiment, the
`secure connection may be a secure tunnel such as an IPSec
`tunnel. IPSec is an IP security protocol used for securing IP
`communications by authenticating and/or encrypting each IP
`
`Samsung, Exh. 1008, p. 9
`
`

`
`US 2008/0220740 A1
`
`Sep. 11,2008
`
`packet in a data stream. In the tunnel mode, the entire IP
`packet is encrypted. Although an IPSec tunnel is described, it
`Will be understood that other secure methods of communica
`tion may be appreciated including a combination of integrity
`protection and/ or ciphering protection.
`[0018] AAA server 102 provides authentication, authoriZa
`tion, and/or accounting services. AlthoughAAA server 102 is
`described, it Will be understood that other authentication
`devices that provide authentication, authorization, and/or
`accounting may be used. AAA server 102 may use different
`protocols to communicate, such as Remote Authentication
`Dial In User Service (RADIUS), DIAMETER, etc.
`[0019] HLR 108 is a central database that contains details
`for mobile node 104 and a user or subscriber that is associated
`With mobile node 104. For example, HLR 108 stores details
`for the unique identi?er for mobile node 104, such as the SIM
`card issued by subscriber. The IMSI may also be associated
`With other details for mobile node 104, such as a telephone
`number, location of mobile node 104, account preferences,
`etc. Although HLR 1 08 is described, it Will be understood that
`any device that stores information for mobile node 104 may
`be appreciated.
`[0020] Network 110 may include any netWork devices that
`mobile node 104 Wants to access. For example, netWork 110
`may include elements of an unlicensed mobile access (UMA)
`netWork, a Voice over IP (VoIP) netWork, etc. Elements of
`netWork 110 Will be described in more detail beloW.
`[0021] When mobile node 104 Wants to access netWork
`110, it sends an IPSec Initiation request to access device 106.
`The initiation request may include the identi?cation informa
`tion for mobile node 104. Alternatively, access device 106
`may request the mobile node 104 to provide its identity infor
`mation. Access device 106 may then send a AAA request to
`AAA server 102. AAA server 102 then authenticates mobile
`node 104. For example, a request may be sent to HLR 108.
`The request may include information for mobile node 104,
`such as the IMSI. HLR 108 may facilitate authentication of
`mobile node 104. For example, HLR 108 may store triplet
`information that is used to authenticate Whether mobile node
`104 can access netWork 110. In another embodiment, a Home
`Subscriber Server (HSS) may be used for quintuplet based
`authentication.
`[0022] If mobile node 104 is authenticated, AAA server
`102 sends a response back to access device 106 indicating
`mobile node 104 has been authenticated. Access device 106
`may then establish a secure tunnel With mobile node 104.
`[0023] Elements in the system may then detect a security
`issue for mobile node 104. For example, any activity that
`indicates a user/mobile node 104 is misbehaving may be
`detected by access device 106, a device in netWork 110 such
`as a denial of service (DoS) detection device, etc. In one
`example, mobile node, 104 may be misbehaving due to a
`Worm, virus, or other malicious behavior. The session With
`mobile node 104 may then be ended. For example, the secure
`tunnel may be brought doWn. In another embodiment, the
`tunnel is kept alive, but traf?c is ‘blackholed’, that isirouted
`to a non-existent destination. By doing this, the process of
`establishing an IPSec tunnel again is also alleviated. In this
`instance, AAA server 102 Would not only maintain the black
`list, but notify access device 106 to blackhole traf?c for this
`particular subscriber. In one embodiment, a device in netWork
`110 indicates to AAA server 102 that a particular device is
`misbehaving. AAA server 102 is then operable to send a
`
`message to access device 106 to trigger the termination of the
`tunnel betWeen access device 106 and mobile node 104.
`[0024] Mobile node 104 may again attempt to reconnect to
`netWork 110 after being disconnected. Thus, mobile node 104
`may be authenticated again using AAA server 102 and HLR
`108. HoWever, identi?cation information for mobile node 104
`may be added to a blacklist that is maintained at AAA server
`102. For example, identi?cation information, such as triplet
`information, the IMSI, etc. for mobile node 104, may be
`added to a blacklist. In another embodiment, a time value is
`attributed to the blacklist entry.
`[0025] Once the identi?cation information is added to the
`blacklist and another connection is received, access may be
`denied. For example, mobile node 104 may send a request to
`access device 106. Access device 106 then sends a AAA
`request With identi?cation information for mobile node 104
`to AAA server 102. For example, the IMSI may be included
`in the AAA request. AAA server 102 may then check the
`blacklist to see if the IMSI for mobile node 104 is included on
`it. If the IMSI is included on the blacklist, AAA server 102
`may deny access to netWork 110. This is done Without con
`tacting HLR 108. Accordingly, HLR 108 is protected from
`any requests being sent to it from mobile nodes that may be
`considered a security issue. Further, any requests that are sent
`to HLR 108 may be expensive and thus requests for mobile
`nodes that are considered security issues are not sent. This
`may save costs for a service provider.
`[0026] In another embodiment, the blacklist is sent, via
`RADIUS, directly to access device 106 With a timer to store
`this entry for a period of time. In this embodiment, AAA
`server 102 is also of?oaded from requests by misbehaving
`devices. Rather, access device 106 polices the blacklist.
`[0027] FIG. 2 depicts an example of a method for authen
`ticating mobile node 104. In step 202, AAA server 102
`receives a request for access to netWork 110 from mobile node
`104. Requests may be for establishing a connection With
`access device 106. For example, a secure connection may be
`desired in Which voice or data may be sent. In one example,
`general packet radio service (GPRS) data may be sent through
`the secure connection. Access device 106 may then send a
`request to AAA server 102.
`[0028] In step 204, AAA server 102 sends a request to HLR
`108 for authenticating mobile node 104. The request may
`include the IMSI for mobile node 104. HLR 108 may then
`authenticate mobile node 104 using the IMSI. The authenti
`cation may be triplet-based.
`[0029] Step 206 receives a response from HLR 108 indi
`cating Whether or not mobile node 104 has been authenti
`cated.
`[0030] In step 208, AAA server 102 sends a response to
`access gateWay 106 indicating Whether or not mobile node
`104 has been authenticated. Accordingly, access device 106
`may establish a secure connection With mobile node 104 if
`mobile node 104 has been authenticated. After establishment
`of the secure connection, mobile node 104 may communicate
`With netWork 110 through access device 106. For example,
`voice, data, etc. may be sent through the secure connection.
`[0031] At some point, a security issue may be determined
`and associated With mobile node 104. For example, any
`device in netWork 110, access device 106, etc. may determine
`that a security issue With mobile node 104 exists. This may be
`because a Worm, virus, or other malicious behavior is
`detected and associated With mobile node 104.
`
`Samsung, Exh. 1008, p. 10
`
`

`
`US 2008/0220740 A1
`
`Sep. 11,2008
`
`[0032] FIG. 3 depicts an example of a method for process
`ing security issues. Step 302 receives an indication of a secu
`rity issue. The security issue may be detected by any element
`in the system.
`[0033] Step 304 determines if the security issue Warrants
`blacklisting. For example, the malicious behavior that is
`detected may or may not be considered malicious after further
`analysis. The behavior may be considered a security issue but
`may not be the result of a Worm or virus, and is thus ignored.
`Also, the blacklisting of a mobile node may occur after a
`certain number of suspicious security issues have occurred.
`For example, mobile node 104 may not be added the ?rst time
`a security issue is detected, but may be added after a security
`issue is detected a number of times.
`[0034] If the security issue Warrants blacklisting, then in
`step 306, identi?cation information, such as triplet informa
`tion, the IMSI, etc. for mobile node 104, is added to the
`blacklist. For example, a noti?cation is sent to AAA server
`102 andAAA server 102 adds the IMSI to a blacklist to note
`in a list of identi?cation information that this mobile node is
`blacklisted (e.g., a ?ag is set). Other information for mobile
`node 104 may also be added to the blacklist entry.
`[0035] Mobile node 104 may be blacklisted for a certain
`period of time. For example, after a certain period of time,
`mobile node 104 may be removed from the blacklist. Also,
`after some a?irmative action, such as the user calling in to a
`service provider to have its information removed from the
`blacklist, the mobile node 104 may be removed.
`[0036] If the security issue does not Warrant blacklisting,
`then in step 308, the event may be logged. This may be used
`to determine if blacklisting for future security issues is War
`ranted.
`[0037] After determining the security issue, the secure con
`nection With mobile node 104 may be brought doWn. At some
`point, mobile node 104 may send another request to connect
`to netWork 110. FIG. 4 depicts an example of a method for
`processing the subsequent request. Although a subsequent
`request is described, the request does not have to be a recon
`nection request for a netWork. For example, mobile node 104
`may be blacklisted across many netWorks once it is detected
`on a single netWork and can be denied access Whenever it is
`requested.
`[0038] In step 402, AAA server 102 receives a request for
`access. This request may be received from access device 106.
`[0039] At step 404, AAA server 102 determines if identi?
`cation information for mobile node 104 is on the blacklist. If
`the identi?cation information is not on the blacklist, a request
`may be sent to HLR 108 in step 406. In this case, mobile node
`104 is authenticated as described above With respect to FIG.
`2.
`[0040] If the IMSI is on the blacklist, in step 408, AAA
`server 102 determines that the request for access should be
`denied and sends a response to access device 106. In this case,
`the request is not sent to HLR 108 for access. Accordingly,
`AAA server 102 does not contact HLR 108 if mobile node
`104 is blacklisted.
`[0041] Particular embodiments may be used With different
`netWorks, such as an unlicensed mobile access (UMA) net
`Work or a voice over Wireless local area netWork (LAN), any
`VoIP netWork including a cable or Wireline-based VoIP. FIG.
`5 is an example of a UMA netWork, Which may also be
`referred to as a generic access netWork (GAN). The UMA
`netWork alloWs seamless roaming and handover betWeen
`local area netWorks and Wide area netWorks using the same
`
`dual mode mobile node 104. The local netWork may be based
`on private unlicensed spectrum technology such as Bluetooth
`or 802.1 1 (WiFi). The Wide area netWork may be GSM/GPRS
`or a universal mobile telecommunication system (UMTS).
`[0042] As shoWn, the UMA netWork includes a UMA net
`Work controller (UNC/GANC) 502, a mobile sWitching cen
`ter (MSC) 504, and a GPRS gateWay support node (GGSN)
`506. It Will be understood that other elements of a UMA
`netWork Will also be appreciated.
`[0043] UNC/GANC 502 is con?gured to translate signals
`from mobile node 104 to make it appear that it is coming from
`a base station. Thus, When a mobile node 104 moves from a
`GSN to a WiFi netWork, it appears to the core netWork that it
`is simply from a different base station. MSC 504 provides
`voice sWitching functions for a cellular netWork.
`[0044] GGSN 506 acts as a gateWay betWeen data net
`Works, such as the Internet and private netWorks. For
`example, data sent and received from mobile node 104 may
`be sent from GGSN 506 to other netWorks.
`[0045] Mobile node 104 may send a request to security
`gateWay 106. Security gateWay 106 may then send a RADIUS
`authentication message that includes the SIM credentials
`from mobile node 104. For example, the SIM credentials may
`include the IMSI for mobile node 104. In one embodiment,
`the RADIUS message may be an extensible authentication
`protocol (EAP)-SIM message. Although RADIUS is
`described, it Will be understood that other protocols may be
`used.
`[0046] AAA server 102 then sends a SIM identity request to
`HLR 108. Information in the SIM identity request is used to
`retrieve data for the user. For example, data stored in HLR 1 08
`may include GSM services that the user has requested orbeen
`given, GPRS settings to alloW the user to access packet ser
`vices, the current location of a subscriber, etc. HLR 108 then
`facilitate authentication of mobile node 104. A response is
`sent back to AAA server 102, Which may then generate a
`RADIUS response message and send it to security gateWay
`106. A secure tunnel may then be established With mobile
`node 104.
`[0047] Any of the devices in UMA netWork 500 may detect
`a security issue. When that issue is detected, it may be sent to
`AAA server 102. AAA server 102 may add information from
`the SIM credentials to a blacklist. After being blacklisted,
`mobile node 104 may send a request to security gateWay 106.
`Security gateWay 106 may then send a RADIUS authentica
`tion message that includes the SIM credentials from mobile
`node 104. AAA server 102 checks to see if the information
`from the SIM credentials is on the blacklist and if so, denies
`the access request. AAA server 102 may send an EAP
`response that supports EAP noti?cation. The Noti?cation
`Type is optionally used to display a message to mobile node
`104. For example, the message may notify a user of mobile
`node 104 that the authentication has failed.
`[0048] FIG. 6 shoWs another example of another netWork
`that can be used for providing a blacklist. For example, net
`Work 110 in FIG. 6 shoWs a voice over Wireless LAN. Mobile
`node 104 may establish an IPSec secure connection With
`access device 106. Access device 106 may be a packet data
`gateWay or packet data interrogating function (PDIF). A
`packet data gateWay may be found in a UMTS/GPRS netWork
`and a PDIF may be found in a code division multiplex access
`(CDMA) netWork.
`[0049] Access device 106 may establish a secure tunnel
`With a gateWay GPRS support node (GGSN) or a home agent
`
`Samsung, Exh. 1008, p. 11
`
`

`
`US 2008/0220740 A1
`
`Sep. 11,2008
`
`(HA) 602. GGSN/HA 602 may contact AAA server 102 to
`authenticate mobile node 104. This communication may or
`may not go through netWork 110. AAA server 102 may then
`contact HLR 108 and mobile node 104 is authenticated as
`described above.
`[0050] After a secure tunnel is established With mobile
`node 104, devices in FIG. 6 may detect a security issue. For
`example, session border controller (SEC) 604 or proxy-call
`session control function (P-CSCF) 606 may detect a security
`issue. P-CSCF 606 may be part of an IP multimedia sub
`system (IMS). Although other components of the IMS are not
`shoWn, it Will be understood that they may be included and
`may detect security issues.
`[0051] SEC 604 may receive session initiation protocol
`(SIP) messages. These are control messages that are used to
`set up the bearer ?oWs for mobile node 104. SEC 604 may
`interrogate the SIP messages to determine if any security
`issues result. This detects security issues before a bearer How
`is established. This may protect the netWork from serious
`harm as a connection is not brought up With a potentially
`malicious mobile node 104.
`[0052] Also, P-CSCF 606 is a SIP proxy and is the ?rst
`point of contact for the IMS netWork. Accordingly, P-CSCF
`606 may analyZe SIP messages to determine any security
`vulnerabilities. If SEC 604, P-CSCF 606, or any other device
`detects a security issue, it may be sent to AAA server 102 for
`blacklisting.
`[0053] FIG. 7 shoWs a more detailed example of access
`gateWay 106 and AAA server 102. A connection establisher
`702 receives an access request from mobile node 104. This
`may be after mobile node 104 has been blacklisted.
`[0054] An access facilitator 704 is con?gured to send a
`AAA request for access to AAA server 102. Access facilitator
`706 receives the request and can forWard it to blacklist deter
`miner 708.
`[0055] Blacklist determiner 708 determines if identi?ca
`tion information for mobile node 104 is found in a blacklist
`710. If so, the request may be denied. Access facilitator 706
`may send the response back to access gateWay 106. Connec
`tion establisher 702 may then deny access to mobile node
`104.
`[0056] Accordingly, particular embodiments of?oad pro
`cessing from HLR 108 to AAA server 102. This also protects
`a link betWeenAAA server 102 and HLR 108. Thus, HLR 108
`may be protected from malicious attacks. Further, the net
`Work is protected by stopping requests at AAA server 102.
`Additionally, requests sent to HLR 108 are considered expen
`sive, and thus, unnecessary requests for mobile nodes 104 that
`may be security issues are avoided.
`[0057] Although the description has been described With
`respect to particular embodiments thereof, these particular
`embodiments are merely illustrative, and not restrictive.
`Although a AAA server is described, it Will be understood
`that other devices may be used to enforce the blacklist and the
`term AAA server may include these devices. Also, mobile
`node 104 may be any device that can communicate With a
`netWork.
`[0058] Any suitable programming language can be used to
`implement the routines of particular embodiments including
`C, C++, Java, assembly language, etc. Different program
`ming techniques can be employed such as procedural or
`object oriented. The routines can execute on a single process
`ing device or multiple processors. Although the steps, opera
`tions, or computations may be presented in a speci?c order,
`
`this order may be changed in different particular embodi
`ments. In some particular embodiments, multiple steps
`shoWn as sequential in this speci?cation can be performed at
`the same time. The sequence of operations described herein
`can be interrupted, suspended, or otherWise controlled by
`another process, such as an operating system, kernel, etc. The
`routines can operate in an operating system environment or as
`stand-alone routines occupying all, or a substantial part, of the
`system processing. Functions can be performed in hardWare,
`softWare, or a combination of both. Unless otherWise stated,
`functions may also be performed manually, in Whole or in
`part.
`[0059] In the description herein, numerous speci?c details
`are provided, such as examples of components and/or meth
`ods, to provide a thorough understanding of particular
`embodiments. One skilled in the relevant art Will recogniZe,
`hoWever, that a particular embodiment can be practiced With
`out one or more of the speci?c details, or With other apparatus,
`systems, assemblies, methods, components, materials, parts,
`and/or the like. In other instances, Well-knoWn structures,
`materials, or operations are not speci?cally shoWn or
`described in detail to avoid obscuring aspects of particular
`embodiments.
`[0060] A “computer-readable medium” for purposes of
`particular embodiments may be any medium that can contain,
`store, communicate, propagate, or transport the program for
`use by or in connection With the instruction execution system,
`apparatus, system, or device. The computer readable medium
`can be, by Way of example only but not by limitation, an
`electronic, magnetic, optical, electromagnetic, infrared, or
`semiconductor system, apparatus, system, device, propaga
`tion medium, or computer memory.
`[0061] Particular embodiments can be implemented in the
`form of control logic in softWare or hardWare or a combina
`tion of both. The control logic, When executed by one or more
`processors, may be operable to perform that What is described
`in particular embodiments.
`[0062] A “processor” or “process” includes any human,
`hardWare and/or softWare system, mechanism or component
`that processes data, signals, or other information. A processor
`can include a system With a general-purpose central process
`ing unit, multiple processing units, dedicated circuitry for
`achieving functionality, or other systems. Processing need
`not be limited to a geographic location, or have temporal
`limitations. For example, a processor can perform its func
`tions in “real time,” “offline,” in a “batch mode,” etc. Portions
`of processing can be performed at different times and at
`different locations, by different (or the same) processing sys
`tems.
`[0063] Reference throughout this speci?cation to “one
`embodiment”, “an embodiment”, “a speci?c embodiment”,
`or “particular embodiment” means that a particular feature,
`structure, or characteristic described in connection With the
`particular embodiment is included in at least one embodiment
`and not necessarily in all particular embodiments. Thus,
`respective appearances of the phrases “in a particular embodi
`ment”, “in an embodiment”, or “in a speci?c embodiment” in
`various places throughout this speci?cation are not necessar
`ily referring to the same embodiment. Furthermore, the par
`ticular features, structures, or characteristics of any speci?c
`embodiment may be combined in any suitable manner With
`one or more other particular embodiments. It is to be under
`stood that other variations and modi?cations of the particular
`
`Samsung, Exh. 1008, p. 12
`
`

`
`US 2008/0220740 A1
`
`Sep. 11,2008
`
`embodiments described and illustrated herein are possible in
`light of the teachings herein and are to be considered as part
`of the spirit and scope.
`[0064] Particular embodiments may be implemented by
`using a programmed general purpose digital computer, by
`using application speci?c integrated circuits, programmable
`logic devices, ?eldprogrammable gate arrays, optical, chemi
`cal, biological, quantum or nanoengineered systems, compo
`nents and mechanisms may be used. In general, the functions
`of particular embodiments canbe achieved by any means as is
`known in the art. Distributed, networked systems, compo
`nents, and/ or