Subject: [Dime] Remarks/Inquiries about rfc3588bis16 changes

From: Jan Engelhardt <[email-masked]>
Date: Tue, 10 Mar 2009 04:29:17 +0100 (CET)

Greetings!

I do have a few remarks and questions regarding the latest -bis16 update 
and the protocol in general.
Quoting bis16.

|page 11
|
|Deprecated the exchange of CER/CEA message in the open state.

What would happen if such an exchange in the open state produces no 
common applications -- terminate connection, or remain in the open state?

|page 46
|
|	DiameterIdentity = FQDN/Realm

Here, DiameterIdentity changed from FQDN to FQDN/Realm. One AVP where 
DiameterIdentity is used is Origin-Host. However, since there is already 
an AVP Origin-Realm which contais the realm, is it really necessary to 
add the realm again, to Origin-Host?

|page 117
|-bis15
|+bis16
|
|-abrubtly shutdown by comparing the old value of the Origin-State-Id
|+abrupbtly shutdown by comparing the old value of the Origin-State-Id

Third try, the correct spelling is:	abruptly

|-11.5. Diameter TCP/SCTP and TLS Port Numbers
|+11.5. Diameter TCP, SCTP and TLS/TCP Port Numbers

The TLS/TCP port number should then also be assigned for TLS/SCTP.

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 10 Mar 2009 09:30:57 -0400

Hi Jan,
> common applications -- terminate connection, or remain in the open state?

In this version of the base protocol, it is not expected that CER/CEA 
will be exchanged in the open state. It is one of the features in bis 
(diameter v2) that is not very backward compatible. Though a separate 
solution is in the works.

> add the realm again, to Origin-Host?

Hmm... the expansion of the context of DiameterIdentity does not include 
an assumption that concatenation of Origin-Host and Origin-Realm would 
form an FQDN. It is probably cleanest to keep Origin-Host as it is since 
there maybe future use cases where Origin-Host is re-used by itself, 
i.e. without any other realm avp accompanying it.

> Third try, the correct spelling is:	abruptly

Ok

> The TLS/TCP port number should then also be assigned for TLS/SCTP.

The new security changes does not support TLS/SCTP. We can clarify this.

regards,
victor

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>
>
>

---

From: Jan Engelhardt <[email-masked]>
Date: Tue, 10 Mar 2009 16:17:06 +0100 (CET)

On Tuesday 2009-03-10 14:30, Victor Fajardo wrote:
>> What would happen if such an exchange in the open state produces no common
>> applications -- terminate connection, or remain in the open state?
>
> In this version of the base protocol, it is not expected that CER/CEA will be
> exchanged in the open state. It is one of the features in bis (diameter v2)
> that is not very backward compatible. Though a separate solution is in the
> works.

Well the question (two actually) is: how was this handled in v1? And:
Consider the case where a broken v2 peer, or malicious v2 peer, issues
a CER in the open state to another v2, and what the non-evil peer should
be doing to keep security straight.

>> DiameterIdentity is used is Origin-Host. However, since there is already an
>> AVP Origin-Realm which contais the realm, is it really necessary to add the
>> realm again, to Origin-Host?
>
> Hmm... the expansion of the context of DiameterIdentity does not include an
> assumption that concatenation of Origin-Host and Origin-Realm would form an
> FQDN. It is probably cleanest to keep Origin-Host as it is since there maybe
> future use cases where Origin-Host is re-used by itself, i.e. without any other
> realm avp accompanying it.

Let me reword it: Should I append whatever has been determined to be
the value of Origin-Realm to the FQDN to obtain the DiameterIdentity
for Origin-Host when a peer creates new messages?

> The new security changes does not support TLS/SCTP. We can clarify this.

May I ask why it is that TLS over (single-substream) SCTP is not 
supported/specified?

Jan

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 09:45:17 -0700

> solution is in the works.

See
http://www.ietf.org/internet-drafts/draft-zorn-dime-capablities-update-00.tx
t; comments welcome!

...

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 10 Mar 2009 15:29:22 -0400

Hi Jan,

> Well the question (two actually) is: how was this handled in v1? And:

It is not explicitly handled in v1 (rfc3588).

> be doing to keep security straight.

that maybe a matter of policy. just like receiving any message that a 
node is not expecting. but we can always include provision in bis 
specifically for CER in v2 that disconnection is recommended in this case.

> for Origin-Host when a peer creates new messages?

short answer is no. there is no assumption such as this in diameter AFAIK.

> May I ask why it is that TLS over (single-substream) SCTP is not 

After two(2) diameter bake-offs and many years of on-and-off discussion 
... it would seem that SCTP support was never really "popular" in 
diameter implementations so it was decided that adding TLS/SCTP does not 
seem useful.

regards,
victor