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. I'll update this in the working draft to also include: ... and MUST NOT create a server transaction for the request. This implies that a server implementing this draft MUST NOT send a 100 response before sending the 4XX. does this satisfy your concern? > 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. Because of the hop-by-hop semantics, i can't see any issues that could be caused with the cookie as any 4XX response is just re-transmitted with the cookie, or if the client doesn't support it and the server requires it then it will just be treated like a 400 response - although i'll have more of a think about any issues it could cause in case there are any unintended side effects. > 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. ~ Theo _______________________________________________ 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
