Subject: [Sip] draft-zourzouvillys-sip-via-cookie

From: Adam Roach <[email-masked]>
Date: Tue, 24 Feb 2009 11:12:18 -0600

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

---

From: Theo Zourzouvillys <[email-masked]>
Date: Tue, 24 Feb 2009 18:20:25 +0000

On Tue, Feb 24, 2009 at 5:12 PM, Adam Roach <[email-masked]> 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*
>

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?

> 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:
>
> 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
> (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

---

From: Adam Roach <[email-masked]>
Date: Tue, 24 Feb 2009 15:29:46 -0600

>    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.

> 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

---

From: Theo Zourzouvillys <[email-masked]>
Date: Tue, 24 Feb 2009 21:58:18 +0000

On Tue, Feb 24, 2009 at 9:29 PM, Adam Roach <[email-masked]> wrote:
> 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.

will do

> 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.

While I did initially consider this problem, and indeed came up with a
potential solution in the form of a new authentication scheme or a
header that the client then used to insert in it's own via header,
HERFP as well as multi-hop authentication just seemed to make any
solution i could come up with very complex compared to this method -
which while it has it's downsides in terms of backward compatibility,
the beauty is in it's simplicity and that it should hopefully not be a
burden for stacks to add with no change outside of the
transaction/transport layer.

 ~ Theo

---

From: Michael Procter <[email-masked]>
Date: Wed, 25 Feb 2009 07:27:42 +0000

Hi Adam,

> This, combined with prohibiting provisional responses, would seem to

I don't think there is any proposed modification.  The response should
be sent according to the rules of RFC 3261 section 8.2.7.  Amongst other
things, this specifically prohibits provisional responses.

I think the draft should explicitly mention this section.

Regards,

Michael

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Feb 2009 09:01:02 -0600

Michael Procter wrote:
> be sent according to the rules of RFC 3261 section 8.2.7.

Wow -- I had completely forgotten about 8.2.7.

>   Amongst other

Yes, that would be a significant improvement. I think you'll also want 
to give the cookie the same properties as 8.2.7 describes for to-tags.

/a

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Feb 2009 16:36:10 -0500

> I think the draft should explicitly mention this section.

And more importantly, according to 8.2.7, the recipient of an INVITE
does *not* resend a 4xx response if it doesn't receive an ACK.  At first
read, this seems to violate the 3-way-handshake model of the INVITE
transaction, but it doesn't -- If the 4xx got lost, the UAC will send it
again, prompting the UAS to send an identical 4xx response.  If the ACK
gets lost, the UAS doesn't care.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Feb 2009 16:39:08 -0500

> to give the cookie the same properties as 8.2.7 describes for to-tags.

Hmmm...  Oddly, you can't do that, because the cookies should depend on
the time.  But the cookie mechanism quasi-satisfies 8.2.7, because
multiple sends of an INVITE will receive multiple responses with
different cookies, but all of the cookies are "equivalent", in that any
one of them can be chosen for successful future use.

Dale