l0om says: Remember UDP loops

It is common for currently protocol designing processes to fall back on well-proven 
protocols to take them as a basis. This seems to be especially true if you take a
look on HTTP. On new requirements it responded with flexibility, it has prevail and
it has proven itself.

One prominent example for dependence of protocols is SIP: Session Initiation Protocol.

> "[...]
> 4 Overview of Operation
> 
>  SIP is based on an HTTP-like request/response transaction model.
>   Each transaction consists of a request that invokes a particular
>   method, or function, on the server and at least one response. [...]" (RFC3261)

As you can see SIP is based on the HTTP transaction model. But there is a minor 
difference between the SIP based ideal of HTTP and the original HTTP. The original
HTTP has been designed to work with TCP. 

> "[...]
> 7.5 Framing SIP Messages
>
>   Unlike HTTP, SIP implementations can use UDP or other unreliable
>   datagram protocols. [...]" (RFC3261)

As SIP is desigend to work on UDP as well the HTTP based transfer model suffers
from the possibilitiy of UDP loops. Lets say someone is sendung trash on a SIPs 
servers UDP port, what will happen?

> "[...]
> 21.4 Request Failure 4xx
>
>   4xx responses are definite failure responses from a particular
>   server.  The client SHOULD NOT retry the same request without
>   modification (for example, adding appropriate authorization).
>   However, the same request to a different server might be successful.
>
> 21.4.1 400 Bad Request
>
>   The request could not be understood due to malformed syntax.  The
>   Reason-Phrase SHOULD identify the syntax problem in more detail, for
>   example, "Missing Call-ID header field [...]". (RFC3261)

well, "The client SHOULD NOT retry the same request" but what if he does and 
will never stop? It is quite easy to construct a UDP loop with SIP. Just take
one of the hundred thousands of daytime servers in the net. The UDP daytime protocol
sends a date string to everyone who sends a UDP packet with random data or none 
data to the active port. An attacker might send such a spoofed UDP packet what will
result in something like this:

>	IP 192.168.2.101.13 > 221.xxx.xxx.xxx.5060: SIP, length: 10
>	IP 221.xxx.xxx.xxx.5060 > 192.168.2.101.13: SIP, length: 85
>	IP 192.168.2.101.13 > 221.xxx.xxx.xxx.5060: SIP, length: 26
>	IP 221.xxx.xxx.xxx.5060 > 192.168.2.101.13: SIP, length: 86
>	IP 192.168.2.101.13 > 221.xxx.xxx.xxx.5060: SIP, length: 26
>	IP 221.xxx.xxx.xxx.5060 > 192.168.2.101.13: SIP, length: 86
>	IP 192.168.2.101.13 > 221.xxx.xxx.xxx.5060: SIP, length: 26
>	IP 221.xxx.xxx.xxx.5060 > 192.168.2.101.13: SIP, length: 86
>	IP 192.168.2.101.13 > 221.xxx.xxx.xxx.5060: SIP, length: 26
>	[...	NEVER ENDING LOOP	...]

In the SIP RFC in "26.1.5 Denial of Service and Amplification" they are talking
about DoS attackes which are based on SIP details but they dont show the possibility
of takeing down a UDP SIP server by a daytime-DDoS attack.

The use of the HTTP transaction model with UDP is not connected without any difficulties.