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

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 04:20:07 +0000

Hi,

I've just submitted an ID that discusses the inherent UDP "problem",
along with a potential workaround to stop it being used maliciously.

I would really welcome any feedback:

  http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-00.txt

 ~ Theo

---

From: <[email-masked]>
Date: Fri, 20 Feb 2009 11:33:24 +0530

Hi Theo,

I was just thinking of a scenario,suppose the attacker creates a spoofed
invite,and inserts his ip in the Via header field and an empty cookie
parameter in the via header field.The Proxie which he wants to use as an
ampilfier in a DoS attack,on receiving such a request will respond with
a 4xx response,and the value of the cookie parameter to be used.On
receiving the cookie,the attacker,resends the invite with the cookie
value and deletes its entry from the Via header field.Thus now the
responses for this invite will be sent back to the UAC which is to be
the victim of the DoS attack only.The UAC which is attacked will receive
a minimum of 22 responses only.

What do you think about this.

Thanks and regards,
 
Shamik Saha
Project Engineer
Voice Protocols
Cell :  +91-9886704155

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Theo Zourzouvillys
Sent: Friday, February 20, 2009 9:50 AM
To: SIP WG
Subject: [Sip] draft-zourzouvillys-sip-via-cookie-00

Hi,

http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-0
0.txt

 ~ Theo
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 07:43:15 +0000

> a minimum of 22 responses only.

SIP responses will always be sent back to the source of the request
(and if rport is included also to the source port), and not the value
of sent-by in the first instance.  The cookie the server generates
would always use the source ip and port in the cookie it creates, so
sending the second request with a different source IP would mean the
server can detect the cookie is invalid.

However, an attacker could indeed make sent-by the address of the
victim, perform the cookie dance (legitimately), and then play dead by
sending ICMP messages for any responses received. However, following
rfc3261 sect 18.2.2 and rfc3263 to the last dot would result in the
response being transmitted every time to the source (attacker) first
before then being transmitted to the victim (after an ICMP port/host
unreachable response), therefore making it a highly unattractive
proposition for the attacker.

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 07:45:42 +0000

> along with a potential workaround to stop it being used maliciously.

note that it's *only* trying to solve the drive-by-shooting problem
that is inherent in UDP where an attacker can just "fire and forget"
by spoofing the source;  it does _not_ try to solve the problem of
verifying Contact or Route header values when establishing a dialog.
I believe this is a separate issue (as it affects all transports, not
just UDP), and am only trying to bring UDP onto the same footing as
connection oriented transports.

Having just read through the draft it again, it would undoubtedly make
more sense to use a non 2xx response as an example instead, and remove
the mention of 100rel to make it clear i'm not trying to solve that :)

 ~ Theo

---

From: Nils Ohlmeier <[email-masked]>
Date: Fri, 20 Feb 2009 10:46:32 +0100

Hi Theo,

>    http://www.ietf.org/internet-drafts/draft-zourzouvillys-sip-via-cookie-00.txt

in general I like your proposal, but I have a few questions/thoughts:

I think the whole "attack scenario" which is described in the draft 
works only if the attacker uses the proxy/registrar of the victim as a 
relay.
Reason 1): because the attacker hopefully does not know which UDP port 
of the victim is currently "open" to accept incoming UDP packets. And if 
their is a NAT or firewall in between the UA it will hopefully only 
accept UDP packets from the proxy/registrar. If the UA of the victim 
runs on a public IP without any "protection" it might accept SIP 
requests from anywhere, although I would call this a very bad UA 
implementation.
Reason 2): when the UA of the victim registeres itself it provides a 
Contact URI. I general I believe UA should only accept incoming requests 
from their registrar IP and port which contains the Contact URI which 
they provided at the registration. This prevents very easily that 
someone sends drive by requests just with the AOR of the victim as R-URI 
to the UA of the victim. If a registrar forwards requests to registered 
UAs with the AOR of the user in the R-URI the registrar is broken in my 
opinion.

Now the question is of the proxy/registrar accepts requests from its 
users from anywhere. I guess that is what you mean with no 
authentication, right?

One bigger concern for the whole approach is: if the attacker knows 
about this cookie extension he will for sure not put an empty cookie in 
the Via header of the request. But how does the proxy of the victim 
handle requests without the cookie extension?
To be backward compatible it would need to accept requests without the 
extension, but then the door is open for the attacker again.
If the proxy of the victim does not care about backward compatibility 
(maybe because attack previntion is more important), wouldn't the need a 
way to tell the sender of the request that the cookie extension is 
required to successfully relay requests? So wouldn't we need a new value 
for the Required header, or would a new 4XX response already be enough.

As I said I like the general idea. But I believe that the attack 
scenario which you describe in your draft should be a little bit more 
narrow then described.

Best regards
   Nils Ohlmeier

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Feb 2009 06:44:40 -0800

Nils,

>If the UA of the victim runs on a public IP without any "protection"
>it might accept SIP requests from anywhere, although
>I would call this a very bad UA implementation.

This is correct.

Why cannot the UA have adequate protection at the application layer, such as authenticating the caller?

Making a massive DOS attack on one single UAs does not seem a "productive" technique for spammers.
And if one individual is a valuable target, such individuals have other communication means besides a sole SIP UA.

Henry

On 2/20/09 3:46 AM, "Nils Ohlmeier" <[email-masked]> wrote:

If the UA of the victim

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 15:36:51 +0000

On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier <[email-masked]> wrote:

Hi Nils,

Thanks for the feedback - i'll elaborate to make the issues you raised
more clear in the next version of the document.

> I think the whole "attack scenario" which is described in the draft works
> only if the attacker uses the proxy/registrar of the victim as a relay.
> Reason 1): because the attacker hopefully does not know which UDP port of
> the victim is currently "open" to accept incoming UDP packets. And if their
> is a NAT or firewall in between the UA it will hopefully only accept UDP
> packets from the proxy/registrar. If the UA of the victim runs on a public
> IP without any "protection" it might accept SIP requests from anywhere,
> although I would call this a very bad UA implementation.

A victim does not need to have an open UDP port;  An attack can easily
be launched against any IP address, even a non SIP related one.

A device behind NAT on the end of a link additionally has no
protection at an IP level, as the link would easily become saturated
as a reflector starts sending failure response retransmits from a IST
every time timerG fires.

> Reason 2): when the UA of the victim registeres itself it provides a Contact
> URI. I general I believe UA should only accept incoming requests from their
> registrar IP and port which contains the Contact URI which they provided at
> the registration. This prevents very easily that someone sends drive by
> requests just with the AOR of the victim as R-URI to the UA of the victim.
> If a registrar forwards requests to registered UAs with the AOR of the user
> in the R-URI the registrar is broken in my opinion.

as above - a victim does not need to be a SIP UA - it doesn't even
need to talk SIP.  The attacker may well be trying to attack a non SIP
entity, for example a web, DNS, or mail server.

On the flip side, a UA that "only accept"s requests from it's
registrar if of course good practice, but is only a step in stopping
SPIT, not denial of service (which this draft tries to tackle), unless
the "only accept" is limited by routability.  Note even NAT doesn't
stop a denial of service attack being launched against the NAT
gateway, causing it's connectivity to become saturated.

This draft is specifically trying to stopping a SIP server transaction
being used as an amplifying reflector in a (distributed) denial of
service attack.  The victim of the attack does not need to be a SIP
endpoint (it doesn't even need to have any ports open!)

> Now the question is of the proxy/registrar accepts requests from its users
> from anywhere. I guess that is what you mean with no authentication, right?

Yes - any SIP server (note a UAS or proxy are both servers for this)
which allows an unauthenticated, untrusted user to create an invite
server transaction (even for failure delivery) is vulnerable.

> One bigger concern for the whole approach is: if the attacker knows about
> this cookie extension he will for sure not put an empty cookie in the Via
> header of the request. But how does the proxy of the victim handle requests
> without the cookie extension?

Any proxy that does wish to be used as an amplifier should reject
requests without cookies with a stateless 4XX, or send a stateless
401/407 if knows it can authenticate it's user.

Of course this is not going to be realistic from day 1, but this
document is a start in finding solutions to some of the DOS problems
we're currently susceptible to by putting a SIP server "on the net".

Right now, there are a large number of SIP endpoints out there that
will amplify a single UDP packet sent to them, and the initiator of
the attack isn't even traceable!

(i'm starting to sound like a scaremonger, so i'll stop now :))

> If the proxy of the victim does not care about backward compatibility (maybe
> because attack previntion is more important), wouldn't the need a way to
> tell the sender of the request that the cookie extension is required to
> successfully relay requests? So wouldn't we need a new value for the
> Required header, or would a new 4XX response already be enough.

I did briefly consider an option tag but the problem is a SIP UA does
not need to implement anything for it to potentially work - for
example a proxy can implement it on behalf of a group of trusted users
(for example, a corporate proxy or an outbound proxy that has
authenticated the inbound request).

There would additionally be no mechanism for recovery if the server
refuses to process UDP requests without cookie support.  The 4XX would
provide a code that allows a machine to understand that it failed due
to cookies (if it knew about, but didn't implement the extension) -
and could for example try upgrading to TCP, [D]TLS etc.  The reason
phrase provides something descriptive for devices that don't
understand it.  For those that don't, it'll fall back to treating it
like a 400.

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 15:40:15 +0000

On Fri, Feb 20, 2009 at 2:44 PM, Henry Sinnreich <[email-masked]> wrote:

Hi Henry,

> Making a massive DOS attack on one single UAs does not seem a “productive”
> technique for spammers.

The problem isn't trying to stop spammers at all, it's trying to stop
SIP servers being used as DOS amplifiers.

> And if one individual is a valuable target, such individuals have other
> communication means besides a sole SIP UA.

The victim does not need to be a SIP UA, it could be any IP address at all.

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 15:42:18 +0000

> 401/407 if knows it can authenticate it's user.

I of course mean does NOT wish to be used, ahem :-)

 ~ Theo

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Feb 2009 07:45:08 -0800

>it's trying to stop SIP servers being used as DOS amplifiers.

If you take this viewpoint, then the fewer servers, the less vulnerability?

Henry

On 2/20/09 9:40 AM, "Theo Zourzouvillys" <[email-masked]> wrote:

Hi Henry,

 ~ Theo

---

From: Michael Procter <[email-masked]>
Date: Fri, 20 Feb 2009 15:53:34 +0000

> If you take this viewpoint, then the fewer servers, the less

In this context, "SIP server" means both proxies and UAs (at least,
their UAS component).  Eliminating B2BUAs (which I think is what you
were getting at) sadly won't eliminate this attack.

Regards,

Michael

---

From: Dean Willis <[email-masked]>
Date: Fri, 20 Feb 2009 14:28:28 -0600

> were getting at) sadly won't eliminate this attack.

I believe Henry would also like to reduce proxies. I'm becoming more  
and more fond of this as a general design principle. Quite possibly,  
the only proxies we should have are ones that provide the outbound/ 
registrar/rendezvous function set. And that's just because we don't  
have those functions at a lower transport level. Other proxy functions  
(like application dispatch and delivery)  may be pointless exercises  
in futility. A working HIP-like transport layer could eliminate the  
outbound/registrar/rendezvous functions.

Most of the other "proxy" functions  we've discussed are probably  
better as UA functions.

Of course, that doesn't help with an attack mode that turns UAs into  
amplifiers . . .

--
Dean

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 21:05:30 +0000

> Of course, that doesn't help with an attack mode that turns UAs into

Well, luckily UAs could more easily remain stateless when rejecting
responses than proxies, as they don't need to worry about things like
forking (be it parallel or serial - e.g due to next hop SRV
processing), so should be able to commonly respond to failure
responses statelessly.

This specific attack only arises when a there can be a invite server
transaction created directly by a UDP request that has not been
authenticated, and doesn't contain a "via cookie"

alas, every UA implementation i've played with to date has almost
always been stateful for even failure responses sent over UDP that
havn't required a large amount of processing (or any variance) to
reach it, except for some very low level induced responses like
malformed header fields.

 ~ Theo

---

From: "Dale Worley" <[email-masked]>
Date: Fri, 20 Feb 2009 17:24:03 -0500

Some quasi-nits regarding the presentation, followed by more substantive
observations:

On page 3, you do an accounting for the level of amplification and total
22 responses for a spoofed INVITE.  But of course, if the spoofed call
can be directed to a UA that will answer (voicemail, anyone?), there can
be far more than 22 RTP packets generated.

On page 7, the process of resending a response that was initially
rejected with a 4XX is discussed.  This should be clarified by noting
that the resent request is a further fork of the original request, which
is much different than the resending operation that is done by a UAC in
response to a 401/407 response.  In particular, the CSeq is not
incremented.

In the discussion, the terms "the client" and "the server" are used,
which would lead people to think of SIP elements in the normal way.  But
in this case, each input or output address/port/transport triple of an
element functions separately:  A cookie used to send from a triple can
only be used to send from that triple, and similarly, the client must
cache known valid cookies for each destination triple separately.

The proposed syntax for cookie is described in the text as using "-" as
a separator, but the BNF uses ":".  "-" should be used, as ":" is
invalid in a "token".

The example shows a request being sent with a value-less cookie
parameter, though the BNF immediately above does not allow such a
parameter.  More importantly, such a value-less parameter does nothing
useful:  If the client will accept requests without cookies, a request
without the parameter will be accepted.  If the client will not accept
requests without cookies, a request without the parameter will elicit a
4XX response, which can be used to resend the request.

In regard to reusing the branch parameters of the initial request in the
resent request -- please do not do that.  Implementations already depend
on proper uniqueness of branch parameters.  In particular, a client that
indexes its transaction states by branch value may respond to the resent
request with the response that was given to the initial request, viz.,
4XX.

In regard to client address triples:  For security, the client must
generate a cookie that is valid for the address to which the response
will be sent.  And validating the cookie requires that the address from
which the request is sent matches the address within the cookie.
Together, these require "symmetric signaling", that responses always go
to the same address from which their requests came, or more exactly, the
address from which the resent request will come.  In any case, the
interaction with the SIP rules in section 18.2.2 need to be enunciated
more clearly:

      o  Otherwise (for unreliable unicast transports), if the top Via
         has a "received" parameter, the response MUST be sent to the
         address in the "received" parameter, using the port indicated
         in the "sent-by" value, or using port 5060 if none is specified
         explicitly.  If this fails, for example, elicits an ICMP "port
         unreachable" response, the procedures of Section 5 of [4]
         SHOULD be used to determine where to send the response.

      o  Otherwise, if it is not receiver-tagged, the response MUST be
         sent to the address indicated by the "sent-by" value, using the
         procedures in Section 5 of [4].

As Shamik notes, the cookie needs to be used not only to validate that
the request comes from the address contained in the cookie, but also to
validate the requested "sent-by" value, the address to which the
response to the later request is to be sent.

Actually, the cookie isn't needed to validate where the request comes
from, but only to validate where the response will be sent.  This allows
us to escape the requirement for symmetric signaling described above --
cookies are generated based on the *destination* of the 4XX, and are
validated against the *response destination address* not the *request
source address*.  This still has the required security property -- the
client can only obtain the cookie for a destination D if D cooperates in
capturing the cookie and providing it to the client.  This does render
unusable the clause "If this fails...", because the client has to know
absolutely what the response destination will be.

(Or can the requester provide multiple cookies for multiple possible
destinations?)

Of course, this mechanism only give benefit if servers start enforcing
cookies, which can't be done until clients implement them.  But the
mechanism can be phased in, in that client implementations can be
deployed first.

Dale

---

From: Nils Ohlmeier <[email-masked]>
Date: Sat, 21 Feb 2009 00:22:24 +0100

Hi Theo,

Am 20.02.2009 16:36 Uhr, schrieb Theo Zourzouvillys:
> On Fri, Feb 20, 2009 at 9:46 AM, Nils Ohlmeier<[email-masked]>  wrote:

Yes, similar to the DNS server aplimifaction attacs which are going on 
right now. I think should you should spend an extra section on the 
scenario to seperate it from the pure SIP scenario.

> as a reflector starts sending failure response retransmits from a IST

Ok, I fear a shortage of you draft caused some confusion here:
IMHO you should differentiate between the attacker, the amplifier and 
the victim.
I was referring here to a UAC behind a NAT being the amplifier. You 
seemed to refer to the real victim here.

With this said I think it would be good if you seperate in your draft 
between UA aplimifers and proxy amplifiers, because they result in 
different traffic numbers if I'm not wrong.

Thus my original though was and still is, that it is most likely easier 
to mis-use any SIP proxy as amplifier. But a proxy will most likely 
"only" re-send any error response 11 times to the victim.
I still believe a UAC should be harder to mis-use as an amplifier (see 
original reasons 1 and 2).

> gateway, causing it's connectivity to become saturated.

See above.
As a victim it makes for sure no difference under which criterias a SIP 
implementation (if it speeks SIP at all) accepts messages. But as an 
amplifier it might make a difference. E.g. if the UA rejects the spoofed 
INVITE with a 305 Use Proxy (although this reply is ambigious), the 
victim will receive only 11 replies within 32 seconds. But if the UA 
accepts the INVITE and starts to ring, and the user accepts... your 
worst case scenario comes into play.

> server transaction (even for failure delivery) is vulnerable.

Agreed. Although a failed server transaction results in a lot less harm 
then an accepted call. Maybe some calculations about the amount of bytes 
would be helpfull here.

> the attack isn't even traceable!

Yep. Like with this DNS amplification attack here:
http://isc.sans.org/diary.html?storyid=5713

(And that only uses the amplification of bytes from a 1:1 
request:response transaction... SIP is worse.)

> understand it.  For those that don't, it'll fall back to treating it

Ok, accepted.

Cheers
   Nils

---

From: Theo Zourzouvillys <[email-masked]>
Date: Fri, 20 Feb 2009 23:34:59 +0000

On Fri, Feb 20, 2009 at 10:24 PM, Dale Worley <[email-masked]> wrote:

Hi Dale,

Thank you very much for your feedback.

I've integrated all your comments into my working -01 draft, with some
additional comments here (i'll reply to your other thoughts

> be far more than 22 RTP packets generated.

absolutely! i'll elaborate on this more in -01, although i'm trying to
be careful not to imply that this particular draft is attempting to
solve RTP sink or in-dialog route/contact verification and only "drive
by shooting" you can do with UDP - i've started a draft that documents
that side of things (and a proposed solution) and will try to submit a
-00 over the weekend.

> More importantly, such a value-less parameter does nothing

A server could behave differently when it receives a request without a
cookie in it, for example require authentication, redirect the user
statelessly to another transport, or something we've not thought of
just yet :-)

It's also useful for diagnostic purposes for deployment: how will we
know when adoption is so widespread it would be safe to require
support for it for a request to proceed?

> resent request -- please do not do that.

agreed - i'd already removed from my current rev.  It was about 4am
when i wrote that, and didn't think it through to well :-)

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sat, 21 Feb 2009 00:06:52 +0000

Hi Nils,

On Fri, Feb 20, 2009 at 11:22 PM, Nils Ohlmeier <[email-masked]> wrote:

> Yes, similar to the DNS server aplimifaction attacs which are going on right
> now. I think should you should spend an extra section on the scenario to
> seperate it from the pure SIP scenario.
>
> [snip]
>
> between UA aplimifers and proxy amplifiers, because they result in different
> traffic numbers if I'm not wrong.

Will do.

> Agreed. Although a failed server transaction results in a lot less harm then
> an accepted call.

although "lot less harm" is still "way more harm than any other
commonly deployed publicly accessible UDP based service" :-)

> Maybe some calculations about the amount of bytes would be helpfull here.

sure.

 ~ Theo

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sat, 21 Feb 2009 00:44:33 +0000

Hi Dale,

> absolutely what the response destination will be.

This actually seems like a far better way, althoguh the original
reasoning was to handle the (all be it pathological) case of different
stacks running on the same IP address but a different port as visible
by a proxy - perhaps for example due to (argh!) CGNAT e.g on most
mobile networks (at least in the UK) , or a serviced office which does
NAT to the same external IP for all it's hosts.

saying that, i'm not too fussed either way, and would appreciate any
thoughts on it...

> (Or can the requester provide multiple cookies for multiple possible

I did consider this previously, but can'y see any way of being able to
handle the case where sent-by contains a host name which resolves to
multiple SRV records with same priority, as the response could go to
any of them (and each would need to be validated and get it's own
token) before passing it to the client to include in the request.
cookies would also need to have a minimum lifetime, so that a server
knows how long those it's generated are valid, and the whole thing
becomes horribly complex... :-)

my thinking was along the lines of because the response is going to be
UDP, a server that needs the redundancy can use anycast on the single
IP / port to ensure to gets the response, even if a given proxy (or
even data centre) dies.

 ~ theo

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 20 Feb 2009 18:14:20 -0800

Please correct me, but these and previous other discussions on related topics, such as forking, early media and race conditions seem to confirm the fact that no formal and reliable routing protocol has been developed as yet to route between a larger number (more than 2 in the trapezoid model) of SIP proxies and various (Oh so many) other feature and media servers.

If there were a reliable routing protocol between all the SIP network elements these discussions would not take place for so long and there would be just one RFC describing something like "The SIP Network Routing Protocol". And some open source implementation to prove it.

As is, every SIP network must be manually engineered, for every configuration instance and adding yet another new "network service" requires starting all over again.

Is this view embarrassingly naïve?
It is only meant to defend the view SIP should be used just as a rendezvous and session setup protocol.

Henry

On 2/20/09 3:05 PM, "Theo Zourzouvillys" <[email-masked]> wrote:

 ~ Theo

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 22 Feb 2009 07:49:08 +0000

> Is this view embarrassingly naïve?

Well, i'd prefer to stay out of a discussion on anything other than
getting the issue at hand fixed, as it's a major problem *right* *now*
for operators who have no choice but to implement SIP/2.0 at it is on
the public internet.

On the other hand, i'll happily engage in any discussion about
anything at all in SF :-)

(on that note, i'm going to be around SF/mountain view the whole of
the week before the IETF if anyone else is and wants to meet up for
drinks or food and general SIP chat - contact me offlist).

 ~ Theo

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 23 Feb 2009 16:19:06 -0500

> statelessly to another transport, or something we've not thought of

"A server may choose to apply additional security mechanisms to a
request without a cookie parameter."

> support for it for a request to proceed?

Good point.

It would help if you added these points to the draft.

Dale