Theo Zourzouvillys wrote:
On Tue, Feb 24, 2009 at 5:12 PM, Adam Roach <[email protected]> wrote:
Hi Adam,
Thank you for the feedback;
With this fact in mind, It's not clear to me how the
proposed extension overcomes the described problem. To wit:
*snip*
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.
The key here is that the 4XX response to a request without a cookie is
sent by the next hop statelessly, and doesn't cause a server
transaction to be created (and thus no re-transmits); as per 4.3, para
4:
If a request is received from an IP address that could be spoofable
(i.e, any request received from the general internet), and that
request is going to have a server transaction created for it, and the
top via field contains a cookie parameter, then the server SHOULD
generate a new cookie for this source and generates a 4XX response,
and place the cookie value into the cookie parameter of the top via
field before sending the response statelessly.
Ah -- "statelessly" means something very different to you than it does
to me. I think you need to explicitly call out that you're proposing a
modification to the basic INVITE transaction model defined in RFC 3261
for this new response.
This, combined with prohibiting provisional responses, would seem to
have the desired effect.
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).
In the case a previous hop doesn't support this draft, then the server
sending the 4XX would know that the client didn't support the cookie
anyway, because the request's top via header didn't contain an empty
"cookie" parameter. Although the copying-to-the-ACK is not there for
any reason other than diagnostic purposes right now - although
arguably the server sending the 4XX can also set the To tag to contain
any data it wanted to store so could be removed.
It sounds like you're currently setting this up so that it can't work
transitively -- that is, if you have a chain of proxies, some of them
compliant to this behavior, others that aren't, then any proxy past a
non-compliant one can't check return routability. That seems like an
artificial limitation. If you had some other way of indicating support
by a client that could be checked by every proxy in the chain, then you
could perform routability checks all the way back to the client
regardless of intervening older proxies.
/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
