Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec

From: <[email-masked]>
Date: Tue, 19 Feb 2002 08:43:56 +0200

Hi David,

> I know that this is obviously what the IESG wants, but I don't think
> it's a very good idea.
> 
> The beauty of RADIUS was that it was light weight.  Forcing 
> all Diameter clients to support IPSEC just isn't going to happen.  Low 
> end devices probably won't even have the CPU to implement it.
> 
> I think adding this paragraph is going to keep all embedded 
> systems from implementing Diameter.  They'll just stick with RADIUS, 
> and force all Diameter servers to implement the RADIUS gateways.
> 
> IMHO, this is a VERY VERY bad "recommendation"

In version 8 of the base spec, the Section 2.2 reads:

 Diameter clients, such as Network Access Servers (NASes) and Mobility
 Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter
 servers MUST support TLS and IPSec. Operating the Diameter protocol without 
 any security mechanism is not recommended.

My text is adding nothing to this.  My text has increased the usage of TLS
from a MAY to a SHOULD.  Are you suggesting that it could be the otherway
around?  Such as IPsec is a SHOULD and TLS is a MUST?

thanks,
John

---

From: David Frascone <[email-masked]>
Date: Tue, 19 Feb 2002 08:20:29 -0600

Well, I've spent this morning searching the archive for my previous post
on this paragraph, but I guess I never made it.

I do have a problem with the MUST in version 8 of the draft too.  I think it
is too much to ask embedded systems to implement IPSEC or TLS.  

For some reason, I even remember a response to my complaint, where someone
said that small boxes would just use RADIUS. . . . guess I need more sleep :)

I prefer a SHOULD instead of the MUSTS for NAS's and Mobility Agents.

-Dave

---

From: Don Zick <[email-masked]>
Date: Tue, 19 Feb 2002 09:34:35 -0500

Hi Dave,
I'm concerned that allowing NASs and Mobility Agents to connect to Diameter
servers without requiring any security makes the Diameter server very vulnerable
to attack.  A Diameter server without security is easier to attack than a RADIUS
server that is at least protected by a shared secret.  I think the NASs and
Mobility Agents must provide at least some credentials before connecting to the
Diameter server.
Don

---

From: David Frascone <[email-masked]>
Date: Tue, 19 Feb 2002 08:45:08 -0600

For the most part, I agree with you.  In large setups, I agree 100%.

But, what about the NAS that's directly connected to a Diameter server
running NASREQ.  In a small singal POP ISP, that's what you have.  One
server, one NAS.  And, for most small ISPs, the NAS will be the cheapest
one they can find.  I just have a hard time believing that this econo-NAS
will have the resources to implement IPSEC.

I know we removed the CMS requirement from NAS's for this same reason.  How
much more lightweight is IPSEC than CMS?  

Why have a MUST for IPSEC, and a SHOULD for CMS (or is it a MAY?  I'm too
lazy to look)?  If a NAS has the ability to do IPSEC, I'll bet it could do
CMS too.

But, I'm not really concerned with the NAS's that *can* do IPSEC.  I'm worried
about the ones that *can't*.  And, with a MUST there, I'm concerned that 
small NAS vendors will just ignore Diameter completely (since they can't
support IPSEC), and stick with RADIUS.

Later,

-Dave

---

From: Johan Johansson <[email-masked]>
Date: Tue, 19 Feb 2002 16:46:02 +0100

Wouldn't that, assuming that insecure connections were allowed, be a 
policy decision that the contacted server would need to take whether to 
allow insecure connections or not based on the network topology? A 
mobility agent is a rather complicated beast and if you can put one of 
those together I think it's a reasonable assumption that it can be made 
to support TLS and/or IPsec. I don't know enough about NASes to have an 
informed opinion, but surely it is not entirely unreasonable to have a 
number of NASes talking to a local diameter server/proxy over dedicated 
lines?

Of course more security gives more room for flexibility when building 
the networks, but then again we are not talking about banning the use of 
security but whether it is feasible to mandate it for every single device.

j

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Feb 2002 06:57:10 -0800 (PST)

> much more lightweight is IPSEC than CMS?  

Not sure about the requirements for CMS, but the "lightweight" argument
was raised in IPS WG, and so we went about looking at implementation code
size. We were surprised that there are IKE implementations of 200
KB (pre-shared keys, minimal cert support). Since Diameter only requires
IPsec ESP with a non-null transform (say, 3DES), the total code is
sufficiently small that it is being implemented on NICs with non-volatile
storage of under 2 MB for everything. 

See draft-ietf-ips-security-09.txt for details on sizes of IKE
implementations.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 19 Feb 2002 06:58:29 -0800 (PST)

> allow insecure connections or not based on the network topology?

Well, we do need to be clear whether we are talking about mandatory to
implement or mandatory to use.