Source: https://patents.google.com/patent/US20120185917A1/en
Timestamp: 2018-08-16 20:32:57
Document Index: 52070492

Matched Legal Cases: ['§ 1', '§ 1', '§ 1', '§ 1', '§ 1', '§ 0', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 0', '§ 4', '§ 4', 'art 1310', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4', '§ 4']

US20120185917A1 - Security extensions using at least a portion of layer 2 information or bits in the place of layer 2 information - Google Patents
Security extensions using at least a portion of layer 2 information or bits in the place of layer 2 information Download PDF
US20120185917A1
US20120185917A1 US13332890 US201113332890A US2012185917A1 US 20120185917 A1 US20120185917 A1 US 20120185917A1 US 13332890 US13332890 US 13332890 US 201113332890 A US201113332890 A US 201113332890A US 2012185917 A1 US2012185917 A1 US 2012185917A1
unique bit
US8793764B2 (en )
Although networking software and network reference models are known to those skilled in the art, they are introduced in §§ 1.2.1 and 1.2.2 below for the reader's convenience. Then, online transactions and security issues related to such transactions are discussed in § 1.2.3.
§ 1.2.3 ONLINE TRANSACTIONS AND SECURITY
In online transactions or e-commerce involving credit card transactions, the purchaser inputs the credit card information from a remote terminal, such as a computer terminal or telephone keypad, and this information is transmitted (typically in encrypted form) to the vendor. Obviously, the authorization and authentication techniques used for in-person transactions introduced above are less useful, if they are possible at all, with electronic credit card transactions. Accordingly, new security measures are needed to prevent or at least minimize fraudulent and unauthorized electronic credit card transactions. Some known authorization techniques and their perceived drawbacks are introduced in § 1.2.3.1 below.
§ 1.2.3.1 KNOWN CREDIT CARD AUTHORIZATION AND AUTHENTICATION TECHNIQUES AND THEIR PERCEIVED DRAWBACKS
The present invention uses information applied to a packet at an ingress port of a network for enhancing security. More specifically, the present invention may use such information for authentication of, for example, a user, a group, etc. Such authentication may be applied in addition to (i.e., as an extension of) other authentication measures. The information applied to a packet may be “context information” which replaces at least some bits of a layer 2 header, as is the case in the systems described in the patent applications listed in § 0 above and summarized in § 4.1 below.
§ 4.1 ENVIRONMENT IN WHICH THE INVENTION MAY OPERATE
FIG. 11 illustrates connections to, and processes that may be performed by, an aggregation unit 1030 and an access router 812, collectively referred to as edge devices 1100. The aggregation unit 1030 may be coupled with an access router 812 by one or more high bandwidth links. Redundant links may be used. Further, links from a number of customers 830 are coupled with ports 1110 of the aggregation unit 1030. Operations that may be performed by the aggregation unit 1030 and the access router 812 are described below in §§ 4.1.2 and 4.1.3, respectively. First, however, an example of context information is described in § 4.1.1.
§ 4.1.1 CONTEXT INFORMATION
§ 4.1.2 PARTS OF AN EXEMPLARY AGGREGATION UNIT
Each customer-facing physical port 1110 may have one or more associated logical interface process 1114 (also referred to as “logical interfaces” or “logical ports”), but a logical interface process 1114 may only be associated with one physical port 1110. Each logical interface process 1114 may be thought of as terminating a virtual channel (or “VC”). Thus, if the access facility technology supports virtual channels (e.g., ATM), then one physical interface 1110 can have multiple associated logical interface processes 1114, each supporting a virtual channel. If, on the other hand, the access facility technology does not support virtual channels (e.g., standard Ethernet), then the physical interface 1110 will have only one associated logical interface process 1114. The number of logical interface processes 1114 that a given aggregation unit 1030 can have may depend upon the design of context information, which was described above in § 4.1.1.
After the data has traversed the public transport network, it must get from the edge of the transport network to the customer device to which it was addressed. To this end, the context information may include (i) information to identify, uniquely, a customer, and (ii) information to identify, uniquely, an ingress logical interface as stated above in § 4.1.1. Further, various service level and service type agreements may be supported. To this end, the context information may further include (iii) information to identify a service level and/or a service type.
§ 4.1.3 PARTS OF AN EXEMPLARY ACCESS ROUTER
If, on the other hand, the data (packet) is received from the public transport network, access rights may be checked. Then, the data may be de-encapsulated (e.g., a de-encapsulation process 1139 may be called). This effectively removes the carrier information—such information is no longer needed since the data has already traversed the public transport network. An effective (layer 2) address of the proper logical interface 1114 is determined (e.g., an effective address determination process 1156 is called). For example, at least a part of the context information (e.g., the VPN-OUI and/or VPN-Index) and the (layer 3) destination address may be used to lookup an effective address of an appropriate logical interface 1114 in address resolution table 1158. The table 1158 may include a number of entries, each of the entries including at least a part of the context information and a (layer 3) destination address, and an associated effective (layer 2) logical interface 1114 address. The effective logical interface address may be defined as the 16 least significant bits of the VPN-OUI, prepended to the 32-bit egress logical interface identifier. The address resolution table 1158 may be populated based on updates from the edge information update facility, assuming that the customer device has a routed interface (e.g., a router, a PC, etc.). If, on the other hand, the customer device has a non-routed interface (e.g., switch, hub, etc.), the access router may use the aggregation device as a proxy for an ARP request. The data is then forwarded to the aggregation unit 1030 based on the effective (layer 2) logical interface 1114 address. Recall from § 4.3.2 above that the aggregation unit converts this effective address to the (layer 2) address of the customer device associated with the logical interface 1114.
Having described a system in which the present invention may be used, functions that may be performed by the present invention are introduced in § 4.2 below. Then, exemplary processes, data structures, methods and architecture for effecting the functions of the present invention are described in § 4.3 below. Thereafter, examples of an end-to-end operation of the present invention will be illustrated in § 4.4 below. Finally, some conclusions regarding the present invention are presented in § 4.5 below.
The present invention may function to enhance security by performing an authentication process that uses at least in part, information for identifying a user or customer provided by the network. This information provided by the network is not susceptible to control by an unauthorized user, thereby deterring or preventing fraud. More specifically, this information may be applied to a packet at an ingress port of a network. The information applied to a packet may be “context information” which replaces at least some bits of a layer 2 header, as is the case in the systems described in the patent applications listed in § 0 above and summarized in § 4.1 above.
§ 4.3 METHODS, DATA STRUCTURES AND ARCHITECTURE FOR EFFECTING THE FUNCTIONS OF THE PRESENT INVENTION
Some exemplary transaction types are illustrated. For example, purchases may be segregated into those no more than a predetermined amount (e.g., $ 500.00) and those more than the predetermined amount. In this exemplary table (defining a customer policy), notice that more of the context information is extracted (less bits are masked) for the more expensive (e.g., >$ 500.00) purchases. As another example of transaction type, transactions may be based on whether a purchased item is to be delivered to the billing address of the credit card or not. Again, notice that more of the context information is extracted (less bits are masked) when the item being purchased is to be delivered to an address other than the billing address of the credit card. In yet another example of transaction type, the transactions may be divided into purchase types such as airline tickets, hotel reservations and office supplies. Thus, a company may authorize certain of its employees (Recall, e.g., part 1310 of FIG. 13), such as sales representatives for example, to purchase airline tickets and make hotel reservations, while authorizing certain of its employees, such as office managers for example, to purchase office supplies. Note that a given transaction may fall into more than one transaction type. For example, office supplies may be for more than $ 500.00 and may be shipped to the credit card billing address. In such cases, each of the tests must be passed for authorization to be approved (e.g., the masks for each of the relevant transaction types may be logically ORed and the authorization codes for each of the relevant transaction types may be logically ORed). Thus, as can be appreciated from the foregoing examples, the level or type of authentication required may be a function of the type of transaction to be authorized.
Having described an exemplary method 1022′ for effecting the authentication process 1022, exemplary data structures 1024′ which may be used by the authentication process 1022, and an exemplary apparatus 1200 for effecting the authorization process 1022 and storing the data structures 1024, an example of an operation of an exemplary embodiment of the invention in the context of the system of FIGS. 8 and 9 is described in § 4.4 below with reference to FIG. 14.
§ 4.4 EXAMPLES OF OPERATION
In the following, examples illustrating possible operations of the present invention are provided. More specifically, § 4.4.1 illustrates an example of how the present invention may operate in the context of an environment, such as that described above with reference to FIG. 10A, in which both the transaction facility and the authentication facility are located outside the transport network. Section 4.4.2 illustrates examples of how the present invention may operate in the context of an environment, such as that described above with reference to FIG. 10B, in which the transaction facility is located outside the transport network, but the authentication facility is located within the transport network. Finally, section 4.4.3 illustrates an example of how the present invention may operate in the context of an environment, such as that described above with reference to FIG. 10C, in which the authentication facility and a hosted transaction facility are located within the transport network, but a client transaction facility is located outside the transport network.
§ 4.4.1 EXAMPLES OF OPERATION: AUTHENTICATION AND TRANSACTION FACILITIES LOCATED OUTSIDE TRANSPORT NETWORK
§ 4.4.2 EXAMPLES OF OPERATION: AUTHENTICATION FACILITY LOCATED WITHIN TRANSPORT NETWORK BUT TRANSACTION FACILITY LOCATED OUTSIDE TRANSPORT NETWORK
§ 4.4.3 EXAMPLES OF OPERATION: AUTHENTICATION FACILITY AND HOSTED TRANSACTION FACILITY LOCATED WITHIN TRANSPORT NETWORK
authenticating a party to a transaction only if the at least a part of the unique bit string examined matches the stored information.
38. The method of claim 37, wherein the at least a part of the unique bit string examined depends on a type of a transaction.
39. The method of claim 37, wherein the stored information compared with the at least a part of the unique bit string examined depends on a type of the transaction.
40. The method of claim 37, wherein the at least a part of the unique bit string examined identifies at least one of a location at which packets from the party to a transaction entered the network, an individual who is a party to the transaction, a group to which an individual, who is a party to the transaction, belongs, and a customer that is a party to the transaction.
41. The method of claim 37, wherein the act of authenticating does not require the transmission of any authentication information from the party.
receiving a packet associated with a transaction, the packet having at least a part of layer 2 header information replaced with a unique bit string;
43. The method of claim 42, wherein the at least a part of the unique bit string examined identifies at least one of a customer identification, an individual user identification, the network ingress location, and an individual user class.
44. The method of claim 42 wherein the unique bit string is provisioned by a network service provider.
45. The method of claim 42 wherein the unique bit string is controlled by a network service provider.
46. The method of claim 42, wherein the at least a part of the unique bit string examined depends on a type of transaction.
47. A device, comprising a processor and a memory, the memory storing instructions for:
48. The device of claim 47, wherein the at least a part of the unique bit string examined depends on a type of a transaction.
49. The device of claim 47, wherein the stored information compared with the at least a part of the unique bit string examined depends on a type of the transaction.
50. The device of claim 47, wherein the at least a part of the unique bit string examined identifies at least one of a location at which packets from the party to a transaction entered the network, an individual who is a party to the transaction, a group to which an individual, who is a party to the transaction, belongs, and a customer that is a party to the transaction.
51. The device of claim 47, wherein the act of authenticating does not require the transmission of any authentication information from the party.
52. A device, comprising a processor and a memory, the memory storing instructions for:
53. The device of claim 52, wherein the at least a part of the unique bit string examined identifies at least one of a customer identification, an individual user identification, the network ingress location, and an individual user class.
54. The device of claim 52, wherein the unique bit string is provisioned by a network service provider.
55. The device of claim 52, wherein the unique bit string is controlled by a network service provider.
56. The device of claim 52, wherein the at least a part of the unique bit string examined depends on a type of transaction.
comparing the at least a part of the unique bit string examined with stored information;
authenticating the party only if the at least a part of the unique bit string examined matches the stored information.
US20120185917A1 true true US20120185917A1 (en) 2012-07-19
US8793764B2 US8793764B2 (en) 2014-07-29
US6363071B1 (en) 2000-08-28 2002-03-26 Bbnt Solutions Llc Hardware address adaptation
US8793764B2 (en) 2014-07-29 grant