Subject: Re: [Ieprep] clarifications about security

From: Fred Baker <[email-masked]>
Date: Fri, 05 Apr 2002 10:56:59 -0800

At 09:27 AM 4/5/2002, Krishnaswamy, Arvind Shankar (UMKC-Student) wrote:
>The most significant drawback to utilizing Public Key encryption is that 
>it is slow. Public Key encryption requires about a thousand times greater 
>CPU time to use than does a typical Symmetric Key technique (using password).

Symmetric key encryption doesn't use a password, at least not as I 
understand the term. It uses a shared secret, but the secret is never 
exchanged on the wire.

>We may have to compromise on QoS because ESP(Encapsulating Security 
>Payload) encrypts the data sent too which is computationally expensive(an 
>IP telephony gateway relies on high-performance to maintain its quality of 
>service). Is this compromise something which we can adjust to?

As I understand it, symmetric key encryption is used with IPSEC pretty 
regularly; it's just not used with IKE, which is a Diffie-Hellman Public 
Key Exchange.

>Proxy servers/Firewalls in IP telephony gateways can be used to maintain 
>Access control lists to include only friendly neighbors (e.g., other 
>gateways) so that DoS attacks can be prevented. By only recognizing 
>friendly machines, this technique of proxy servers or firewalls is one of 
>the most effective methods against outside intrusion on the physical
>system and its resources. Can this be included as a security requirement?

I don't think it would be wise to *require* firewalls or proxies, although 
they can certainly be part of the defensive solution. There are several 
reasons.

There may not be a need for a firewall, for one thing. Taking the IM model, 
if instant messaging is something that always happens among a set of 
servers operated by the same company, there is no need for us to tell the 
company how to run its business.

Also, firewalls do not provide security; they reduce risk. Let me give you 
a medical example: your body. Your body has a firewall, in the form of an 
organ called the "skin". It serves as a fairly effective barrier against 
all sorts of junk getting into your body, and reduces the risks that the 
rest of the immune system needs to deal with. However, anyone who thinks 
the skin is sufficient as a defence hasn't thought through AIDS or even the 
common cold. The body backs up the skin with a fairly intricate and 
effective intrusion detection and management system that deals with attacks 
on the cell level (lymphocytes), the wound level (platelets, the lymph 
system, and so on), and at the infection level (for example shutting down 
perspiration and raising the body temperature to kill a widespread infection).

In the end, security is always a matter of risk reduction, and as far as I 
know there is no single technology that obviates the risk of internal 
attack as well as external attack, or addresses all attacks.

What seems to be the requirement to bring out in this case is that the 
networks impose appropriate defences, which may include firewalls and 
proxies, and may well include intrusion detection systems and other mechanisms.

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

---

From: Alistair Munro <[email-masked]>
Date: Mon, 08 Apr 2002 08:59:04 +0100

> >service). Is this compromise something which we can adjust to?

I don't see what compromise is required. If more bits are sent then the bandwidth
allocated will have to increase. If more computation is involved then
terminals/forwarders/gateways will have to be more powerful.

Can you explain your model of IP telephony a bit more please? In my system(s), I
run a gatekeeper to place the calls, and a gateway to interwork with PSTN/ISDN. The
performance I budget for depends on the number of calls I expect to handle which
tends to encourage replication, not more powerful systems - gateway load can be
reduced by peering and planning. This is a choice that an installer can make and
budget for; it isn't a compromise.

I assume that handsets will normally talk to each other directly in the IP domain,
(through firewalls if they are installed), not via a relay unless there is a non-IP
transit network in the way. Do we require the handsets to support additional
protocols for security purposes? If so which ones? I am not sure what the current
practice is for encrypting content, nor if such measures are widely implemented in
typical video/voice telephony products - I'll check the ones that I am using. BTW,
can we draw on the MIDCOM WG for protocols to achieve dome of this functionality?

Regards,

Alistair

---

From: Ian Brown <[email-masked]>
Date: Mon, 8 Apr 2002 14:20:20 +0100

> Do we require the handsets to support additional
> protocols for security purposes? If so which ones?

Most likely IPSEC/TLS for signalling protection and SRTP for content
protection.

---

From: Fred Baker <[email-masked]>
Date: Mon, 08 Apr 2002 08:46:40 -0700

At 12:59 AM 4/8/2002, Alistair Munro wrote:
>I am not sure what the current
>practice is for encrypting content

there are two cases: one can encrypt a call, or one can encrypt the traffic 
going to a target system, as in the case of a VPN. They are rather 
different. In either case, any QoS procedures need to minimize the delay in 
transmitting the voice, by some combination of shaping and queuing.

---

From: "Stuart (Stu) Goldman" <[email-masked]>
Date: Thu, 18 Apr 2002 07:13:44 -0700

Fred,

I loved your "medical example" and I fully agree that the best defense for an
unexpected attack is to have many defense mechanisms available.

Fred Baker wrote:
snip