The Dynamic Host Configuration Protocol (DHCP) is a protocol for managing and dynamically assigning IP (Internet Protocol) addresses to stations in a TCP/IP (Transmission Control Protocol/Internet Protocol) network. DHCP is a client-server-architecture and a process as illustrated in FIG. 1 is performed between the client and the server for assigning an IP address (without considering GTP (GPRS (General Packet Radio Service) Tunneling Protocol).
As shown in FIG. 1, the client sends a broadcast message ‘DHCP-Discovery’ to the server in step S11 which in turn responds in step S12 with a ‘DHCP-Offer’ message including an proposal for an IP address and other relevant parameters. Then, the client broadcasts a “DHCP-Request” message in step S13 for confirming/requesting the IP address offered in the “DHCP-Offer” message and the sever responds in step S14 with a “DHCP-ACK” message containing the configuration parameters for the requesting client. Details in this regard are described in the document RFC (Request for Comments) 2131.
FIG. 2 is a signaling diagram (cf. 3GPP TS (Technical Specification) 29.061) illustrating another example of an address allocation using DHCPv4 between a terminal equipment (TE) acting as the DHCP client and an Intranet or ISP (Internet Service Provider) acting as the DHCP server. FIG. 2 further shows a mobile terminal (MT), a SGSN (Serving GPRS Support Node) and a GGSN (Gateway GPRS (General Packet Radio Service) Support Node) acting as a DHCP relay agent. The following description of steps 1) to 12) of FIG. 2 is taken from TS 29.061. For details in this regard, reference is made to this document.
In step S21, the TE (Terminal Equipment) and MT (Mobile Terminal) exchange several AT (Attention, as described for example in 3GPP TS 27.007) commands carrying the QoS (Quality of Service) and other parameters requested by the TE, and requesting the activation of a PDP (Packet Data Protocol) context of PDP type IP. The TE selects the APN (Access Point Name) of the configured Intranet/ISP offering a DHCP service, or the APN consisting of the Reserved Service Label for DHCP that the user has subscribed to. In the latter case the TE will be connected to a PLMN (Public Land Mobile Network) operator-configured service provider offering a DHCP service (according to the APN selection rules).
In step S22, the MT sends the Activate PDP Context Request message to the SGSN with an empty PDP address field.
In step S23, the SGSN selects a GGSN based on the APN requested by the MS (Mobile Station), constituted by the TE and the MT, and sends a Create PDP (Packet Data Protocol) Context Request message to that GGSN. The GGSN replies with a Create PDP Context Response message. If the GGSN has not been configured by the operator to use external PDN (Packet Data Network) address allocation with DHCP for the requested APN, the cause shall be set to ‘Service not supported’. No IP address is assigned at this point; the PDP address returned by the GGSN is set to 0.0.0.0, indicating that the IP address is not yet assigned and shall be negotiated by the TE with the Intranet/ISP after the PDP context activation procedure.
In step S24, depending on the cause value received in the Create PDP Context Response, the SGSN sends either an Activate PDP Context Accept or an Activate PDP Context Reject back to the MT. In case of a successful activation, the PDP context is established with the PDP address set to 0.0.0.0.
In step S25, upon reception of the Activate PDP Context Accept, the MT sends an AT response to the TE that acknowledges the completion of the PDP context activation procedure.
In step S26, the TE sends a DHCPDISCOVER message with the IP destination address set to the limited broadcast address (all 1 s). The GGSN will pass the DHCPDISCOVER to the DHCP relay agent which will relay the request to the DHCP server configured for the APN of the PDP context. If more than one DHCP server is configured for a given APN, the request will be sent to all of them. The DHCP relay agent will add enough information to the DHCPDISCOVER message to be able to relay the replies back to the MS.
In step S27, DHCP servers receiving the DHCPDISCOVER request reply by sending a DHCPOFFER message including an offered IP address. The DHCP relay agent forwards the replies to the proper MS.
In step S28, the TE chooses one of the possibly several DHCPOFFERs and sends a DHCPREQUEST confirming its choice and requesting additional configuration information. The relay agent relays the DHCPOFFER as explained in step S26.
In step S29, the selected DHCP server receives the DHCPREQUEST and replies with a DHCPACK containing the configuration information requested by the TE. The DHCP relay agent relays the DHCPACK to the TE.
In step S210, the DHCP relay agent passes the allocated IP address to the GGSN which stores it in the corresponding PDP context. The GGSN then initiates a PDP context modification procedure by sending an Update PDP Context Request to the appropriate SGSN with the End User Address information element set to the allocated IP address.
In step S211, the SGSN sends a Modify PDP Context Request to the MT with the allocated IP address in the PDP Address information element. The MT acknowledges by sending a Modify PDP Context Accept to the SGSN.
In step S212, the SGSN sends an Update PDP Context Response to the GGSN. The PDP context has been successfully updated with the allocated IP address.
Regarding 3GPP, in case the UE requested the IP address allocation via DHCP, the GTP-U (GPRS Tunneling Protocol User Plane) carries both the DHCP signaling traffic and the payload of the traffic generated by the UE.
Further, according to today's OpenFlow specification, it is in general possible to send all the DHCP messages being received in the GTP-U of the EPC GW (Evolved Packet Core Gateway) up to the controller in an SDN (Software Defined Networking) environment.
Thus, in SDN, all DHCP messages being received in the user plane may be sent to a SDN controller. However, this raises security concerns as the SDN controller can be flooded by DoS (Denial-of-Service) attacks.
Thus, a solution is required to secure the controller to ensure a carrier grade behavior of the network such that other users/subscriber of the customer's network and of course the networks itself are not impacted by a corresponding attack.
As the DHCP protocol is UE originated, if the UE requested DHCP via the PCO (Protocol Configuration Option, see 3GPP TS 24.008, either via the S5/S8 interface TS 29.274 GTPv2 control Plane (4G) or via the Gn interface TS 29.060 GTPv1 control Plane (3G)), the UE can impact the network SDN controller.
In former times, the SDN controller did not exist as such. Therefore the threat that the operators network is potentially attacked and damaged (due to that especially the SDN controller may not be able to control the flows in the assigned switches in the network as appropriate anymore) is newly created by the SDN approach. Up to now, before the SDN was introduced, it was not necessary to take care as there was no threat.
Currently, either all DHCP messages are sent to the controller or none, but the PGW-C (Packet Data Network Gateway control plane) needs to have the IP address which is allocated/assigned to the UE. So in the SDN environment, there are conflicting requirements which are not solved today.
However, it is noted that DHCP is just an example. The above described issues and the present invention is also applicable to other protocols like for example, RADIUS (Remote Authentication Dial-In User Service), L2TP (Layer 2 Tunneling Protocol) and PPP (Point-to-Point Protocol) etc.
FIG. 9 is a signaling diagram illustrating an example of a successful PDP context activation, as defined in 3GPP TS 29.061.
In the example shown in FIG. 9, the MS (Mobile Station) is given an address belonging to the Intranet/ISP addressing space. The address is given either at subscription in which case it is a static address or at PDP context activation in which case it is a dynamic address. This address is used for packet forwarding within the GGSN and for packet forwarding on the Intranet/ISP. This requires a link between the GGSN and an address allocation server, such as AAA (Authentication, Authorization and Accounting), or DHCP, belonging to the Intranet/ISP.
The communication between the Packet Domain and the Intranet/ISP may be performed over any network, even an insecure e.g. the Internet. In case of an insecure connection between the GGSN and the Intranet/ISP there may be a specific security protocol in between. This security protocol is defined by mutual agreement between PLMN (Public Land Mobile Network) operator and Intranet/ISP administrator.
In step S91, the TE sends an AT-command to the MT to set up parameters.
In step S92, the MT sends the Activate PDP context request message to the SGSN which sends the Create PDP context request message to the chosen GGSN in step S93.
The GGSN deduces from the APN                the server(s) to be used for address allocation and authentication;        the protocol such as RADIUS, DHCP or L2TP to be used with this/those server(s);        the communication and security feature needed to dialogue with this/those server(s) e.g. tunnel, IPSec security association, dial-up connection (using possibly PPP).As an example the GGSN may use one of the following options:        RADIUS for authentication and IP-address allocation. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN;        RADIUS for authentication and DHCP for host configuration and address allocation. The AAA server responds with either an Access-Accept or an Access-Reject to the RADIUS client in the GGSN. After a successful authentication, the DHCP client discovers the DHCP server(s) in the ISP/Intranet and receives host configuration data;        L2TP for forwarding PPP frames to a L2TP Network Server.        
In step S94, the GGSN sends back to the SGSN a Create PDP Context Response message. Depending on the cause value received in the Create PDP Context Response the SGSN may either send the Activate PDP Context Accept message or send the Activate PDP Context Reject message to the MS in step S95.
In step S96, the MT responds with an AT-response that may indicate whether the context activation was successful or not. In the case of a non-successful context activation the response may also indicate the cause.
In case of successful context activation, the TE will start its PPP protocol after the LLC (Logical Link Control) link has been established. The LCP (Link Control Protocol), Authentication and NCP (Network Control Protocol) negotiations are then carried out in step S97 and RADIUS/DHCP or L2TP negotiation is carried out in step S98.
FIG. 10 describes an example of RADIUS message flows between a GGSN and an Authentication, Authorization and Accounting (AAA) server for the case where PPP is terminated at the GGSN, as described in 3GPP TS 29.061. A detailed description thereof is omitted here and reference is made to TS 29.061 in this regard.