Subject: RE: [Ieprep] IPsec vs TLS for SIP message protection

From: "Nguyen, An" <[email-masked]>
Date: Mon, 24 Jun 2002 14:03:24 -0400

Ian,

My understanding is that TLS is more interoperable than IPSec because the
TLS architecture is much simpler. TLS deals with transport layers and IPsec
with IP. IETF has so many flavors of IPSec. And getting all these to talk to
one another is more of a political issue than technical. 

I would like to know technically how IPSec protects SIP messages better than
TLS as far as DoS is concerned.

Personally I think IPsec and TLS are good for SIP and other applications.

Regards,

An

-----Original Message-----
From: Ian Brown [mailto:[email-masked]]
Sent: Monday, June 24, 2002 10:47 AM
To: ieprep
Subject: [Ieprep] IPsec vs TLS for SIP message protection

I had some feedback from Eric Rescorla that he considers IPSec much more
suitable for use in protecting SIP messages in a resource-constrained
environment than TLS due to its better Denial of Service protection.
However, not all SIP devices will support IPSec (but should support TLS).

What do people think about specifying that IPSec should be used where
available in preference to TLS?

Thanks,

Ian.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 24 Jun 2002 17:00:17 -0400

On Monday, June 24, 2002, at 02:03 , Nguyen, An wrote:
> IETF has so many flavors of IPSec. And getting all these to talk to

anh A^n,

	If one defines "IPsec" to include dynamic key management (e.g. 
ISAKMP/IKE),
then interoperability has been a real problem.  IKE is quite complex.
Moreover, IKE is unstable in the standards sense.  It will either be 
replaced
by IKEv2 or JFK or some other proposal -- because IKEv1 is widely 
believed
to have a range of problems -- including security anomalies.

	However, if one defines "IPsec" (as I do) to only mean AH and ESP,
then interoperability has not been a significant problem since 1996.
Commercial interoperable implementations of AH and ESP are pretty widely
available today, not just in firewall products, but also in commercial
operating systems (e.g. Sun Solaris).

> TLS as far as DoS is concerned.

- TLS does not protect the IP header, as AH does.
- TLS does not protect the actual TCP header, as either ESP or AH does.
- TLS does not protect any UDP-based traffic, as either ESP or AH does.
- Unlike ESP, the US has universally permitted export of AH because
   AH is authentication-only, while ESP can also be used for 
confidentiality.

There are a number of documented attack methods [Bellovin89] on the TCP 
header
(e.g. send a forged RST to take down a session) that ESP or AH can 
protect
against that TLS cannot protect against.

I'm not so much arguing for or against using ESP/AH in the context of 
SIP;
I am trying to clear up the misunderstandings that appear to exist
on this mailing list about the differences in the security properties
provided by TLS, ESP, and AH.

Regards,

Ran
[email-masked]

PS:	and yes, I'm the guy who invented ESP and AH in the first place,
	and lead the team at NRL with the first ESP/AH implementation (in 
4.4 BSD),
	though I am not working on security stuff these days...

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Jun 2002 12:24:51 +0100

Isn't there on-going work on payload level protection of SIP
messages?

If so, then s/mime &/or pgp (or whatever the SIP folks develop)
should also be considered.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Jun 2002 08:23:08 -0400

> should also be considered.

Indeed; S/MIME is specified in the current draft that will become the 
successor of RFC 2543. After wasting far too much time trying to argue 
which is the best mechanism, most of the working group seems to have 
reached the conclusion that S/MIME, TLS and IPsec all have strengths in 
particular deployment scenarios and that we'll see a combination of them 
in practice. S/MIME is no replacement for IPsec or TLS, since it is an 
end-to-end encryption mechanism that needs to leave a number of header 
fields unencrypted. (The converse is true, too.) I suspect that this 
working group may have better things to do than rehash those arguments.