Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer

From: Steve Rich <[email-masked]>
Date: Thu, 1 Nov 2001 11:32:22 -0500

Hi, Tony.

I think that we did, indeed, decide this.

Thanks,
sjr

Tony Johansson writes:
 > Didn't we agree that some text should be added that state that a host
 > MAY silently discard a received CER with unknown host and disconnect,
 > without returning a CEA to prevent a malicious hacker to discover valid
 > Diameter server/client.
 > 
 > But my recollection may be wrong.
 > 
 > /Tony
 > 
 > Pat Calhoun wrote:
 > > 
 > > On Tue, Oct 30, 2001 at 07:26:46AM -0600, David Frascone wrote:
 > > > Also, the other avps should be optional.  A Diameter server would not want
 > > > to inform a malicious (unknown) host of it's version, or of all the
 > > > applications it supports.
 > > 
 > > and why? What is the damage caused by sending this information?
 > > 
 > > PatC
 > > >
 > > > On Tue, Oct 30, 2001 at 03:56:55AM -0800, Pat Calhoun wrote:
 > > > > All,
 > > > >
 > > > > Here is the proposed text to handle this issue:
 > > > >
 > > > > 5.3 Capabilities Exchange
 > > > >
 > > > > [...]
 > > > > Receipt of a CER from an unknown peer will cause the a CEA to be returned
 > > > > with the Result-Code set to DIAMETER_UNKNOWN_PEER. This result code is
 > > > > used to inform the peer that it has not been configured to communicate with
 > > > > the receiver, and doesn't wish to establish a Diameter session.
 > > > > [...]
 > > > >
 > > > > 7.1.5  Permanent Failures
 > > > >
 > > > > [...]
 > > > >       DIAMETER_UNKNOWN_PEER              5019
 > > > >          A CER was received from a peer that is unknown, and the sender of
 > > > >          the CEA doesn't wish to establish a Diameter transport.
 > > > >
 > > > > Comments welcomed,
 > > > >
 > > > > PatC
 >

---

From: David Frascone <[email-masked]>
Date: Thu, 1 Nov 2001 10:49:14 -0600

> and why? What is the damage caused by sending this information?

Well, if a malicious host knows that you are running version 1.75b of 
orginazation.com's Diameter server, which has a know race-condition or 
buffer overflow bug, then they know that they can exploit it.

It has become common for protocols to give as little information as possible
to connecting hosts.  Sendmail lines have gone from:

220 johnson.mail.mindspring.net ESMTP Sendmail 8.9.3/8.8.5; Thu, 1 Nov 2001 11:46:30 -0500 (EST)

. . . to . . .

220 frascone.com ESMTP

 . . . for security reasons.  The less information about your system you give
to a potentially malicious peer, the better.

Can you even remember the last time you were able to use "finger" to look
up someone's telephone number?

Just my $.02 worth,

Dave

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 1 Nov 2001 19:55:45 -0800

But I thought that we agreed that sending a CEA doesn't actually
provide any information that the malicious hacker couldn't otherwise
know.

PatC

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 1 Nov 2001 19:57:11 -0800

ah so I can buy Dave's point. So a stripped down CEA is probably a better
approach then.

PatC

---

From: David Frascone <[email-masked]>
Date: Fri, 2 Nov 2001 00:23:18 -0600

I was responding to the question about possible damages.

Sending a stripped down CEA is a better approach than the current one in
the draft (sending a full CEA)

Better yet is silently closing the connection.  (Just like tcpwrappers does.
Too bad it's not possible at the application layer to just ignore a host,
like you can with UDP)

So, my vote is for closing the connection w/o a response.

-Dave