On Mon, Oct 27, 2025 at 6:10 PM Aijun Wang <[email protected]> wrote: > > 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.
I'm pretty confused by this. Session affinity is a very application specific idea. Even for HTTP there's a lot of configuration required to inform the CDN/HTTP balancing layer about what the application uses for a session. We can however ensure all packets from a TLS connection land on the same box via standard techniques (Maglev, Unimog, etc. are the systems I remember off the top of my head). Very few applications that I can think of need affinity across TLS connections. Sincerely, Watson > > > > 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]> 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]> > 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= > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
