Theo:
Thanks for pulling this draft together. I certainly admire the problem
you're trying to solve, and you've done a very good job of summarizing
it and its effects.
I have one fundamental point about the proposed mechanism, and a
suggestion for further analysis.
The fundamental point is based on your observation that this attack can
be effective when the victim is a non-SIP endpoint, simply because the
incoming SIP messages can saturate their link. (I'll add to that that
the attack can wreak havoc on a deployed non-SIP service by
intentionally targeting that service's port). With this fact in mind,
It's not clear to me how the proposed extension overcomes the described
problem. To wit:
1. The attacker sends a request to the amplifiers, with a spoofed
source IP.
2. Each of the amplifiers, which are compliant to this specification,
sends the new 4XX defined by this document to the victim's IP
address. It contains a cookie.
3. Of course, the victim (not having a SIP client running on that
port) doesn't respond (at least, not with a SIP message). The
attacker, wanting his attack to succeed, has craftily chosen a
port he knows to be open (probably by first portscanning the
victim). As a consequence, the victim does not send any ICMP error
to the amplifiers.
4. Because they didn't get an ACK, 500 ms later, each of the
amplifiers sends another 4XX response.
5. This continues according to the response retransmission rules of
RFC 3261 until all 11 responses have been sent.
So the 11-to-1 amplification attack doesn't appear to be fixed by this
mechanism, assuming the attacker makes a rather modest attempt to succeed.
Presuming this can be remedied (and I have no immediate suggestions for
doing so), I would recommend you consider the interaction between your
proposal and forking. Analyze it in the context of the HERFP issues, and
make sure forking doesn't cause unintended behavior when interacting
with your mechanism. Also, consider longer proxy chains. For example:
Note that a 4XX response MUST trigger an ACK to be sent as per normal
SIP processing rules. The generated ACK MUST contain the cookie
parameter copied from the 4XX response.
Keeping in mind that ACK messages triggered by non-2XX responses are
hop-by-hop, this falls down when you have a proxy between the UAC and
the server sending the 4XX. The intervening proxy may not implement this
extension, so you can't rely on it doing anything special with the ACK
(unless you define a Proxy-Require, which pretty much renders the
extension undeployable).
/a
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
