(no title)
chmike
|
2 years ago
The problem result from the ability to forge a fake origin IP address. This can be avoided by adding a certificate for the IP address. It adds a processing and size overhead, but it also preserves the single round trip transaction.
cyberax|2 years ago
At which point, it makes sense to just give up and use a normal TLS/QUIC connection. QUIC also has 0-RTT resumption, which is functionally similar to what you want.
Really, raw UDP makes very little sense in today's Internet. It might have been marginally more useful if BCP38/RFC2827 were more widely adopted.
tjoff|2 years ago
I might agree if the only purpose of UDP was to avoid the handshake. But this issue alone only affects some usecases.
Naive workaround/thought, require the client to pad the first packet to the point where there you can't use it for amplification attacks (not an absurd amount, just 1k or something. Of course depends on the context).
And possibly embed the source IP in the first response so that the indirection isn't as effective either.
chmike|2 years ago
Revocation is indeed a weak point of this solution as it would take time, probably a transaction, to check. This problem might be mitigated by shortening the certificate validity duration.
I don't see why time synchronization would be critical if the validity periods are slightly overlapping.
amtamt|2 years ago
tjoff|2 years ago
fulafel|2 years ago
chmike|2 years ago
unknown|2 years ago
[deleted]
jzwinck|2 years ago