Iptables: "-p udp --state ESTABLISHED"
So, iptables basically remembers the port number that was used for the outgoing packet (what else could it remember for a UDP packet?),
I am pretty sure for UDP the source and destination ports and addresses are stored.
If you want to inspect the state tables install conntrack and/or netstat-nat.
(What would happen, if I accidentally tried to start a service on that port within the timeframe - would that attempt be denied/blocked?)
Since you are using OUTPUT and INPUT your are talking about local services. The port is already used I don't believe your system will allow you to start up another service since something is already listening on that port. I guess you could stop the first service and start another if you really wanted to though, in that case the response would probably get to your service. What the service does with the packet depends on what the contents of the packet is, and what service it is.
NB: This answer has been edited.
Despite what the man pages say, ESTABLISHED appears to mean "stateful". For UDP that simply means (as you suggest) remembering each outbound UDP packet (the "src ip, src port dst ip, dst port" tuple) for a while and recognising its responses.
FWIW, my normal rules for DNS traffic would be something like this:
# permit any outbound DNS request (NB: TCP required too)
iptables -A OUTPUT -p udp --sport 1024:65535 --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024:65535 --dport 53 -j ACCEPT
# accept any packet that's a response to anything we sent
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
i.e. control traffic on the OUTPUT chain, and then let the iptables state modules handle everything else on the INPUT chain.
See also this related question.
The iptables developers have considered that an "ESTABLISHED" state was the situation when packets have been seen in both directions whatever the protocol between two clients.
the state extension is part of conntrack. The kernel understands the state from table
/proc/net/nf_conntrack
Example of iptable states for UDP in table nf_conntrack from sender point of view. Let's imagine you send a DNS query on UDP
udp 17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
[UNREPLIED] src=192.168.1.10 dst=192.168.1.2 sport=53 \
dport=35237 use=1
A packet has been sent. It unreplied and oh, the table has the data for what is expected in return (the packet for the DNS answer).
udp 17 20 src=192.168.1.2 dst=192.168.1.10 sport=35237 dport=53 \
src=192.168.1.10 dst=192.168.1.2 sport=53 \
dport=35237 use=1
The reply is arrived, the unreplied flag is gone, it means this UDP connection is in ESTABLISHED state for a small amount of time defined in your system.
Its a common misconception about UDP, most of the people get confused between STATE-LESS and CONNECTION-LESS. UDP is connectionless but its session is stored in the session table of TCPIP stack and the same is used by iptables and conntrack.