WO2017207026A1

WO2017207026A1 - Technique for enhancing transport protocol initiation

Info

Publication number: WO2017207026A1
Application number: PCT/EP2016/062254
Authority: WO
Inventors: Szilveszter NÁDAS; Attila MIHÁLY
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-05-31
Filing date: 2016-05-31
Publication date: 2017-12-07

Abstract

An extended transport protocol - TP - for establishing a connection between two endpoints, namely a client (10) and a server (12) is presented. The extended TP supports the presence or absence of a performance enhancing proxy (14) - PEP - situated at a network node. When a PEP wishes to participate in the connection, it intercepts a TP setup request from a client, terminates the connection to the client and initiates a new connection to the server. The TP is extended such that, in the TP setup request, there are placed in a declarative information part of the request, proxy security setup information for the PEP and application-layer security setup information for the server. With this approach, either or both of the TPs between client and proxy and between proxy and server can be encrypted. The TP setup request sent by the client also includes default protocol setup information for a server in case the TP setup request is received directly by the server without PEP intervention. This allows the client-server connection to be established conventionally if needed.

Description

Technique for enhancing transport protocol initiation

Technical Field

The present disclosure generally relates to Transport Protocols (TPs) of the type that support Performance Enhancing Proxies (PEPs) and in particular those aspects of a transport protocol that are relevant for establishing a communications connection between client and server endpoints of a communications path. The technique of the present disclosure may be embodied in a method, a client, a server, a network node, and a computer program product.

Background

TPs continuously evolve as a result of new requirements emerging from the evolution on the application layer and the service layer. As a result, new TPs have been proposed such as Quick User Datagram Protocol (UDP) Internet Connections (QUIC) which is a TP for HyperText Transfer Protocol 2 (HTTP2). Details of QUIC are described in Iyengar & Swett 2015 http://tools.ietf.org/html/draft-tsvwg-quic-protocol- 00 "QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2

draft-tsvwg-quic-protocol-OO" 17 June 2015.

Some TPs support the inclusion of PEPs. As will be discussed in more detail below, PEP is a particular type of proxy which is used to improve the performance of a connection between two endpoints. A PEP is useful in situations where native performance suffers due to characteristics of a link or subnetwork on the path, for example a noisy wireless environment or communication between a satellite and a ground base station. A description of PEPs is given in RFC3135: Border, Kojo, Griner, Montenegro & Shelby 2001: https://tools.ietf.org/html/rfc3135 "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations" June 2001.

TPs ideally incorporate one or more of the following features: (i) ability to evolve to take account of technical developments; (ii) short setup time of connections; (iii) ability to handle encrypted communication; and (iv) compatibility with PEPs. Each of these desirable features is now discussed in turn. Ability to Evolve: Specifically, in TPs, it is desired to avoid the ossification that is apparent with the ubiquitous Transmission Control Protocol (TCP). An example of a TP which is capable of evolving is QUIC, specifically its pluggable congestion control feature. Pluggable congestion control allows the congestion control algorithms to be updated if needed.

Short Setup Time: A desirable feature of TPs is a short setup time for the connection. For example, QUIC provides for fast setting up. Initial setup in QUIC frequently requires only one roundtrip handshake, i.e. a Round Trip Time (RTT) of one, which is needed for security context establishment and involves creating a unique Connection ID (CID). Re-establishing an existing server connection frequently requires a zero roundtrip before sending a payload, i.e. a RTT of zero, by re-using the unique CID already known from the previous connection.

Encryption: A desirable feature of TPs is that they should be able to handle encryption of all aspects of the communication including the TP layer, in order to provide the desired security and privacy.

PEPs: It is desirable to incorporate PEPs into the TP layer. PEPs are network agents designed to improve the end-to-end performance of a communications protocol by intercepting communications data intended for a recipient and then re-transmitting these data, typically in a different TP. A PEP thus acts as a translator. PEPs represent a single point of control in the network, and therefore can select the most appropriate TPs with the most appropriate parameter settings to each of the endpoints of the connection. Improved TP performance can be expected, since the PEP has access to intrinsic information that is not available to the endpoints themselves. It should therefore be possible to set up or resume a TP connection to a remote endpoint in such a way that a trusted PEP is able to terminate the TP from either endpoint of the communication link.

PEPs come in different types, in particular there are "explicit PEPs" and "transparent PEPs". An explicit PEP needs to have pre-configured settings at the endpoints to know with which entity to set up the connection, so will be associated with longer setup times. On the other hand, a transparent PEP does not need configured end- points, so is compatible with rapid setup. However, transparent PEPs only function with unencrypted TPs, so security is compromised. Some example patent publications which relate to the insertion of proxies in a communications path are as follows.

US 9 054 913 Bl provides a network proxy as a layer between an application layer protocol, such as the Remote Desktop Protocol (RDP), and a transport layer protocol, such as TCP. The network proxy can intercept communications between the application layer protocol and the transport layer protocol. The network proxy can transmit communications on multiple connections, without the application layer or transport layer protocols being aware of the parallelization.

US 2012 272058 Al, now issued as US 8 504 822 B2, discloses a method which involves obtaining server security information at a proxy device from a server. A client-proxy security session is initiated from the device using a trusted proxy certificate of the device. Client security information is obtained at the device. A dynamic certificate is created using the obtained client information and the proxy certificate. An initiated proxy-server security session is established with the dynamic certificate. The client-proxy session is established, where the session transparently appears to the client and server as a requested client-server security session.

Summary

Referring back to the above discussion of PEPs, it is therefore desired to provide a TP which incorporates the use of PEPs, but with a better compromise between setup speed and security than is possible with currently available explicit and transparent PEPs.

According to one aspect of the disclosure, there is provided a method by which a client initiates a packet-based transport protocol connection between a client and a server, comprising:

(a) generating default protocol setup information for a server;

(b) generating proxy security setup information for a performance enhancing proxy and application-layer security setup information for a server;

(c) generating a connection setup request having a first part and a second part, wherein the default protocol setup information is placed in the first part and the proxy security setup information as well as the application-layer security setup information are placed in the second part; and

(d) sending the connection setup request as a connection setup request. According to another aspect of the disclosure, there is provided a method of mediating a packet-based transport protocol connection between a client and a server at a network node hosting a performance enhancing proxy, the method comprising:

(a) intercepting a connection setup request from a client at the performance enhancing proxy, wherein the connection setup request includes: (i) default protocol setup information for a server which is in a first part of the connection setup request; and (ii) proxy security setup information for a performance enhancing proxy and application-layer security setup information for a server which are in a second part of the connection setup request;

(b) terminating the connection towards the client;

(c) extracting the proxy security setup information;

(d) generating a new setup request for the server by extracting the application- layer security setup information to the server; and

(e) sending the new setup request to the server.

In the course of generating the new setup request, it is additionally possible to include one or more of the following in that request: a token indicating proof of ownership of an internet protocol address; an indication of the transport protocol being used to send the new setup request; a version number for said transport protocol; and an application type.

According to another aspect of the disclosure, there is provided a method by which a server establishes a packet-based transport protocol connection to a client mediated by a performance enhancing proxy, the method comprising:

(a) receiving a connection setup request including application-layer security setup information for the server and transmitter credentials;

(b) checking the transmitter credentials to determine whether the connection

setup request was transmitted by a performance enhancing proxy or a client; and

(c) if the connection setup request is determined to have been transmitted by a performance enhancing proxy, sending a first setup request to the performance enhancing proxy containing the server credentials for the performance enhancing proxy and a first token for server-proxy communication, and also, placed in the first setup request, a second setup request for the client containing the server credentials for the client and a second token for client-server communication. The performance enhancing proxy is thus able to extract the second setup request for the client and send it on to the client using a protocol selected by the performance enhancing proxy.

In the above aspect, if the connection setup request is determined to have been transmitted by a client, the server may send a setup request to the client containing the server credentials for the client and a token for client-server communication.

According to another aspect of the disclosure, there is provided a method for establishing a packet-based transport protocol connection between a client and a server, wherein a connection setup request issued by a client includes:

(a) default protocol setup information for a server which is in a first part of the connection setup request; and

(b) proxy security setup information for a performance enhancing proxy and application-layer security setup information for a server which are in a second part of the connection setup request, and

wherein,

if the connection setup request is intercepted by a performance enhancing proxy, the performance enhancing proxy terminates the connection towards the client, sets itself up using the proxy security setup information, and establishes a new connection to the server using the application-layer security setup information, whereas,

if the connection setup request is received by a server without interception by a performance enhancing proxy, the server establishes a connection to the client based on the default protocol setup information.

According to further aspects of the disclosure, there is provided a computer program product bearing machine readable instructions executable to implement a packet- based transport protocol according to the methods of any of the above method aspects of the disclosure. The computer program product may be stored on a computer readable recording medium.

According to another aspect of the disclosure, there is provided a client capable of initiating a packet-based transport protocol connection to a server, wherein the client is operable:

(a) to generate default protocol setup information for a server;

(b) to generate proxy security setup information for a performance enhancing proxy and application-layer security setup information for a server; (c) to generate a connection setup request having a first part and a second part, wherein the default protocol setup information is placed in the first part and the proxy security setup information as well as the application-layer security setup information are placed in the second part; and

(d) to send the connection setup request.

According to another aspect of the disclosure, there is provided a network node hosting a performance enhancing proxy capable of mediating a packet-based transport protocol connection between a client and a server, wherein the performance enhancing proxy is operable:

(a) to intercept a connection setup request from a client at the performance enhancing proxy, wherein the connection setup request includes: (i) default protocol setup information for a server which is in a first part of the connection setup request; and (ii) proxy security setup information for a performance enhancing proxy and application-layer security setup information for a server which are in a second part of the connection setup request;

(b) to terminate the connection towards the client;

(c) to extract the proxy security setup information;

(d) to generate a new setup request for the server by extracting the application- layer security setup information to the server; and

(e) to send the new setup request to the server.

In the above network node, the performance enhancing proxy can be further operable to add to the new setup request one or more of the following: a token indicating proof of ownership of an internet protocol address; an indication of the transport protocol being used to send the new setup request; a version number for said transport protocol; and an application type.

According to another aspect of the disclosure, there is provided a server capable of establishing a packet-based transport protocol connection to a client mediated by a performance enhancing proxy, the server being operable:

(a) to receive a connection setup request including application-layer security setup information for the server and transmitter credentials;

(b) to check the transmitter credentials and determine whether the connection setup request was transmitted by a performance enhancing proxy or a client; and

(c) if the connection setup request is determined to have been transmitted by a performance enhancing proxy, to send a first setup request to the perfor- mance enhancing proxy containing the server credentials for the performance enhancing proxy and a first token for server-proxy communication, and also, in the first setup request, a second setup request for the client containing the server credentials for the client and a second token for client-server communication.

The performance enhancing proxy is thus able to extract the second setup request for the client and send it on to the client using a protocol selected by the performance enhancing proxy.

The server can be further operable, if the connection setup request is determined to have been transmitted by a client, to send a setup request to the client containing the server credentials for the client and a token for client-server communication.

According to another aspect of the disclosure, there is provided a system comprising a client, a server and a performance enhancing proxy, the system being operable to establish a packet-based transport protocol connection between the client and the server, wherein a connection setup request issued by a client includes:

wherein,

if the connection setup request is intercepted by the performance enhancing proxy, the performance enhancing proxy is operable to terminate the connection towards the client, set itself up using the proxy security setup information, and establish a new connection to the server using the application-layer security setup information, whereas,

if the connection setup request is received by the server without interception by the performance enhancing proxy, the server is operable to establish a connection to the client based on the default protocol setup information.

In certain embodiments, the second part of the connection setup request may be designated as declarative information. In certain embodiments, the second part of the connection setup request may be in a protocol layer below that of the transport protocol being used to transmit the packet.

In certain embodiments, the second part of the connection setup request is a service data unit (SDU) part.

In certain embodiments, the second part of the connection setup request may be in a Concise Binary Object Representation (CBOR) map of a Substrate Protocol for User Datagrams - SPUD - message. The packet-based transport protocol may for example be an extended version of SPUD.

SPUD is an example of a protocol, which can be easily extended to include declarative information parts. A possible option is to include SPUD as an additional layer below evolved transport protocols so that the SPUD layer can be used to support declarative information parts. This idea builds on the declarative nature of the SPUD information elements, i.e. that it is expected and safe to discard any CBOR key-value pairs which are not understood.

Another example protocol to which embodiments can be applied is TCP (Transmission Control Protocol), more especially TCP Fast Open, the specification of which was published as RFC 7413. TCP Fast Open has a feature for opening subsequent TCP sessions between the client and the server.

In certain embodiments, the second part of the connection setup request may be in an extension header of the transport protocol being used to transmit the connection setup request.

Brief Description of the Drawings

The embodiments of the technique presented herein are described herein below with reference to the accompanying drawings.

Figure 1A shows a performance enhancing proxy arranged between a client and a server interconnected by a communication path.

Figure IB shows an example data packet. Figure 2A shows a protocol stack suitable for use for a direct client-server connection with no intervening performance enhancing proxy.

Figure 2B shows a protocol stack suitable for use when a performance enhancing proxy participates as an intermediary in the client-server connection.

Figure 3 is an example sequence diagram illustrating a client-server transport protocol setup involving a performance enhancing proxy.

Figure 4 is an example sequence diagram illustrating a client-server transport protocol setup when a performance enhancing proxy does not exist or opts out of participating in the connection.

Figure 5 is an example sequence diagram illustrating a client-server transport protocol resumption using a performance enhancing proxy that has been used beforehand.

Figure 6 is an example sequence diagram illustrating a client-server transport protocol resumption when a performance enhancing proxy does not exist or opts out of participating in the connection.

Figure 7 is an example sequence diagram illustrating a client-server transport protocol resumption using a performance enhancing proxy that has not been used beforehand.

Figure 8 shows an example data structure container in the form of a Substrate

Protocol for User Datagrams (SPUD) wire format with a Concise Binary Object Representation (CBOR) map.

Figure 9 shows an example data structure for the CBOR in the client setup message.

Figure 10 is a block diagram showing computer program product units hosted by a client.

Figure 11 is a block diagram showing computer program product units hosted by a performance enhancing proxy. Figure 12 is a block diagram showing computer program product units hosted by a server.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth (such as particular method steps) in order to provide a thorough understanding of the technique presented herein. It will be apparent to one skilled in the art that the present technique may be practiced in other embodiments that depart from these specific details.

Those skilled in the art will appreciate that the services, functions and steps explained herein may be implemented using software functioning in conjunction with a programmed microprocessor, or using an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a field programmable gate array (FPGA) or general purpose computer. It will also be appreciated that while the following embodiments are described in the context of methods and devices, the technique presented herein may also be embodied in a computer program product as well as in a system comprising a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that execute the services, functions and steps disclosed herein.

Certain terms used in the following detailed description of exemplary embodiments are defined as follows:

Term Definition

Client Endpoint of a connection that initiates a connection request

Connection Conversation between two endpoints

Connection ID The identifier for establishing a connection

Endpoint Endpoint of a connection (client or server)

Middlebox Generic term, encompassing proxy, for an entity arranged in a connection for any purpose other than packet forwarding

PEP Proxy designed to improve connection performance

Proxy Intermediary for a client-server connection

Server Endpoint of a connection that receives a connection request

Figure 1A shows a generic platform on which embodiments of the disclosure may be implemented. A client 10 and a server 12 have a proxy 14 arranged between them at a network node. The network node thus acts as a middlebox. The proxy 14 acts as an intermediary in a client-server connection, breaking it up into a client-proxy connection 16 and a proxy-server connection 18. The client 10 and server 12 are examples of con^¬ nection endpoints. The type of proxy 14 of relevance for the present disclosure is a PEP, which, as already described above, is used to improve the performance of a connection between two endpoints. As shown in Figure 1A, the PEP may translate between the client and server, by which is meant that the TP used for the client- proxy connection 16 may differ from the TP used from the proxy-server connection 18, these being labelled as TPi and TP₂ respectively.

Each of the client 10, PEP 14 and server 12 have a processor unit, memory and a transceiver unit as schematically shown in Figure 1A. Namely, the client 10 has a processor unit 11, memory 13 and a transceiver unit 15. The PEP 14 has a processor unit 17, memory 19 and a transceiver unit 21. The server 12 has a processor unit 23, memory 25 and a transceiver unit 27. The respective processor unit 11, 17, 23 may be configured to execute any of the method embodiments described herein under control of a computer program stored in the respective memory 13, 19, 25.

Figure IB shows an example data packet 20 that may be transmitted in the scenario of Figure 1A (e.g., as a connection setup request or a part thereof). The data packet 20 is made up of a header 22 and a payload 24 which ordinarily carries the data to be transmitted, but on occasion, for example during transport protocol connection setup, may be empty. (In some embodiments of the disclosure, as discussed below, the otherwise empty payload portion may be partly filled during setup with embedded setup messages contained as declarative information.) The header 22 is made up of a number of header portions 26_n including a default protocol setup portion 26i - DEF - which carries conventional setup information, a proxy security setup portion 26₂ - PEP - which carries setup information for the PEP 14 and an application-layer security setup portion 263 - APP - which carries setup information for the server 12.

As described in more detail below, the PEP and APP header portions can be in header portions which are designated as declarative information by the protocol, specifically by an extended version of SPUD. The extension may be a new part of the conventional SPUD protocol which is specific to implementation of embodiments of the disclosure, as described in more detail further below. Alternatively, in other embody- ments, some or all of the declarative information parts, namely in this example the proxy security setup portion 26₂ and the application-layer security setup portion 26₃, could be embedded in the payload 24.

Figures 2A and 2B show a protocol stack suitable for implementing embodiments of the disclosure respectively without and with a PEP being involved. When no PEP is involved, as shown in Figure 2A, the stack represents a conventional or legacy case suitable for unencrypted TPs, which is useful in order to avoid unnecessary complexity at the endpoint side when the TP is unencrypted. The layers of the legacy protocol stack of Figure 2A are: Internet Protocol layer, IP; user datagram protocol layer, UDP; extended SPUD layer, SPUD Plus; secure TP layer, Sec(TP); and application layer, APP. The protocol stack which supports encrypted TPs, as shown in Figure 2B, has an additional layer, Sec(Content), for encrypting content, i.e. the data in the payload part of the packets arranged between the TP layer and the APP layer. It is noted that Figure 2A and Figure 2B assume that the communication protocol (e.g., SPUD) used for TP setup is carried over UDP. This is optional. It is noted that the TP and Sec(TP) layers in Figure 2A and Figure 2B could be depicted as a single layer of the protocol stack, i.e. an encrypted TP layer, as is the case with QUIC. The same could be said of the APP and Sec(Content) layers in Figure 2B.

Several example sequence diagrams which show step-by-step how various communications situations are handled are now discussed. These sequence diagrams use the convention of showing the declarative information parts of messages in bold font, i.e. those message parts which would be ignored by nodes running a legacy, conventional version of the transport protocol. In the following description, we refer to these declarative information parts as safe-to-ignore parts. The sequence diagrams and the following supporting description use a number of acronyms, the meaning of which is as follows:

Acronym Description

A Application Layer (when 'A' is used as a subscript)

App Application

AppMsg Application message (e.g., HTTP GET)

CBOR Concise Binary Object Representation

CLHO Client HELLO (TP setup message)

Cred Credential

Credx(info) Encrypted information using Cred_x

CS Client to server

DTLS Datagram TLS IDp Proxy identification information

MSG Message packet

PDU Protocol data unit

PS Proxy to server

REJ Server REJECT (TP setup message)

RTT Round Trip Time

SDU Service Data Unit

SPUD Substrate Protocol for User Datagrams

TCP Transmission Control Protocol

TLS Transport Layer Security

Tokxx Proof of ownership token for entity XX

TP Transport Protocol

UDP User Datagram Protocol

Figure 3 is an example sequence diagram illustrating the execution of an exemplary client-server TP setup process in the case that a PEP 14 is involved for which the client 10 does not possess previously exchanged credentials. In this case, the following messages are exchanged with the logical step numbering in Figure 3 following the paragraph numbering below:

1. The client 10 prepares and sends a TP setup message with or as a connection setup request to the server 12, specifying its credentials CLHO_Tp(Credcs)- The message also includes setup information for the PEP 14 in the safe-to-ignore part,

1. e. CLHO_Tp(Cred_Cp). Additionally, the safe-to-ignore part also contains the application-layer security setup information CLHO_Tp(CLHO_A(Credcs)) from client 10 to server 12. The syntax of an example TP setup message is given further below with reference to Figure 9.

2. The proxy, i.e. the PEP 14, intercepts the message sent by the client 10 and decides whether to attempt to act as a proxy for this session. If it wishes to act as a proxy, the PEP 14 processes the setup messages contained in the declarative information of the safe-to-ignore header portions, while ignoring the conventional setup message in the default protocol setup header portions. The PEP 14 then creates a new TP setup message to be sent to the server 12, including the application-layer security setup information (CLHO_A) sent by the client 10 in the message service SDU. The hello message from the client 10 is terminated during this step. 3. The PEP 14 sends out the TP setup message created in Step 2 to the server 12, i.e. CLHO_Tp(Credp_S; CLHO_A(Cred_cs)).

4. The server 12 processes the setup message from the PEP 14. The server 12 checks the received credentials to determine whether the TP connection setup request was transmitted by a PEP 14 or a client 10. In this case, the server 12 recog^¬ nizes that the transmitter was the PEP 14. The server 12 thus responds to the PEP 14 with a server reject message REJ(Cred_Sp, Tok_SP; REJ(Cred_Sc, Tok_Sc)), since it does not have the security context for the PEP 14. The REJ message includes: the server credentials for the PEP 14, the selected token, and a similar REJ message for the client 10 embedded in the message's SDU. Here it is noted that the server 12 cannot have a conventional protocol stack, but needs the extended version of SPUD or equivalent, since the server 12 needs to know the requirement to embed the credentials and token for the client 10 in its reply to the proxy.

This is all done in response to the application-layer security setup information

(CLHOA) received from the client 10 via the PEP 14.

5. When the message from the server 12 arrives at the PEP 14, the secure TP connection between the PEP 14 and the server 12 - TP_PS - is established. The PEP 14 is able to reply to the original setup message from the client 10, based on the infor^¬ mation received originally from the client 10 and subsequently from the server 12. The PEP 14 prepares a REJ message to the client 10, including: the PEP 14 credentials, the selected token, proxy identification information for the client 10 based on which the client 10 may identify the trusted PEP 14, and the REJ message received by the PEP 14 in the message SDU from the server 12.

6. The client 10 identifies the PEP 14, and if it decides to proceed with establishing a proxy-mediated connection, the client 10 finalizes both the TP_Cp setup pro^¬ cess with the PEP 14 and the application-layer security setup process with the server 12.

7. At this stage the secure TP_CP connection between client 10 and PEP 14 is established and the client 10 may start sending encrypted communication messages to server 12 through this TP_CP connection.

8. On receipt of a TP_CP encoded message from the client 10, the PEP 14 terminates the message, decrypts the PDU received and re-encrypts it using TP_PS ere- dentials. Note that the Application layer PDU is encrypted with the server 12 credentials, thus the PEP 14 does not have access to the application content, i.e. the pay- load data.

9. The PEP 14 sends the TP_PS message created in the previous step to the server 12.

10. The server 12 replies to this message on the TP_SP connection.

11. The server's 12 reply message is terminated by the PEP 14 and re- encrypted.

12. The re-encrypted message from the previous step is sent to the client 10 through the TP_PC connection.

Figure 4 is an example sequence diagram illustrating the execution of a client-server TP setup process in the case that a PEP 14 does not exist or opts out of becoming involved as a proxy.

Step 1 is identical to that in the previous case, but here the PEP 14 does not intercept and terminate the message.

In Step 2, the server 12 checks the credentials of the received TP connection setup request to determine whether it was transmitted by a PEP 14 or a client 10. In this case, the server 12 recognizes that the transmitting entity was a client 10. Still in Step 2, the server 12 creates a reply to the TP connection setup from the client 10 in a conventional manner based on the conventional setup message (CLHO_Tp) in the default protocol setup header portions. Specifically, the server 12 ignores the setup message (CLHO_Tp) intended for the PEP 14 contained in the safe-to-ignore portions of the packet (which may be header portions or payload portions, or a combination of both) and creates a conventional reply REJ(Cred_Sc, Toksc).

Step 3 involves sending this reply. At this stage the connection is now setup and messaging to and fro can proceed conventionally as shown in Steps 4 and 5.

Figure 5 is an example sequence diagram illustrating a client-server TP resumption in the case that a PEP 14 has been used beforehand. 1. The client 10 prepares a TP_Cs message to the server 12. At the same time, the client 10 prepares a message with the same content also to the PEP 14 (bold message). The PEP 14 message also uses application layer encryption for the content and encrypted TP_CP encapsulation. The full content is placed in the safe-to-ignore part of the TPCP message. It is noted that the initial message is in general small, e.g., a "HTTP GET" message, so even with this expansion of the message into PEP and server parts, the message should still fit into a single IP packet. Both message parts are prepared by making use of stored credentials when encrypting the different parts of a message. The different message parts also contain two different tokens - Tok_PC and Toksc - that the two different receiving entities - PEP 14 and server 12 - may use as respective proof of ownership.

2. The PEP 14 intercepts the message sent by the client 10 and, if it decides to act as a proxy, the PEP 14 ignores the TP_Cs message and terminates the TP_CP connection based on the information in the safe-to-ignore part of the client 10 message. The PEP 14 then encapsulates in an encrypted TP connection the already end- to-end encrypted application data using TP_PS credentials according to the protocol stack of Figure 2B.

3. The PEP 14 sends the TP_PS message created in the previous step to the server 12. The PEP 14 also uses an existing token received during previous communication from the server 12 as proof of ownership.

4. The server 12 replies to this message on the TP_SP connection.

5. The TPSP connection is terminated by the PEP 14 and the message is re- encrypted into TP_PC.

6. The message is then sent to the client 10 through the TP_PC connection.

The above method assumes there are pre-stored credentials in the endpoints, i.e. at the client 10, at the server 12, and at the network node 14 hosting the proxy, based on which the proof of ownership and message encryption and decryption can take place.

There is also an alternative solution that can enable a new PEP 14 instance to replace a previous PEP 14 instance in the communication. For this, the PEP 14 could send an additional message to the client 10 (at any point from Step 7 of the connection es- tablishment in Figure 4) containing the credentials needed for this communication (Credps), which is encrypted with the credentials only known by the PEP 14. At the resumption stage, i.e., in Step 1 above (Figure 5), the client 10 would send this information back to the PEP 14. Thus, only a PEP 14 capable of decrypting this message will be able to access the credentials needed to be involved in the client-server communication.

Fig. 6 is an example sequence diagram illustrating a client-server TP resumption when a PEP 14 does not exist or opts out of participating in the connection.

Step 1 is identical with that in the previous case, but here the PEP 14 does not intercept the message as in Step 2 above, and therefore the server 12 (disregarding the declarative information, i.e. the embedded safe-to-ignore parts) will reply to the message and resume the TP from the client 10 in a conventional manner.

Fig. 7 is an example sequence diagram illustrating a client-server TP resumption using a PEP 14 that has not been used beforehand. This situation may arise after an access change, for example. One reason for the new PEP 14 to elect to participate would be in order to optimize the traffic on the new access.

In Step 1, the client 10 sends a hello message to the PEP 14 in the safe-to-ignore part of the message to the server 12. This enables the PEP 14 to set up a TP to the client 10 (Steps 2-5), and then forward the client 10 message as a new PEP 14 hello message to the server 12 (Steps 6-7). In Step 8, the server 12 accepts the token Toksc in the application layer as proof of IP ownership for TP setup to PEP 14. In Step 9, the server 12 replies to the PEP's hello message on the TP_Sp connection. In Step 10, the server's 12 reply message is terminated by the PEP 14 and re-encrypted for the client 10. In Step 11, the re-encrypted message from the previous step is sent to the client 10 through the TP_PC connection. This setup thus involves one additional RTT delay between the client 10 and the PEP 14.

It is noted that, as an alternative to the process shown in Figure 7, this situation could be dealt with essentially following the procedure of Figure 3, but bearing in mind that in the resumption situation considered here the client 10 and server 12 already have exchanged credentials, i.e. tokens and application messages, so that part of the process of Figure 3 need not be repeated. Following this modified process of Figure 3 for resumption with a new PEP 10 would cause an additional 1-RTT delay compared with the process if Figure 7, so is less preferred. This completes the detailed description of how the various communications situations are handled.

It is now described in the following how embodiments of the disclosure may be implemented based on a substrate middlebox communication protocol, such as SPUD. In other words, the communicating entities client 10, server 12 and PEP 14, are assumed to support SPUD or another suitable substrate middlebox communication protocol.

SPUD is used in the main example, because SPUD is intended to be a communication layer arranged below UDP-based TPs, which makes SPUD suitable for implementing embodiments of the disclosure. It is however noted that alternative communication protocols based one on a legacy transport protocol in another protocol layer of the protocol stack would also be possible, provided that the legacy protocol can support sufficiently long safe-to-ignore data portions in its setup messages.

SPUD is an example for a protocol suitable for extending to use declarative information to embed PEP support information as is needed to implement embodiments of the disclosure. One option is to include SPUD as a new layer below evolved transport protocols. It is noted that most servers 12 have SPUD available, as well as one or more commonly used transport protocols.

SPUD is proposed in IETF, i.e. the Internet Engineering Task Force, for a somewhat different purpose to that which is contemplated here. Namely, SPUD was proposed as an extensible in-band channel below UDP that allows endpoints to send traffic meta-data to the middleboxes on the communication path. SPUD also provides a mechanism for the middleboxes to signal back to the same endpoint using the same in-band channel. The prior art discussion around SPUD has identified a number of constraints on the information exposed between the end-points and the middleboxes. In the current case, where we use SPUD for communication between endpoints, these constraints are not directly relevant. Nevertheless, these constraints are listed for the sake of completeness:

• SPUD is based on declarations only, thus no negotiation is needed between the parties, which reduces the communication latency. There is also no assumption on what action (if any) will follow a given declaration. • In SPUD, endpoints and middleboxes may trust, but can verify the information received on the basis that the best way to prevent cheating is to remove incentives to do so.

• SPUD need not be supported by all nodes on a communication path before a benefit is seen. All parties must ignore (and not delete) what they do not understand. The sender must also assume it may not be understood. This facilitates incremental deployment and there is no requirement for a mandatory minimum vocabulary.

A further discussion of this topic is to be found in Hildebrand and Trammell 2015 https://www.ietf.org/proceedings/92/slides/slides-92-spud-l.pdf "Substrate Protocol for User Datagrams (SPUD) Prototype draft-hildebrand-spud-prototype-03" Hildebrand and Trammell 9 March 2015.

Figure 8 shows an example structure of a SPUD packet, namely an example data structure container in the form of a SPUD wire format with a CBOR map as specified in the current SPUD prototype. The so-called "magic" number is a constant used to avoid collision with valid packet content at the same offsets for a variety of known UDP-based protocols. The "tube ID" identifies the UDP packets grouped together from the sender. The packet also contains two one-bit markings showing whether this packet is an application declaration (adec) or a path (i.e., middlebox) declaration (pdec). The last part of the SPUD packet contains a "CBOR map".

CBOR maps as usable in the context of the present disclosure are described in Bor- mann and Hoffman 2013 https://tools.ietf.org/html/rfc7049 "Concise Binary Object Representation (CBOR)" October 2013.

The CBOR map consists of key-value pairs of the form:

{[key 1] : [value 1] , ... ,[key n] : [value n]}

The key "0" is reserved for application data, i.e. the data of the transport protocol follows the key "0".

Figure 9 shows an example data structure for the CBOR in the client 10 setup message, assuming usage of the extended SPUD protocol. The 5-tuple and the SPUD tube identifier together identify the connection attempt (see SPUD header in Figure 8). The legacy TP-related setup in the example is identified by the "0" key. The safe- to-ignore information destined for the PEP 14, in the case that the PEP 14 wants to participate, is indexed by key "1" containing both PEP 14 TP setup information and application-layer security setup information. The "procedure ID" is a constant hexadecimal value that identifies that an embodiment of the disclosure with the extended SPUD is being used. There is also a "version" value in this example, which can identify the current setup procedure implementation in the client 10. Finally, the client 10 may optionally give additional information about the nature of the data stream and the network that is going to be communicated on this connection, and which might be relevant for helping the PEP 14 to select the most appropriate transport protocol, e.g., "app", "jitter" and "network type". Any information which is known not to be relevant for helping the PEP 14 decide upon the most appropriate TP should preferably be communicated using higher layers in the protocol stack.

It is noted that the additional key-value pairs present in the setup message represent little overhead. In the case of fast (e.g. 1-RTT) TP setup, it is generally advisable that the sender pads the packet to fill it to its maximum specified size, i.e. filling to the maximum transmission unit (MTU). This padding is done to ensure that a full-packet- response can be sent by the server 12, and that it will typically be no larger than the client's 10 first packet. This full-packet will also raise the bandwidth cost for any attacker, i.e. a party who is supplying a false return address, thereby diminishing the potential for any reflected amplification. Thus, in many cases, there is no overhead associated with employing an embodiment of the disclosure. If there are numerous possible TPs to select from, not all setup messages might fit into the same setup packet. In this case it is advisable only to include the most common and most preferred TPs, while only including references to other TP options. In this case, a TP that is not included in the setup message can still be chosen via the reference, but its setup will require an additional RTT delay.

Figure 10 is a block diagram showing computer program product units hosted by a client 10, which, when executed by a processor also hosted by the client 10, initiate a packet-based transport protocol connection between a client 10 and a server 12.

A first information generation unit 102 generates default protocol setup information for a server 12. A second information generation unit 104 generates proxy security setup information for a PEP 14 and application-layer security setup information for a server 12. A packet generation unit 106 generates a packet having a first part and a second part, wherein the default protocol setup information is placed in the first part and the proxy security setup information as well as the application-layer security setup information are placed in the second part. A transmitter unit 108 sends the packet as a connection setup request. The packet generation unit 106 may be further operable to add to the new setup request packet one or more of the following: a token indicating proof of ownership of an internet protocol address; an indication of the transport protocol being used to send the new setup request packet; a version number for said transport protocol; an application using the connection; and network type, i.e. how the terminal attaches to the other network nodes, e.g. cellular, WiFi etc.

It will be understood that the functions of these client computer program product units will be subsumed in the client processor 11, client memory 13 and client transceiver unit 15 shown in Figure 1A and may be configured to operate as discussed above in connection with Figs. 3 to 7.

Figure 11 is a block diagram showing computer program product units hosted by a PEP 14, which, when executed by a processor also hosted by the PEP 14, mediate a packet-based transport protocol connection between a client 10 and a server 12 at the network node hosting the PEP 14.

An interception unit 111 intercepts a connection setup request packet from a client 10 at the PEP 14, wherein the packet includes: (i) default protocol setup information for a server 12 which is in a first part of the packet; and (ii) proxy security setup information for a PEP 14 and application-layer security setup information for a server 12 which are in a second part of the packet. A termination unit 113 terminates the connection towards the client 10. An extraction unit 115 extracts the embedded proxy security setup information. A packet generation unit 117 generates a new setup request packet for the server 12 by extracting the application-layer security setup information to the server 12. A transmitter unit sends the new setup request packet to the server 12. The packet generation unit 117 may additionally include one or more of the following in the packet: a token indicating proof of ownership of an internet protocol address; an indication of the transport protocol being used to send the new setup request packet; a version number for said transport protocol; and an application type. It will be understood that the functions of these PEP computer program product units will be subsumed in the PEP processor 17, PEP memory 19 and PEP transceiver unit 21 shown in Figure 1A and may be configured to operate as discussed above in connection with Figs. 3 to 7.

Figure 12 is a block diagram showing computer program product units hosted by a server 12, which, when executed by a processor also hosted by the server 12, estab- lish a packet-based transport protocol connection to a client 10 mediated by a PEP 14.

A receiver unit 122 receives a connection setup request packet including application- layer security setup information for the server 12 and transmitter credentials. A credential checking unit 124 checks the transmitter credentials to determine whether the connection setup request packet was transmitted by a PEP 14 or a client 10. In the case that the connection setup request packet was transmitted by a client 10, a client transmitter unit 126 sends a setup request to the client 10 containing the server 12 credentials for the client 10 and a token for client-server communication. In the case that the connection setup request packet was transmitted by a PEP 14, a PEP transmitter unit 128 sends a first setup request to the PEP 14 containing the server 12 credentials for the PEP 14 and a first token for server-proxy communication, and also, placed in the first setup request, a second setup request for the client 10 containing the server 12 credentials for the client 10 and a second token for client-server communication. The PEP 14 is thereby able to extract the second setup request for the client 10 and send it on to the client 10 using a protocol selected by the PEP 14.

It will be understood that the functions of the server computer program product units will be subsumed in the server processor 23, server memory 25 and server transceiver unit 27 shown in Figure 1A and may be configured to operate as discussed above in connection with Figs. 3 to 7.

Having now described how to implement embodiments of the disclosure in some detail the following additional observations are made.

Embodiments can provide comparatively fast setup for connections, both with and without a PEP 14 acting as a proxy, and with or without a previous client-server connection or client-proxy-server connection. A trusted PEP 14 can participate in the end-to-end path without additional delay in the TP setup times (i.e. 0-1 RTT).

A solution adopting explicit PEPs 10 rather than transparent PEPs 10 has been adopted to allow full encryption of the TP layer, but the explicit PEPs 10 can be dynamically involved, similar to transparent PEPs 10, provided there is client 10 and server 12 consent.

The TPs which the PEP 14 terminates can be encrypted in which case a separate content encryption is involved, which adds a layer to the protocol stack as shown in Figure 2B compared to Figure 2A, which shows the situation when a PEP 14 is not participating. Namely, the protocol stack reverts to the legacy case, which avoids unnecessary complexity at the endpoints.

The above embodiments describe implementations in which the connection setup request is in a single packet. It will be understood that the connection setup request may be spread between multiple packets if desired.

In the above embodiments, the PEP 14 may be operable to establish said new connection to the server 12 using either the same, or a different, transport protocol from the one in which the connection setup packet was sent from the client 10. In other words, the PEP 14 may perform a translation function. When the same transport protocol is used, the PEP may configured the transport protocol differently for PEP- to-client and PEP-to-server communication, wherein the different configurations are set according to properties of the connection, such as bit error rates or other line characteristics.

Good security is provided, since only a trusted PEP 14 may participate and both TPs (i.e. TPCP and TP_PS) can be encrypted. There is also the option of only having TP encryption for one or the other of the client-proxy and proxy-server connections. For example, encryption may be dropped from one side, if the PEP 14 and one of the endpoints are in the same trusted domain. With the embodiments of the disclosure described in detail above, security is inherently between two parties, which is simpler than a 3-way security model. Moreover, although the PEP 14 is trusted, end-to-end privacy is still retained, since the PEP 14 has no access to the end-to-end user data, which is encrypted with a different key.

Embodiments of the disclosure can provide support for proprietary TPs between the PEP 14 and either endpoint.

If a legacy server 12 is one of the endpoints and cannot form a trusted relation with the PEP 14, a client-server connection can still be established provided that the server 12 supports application-layer security.

Embodiments of the disclosure can provide a low overhead solution, since in general no additional setup packets are needed. A conventional setup already requires one round trip, and conventionally in this round trip the packet is padded to MTU for security reasons. Implementation of embodiments of the disclosure can in many - -

cases simply take up some of the space which was previously only used for padding to embed the relevant PEP 14 setup information in a safe-to-ignore part of the packet.

In summary of the above, an extended TP is provided for establishing a connection between two endpoints, namely a client 10 and a server 12. The extended TP supports the presence or absence of a PEP 14 situated at a network node. When a PEP 14 wishes to participate in the connection, it intercepts a TP setup request from a client 10, terminates the connection to the client 10 and initiates a new connection to the server 12. The TP is extended such that, in the TP setup request, there are placed in a safe-to-ignore part of the request, proxy security setup information for the PEP 14 and application-layer security setup information for the server 12. With this approach, either or both of the TPs between client 10 and proxy and between proxy and server 12 can be encrypted. The TP setup request sent by the client 10 also includes default protocol setup information for a server 12 in case the TP setup request is received directly by the server 12 without PEP 14 intervention. This allows the client-server connection to be established conventionally if needed.

It is believed that the advantages of the technique presented herein will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, constructions and arrangement of the exemplary aspects thereof without departing from the scope of the disclosure or without sacrificing all of its advantageous effects. Because the technique presented herein can be varied in many ways, it will be recognized that the disclosure should be limited only by the scope of the claims that follow.

Claims

1. A method by which a client initiates a packet-based transport protocol connection between a client (10) and a server (12), comprising:

(a) generating default protocol setup information for a server;

(b) generating proxy security setup information for a performance enhancing

proxy (14) and application-layer security setup information for a server;

(d) sending the connection setup request.

2. The method of claim 1, wherein the second part of the connection setup request is designated as declarative information.

3. The method of claim 1 or 2, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

4. The method of any preceding claim, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

5. The method of any preceding claim, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

6. A method of mediating a packet-based transport protocol connection between a client (10) and a server (12) at a network node hosting a performance enhancing proxy (14), the method comprising:

(b) terminating the connection towards the client; (c) extracting the proxy security setup information;

(e) sending the new setup request to the server.

7. The method of claim 6, wherein the second part of the connection setup request is designated as declarative information.

8. The method of claim 6 or 7, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

9. The method of any of claims 6 to 8, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

10. The method of any of claims 6 to 9, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

11. A method by which a server (12) establishes a packet-based transport protocol connection to a client (10) mediated by a performance enhancing proxy (14), the method comprising:

(b) checking the transmitter credentials to determine whether the connection

setup request was transmitted by a performance enhancing proxy or a client; and

(c) if the connection setup request is determined to have been transmitted by a performance enhancing proxy, sending a first setup request to the performance enhancing proxy containing the server credentials for the performance enhancing proxy and a first token for server-proxy communication, and also, placed in the first setup request, a second setup request for the client containing the server credentials for the client and a second token for client-server communication.

12. The method of claim 11, wherein, if the connection setup request is determined to have been transmitted by a client, the server sends a setup request to the client containing the server credentials for the client and a token for client-server communication.

13. The method of claim 11 or 12, wherein the second part of the connection setup request is designated as declarative information.

14. The method of any one of claims 11 to 13, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

15. The method of any one of claims 11 to 14, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

16. The method of any one of claims 11 to 15, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

17. A method for establishing a packet-based transport protocol connection between a client (10) and a server (12), wherein a connection setup request issued by a client includes:

(b) proxy security setup information for a performance enhancing proxy (14) and application-layer security setup information for a server which are in a second part of the connection setup request, and

wherein,

18. The method of claim 17, wherein the second part of the connection setup request is designated as declarative information.

19. The method of claim 17 or 18, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

20. The method of any one of claims 17 to 19, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

21. The method of any one of claims 17 to 20, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

22. A computer program product bearing machine readable instructions executable to implement a packet-based transport protocol according to the method of any one of claims 1 to 21.

23. The computer program product of claim 22, stored on a computer readable recording medium.

24. A client (10) capable of initiating a packet-based transport protocol connection to a server (12), wherein the client is operable:

(a) to generate default protocol setup information for a server;

(b) to generate proxy security setup information for a performance enhancing proxy (14) and application-layer security setup information for a server;

(c) to generate a connection setup request having a first part and a second part, wherein the default protocol setup information is placed in the first part and the proxy security setup information as well as the application-layer security setup information are placed in the second part; and

(d) to send the connection setup request.

25. The client of claim 24, wherein the second part of the connection setup request is designated as declarative information.

26. The client of claim 24 or 25, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

27. The client of any one of claims 24 to 26, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

28. The client of any one of claims 24 to 27, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

29. A network node hosting a performance enhancing proxy (14) capable of mediating a packet-based transport protocol connection between a client (10) and a server (12), wherein the performance enhancing proxy is operable:

(b) to terminate the connection towards the client;

(c) to extract the proxy security setup information;

(e) to send the new setup request to the server.

30. The network node of claim 29, wherein the performance enhancing proxy is further operable to add to the new setup request one or more of the following: a token indicating proof of ownership of an internet protocol address; an indication of the transport protocol being used to send the new setup request; a version number for said transport protocol; and an application type.

31. The network node of claim 29 or 30, wherein the second part of the connection setup request is designated as declarative information.

32. The network node of any one of claims 29 to 31, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

33. The network node of any one of claims 29 to 32, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

34. The network node of any one of claims 29 to 33, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

35. A server (12) capable of establishing a packet-based transport protocol connection to a client (10) mediated by a performance enhancing proxy (14), the server being operable:

(c) if the connection setup request is determined to have been transmitted by a performance enhancing proxy, to send a first setup request to the performance enhancing proxy containing the server credentials for the performance enhancing proxy and a first token for server-proxy communication, and also, in the first setup request, a second setup request for the client containing the server credentials for the client and a second token for client-server communication.

36. The server of claim 35, which is further operable, if the connection setup request is determined to have been transmitted by a client, to send a setup request to the client containing the server credentials for the client and a token for client-server communication.

37. The server of claim 35 or 36, wherein the second part of the connection setup request is designated as declarative information.

38. The server of any one of claims 35 to 37, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

39. The server of any one of claims 35 to 38, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

40. The server of any one of claims 35 to 39, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.

41. A system comprising a client (10), a server (12) and a performance enhancing proxy (14), the system being operable to establish a packet-based transport protocol connection between the client and the server, wherein a connection setup request issued by a client includes:

wherein,

42. The system of claim 41, wherein the second part of the connection setup request is designated as declarative information.

43. The system of claim 41 or 42, wherein the second part of the connection setup request is in a protocol layer below that of the transport protocol being used to transmit the connection setup request.

44. The system of any one of claims 41 to 43, wherein the second part of the connection setup request is in a Concise Binary Object Representation - CBOR - map of a Substrate Protocol for User Datagrams - SPUD - message.

45. The system of any one of claims 41 to 44, wherein the second part of the connection setup request is in an extension header of the transport protocol being used to transmit the connection setup request.