(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2008/0220740 A1
`
`
` Shatzkamer et al. (43) Pub. Date: Sep. 11, 2008
`
`US 20080220740A1
`
`(54) BLACKLISTING 0F UNLICENSED MOBILE
`
`Publication Classification
`
`)
`
`51
`
`(
`
`I t Cl
`'
`n '
`H04M 1/66
`(2006.01)
`(52) US. Cl. ........................................................ 455/411
`(57)
`ABSTRACT
`
`ACCESS (UMA) USERS VlAAAA POLICY
`DATABASE
`
`(75)
`
`Inventors:
`
`Kevin Shatzkamer, San Francisco,
`CA (US); Anand K. Oswal,
`Sunnyvale, CA (US); 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) Appl. No .:
`
`1 1/716,267
`
`(22)
`
`Filed:
`
`Mar. 9, 2007
`
`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. Identification information for the device is
`added to the blacklist at the authentication server. Ifthe 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 identification 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
`
` Send the request
`to the HLR
`Blacklisted.
`
`7
`
`-
`
`406
`
`Determine that the request for
`access should be denied and
`sends a response to access
`device
`
`Page 1 of 14
`
`1
`
`HTC EXHIBIT 1006
`
`1
`
`HTC EXHIBIT 1006
`
`Page 1 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 1 0f 7
`
`US 2008/0220740 A1
`
`108
`
`102
`
`Fig.1
`
`Page 2 of 14
`
`2
`
`2
`
`Page 2 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 2 0f 7
`
`US 2008/0220740 A1
`
`202
`
`204
`
`205
`
`208
`
`Receive a request for access to
`a network from a mobile node
`
`Send the request to an HLR for
`authenticating the mobile node .
`
`
`
`Receive a response from HLR
`
`Send a response to the access
`gateway indicating whether or
`not the mobile node has been .
`
`authenticated
`
`Fig. 2
`
`Page 3 of 14
`
`3
`
`3
`
`Page 3 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 3 0f 7
`
`US 2008/0220740 A1
`
`
`Receive an indication of a
`security issue
`
`302
`
`
`Blacklisting?
`
`
`
`
`Add identifier for the mobile node
`to the blacklist
`
`_
`
`.
`
`
`
`_
`Log the security event
`
`Fig. 3
`
`Page 4 of 14
`
`4
`
`4
`
`Page 4 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 4 of 7
`
`US 2008/0220740 A1
`
`402
`
`receives a request for access
`
`
` Blacklisted?
`
`Send the request
`to the HLR
`
`
`
`Determine that the request for
`access should be denied and
`sends a response to access
`‘
`device
`
`406
`
`Fig. 4
`
`Page 5 of 14
`
`5
`
`5
`
`Page 5 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 5 of 7
`
`US 2008/0220740 A1
`
`m.mE
`
`vomMED/xx
`
`
`
`cosmozcofiz<waged
`
`@20me
`
`Hmmzcmm
`
`
`
`6:5:050mm
`
`vow
`
`2522
`
`one:
`
`mowNow
`
`Page 6 of 14
`
`6
`
`Page 6 of 14
`
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 6 of 7
`
`US 2008/0220740 A1
`
`c.mt
`
`.2522
`
`
`
`_0Cr_30..:owm
`
`wuo:
`
`Page 7 of 14
`
`7
`
`Page 7 of 14
`
`

`

`Patent Application Publication
`
`Sep. 11, 2008 Sheet 7 of 7
`
`US 2008/0220740 A1
`
`
`
`>m>>2mmwmwoo<
`
`mow
`
`hat
`
`mmmoo<v
`
`5559
`
`$23<<<
`
`mmmoo<
`
`
`
`hENE_omu_
`
`5:02:00
`
`Lmzflfimawm
`
`
`
`35853.285
`
`BEESEv
`
`No_‘
`
`Page 8 of 14
`
`8
`
`Page 8 of 14
`
`
`

`

`US 2008/0220740 A1
`
`Sep. 11,2008
`
`BLACKLISTING OF UNLICENSED MOBILE
`ACCESS (UMA) USERS VIA AAA POLICY
`DATABASE
`
`TECHNICAL FIELD
`
`Particular embodiments generally relate to network-
`[0001]
`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
`
`FIG. 1 shows an example of a system for providing
`[0004]
`a blacklist.
`
`FIG. 2 depicts an example of a method for authen-
`[0005]
`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
`
`an authentication server
`In one embodiment,
`[0011]
`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. Identification informa-
`tion for the device is added to the blacklist at the authentica-
`
`tion server. Ifthe 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 identification
`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
`
`FIG. 1 shows an example of a system for providing
`[0013]
`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 fixed or not mobile (e.g., a VoIP telephone, set-top box,
`personal computer, etc.).
`[0015] Mobile node 104 may be associated with identifica-
`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 identifiers 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 identification.
`[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)
`defined in 3GPP Interworking-WLAN (I-WLAN), packet
`data interworking function (PDIF) defined in 3GPP2, etc.
`[0017] Access device 106 is configured 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
`
`Page 9 of 14
`
`9
`
`Page 9 of 14
`
`

`

`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 identifier 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 identification 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.
`
`If mobile node 104 is authenticated, AAA server
`[0022]
`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 traffic 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 traffic 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 ofthe
`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, identification information for mobile node 104
`may be added to a blacklist that is maintained at AAA server
`102. For example, identification 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 identification 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 identification 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 ifthe 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 offloaded 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 11 0 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.
`
`In step 208, AAA server 102 sends a response to
`[0030]
`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
`
`ofthe 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.
`
`Page 10 of14
`
`10
`
`10
`
`Page 10 of 14
`
`

`

`US 2008/0220740 A1
`
`Sep. 11,2008
`
`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 configured 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 108
`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 notification. The Notification
`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.
`
`FIG. 6 shows another example of another network
`[0048]
`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
`
`FIG. 3 depicts an example of a method for process-
`[0032]
`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 first time
`a security issue is detected, but may be added after a security
`issue is detected a number of times.
`
`If the security issue warrants blacklisting, then in
`[0034]
`step 306, identification information, such as triplet informa-
`tion, the IMSI, etc. for mobile node 104, is added to the
`blacklist. For example, a notification is sent to AAA server
`102 andAAA server 102 adds the IMSI to a blacklist to note
`in a list of identification information that this mobile node is
`
`blacklisted (e.g., a flag 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 afiirmative 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 identifi-
`cation information for mobile node 104 is on the blacklist. If
`
`the identification 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 [
`
`If the IMSI is on the blacklist, in step 408, AAA
`0040]
`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.
`
`Particular embodiments may be used with different
`[0041]
`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
`
`Page 11 of 14
`
`11
`
`11
`
`Page 11 of 14
`
`

`

`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 ofthe 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 flows 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 flow
`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 first
`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 configured 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 identifica-
`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 offload pro-
`cessing from HLR 108 to AAA server 102. This also protects
`a link betweenAAA server 1 02 and HLR 1 08. Thus, HLR 1 08
`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 1 04 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 specific order,
`
`this order may be changed in different particular embodi-
`ments.
`In some particular embodiments, multiple steps
`shown as sequential in this specification 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, ofthe
`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.
`In the description herein, numerous specific details
`[0059]
`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 ofthe specific 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 specifically 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.
`
`this specification to “one
`[0063] Reference throughout
`embodiment”, “an embodiment”, “a specific 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 ofthe phrases “in a particular embodi-
`ment”, “in an embodiment”, or “in a specific embodiment” in
`various places throughout this specification are not necessar-
`ily referring to the same embodiment. Furthermore, the par-
`ticular features, structures, or characteristics of any specific
`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 modifications of the particular
`
`Page 12 of14
`
`12
`
`12
`
`Page 12 of 14
`
`

`

`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 specific integrated circuits, programmable
`logic devices, fieldprogrammable gate arrays, optical, chemi-
`cal, biological, quantum or nanoengineered systems, compo-
`nents and mechanisms may be used. In general, the functions
`ofparticular embodiments canbe achieved by any means as is
`known in the art. Distributed, networked systems, compo-
`nents, and/or circuits can be used. Communication, or trans-
`fer, of data may be wired, wireless, or by any other means.
`[0065]
`It will also be appreciated that one or more of the
`elements depicted in the drawings/figures can also be imple-
`mented in a more separated or integrated manner, or even
`removed or rendered as inoperable in certain cases, as is
`useful in accordance with a particular application. It is also
`within the spirit and scope to implement a program or code
`that can be stored in a machine-readable medium to permit a
`comput