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

From: Pat Calhoun <[email-masked]>
Date: Tue, 30 Oct 2001 03:56:55 -0800

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: Tue, 30 Oct 2001 07:26:46 -0600

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.

---

From: Pat Calhoun <[email-masked]>
Date: Tue, 30 Oct 2001 08:24:53 -0800

> applications it supports.

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

PatC

---

From: "Kevin Purser" <[email-masked]>
Date: Tue, 30 Oct 2001 16:29:02 -0800

Submitter name: Kevin Purser
Submitter email address: [email-masked]
Date first submitted: 10/30/01
Reference: none
Document: Base-08-alpha
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 3.0 Diameter Header
Rationale/Explanation of issue:

On diameter servers which may utilize multiple (and potentially many)
processors, forcing the end-to-end identifier to be monotonically increased
by one for every message sent will probably cause scalability issues.  This
is due to the fact that this identifier would have to be in shared memory,
and would require mutually exclusive access amongst all processors in order
to update the value, thus slowing down all other diameter processes waiting
to send a message.

Requested change:
In the sentence below, remove the phrase "by incrementing the identifier by
one (1)."  After all, the method of ensuring the uniqueness of an identifer
is probably more of an implementation issue anyway, right?

Senders of request or answer messages MUST
      insert a unique identifier on each message, by incrementing the
      identifier by one (1).

---

From: Barney Wolff <[email-masked]>
Date: Wed, 31 Oct 2001 01:46:35 -0500

I cannot imagine any implementation where a single spinlock-protected
increment would even be measurable, so I'd urge rejection of this issue.
Do all these processors share a single transport connection?  If so,
there are many more accesses that need protection.  If not, you're
making scalability problems for your peer.

If you don't have shared memory, do the id assignment and increment in
the process that owns the transport.  Or allocate N id's per invocation.
I don't see a requirement here to actually transmit the messages in
id order.

-- 
Barney Wolff

"Nonetheless, ease and peace had left this people still curiously tough.
They were, if it came to it, difficult to daunt or to kill; and they were,
perhaps, so unwearyingly fond of good things not least because they could,
when put to it, do without them, and could survive rough handling by grief,
foe, or weather in a way that astonished those who did not know them well
and looked no further than their bellies and their well-fed faces." J.R.R.T.

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 31 Oct 2001 09:42:49 -0500

Hi Barney and Kevin,

I'd like to see this accepted, for the same reasons that Kevin stated, 
plus more.

This isn't actually a new issue.  Issue#93 is about the e-t-e
identifier.  I re-opened this issue in an email on 10-12-2001,
because I saw what I believe to be a flaw in the current draft
regarding e-t-e identifier.  I also requested that the
"increment by 1" requirement be removed.  There were a few
emails exchanged among Pat, Barney, Mark, and myself, but 
then the thread quietly died without resolution.

Here's a rehash of my thinking as to why the "increment by 1"
is unuseful and unnecessary:

The "increment by 1" requirement seems to be an over-specification which
imposes restrictions on the message originator's implementation, is
undetectable by the message's recipient, and doesn't benefit the
message's recipient.  The previous thread concluded that a receiver
could not make use of the "increment by 1".  Chiefly, a recipient may
receive an unordered and vanishingly small percentage of a client's
Diameter messages.

I was also thinking that the "increment by 1" might cause complications
for multi-process Diameter implementations.

For example, imagine a Diameter server implemented as three
communicating processes: The NASREQ application is one process.  The
Mobile-IP application is a second process.  And there is a third
lower-level process which handles the Diameter base protocol and the
TCP/SCTP connections.  When the NASREQ application or Mobile-IP
application originate a message, they pass it to the lower-level
process for transmission.

If there is an "increment by 1" rule, then the applications would
need to access some common "end-to-end-identifier allocator".  Or
the applications would have to let the lower-level transport process 
assign the end-to-end-identifier, but then the lower-level transport
process would have to return it to the application process.

If there wasn't an "increment by 1" rule, than each application
could manage its own end-to-end-identifier allocation, as long as it
didn't clash with the end-to-end-identifiers allocated by other
processes.  To ensure a non-clash in this example, the NASREQ
application could assign even-numbered end-to-end-identifiers, while
the Mobile-IP application could assign odd-numbered
end-to-end-identifiers.  In this case, then, each application would
be incrementing by two rather than one.

Bob K.

> From: [email-masked] on behalf of Barney Wolff
> [[email-masked]]
> Sent: Wednesday, October 31, 2001 1:47 AM
> To: [email-masked]
> Subject: Re: [AAA-WG]: New Issue: End to end identifier
> 

Bob K.

---

From: David Frascone <[email-masked]>
Date: Wed, 31 Oct 2001 08:59:25 -0600

I agree that it is an implementation issue.  I think "implementing by one"
should be removed and left up to the implementor.

---

From: Tony Johansson <[email-masked]>
Date: Wed, 31 Oct 2001 11:54:27 -0800

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

---

From: "Bob Kopacz" <[email-masked]>
Date: Wed, 31 Oct 2001 15:06:16 -0500

Hi Tony,

Here's what Don and I recall:

At the little round table discussion we had a couple days before Pat
came, we talked about two things when receiving a CER from an unknown peer:
1. silently dropping the connection, no response; or
2. respond with a negative stripped-down CEA, which doesn't reveal the
server's identity or supported applications, etc.

I think when Pat showed up, we talked about the silent discard and
the negative CEA, but don't think we talked about the negative
CEA being stripped down.

Bob K.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tony Johansson
> Sent: Wednesday, October 31, 2001 2:54 PM
> To: Pat Calhoun
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: Issue 204: How to handle CER from unkwown peer
>
>

---

From: David Frascone <[email-masked]>
Date: Wed, 31 Oct 2001 14:28:45 -0600

I thought we did, but I can live with not returning any extra information.