I agree with Matt. The port/IP could be reallocated to the peer that sends packets with connection ID.
Yin Xinxing -----邮件原件----- 发件人: TLS [mailto:tls-boun...@ietf.org] 代表 Matt Caswell 发送时间: 2017年11月3日 0:32 收件人: tls@ietf.org 主题: Re: [TLS] Connection ID Draft On 17/10/17 22:35, Martin Thomson wrote: > On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) <thomas.foss...@nokia.com> wrote: >> The following case (NAT box reboot) is problematic: >> >> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on >> host B (B.1); >> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; 3. >> The NAT box reboots (all previous 5-tuple mappings are lost); 4. B.1 >> receives a record from A.1 (whose 5-tuple has changed in the >> meanwhile); >> >> How is B.1 supposed to correctly interpret the bytes starting at >> offset >> +11? (For what it knows, it could be CID from A.1 or the length >> +field >> from A.2.) > > I don't think that this is a problem. > > connection = five_tuples.lookup(packet.five_tuple) > if (!connection) { > connection = > connection_ids.lookup(packet[connection_id_offset:connection_id_offset > +connection_id_length]) > } Just skimming this old thread...doesn't this fail in the case where the five tuple has been reused? In that case five_tuples.lookup will return an old stale connection which the server thinks is still valid so we never get to lookup the connection id. With an explicit marking we would not fail in this scenario. Matt _______________________________________________ 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
