Hi,

I was just wondering whether there is any mechanism to guard against
Distributed Denial of Service using multiple proxies.

Section 16.11 of RFC says
"When a response arrives at a stateless
proxy, the proxy MUST inspect the sent-by value in the first
(topmost) Via header field value. If that address matches the proxy,
(it equals a value this proxy has inserted into previous requests)
the proxy MUST remove that header field value from the response and
forward the result to the location indicated in the next Via header
field value. The proxy MUST NOT add to, modify, or remove the
message body. Unless specified otherwise, the proxy MUST NOT remove
any other header field values..."

If proxy gets a response with its value in the Top Most VIA, it would just
forward the response to the next VIA entry. Can't this feature be used to
setup a DDOS?

The way to achieve DDOS with this, is by sending fake responses to
proxy. These responses should have the second via entry as the server
that is under attack. Since a proxy would remove top-most via and
forward the response to the next entry, the machine under attack would
receive the responses. Now if multiple proxies are used to target a single
server, then the machine under attack would receive response from all the
different proxies. Here the different proxies would become "innocent"
accomplice in carrying out the attack.

A way to guard against this is to have a validation cookie in the branch.
When ever proxy forwards a request, proxy should add a cookie parameter
in its Via header. The cookie has to be generated using some private data
that only the proxy knows. One way of generating it is to use MD5 on
private key + the mandatory headers CSEQ, & CALLID & Via.

Now, if a response comes in which has SentBy value of the proxy, Proxy would
regenerate the Cookie using the above principle (Call-Id & Cseq & Via headers
would remain same in the response). Proxy would compare it with the cookie
present in the Top most Via branch. If it does not match, proxy would silently
discard the response.


This cookie value needn't be part of existing Via branch. It could be a extension
parameter.

eg.

Via: SIP/2.0/UDP uac1.d1.sachins.com:5088;
branch=z9hG4bKd13e5c725cede1645508afaeed9a65bd;
cookie=aa663004def625ffc29e78491e02ca2

Above mechanism won't blocks all kinds of DOS. But it would
make it harder to carryout DDOS using the response hacking.

Hope I have not missed something?

Thanks
Sachin


_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to