Document: draft-wang-tls-service-affinity-00.txt I'm a little confused about the requirements driving this design.
At a high level, it seems to me that you have the following set of events: 1. The client connects to the server using TLS via an anycast address A1. 2. The server tells the client that it can/should be reached at a new non-anycast address A2. 3. The client reconnects to the server at A2. I would make several points. First, the mechanism you propose seems heavyweight for this purpose. In particular, I don't understand why you need any authentication at all for the new address indication (the MigrationToken) because the client is going to authenticate to the server via normal TLS mechanisms. Recall that TLS is designed for a Dolev-Yao style attacker and doesn't trust the network at all, including the binding of DNS name to IP address; even if the client were provided with a completely false IP address for the server this would not allow impersonation of the server. Second, I don't understand why you need the server to validate the MigrationToken. What properties are being bound to this token? It seems better to just bind whatever properties those are into the session ticket and treat this as a new connection. Third, I'm skeptical that the TLS layer is the right place to do this kind of migration, because you have race conditions where one side initiates a migration and the other side has outstanding data which will never be processed. These kinds of issues need to be resolved at the application layer, which is also a more convenient layer to initiate migration. Overall, ISTM that a better design would be to just use something like HTTP Alt-Svc to steer the client to a different address, rather than doing this at the TLS layer. If you disagree, I think it would be helpful to explain the requirements that lead to this design. -Ekr On Tue, Oct 21, 2025 at 2:10 AM Aijun Wang <[email protected]> wrote: > Hi, All: > > We have submitted one new draft regarding to the service affinity function > for TLS based application. > We are also applying the time slot for the presentation on the coming IETF > 124 meeting. > > Wish to get your comments/suggestions on this topic before the meeting, > and we can also discuss further during the on-site meeting. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Friday, October 17, 2025 4:34 PM > To: Aijun Wang <[email protected]>; Ketul Sheth < > [email protected]>; Mohit Sahni <[email protected]>; > Wei Wang <[email protected]> > Subject: New Version Notification for > draft-wang-tls-service-affinity-00.txt > > A new version of Internet-Draft draft-wang-tls-service-affinity-00.txt has > been successfully submitted by Wei Wang and posted to the IETF repository. > > Name: draft-wang-tls-service-affinity > Revision: 00 > Title: Service Affinity Solution based on Transport Layer Security (TLS) > Date: 2025-10-17 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/archive/id/draft-wang-tls-service-affinity-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/ > HTMLized: > https://datatracker.ietf.org/doc/html/draft-wang-tls-service-affinity > > > Abstract: > > This draft proposes a service affinity solution between client and > server based on Transport Layer Security (TLS). An extension to > Transport Layer Security (TLS) 1.3 to enable session migration. This > mechanism is designed for modern network architectures, particularly > for multi-homed servers that possess multiple network interfaces and > IP addresses. > > Comparing to the existing solutions such as maintaining the customer- > based connection status table in network devices, HTTP redirection > and DNS redirection, this solution can avoid the waste of resources > caused by saving a large amount of customer status data in the > network devices, and realize the optimized scheduling of resources > based on network conditions and computing resources in the computing- > aware traffic steering scenario, so as to realize the reasonable > operation of network resources, cloud resources and computing > resources. > > > > The IETF Secretariat > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
