HK1098269B - Method and system for providing a secure communication between communication networks - Google Patents

Description

Method and system for providing secure communication between communication networks

Technical Field

The present invention relates to a communication method.

Background

A communication system may be seen as a facility that enables communication sessions to be conducted between two or more entities such as user equipment and/or other nodes associated with the communication system. The communication may include, for example, voice communication, data communication, multimedia communication, and so on. A session may include, for example, a telephone call or a multi-way conference session between users, or a communication session between a user device and an Application Server (AS) (e.g., a service provider server). The establishment of these sessions generally enables various services to be provided to the user.

A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved. For example, a standard or specification may define whether a user, or more precisely a user equipment, is configured with circuit switched services and/or packet switched services. Communication protocols and/or parameters for making the connection are also defined. In other words, a specific set of "rules" on which the communication is based is defined to enable communication through the system.

Communication systems providing wireless communication for user equipment are known. An example of a wireless system is a Public Land Mobile Network (PLMN). PLMNs are typically based on cellular technology. In cellular systems, a Base Transceiver Station (BTS) or similar access entity serves wireless User Equipment (UE), also known as a Mobile Station (MS), over the air interface between these entities. The communication over the radio interface between the user equipment and the elements of the communication network may be based on a suitable communication protocol. The operation of the base station equipment and other equipment required for communication may be controlled by one or several control entities. The various control entities may be interconnected.

One or more gateway nodes may also be provided for connecting the cellular network to other networks, for example to a Public Switched Telephone Network (PSTN) and/or other communication networks, such as an IP (internet protocol) and/or other packet switched data networks. In such an arrangement, the mobile communications network provides an access network that enables a user with a wireless user device to access external networks, hosts, or services provided by specific service providers. The access point or gateway node of the mobile communication network then provides further access to an external network or an external host. For example, if the requested service is provided by a service provider located in another network, the service request is routed to the service provider through the gateway. The routing may be based on definitions in mobile subscriber data stored by the mobile network operator.

An example of a service that may be provided to a user of a communication system, such as a subscriber, is a so-called multimedia service. Some communication systems capable of providing multimedia services are referred to as Internet Protocol (IP) multimedia networks. IP Multimedia (IM) functionality may be provided by an IP multimedia Core Network (CN) subsystem, or simply an IP Multimedia Subsystem (IMS). The IMS includes various network entities for providing multimedia services. IMS services are intended to provide IP connectivity between mobile user equipment, as well as other services.

The third generation partnership project (3GPP) has defined the use of General Packet Radio Service (GPRS) for providing IMS services and thus will in the following be used as an example of a possible backbone communication network supporting IMS services. An exemplary General Packet Radio Service (GPRS) operating environment includes one or more sub-network service areas interconnected to each other by a GPRS backbone network. A sub-network includes a plurality of packet data Service Nodes (SNs). In this application, the serving node will be referred to as a Serving GPRS Support Node (SGSN). Each SGSN is connected to at least one mobile communication network, typically to a base station system. Typically, this connection is made through a Radio Network Controller (RNC) or other access system controller such as a Base Station Controller (BSC) in such a way that: packet services are provided to mobile user equipment through multiple base stations. The intermediate mobile communications network provides packet switched data transmission between the support node and the mobile user equipment. The different sub-networks are in turn connected to external data networks, for example to a public switched data network (PSPDN), via Gateway GPRS Support Nodes (GGSN). The GPRS service thus allows packet data transmission between mobile data terminals and external data networks.

In such networks, packet data sessions are established to carry traffic flows through the network. Such a packet data session is commonly referred to as a Packet Data Protocol (PDP) context. The PDP context may include a radio access bearer set up between the user equipment, the radio network controller and the SGSN, and a switched packet data channel set up between the serving GPRS support node and the gateway GPRS support node.

A data communication session between the user equipment and the other party may then be enabled in the established PDP context. Each PDP context can carry more than one traffic flow, but all traffic flows in a particular PDP context are handled in the same way with respect to their transmission through the network. The PDP context handling requirements are based on PDP context handling attributes associated with the traffic flows, such as quality of service and/or charging attributes.

The third generation partnership project (3GPP) has also defined a reference architecture for the third generation (3G) core network, which will provide users of user equipment with access to multimedia services. The core network is divided into three main domains. They are the Circuit Switched (CS) domain, the Packet Switched (PS) domain and the internet protocol multimedia (IM) domain. The latter, IM domain, is used to ensure that multimedia services are adequately managed.

The IM domain supports the Session Initiation Protocol (SIP) developed by the Internet Engineering Task Force (IETF). Session Initiation Protocol (SIP) is an application-layer control protocol for creating, modifying, and terminating sessions with one or more participants (endpoints). In general, SIP was developed to allow a session to be initiated between two or more endpoints in the internet by enabling the endpoints to be aware of the session semantics. A user connected to a SIP-based communication system may communicate with various communication system entities based on standardized SIP messages. A user equipment, or a user running a certain application on the user equipment, is registered with the SIP backbone in order to enable the initiation of a specific session to be correctly delivered to these endpoints. To accomplish this, SIP provides a registration mechanism for devices and users, and it applies mechanisms such as location servers and registrars to route session invitations appropriately. Examples of possible sessions that may be provided through SIP signaling include internet multimedia conferences, internet telephone calls, and multimedia distribution.

Reference is made to IETF document RFC 3325, which is incorporated herein by reference. This document describes a privacy extension to SIP that enables a network of trusted SIP servers to prove the identity of an end user or end system and to convey an indication of the privacy required by the end user. The use of these extensions can be applied in "trust domains" as defined in "Short terms requirements for network asserted Identity". Nodes in such a trust domain are explicitly trusted by their users and the final system to publicly prove the identity of each party and to be responsible for denying the provision of the identity outside the trust domain when privacy is required.

In order to be able to apply the privacy procedure described in RFC 3325, there is a need to detect the trustworthiness of the next hop network. If the next hop is trusted, a process involving a different privacy option is granted to the next hop. Otherwise, a privacy procedure needs to be performed.

As an example, if the caller requires Identity privacy, the P-Asserted-Identity header must be removed before it reaches the called party. The message sent by the caller contains a header identifying the sender, called a P-Asserted-Identity header. If the sender is a user with a known user identity, the format of the header is: < sip: user1_ public1@ home1.net >. The caller's home network must remove the header only if the called party's home network is not trusted. If the called party's home network, which is the next hop for the caller's home network, is trusted, the caller's home network will not remove the header. This is required in order to comply with RFC 3325, which specifies that the P-Asserted-Identity header must be removed by the last element of the trusted domain.

In RFC 3325, the proposed mechanism relies on a header field called "P-Asserted-Identity" that contains the URI (typically a SIP URI) and optionally the display name. A proxy server that processes a message can insert such a P-Asserted-Identity header field into the message after authenticating the originating user in some manner (e.g., digest authentication) and forward the message to other trusted agents. The proxy that is going to forward the message to a proxy server or UA that it does not trust will remove all P-Asserted-Identity header field values if the user requires that the information be kept private. Users may require this type of privacy.

For the process to be applied at the right place, the trustworthiness of the next hop must be detected in some way.

Disclosure of Invention

According to a first aspect of the present invention, there is provided a method of communicating between a calling party of a first network and a called party of a second network, comprising the steps of:

determining an address associated with said called party in the first network;

determining whether the called party is in a trusted network based on the address; and

controlling communication between the called party and the calling party depending on whether the called party is in a trusted network.

According to a second aspect, there is provided a communication system comprising a first network having a calling party and a second network having a called party, the first network comprising:

determining means for determining an address associated with the called party;

determining means for determining whether the called party is in a trusted network based on the address; and

control means for controlling communication between the called party and the calling party depending on whether the called party is in a trusted network.

According to a third aspect, there is provided a first network having a calling party arranged to call a called party in a second network, the first network comprising:

determining means for determining an address associated with the called party;

determining means for determining whether the called party is in a trusted network based on the address; and

control means for controlling communication between the called party and the calling party depending on whether the called party is in a trusted network.

According to a fourth aspect, there is provided a method of communicating between a calling party of a first network and a called party of a second network, comprising the steps of:

determining in the first network whether a secure connection exists with the second network; and

if it is determined that a secure connection to the second network does not exist, the message from the calling party to the called party is discarded or modified.

Drawings

For a better understanding of the present invention, reference will now be made, by way of example, to the accompanying drawings, in which:

FIG. 1 illustrates a communication system in which the present invention may be implemented;

FIG. 2 is a flow chart illustrating operation of one embodiment of the present invention;

FIG. 3 is an environment in which one embodiment of the present invention may be disposed.

Detailed Description

Embodiments of the present invention relate particularly, but not exclusively, to Rel-5 IMS networks. Embodiments of the present invention may also be applied to other versions of IMS networks. Embodiments of the present invention may be applied to other SIP networks. Some embodiments of the invention may find broader application outside of SIP and IMS environments.

Particular embodiments of the present invention will be described by way of example with reference to the exemplary architecture of a third generation (3G) mobile communication system. However, it should be understood that certain embodiments may be applied to any other suitable form of network. Typically, mobile communication systems are arranged to serve a plurality of mobile user equipment, typically via a wireless interface between the user equipment and a base station of the communication system. The mobile communication system may be logically divided into a Radio Access Network (RAN) and a Core Network (CN).

Referring to fig. 1, there is shown an example of a network architecture in which the present invention may be implemented. Fig. 1 shows an IP multimedia network 45 for providing IP multimedia services to IP multimedia network subscribers. IP Multimedia (IM) functionality can be provided through a Core Network (CN) subsystem, which includes various entities for providing services.

The base stations 31 and 43 are arranged to transmit signals to and receive signals from mobile user equipment 30 and 44 of mobile users, i.e. subscribers, over a wireless interface. Accordingly, each mobile user equipment is able to transmit signals to and receive signals from the base station over the wireless interface. In the simplified representation of fig. 1, the base stations 31 and 43 belong to different Radio Access Networks (RAN). In the arrangement shown, each of the user equipment 30, 44 may access the IMS network 45 via two access networks associated with the base stations 31 and 43, respectively. It should be understood that although fig. 1 shows base stations of only two radio access networks for clarity, a typical mobile communication network typically comprises a plurality of radio access networks.

The 3G Radio Access Network (RAN) is typically controlled by a suitable Radio Network Controller (RNC). For clarity, the controller is not shown. One controller may be assigned to each base station, or a controller may control multiple base stations. Solutions are also known in which the controller is provided both at an individual base station and at the radio access network level to control a plurality of base stations. It should therefore be understood that the name, location and number of network controllers depends on the system.

The mobile user may use any suitable mobile device adapted for Internet Protocol (IP) communication to connect to the network. For example, a mobile user may access a cellular network through a Personal Computer (PC), a Personal Data Assistant (PDA), a Mobile Station (MS), and so on. The following examples are described in the context of a mobile station.

Those skilled in the art are familiar with the features and operation of a typical mobile station. Therefore, a detailed explanation of these features is not necessary. It should be noted that a user may use a mobile station for tasks, such as for making and receiving phone calls, for receiving or sending data from or to a network, and for experiencing, for example, multimedia content. The mobile station is typically configured with a processor and memory means for accomplishing these tasks. The mobile station may comprise antenna means for wirelessly receiving and transmitting signals from and to base stations of the mobile communication network. The mobile station may also be provided with a display for displaying images and other graphical information to a user of the mobile user equipment. Speaker means may also be provided. The operation of the mobile station may be controlled by means of a suitable user interface, such as control buttons, voice commands and the like.

It should be understood that although only two mobile stations are shown in fig. 1 for clarity, multiple mobile stations may be in communication with each base station of the mobile communication system at the same time. The mobile station may also have several simultaneous sessions, e.g. multiple SIP sessions and activated PDP contexts. The user may also make a telephone call and connect to at least one other service simultaneously.

The Core Network (CN) entities typically include various control entities and gateways for supporting communication over multiple radio access networks and also for interfacing a single communication system with one or more communication systems, e.g., with other cellular systems and/or fixed line communication systems. In figure 1, the serving GPRS support nodes 33, 42 and the gateway GPRS support nodes 34, 40 are used to provide support for GPRS services 32, 41, respectively, in the network.

The radio access network controller is typically connected to an appropriate core network entity or entities such as, but not limited to, serving general packet radio service support nodes (SGSNs) 33 and 42. Although not shown, each SGSN typically has access to a designated subscriber database configured for storing information associated with respective user equipment subscriptions.

User equipment in a radio access network may communicate with a radio network controller through radio network channels, which are typically referred to as Radio Bearers (RBs). Each user equipment may open one or more radio network channels with the radio network controller at any time. The radio access network controller communicates with the serving GPRS support node over a suitable interface, for example the Iu interface.

The serving GPRS support node then communicates with the gateway GPRS support node, typically via the GPRS backbone network 32, 41. The interface is typically a switched packet data interface. The serving GPRS support node and/or the gateway GPRS support node are used to provide support for GPRS services in the network.

All communication between the user equipment at the access entity and the gateway GPRS support node is typically provided by a Packet Data Protocol (PDP) context. Each PDP context typically provides a communication path between a particular user equipment and a gateway GPRS support node, and once established, the PDP context is typically capable of carrying multiple flows. Each flow generally represents, for example, a particular service and/or a media component of a particular service. Thus, a PDP context often represents a logical communication path for one or more flows through a network. In order to implement a PDP context between the user equipment and the serving GPRS support node, a Radio Access Bearer (RAB) needs to be established, which typically allows data transmission for the user equipment. The implementation of these logical and physical channels is known to those skilled in the art and is therefore not discussed further herein.

The user equipment 30, 44 may be connected via the GPRS network to an application server, which is typically connected to the IMS.

Communication systems have been developed that make it possible to provide services to user equipment through various functions of a network that are handled by network entities called servers. For example, in the current third generation (3G) wireless multimedia network architecture, it is assumed that several different servers are used to handle different functions. This includes functions such as Call Session Control Functions (CSCFs). Call session control functions may be divided into various categories such as proxy call session control functions (P-CSCFs) 35 and 39, query call session control functions (I-CSCFs) 37, and serving call session control functions (S-CSCFs) 36 and 38. A user wishing to use a service provided by an application server over an IMS system may need to register with a service control entity. The serving call session control function (S-CSCF) may form an entity in the 3G IMS setup with which the user needs to register in order to be able to request services from the communication system. The CSCF may define an IMS network of the UMTS system.

It should be understood that similar functions may be referred to by different names in different systems. For example, in certain applications, a CSCF may be referred to as a call state control function.

The communication system may be arranged such that a user who has been provided with the required communication resources by the backbone network has to initiate the use of the service by sending a request for the desired service via the communication system. For example, a user may request a session, transaction, or other type of communication from an appropriate network entity.

In one embodiment of the invention, there is a database at the S-CSCF of the calling party' S home network listing all known IMS network domain names and IP addresses trusted by the home network.

A database containing the IMS network domain name and the IP address of the corresponding I-CSCF must be maintained in the SIP layer database. Since the SIP request may contain both the domain name and the IP address in the request (R) universal resource indicator. It is not sufficient to store only the domain name in the database. The calling party can thus check whether the called party is in a trusted or untrusted network by looking at the domain name or IP address associated with the called party stored in the database.

However, it is possible in an alternative embodiment of the invention that the reverse DNS domain name server query is made whenever an IP address is received in the R-URI instead of the domain name. Thus, the following simplified scheme is also possible, which will be described with reference to fig. 2:

the database holds IMS network domain names trusted by the local networks.

In step S1, it is determined that the request includes a domain name.

If the result is positive, step S2 is next performed, in which a check is made to see if the domain is in the database. If the result is positive, the next hop is considered as a trusted domain and the corresponding procedure is applied (step S3). If the domain is not in the database, the next hop is considered to be an untrusted domain and the corresponding procedure is applied-step S4.

If the called party is an untrusted party, the message may be discarded or optionally modified. If the message is modified, the information identifying the calling party will be removed. The information may be a P-Asserted header. If the caller has requested privacy, the process will be performed, i.e. its identity will be kept secret.

If the request does not contain a domain name, it is determined whether a request with an IP address is received in the R-URI-step S5. Step S5 and step S1 may be combined into a single step. If the request contains an IP address, a reverse DNS query is made to find the corresponding domain, step 6. I.e. sends a request to the domain name server for the domain name associated with the IP address. The next step will then be step S2, where the database is checked.

In another embodiment of the invention a database is kept only at the S-CSCF of the home network listing all known IMS network domain names trusted by the home network.

If the R-URI contains an IP address instead of a domain name (and therefore cannot be checked against the database), then it is simply assumed that the next hop is an untrusted domain.

In yet another embodiment of the present invention, NDS network domain security is configured in a security gateway (SPD) in such a way that: IP packets from the CSCF of the domain of which the gateway is part will be sent over the secure connection. If a secure connection to the destination does not exist, the packet is simply dropped and an ICMP Internet control message protocol message is generated. ICMP is an internet protocol that delivers error and control messages between a gateway or destination host and a source host with respect to IP datagram processing. ICMP can, for example, report errors in IP datagram processing. ICMP is typically part of the IP protocol. Thus, the home network always assumes that the next hop is trusted and does not remove the P-Asserted-Identity. If it happens that the next hop is not trusted, the packet is dropped and it does not reach the called party.

As a result of this scheme, the CSCF will only be able to communicate with SIP entities belonging to trusted domains.

Reference is made to the third generation partnership project specification version 3.3.0, TS33.210, which is incorporated herein by reference. This document describes an outline of a network domain security architecture. Referring to FIG. 3, such an architecture is shown in which embodiments of the present invention may be applied.

First, an explanation will be given regarding Za and Zb interfaces existing between and among networks, respectively. The explanation is adopted from 3GPP TS33.210 v6.0.0 (12 months 2002), release 6. Fig. 3 shows two security domains, and the Za and Zb interfaces between the entities of these domains.

Defining interfaces to protect local IP-based protocols:

za interface (SEG-SEG)

The Za interface covers NDS/IP (network domain security/internet protocol) traffic between all security domains. SEGs (security gateways) use IKE (internet key exchange) to negotiate, establish and maintain a secure ESP (encapsulated secure payload) channel between them. Subject to roaming agreements, an interactive SEG channel (inter-SEG tunnel) is normally available at all times, but can also be established when required. ESP will be used with encryption and authentication/integrity, but allowed only authentication/integrity mode. Next, the NDS/IP traffic is forwarded between security domain A and security domain B using tunneling.

One SEG can be dedicated to serve only a certain subset of all roaming partners. This will limit the number of SAs and tunnels that need to be serviced.

All security domains that comply with this specification should operate the Za-interface.

Zb interface (NE-SEG/NE-NE)

The Zb interface is located between the SEG and the NE and between NEs within the same security domain. The implementation of the Zb interface is optional. If implemented, it will implement ESP + IKE.

ESP will always be used with authentication/integrity protection at the Zb interface. The use of encryption is optional. The ESP security association will be used for all control plane traffic that needs security protection.

Whether the security association is established when needed or a priori is decided by the security domain operator. The security association is then used to exchange NDS/IP traffic between the NEs.

The security policy established on the Za interface is subject to roaming agreements. This is different from the security policy implemented on the Zb interface, which is unilaterally decided by the security domain operator.

The basic idea for the NDS/IP architecture is to provide hop-by-hop security. This is consistent with the chain-channel (chained-channel) or hub-and-spoke (hub-and-spoke) model of operation. Using hop-by-hop security also makes it easy to operate independent security policies internally as well as to other external security domains.

In NDS/IP, only the security gateway (SEG) would be directly involved in communicating with other entities in the security domain for NDS/IP traffic. The SEG will then establish and maintain IPsec protected ESP security associations in tunnel mode between security domains. Normally, an SEG will maintain at least one IPsec tunnel that is available at all times to a particular peer SEG. The SEG will logically maintain separate SAD and SPD databases for each interface.

The NE may be able to establish and maintain ESP security associations to SEGs or other NEs within the same security domain, if needed. All NDS/IP traffic from an NE of one security domain to an NE of a different security domain will be routed through the SEG and will be undertaken by hop-by-hop security protection to the final destination.

The operator may decide to establish only one ESP security association between two communicating security domains. This results in a coarse-grained security granularity. This has the benefit that it gives a certain amount of protection with respect to traffic flow analysis, while the disadvantage that it will not be possible to distinguish a given security protection between communicating entities. This does not preclude negotiation of a finer granularity of security granularity as determined by the communicating entities.

In an embodiment of the present invention, the SEG of the calling party will determine whether the packet of the called party will be sent to the SEG of the called party over a secure connection. If no secure connection exists, the packet is dropped. If a secure connection exists, the packet is sent.

In one embodiment, if there is no secure connection, the SEG of the calling party will remove the identity information, i.e., the P-Asserted header, from the message. The modified message is then sent to the called party.

In an embodiment of the present invention, P-asserted header information is removed from the packet. In an alternative embodiment of the invention, where P-Asserted information is not present, the identification information relating to the identity of the calling party is removed.

The database is described as storing only trusted party identities. In one refinement it is possible to store only the identity of the untrusted party or to store both the untrusted and trusted parties together with information indicating whether they are trusted or not.

It will be appreciated that the description of one embodiment in which a GPRS system is present is by way of example only, and that other systems may be used in alternative embodiments of the invention.

It should be appreciated that whilst embodiments of the present invention have been described in relation to user equipment such as mobile stations, embodiments of the present invention may be applied to any other suitable type of user equipment.

Examples of the present invention have been described in the context of an IMS system and a GPRS network. The invention can also be applied to any other access technology. Furthermore, the given example is described in the context of a SIP network with supporting SIP entities. The invention is also applicable to any other suitable communication system, both wireless and fixed line systems, as well as standards and protocols.

Embodiments of the present invention have been discussed in the context of a call state control function. Embodiments of the present invention can be applied to other network elements that may be used.

It is also noted herein that while the above describes exemplifying embodiments of the invention, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention as defined in the appended claims.

Claims (24)

1. A method of communicating between a calling party of a first network and a called party of a second network, comprising:

determining an address associated with said called party in the first network;

determining whether the called party is in a trusted network based on the address; and

controlling communication between the called party and the calling party depending on whether the called party is in a trusted network, wherein at least one message to the called party is modified if the called party is not in a trusted network.

2. The method of claim 1, wherein the address is included in a message of the called party.

3. The method of claim 2, wherein the message is in the form of a packet.

4. A method as claimed in any preceding claim, wherein determining whether the called party is in a trusted network comprises checking whether the address is contained in a database of trusted networks.

5. The method of claim 4, wherein the database is in the first network.

6. A method according to claim 4, wherein the database is provided in a call session control function or in a security gateway.

7. The method of claim 4, wherein the database includes a domain name associated with the trusted network and optionally an IP address of the trusted network.

8. The method of claim 1, wherein said determining an address comprises determining whether the address contains a domain name.

9. The method of claim 8, wherein if it is determined that the address does not contain a domain name, sending a request for the domain name.

10. The method of claim 9, wherein the request is sent to a domain name server.

11. A method according to claim 1, wherein if it is determined that the address does not contain a domain name, then it is assumed that the called party is in an untrusted network.

12. A method according to claim 1, wherein said at least one message to the called party is modified by removing identity information relating to said calling party.

13. The method of claim 12, wherein the Identity information is a P-Asserted-Identity header.

14. The method of claim 1, wherein the first and second networks operate in accordance with SIP.

15. The method of claim 1, wherein the determining whether the called party is in a trusted network comprises determining whether a connection from the calling network to the called network is secure.

16. The method of claim 15, wherein determining whether the called party is in a trusted network is performed at a gateway of the calling network.

17. The method of claim 16, wherein determining whether the called party is in a trusted network comprises determining whether a connection between a gateway of the calling network and a gateway of the called network is a secure connection.

18. The method of any of claims 15-17, wherein the first network is a first domain.

19. The method of any of claims 15-17, wherein the second network is a second domain.

20. A communication system comprising a first network having a calling party and a second network having a called party, the first network comprising:

determining means for determining an address associated with the called party;

determining means for determining whether the called party is in a trusted network based on the address; and

control means for controlling communication between the called party and the calling party depending on whether the called party is in a trusted network, wherein at least one message to the called party is modified if the called party is not in a trusted network.

21. A first network having a calling party arranged to call a called party in a second network, said first network comprising:

determining means for determining an address associated with the called party in the second network;

determining means for determining whether the called party is in a trusted network based on the address; and

control means for controlling communication between the called party and the calling party in said first network depending on whether said called party is determined to be in a trusted network, wherein at least one message to the called party is modified if the called party is not in a trusted network.

22. A first network according to claim 21, wherein said determining means comprises means for determining whether a link from the first network to the second network is secure.

23. The first network of claim 21 or 22, wherein the determining means is located at a gateway of the first network.

24. A first network according to claim 21, 22 or 23, wherein the gateway is a security gateway of the first network.