Application ‘1’ on host A uses DTLS+CID with application ‘1’ on host B;
Application ‘2’ on host A uses plain-old DTLS with the same application ‘1’ on host B;
NAT rebinding event occurs which reshuffles the two 5-tuples;
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.)
Hannes:
B1 would look at the CID store and then two cases are possible:
a) It finds a match: If it was indeed from A.1 then everything is fine. If it isn’t then it could be from A.2 o(a false positive).
b) It does not find a match: In this case it could try to handle it as an A.2
Yin Xinxing:
Maybe we can add a new “ContentType” in the DTLS record format to help server identify the “connection ID” packet. In addition, you see the length of the record payload is limited by 2^14-1, this means the first two bits of “length” is zero. We could utilize this feature and set the first two bits or more bits of CID being one, e.g., 1111….(but the CID must be put between sequence number and length). When server finds 1111 after sequence number, it knows this is a “connection ID” packet. However, I don’t know whether it is proper to use such magic number. In my view, adding new contenttype may be a choice.
Thomas:
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.)
Hannes:
B1 would look at the CID store and then two cases are possible:
a) It finds a match: If it was indeed from A.1 then everything is fine. If it isn’t then it could be from A.2 o(a false positive). b) It does not find a match: In this case it could try to handle it as an A.2
Yin Xinxing:
Maybe we can add a new “ContentType” in the DTLS record format to help server identify the “connection ID” packet. In addition, you see the length of the record payload is limited by 2^14-1, this means the first two bits of “length” is zero. We could utilize this feature and set the first two bits or more bits of CID being one, e.g., 1111….(but the CID must be put between sequence number and length). When server finds 1111 after sequence number, it knows this is a “connection ID” packet. However, I don’t know whether it is proper to use such magic number. In my view, adding new contenttype may be a choice.