Re: [Dime] rfc3588bis version number

[Stefan Winter <stefan.winter at restena.lu>]

Hi,

> The original plan for 3588bis was sound and is still required. IMO the decision to address TLS negotiation in bis knowing that the fix was not backwards compatible was our error. I vote we deprecate this feature in 3588bis, move the proposed solution to a new draft (Diameter v2 if required) and get 3588bis out the door.
>   

Deprecating what? Use of TLS altogether? IIRC, the use of IPSec is not
mandatory to implement any more in bis:


      2.2. Securing Diameter Messages



   Connections between Diameter peers SHOULD be protected by TLS.  All
   Diameter base protocol implementations MUST support the use of TLS.
   If desired, alternative security mechanisms that are independent of
   Diameter, such as IPsec [RFC4301 <http://tools.ietf.org/html/rfc4301>], can be deployed to secure
   connections between peers.  The Diameter protocol MUST NOT be used
   without any security mechanism.


So, with TLS being deprecated and IPsec being optional, one can not be
sure to have *any* interoperable security profile. A suggestion to
deprecate TLS would have to make IPSec mandatory again.

NB: There's a superfluous condition in 2.1, the wording could be cleared:

When connecting to a peer and either zero or more transports are
   specified, TCP SHOULD be tried first, followed by SCTP.  See Section
   5.2 for more information on peer discovery.


"either zero or more transports are specified" : this condition always
evaluates to TRUE. You cannot by definition define a negative amount of
transports. The sentence can be shortened to:

When connecting to a peer, TCP SHOULD be tried first, followed by SCTP.  See Section
   5.2 for more information on peer discovery.


Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473