Hi Martin, According to the code you described in previous email, ISTM your idea of parsing the standard packet and CID packet is using the 5-tuple. The benefit is that no new contenttype or version is needed. But the precondition for well working is that the 5-tuple of the CID packet will not be successfully matched in the receiver's 5-tuple table. However, this condition is not always true.
If I misunderstand your idea, please correct me. Thanks. Yin Xinxing -----邮件原件----- 发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Martin Thomson 发送时间: 2017年10月18日 16:08 收件人: Fossati, Thomas (Nokia - GB/Cambridge, UK) 抄送: tls@ietf.org 主题: Re: [TLS] Connection ID Draft On Wed, Oct 18, 2017 at 5:44 PM, Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote: > This is quite similar to the trial and error / heuristic that I was > mentioning in [1]. You didn't mention 5-tuples. And it isn't trial and error: you use 5-tuple as your primary key and use connection ID to latch. > Note that if A.1 and A.2's 5-tuples are swapped, the algorithm fails > to recognise A.1 as CID-enabled and sends it forward to the crypto > handler when it shouldn't. As I said before, any connection without a connection ID monopolizes that 5-tuple making it inaccessible to other connections. I think that in this case: too bad. > And the already discussed limitations: > - Fragility on corner cases (e.g., the 5-tuple swap above); I don't see how you can avoid this in the general case. Any connection without connection ID is going to be hard to correlate if it moves. As for the connection that does have a connection ID but moves on top of a connection that doesn't, I don't think that is an acceptable loss. > - Forcing middleware to keep state; > - Breaking wireshark & co unless they can see the whole session; Both of these are acceptable to me. Unless you can describe a middlebox use case that needs access to this information and can't deal with the solution that I described. Wireshark and co will need to see the handshake if they want to decrypt and that's the only case that is important. > - (Depending on the use case, the cost of the two lookups per record > on the parsing might have a performance impact.) The second lookup only happens after a migration. I neglected to mention that successful use of a connection ID causes the 5-tuple to be assigned to that connection; there's a trick there in that you need to watch for reordering, but it saves the double lookup. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
