Subject: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 16:05:48 -0500

rant inline.

Dean Willis wrote:

> 
> But please help us understand what's different about IPSEC usage in  the 
> IMS sense.
> 
> IMS has a persistent IPSEC SA established between the edge proxy and  
> the UA. Authentication is accomplished using the SIM as a token  
> generator, and the crypto is one of the usual mechanisms (keep in  mind 
> TLS still allows plain small-key DES, which isn't all that  strong). The 
> applications are constructed so that the SIP function is  aware of the 
> SA and that it is connected to an authenticated party.

Well, now you're going to get me started on how bad the IMS IPSec 
mechanism is.

<rant>
Its IPSEC, sure, but its keyed with a horrific 
tunnel-keys-through-SIP-register mechanism. Given the immense 
complication in designing secure keying protocols, I have a deep fear 
that there is a lurking security hole in the way keying works in IMS. 
Indeed, the specifications for this 'keying' protocol are about as 
opaque as you can make them. They are deeply buried within IMS 
specifications, bundled with lots of other stuff. This makes it nearly 
impossible for broad analysis and critique from the security community, 
which includes many folks (if not most) that would never be able to 
penetrate the IMS specifications in order to comment.

I'll also note that it is a massive layer violation; we're using an 
application layer protocol to key a security protocol over which that 
very same application layer protocol will run. Does that not simply 
strike you as absurd?

 From an implementation perspective, the IMS security mechanism is a 
nightmare. You can't use "standard" offloaders, since those assume 
standardized keying mechanisms, not this insanity of using SIP for 
keying. This makes IMS servers more expensive. You need to deeply 
integrate your IPSec and SIP stacks. Awful!!

If TCP is the stumbling block to using TLS in IMS, then DTLS to me would 
be a blessing. Nothing would please me more than to deprecate the specs 
that define this nightmare. Two in particular - the seemingly innocuous 
RFC4169 which opens the door for sip-as-a-keying-protocol, and the even 
more horrible RFC3329, which hides its real agenda of adding bid-down 
prevention to SIP-the-IPSec-keying-protocol. Once deprecated, we can 
tell 3gpp to use SIP over DTLS in R8.
</rant>

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.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: Aki Niemi <[email-masked]>
Date: Thu, 02 Nov 2006 11:11:33 +0200

Rants are so much fun. Another inline.

ext Jonathan Rosenberg kirjoitti:
> rant inline.
> 
> Dean Willis wrote:
> 
> 
>>
>> But please help us understand what's different about IPSEC usage in 
>> the IMS sense.
>>
>> generator, and the crypto is one of the usual mechanisms (keep in 
>> mind TLS still allows plain small-key DES, which isn't all that 
>> strong). The applications are constructed so that the SIP function is 
>> aware of the SA and that it is connected to an authenticated party.
> 

<rant style='my opinions only'>
In all fairness, I don't remember you or anyone else offering DTLS as an
alternative ~5 years ago when all this was specified. Nor did we have
the PSK cipher suite for TLS, which IMO would go far in solving the IMS
first-hop problem in a much, much cleaner way.

Being involved in the work you mention, I would be first to admit it's
an Utter Hack, and nothing would please me more than to see it go away.
What's worse is that the way it's being implemented and deployed manages
to lose the one bit that is actually worth something, i.e., the bid-down
protection of sec-agree. I think we managed to lay in enough bugs in
there, too, that interop is pretty horrible. But hey, live and learn.

That said, the root of all evil here is UDP. It still escapes me why
people insist on dragging that baggage around when all I see are cons
with using UDP as transport. If anything, that's a massive layer
violation to run SIP over UDP, and then replicate the state machine of
TCP in SIP. A while ago there was speculation on the SIP WG list about
defining delayed ACK for SIP to get around some weird error condition
(pardon me, the details escape me ATM). That to me would have been the
last spool that completes the reinvented wheel.

People have cited performance problems for servers having to scale up
with a huge number of TCP connections. I don't buy that. People have
cited problems with mobile handsets not being able to handle TCP. Bogus.
Even the low-end phones today handle TCP and run TLS just fine. If
someone has a phone that doesn't, well, perhaps it's time to upgrade.

What's nice about TCP is that the performance in presence of NAT tends
to be a lot better than with UDP. In wide area cellular, using UDP
keepalives will drain the battery unless you have the phone connected to
a charger. And that pretty much defeats the purpose of a *mobile* device.

So lets not forget what brought on the Rel5 security specs with their
associated problems for the IMS. It was the total lack of a viable
security solution for SIP over UDP, and the inability to use anything
but Digest as the authentication method. Today, we're not much better off.
</rant>

Cheers,
Aki

P.S. I only guarantee the above to be well-formed, not necessarily valid.

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Nov 2006 11:51:37 -0600

Pication is pretty  
> problematic for
> confidentiality. So statelessness in combination with security  
> seems unlikely to be
> sucessesful to me at least. So let's just not keep investing time  
> on it? I've become
> pretty sympathetic to the idea of deprecating UDP over the years  
> given these
> realities.

I don't disagree, but that sort of change requires normative change  
to standards-track RFCs, not usage guidlines.

>
> Part of this for me is that SIP is just too damn complicated, and  
> it's painfully
> obvious that it keeps getting itself wrapped around the axle  
> because of some
> fairly high level decisions which at a high level seemed unrelated  
> but have
> proven to be vexingly difficult to unify. It would be really nice  
> to just chuck
> some of the decisions made mostly in a different time (cf Aki's  
> note), and
> move on given the current reality. SIPS is one of these, UDP is  
> probably
> another, and my sense is there are a whole host of things that I  
> don't pay
> much attention to that qualify too.
>

Choir preaching!

> So I'll try to put this into a more constructive light rather than  
> the whine above:
> why not make a BCP which discourages the use of things known to be  
> problematic
> aiming at while not exactly deprecating, but end-of-life'ing those  
> things so that
> we have a more manageable SIP going forward? Leave the problematic  
> things
> alone for closed systems where they might be feasible, but stop  
> developing for
> them for open internet standards where those assumptions can't be  
> made.

Might be reasonable. There are limits, of course, to what one can  
change in a BCP. For example, one can say "The RFCs allow options A  
and B. A has been proven not to work, so we suggest you use B". One  
can't add a new option with a BCP. And unfortunately, we may need a  
new option in order not to run afoul of the current RFC-tangle.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 2 Nov 2006 11:51:37 -0600

> Rants are so much fun. Another inline.

Excellent rant, which could be summarized as "deprecate UDP". I think  
that's an interesting suggestion. It almost sounds like something I  
might have said myself at some timeIt would also solve our large- 
responses problem, and our "oh my god my request is too big to send  
in one packet" problem, and a bazillion other things.

It does have a bit of susceptibility to the RST DOS attack of TCP to  
think about, something that DTLS does not suffer from. But other than  
that and inertia I can think of no good reason to keep using UDP.

I'll note however that Robert reports that SIPit seems to indicate  
that most implementations are dealing with fragmented UDP just fine  
and nobody is actually noticing any problems with large packets, so  
we may be "burning a straw witch" when we worry about fragmentation.  
Personally, I'm far more worried about rampant complexity.

--
Dean

recedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

> Rants are so much fun. Another inline.

Excellent rant, which could be summarized as "deprecate UDP". I think  
that's an interesting suggestion. It almost sounds like something I  
might have said myself at some timeIt would also solve our large- 
responses problem, and our "oh my god my request is too big to send  
in one packet" problem, and a bazillion other things.

It does have a bit of susceptibility to the RST DOS attack of TCP to  
think about, something that DTLS does not suffer from. But other than  
that and inertia I can think of no good reason to keep using UDP.

I'll note however that Robert reports that SIPit seems to indicate  
that most implementations are dealing with fragmented UDP just fine  
and nobody is actually noticing any problems with large packets, so  
we may be "burning a straw witch" when we worry about fragmentation.  
Personally, I'm far more worried about rampant complexity.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 3 Nov 2006 14:41:40 -0800

> Excellent rant, which could be summarized as "deprecate UDP". 
> I think that's an interesting suggestion. It almost sounds like 
> something I might have said myself at some timeIt would also 
> solve our large-responses problem, and our "oh my god my request 
> is too big to send in one packet" problem, and a bazillion 
> other things.
> 
> think about,

If you're worried about that attack, you should be equally concerned
about a nearly-identical attack on UDP that seems apparent -- 
draft-jung-sipping-authentication-spit-00 discusses a solution, but
as I have posted earlier, if a UA expects all messages from its
proxy contain Authentication-Info, we may be able to solve the
same problem.

> something that DTLS does not suffer from. But 
> other than that and inertia I can think of no good reason to 
> keep using UDP.

To be clear, DTLS does not solve the large UDP problem -- DTLS 
has support for fragmentation, but only for the TLS handshake 
itself.  We could, and maybe should, invent some framing 
so that DTLS could solve that problem, too.  Adding such framing
might be appropriate if/when draft-jennings-sip-dtls-02.txt 
becomes a WG item.

> Personally, I'm far more worried about rampant complexity.

That conflicts with the conclusion of 
draft-heffner-frag-harmful-02, which is in IETF last call.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Nov 2006 20:51:08 -0500

inline.

Aki Niemi wrote:

> alternative ~5 years ago when all this was specified. 

Of course not; it didnt exist. The alternative was TLS and that was 
deemed unacceptable.

> Nor did we have

Great! SO lets work on it!

> someone has a phone that doesn't, well, perhaps it's time to upgrade.

The oft-cited problem is one of performance for real-time services, 
i.e., the delays in call setup that tcp would cause. I'm not enough of a 
TCP expert to know whether any of these have merit or are just bogus 
paranoia.

> a charger. And that pretty much defeats the purpose of a *mobile* device.

Sure; though even with TCP its still bad for wireless. NAT between a 
mobile device and the radio network is just an awful topology. Recently 
Dan submitted a draft which addresses the only solution I've seen that 
allows a good solution for cellular here:

http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usage-00.txt

-Jonathan R.

---

From: <[email-masked]>
Date: Sun, 5 Nov 2006 14:47:18 +0200

Hi,

Jonathan Rosenberg wrote:
>> In all fairness, I don't remember you or anyone else 
>offering DTLS as 
>> an alternative ~5 years ago when all this was specified.
>
>Of course not; it didnt exist. The alternative was TLS and 
>that was deemed unacceptable.
>

The point is that 3GPP IMS tried to do the best it could with the tools
available 5 years ago, and with the requirement of supporting both TCP
and UDP. Now that we do have better tools and better understanding, I
agree that it is possible to device a better solution. 

>> Nor did we have
>> the PSK cipher suite for TLS, which IMO would go far in solving the 
>> IMS first-hop problem in a much, much cleaner way.
>> 

Yes, I think it would make sense to redefine the IMS security solution
based on TCP, TLS, and TLS-PSK. From my point of view the biggest
problem is that nowadays we have two main security specs for SIP
authentication and first hop protection, one based on TLS and another
based on IPSec. It is a burden to keep supporting both of them.

I note however, that it is 3GPP who maintains the IMS specification, so
any updates of this magnitude are subject to concensus there. But it
would certainly help, if the IETF came up with a working solution
meeting the IMS requirements. 

>The oft-cited problem is one of performance for real-time 
>services, i.e., the delays in call setup that tcp would cause. 
>I'm not enough of a TCP expert to know whether any of these 
>have merit or are just bogus paranoia.
>

I don't call myself a TCP expert either, but I fail to see any major
problem. If the UA maintains a persistent TCP connection with its edge
proxy, the initial INVITE and any furhter messages can be send and
received without any additional delay compared to UDP. Also, the
problems that TCP can have over wireless links that lose packets, do not
really show up with the kind of "lock-step" pattern that SIP has. All
messages fit into one or two packets, and then the sender waits for
something in return. So, even if packets are lost, the congestion
windows etc. do not cause much harm, since you always ever have only one
or two packets to send. It is a different thing if you'd send a big
chunk of data over SIP, but then we're not talking about real-time
anymore and besides you'd need to do that on top of a
congestion-controlled transport anyway.

>mobile device and the radio network is just an awful topology. 

True. If the wireless access provider can use public addresses, no
problem. If it can't, it can still put its *OWN* servers to the same
private address space as where the mobile hosts are. But, if some other
service provider who does not have anything to do with the access
network wants to offer, say SIP, service, then there's going to be a NAT
and the service provider can do nothing about it. (And even if there's
no NAT, it's possible that there's a stateful firewall which is nearly
as bad.) This is not a SIP specific problem at all, but is visible in
any applications requiring the host to be reachable from the network
side. SIP, however, makes things even worse by using UDP for signaling.
The best we can do is to run SIP over TCP and mux RTP/RTCP into the same
port. (And still it may not be good enough.)

Markus

---

From: Dean Willis <[email-masked]>
Date: Sun, 5 Nov 2006 10:18:00 -0600

On Nov 3, 2006, at 7:51 PM, Jonathan Rosenberg wrote:

> i.e., the delays in call setup that tcp would cause. I'm not enough  
> of a TCP expert to know whether any of these have merit or are just  
> bogus paranoia.
>

I believe that particular argument is bogus, at least within the  
bounds of IMS as currently defined. Since the TCP connection to the P- 
CSCF would be formed during registration, there should generally be  
no impact on call-setup times.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sun, 5 Nov 2006 17:51:01 +0100

Dean,

Your mileage may vary here. In the best case TCP will be at par with UDP. 
You need a connection between each pair of hops, so for a typical case (see 
e.g. http://www.tech-invite.com/Ti-ims-sesflow-1.html) that's 6 + 1 (because 
the I-CSCF drops out) = 7 connections. Even when assuming outbound on both 
sides, the worst case still involves 5 TCP setups (sequentially).

That being said, the way things are going those INVITEs will quickly reach 
the 1300 byte limit (if not at the UA then somewhere at one of the proxies, 
see message 1f). So assuming IETF recommendations are followed, UDP won't be 
a feasible option for long.

Regards,
jeroen

---

From: David R Oran <[email-masked]>
Date: Sun, 5 Nov 2006 13:38:28 -0500

On Nov 5, 2006, at 11:51 AM, Jeroen van Bemmel wrote:

> Dean,
>
> Your mileage may vary here. In the best case TCP will be at par  
> with UDP. You need a connection between each pair of hops, so for a  
> typical case (see e.g. http://www.tech-invite.com/Ti-ims- 
> sesflow-1.html) that's 6 + 1 (because the I-CSCF drops out) = 7  
> connections. Even when assuming outbound on both sides, the worst  
> case still involves 5 TCP setups (sequentially).
>

That's one way of looking at it. The other way is to ask why there  
are 7 hops in the first place!

> That being said, the way things are going those INVITEs will  
> quickly reach the 1300 byte limit (if not at the UA then somewhere  
> at one of the proxies, see message 1f). So assuming IETF  
> recommendations are followed, UDP won't be a feasible option for long.
>
> Regards,
> jeroen
>
>
> Dean Willis wrote:

---

From: "Samir Srivastava" <[email-masked]>
Date: Sun, 5 Nov 2006 12:45:31 -0600

I too believe so. Proxies in the path mostly will keep the TCP
connections persistent between them and we are talking about
connect-reuse.

If the UAC and UAS are only reachable via UDP, then it will be only two
TCP connection setup delay. But I don't believe so as SDP is becoming
huge and huge, these two TCP connection setup will be far better than
the call failure due to loss of packets etc...
How long people will keep refraining from using Security, unless it
doesn't come with prohibiting price ?

Also with Proxy-Require (TCP), we know that it is e2e TCP, Do we need
then PRACK ? We can simplify the complex state m/c.... Offer / Answer
break ?

Thx
Samir

>-----Original Message-----
>From: Dean Willis [mailto:[email-masked]] 
>Sent: Sunday, November 05, 2006 8:18 AM
>To: Jonathan Rosenberg
>Cc: Joel M. Halpern; 'IETF SIP List'; Aki Niemi
>Subject: Re: SIP as an alternative to IKE?, was: Re: [Sip] RE: 
>TLS meaning
>
>
>> i.e., the delays in call setup that tcp would cause. I'm not 
>enough of 
>> a TCP expert to know whether any of these have merit or are 
>just bogus 
>> paranoia.
>>
>
>I believe that particular argument is bogus, at least within 
>the bounds of IMS as currently defined. Since the TCP 
>connection to the P- CSCF would be formed during registration, 
>there should generally be no impact on call-setup times.
>
>--
>Dean
>
>
>
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 05 Nov 2006 23:02:34 -0500

Jeroen van Bemmel wrote:
> Dean,
> 
> Your mileage may vary here. In the best case TCP will be at par with 
> UDP. You need a connection between each pair of hops, so for a typical 
> case (see e.g. http://www.tech-invite.com/Ti-ims-sesflow-1.html) that's 
> 6 + 1 (because the I-CSCF drops out) = 7 connections. Even when assuming 
> outbound on both sides, the worst case still involves 5 TCP setups 
> (sequentially).

That would be a very unlikely worst case. In general all of those 
connections, except perhaps the first and the last, will typically be up 
all the time. And if outbound was used for IMS then the first and the 
last would also be up all the time the UAs are able.

Its possible that some freakish set of circumstances could conspire to 
result in needing 5 sequential setups, but such a case is likely to be 
in calamitous situations.

	Paul

> That being said, the way things are going those INVITEs will quickly 
> reach the 1300 byte limit (if not at the UA then somewhere at one of the 
> proxies, see message 1f). So assuming IETF recommendations are followed, 
> UDP won't be a feasible option for long.
> 
> Regards,
> jeroen
> 
> 
> Dean Willis wrote:

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Nov 2006 09:56:20 -0600

> recommendations are followed, UDP won't be a feasible option for long.

Perhaps, but the argument was that TCP was unsuitable for mobile use  
because of the unsuitability of TCP on the last-hop mobile phone  
link. I think we now have ample evidence to refute that part of the  
argument.

--
Dean

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 6 Nov 2006 23:05:07 +0100

Dean,

I've just done some measurements. This is in no way representative or 
statistically significant, but what I get on my PDA (Windows Pocket PC 2003) 
on a commercial Dutch operator GPRS network (no NAT) connecting to my home 
grown proxy at home (on ADSL and then behind NAT):

start-REGISTER-401-REGISTER-OK-end (starting with GPRS off, SIP UA detects 
IP assignment and registers, times measured at UAC):
UDP : 2-3 seconds (T1=2 seconds, no retransmissions occur)
TCP:  ~1 second connection setup, then 2-3 seconds
TLS: ~3 seconds handshake, then 2-3 seconds (without cert checking etc)

In all cases, a re-REGISTER sequence has similar timing.

In other words: for my environment, once the connection is up, round trip 
delay differences are indeed negligible

Regards,
Jeroen

Dean Willis wrote:
>> recommendations are followed, UDP won't be a feasible option for
>> long. Regards,
>> jeroen
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 6 Nov 2006 18:16:57 -0600

On Nov 6, 2006, at 4:05 PM, Jeroen van Bemmel wrote:

> Dean,
>
> I've just done some measurements. This is in no way representative  
> or statistically significant, but what I get on my PDA (Windows  
> Pocket PC 2003) on a commercial Dutch operator GPRS network (no  
> NAT) connecting to my home grown proxy at home (on ADSL and then  
> behind NAT):
>
> start-REGISTER-401-REGISTER-OK-end (starting with GPRS off, SIP UA  
> detects IP assignment and registers, times measured at UAC):
> In other words: for my environment, once the connection is up,  
> round trip delay differences are indeed negligible
>

Cool. Thanks.

That matches with my own informal observations.

--
Dean