Subject: [Sip] Draft: draft-holmberg-sip-keep-00.txt

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 6 May 2008 17:50:27 +0200

Hi,
 
Based on discussions we've had in SIP, I have (with some good input from a number of people) put together a draft which defines a mechanism to indicate support of, and use, the keep-alive techniques defined in draft-outbound, without using the Outbound mechanism itself.
 
One use-case, which is also what we mostly have discussed, is simply when entities do not support the Outbound mechanism but still want to implement and use keep-alive.
 
Another use-case is non-registration calls (for example non-registration emergency calls) where Outbound can't be used.
 
The draft can be found at:
 
http://users.piuha.net/cholmber/drafts/draft-holmberg-sip-keep-00.txt
 
Regards,
 
Christer
_______________________________________________
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: [email-masked] (Juha Heinanen)
Date: Tue, 6 May 2008 18:59:10 +0300

Christer Holmberg writes:

 > Based on discussions we've had in SIP, I have (with some good input
 > from a number of people) put together a draft which defines a
 > mechanism to indicate support of, and use, the keep-alive techniques
 > defined in draft-outbound, without using the Outbound mechanism
 > itself.

why does the keepalive support be indicated?  why can't the UA simply
start sending keepalives and be happy if it receives responses?  this
works today fine with double-CRLF keepalives without any indication or
outbound support.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 May 2008 13:03:19 -0500

I think it's really for the STUN-in-SIP UDP thing more than double-CRLF-in-TCP.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Juha Heinanen
> Sent: Tuesday, May 06, 2008 08:59
> To: Christer Holmberg
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Sip] Draft: draft-holmberg-sip-keep-00.txt
> 
>  > Based on discussions we've had in SIP, I have (with some 
> good input  > from a number of people) put together a draft 
> which defines a  > mechanism to indicate support of, and use, 
> the keep-alive techniques  > defined in draft-outbound, 
> without using the Outbound mechanism  > itself.
> 
> why does the keepalive support be indicated?  why can't the 
> UA simply start sending keepalives and be happy if it 
> receives responses?  this works today fine with double-CRLF 
> keepalives without any indication or outbound support.
> 
> -- juha
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 6 May 2008 21:13:22 +0300

> I think it's really for the STUN-in-SIP UDP thing more than

the draft talks about "keepalive techniques".  but even in stun case,
why can't the UA just try to use it and see what happens?

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 May 2008 13:37:32 -0500

People are worried that multiplexing different protocols (SIP and STUN) on the same port
may cause problems.

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Tuesday, May 06, 2008 11:13
> To: Audet, Francois (SC100:3055)
> Cc: Christer Holmberg; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: [Sip] Draft: draft-holmberg-sip-keep-00.txt
> 
> Francois Audet writes:
>  
>  > I think it's really for the STUN-in-SIP UDP thing more 
> than  > double-CRLF-in-TCP. 
> 
> the draft talks about "keepalive techniques".  but even in 
> stun case, why can't the UA just try to use it and see what happens?
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 6 May 2008 21:51:44 +0300

Francois Audet writes:

 > People are worried that multiplexing different protocols (SIP and
 > STUN) on the same port may cause problems.

if they cause problems to the proxy, then the proxy is an easy
target for attacks and should not be connected to the net anyway.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 May 2008 15:07:20 -0400

Actually, it will cause problems for the device sending STUN, because that next-hop proxy will (rightly) consider it a malformed attack and blacklist the sender.

But it's also because by letting the next-hop proxy know the sender can send STUN or CRLF keepalives means the next-hop proxy does not need to potentially do other things itself.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Juha
> Heinanen
> Sent: Tuesday, May 06, 2008 2:52 PM
> To: Francois Audet
> Cc: [email-masked]; Christer Holmberg
> Subject: Re: [Sip] Draft: draft-holmberg-sip-keep-00.txt
>
> Francois Audet writes:
>

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 6 May 2008 22:32:35 +0300

Hadriel Kaplan writes:

 > Actually, it will cause problems for the device sending STUN, because
 > that next-hop proxy will (rightly) consider it a malformed attack and
 > blacklist the sender.

if proxy supports stun, it can recognize that the request is a stun
requests and not an attack.

 > But it's also because by letting the next-hop proxy know the sender
 > can send STUN or CRLF keepalives means the next-hop proxy does not
 > need to potentially do other things itself.

that does make sense, but then the ua needs to let the proxy know,
exactly which keepalive method(s) it supports and the proxy should be
able to respond, which one it wants to receive if there is more than one
that the us is advertising.

-- juha

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 6 May 2008 15:56:46 -0400

> Sent: Tuesday, May 06, 2008 3:33 PM
> To: Hadriel Kaplan
> Cc: Francois Audet; [email-masked]; Christer Holmberg

Right, but the whole thing here is the UA doesn't know if the proxy supports STUN/CRLF, or is legacy.  If the UA does draft-outbound and so does the proxy, it can find out; if it does draft-sip-keep, it can find out.  If the UA finds out the proxy can't do it, then it will not do it.

> that the us is advertising.

I think Christer's current proposal is to re-use exactly what outbound does, which I thought was basically one and only one mechanism per transport type, of message-based/UDP=STUN, stream-based=CRLFCRLF.  If so, then there is no choice to make. (which is good, imo)

-hadriel

---

From: Fredrik Thulin <[email-masked]>
Date: Wed, 07 May 2008 10:08:14 +0200

> Actually, it will cause problems for the device sending STUN, because that next-hop proxy will (rightly) consider it a malformed attack and blacklist the sender.

It's not reasonable for a proxy to blacklist source IPs sending it stuff 
it doesn't like.

If you receive a UDP packet, it's a really rare case that you can know 
that the source IP wasn't spoofed.

If you blacklist based on source IP addresses, it will be very easy to 
denial of service your proxy by getting it to blacklist real clients or 
other SIP proxies for example. That will be a much bigger problem for 
you than actually writing code that don't die when it receives unknown 
data (which you should do anyway, of course).

/Fredrik

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 7 May 2008 11:35:58 -0400

> From: Fredrik Thulin [mailto:[email-masked]]
>
> Hadriel Kaplan wrote:

Au contraire.

> that the source IP wasn't spoofed.

I absolutely agree.  It is unknowable, sans some transport or IP level auth.

> other SIP proxies for example.

If someone knows your IP+port and can successfully spoof it, they can DoS your service *anyway*.  That's the whole problem.  It's game over for your phone, period.  The goal of the proxy then is to stop that from impacting anyone _else_.

> That will be a much bigger problem for

This has nothing to do with writing code that won't die.

-hadriel

---

From: Fredrik Thulin <[email-masked]>
Date: Thu, 08 May 2008 15:58:36 +0200

> This has nothing to do with writing code that won't die.

Ok, good. We agree that network servers should not die when receiving 
stuff it doesn't recognize.

However, I'm not sure I understand you fully - are you saying you 
_still_ think it is a good idea to blacklist source IPs sending you 
bogus stuff to your SIP proxy port 5060, because as long as I don't know 
your legitimate clients IP addresses this won't hurt anyone you care about?

What if someone send you spoofed packets from lots of well known SIP 
servers (future SIP hotmails and gmails for example)? Oh, right - you 
can whitelist those... perhaps.

What if someone sends you spoofed packets from five million different 
source IP addresses? Does blacklisting actually provide any value? One 
of those five million packets _might_ be the phone of one of your users.

If you were _not_ saying you still think it's a good idea to blacklist 
based on source IP, then please just disregard the above =).

/Fredrik

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 May 2008 23:19:04 -0400

> your legitimate clients IP addresses this won't hurt anyone you care

Yup.  Not for those reasons, but yes I still think it's a good idea, as do many of my customers.  It's not like they don't care about all their clients (they do), but they usually err on the side of caution to protect the many over the few.  Some of them only degrade the service of the offenders (graylist them), which I like better but is not as popular as blacklisting.

> can whitelist those... perhaps.

Yup, they're typically white-listed.  And I would hope they'd use an auth mechanism too, such as TLS or IPSEC provide... or at least use TCP.

> of those five million packets _might_ be the phone of one of your users.

Yup.  Most of the proxies I know of which do this don't blacklist on one bad packet alone - it would take a scanner spoofing the right ones for a while to get legit endpoints blacklisted. (and it would have to spoof more than just source IP typically, fwiw)

There are certain things the proxy can do to mitigate that for of attack.  And it's not like it goes unnoticed by the operator either.  And some operators also employ passive systems to detect and stop such scanner attacks.

> based on source IP, then please just disregard the above =).

Well, blacklist the source IP+port and a couple other tuples, but essentially yes that is what I was saying.  What you're describing is essentially indistinguishable from malicious or broken endpoints, or a MitM attack for that matter.  And such defense tactics aren't just triggered by malformed messages either.  Similar tactics with different triggers are ultimately used as a last resort to stop DDoS by bot-nets, and SPIT by war-dialers, for example.

But this really shouldn't be a surprise - people have been doing this for several years (back in 2004 at least, maybe earlier).  The tactics and triggers have gotten smarter over the years, but operators don't upgrade very often.

-hadriel