Differences for page UDP

Current version compared with version Wed May 19 13:14:52 GMT 2004

- *User Datagram Protocol*. TODO: list the related RFC and describe how this protocol is sensible to IP spoofing if the application level protocol doesn't care about this problem.+ *User Datagram Protocol* ([link http://ietf.org/rfc/rfc0768.txt RFC768]).
+ The UDP protocol is very similar to the [IP] itself, because it's just able to send datagrams from an host to another, without
+ to try to make the link reliable. As [IP], [UDP] datagrams can get lost, duplicated, or delivered out of order. Protocols using [UDP] that need
+ to be reliable have to implement retrasmission after a timeout on top of [UDP]. For instance the [DNS] protocol, that implements a request/reply
+ protocol on top of [UDP] retry to send the query after some time if no response was received from the [DNS] server.
+ 
+ The main abstraction that [UDP] adds to [IP] is the concept of [port]. With [IP address]es it's possible to send data to a specific host,
+ but with [port]s it's possible to send data to a specific process of a specific host.
+ 
+ ===UDP header===
+ [img udp-hdr.png]
+ 
+ This is the C structure for the UDP header:
+ 
+  struct udphdr {
+          __u16   source;
+          __u16   dest;
+          __u16   len;
+          __u16   check;
+  };
+ 
+ ===IP spoofing and UDP===
+ 
+ Being [UDP] a datagram protocol there is no state, different UDP packets are not about the same connection.
+ If the application level protocol is not designed for security it's often very simple to do [spoofing] against protocols
+ implemented on top of [UDP]: it's as simple as to do spoofing with [IP] itself, the destination host can't tell what's
+ the real source of the packet, there is nothing of similar to the [TCP] sequence numbers (that often the attacker
+ can't guess, so it's not able to forge a valid packet).
+ 
+ ===See also===
+ [IP], [TCP], [ICMP]

The following is the old page content