HK1157971A - Method and apparatus for avoiding unwanted data packets - Google Patents

Abstract

Method and apparatus for controlling transmission of data packets in a packet-switched network. When a first end-host (A) sends an address query to a DNS system (300) for a second end-host, the DNS system responds by providing a sender key created from a destination key registered for the second end-host, if the first end-host is authorised to send packets to the second end-host. Thereby, the first end- host, if authorised, is able to get across data packets to the second end-host by attaching a sender tag (TAG) generated from the sender key, as ingress tag to each transmitted data packet. A router (302) in the network matches an ingress tag in a received packet with entries in a forwarding table and sends out the packet on an output port (X) according to a matching entry. Otherwise, the router discards the packet if no matching entry is found in the table.

Description

Method and apparatus for avoiding unwanted data packets

Technical Field

The present invention relates generally to a method and apparatus for controlling the transmission of data packets in a public packet-switched network, such as the internet, so that unwanted data packets can be avoided.

Background

Packet-based transmission of digitally encoded information between different parties over an IP (internet protocol) network is used for a variety of communication services, such as e-mail messaging, internet browsing, voice and video telephony, content streaming, gaming, and so forth. Digitally encoded information is configured into data packets at a sender and then the data packets are transmitted over a transmission path to an intended recipient. The transmission path between the sender and the receiver may include various networks, switches, gateways, routers, and interfaces. The correspondent, commonly referred to as an "end-host," may be any type of device capable of packet-based IP communications, such as fixed and mobile phones, computers, servers, game stations, and the like. In this specification, the term "end host" will generally denote any such communication device.

Typically, an end-host connected to the internet or other IP network has been assigned a forwarding identity in the form of an IP address required to route any data packets directed to that end-host along a transmission path. Typically, the end hosts have also been assigned more or less understandable names in the form of text strings, such as traditional email addresses or web addresses,com. e.g. user @ operatorAssociated with the assigned IP address of the actual user/end-host or some other host that receives messages on behalf of the user. A DNS (domain name server) system comprising a DNS server hierarchy is used to retrieve the current IP address of a particular host name. Thus, the end-host can query the DNS system for the host name to communicate with, and the DNS will then reply by providing the current IP address of the corresponding end-host. This type of query is sometimes referred to as a destination query, an identification query, or an address query, whereThe latter is used throughout this specification.

Data packets are basically configured with a data field containing payload data and a header field into which the sending end host inserts the destination address of the target end host (i.e. the IP address obtained from the DNS system). Each data packet is therefore routed through a plurality of network nodes (commonly referred to as IP routers) along appropriate transmission paths based on the destination address in the header field of the packet.

In addition to simply receiving and forwarding data packets, IP routers may also be capable of performing other functions, such as security functions, packet scheduling, and translation of addresses and protocols. Further, the end host may have: a filter/firewall function for determining whether incoming data packets should be admitted or dropped, e.g., according to settings typically made by a user or administrator associated with the end host.

Typically, each router in an IP network comprises: an ingress unit and an egress unit acting as interfaces for receiving and transmitting data packets, respectively. The router further comprises: a routing or forwarding function for determining to which router an incoming data packet should be sent as a "next hop" based on a forwarding table defined in the router. As is known in the art, data packets may be routed along multiple alternative paths, typically depending on the network topology and current traffic load.

Links to the "nearest" neighboring routers are provided in each router through the corresponding ports, and a forwarding fabric is also configured in the router based on the distribution of topology information and link information. Each port may be configured with an IP address and an IP mask on its interface, and the routing protocol is used to distribute this information among the routers in the network during the configuration process. Each router then calculates its own forwarding table, containing a plurality of destination IP addresses and associated outgoing ports, according to the distributed topology information. Since each incoming data packet has a destination IP address in its header, a forwarding table is used from which to look up the appropriate entry. The main functions of the forwarding table are therefore: for each incoming packet, an appropriate outgoing port leading to the next hop router is determined.

In fig. 1, the basic structure of a conventional IP router 100 is shown when located in an IP network. Therein, the IP router 100 comprises an ingress part 100a, an egress part 100b, and a forwarding function, here schematically represented by a forwarding table 100 c. The outlet portion 100b includes: multiple outgoing ports P_A、P_B、P_C… …, respectively, to different neighboring routers A, B, C … … directly connected to the router 100. Any incoming data packet 102 has a payload field PL and a header H, the latter containing the destination address of the packet.

Forwarding table 100c is made up of a plurality of entries, where each entry contains an IP mask, an IP address, and an outgoing port number. The IP mask may be defined in hexadecimal code string such as ff.ff.ff.0 or ff.ff.8.0. Briefly, the destination address in header H is combined with the IP mask in forwarding table 100c by applying a logical AND operation to detect a matching entry having the same IP address. The purpose of this masking mechanism is to: aggregating (aggregating) traffic destined for a plurality of different destinations; and simplifying identification of outgoing ports for the aggregation. In fact, the bit mask functions similarly to a "wildcard" when comparing and matching the destination address to the entry. Once a matching entry is found, the packet may be sent out on the outgoing port based on the port number of the entry.

Thus, an incoming data packet 102, which may have been forwarded to the router 100 from a previous router (not shown), is first received at the ingress unit 100 a. It is then determined which next router the packet should be sent to based on the destination address in header H and using forwarding table 100c and the logical and operation described above. In this example, the destination IP address of the incoming packet 102, when combined with the mask, is combined with the port number P in the forwarding table 100c_CThe IP address of the entry of (1). Therefore, the temperature of the molten metal is controlled,the packet 102 is sent out on the corresponding port connected to router C.

As described above, routing protocols are used to distribute topology and link information among routers in an IP network. The currently used routing protocols are configured to obtain "resilience", i.e. in case of a link or node failure in the original path, the packet has to be rerouted in a different path. Routing protocols are also configured to facilitate router management, as configuring routers is typically a cumbersome task that is generally expected to be simplified. Thus, in the event of a detected failure of a link or node, the routing protocol will reconfigure the forwarding tables in the affected routers while distributing information to the routers, thereby simplifying management. To achieve scalability, which is still an inherent problem in the routing architecture, the routing process may use traffic aggregation based on a hierarchical bit mask scheme, which is well known in the art and need not be described further herein.

However, the main problems in IP networks and the internet are: as explained below, security support is generally insufficient. In a sense, the above resilience can sometimes make a packet "too easy" to pass through the network. This is because current routing architectures and protocols were originally designed for "friendly" environments, i.e., assuming that no "illicit" or "malicious" users are communicating in the IP network, and that data packet transmissions do not have to be protected. However, it has been found necessary or desirable to add various security schemes to the IP architecture to protect communicated data, such as IP-sec at lower layers and TLS (transport layer security) at higher layers. These protocols may provide authentication and encryption of data packets. Further, MPLS (multiprotocol label switching) is a scheme for constructing a layer 3VPN (virtual private network) to ensure secure communication. In the case of VPNs, when an intranet is used, private addressing is required and the network is isolated to some extent from the public internet so that external unauthorized hosts are not allowed to reach and communicate with hosts attached to the intranet.

Other prior art solutions for providing security in routing protocols include: secure communication between routers such that an entity without violation can eavesdrop, manipulate, or impersonate a router; establishing an IP-sec tunnel between router ports to protect packet transmission between routers; and layer 2 link security, for example according to IEEE 802.1AE or IEEE 802.10. Various authentication procedures using cryptographic keys may also be used, e.g. according to DNSSec (DNS security), HIP (host identity protocol) and CGA (cryptographically generated addresses), in order to enhance security. However, while protection is taken against unwanted traffic (e.g., spam filtering of email) for certain applications, basic protection against violating end hosts and unwanted data packets has not generally been provided in the public IP infrastructure.

Since the internal forwarding identities (i.e., IP addresses) are publicly distributed end-to-end in the manner described above, essentially any end host is able to send messages and data packets to any other end host over the internet, leading to the well-known problems of flooding, spam, viruses, fraud and so-called "denial of service" (DoS) threats. Therefore, the following problems have generally occurred: any end-host can propagate data packets completely out of the control of the receiving end-host, and public packet-switched networks such as the internet do not have a mechanism in the IP infrastructure to prevent routing data packets from a potentially illicit or malicious end-user to the recipient.

Although more or less complex functions, such as filters/firewalls etc., may be added at the end user or in the link layer to restrict the connection. However, these schemes are "last line of defense" schemes, meaning that although packets are dropped at the receiver anyway, the transmission of unneeded data packets can consume network resources along the entire sender-receiver path.

Disclosure of Invention

It is an object of the present invention to address at least some of the above problems. Furthermore, it is an object of the invention to obtain a mechanism for avoiding the transmission of unwanted data packets in a packet switched network. These objects, among others, are achieved by providing a method and an apparatus according to the definitions in the appended independent claims.

According to an aspect, a method in a router is provided for controlling data packet transmission in a packet switched network. When a data packet is received comprising an ingress label derived by a sender key or a router key using a first label derivation function TDF known to the router, a matching operation is performed on at least one entry in the forwarding table and the received ingress label. The entry comprises an entry key and a corresponding outgoing port number. The matching operation is performed using the first TDF to determine whether the received entry tag matches the entry key in the table entry. If a matching entry is found, the packet is sent from the outgoing port indicated in the matching entry to the next hop node. Otherwise, if no matching entry is found, the packet is discarded.

In one embodiment, each matching operation includes: the first TDF is applied to candidate entry keys in rows of the forwarding table to derive candidate entry labels. A match is deemed to be found if the candidate ingress tag satisfies a predetermined relationship with the received ingress tag in the packet. The predetermined relationship may be equal, i.e. a match is considered to be found if the candidate ingress tag is equal to an ingress tag in the packet.

In another embodiment, the egress label is created by applying a second label derivation function TDF' to an egress key in the matching entry, said egress label being attached to said data packet when sent to said next hop node.

In another embodiment, the received data packet also contains a key index pointing to an entry or set of entries in the forwarding table, which is used to find the appropriate entry for the matching operation.

According to another aspect, there is provided an arrangement in a router of a packet switched network for controlling data packet transmission in the network. The router apparatus includes: an ingress unit adapted to receive a data packet having an ingress label derived from the sender key or the router key using a first label derivation function TDF known to the router. Furthermore, the tag matching unit is adapted to perform a matching operation on the received ingress tag and at least one entry in the forwarding table, said entry comprising an ingress key and a corresponding outgoing port number, using the first TDF to determine whether the received ingress tag matches the ingress key in said entry. The router apparatus further comprises: and the exit unit is used for sending the data packet to the next hop node, wherein if a matching table entry is found in the forwarding table, the data packet is sent from an outgoing port indicated in the matching table entry, and otherwise, the data packet is discarded.

In one embodiment, the apparatus further comprises: a tag creation unit adapted to create an egress tag by applying a second tag derivation function TDF' to an egress key in the matching entry and to attach the egress tag to the data packet when the data packet is sent to the next hop node.

According to another aspect, a method is provided in a DNS system for controlling data packet transmission in a packet-switched network. Destination keys are registered for the end hosts and router keys are distributed to routers in the network, each router key being derived from the registered destination key representing the end host and/or from network topology information. Upon receiving an address query from the first end-host relating to the second end-host, a sender key is created by applying a key derivation function KDF to at least the destination key associated with the second end-host. The sender key is then sent to the first end-host, thereby enabling the first end-host to propagate the data packet to the second end-host by attaching a sender tag generated by the sender key to the transmitted data packet, the sender tag directing the packet to the second end-host.

In one embodiment, to process the query, the first end-host needs to be authenticated and the query is rejected if the first end-host is not authenticated. The first end-host may require authorization via DHCP, and the DHCP server may then provide the first end-host with a way to query the DNSS server system only if the first end-host is authorized via DHCP.

In another embodiment, a policy defined for the second end-host is applied to the query to determine whether the first end-host is authorized to send data packets to the first end-host, and the query is rejected if the first end-host is not authorized.

In other embodiments, the sender key is created by applying the KDF also to the identity of the first end-host and/or to a timestamp and/or to a random number. The router keys may represent individual end hosts or sets of end hosts according to the network topology and the location of those end hosts relative to the network topology. Key indices may be distributed to routers in a network, each key index identifying at least one of the router keys.

According to another aspect, an apparatus is provided in a DNS server system for controlling data packet transmission in a packet-switched network. The DNS device includes: a host database for registering a destination key associated with the terminal host; and a router key manager adapted to distribute router keys to the routers, each router key being derived from a destination key representing an end host and/or from network topology information. The DNS device further includes: an address query manager adapted to receive an address query from the first end-host relating to the second end-host, to create a sender key by applying a key derivation function to at least a destination key associated with the second end-host, and to send the sender key to the first end-host in response to the address query. The first end-host is thereby able to propagate the data packets to the second end-host by attaching a sender tag generated according to said sender key to the transmitted data packets, said sender tag directing said packets to the second end-host.

According to another aspect, a method is provided in an end host device for use by a first end host for enabling control of data packet transmission in a packet-switched network. An address query for the second end-host is sent to the DNS system. In response thereto, a sender key derived from a destination key associated with the second end-host is received from the DNS system, the sender key being derived by applying a key derivation function KDF to at least the destination key associated with the second end-host. The sender tag is created by applying a tag derivation function TDF at least to the received sender key. The created sender tag is attached to a second end-host directed data packet that is sent to the first-hop router.

In one embodiment, a key index identifying one or more router keys in a forwarding table of a first hop router is also received from the DNS system in response to the query, and the key index is attached to a data packet transmitted by a first end-host to a second end-host. The sender tag may be created by applying TDF also to at least a portion of the payload in the packet and/or to a random number.

According to another aspect, there is provided in an end host device, means for use by a first end host for effecting control of transmission of data packets in a packet-switched network. The device comprises: an address querying unit adapted to send an address query for the second end-host to a DNS system and to receive from the DNS system a sender key derived from a destination key of the second end-host. The device further comprises: a tag creation unit adapted to create a sender tag by applying a tag derivation function TDF at least to the received sender key; and a packet transmitting unit adapted to attach the sender tag to a data packet and then transmit the data packet to a first-hop router.

Other possible features and advantages of the present invention will become apparent from the following detailed description.

Drawings

The invention will now be described in more detail by way of example embodiments and with reference to the accompanying drawings, in which:

fig. 1 is a schematic block diagram illustrating a conventional router in an IP network according to the prior art.

Fig. 2 illustrates a typical transmission path scenario for routing data packets from a sending end host a to a receiving end host B, which may utilize the present invention.

FIG. 2a illustrates a portion of an example forwarding table in accordance with one embodiment.

Fig. 3 is a block diagram illustrating how a sending end host a may propagate data packets in a first hop router, according to other embodiments.

Figure 4 is a flow diagram of steps in a process performed by a DNS server system to control transmission of data packets in a packet-switched network, according to another embodiment.

Fig. 5 is a flow diagram of steps in a process performed by a packet-sending end-host in a packet-switched network to implement control of data packet transmission, according to another embodiment.

Figure 6 is a flow diagram of steps in a process performed by a router in a packet-switched network to control transmission of data packets, according to another embodiment.

Figure 7 is a schematic block diagram illustrating in more detail a DNS server system and routers in a packet-switched network, according to other embodiments.

Fig. 8 is a schematic block diagram illustrating an end user device in more detail according to another embodiment.

Detailed Description

The present invention provides a mechanism for controlling the transmission of data packets along a transmission path between a sending end-host and a receiving end-host over a packet-switched network. In particular, the end-host may be protected from receiving unwanted data packets in the manner described below. A typical transmission path scenario is schematically illustrated in fig. 2, where the following nodes are basically involved in transmitting a data packet according to the following embodiments: and first hop router R₁A connected sending end-host a, a plurality of intermediate routers R potentially usable in the transmission path, and a last-hop router R connected to a receiving end-host B_x(ii) a It also relates to a DNS server system for processing address queries Q and generally distributing routing information 1 to routers.

According to the embodiments described below, a security scheme may be built into the core protocol of the forwarding architecture used by routers in the network. Generally, as described above, any packet transmitted over a public packet-switched IP network must pass through a forwarding mechanism in the forwarding plane of the router in the transmission path. By embedding packet forwarding control mechanisms within the forwarding plane in a router (as described below), the resulting security will be effectively implemented in the IP infrastructure to control the routing of any packets passing through the router.

Briefly, a predefined implicit destination key associated with the target end-host and a preconfigured router key associated with the destination key and the network topology are used instead of using an explicit IP address for routing data packets through the IP network. Thus, the DNS system registers such destination keys for end hosts that are potential recipients of data packets, and provides corresponding sender keys instead of IP addresses in response to an "address query" or the like from a querying end host for a target end host. In this specification, the term "address query" should be understood as any query for information that may be used to authorize communication of data packets to a target end host. The sender key is created by applying a "key derivation function KDF" to at least the destination key and optionally also to the identity of the querying end host, as will be described in more detail below. Thus, the destination key is effectively "hidden" in the sender key.

The inquiring end-host then also derives a sender tag from the obtained sender key by applying a "tag derivation function TDF" to the sender key and inserts the sender tag in the header of each transmitted data packet of at least the ongoing data flow or session with the receiving target end-host. Thus, the sender tag implicitly encodes the destination key of the target end-host.

Further, the DNS system creates different router keys based on the registered destination key and/or network topology and distributes the router keys to routers in the IP network. The router then configures its forwarding table through the distributed router key. As indicated above, the created router keys may be dependent on the network topology, where the router keys may point to destinations in the network or groups of routers to achieve aggregation, thereby reducing the forwarding table size in the routers. Optionally, the DNS system may also distribute key indices for inclusion in the forwarding table, each key index pointing to one or more rows in the table having a different router key to facilitate forwarding operations in a manner described below. In practice, the DNS system can essentially assign a key index to each router key.

Thus, an entry of the forwarding table in the router has a router key, a corresponding outgoing port, and optionally a key index. Instead of an IP address, a label is included in the header of each transmitted data packet, the label being created by applying a TDF to the sender key and/or router key depending on whether the packet is sent from the sending end host or forwarded by the router. In this specification, the label in a transmitted or forwarded packet is generally referred to as an "egress label" derived from an "egress key", while the label in a received packet is referred to as an "ingress label". Further, the "entry key" is the key from which the received entry tag is derived.

In a forwarding operation performed by a router that has received a data packet containing an ingress label, the ingress label is matched to an ingress key in a forwarding table, and if a matching entry is found, the corresponding outgoing port in that entry is selected to issue the packet. A new egress label derived from the egress key in the matching entry is also attached to the packet header before the packet is sent out on the outgoing port to the next hop router. Alternatively, the ingress label of a received packet may be reused as the egress label (i.e., the label in the packet is not changed) when forwarding the packet to the next hop router according to the forwarding table configuration in the router performing the forwarding operation.

If no matching entry is found in the table, the packet may be processed according to a "default policy" (e.g., indicating that the packet is dropped and no longer forwarded). Typically, a router will employ this strategy if some unauthorized sending end-hosts, which do not know the appropriate key, attempt to propagate data packets with "fake" labels inserted.

When the next hop router receives the packet, the process will essentially repeat. If a key index is used, the key index in the ingress tag of the received packet will point directly to an entry, or to a limited set of entries in the forwarding table, thereby identifying the ingress key in the entry. The router may then restrict the matching operation to the entry key identified by the key index.

In this way, by not exposing the destination/sender/router keys to unauthorized parties, it is not possible to intercept display end-host addresses or identities that may be used by other hosts to propagate data packets. Thus, sending unsolicited data packets to those end hosts may be avoided. The sender and router keys and, optionally, the key index are therefore useful in forwarding operations performed by routers in the transmission path, the manner of which is described in more detail below with reference to specific example embodiments. It should be noted, however, that the use of such keys and labels does not necessarily preclude the use of traditional IP addresses for routing data packets, and that traditional IP address routing and the key/label routing of the present invention can be implemented well within the same network.

Fig. 2a illustrates a forwarding table that may be used in the present scheme, where an example entry or table row is denoted by "x". The table has a plurality of columns 200, 210, including a first column 200 having an entry key index "Iki" that can be used to look up one or more appropriate entries to perform a matching operation, i.e., to match the entry label attached to an incoming packet with the entry key "IK" appearing in a second column 202 in the table. A single entry key index may point to a collection of multiple entries in the table to which the matching operation may be restricted.

The third column 204 contains an egress key "EK" from which a new egress tag is created for inclusion in the forwarded packet once a matching entry is found. The fourth column 206 contains the egress key index "EKi" to be attached to the outgoing data packet, which will actually be used as the ingress key index when received by the next hop router. The fifth column 208 contains a port number "P" indicating the port on which the received and matching packet is to be sent out to the next hop router.

Finally, an optional sixth column 210 may include: various additional data "D", may be policy rules, etc., such as "drop packet", "use default port", "use aggregation … …", "retrieve new router key from DNS", "request previous hop router to explicitly authenticate itself", etc. If the key index is not used, columns 200 and 206 would be omitted naturally. Furthermore, the same label may be used unchanged as an egress and ingress label on two or more routers in the transmission path. In this case, columns 204 and 206 may be ignored and each router receiving a data packet with an ingress label may find the appropriate outgoing port in column 208 simply by matching the ingress label with the ingress key in column 202. The ingress label is then reused as the egress label, and if a key index is used, the key index does not change when the packet is forwarded to the next hop router. Alternatively, the egress key EK may be equal to the ingress key IK, but still perform a new calculation of the egress label, e.g., including a new random number (nonce) for randomizing the egress label as described in more detail below.

Figure 3 is a block diagram illustrating how transmission of data packets sent from end host a to a target end host (not shown) may be controlled in a packet-switched network having a particular network topology, according to some example embodiments. The process is shown as a series of acts or steps involving primarily end host a, DNS system 300 directly connected to end host a, and first hop router 302.

In a first step 3: in 1, destination keys associated with respective end hosts B, C, D … … are registered and stored into DNS system 300, where each unique destination key actually identifies or "defines" a corresponding destination, i.e., end host. In this process, the destination key may be determined in an agreement between the end-host and the DNS system, preferably after authentication of the end-host. In fact, this step may replace the assignment of an IP address to an end host according to the prior art. Furthermore, the destination key does not have to be arranged in the hierarchical system, and a "flat" naming structure may be used.

The DNS system 300 also proceeds to the next step 3: the router key is derived from the above registered destination key and network topology in 2, and a key index may also be defined for each router key. Each router key may be derived from a destination key or from a set of aggregated destination keys, the aggregation being based on the network topology and the location of the corresponding end host. If a key index is used, each key index identifies a router key or a set of router keys. The DNS system 300 then typically in a further step 3: the router key and optional key index are distributed in 3 to routers in the router domain of the network, including router 302 shown here.

The router can then configure its own forwarding table accordingly, including the distributed router keys and alternate key indices to be used for forwarding incoming data packets, thereby creating a useful forwarding architecture in the network. This forwarding operation will be described in more detail later. Essentially, comprise inIs transmitted intoThe label included in the data packet is an ingress label corresponding to an ingress key as a router key, and is included inIs delivered outThe label in the data packet is an egress label corresponding to the egress key as a router key. Thus, the router key may be an ingress key or an egress key, or both.

As described above, a router key may also represent a single destination or an aggregated set of multiple destinations. In the latter case, the number of entries in the forwarding table will be substantially reduced. If a key index is used, the operation of matching the ingress key of an incoming packet with a router key in a forwarding table may be facilitated in a manner described later.

The distribution of the router keys and optionally key indices associated with the destination key and network topology may be performed during a configuration process or otherwise (e.g., using a routing protocol, such as when configuring a conventional forwarding architecture in a router domain as described above). The router may then configure its forwarding table with entries including different ingress and egress keys and outgoing ports based on the distributed router keys and other topology information. The distributed router keys may in fact include an ingress key and an egress key. A particular key server may be responsible for distributing router keys to routers in a domain, although illustrated here as actions by DNS system 302 for simplicity. However, the distribution of the router keys may be done in different ways, e.g. in a more dynamic way triggered by an address query from the end host, or in a way responsive to a query from the router, as will be described later.

Returning to the example of fig. 3, end host a desires to communicate with the target end host, and at some point, at the next step 3: in 4, an address query or the like is accordingly sent to the DNS system 300 in a conventional manner as described above, for example referring to an email address or a web address of the target terminal host. Optionally, DNS system 302 may then apply a policy defined for the target end host to the query to determine whether the querying end host is authorized to send data packets to the target end host. Other policies (e.g., indicating routing of communications) may also be applied to use a particular operator network and/or avoid another operator network, or use a particular service, or redirect packets to another recipient, etc.

Assuming end host a is authorized and may be allowed to send packets to the target end host, DNS system 300 retrieves the destination key associated with the target end host and, at the next step 3: the sender key is created from the destination key in 5. The sender key is created by applying a key derivation function KDF to at least the destination key and optionally also to other data such as the identity of the querying end-host, a timestamp and/or a random number for randomization (commonly referred to as "RAND" or "NONCE"). This can be expressed as:

sender _ key ═ KDF (Destination _ key, < other data >) (1)

If the identity of the inquiring end-host is used as "other data" in (1), the sender key will be uniquely associated with that end-host. Preferably, the KDF may be a cryptographic function or the like.

Then, in a further step 3: in 6, DNS system 300 responds to step 3: 4, providing the end host a with a sender key so that the end host a can derive a sender tag therefrom and send the data packet with the sender tag attached as an ingress tag to the target end host. First hop router 302 of end host a also needs to have access to the same sender key to perform a matching operation on the ingress label, which is the sender label generated by the sending end host. This can be achieved in different alternative options including the three examples described below.

The first option is:assuming that a key index is used and the DNS system knows which first hop router to use, DNS system 300 can also at step 3: end host a is provided with a predefined key index in 6 that is associated with the previously distributed router key (i.e., the key corresponding to the destination of the target end host). Thus, the key index points to the correct row or set of rows in the forwarding table of first hop router 302, providing the outgoing port to which the appropriate next hop router is connected.

The second option is as follows:router 302 may receive in a notification from DNS system 300 that end host a has issued an address query to a target end host, the notification that in step 3: 5 or router 302 may retrieve the sender key from the DNS system upon receiving the first data packet from end host a. Router 302 will then reconfigure its forwarding table by adding the sender key and also additional information indicating the relationship between the network topology and the traffic destination, which need not be described further herein.

A third option:DNS system 300 in step 3: included in 6 is an encrypted copy of the sender key provided to end host a as to be included in the generated sender tag of the data packet. This may be done using a similar scheme as "Kerberos," where DNS system 300 encrypts a copy of the sender key with a specific encryption key known (only) to the router.

To send a data packet to the target end-host, in a next step 3: in 7, the end-host a applies a predefined first label derivation function TDF at least to the received sender key in order to create a sender label "TAG" to be inserted as an egress label in the transmitted packet. Depending on the implementation, TDF may also be applied to "other data" such as payload data contained in the packets to be transmitted, timestamps, and/or RAND or NONCE for randomization. This can be expressed as:

sender _ tag ═ TDF (Sender _ key, < other data >) (2)

If the payload in the packet is included in the "other data", the sender tag will be unique to the packet. The TDF may be a cryptographic function or the like. End host a may have been pre-configured to use TDF in transmitting data packets, or at step 3: TDF may be submitted to terminating host a with the sender key in 6. In addition, TDF is also known in the network (at least to first hop router 302). According to different options, the TDF to be used may be a predetermined negotiated parameter (e.g. pre-configured network-wide and out-of-band), or end host a may select a TDF to be used from a predetermined set of TDFs known in the network and then include a predetermined identifier of the TDF in the tag itself.

If in step 3 above: receiving the corresponding key index from DNS system 300 in 6, end host a may also include the corresponding key index in the sender tag, and, if the above third option is used, end host a may also include a Kerberos encrypted copy of the sender key in the sender tag. Attaching the sender tag to the transmitted data packet will effectively authorize the packet to be routed through the network to its destination. If the router detects that the received data packet does not contain any valid sender tag, the packet cannot be authorized and can simply be discarded.

In a further step 3: in 8, end host a sends data packets with the created sender TAG "attached as an egress TAG to the target end host, possibly sending them when using key indices and other data, for reception by ingress portion 302a at router 302. The sender tag may be inserted into the destination field in the packet header as is conventionally done for destination IP addresses according to the prior art. When the sender TAG "TAG" is received as an incoming packet at router 302, the sender TAG "TAG" is an ingress TAG, and if a key index is used, the key index is an ingress key index.

Up to now it has been assumed that end host a is authorized to send packets and furthermore a is compliant in the sense of complying with the above described embodiments (e.g. according to one of the three options). However, it should also be appreciated that the situation when the sending end-host is not authorized to send packets and/or is not compliant, and simply attempts to generate a valid sender tag without the assistance of a DNS. However, by properly selecting TDF as a strong cryptographic function, any such forgery attempt will most likely be unsuccessful and can thus be ignored. In this specification, it is assumed that the end host a is authorized and compliant.

As a first hop router, router 302 must be able to detect the sender key from which the attached sender tag was created. This may be achieved, for example, according to the different options described above, which are discussed further below:

in a first option:if DNS system 300 can predict the identity of the first hop router to be used by end host a, DNS system 300 can simply derive the sender key so that the first hop router can also use existing entries in its forwarding table, or so that the router can use the aggregation destination already provided in the forwarding table.

In a second option:first hop router 302 explicitly receives the sender key from DNS system 300, for example, by: 8 or in step 3: 4-3: after 6, the sender key is acquired in the notification from the DNS system 300. The key may then be cached in the router (e.g., as an update to the routing table) in preparation for receiving other packets from a.

In a third option:using the Kerberos method described above, DNS system 300 in step 3: included in 6 is a copy of the sender key provided to end host a, encrypted by a "group encryption key" KR known to, for example, the router. End host a then includes the encrypted copy in the generated transmissionIn the party/entry tag, where the first hop router may retrieve the sender key by decrypting with KR.

The forwarding unit 302b at the router 302 is generally configured to perform a forwarding operation on each incoming data packet by means of a forwarding table schematically shown in the forwarding unit 302b to find an outgoing port in the egress unit 302 c. In a further step 3: in 9, the forwarding unit 300b performs a matching operation on the attached ingress TAG "and a different ingress key IK in the forwarding table using the known first TAG derivation function TDF to find a matching entry in the table. In other words, the forwarding unit 300b attempts to match the received ingress label with the ingress key IK for one entry at a time in the table. It should be noted that in first hop routers, the entry key in the table will mostly correspond to the sender key.

In more detail, the matching operation may include: the router applies the TDF to a "candidate" ingress key in a row of the forwarding table to derive a candidate ingress label. A match is deemed to be found if the candidate ingress tag satisfies a predetermined relationship with the ingress tag in the packet. The predetermined relationship may be equal, i.e., a match is considered to be found if the candidate ingress tag is the same as the ingress tag in the packet. If the two labels do not match, the next candidate key in the table is tried, and so on. If an entry key index Iki is included in the received packet, then only the matching operation must be performed on the entry or entries in the table that contain the entry key index Iki. Thus, using the ingress key index Iki will effectively speed up the matching operation for each received data packet.

If in step 3: 9, then in the next step 3: the port in the entry, in this case port p (x), is determined in 10 to be the outgoing port of the packet. If in step 3: if no matching entry is found in 9, then the packet is not authorized and thus will be processed in step 3: the packet is dropped 10, thereby stopping the forwarding of any such packets. Performing a matching operation will effectively validate the packet for further transmission. If a key index is used, the appropriate port can be found and the packet forwarded by the key index alone, although step 3 can still be performed, preferably for security: 9.

In the next step 3: in 11, after finding the packet to be authorized in the forwarding operation above, the forwarding unit 302b applies the second TAG derivation function TDF 'to the egress key EK in the matching entry to obtain a new egress TAG "TAG'" attached to the packet. If the next hop router is to perform a matching operation on the packet as well, the next hop router should be aware of TDF' to achieve the matching operation. TDF and TDF' may be different or equal functions. Thus, the new exit TAG' can be expressed as:

egress _ tag ═ TDF' (Egress route _ key, < other data >) (3)

(3) The "other data" in (b) may be payload data contained in the packet to be transmitted and/or RAND or NONCE used for randomization.

If the key index is used, then in step 3: the exit key index EKi of the matching entry is also attached to the packet in 11, for example in the destination field of the packet header. The attached EKi will then be used in the next hop router as the entry key index IKi to find the relevant row in its forwarding table, to perform a matching operation, and so on. As described above, an unchanged ingress/egress label may be used between two or more successive routers, thereby substantially omitting step 3 above: 11.

then, in the next step 3: the packet is forwarded to port p (x) of egress unit 302c in 12. Finally, in a last step 3: in 13, the packet with the new egress TAG' attached is issued on port p (x) as the next hop. The next hop router will then be able to match the new ingress label TAG' with entries in its forwarding table to determine the next hop in the same manner as described above. The last router Y in the transmission path connected to the target end host may not apply TDF to perform the steps according to step 3: 11 create a new egress label since the target end-host does not need to read the destination field at all.

In step 3: the router keys distributed in 3 that form the basis of the forwarding tables in the routers can be defined by the DNS system 300 as follows:

route _ key KDF (Destination _ key, < other data >) (4)

In the example of (4), the router key represents a single destination, i.e. end host, having the destination key in question. However, if aggregation is used, the router key may represent a set of multiple destinations (i.e., end hosts) according to the network topology and the location of those end hosts/destinations. However, the creation of such an aggregated router key is outside the scope of the present invention. Furthermore, a tag, header extension, etc. may be attached to the data packet to indicate the structure or format of the packet, i.e. with respect to the ingress tag and optionally also with respect to the key index.

Additional security may also be added to authorize the querying end-host at the DNS system in the following manner: initially, when an end-host sends an address query to the DNS system (e.g. in step 3: 2 above), the end-host must know the address of the DNS system or the corresponding destination identity for such a query. The DNS address may be a well-known address, but it may also be obtained only from a DHCP (dynamic host configuration protocol) server as a node well-known in the art. In one embodiment, the DHCP server provides the DNS tag required to make queries that can only be obtained by the host after authentication and authorization via DHCP. If the address query lacks the required label for DNS, the query will be rejected and the querying end-host is prevented from sending packets to the target end-host. In this way, unsolicited data packets can be avoided by allowing only end hosts that are authoritative for DNS/DHCP to propagate data packets during forwarding in the router.

Figure 4 is a flow diagram of steps in an example process performed by a DNS server system (e.g., DNS system 300 in figure 3) to control transmission of data packets in a packet-switched network. In a first step 400, a destination key is registered for different end hosts and router keys derived from the destination key and the network topology are distributed to routers in the network. In practice, the router key may be distributed from the DNS system or from an associated key server or the like. Step 400 may be performed during configuration or otherwise.

In a next step 402, an address query is received from the first end-host at a time, basically requesting the destination address of the target second end-host, etc. The address query may be made in a conventional manner, e.g., as described above, for example, referring to an email address or web address of the target end host.

In a further step 404, if the first end-host is authorized to send data packets to the second end-host, the DNS system creates a sender key by applying a key derivation function KDF at least to the destination key associated with the second end-host. If not, the query may simply be rejected. The KDF may further be applied to other data, such as to the identity of the first end-host, to make the sender key unique to the first end-host, for example according to (1) above. Alternatively, as described above, in order to process the query, the first end-host may need to be authenticated via DHCP.

A policy defined for the second end-host may also be applied to determine whether the querying end-host is authorized to send data packets to the second end-host. If the first end-host is not authorized, the DNS system may reject the query, as shown in step 404. In this example, the first end-host is actually authorized to send data packets to the second end-host. As above for step 3: 4, other policies may also be applied, such as using preferred routes or avoiding non-preferred routes, using a particular service, function, or quality of service level, redirecting packets to another recipient, and so forth.

In a final step 406, the DNS system sends the created sender key to the first end-host in response to the query of step 402. Thus, the first end-host can substantially adopt the above for step 3 by applying the tag derivation function TDF to the received sender key: 7 to propagate the data packets towards the second end-host, and then attaching the obtained sender tag to each transmitted packet.

Figure 5 is a flow diagram of steps in an example process performed by a packet sending first end host, such as end host a in figure 3, to implement control of data packet routing in a packet-switched network. In a first step 500, in contrast to step 3 in fig. 3: correspondingly, the first end-host sends an address query for the second end-host to the DNS system. In response, the first end-host in step 3 in fig. 3: 6 corresponds to a next step 502 of receiving from the DNS system a sender key derived from the destination key of the second end-host. A key index is also received, possibly along with the sender key, that points to the appropriate entry or row in the forwarding table of the first hop router.

In the next step 504, in contrast to step 3 in fig. 3: correspondingly, the first end-host creates a sender tag by applying a predefined TDF to the received sender key. Finally, the first end-host performs the following steps 3: 8 attach the created sender tag to one or more data packets transmitted over the network. The first hop router will then be able to determine the appropriate outgoing port by matching the received sender tag with the entries in its forwarding table, substantially as described above.

Fig. 6 is a flow diagram of steps in an example process performed by a router in a network (e.g., router 302 in fig. 3) to control transmission of data packets in a packet-switched network. In a first step 600, a router receives a data packet. The packet may have been transmitted from a neighboring router or from the sending end-host as the first hop.

In an optional next step 602, it may be checked whether the packet contains an entry label generated by a sender key already provided by the DNS system, e.g. as described above for step 3: 7 and step 3: 6, and (3). If no such ingress tag is found, the packet may be dropped in another step 604. On the other hand, if the packet contains an ingress label, then in the next step 606, the packet is forwarded using the protocol as described above for step 3: 9, performing a matching operation on the received ingress label and the different ingress keys in the forwarding table to find a matching entry in the table. If the key index is used in the forwarding table and is also attached to the received packet, the key index can be used in this step to limit the matching operation to one entry or only a few entries and to quickly find the correct entry in the table.

In a next step 608, it is determined whether a matching key is found in the forwarding table by a matching operation, e.g. to address step 3 in fig. 3: 9 in the manner described above. If not, the packet is discarded in step 610. If a matching entry is found, then in another step 612 the port in the matching entry is selected as the outgoing port for the packet. Then, in step 614, an exit label is created by applying a label derivation function to the exit key in the matching entry. Finally, in the last illustrated step 616, the packet with the created new egress label attached is sent from the determined port to the next hop node.

If a key index is used, the exit key index in the matching entry may also be attached to the packet. The receiving next hop node can then substantially repeat the process according to steps 610-616 above. As above for step 3: 11, the ingress/egress label may not be changed between two or more successive routers. Thus, depending on the implementation, step 614 may not necessarily be performed in all routers in the transmission path, in which case the packet with the received ingress label attached and reused as egress label is sent in step 616.

Fig. 7 is a logical block diagram illustrating in more detail the arrangement in the devices in the DNS server system 700 and the router 702 in the packet switched network for controlling the transmission of data packets in the network according to other example embodiments. The DNS server system 700 includes: the address query manager 700a is adapted to receive an address query Q from the first end-host, said address query Q basically requesting useful sender keys for the target second end-host. DNS server system 700 further includes: a host database 700b for generally registering a destination key associated with the end host. In particular, host database 700b is adapted to provide a destination key for the second end-host registration. Host database 700b may also maintain information indicating which end hosts are authorized to send packets to each registered end host. The information may include policies defined for registered end hosts and determine whether the querying end host is authorized to send data packets to a particular destination.

DNS server system 700 further includes: router key manager 700c is adapted to create and distribute router keys and optionally key indices to routers in the network, including router 702. The address query manager 700a is further adapted to create a sender key by applying a KDF to at least the destination key of the second end-host and to provide the sender key to the first end-host in response to the address query Q. The first end-host is thus able to propagate the data packets towards the second end-host by creating a sender tag from the received sender key and attaching the sender tag to each data packet transmitted to the second end-host. The received sender key may only be valid for a particular session or data flow, such that the first end-host must obtain a new sender key for any other session or data flow with the second end-user. Thus, the above sender tag is attached to the packet in a specific session or data flow.

The router 702 includes: an ingress part 704 adapted to receive a data packet P from a neighboring node, such as another router in the network, or directly from a sending end-host. The ingress portion 704 may also be adapted to admit a packet if a valid ingress tag is attached to the packet and to discard the packet if a valid ingress tag is not included.

The router 702 further includes a forwarding unit 706, where the forwarding unit 706 includes a forwarding table 706a and a label matching unit 706b, and the label matching unit 706b is configured to match the received ingress label with an ingress key in the forwarding table 706a to determine an outgoing port of the packet, for example, by respectively employing the following steps with respect to step 3 in fig. 3: 9-3: 10 and the manner described with respect to steps 606-612 in figure 6. The forwarding unit 706 further includes: a label creating unit 706c for creating an egress label of the packet. The router 702 further includes: an egress part 708 adapted to send the packet from the determined outgoing port to a next hop node, such as another neighboring router, to which the created new egress label is attached.

Figure 8 is a schematic block diagram illustrating in more detail the devices in an end user device 800 implementing control of data packet transmission in a packet switched network according to another embodiment. End user device 800 includes: an address querying unit 800a adapted to send an address query "Q" for the second end-host to the DNS system "DNS" and to receive, in response to the query, a sender key derived from a destination key registered for the second end-host from the DNS system.

End user device 800 further comprises: a tag creation unit 800b adapted to create a sender tag by applying a tag derivation function TDF at least to the received sender key; and a packet transmission unit 800c adapted to attach a sender tag to the data packet P and then transmit the data packet P to the first-hop router R₁。

It should be noted that fig. 7 and 8 illustrate the various functional elements in DNS system 700, router 702, and end-user device 800, respectively, in a logical sense only. However, one skilled in the art is free to use virtually any suitable software and hardware means to implement these functions. Thus, the present invention is not generally limited to the illustrated structures of DNS server system 700, router 702, and end-user device 800.

In this scheme, the router may thus match the ingress label included in the received data packet with a route or ingress key in the forwarding table in the manner described above to validate the packet while finding the correct outgoing port. If a match is found in an entry of the forwarding table, the port number in the entry is determined to be the correct outgoing port for the packet.

The described embodiments implement a forwarding architecture in which scalable forwarding tables may be used in routers. The routing of data packets may also be controlled to avoid flooding, spam, viruses, fraud, DoS attacks, and generally unsolicited traffic. While the present invention has been described with reference to specific exemplary embodiments, the description is in general only intended to illustrate the inventive concept and should not be taken as limiting the scope of the invention. The invention is defined by the appended claims.

Claims (19)

1. A method of controlling data packet transmission in a packet switched network, comprising the following steps performed by a router (302, 702) in the network:

receiving a data packet comprising an ingress label derived from a sender key or a router key using a first label derivation function TDF known to the router;

performing a matching operation on the received ingress label and at least one entry in a forwarding table, the entry comprising an ingress key and a corresponding outgoing port number, using the first TDF to determine whether the received ingress label matches the ingress key in the entry; and

if a matching entry is found in the forwarding table, the packet is sent from the outgoing port indicated in the matching entry to the next hop node, and if no matching entry is found, the packet is discarded.

2. The method of claim 1, wherein each matching operation comprises: the first TDF is applied to a candidate ingress key in a row of a forwarding table to derive a candidate ingress label, and a match is deemed to be found if the candidate ingress label satisfies a predetermined relationship with the received ingress label in the packet.

3. The method of claim 2, wherein the predetermined relationship is equality, i.e., a match is deemed to be found if the candidate ingress tag is the same as the ingress tag in the packet.

4. A method according to any of claims 1-3, wherein an egress label is created by applying a second label derivation function TDF' to an egress key in a matching entry, the egress label being attached to the data packet when sent to the next hop node.

5. The method of any of claims 1 to 4, wherein the received data packet further contains a key index pointing to an entry or set of entries in a forwarding table, the key index being used to find a suitable entry for a matching operation.

6. An arrangement in a router (302, 702) of a packet switched network for controlling data packet transmission in the network, the arrangement comprising:

an ingress unit (704) adapted to receive a data packet (P) comprising an ingress label derived from a sender key or a router key using a first label derivation function TDF known to the router;

a tag matching unit (706b) adapted to perform a matching operation on a received ingress tag and at least one entry in a forwarding table, the entry comprising an ingress key and a corresponding outgoing port number, using the first TDF to determine whether the received ingress tag matches the ingress key in the entry; and

an egress unit (708) for sending a data packet (P') to a next hop node, wherein the data packet is sent from an outgoing port indicated in a matching entry if the matching entry is found in the forwarding table and discarded if no matching entry is found.

7. The apparatus of claim 6, further comprising: a tag creation unit (706c) adapted to create an egress tag by applying a second tag derivation function TDF' to an egress key in the matching entry, and to attach the egress tag to the data packet when the data packet is sent to the next hop node.

8. A method of controlling data packet transmission in a packet switched network, comprising the following steps performed by a DNS system (300, 700):

registering a destination key for an end host (B, C, D … …) in the network;

distributing router keys to routers (302) in the network, each router key being derived from a registered destination key representing an end host and/or from network topology information;

receiving an address query from a first end-host (a) relating to a second end-host;

creating a sender key by applying a key derivation function KDF to at least a destination key associated with the second end-host;

in response to the address query, sending the created sender key to the first end-host, thereby enabling the first end-host to propagate the data packet to the second end-host by attaching a sender tag generated according to the sender key, which directs the transmitted packet to the second end-host, to the transmitted data packet.

9. The method of claim 8, wherein to process the query, the first end-host needs to be authenticated and the query is rejected if the first end-host is not authenticated.

10. A method according to claim 9, wherein the first end-host requires authorization via DHCP, and the DHCP server provides the first end-host with a way to query the DNS server system only if the first end-host is authorized via DHCP.

11. A method according to any one of claims 8 to 10, wherein a policy defined for the second end-host is applied to the query to determine whether the first end-host is authorised to send data packets to the second end-host, and the query is rejected if the first end-host is not authorised.

12. A method according to any of claims 8 to 11, wherein the sender key is created by applying a KDF also to the identity of the first end-host and/or to a timestamp, and/or to a random number.

13. A method according to any one of claims 8 to 12, wherein the router key represents a single end host or a set of end hosts according to a network topology and the location of those end hosts relative to the network topology.

14. The method of any of claims 8 to 13, wherein key indices are distributed to the routers in a network, each of the key indices identifying at least one of the router keys.

15. An arrangement in a DNS server system (300, 700) for controlling data packet transmission in a packet switched network, the arrangement comprising:

a host database (700b) for registering a destination key associated with the terminal host;

a router key manager (700c) adapted to distribute router keys to routers (702) in the network, each router key being derived from a destination key representing an end host and/or from network topology information; and

an address query manager (700a) adapted to receive an address query (Q) from a first end-host relating to a second end-host, create a sender key by applying a key derivation function to at least a destination key associated with the second end-host, and send the sender key to the first end-host in response to the address query, thereby enabling the first end-host to propagate data packets to the second end-host by attaching a sender tag generated from the sender key to the transmitted data packets, the sender tag directing the transmitted data packets to the second end-host.

16. A method of enabling control of data packet transmission in a packet switched network, comprising the following steps performed by an end host device (a, 800) used by a first end host:

sending an address query for the second end-host to the DNS system (300, 700);

receiving a sender key from the DNS system in response to the address query, the sender key being derived from a destination key associated with the second end-host by applying a key derivation function KDF to at least the destination key of the second end-host;

creating a sender tag by applying a tag derivation function TDF at least to the received sender key;

attaching the created sender tag to a second end-host-directed data packet; and

sending the data packet to a first hop router (302, R)₁)。

17. The method of claim 16, wherein a key index identifying one or more router keys in a forwarding table of a first hop router is further received from the DNS system in response to the query, and the key index is attached to a data packet transmitted by a first end-host to a second end-host.

18. The method of claim 16 or 17, wherein the sender tag is created by applying TDF also to at least a portion of a payload in a packet and/or to a random number.

19. An arrangement in an end-host device (a, 800), for use by a first end-host, for enabling control of data packet transmission in a packet-switched network, the arrangement comprising:

an address querying unit (800a) adapted to send an address query (Q) for the second end-host to a DNS system (300, 700) and to receive a sender key derived from a destination key of the second end-host from the DNS system in response to the query;

a tag creation unit (800b) adapted to create a sender tag by applying a tag derivation function TDF at least to the received sender key; and

a packet sending unit (800c) adapted to attach the sender tag to a data packet (P) and then send the data packet to a first hop router (302, R)₁)。