Hi, Erik:
Let’s try to answer your main concern: “Can you expand on this in more detail? Why can't the network inform the application of what to do, just as it does the TLS stack (they are often co-located in any case)?” >From Figure 1 of >https://datatracker.ietf.org/doc/draft-wang-tls-service-affinity/, we can see >that: 1) When customer A send the request packet to R1, based on the service’s anycast address, it is network, that is R1 itself, select the best service node within the network (based on the network real time conditions, and the availability information of the service node). 2) When the request packet reaches the optimal service node, we expect the service node notify the client as quickly as possible to switch to its unique address. 3) If the service node doesn’t do the switch work, the following packets from the same session of this customer may be switched to another service node, when the network topology changed. 4) we call the above procedure as “service affinity”, that is to say, when the first packet of the session reaches to one service node, we will try to keep the following packets of the session to the same service node. For your suggestions, if the network inform the application of what to do, it still need one new TLS connection. And if the TLS layer can accomplish such task, why we bother the application layer? And, additionally, as Mohit said, if we design the switchover at the application layer, we need such mechanism at every kind of application that based on TLS. That’s the reason we select to accomplish such task on the TLS layer, make the mechanism application-agnostic. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Eric Rescorla Sent: Monday, October 27, 2025 11:03 AM To: Aijun Wang <[email protected]> Cc: [email protected]; [email protected]; Aijun Wang <[email protected]> Subject: [TLS] Re: FW: New Version Notification for draft-wang-tls-service-affinity-00.txt On Sun, Oct 26, 2025 at 7:54 PM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Eric: Thanks for your comments. Your understanding of the overall procedure for this proposal is correct. But, as indicated by Usama and replied by Mohit, the detail procedures in Figure 2 of this document should be based on TLS 1.3 https://datatracker.ietf.org/doc/html/rfc8446#section-2 If there is any misunderstanding due to the above ignorance, let's discuss further based on our future update based on TLS 1.3 No I'm not confused by that. 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. 【WAJ】The "Migration_Token" is manly used to bind the new connection to the previous session. As I said, you don't need to do that. You can bind all the information you need to the PSK. 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. 【WAJ】The main properties in "Migration_Token" is the session_id, which can be used to lookup the previous negotiated PSK. Such design can eradicate the new PSK negotiation procedure. See above. You can put this information in the PSK label 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. 【WAJ】The initial purpose is to switch the address ASAP. There may be some race conditions(would you like to illustrate some?) I gave an example above. To expand on this a bit: Client sends an application protocol message that induces some change on the server Server sends a migration alert. How does the client know whether its message was processed? TLS has no way of telling you, though the application layer might have an ACK. 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. 【WAJ】Before proposing the switchover at TLS layer, we have analyzed the other possible solutions, for example, via application load balance, http redirection and DNS redirection(please review https://datatracker.ietf.org/doc/html/draft-wang-tls-service-affinity-00#name-introduction). The reason that we propose the switchover at TLS layer, due to the optimization selection decision is made at the network itself(together with the availability of server resource), not at the application layer. The application is difficult to know which is the best server that can match the client's QoS requirements.(we call it the combination optimization process, which is the goal of the CATS WG). Can you expand on this in more detail? Why can't the network inform the application of what to do, just as it does the TLS stack (they are often co-located in any case)? And, actually, QUIC has also such migration process: https://datatracker.ietf.org/doc/html/rfc9000#name-connection-migration Yes, I'm familiar with the QUIC mechanism, but unlike the mechanism you propose, the QUIC abstraction looks like a single connection and so issues like the one I raised above do not occur, as QUIC naturally ensures reliable transmission of application layer messages between the endpoints even during a migration. By contrast, the design you propose is just two TLS connections, which don't have this kind of continuity.e -Ekr -Ekr On Tue, Oct 21, 2025 at 2:10 AM Aijun Wang <[email protected] <mailto:[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]> > [mailto:[email protected] <mailto:[email protected]> ] > Sent: Friday, October 17, 2025 4:34 PM > To: Aijun Wang <[email protected] <mailto:[email protected]> >; > Ketul Sheth < > [email protected] <mailto:[email protected]> >; Mohit > Sahni > <[email protected] <mailto:[email protected]> >; Wei Wang > <[email protected] <mailto:[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=
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
