Re: draft-zourzouvillys-sip-via-cookie

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