TLS Session Resumption in Service Function Chains
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The transition from TLS 1.2 to TLS 1.3 encrypts all handshake messages, making it difficult for Service Function Forwarders to identify the originating server for TLS session resumption, leading to inefficient session resumption and increased computational resources due to forced new handshakes.
Innovation Solution
The proposed solution involves transmitting a Pre-Shared Key (PSK) identifier and ticket lifetime from the Service Function node to the Service Function Forwarder, allowing it to store associations and correctly forward resume requests without triggering a new TLS handshake, enabling session resumption at the original or new nodes without full handshakes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If TLS 1.3 encrypts all handshake messages to enhance security, then security is improved, but the ability to identify the originating server for session resumption deteriorates
Solution Approach 1:
The patent segments the TLS handshake information into two parts: encrypted handshake messages (for security) and unencrypted metadata including PSK identifiers and ticket lifetimes (for session resumption). This allows the Service Function Forwarder to identify and forward session resumption requests without decrypting the encrypted handshake messages, thus maintaining both security and session resumption capability.
Solution Approach 2:
The patent introduces an intermediary mechanism where the Service Function node transmits PSK identifiers and ticket lifetimes to the Service Function Forwarder. This intermediary information acts as a key that enables the forwarder to identify the originating server and correctly forward session resumption requests, bridging the gap between encrypted communication and session management.
2Adaptability or versatility
If a Service Function Forwarder performs load balancing to forward endpoint client communications, then adaptability is improved, but the ability to correctly identify the originating Service Function node deteriorates
Solution Approach 1:
The patent applies preliminary action by having the Service Function node transmit PSK identifiers and ticket lifetimes to the Service Function Forwarder before session resumption occurs. This advance preparation enables the forwarder to maintain a mapping between PSK identifiers and Service Function nodes, allowing it to correctly identify and forward session resumption requests even when performing load balancing across multiple nodes.
3Reliability
If a full TLS handshake is performed for every connection to ensure security, then security is improved, but productivity deteriorates due to increased latency and computational overhead
Solution Approach 1:
The patent uses copying by having the endpoint client retain a copy of the PSK identifier and ticket lifetime from the initial TLS handshake. This copied information is then reused during session resumption, allowing the client to quickly re-establish the TLS session without performing a full handshake, thus improving productivity while maintaining security through the use of previously established cryptographic material.
Data Source
AI summary
A method for resuming a Transport Layer Security (TLS) session in a Service Function Chain comprising a plurality of Service Function nodes coupled to a Service Function Forwarder. A request is received at a first Service Function node to establish a TLS session, and a Pre-Shared Key (PSK) and a PSK identifier that uniquely correspond to the first Service Function node and the TLS session are generated. The PSK identifier is forwarded to one or more of the Service Function Forwarder and the plurality of Service Function nodes. A request to resume the TLS session is received from a client device that previously disconnected. It is determined that the connection request contains the PSK identifier, a second Service Function node is selected, and the TLS session is re-established between the client device and the second Service Function node using the same PSK as the prior TLS session.