WO2004036867A1

WO2004036867A1 - Multi-path secured network communication

Info

Publication number: WO2004036867A1
Application number: PCT/GB2003/004488
Authority: WO
Inventors: David Hutchison; Manolis Sifalakis; Stefan Scmid; Andrew Scott
Original assignee: The University Of Lancaster
Priority date: 2002-10-18
Filing date: 2003-10-16
Publication date: 2004-04-29
Also published as: AU2003301488A1; GB0224224D0

Abstract

A method of communication between hosts connected to a computer network, wherein: a stream of data packets which is to be sent to at least one predetermined host connected to the computer network is transmitted to a first set of network addresses. At least one first data packet in the stream of data packets is transmitted to a first network address in the first set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the first set of network addresses. The at least one predetermined host is provided with means to determine the first network address to which the at least one first data packet is transmitted, and the second address to which the at least one second data packet is transmitted, such that the at least one predetermined host receives the stream of data packets.

Description

MULTI-PATH SECURED NETWORK COMMUNICATION

The present invention relates to a method of computer network communication, and more specifically to a method which may be used to increase security within an insecure network such as the Internet.

An increasing number of commercial organisations such as banks, and e-commerce enterprises are choosing to exploit Internet connectivity and Virtual Private Network (VPN) technology to build their intranets and extranets. This results in considerable cost savings as compared with using more traditional private physical circuits. The importance of the security provided by any computer network carrying confidential information is apparent both to Internet Service Providers (ISPs) and to client organisations. A study carried out by Lucent Technologies in 2001 (Lucent Technologies, Bell Labs innovations: "Network Challenges and Opportunities in uncertain times (2001)" htφ://www.lucent.com/livelmk/ 162366_CaseStudy.pdf, confirms the extreme importance of security. This study shows that security has always been the foremost concern of network professionals although expenditure on security is not always consistent with this concern.

Accordingly, it is an object of the present invention to provide a method of network communication which increases security.

To ease understanding, the following terms are used in the following manner to define the present invention. The term "host" is hereinafter used to mean any device connected to the computer network. The term "set υf network addresses" is hereinafter used to mean a collection of network addresses, which may or may not have an implied order.

According to the present invention, there is provided a method of communication between hosts connected to a computer network, wherein: a stream of data packets which is to be sent to at least one predetermined host connected to the computer network is transmitted to a first set of network addresses, such that at least one first data packet in the stream of data packets is transmitted to a first network address in the first set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the first set of network addresses; and the at least one predetermined host is provided with means to determine the first network address to which the at least one first data packet is transmitted and the second network address to which the at least one second data packet is transmitted, such that the at least one predetermined host receives the stream of data packets.

Transmission of the stream of data packets to a set of network addresses makes it considerably more difficult for an unauthorised third party to intercept and reconstruct data transmitted to the at least one host. In order to correctly receive data, the addresses and the order in which these addresses are used must be discovered. This information is not readily available to unauthorised third parties. The method of the invention is complementary to most security mechanisms. It may therefore be used alongside other security mechanisms, such as encryption, to provide still greater security.

The term "hopping sequence" is hereinafter used to mean an order in which the network addresses in a set of network addresses are used for data transmission or reception. It will be appreciated that a set of network addresses and a hopping sequence can be combined to form an ordered list of network addresses, and thus these two terms are used in combination to mean any way of providing an ordered list of network addresses.

A first host may provide the first set of network addresses to a second host, the first host may provide a first hopping sequence to the second host, and means may be provided to synchronise the first and second hosts, such that the second host is able to receive data transmitted by the first host to the second host using the first set of network addresses and the said first hopping sequence. The first host may also be able to receive data transmitted by the second host to the first host using the first set of network addresses and the said first hopping sequence.

The second host may provide a second set of network addresses to the first host, the second host may provide a second hopping sequence to the first host, and means may be provided to synchronise the first and second hosts, such that data transmitted by the second host to the first host using the second set of network addresses and the said second sequence can be received by the first host.

Preferably, the first set of addresses includes a first sending set of addresses and a first receiving set of addresses, the second set of network addresses includes a second sending set of network addresses and a second receiving set of network addresses, and the first host can receive data packets sent from an address in second sending set of network addresses to the first receiving set of network addresses, and the second host can receive data packets sent from an address in the first sending set of network addresses to the second receiving set of network addresses.

Each network address may comprise an Internet Protocol address and a Transmission Control Protocol port number. The or each set of network addresses and the or each hopping sequence may be communicated between hosts in an encrypted form. The or each hopping sequence may comprise a mathematical function which is evaluated by a host by which it is received to determine the order in which addresses in the set of network addresses are used. The mathematical function is preferably a pseudo-random number generator. The mathematical function may take as its argument a part of the hopping sequence which has been used. A sequence number may be allocated to each data packet in the said stream of data packets, and the sequence number may be used to synchronise the first and second hosts. The Internet provides an Internet Protocol (IP) Multicasting service for, point-to- multipoint communication. Examples of prior art use of multicasting include updating replicated distributed databases, transmitting stock quotes to multiple brokers and handling digital conference (i.e., multiparty) telephone calls. The IP supports multicasting using class D addresses in the range 224.0.0.0 to 239.255.255.255. Each class D address identifies a group of hosts on the Internet. Twenty-eight bits of the class D address are available for identifying multicast groups, so over 250 million groups can exist at any one time.

A process operating on a host can make a request to a network subsystem of that host to join a predetermined multicast group. Similarly, a process can make a request to leave a predetermined multicast group. Each host records the multicast groups which are currently used by its processes. IP Multicasting is implemented by special multicast routers each of which may or may not be co-located with a standard network router. At predetermined time intervals (e.g., once every minute) each multicast router sends a data link layer multicast message to every host on its Local Area Network (LAN). This message is sent to IP address 224.0.0.1, which is a multicast group to which all hosts on the LAN belong by default. In response to this multicast message, each host responds with a list of class D addresses representing multicast groups to which its processes belong. A data packet which is to be sent to a multicast group is sent to an appropriate class D address, and is received by all hosts which are members of that multicast group. It should be noted that the IP multicast service does not offer guaranteed delivery to all group members, and some data packet loss may therefore occur.

The exchange of data outlined above uses a protocol known as the Internet Group Management protocol (IGMP). IGMP has only two types of data packet, a query packet which is sent from a multicast router to hosts on its LAN and a response packet which is sent from the hosts to the multicast router. Each of these packets has a simple fixed format containing control information in the first word of the payload field and a class D address (representing a group to which a host belongs) in the second word. A full description of IGMP is provided in Request For Comments (RFC) 1112, published by the Internet Engineering Taskforce at www.ietf.org.

IP multicasting offers considerable savings of bandwidth, and reduces the transmission overhead and cost by eliminating the need for multiple single point-to-single point communications. As the number of group applications and services increases, a need for the deployment of IP multicasting is emerging. Unfortunately, commercial support for IP multicasting has currently been delayed indefinitely. It has been argued that one of the main reasons for the lack of commercial support is the absence of built-in mechanisms to provide access control and security (see, for example A. Mauthe, D. Hutchison, G. Coulson and S. Na uye: "Multimedia group communications towards new services", Distributed Systems Engineering Journal, Volume 3, Number 3. September 1996.).

Several approaches have been proposed in the prior art to provide the IP multicast service model with security support, including for example, the use of various cryptographic techniques to encrypt the data that is to be multicast. Such a security mechanism is effective only after interception of data has taken place, and if the encryption key has been compromised no security redundancy is provided.

Alternative security mechanisms include that described in S. Mittra. "Iolus: A Framework for Scalable Secure Multicasting", ACM SIGCOMM '97, September 1997. This document abandons the idea of large flat secure multicast group and instead uses a notion of a secure distribution tree that is composed of multiple smaller secure multicast subgroups arranged in a hierarchy. All these subgroups together form a single virtual secure multicast group. Security agents (GSAs) who manage each subgroup are responsible for the consistency of the virtual secure multicast group. The GSAs communicate with each other to deliver the multicast traffic securely between the subgroups, thereby creating a view of a single, global multicast group for the senders and receivers.

A further prior art security method is described in B. Cain.: "Source Access Control for Bi-directional Trees" 41^st IETF meeting. March 1998. L.A., C.A., USA. This document suggests a way to bypass a limitation of secure multicast approaches such as KHIP. This approach has a limitation in that it does not provide a fine-grained way of excluding specific sources from the multicast tree. The approach set out in the document enforces authorisation at the edges of a network where group state will be maintained to operate upon receiver-specific source prunes. The disadvantage is that access-control is only reinforced at the edge network, since such a solution cannot be effective at the backbone.

KHIP is a secure hierarchical multicast routing protocol, extending the idea of HIP (Hierarchical multicast routing), in the sense that it provides an authentication service model and secure routing for authorised group members. In KHIP each prospective member is authenticated using public keys. Certificates are issued to authorised tree members, based on which, they are allowed to alter the tree (i.e. join or leave a multicast group). For fine-grained access control, the method proposed by Cain organises the multicast tree into sub-branches, and on each sub-branch, a separate shared key can be used for controlling data transmission. All messages exchanged in a branch carry nonces to prove their permission to access the group. While in KHIP not all possible attacks can be prevented, it is claimed that this method provides a reasonable degree of protection.

It is a further object of the present invention to provide a method of network communication which can be used to secure multicast communication.

Accordingly, the at least one predetermined host may be a plurality of hosts, and the plurality of hosts may form a multicast group. Hosts which are members of a multicast group will receive all data which is sent to the multicast group. Some members of the multicast group will also be able to send data to the multicast group, and such multicast group members are herein referred to as "sender hosts". It should be noted that sender hosts will receive data sent to the multicast group as well as being able to send data to the multicast group.

The stream of data packets may be sent from a sender host which is a member of a multicast group to a router host, and from the router host to the plurality of hosts using the first set of network addresses. The router host may comprise means to transmit the stream of data packets to the first set of network addresses using a predetermined hopping sequence. The stream of data packets may be sent from a sender host to a router host using a second set of network addresses such that at least one first data packet in the stream of data packets is transmitted to a first network address in the second set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the second set of network addresses; the router host may be provided with means to determine the second set of network addresses and a second hopping sequence; on becoming a member of the multicast group, the sender host may be provided with means to determine the second set of network addresses and the second hopping sequence; and the sender host may send the said stream of data packets to the second set of network addresses in the order determined by the hopping sequence, and the router host may receive the said stream of data packets sent using the second set of network addresses and the second hopping sequence. The first and second sets of network addresses are preferably different, or alternatively the first and second sets of network addresses may be identical, and the first and second hopping sequences may be different.

In order to join the multicast group, a host connected to the computer network may present a ticket to the router host, and the host is permitted to join the multicast group if the presented ticket is validly authenticated by the router host. The ticket presented to the router host may specify whether the host is to receive data from the multicast group, and or send data to the multicast group, and the ticket may be provided to the host by an authentication server which is connected to the computer network. The authentication server may ensure that a user of the host is permitted to obtain the requested ticket, before the ticket is issued. The ticket supplied by the authentication server is preferably encrypted using a public key of a router to which it is to be presented, and the ticket is preferably signed using a signature of the authentication server. The ticket may include a session key which can be used for encrypted communication between the router host and the host. The ticket may be presented to the host in an encrypted form, using an encryption key which is based upon a password of a user of the host.

The hopping sequence may include a mathematical function specified by the router host. The function is suitably a pseudo-random number generator, and may take the order in which network addresses are used as an argument.

A unique sequence number may be allocated to each data packet of the said stream of data packets, and the unique sequence number may be used to determine the network address in the first set of network addresses to which each data packet is transmitted. The sequence number is preferably included in a field of the data packet, such that each member of the multicast group can determine the current sequence number. The sequence number may be encrypted, and may be used to allow synchronisation of hosts connected to the computer network which are to communicate with one another.

In both the unicast and multicast embodiments of the invention, data included in the said stream of data packets may be encrypted. The stream of data packets may collectively contain a series of encrypted data chunks, each encrypted chunk may contain a quantity of data which is greater than a quantity of data contained in each data packet, and decryption of the stream of data packets requires a plurality of sequentially transmitted data packets.

According to a further aspect of the present invention, there is provided a multicast router host device comprising a connection to a computer network, storage means suitable for storing a sequence of network addresses associated with any one multicast group, means for receiving a message requesting that a host be allowed to join the multicast group, and transmitting means activatable to provide details of the sequence of network addresses associated with the multicast group to the host.

The multicast router host device may further comprise access means to control access to the multicast group, and/or means to change the said sequence of network addresses.

According to another aspect of the present invention, there is provided a host device comprising: means for connection to a computer network; means to transmit a stream of data packets which is to be sent to at least one predetermined host to a set of network addresses such that at least one first data packet in the stream of data packets is transmitted to a first network address in the first set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the first set of network addresses; and means to determine a network address in the said set of network addresses to which a particular data packet in the said stream of data packets is to be sent.

The invention also provides a host device comprising: means for connection to a computer network; means to receive a stream of data packets which are transmitted using a set of network addresses; and means to determine a network address in the said set of network addresses to which a particular data packet in the said stream of data packets is sent.

The invention also provides a computer network configured to carry out the method set out above.

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic illustration of a part of a computer network on which an embodiment of the present invention is implemented; and

Figure 2 is a schematic illustration of a series of communications required when a host joins a multicast group using a method in accordance with the present invention.

In accordance with the present invention, data packets which are transmitted to a particular host, or to a group of hosts forming a multicast group, are distributed across a number of different network addresses in a "hopping pattern". The hopping pattern comprises a set of network addresses, and a "hopping sequence" which defines the order in which addresses in the set of network addresses are used for data transmission or reception. The hopping pattern also contains further information which can be used to amend the hopping sequence and provide synchronisation. Suitable hopping patterns are described in further detail below. It should be appreciated that the minimum requirement for a functional embodiment of the invention is an ordered list of network addresses, together with some means of synchronisation, these minimum requirements together with further non-essential features are provided in the hopping patterns discussed further below. Each host participating in a particular communication has knowledge of this hopping pattern and can thus determine the address on which each data packet should be sent or received. This is very different from a conventional network communication system where all data packets which are to be transmitted to a particular host or multicast group are sent to a predetermined network address. In some embodiments of the invention, hosts can join multicast groups by providing an appropriate ticket to a suitably configured router. Authentication servers are provided to authenticate hosts during the group-join procedure, and provide tickets to the hosts, which are subsequently provided to the router.

Two embodiments of the present invention are now described by way of example, a first embodiment involves host-to-host unicast communication, and a second embodiment involves multicast group communication.

Current Internet communication uses unicast for the vast majority of applications. Unicast communication involves one networked host (sender) in a communication with a single peer (receiver) in a one-to-one, peer-to-peer type interaction. If a sender host wishes to interact with many other hosts, separate unicast communications are established with each peer. For this reason, security concerns in unicast communication are essentially an end-to-end issue, although fire walls may protect several entities simultaneously.

In the first embodiment of the present invention, a unicast communication between two hosts is multiplexed over a number of end-to-end connections between the two hosts. Each one of the connections provides a channel between the two hosts, and each of these channels has a network address which is used in the address hopping mechanism of the invention. In this example, an architecture providing a bi-directional exchange of hopping patterns is described, such that each host provides its peer with details of a set of IP addresses and transport layer ports which are to be used for sending and receiving data. When a communication between first and second hosts is to be established, a first host contacts the second host with which it wishes to communicate, by sending a normal service request. This request may typically be made in the HyperText Transfer Protocol (HTTP) or the File Transfer Protocol (FTP), although those skilled in the art will realize that other suitable protocols can be used. This service request includes data in its header field indicating that the first host is able to and wishes to communicate using the address hopping mechanism of the invention. If the second host is similarly able to communicate using the address hopping mechanism, it switches to a secure communication mode and responds by sending its hopping pattern to the first host. On receipt of this hopping pattern, the first host responds by sending its hopping pattern to the second host. After this exchange of hopping patterns, the first host reissues its service request to the second host using the unicast address hopping mechanism of the invention, and the unicast address hopping mechanism is then used for future communications.

In preferred implementations of this first embodiment, an encryption scheme based on secret or public key cryptography is provided such that the hopping patterns which are exchanged between hosts can be exchanged securely. This is of particular concern given that the address hopping mechanism can not be used at this stage. However, even if such an encryption method is not available, the invention can still be effectively implemented, given that the exchange of hopping patterns occurs relatively infrequently, and thus the risk of unauthorized third parties successfully intercepting the hopping patterns is small.

A typical hopping pattern for a given host is shown in table 1 :

TABLE 1: HOPPING PATTERN FOR UNICAST COMMUNICATION FOR A

GIVEN HOST As shown in table 1, each host specifies a set of addresses it wishes to use for sending and receiving data. In table 1, the first three rows specify addresses that are to be used for sending data, and the following two rows specify addresses that are to be used for receiving data. Each address used in this embodiment of the invention comprises an IP address and a transport layer port number that is used with that IP address to form a network address, and thus a channel endpoint. Each of the first five rows of table 1 comprise an IP address and one or more transport layer ports that are to be used with that IP address, so as to form a set of network addresses, and thus a set of channel endpoints. For example, the first row of table 1 specifies three sending addresses, each having the same IP address but different transport layer port numbers. The other information provided in table 1 comprises a hopping sequence, a hopping function and a shared session key for encryption. This information is described further below.

Once the exchange of the hoping patterns has been completed (as described above), the two hosts compute the channels which are to be used for communication, and start exchanging data over these channels by using the hopping sequence corresponding to each logical connection.

Bi-directional communication between two hosts is based on two independent unidirectional connections. Each of these connections comprises a plurality of channels as specified by the addresses set out in table 1. Each host uses one of these connections for data transmission, and the other for data reception. Each channel is defined by the following tuple:

{src [IP addr., TL port], dst [IP addr., TL port] }

where src [IP addr., TL port] is a tuple containing the IP addresses and Transport Layer Ports from which data to be transmitted using that connection is sent; and dst [IP addr., TL port] is a tuple containing the IP addresses and Transport Layer Ports at which data transmitted using that connection is received.

It should be noted that both source and destination tuples will be used by both hosts. In a predetermined unidirectional communication of the type set out above, the destination tuple of the connection will be used by a receiving host for "listening" and receiving data, and the source tuple of the connection will by used by a receiving host for authenticating and verifying that the data received is coming from a valid sender. That is, data received at the endpoint specified by the destination tuple will not be accepted unless the source IP address and port number match that which is specified in the relevant tuple. A sending host will use the source tuple to determine the network address from which data should be transmitted and the destination tuple to determine the network address to which data should be transmitted.

Each peer can compute the transmitting channel set by combining its own sending endpoints (as known from its hopping pattern) with the peer's receiving endpoints (from the peer's hopping pattern which has been received). Similarly it can compute the receiving channel set by combining its own receiving endpoints with the peer's sending ones. Thus, the information set out in table 1 can be used to compute all the channels for both sending and receiving, that are to be used for communication between the two hosts.

From the discussion set out above, it will be realized that data other than the network addresses which are used to specify channel start and end points needs be communicated between hosts. This information is set out in the hopping pattern of table 1. Each of the connections comprising source and destination tuples is a unidirectional connection as described above. In a particular embodiment of the invention, it is the sender host of each connection which specifies this additional information by means of its hopping pattern, although it will be appreciated that in alternative embodiments of the present invention, the receiving host for each connection could provide its hopping pattern. Referring back to table 1, in addition to IP addresses, transport layer ports and the hopping sequence, it can be seen that the hopping pattern also contains a hopping function, a synchronization parameter and a shared session key. The significance of each of these is now described.

In order to enable synchronization between two hosts, the hosts must agree on an initial state. This can be accomplished in a number of ways. Two possibilities for addressing this issue are discussed below. In a first implementation IP header options are used to add an encrypted packet counter storing the sequence number for each packet of the unicast session. In a second implementation the counter is inserted between the IP header and the IP payload, so as to avoid the sequence number being processed by intermediate hosts, and thereby slowing communication between the hosts. In both implementations separate unique, monotonically increasing counters are used for synchronization on each logical connection. Synchronisation is achieved by agreeing on a common initial sequence number value, (the synchronization parameter in the hopping pattern of Table 1), after which both ends start using the hopping sequence for identifying the correct channel for transmitting the next packet. Throughout the address hopping session, the counter is used to detect packet loss and maintain the synchronisation. The counter is encrypted with the shared key sent as part of the hopping pattern. Therefore only network entities sharing the same hopping pattern can synchronise with each other. Synchronisation takes place independently on both logical connections in order to establish a meaningful communication.

The hopping function (see Table 1), adds an extra degree of randomness to the order in which addresses are used, and therefore makes it more difficult for a third party to determine the hopping sequence. It is defined as part of the hopping pattern and is used to generate a continuously changing hopping sequence. Every time the hopping sequence is to be used, this function is used by each of the hosts to generate the next element of the hopping sequence. In a preferred embodiment of the invention, a pseudo-random generator is used as a hopping function and the function takes the current hopping sequence as an argument. For example, the hopping sequence will specify the addresses that are to be used for the first n communications. The hopping sequence acts as an index which is used to determine the network address to be used. When the initial hopping sequence is exhausted, the hopping function is used to generate a constantly changing hopping sequence, which is used to determine the address used to send or receive data.

The amount of time that each channel is occupied is defined as part of the hopping pattern (synchronisation parameters). Channels may be changed on a per packet basis. Since no two consecutive packets are transmitted in the same channel (unless the same channel appears twice in the hopping sequence), it is harder for an unauthorized third- party to determine the hopping pattern and thereby gain access to the data.

So as to reduce the chance of a malicious user obtaining either the channel set or the hopping function, hopping pattern updates are periodically sent by both ends. As mentioned above, the hopping pattern updates can be encrypted. For hopping pattern updates (subsequent to the initial exchange) the hosts can use the shared key of the previous hopping pattern for secret key encryption of the update. In this case, only "legitimate" hosts already holding a valid hopping pattern can decrypt the new hopping pattern. Each host will send its hopping pattern update before the expiration time of the old hopping pattern. Upon reception of the update the remote host should respond with a 3 -way handshake process. The 3 -way handshake process is an algorithm where for each message sent, the receiver of the message must send a acknowledgement denoting that it received the message and in response to that the sender must reply by acknowledging the reception of the receiver's acknowledgement. If there is no acknowledgement from the receiving host, the update is resent again (at regular intervals) until either an acknowledgement is received, or until the old hopping pattern expires, in which case the session must be killed. As has been described above, the first embodiment of the invention provides increased security in unicast communication. To compromise the communication a prospective impostor would have to intercept all the traffic sent to all the hopping channels and try a factorial number of possible combinations in order to place the packets in the correct order. The proposed model includes the features set out below to increase the difficultly of any attack.

The sending hosts regularly sends "dummy" packets to unused hopping channels. The complexity of a prospective attack is consequently increased because the impostor must filter and process all the "noise" created by these dummy packets.

The IP addresses preferably come from different aggregate blocks (e.g. different ISPs). The probability of the data packets following different and potentially disjoint routes is therefore increased. The disjoint nature of such routes reduces the number of network points which the impostor may use for "tapping", if all packets are to be intercepted.

The fact that packets on different channels have different source and destination identifiers increases the effort required by the impostor to correlate packets of the same stream, and filter out traffic belonging to other streams.

Given that different connections are used for sending and receiving data, the imposter must compromise two distinct logical connections (hoping patterns and sequences) at the same time. Thus the work required by the impostor and the cost of the attack is doubled.

The first embodiment of the invention may be used in circumstances where encryption is used to further protect data within the data packets. If no encryption is provided, employing the unicast connection hopping extensions cannot guarantee total data confidentiality. Nothing can prevent a malicious receiver on the (local) network from switching into "promiscuous mode" and intercepting all the (local) traffic, including the session data. Since data packets carry state information, it will not be impossible to reconstruct the session streams. However, there are many difficulties involved, which make this a non-trivial task. First, it may well be impossible to intercept all traffic due to spreading across multiple (disjoint) paths as described above. Also, operating in "promiscuous mode" is a resource intensive task, which may significantly degrade if not saturate (under certain conditions) the performance of the impostor's end system. Additionally, having to reassemble traffic, which has been spread "randomly" across many streams, makes real-time reconstruction of a session computationally expensive.

In cases where reassembling a session streams in real-time is not possible (e.g. because too many "dummy" data packets must be processed), all the traffic data must be intercepted and stored for later reconstruction of the session. This is only feasible for data without hard time constraints and may require huge amounts of storage space. As a result, the effectiveness of such an attack is highly conditional. And thus, it depends on the type of data transmitted (time sensitive, computation intensive, etc), the hardware available, and the security configuration. Thus in summary, even without any encryption, it is a non-trivial task for unauthorized third parties to gain access to the data.

In the case where encryption mechanisms are available, the sender of the multicast traffic can encrypt the IP payload to ensure data privacy. In this case the employment of unicast connection hopping adds another level of security to the existing scheme and thus improves the level of protection provided. Spreading the data across several frequently changing channels (unknown to a potential impostor) significantly hardens crypto- analysis on the end-to-end flows. Even if all potential data traffic is intercepted, there is no easy way - except trying all possible combinations - of reconstructing the session data, since encryption hides all kind of "sequence information" (e.g. in the network or transport header). The second described embodiment of the present invention is concerned with multicast communication. Figure 1 schematically illustrates a network structure which has standard IP multicast support and on which the present invention is implemented. The illustrated network comprises first and second policy domains 1, 2, each of which is connected to the Internet which is denoted by a cloud 3. Each policy domain is a routing domain operating under the control of a single authority. For example, a policy domain maybe an individual Local Area Network (LAN), a campus network, or ISP network. The choice is a matter of scalability and granularity. The first policy domain 1 includes a plurality of hosts 4 which are connected to the network via routers. The first policy domain 1 includes two security enhanced multicast (SEM) routers 5, which are configured to operate in accordance with the present invention. The first policy domain 1 also includes three conventional multicast routers 6 and two further conventional non-multicast routers 7. The second policy domain 2 is only partially illustrated in Figure 1, but in practice will contain all the features of the first policy domain.

The SEM routers 5 are conventional multicast routers which have been enhanced with functionality required to put the invention into effect. The SEM routers 5 provide an authorisation procedure which a host must satisfy before joining a multicast group. The first policy domain 1 further comprises an authentication server 8 which provides tickets which hosts present to SEM routers to allow access to a particular multicast group.

Enhanced security provided by the present invention relies on the fact that only authorised hosts know the hopping pattern used to transmit data packets and hence only authorised hosts can send and receive multicast messages. Authorisation m this multicast implementation of the invention is based on a Kerberos style authentication mechanism, (See J. Kohl, C. Neuman. "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.) where the authentication server 8 issues authorised hosts with a "ticket" which is presented to a SEM router when a multicast group is joined. The process of joining a multicast group is illustrated in Figure 2. A host 4 wanting to join a multicast group first requests a valid ticket from the authentication server 8 by means of a request message 9. This request message comprises a client identifier CID for the host 4, which is typically the host's IP address, a User ID for the user currently using that host, and a list of multicast groups MG_ΓOUPS which the user wishes to join.

The Authentication server 8 uses the request message 9 to determine whether or not the user represented by the User ID has permission to join the specified multicast groups M_Groups If the requisite permissions are held by the user, a ticket 10 is generated for transmission to the host 4. The ticket 10 comprises a session key Ks, the identifier of the host C_ID for which the ticket is intended, an expiry time TE P and a list of multicast groups MG_rou s which may be joined using the ticket. It should be noted that the list of multicast groups contained in the ticket 10 may be the same as that contained in the request message 9, or may be a subset of that contained in me authentication request if the user requested access to groups for which suitable permissions were not held.

In order to prevent access to the ticket by unauthorised third parties, the ticket is encrypted (represented by "E" in the ticket 10) using the public key [K _{U {SEM}}] of an SEM router 5 to which the ticket will be presented. Thus, the contents of the ticket can be read only by that SEM router. The appropriate SEM router is determined by the authentication server 8 using the identifier C_ΓD of the host as presented in the request message 9. The authentication server 8 keeps a record of the service domain of each SEM router 5, and can thus determine which public key should be used for a particular client. In addition to this encryption, the ticket is signed by the authentication server 8 using a signature Sig[AS]. This allows the SEM router to ensure that the ticket was generated by a valid authentication server, when the ticket is presented by a host 4. Given that the ticket 10 is encrypted using a key of the appropriate SEM router 5, it can not be read by the host to which it is sent. An authentication response 11 therefore includes data in addition to the ticket 10. This additional data comprises the secret session key K_s, the client identifier C_ID and the expiry time T_EXP as in the ticket. The authentication response 11 is encrypted using a key based upon the user's password [ pa_ssw_ord] to prevent unauthorised access to the data contained therein. This password is determined by the authentication server 8 performing a database lookup using the user's logon ID. This lookup obtains the user's password, and this password is used to encrypt the authentication response 1 1. Thus, given that the authentication response 11 is encrypted using the user's password, only that user can obtain access to the data included in the authentication response.

When the authentication response 11 is received by rhe host 4 it is decrypted using the user's secret password. The user then holds a valid ticket (which can be used only by that user) to join the multicast groups specified in the ticket. Joining a multicast group involves a host obtaining the hopping pattern for that multicast group from the SEM router 5.

To join a multicast group the host sends a standard Internet Group Management Protoctol (IGMP) join request to its local router. If the local router is an SEM router 5 it challenges the host to present a ticket. If the router is a conventional multicast router 6, this router will automatically allow access to the group (in conformity with the conventional protocol). In this case, the join request is propagated up to the first SEM router 5 so that the hopping pattern can be obtained, following presentation of a suitable ticket.

A join request 12 sent from a host 4 to an SEM router 5 can be either ajoin-as-a-receiver request or alternatively ajoin-as- -sender request, the type of the request being indicated by data included in the ticket. The request 12 comprises the ticket supplied by the authentication server 8, an identifier of the host CI_D and a current time stamp. The identifier of the host C_ID and the current time stamp are encrypted using the current session key Ks, which was provided by the authentication server 8 and which is also contained in the ticket. This encryption of Ks allows the SEM router 5 to ensure that the session key is known to the host. The SEM router verifies that the ticket contained in join request 12 is authentic by comparing the host identifier C_ID as encrypted by the session key, with the version of the host identifier specified in the ticket.

It will be recalled that the ticket is itself encrypted using the public key of the SEM router. The ticket can therefore be decrypted by the SEM router, and the data within the ticket can be used as necessary. Assuming that all authentication checks are satisfied, the current hoping pattern used by the SEM router 5 is transmitted to the host 4. This is denoted by a message 13, and the hopping pattern is encrypted using the session key which is known only to the SEM router 5 and the host 4. The timestamp Ts (taken from the message 12) can also be included in the hopping pattern message 13, so that the host can authenticate the SEM router 5 and verify that the message 13 is valid response to the message 12.

If the router which is local to the host wishing to join the multicast group is an SEM router, the join is completed. The host knows the hopping pattern used by the SEM router, and can therefore take the necessary action to receive messages sent to the relevant multicast group. If the local router is not a SEM router, that is the SEM router is not located within the local subnet, but is instead located higher up the multicast tree, the host must join the multicast channels that are used by the corresponding hopping pattern using the conventional IGMP mechanisms. Given that the exchange of the hopping pattern has been completed, and the member host therefore knows the hopping pattern (and thus the set of multicast addresses to use), it can join all the corresponding multicast groups by issuing standard IGMP requests to the local (non SEM) multicast router. In this way the communication with the SEM router is established using the conventional multicast protocol. For any intermediate conventional multicast router the multicast address hopping operation will be transparent (and will therefore not require any special support). Essentially the hosts join standard ("low level") multicast addresses (channels), that are used by the address hopping scheme in cases where the SEM router is not located locally.

The procedure for joining a multicast group using SEM routers has been described above. If a host joins a group as a receiver, the currently used hopping pattern for receiving data is transmitted from the SEM router 5 to the host 4. Alternatively, if the host joins a group as a sender to that group, a hopping pattern is transmitted to the sender. Typically, each sender will have its own unique hopping pattern, while all receivers will share a common hopping pattern. However, it should be appreciated that while it is desirable that each sender has its own unique hopping pattern (so as to increase security), the invention can be implemented such that all senders share a common hopping pattern.

Senders transmit to the local SEM router 5, which is in turn responsible for distributing the traffic to the other multicast session members, both the local receivers ("down-the- tree") and the other SEM routers 5 which together form the rest of the multicast tree ("up- the-tree"). In this way the SEM router acts like a local proxy for the SEM router's "coverage area". This arrangement allows SEM routers to be added to or removed from the network as required, thereby providing the network with greater scalability.

The main elements of the hopping pattern used in the multicast embodiment of the invention, which is used for sending and receiving multicast data are shown in table 2.

TABLE 2: Hopping pattern for Multicast Use

A host must synchronise itself with its SEM router 5, to ensure that the SEM router and the host are transmitting and receiving using^'fhe same address at the same time. In order for this synchronisation to occur, it is necessary for the SEM router and the host to share state information. This can be accomplished in a number of ways. For example, IP header options can be used to add an encrypted data packet counter storing a unique sequence number for each packet in a multicast session (as described above in the unicast embodiment of the invention). Separate counters are used for synchronisation: one for all receivers and one for each sender. The members of a multicast session use this unique, monotonically increasing, sequence number in order to synchronise themselves with their SEM router. Synchronisation is achieved by having the SEM router and its hosts, agree on a common sequence number value, after which they both use the hopping sequence (as set out in table 2) to identify the correct address for packet transmittal and receipt. Throughout the multicast address hopping session the counter is used to detect packet loss and maintain the synchronisation. The counter is encrypted with the shared key sent as part of the hopping pattern as shown in table 2. The packet counter is encrypted in order to prevent malicious users from reconstructing the session streams based on this information. Only authorised session members sharing the same hopping pattern can synchronise with the SEM router. One embodiment of the present invention uses the initial hopping sequence as the shared key.

The hopping function (see Table 2) performs a similar function to that described with reference to Table 1 in the unicast embodiment of the invention. That is, the hopping function adds an extra degree of randomness to the succession of the group addresses (and therefore increases the difficulty of cracking the hoping sequence). It is defined in the hopping pattern, and is used to generate a continuously changing hopping sequence. Every time the hopping sequence is applied, this function is used to generate the next element of the hopping sequence. A pseudo-random number generator can be used as a hopping function and the current hopping sequence can be used as a seed. Since the hopping function is part of the hopping pattern it is known to the SEM routers and is communicated to relevant hosts such that all members of the multicast group can determine the next item in the hopping sequence.

The amount of time that each address is occupied is defined by the hopping pattern. In a preferred embodiment of the present invention, the address is changed on a per packet basis. Since no two consecutive packets are transmitted on the same channel (unless the same channel appears twice in the hopping sequence), it is harder to crack a session. The SEM router periodically transmits hopping pattern updates to clients in order to update the hopping pattern. This decreases the chances of malicious users deducing either the multicast address set or the hopping function. The hopping pattern updates can be accomplished by either unicasting an encrypted update message to each client or by multicasting the update message to all group members. The latter approach is used in a preferred embodiment of the invention, where the SEM router multicasts a separate update message with the new hopping pattern encrypted for each client (using its session key). Therefore, only clients with a valid session key can decrypt the new hopping pattern This mechanism has scope to withdraw a client's privilege to receive or transmit to the multicast group in the middle of the session, based on the lifetime of the Ticket. The lifetime of the ticket is based upon the Texp timestamp (which is part of the ticket) in message 10 and 11, and is independent of the timestamps included in the messages 12 and 13 as discussed above. When the Ticket expires and a new one has not been issued, the SEM router sends no more hopping pattern updates to the host, thus the host is essentially removed from the multicast group, given that it no longer knows the hopping pattern.

So as to ensure that a lost update message does not lead to de-synchronisation of the clients, because they do not become aware of the new hopping pattern, clients explicitly request a hopping pattern update as soon as a predetermined update time has elapsed.

Access control for unauthorised sending to the multicast tree is performed implicitly, because SEM routers do not propagate multicast traffic that is not transmitted to a correct address as defined by the hopping sequence, at any moment in time.

The address hopping mechanism presented above can be used to enhance currently provided security within a network environment. The invention can therefore be used to provide an additional layer of protection, thereby providing redundancy. Where no encryption is provided by the network environment, the multicast address hopping scheme of the invention will make eavesdropping by an unauthorised third party more difficult. By transmitting any given stream of multicast data to many different addresses, any receiver must know the hopping pattern in order to be able to re-assemble the data stream. A prospective impostor would have to intercept all the traffic sent to all multicast channels and try a factorial number of possible combinations in order to place the packets in the correct oτder. This is particularly difficult as the SEM routers might reuse the same addresses for different multicast sessions. In this way a multiplexing effect is achieved that substantially increases the complexity of a prospective attack. Indeed, the use of a particular address in more than one multicast group will mean that knowing the addresses alone is not enough - the hopping pattern must also be known, and synchronisation with the SEM router must also be maintained.

A legitimate user can easily identify which flow a packet belongs to by crosschecking the sequence number with the hopping function and the packet address. If only one multicast session has been joined in a subnet, a similar effect can be achieved if the SEM router regularly sends dummy packets to the unused channel addresses.

When no encryption scheme is used, employing the method of the invention cannot guarantee total data confidentiality. If a client is not authorised by the SEM router, and therefore is unaware of the hopping pattern, it will not know the set of multicast channels and the hopping sequence. However a malicious receiver on the local network can switch into "promiscuous mode" and intercept all the local traffic, including the multicast session data. Since data packets carry state information, it will not be impossible to reconstruct the session streams. However, there are many difficulties involved, which make this a non-trivial task. Firstly, operating in "promiscuous mode" is a resource intensive task, which may significantly degrade the performance of the impostor's end system. In addition to that, having to reassemble traffic based on a continually altered sequence of multicast channels makes real-time reconstructing of a session computationally very expensive. In cases where reassembling a session streams in real- time is not possible (e.g. because too much data must be processed), all the traffic data must be stored for later reconstruction of the session. This of course is only feasible for data without hard time constraints and may require huge amounts of storage memory. As a result, the effectiveness of such an attack depends highly on the type of data transmitted in the multicast session (time sensitive, computation intensive, etc), as well as on the hardware available.

However, if encryption is provided by the network environment, the sender of the multicast traffic can encrypt data within each data packet ensure data privacy. In this case the employment of multicast address hopping adds another level of security to the existing scheme. Spreading the data across several frequently changing addresses (unknown to a potential impostor) significantly hardens crypto-analysis on the end-to-end flows. Unless the receiver knows both the hopping pattern and the encryption key, there is no easy way of reconstructing the multicast session data, since encryption hides all kind of "sequence information" (e.g. in the network or transport header). A potential impostor cannot easily reassemble a data flow and perform crypto-analysis. Even if the encryption key is known, reconstructing the stream is extremely complex.

The SEM routers are the core entities that provide the multicast address hopping service to the clients. As a result, their processing load is a key factor in the scalability of the invention. It should be noted that in an active network environment the effect of the processing load of SEM routers can be mitigated by creating the SEM router hierarchy in response to system demand. Thus it is possible to accommodate a varying numbers of clients. This provides the architecture of a network in accordance with the invention with good scalability characteristics.

The Authentication server is the "central point" of authentication for clients wishing to join a multicast address hopping session. Considering the spanning of a multicast tree along multiple policy domains as well as the number of potential members of a multicast session, it is clear that this service should be distributed. The architecture provided by a preferred embodiment of the present invention therefore deploys one or more Authentication Servers per multicast communication session.

The effectiveness of the embodiment of the present invention used for multicast communication does not rely solely on a large set of multicast addresses for each session. Most important for the effectiveness of the invention is the hopping frequency and the selection of the hopping function. The continuous updating of the hopping sequence based on the hopping function, as well as the use of a pseudo-random function, makes it very difficult to find the correct hopping sequence (even for small number of addresses). Note that for an address set of size n and a stream of m packets, there are n possible combinations for spreading the packets across the multicast addresses. The fact that a small number of addresses allows a good level of security to be enforced means that the address space limitations of IPv4 do not affect the effectiveness of the invention. Thus the present invention does not impose problems related to IP address space utilisation. This is because the scope of the addresses can be local (as opposed to global), because the effectiveness of the invention relies mainly on the hopping frequency and the selection of the hopping function (not on a large set of IP addresses), and also because some addresses can be used for different multicast groups concurrently, thus enabling the reuse of the addresses.

Furthermore, the potential reuse of the same address set, as well as the periodic variation of the channel set and/or the hopping function as part of the hopping pattern update, which is securely propagated to the valid clients, makes it practically impossible for an impostor to infiltrate the multicast broadcast. One of the main concerns of deploying the multicast address hopping scheme is the additional processing overheads that are involved. These overheads are distributed between members of a multicast group, the SEM routers and the authentication servers.

Each multicast group member has the responsibility of authenticating itself with the authentication server, This usually takes place at the beginning of a multicast session, and subsequently each time the ticket expires. The lifetime of the ticket is best based upon the content/service, but this is a policy decision. Choosing a sufficiently long period may achieve the effect of once-per-session authentication. A member node is also responsible for maintaining synchronisation with the SEM router, by continually computing the next hopping address using a function supplied by the SEM router. Finally, the client needs to encrypt/decrypt parts of the packets (e.g. synchronisation information such as the packet counter). The overhead of this process depends on the level of protection required (i.e. the encryption mechanism), but marginal compared to normal IPSec processing.

Each SEM router must perform the operations equivalent to those performed by a member node in order to maintain synchronisation with the receivers and each sender. There is also a need for maintaining the data structures for synchronisation with the senders/receivers of each multicast group. This synchronisation includes the transfer of data representing host session keys, and the hopping patterns involved. Furthermore, the SEM routers will have to perform some sort of address translation, which will involve the re-computation of the checksums in the packet (at least for IPv4).

Authentication servers responsible for large numbers of client hosts may become heavily loaded at times. With this in mind, it is preferred that authentication servers are replicated as described above.

It has been described above that both the unicast and multicast embodiments of the invention can be used in conjunction with suitable encryption mechanisms. The invention can be implemented with an end-to-end encryption mechanism that differs slightly from standard IP Security (IPSec). Here, the sender does not encrypt the session data on a per packet basis, but instead applies encryption on data chunks that exceed the maximum transmission unit (i.e. the encrypted chunks are spread across several IP packets). In this case, crypto-analysis cannot be performed on a single packet. Instead the hopping pattern is essential in order to put the intercepted packets in sequence, before decryption is applied. Even if the encryption key is stolen, deciphering is practically impossible without the current hopping pattern. Moreover an attacker would need to know the segment size used for the flow encryption. It should be noted that this approach is only practical on reliable networks, where packet losses are infrequent, because in the case of a lost packet, all the IP packets belonging to the encryption segment would be worthless (i.e. impossible to decrypt). Hence, this option should only be employed on networks with reliable multicast capabilities or in conjunction with other types of error control and correction such as Forward Error Correction (FEC). FEC is used to refer to a set of methods that can be used to recover communication enors at the receiver end, without need for retransmission. The transmitted information conveys encoded state information suitable for detecting and correcting potential errors.

In the embodiments described above, the invention has been described with reference to its application to the Internet. However, it will be appreciated that the general address hopping mechanism of the invention is not limited to IP based networks, but is instead applicable to any network environment where data packets are sent between hosts, and security is to be improved.

Claims

1. A method of communication between hosts connected to a computer network, wherein: a stream of data packets which is to be sent to at least one predetermined host connected to the computer network is transmitted to a first set of network addresses, such that at least one first data packet in the stream of data packets is transmitted to a first network address in the first set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the first set of network addresses; and the at least one predetermined host is provided with means to determine the first network address to which the at least one first data packet is transmitted and the second network address to which the at least one second data packet is transmitted, such that the at least one predetermined host receives the stream of data packets.

2. A method according to claim 1, wherein a first host provides the first set of network addresses to a second host, the first host provides a first hopping sequence to the second host, and means are provided to synchronise the first and second hosts, such that the second host is able to receive data transmitted by the first host to the second host using the first set of network addresses and the said first hopping sequence.

3. A method according to claim 2, wherein the first host is able to receive data transmitted by the second host to the first host using the first set of network addresses and the said first hopping sequence.

4. A method according to claim 2, wherein the second host provides a second set of network addresses to the first host, the second host provides a second hopping sequence to the first host, and means are provided to synchronise the first and second hosts, such that data transmitted by the second host to the first host using the second set of network addresses and the said second sequence can be received by the first host.

5. A method according to claim 4, wherein the first set of network addresses includes a first sending set of network addresses and a first receiving set of network addresses, the second set of network addresses includes a second sending set of network addresses and a second receiving set of network addresses, and the first host can receive data packets sent from a network address in the second sending set of network addresses to the first receiving set of network addresses, and the second host can receive data packets sent from a network address in the first sending set of network addresses to the second receiving set of network addresses.

6. A method according to claim 1, wherein each network address comprises an Internet Protocol address and a Transmission Control Protocol port number.

7. A method according to any one of claims 2 to 6, wherein the or each set of network addresses and the or each hopping sequence are communicated between hosts in an encrypted form.

8. A method according to any one of claims 2 to 7, wherein the or each hopping sequence comprises a mathematical function which is evaluated by a host by which it is received to determine the order in which network addresses in the set of network addresses are used.

9. A method according to claim 8, wherein the mathematical function is a pseudorandom number generator.

10. A method according to claim 8 or 9, wherein the mathematical function takes a part of the hopping sequence which has been used as its argument.

11. A method according to any one of claims 2 to 10, wherein a sequence number is allocated to each data packet in the said stream of data packets, and the sequence number is used to synchronise the first and second hosts.

12. A method according to claim 1, wherein the at least one predetermined host is a plurality of hosts, and the plurality of hosts form a multicast group.

13. A method according to claim 12, wherein the stream of data packets is sent from a sender host which is a member of a multicast group to a router host, and from the router host to the plurality of hosts using the first set of network addresses.

14. A method according to claim 13, wherein the router host comprises means to transmit the stream of data packets to the first set of network addresses using a predetermined hopping sequence.

15. A method according to any one of claims 12, 13 or 14, wherein: the stream of data packets is sent from a sender host to a router host using a second set of network addresses such that at least one first data packet in the stream of data packets is transmitted to a first network address in the second set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the second set of network addresses; the router host is provided with means to determine the second set of network addresses and a second hopping sequence; on becoming a member of the multicast group, the sender host is provided with means to determine the second set of network addresses and the second hopping sequence; and the sender host sends the said stream of data packets to the second set of network addresses in the order determined by the hopping sequence, and the router host receives the said stream of data packets sent using the second set of network addresses and the second hopping sequence.

16. A method according to claim 15, wherein the first and second sets of network addresses are different.

17. A method according to claim 15, wherein the first and second sets of network addresses are identical, and the first and second hopping sequences are different.

18. A method according to any one of claims 13 to 17, wherein in order to join the multicast group, a host connected to the computer network presents a ticket to the router host, and the host is permitted to join the multicast group if the presented ticket is validly authenticated by the router host.

19. A method according to claim 18, wherein the ticket presented to the router host specifies whether the host is to receive data from the multicast group, and/or send data to the multicast group.

20. A method according to claim 18 or 19, wherein the ticket is provided to the host by an authentication server which is connected to the computer network.

21. A method according to claim 20, wherein the authentication server ensures that a user of the host is permitted to obtain the requested ticket, before the ticket is issued.

22. A method according to claim 20 or 21, wherein the ticket supplied by the authentication server is encrypted using a public key of a router to which it is to be presented.

23. A method according to any one of claims 20 to 22, wherein the ticket is signed using a signature of the authentication server.

24. A method according to any one of claims 18 to 23, wherein the ticket includes a session key which can be used for encrypted communication between the router host and the host.

25. A method according to any one of claims 18 to 23, wherein the ticket is presented to the host in an encrypted form, using an encryption key which is based upon a password of a user of the host.

26. A method according to any one of claims 14 to 25, wherein the hopping sequence includes a mathematical function specified by the router host.

27. A method according to claim 26, wherein the function is a pseudo-random number generator.

28. A method according to claim 26 or 27, wherein the function takes the order in which network addresses are used as an argument.

29. A method according to any one of claims 2 to 28, wherein a unique sequence number is allocated to each data packet of the said stream of data packets, and the unique sequence number is used to determine the network address in the first set of network addresses to which each data packet is transmitted.

30. A method according to claim 29, wherein the sequence number is included in a field of the data packet, such that each member of the multicast group can determine the current sequence number.

31. A method according to claim 30, wherein the sequence number is encrypted.

32. A method according to any preceding claim, wherein data included in the said stream of data packets is encrypted.

33. A method according to any preceding claim, wherein the stream of data packets collectively contain a series of encrypted data chunks, each encrypted chunk contains a quantity of data which is greater than a quantity of data contained in each data packet, and decryption of the stream of data packets requires a plurality of sequentially transmitted data packets.

34. A multicast router host device comprising a connection to a computer network, storage means suitable for storing a sequence of network addresses associated with any one multicast group, means for receiving a message requesting that a host be allowed to join the multicast group, and transmitting means activatable to provide details of the sequence of network addresses associated with the multicast group to the host.

35. A multicast router host device according to claim 34, further comprising access means to control access to the multicast group.

36. A multicast network router according to claim 34 or 35, further comprising means to change the said sequence of network addresses.

37. A host device comprising: means for connection to a computer network; means to transmit a stream of data packets which is to be sent to at least one predetermined host to a set of network addresses such that at least one first data packet in the stream of data packets is transmitted to a first network address in the first set of network addresses, and at least one second data packet in the stream of data packets is transmitted to a second different network address in the first set of network addresses; and means to determine a network address in the said set of network addresses to which a particular data packet in the said stream of data packets is to be sent.

38. A host device comprising: means for connection to a computer network; means to receive a stream of data packets which are transmitted using a set of network addresses; and means to determine a network address in the said set of network addresses to which a particular data packet in the said stream of data packets is sent.

39. A host device according to claim 37 and 38.

40. A computer network configured to carry out the method of any one of claims 1 to

33.

41. A method substantially as hereinbefore described, with reference to the accompanying drawings.

42. A computer network substantially as hereinbefore described, with reference to the accompanying drawings.

43. An multicast router host device substantially as hereinbefore described, with reference to the accompanying drawings.