Re: [Dime] Remarks/Inquiries about rfc3588bis16 changes

[Victor Fajardo <vfajardo at tari.toshiba.com>]

Hi Jan,

> On Tuesday 2009-03-10 14:30, Victor Fajardo wrote:
>   
> > > |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?
> > >       
> > 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:
>   

It is not explicitly handled in v1 (rfc3588).

> 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.
>   

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.

>   
> > > |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?
> > >       
> > 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?
>   

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

>   
> > > |-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.
> > >       
> > 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?
>   

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