Return-Path: X-Original-To: tls@mail2.ietf.org Delivered-To: tls@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A0601A0B8AAA; Tue, 30 Dec 2025 02:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7cNkHDBceko; Tue, 30 Dec 2025 02:10:58 -0800 (PST) Received: from mail-m155101.qiye.163.com (mail-m155101.qiye.163.com [101.71.155.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BC66BA0B8AA2; Tue, 30 Dec 2025 02:10:56 -0800 (PST) Received: from LAPTOP09T7970K (unknown [219.142.69.75]) by smtp.qiye.163.com (Hmail) with ESMTP id 2f0609acf; Tue, 30 Dec 2025 18:10:47 +0800 (GMT+08:00) From: "Aijun Wang" To: "'Eric Rescorla'" References: <000001dc7615$cf415b70$6dc41250$@tsinghua.org.cn> In-Reply-To: Date: Tue, 30 Dec 2025 18:10:53 +0800 Message-ID: <004e01dc7974$957ebab0$c07c3010$@tsinghua.org.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01DC79B7.A3A46BB0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI7N+UrCa4wrDE8olUN5ROrNp4g5AJ9CNDCtGiIcHA= Content-Language: zh-cn X-HM-Tid: 0a9b6ebd221303a2kunm0b31ae351724a0 X-HM-MType: 10 X-HM-Spam-Status: e1kfGhgUHx5ZQUpXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkZHkoZVh5DHUMdSx4fThkaQlYeHw5VEwETFh oSFyQUDg9ZV1kYEgtZQVlJSkJVSk9JVU1CVUxOWVdZFhoPEhUdFFlBWU9LSFVKS0lPT09IVUpLS1 VKQktLWQY+ Message-ID-Hash: 7IT7R4ZJFON2AAJLOA3ZF57E4SRSAMCL X-Message-ID-Hash: 7IT7R4ZJFON2AAJLOA3ZF57E4SRSAMCL X-MailFrom: wangaijun@tsinghua.org.cn X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tls@ietf.org, draft-wang-tls-service-affinity@ietf.org, 'Mohit Sahni' , 'Aijun Wang' X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_=E3=80=90Reply_to_the_comments_after_the_presentat?= =?utf-8?q?ion_in_Montreal=E3=80=91RE=3A_Re=3A_FW=3A_New_Version_Notificatio?= =?utf-8?q?n_for_draft-wang-tls-service-affinity-00=2Etxt?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_004F_01DC79B7.A3A46BB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Eric: =20 Contrary to your conclusions, I think the application layer and TLS/TCP = layer should(already) have their own mechanisms to assure the data = integrity, there is no necessary to consider them again at the protocol = layer, we need just some guidance for the implementation of = client/server sides themselves. If there is data arrival during the switchover, the internal = implementation logic is the application layer will call the api of = TLS/TCP to send some data, with the same session identifier. =20 When these data reach to the TLS/TCP stack, and the connection between = client/server sides are not established, the client can cache these data = for a short time. And, if the connection time exceeds some threshold, there will(should) = be some indications to the application layer, which will should be = similar with the results when the server can=E2=80=99t be reachable with = other unknown reason. =20 When the application receives such signal from the undelay TLS/TCP = layer, it should notify the user to retry to send the data = again(=E2=80=9Cclick the button again=E2=80=9D) =20 If the switchover occurs within the threshold, the application layer = will not even notify the change. Some detail reply can see below inline[WAJ], based on your example. =20 Happy New Year to you! J =20 Best Regards =20 Aijun Wang China Telecom =20 From: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] = On Behalf Of Eric Rescorla Sent: Saturday, December 27, 2025 7:57 AM To: Aijun Wang Cc: tls@ietf.org; draft-wang-tls-service-affinity@ietf.org; Mohit Sahni = ; Aijun Wang Subject: [TLS] Re: =E3=80=90Reply to the comments after the presentation = in Montreal=E3=80=91RE: Re: FW: New Version Notification for = draft-wang-tls-service-affinity-00.txt =20 =20 =20 On Thu, Dec 25, 2025 at 7:14=E2=80=AFPM Aijun Wang = > wrote: Hi, Eric and Martin: =20 During my presentation in IETF 124 meeting for this service affinity = proposal, you raised the following questions that can be summarized as = the followings: 1) How to assure there is no application data loss during the switch = take place? 2) How to keep the application unware about the switchover, because = the TCP connection switchover? =20 Regarding to the question 1), after discussing with some experts = offline, we think: 1.1) TLS is based on TCP, and the TCP layer can assure the application = data be transferred successfully to the peer, based on the TCP ACK = mechanism.=20 1.2) The client can decide when to switchover, based on the = peer=E2=80=99s TCP ACK. 1.3) If some application data comes to the client during the switchover, = the client can store them temporarily. This is local implementation = consideration, needs not the extension of the protocol. =20 I'm not sure that this is quite correct about the concerns MT and I were raising, so let me try to clarify. Consider a simple HTTP REST API. Client Server POST /make-payment -----------------------------------------> [Process payment] <------------------------------------------------------ 200 OK When the client receives a 200 OK, it knows that the request has been processed. If it doesn't, it has to assume it has not. For instance, consider the following case: Client Server POST /make-payment -----------------------------------------> [Process payment] [Server crashes] [TCP retransmit] --------------------------------------------> <--------------------------------------------------------- RST In this case, the client doesn't know what has happened. You need mechanisms either at the HTTP layer--or more typically at the REST API layer--to do the right thing, which might be an idempotency layer combined with client-side retransmit. This is all just a straightforward application of the end-to-end argument, and there's no real way around it as long as systems might asynchronously fail, but it's also a source of defects (think about how many times sites tell you not to press the submit button twice) because these mechanisms may not have been exercised or tested. For instance, if the server is high reliability and the client just assumes that anything it sent works, that will be good enough a very large fraction of the time, but not if the server has a high failure rate. [WAJ] From the example, we can know each application has its own = confirmation mechanism, because most of them are asynchronous.=20 The application knows there will be possibilities that the server crash, = or the underlay connection broken. =20 This brings us to your proposed mechanism, in which the server sends an indication that you should do a switchover, and then the client does it. The base case of this looks something like the following: Client Server <------------------ First TCP/TLS Connection ----------------> POST /make-payment -----------------------------------------> [Process payment] <------------------------------------------------------ 200 OK <----------------------------------------------- Switch servers <-------------------- New TCP/TLS Connection ----------------> POST /something-else ----------------------------------------> <------------------------------------------------------ 200 OK This is fine, but now consider what happens if the server sends its request to switch immediately and so the client's request and the server's request to switch cross in transit, like so: Client Server <------------------ First TCP/TLS Connection ----------------> POST /make-payment ---------\ /---------------- Switch servers X <---------------------------/ \------------------------------> Until the client receives the 200 OK, it has no way of knowing that the server has processed the request, so the right thing to do is is to wait until that 200 OK is received, because otherwise you have created exactly the issue discussed above, where you're counting on the application retry logic to be right on both the client and the server; and because this happens a lot we're risking a lot of new errors. [WAJ] The retry logic have already existed in almost each application = interactive pattern. Unfortunately, these transaction semantics only exist at the HTTP layer, not the TLS layer, so the TLS layer has no way of knowing to wait for the 200 OK, it just knows that the client sent some data, but not whether that reflects an outstanding request or something else; recall that TLS doesn't even know about the HTTP request/response semantics, because it's just a dumb pipe. [WAJ] TLS needn=E2=80=99t aware the 200 OK signal, it is the job of = application layer. TLS/TCP needs only transmit the data from the application layer = correctly to other side. In your email, you suggest that the client ought to: 1. Wait for the server's TCP ACK of all transmitted data, with the implied semantics being that once the message is ACKed it will be reliably delivered to the server, not just to the TCP stack. [WAJ] No. I emphasize only the TCP ACK and the TCP stack. Not the = application stack. That is to say, receiving the TCP ACK doesn=E2=80=99t = represent the application layer ACK. 2. Buffer any data it receives form the cleint while waiting for the ACK and retransmit it on the new connections. [WAJ] Buffer any data it receives, but can=E2=80=99t transmit = immediately during the switchover process, not waiting for the = application ACK. This is a pretty big layering violation, but I don't believe that this will work either, because we don't know that the client's flight was complete. Suppose instead that we have a situation where the client's request is in two parts and the first one and the server's request cross in transmission. In that case, we might get this: Client Server <------------------ First TCP/TLS Connection ----------------> POST /make-payment (1/2) ---\ /---------------- Switch servers X <---------------------------/ \------------------------------> [Buffer /make-payment (2/2)] <-------------------------------------------------------- ACK <-------------------- New TCP/TLS Connection ----------------> /make-payment (2/2) -----------------------------------------> In this case, the server won't process the first half of the request (probably),=20 [WAJ]: The client should try to send the first half of the request later = when the switchover finished, or else, let the user send again. and the second half of the request isn't even validly formed HTTP, so we've got a mess. The only thing that will work here is that the client retries the POST in totality, but we're back to the situation above, and in neither case do we want to buffer and re-send the second half of the request. =20 [WAJ] Such situation should be left to the application itself, if some = requests are longer and need to be send in multiple http request(or = response), the application should be able to repacking the disorder = application data. Here too, the problem is that the semantics are only known at the HTTP layer, and the TLS layer doesn't know them, so it can't do the right thing. By contrast, if you do the switchover at the application layer, it can pick an appropriate timepoint where there is no ambiguity about the client and server state and proceed appropriately. [WAJ] The aim of switchover is application agnostic, and can be applied = to various application. It=E2=80=99s better in TLS/TCP layer. -Ekr =20 Regarding to question 2), we think: 2.1) The application runs on the TLS layer. If the TLS layer = doesn=E2=80=99t notify the application during the switchover, the = application needs not be aware for the underlying switchover 2.2) TLS layer should only keep the switchover as quickly as possible, = for example, reuse the previous negotiated shared key etc, as we = proposed in the draft. 2.3) The application needs just send the data to the same TLS instance. How about your concerns regarding to the above explanation?=20 Should we include them into the document for further clarify if the = above considerations is reasonable? =20 Happy holiday to you all! =20 Best Regards =20 Aijun Wang China Telecom =20 From: forwardingalgorithm@ietf.org = [mailto:forwardingalgorithm@ietf.org = ] On Behalf Of Eric Rescorla Sent: Tuesday, October 28, 2025 4:13 AM To: Mohit Sahni > Cc: Aijun Wang >; tls@ietf.org = ; draft-wang-tls-service-affinity@ietf.org = ; Aijun Wang = > Subject: [TLS] Re: FW: New Version Notification for = draft-wang-tls-service-affinity-00.txt =20 =20 =20 On Mon, Oct 27, 2025 at 1:02=E2=80=AFPM Mohit Sahni = > = wrote: Hi Eric,=20 One concern regarding using HTTP Alt Svc is that this limits the = solution to HTTP based application, however TLS based solution helps = with other application protocols too e.g. FTP or SMTP or any other = protocol that uses STARTTLS construct. =20 Yes, I'm aware of that. However, for the reasons Indicated in my = response upstream, I think it's a feature that it happen at the = application layer in a protocol-specific fashion. =20 -Ekr =20 =20 -Mohit=20 =20 On Sun, Oct 26, 2025 at 7:55=E2=80=AFPM Aijun Wang = > 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_rfc8446-23section-2D2 = = &d=3DDwIFaQ&c=3DV9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=3DJ7DgfMyeL= 26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=3DS278vH9k736nF13K7hekoC9UmWiLbx5bPp= ySG6AG0wl-GJWmZBEH76RXKh178Prx&s=3DB0_YVjIgvDRP9AWMrgVcHGU594aeWIXGEZAZqv= D8Liw&e=3D=20 If there is any misunderstanding due to the above ignorance, let's = discuss further based on our future update based on TLS 1.3 Anyway, I try to explain our considerations in more detail inline below. Best Regards Aijun Wang China Telecom -----Original Message----- From: forwardingalgorithm@ietf.org = [mailto:forwardingalgorithm@ietf.org = ] On Behalf Of = =E3=80=90=E5=A4=96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 Eric Rescorla Sent: Saturday, October 25, 2025 1:24 AM To: Aijun Wang > Cc: tls@ietf.org ; = draft-wang-tls-service-affinity@ietf.org = =20 Subject: Re: [TLS] FW: New Version Notification for = draft-wang-tls-service-affinity-00.txt 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. =E3=80=90WAJ=E3=80=91Yes 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. =E3=80=90WAJ=E3=80=91The "Migration_Token" is manly used to bind the new = connection to the previous session. 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. =E3=80=90WAJ=E3=80=91The 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. 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. =E3=80=90WAJ=E3=80=91The initial purpose is to switch the address ASAP. = There may be some race conditions(would you like to illustrate some?) = and extra signal may be necessary later to refine the switchover. 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. =E3=80=90WAJ=E3=80=91Before 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_draft-2Dwang-2Dtls-2Dservice-2Daffinity-2D00-23name-2Dintrodu= ction = = &d=3DDwIFaQ&c=3DV9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=3DJ7DgfMyeL= 26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=3DS278vH9k736nF13K7hekoC9UmWiLbx5bPp= ySG6AG0wl-GJWmZBEH76RXKh178Prx&s=3DwjYYFdlQkm_hyIPH5wlCSjErLDcYyWrJ_FkapL= N_7k0&e=3D ). 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). And, actually, QUIC has also such migration process: = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_html_rfc9000-23name-2Dconnection-2Dmigration = = &d=3DDwIFaQ&c=3DV9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=3DJ7DgfMyeL= 26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=3DS278vH9k736nF13K7hekoC9UmWiLbx5bPp= ySG6AG0wl-GJWmZBEH76RXKh178Prx&s=3DIhoM_hlC_ptCYdMMOa72ZAogUt3qS7ywnXCGgH= 8gpWA&e=3D=20 -Ekr On Tue, Oct 21, 2025 at 2:10=E2=80=AFAM Aijun Wang = > wrote: > Hi, All: > > We have submitted one new draft regarding to the service affinity=20 > function for TLS based application. > We are also applying the time slot for the presentation on the coming=20 > IETF > 124 meeting. > > Wish to get your comments/suggestions on this topic before the=20 > meeting, and we can also discuss further during the on-site meeting. > > Best Regards > > Aijun Wang > China Telecom > > -----Original Message----- > From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org ] > Sent: Friday, October 17, 2025 4:34 PM > To: Aijun Wang >; Ketul Sheth <=20 > ksheth@paloaltonetworks.com >; = Mohit Sahni=20 > >; = Wei Wang > > 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=3D ------=_NextPart_000_004F_01DC79B7.A3A46BB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi, = Eric:

 <= /span>

Contrary to your = conclusions, I think the application layer and TLS/TCP layer = should(already) have their own mechanisms to assure the data integrity, = there is no necessary to consider them again at the protocol layer, we = need just some guidance for the implementation of client/server sides = themselves.

If there is data = arrival during the switchover, the internal implementation logic is the = application layer will call the api of TLS/TCP to send some data, with = the same session identifier.

 <= /span>

When these data = reach to the TLS/TCP stack, and the connection between client/server = sides are not established, the client can cache these data for a short = time.

And, if the = connection time exceeds some threshold, there will(should) be some = indications to the application layer, which will should be similar with = the results when the server can=E2=80=99t be reachable with other = unknown reason. =C2=A0

When = the application receives such signal from the undelay TLS/TCP layer, it = should notify the user to retry to send the data again(=E2=80=9Cclick = the button again=E2=80=9D)

 <= /span>

If the switchover = occurs within the threshold, the application layer will not even notify = the change.

Some detail reply = can see below inline[WAJ], based on your = example.

 <= /span>

Happy New Year to = you! =C2=A0J=

 <= /span>

Best = Regards

 <= /span>

Aijun = Wang

China = Telecom=

 <= /span>

From:<= /b> = forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] On = Behalf Of Eric Rescorla
Sent: Saturday, December 27, 2025 = 7:57 AM
To: Aijun Wang = <wangaijun@tsinghua.org.cn>
Cc: tls@ietf.org; = draft-wang-tls-service-affinity@ietf.org; Mohit Sahni = <msahni@paloaltonetworks.com>; Aijun Wang = <wangaj3@chinatelecom.cn>
Subject: [TLS] Re: = =E3=80=90Reply to the = comments after the presentation in Montreal=E3=80=91RE: Re: FW: = New Version Notification for = draft-wang-tls-service-affinity-00.txt

 

 

 

On Thu, Dec 25, 2025 at = 7:14=E2=80=AFPM Aijun Wang <wangaijun@tsinghua.org.cn&g= t; wrote:

Hi, = Eric and Martin:

 

During my = presentation in IETF 124 meeting for this service affinity proposal, you = raised the following questions that can be summarized as the = followings:

1)    How to assure = there is no application data loss during the switch take = place?

2)    How to keep the = application unware about the switchover, because the TCP connection = switchover?

 

Regarding to the = question 1), after discussing with some experts offline, we = think:
1.1) TLS is based on TCP, and the TCP layer can assure the = application data be transferred successfully to the peer, based on the = TCP ACK mechanism.
1.2) The client can decide when to switchover, = based on the peer=E2=80=99s TCP ACK.
1.3) If some application data comes to the = client during the switchover, the client can store them temporarily. = This is local implementation consideration, needs not the extension of = the protocol.

 

I'm not sure that this is quite = correct about the concerns MT and I
were raising, so let me try to = clarify.

Consider a simple HTTP REST API.

Client   =                     =                     =        Server

POST /make-payment =  ----------------------------------------->
    =                     =                     =   [Process = payment]
<------------------------------------------------------ = 200 OK

When the client receives a 200 OK, it knows that the = request
has been processed. If it doesn't, it has to assume it has = not.
For instance, consider the following case:


Client =                     =                     =          Server

POST /make-payment =  ----------------------------------------->
    =                     =                     =   [Process payment]
            =                     =               [Server = crashes]
[TCP retransmit] = -------------------------------------------->
<-----------------= ---------------------------------------- RST

In this case, the = client doesn't know what has happened. You need
mechanisms either at = the HTTP layer--or more typically at the REST API
layer--to do the = right thing, which might be an idempotency layer
combined with = client-side retransmit.  This is all just a
straightforward = application of the end-to-end argument, and there's no
real way = around it as long as systems might asynchronously fail, but
it's also = a source of defects (think about how many times sites tell
you not to = press the submit button twice) because these mechanisms may
not have = been exercised or tested. For instance, if the server is = high
reliability and the client just assumes that anything it sent = works,
that will be good enough a very large fraction of the time, = but not if
the server has a high failure rate.

[WAJ] From the = example, we can know each application has its own confirmation = mechanism, because most of them are asynchronous. =

The application = knows there will be possibilities that the server crash, or the underlay = connection broken.

 <= /span>


This brings us to = your proposed mechanism, in which the server sends
an indication that = you should do a switchover, and then the client
does it. The base = case of this looks something like the following:

Client   =                     =                     =        Server

<------------------ First = TCP/TLS Connection ---------------->
POST /make-payment =  ----------------------------------------->
    =                     =                     =   [Process = payment]
<------------------------------------------------------ = 200 OK
<----------------------------------------------- Switch = servers

<-------------------- New TCP/TLS Connection = ---------------->
POST /something-else = ---------------------------------------->
<---------------------= --------------------------------- 200 OK


This is fine, but = now consider what happens if the server sends its
request to switch = immediately and so the client's request and the
server's request to = switch cross in transit, like so:


Client       =                     =                     =    Server

<------------------ First TCP/TLS = Connection ---------------->
POST /make-payment ---------\ = /---------------- Switch servers
          =                   =  X
<---------------------------/ = \------------------------------>


Until the client receives = the 200 OK, it has no way of knowing that
the server has processed = the request, so the right thing to do is is
to wait until that 200 OK = is received, because otherwise you have
created exactly the issue = discussed above, where you're counting on
the application retry logic = to be right on both the client and the
server; and because this = happens a lot we're risking a lot of new
errors.

[WAJ] The retry = logic have already existed in almost each application interactive = pattern.

Unfortunately, these = transaction semantics only exist at the HTTP
layer, not the TLS = layer, so the TLS layer has no way of knowing to
wait for the 200 OK, = it just knows that the client sent some data, but
not whether that = reflects an outstanding request or something else;
recall that TLS = doesn't even know about the HTTP request/response
semantics, because = it's just a dumb pipe.

[WAJ] TLS = needn=E2=80=99t aware the 200 OK signal, it is the job of application = layer.

TLS/TCP needs = only transmit the data from the application layer correctly to other = side.


In your email, you suggest that the client ought = to:

1. Wait for the server's TCP ACK of all transmitted data, = with the
implied semantics being that once the message is ACKed it = will be
reliably delivered to the server, not just to the TCP = stack.

[WAJ] No. I = emphasize only the TCP = ACK and the TCP stack. Not the application stack. That is to say, = receiving the TCP ACK doesn=E2=80=99t represent the application layer = ACK.=


2. Buffer any data it = receives form the cleint while waiting for the
ACK and retransmit it = on the new connections.

[WAJ] Buffer any = data it receives, but can=E2=80=99t transmit immediately during the = switchover process, not waiting for the application = ACK.



This is a pretty big layering violation, but I = don't believe that this
will work either, because we don't know that = the client's flight was
complete. Suppose instead that we have a = situation where the client's
request is in two parts and the first = one and the server's request
cross in transmission. In that case, we = might get this:

Client             =                     =                 =  Server

<------------------ First TCP/TLS Connection = ---------------->
POST /make-payment (1/2) ---\ /---------------- = Switch servers
              =               =  X
<---------------------------/ = \------------------------------>
[Buffer /make-payment = (2/2)]
<-------------------------------------------------------- =  ACK

<-------------------- New TCP/TLS Connection = ---------------->
/make-payment (2/2) = ----------------------------------------->


In this case, = the server won't process the first half of the request
(probably), =

[WAJ]: The client = should try to send the first half of the request later when the = switchover finished, or else, let the user send = again.

and = the second half of the request isn't even validly
formed HTTP, so = we've got a mess. The only thing that will work
here is that the = client retries the POST in totality, but we're back
to the situation = above, and in neither case do we want to buffer
and re-send the = second half of the request.

 <= /span>

[WAJ] Such = situation should be left to the application itself, if some requests are = longer and need to be send in multiple http request(or response), the = application should be able to repacking the disorder application = data.

Here too, the problem is that the = semantics are only known at the HTTP
layer, and the TLS layer doesn't = know them, so it can't do the right
thing. By contrast, if you do the = switchover at the application layer,
it can pick an appropriate = timepoint where there is no ambiguity
about the client and server = state and proceed appropriately.

[WAJ] The aim of = switchover is application agnostic, and can be applied to various = application. It=E2=80=99s better in TLS/TCP = layer.



-Ekr
 

Regarding to = question 2), we think:
2.1) The application runs on the TLS layer. If = the TLS layer doesn=E2=80=99t notify the application during the switchover, the = application needs not be aware for the underlying switchover
2.2) TLS = layer should only keep the switchover as quickly as possible, for = example, reuse the previous negotiated shared key etc, as we proposed in = the draft.
2.3) The application needs just send the data to the same = TLS instance.

How = about your concerns regarding to the above explanation?

Should we include = them into the document for further clarify if the above considerations = is reasonable?

 

Happy holiday to = you all!

 

Best = Regards

 

Aijun = Wang

China = Telecom

 

From:<= /b> forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] On Behalf Of = Eric Rescorla
Sent: Tuesday, October 28, 2025 4:13 = AM
To: Mohit Sahni <msahni@paloaltonetworks.com>
Cc: = Aijun Wang <wangaijun@tsinghua.org.cn>; tls@ietf.org; draft-wang-tls-service-affinity@ietf.org; Aijun = Wang <wangaj3@chinatelecom.cn>
Subject: = [TLS] Re: FW: New Version Notification for = draft-wang-tls-service-affinity-00.txt

 

 

 

On Mon, Oct 27, 2025 at 1:02=E2=80=AFPM Mohit Sahni <msahni@paloaltonetworks.com> = wrote:

Hi Eric, 

One concern regarding using HTTP Alt Svc is that this = limits the solution to HTTP based application, however TLS based = solution helps with other application protocols too e.g. FTP or SMTP or = any other protocol that uses STARTTLS = construct.

 

Yes, I'm aware of that. However, for the reasons Indicated = in my response upstream, I think it's a feature that it happen at the = application layer in a protocol-specific = fashion.

 

-Ekr

 

 

-Mohit 

 

On Sun, Oct 26, 2025 at 7:55=E2=80=AFPM Aijun Wang <wangaijun@tsinghua.org.cn> = 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= datatracker.ietf.org_doc_html_rfc8446-23section-2D2&d=3DDwIFaQ&c=3D= V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=3DJ7DgfMyeL26OZuy8d3qTy= _h24Ff1NatxSKMgDUj2Kxg&m=3DS278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0w= l-GJWmZBEH76RXKh178Prx&s=3DB0_YVjIgvDRP9AWMrgVcHGU594aeWIXGEZAZqvD8Li= w&e=3D
If there is any misunderstanding due to the above = ignorance, let's discuss further based on our future update based on TLS = 1.3

Anyway, I try to explain our considerations in more detail = inline below.

Best Regards

Aijun Wang
China = Telecom

-----Original Message-----
From: forwardingalgorithm@ietf.org [mailto:forwardingalgorithm@ietf.org] On Behalf Of = =E3=80=90=E5=A4=96=E9=83=A8=E8=B4=A6=E5=8F=B7=E3=80=91 Eric Rescorla
Sent: Saturday, October 25, 2025 1:24 = AM
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: tls@ietf.org; draft-wang-tls-service-affinity@ietf.org
Subject= : Re: [TLS] FW: New Version Notification for = draft-wang-tls-service-affinity-00.txt

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.
=E3=80=90WAJ=E3=80=91Yes

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.
=E3=80=90WAJ=E3=80=91The = "Migration_Token" is manly used to bind the new connection to = the previous session.

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.
=E3=80=90WAJ=E3=80=91The 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.

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.
=E3=80=90WAJ=E3=80=91The initial purpose = is to switch the address ASAP. There may be some race conditions(would = you like to illustrate some?) and extra signal may be necessary later to = refine the switchover.

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.
=E3=80=90WAJ=E3=80=91Before 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://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= datatracker.ietf.org_doc_html_draft-2Dwang-2Dtls-2Dservice-2Daffinity-2D0= 0-23name-2Dintroduction&d=3DDwIFaQ&c=3DV9IgWpI5PvzTw83UyHGVSoW3Uc= 1MFWe5J8PTfkrzVSo&r=3DJ7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&= ;m=3DS278vH9k736nF13K7hekoC9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&= ;s=3DwjYYFdlQkm_hyIPH5wlCSjErLDcYyWrJ_FkapLN_7k0&e=3D = ).
   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).
    And, actually, QUIC has also such migration = process: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= datatracker.ietf.org_doc_html_rfc9000-23name-2Dconnection-2Dmigration&= ;d=3DDwIFaQ&c=3DV9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=3DJ= 7DgfMyeL26OZuy8d3qTy_h24Ff1NatxSKMgDUj2Kxg&m=3DS278vH9k736nF13K7hekoC= 9UmWiLbx5bPpySG6AG0wl-GJWmZBEH76RXKh178Prx&s=3DIhoM_hlC_ptCYdMMOa72ZA= ogUt3qS7ywnXCGgH8gpWA&e=3D =


-Ekr













<= br>
On Tue, Oct 21, 2025 at 2:10=E2=80=AFAM Aijun Wang <wangaijun@tsinghua.org.cn>
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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, = October 17, 2025 4:34 PM
> To: Aijun Wang <wangaj3@chinatelecom.cn>; Ketul Sheth < =
> ksheth@paloaltonetworks.com>; Mohit Sahni =
> <msahni@paloaltonetworks.com>; Wei Wang <weiwang94@foxmail.com>
> 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=3D

------=_NextPart_000_004F_01DC79B7.A3A46BB0--