[chmike]

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]

It doesn't really work. You need to use fairly strong cryptography, and this means a lot of CPU power from your side to validate it. You also need mechanisms to notify users about certificate invalidation and expiration, you need ways to synchronize "time", etc.

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]

> 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.

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.

[cyberax]

I guess, I should have specified that I meant raw UDP for simple request-response protocols.

The other major use-case for UDP is for protocols where loss is preferable to retransmission delay, it's still very much valid. But in this case, UDP is used within a stateful context, with multi-stage handshakes and everything.

[chmike]

I didn't mean to generalize the use of certificate. It would be for a specific protocol for a specific application. I just wanted to justify that we are not required to use three way handshake.

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]

We probably don't need certificates for IP addresses,and just ensure edge routers sending packets to the internet ensure they are sending pockets with source defined as a network IP only within defined CIDRs.

[tjoff]

How do you do that and still allow access from anyone without any prior configuration?

[fulafel]

There have been several plans for deploying IPSec everywhere as a evolution of IP with different key management strategies. There needs to be a way to look up a public key for a ip address, there's more than one way to do it.

[chmike]

In prior configuration, the UDP client must get a certificate which uses three way handshake to verify the IP address. Once a client has it's certificate, it can perform transactions with a simple two way transactions.

[jzwinck]

One way could be to require signing with a TLS certificate whose hostname resolves to the source IP(s).

[tonyarkles]

When NAT gets involved things get very complicated very quickly for that. For many networks and ISPs this would need to happen at the IP egress level and couldn’t happen on the end device, since the end device doesn’t even know its own IP and neither does the on-prem router.

[chmike]

Thank you. It's the best argument against the certificate suggestion I have read so far. It's a problem I overlooked.

Edit: If the server creates the certificate with a three way handshake, it will use the remote IP address. So the client doesn't have to know it's IP address

[tjoff]

How is that no prior configuration on the client side?

[jzwinck]

Clients could use the same certificate for every server, so there is only a one-time setup. Analogous to how clients need to be "configured" with an IP address, the certificate could be given to them by their internet gateway if desired.

[tjoff]

Yeah, and in what universe could that work? I need directions.

Seems far simpler to send a physical mail to the service operator who then hardcodes the IP in the server.

Or, maybe do a handshake once and cache it for X amounts of time whatever makes sense for that service.