Subject: [Dime] rfc3588bis version number

From: Victor Fajardo <[email-masked]>
Date: Wed, 01 Apr 2009 12:18:10 -0400

As noted in IETF74, there were concerns on incrementing the version 
number for rfc3588bis. The latest rev of the bis draft has the diameter 
header version number set to 2. The main reason for incrementing the 
version number are the following non-backward compatible fixes/changes 
in bis:

* TLS negotiation are no longer done within the context of CER/CEA. TLS 
connectivity is now established prior to any diameter traffic via a well 
known port.

* Capabilities exchange in the open state is no longer supported.

The concerns folks have raised for incrementing the version number in 
bis are as follows (pls correct me if I mis-state some of these issues 
or if I miss some issues):

* The version increment was very sudden and seems to have been done 
without much discussion. The current changes in bis can be classified 
into either clarifications and bug fixes (the changes above are 
included). Both types of changes does not warrant a  version increment 
given that no new significant feature is being introduced beyond these 
two types.

* The changes above that triggered discussion of version increment are 
considered critical "bug fixes" anyway. The fixes should be considered 
as "updates/patches" that would require code change regardless since it 
leaves certain features of the original 3588 broken, un-secure or 
inter-operable. An incremental approach is better: i.e., bis as a patch 
and a new separate document as 3588 version 2.

* Some clarifications may require code changes for some vendors 
(although care was always been taken to advertised proposed solutions on 
the list so this should be rare) but the code changes would have been 
required anyway for successful interop.

* If the version number is incremented, it would be unclear what RFC3588 
state would be. Whether the new version would deprecate 3588 or it would 
be a completely separate branch/track that's very similar yet slightly 
different from 3588. It creates more ambigouity and does not seem to 
warrant a version increment as well.

* Using bis to create a new revision of Diameter will open it up to 
addition of new features that can further delay publication of needed 
bug fixes and clarifications.

A possible middle-ground is to keep to the intent of bis as a bug fixing 
instrument and keep bis as version 1. With regards to the changes above:

* The version number in the diamter header may not help the TLS 
negotiation anyway because we only see the version number after the 
first diameter message. So a bis implementation and an original 3588 may 
not be able to inter operate regardless of whether the version number is 
reved-up.

* The capabilities exchange in 3588 was never really clearly specified 
(only hinted on in the statemachine). One possible solution is to keep 
the open-state capabilities exchange in bis have it as a "NO OP" process 
just to make it backward compatible with 3588. Then make sure we state 
this is clearly stated and that we intend to rely on 
draft-zorn-dime-capablities-update-00.txt 
<http://www.ietf.org/internet-drafts/draft-zorn-dime-capablities-update-00.txt> 
in the future. Other possible approaches are welcomed.

Comments appreciated.

regards,
victor

---

From: <[email-masked]>
Date: Wed, 1 Apr 2009 23:52:00 +0200

Hi Victor,

Thanks for the good summary of the discussion!

I can just re-assess what I said during the meeting.

In my understanding, the current scope of the work was "limited" to fix bugs and clarify procedures/texts in the existing RFC 3588 (along with Diameter application design guidelines draft).
It was not foreseen to add "new features" to the set of Diameter base protocol functionalities and backward compatibility was THE leitmotiv. For example, some "proposed improvments" was recently rejected because of non-backward compatibility issues.

If there are issues that are required to be fixed in a way that is not backward compatible with current Diameter base implementations, I think that the rationale to accept them is that they are actually "issues"! IMHO, solving issues takes precedence over keeping unchanged something wrong...

But this is not a reason to change the version. It is a reason to update the specification of the current version. Without these changes, the current implementation is just "incomplete" or "unstable" or "whatever": these solutions should be deemed required.

IETF, 3GPP, Wimax and other SDOs, as well as vendors are waiting for this RFC 3588bis document for a while. We cannot take the liberty of delaying again the publication of this document. And it is too late to open a discussion on a v2 version, starting with a clear definition of the new scope of the functional requirements and a clear version negociation handling at the Diameter base protocol level.

Whatever the final position taken about the issues and the proposed solutions, the final document should describe the (new) recommended implementation of the Diameter base protocol (i.e. v1).

For the two current issues/solutions, I would recommend to use separate threads, in order to separate the discussions: version number, TLS negociation and Capabilities Exchange.

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Victor Fajardo
> Envoyé : mercredi 1 avril 2009 18:18
> À : [email-masked]
> Objet : [Dime] rfc3588bis version number
> 
> As noted in IETF74, there were concerns on incrementing the 
> version number for rfc3588bis. The latest rev of the bis 
> draft has the diameter header version number set to 2. The 
> main reason for incrementing the version number are the 
> following non-backward compatible fixes/changes in bis:
> 
> * TLS negotiation are no longer done within the context of 
> CER/CEA. TLS connectivity is now established prior to any 
> diameter traffic via a well known port.
> 
> The concerns folks have raised for incrementing the version 
> number in bis are as follows (pls correct me if I mis-state 
> some of these issues or if I miss some issues):
> 
> * The version increment was very sudden and seems to have 
> been done without much discussion. The current changes in bis 
> can be classified into either clarifications and bug fixes 
> (the changes above are included). Both types of changes does 
> not warrant a  version increment given that no new 
> significant feature is being introduced beyond these two types.
> 
> * The changes above that triggered discussion of version 
> increment are considered critical "bug fixes" anyway. The 
> fixes should be considered as "updates/patches" that would 
> require code change regardless since it leaves certain 
> features of the original 3588 broken, un-secure or 
> inter-operable. An incremental approach is better: i.e., bis 
> as a patch and a new separate document as 3588 version 2.
> 
> * Some clarifications may require code changes for some 
> vendors (although care was always been taken to advertised 
> proposed solutions on the list so this should be rare) but 
> the code changes would have been required anyway for 
> successful interop.
> 
> * If the version number is incremented, it would be unclear 
> what RFC3588 state would be. Whether the new version would 
> deprecate 3588 or it would be a completely separate 
> branch/track that's very similar yet slightly different from 
> 3588. It creates more ambigouity and does not seem to warrant 
> a version increment as well.
> 
> * Using bis to create a new revision of Diameter will open it 
> up to addition of new features that can further delay 
> publication of needed bug fixes and clarifications.
> 
> A possible middle-ground is to keep to the intent of bis as a 
> bug fixing instrument and keep bis as version 1. With regards 
> to the changes above:
> 
> * The version number in the diamter header may not help the 
> TLS negotiation anyway because we only see the version number 
> after the first diameter message. So a bis implementation and 
> an original 3588 may not be able to inter operate regardless 
> of whether the version number is reved-up.
> 
> * The capabilities exchange in 3588 was never really clearly 
> specified (only hinted on in the statemachine). One possible 
> solution is to keep the open-state capabilities exchange in 
> bis have it as a "NO OP" process just to make it backward 
> compatible with 3588. Then make sure we state this is clearly 
> stated and that we intend to rely on 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 02 Apr 2009 10:02:54 +0900

Hello all,

I would like to comment on this "version 2" change.

 I think that incrementing the version number in the header does not
mean we have to redesign and improve the whole protocol. It does not
mean a "major update". It is simply a hint for implementations
indicating what behavior is expected (state machine, ...)

>> of whether the version number is reved-up.
This is true for some situations, but there are also cases where a
different version number would be very useful for an implementation that
tries to be compatible with both specifications.

On a technical point of view, changing the version number in the code is
a trivial change, especially compared with all the other changes that
are in the "bis" document. I don't see a reason why an implementor would
complain about having to do this change on the version number -- if they
are willing to deploy the changes from this revision, at least. On the
contrary, on a marketing point of view, "We support Diameter 2" is more
attractive IMO :)

In any case, we will have to distinguish between the original Diameter
or the revised version. Talking about "version 1" and "version 2" is
more convenient and less error-prone.
In my opinion, not incrementing the version number will add even more
complexity to the protocol and implementations, leading to even less
people understanding it and wanting to use it...

Thank you for reading.

Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 2 Apr 2009 10:10:21 +0200

Hi,

 I second lionel's comments. I thought this version Bis was about
correcting bugs and clarify some process and not about adding new
functionalities to the protocol.

 So, I would prefer to stick with Version 1 in the header.

 Regards,

 Julien

---

From: <[email-masked]>
Date: Thu, 2 Apr 2009 11:55:41 +0200

Diameter is not anymore only an academic topic as we used to hear in the recent past.
There are existing implementations running the Diameter base protocol and "introducing" a new version of the protocol is not as simple as just incrementing only the value of the version field in the message header. If a v2 is created, what should we do with existing v1 implementations? Upgrade any Diameter existing implementation to v2? Any v2 implementation will have to support both v1 and v2? And so on...

Recent discussions in other fora about version handling for different protocols (including protocols based on Diameter applications for instance) showed that issues with versioning and interworking are often reasons good enough to be stuck with the previous version and postpone (forever?) the migration to the new version. At this stage, what it is required is not a new version of the protocol. It is just a version of the protocol that is good enough to remove any existing open issue with the current specification. Having a new document describing the correct implementation of the Diameter base protocol doesn't require a v2. The new document can just make obsolete the previous document.

And again, going for a v2 without a clear pre-existing requirement definition phase and deciding the version update at the latest stage would be counterproductive and an open door for a v3 discussion, even maybe before the effective deployment of the v2, without collecting feedback from the operational field. Having a long-term stable base protocol should be our goal, to ensure a successful deployment of any application running on top of the base protocol. Especially for a protocol used over interfaces between different administrative domains.

BR,

Lionel

> la part de Sebastien Decugis
> Envoyé : jeudi 2 avril 2009 03:03
> À : [email-masked]
> Objet : Re: [Dime] rfc3588bis version number
> 
> Hello all,
> 
>  I think that incrementing the version number in the header 
> does not mean we have to redesign and improve the whole 
> protocol. It does not mean a "major update". It is simply a 
> hint for implementations indicating what behavior is expected 
> (state machine, ...)
> 
> >> first diameter message. So a bis implementation and an 
> original 3588 
> >> may not be able to inter operate regardless of whether the version 
> >> number is reved-up.
> >>     
> This is true for some situations, but there are also cases 
> where a different version number would be very useful for an 
> implementation that tries to be compatible with both specifications.
> 
> On a technical point of view, changing the version number in 
> the code is a trivial change, especially compared with all 
> the other changes that are in the "bis" document. I don't see 
> a reason why an implementor would complain about having to do 
> this change on the version number -- if they are willing to 
> deploy the changes from this revision, at least. On the 
> contrary, on a marketing point of view, "We support Diameter 
> 2" is more attractive IMO :)
> 
> In any case, we will have to distinguish between the original 
> Diameter or the revised version. Talking about "version 1" 
> and "version 2" is more convenient and less error-prone.
> In my opinion, not incrementing the version number will add 
> even more complexity to the protocol and implementations, 
> leading to even less people understanding it and wanting to use it...
> 
> Thank you for reading.
> 
> Sebastien.
> 
> --
> Sebastien Decugis
> Research fellow

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 02 Apr 2009 09:04:08 -0400

Hi Sebastien,

> indicating what behavior is expected (state machine, ...)

I guess it's really a question of what the version number in the header 
indicates. So far, its the opinion of most folks that the version number 
means ONLY "major update and/or new significant features" and bis is 
merely an update/patch to an existing version.

> tries to be compatible with both specifications.

Typically yes. But 1) we should confine ourselves to the changes in bis 
because those are the only changes that exist/relevant. 2) If bis is 
treated as fix/patch to problems that renders certain features in 3588 
as non-interoperable then why would an implementation need to support 
both version ?

regards,
victor

---

From: Mark Jones <[email-masked]>
Date: Thu, 2 Apr 2009 09:22:43 -0400

I agree with Victor's summary and the conclusion to keep 3588bis at version 1. I am not against adding a Diameter v2 work item to the charter but this was clearly not the intent for 3588bis. The 3588bis was started was started over 2 years ago and we made lots of compromises in how we addressed 3588 issues in order to ensure backwards compatibility. If we'd wanted a v2, we would have tackled those issues differently.

In addition, 3588bis is needed immediately to guide implementors towards a successful interop of v1. Moving to v2 now effectively orphans v1 just when other SDOs are completing specifications of their Diameter-based applications and operators are planning deployments.

Regards
Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Victor Fajardo
> Sent: April 1, 2009 12:18 PM
> To: [email-masked]
> Subject: [Dime] rfc3588bis version number
> 
> CER/CEA. TLS 
> increment are 
> as a patch 
> what RFC3588 
> bug fixing 
> original 3588 may 
> specified

---

From: Avi Lior <[email-masked]>
Date: Thu, 2 Apr 2009 14:33:48 -0400

The summary correctly captures the discussion.

I support keeping 3588bis at version 1. 

I would support adding a Diameter v2 work item to the charter.

Furthermore, we should identify the areas that need to be enhanced by way of problem statements into a single draft or a set of drafts.

A design team or teams should then tackle the solutions space.

Avi

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 03 Apr 2009 11:15:20 +0900

Hi,

> I guess it's really a question of what the version number in the
> header indicates. So far, its the opinion of most folks that the
> version number means ONLY "major update and/or new significant
> features" and bis is merely an update/patch to an existing version.
Well, what about calling it "version 1.1" in the draft and changing the
header field to some stupid value like 0x11 ? Would it release the
psychologic barrier ? :)

>
> Typically yes. But 1) we should confine ourselves to the changes in
> bis because those are the only changes that exist/relevant. 2) If bis
> is treated as fix/patch to problems that renders certain features in
> 3588 as non-interoperable then why would an implementation need to
> support both version ?
As pointed out by Lionel, we need to support both versions *because*
equipment already exist and is deployed that implement the original
3588. What do you do when you have to equipments bought at different
times, that support the same protocol, and that are unable to
interoperate? Especially in the case of several administrative domains...

To me, not changing the version number in the header will lead to a lot
more problems than changing it.

I am now starting to deploy Diameter in an academic environment. I plan
to use the revised version of the protocol. Then I will interconnect
this as much as possible with other organizations. If these
organizations already run a Diameter infrastructure, they will very
likely implement the original RFC. How is it possible to interconnect
with them?

Best regards,
Sebastien.

---

From: Sebastien Decugis <[email-masked]>
Date: Fri, 03 Apr 2009 11:29:36 +0900

Hi Lionel,

> There are existing implementations running the Diameter base protocol and "introducing" a new version of the protocol is not as simple as just incrementing only the value of the version field in th…
How is it different with the bis version? Regardless of the header in
the message, we *are* introducing a new version of the protocol, since
it is not interoperable with original RFC3588. The exact same questions
apply. At least by bumping the version number, the situation is easier
to manage, IMHO.

> Recent discussions in other fora about version handling for different protocols (including protocols based on Diameter applications for instance) showed that issues with versioning and interworking…
Ok, you obsolete the original document. What about existing
implementations of this original document?

> And again, going for a v2 without a clear pre-existing requirement definition phase and deciding the version update at the latest stage would be counterproductive and an open door for a v3 discussi…
Now, if 3588 and 3588bis protocols *were* interoperable, I totally
support that we should not bump the version number and save the
not-interoperable changes to a v2 version later, following the whole
clean process.

I guess I did not make my point very clear. What I want to enforce is
that if we are introducing changes that make original and revised RFCs
not interoperable, then the version number MUST be bumped. I have no
problem with saving these changes for a future revision (a real v2) and
going with an interoperable version in rfc3588bis. I think this is the
reasonable approach that everyone supports in the WG.

Best regards,
Sebastien.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 03 Apr 2009 08:14:39 +0200

Hi,

> apply. At least by bumping the version number, the situation is easier
[...]
> reasonable approach that everyone supports in the WG.

I fully support Sebastien. If bis is not given a new version number,
there are different protocols in the wild which claim to be the very
same protocol. These protocols are not interoperable with each other,
and their differences are subtle. I suspect implementation nightmares
dead ahead.

I acknowledge that it's a pity that the plan not to introduce
incompatible changes in bis couldn't be upheld. But regardless of that:
these *are* two different protocols, and they *really really should* be
easily distinguishable from each other.

Giving bis the version number 2 doesn't at all prevent future
backwards-incompatible cleanups (those that were rejected earlier for
bis, and others) from happening: such a revision simply can get version
3. The Version field is 8 bits - It's not like we're running short of
integers.

Greetings,

Stefan Winter

P.S.: Why am I reminded of the subtle differences of MS-CHAPv2 in
EAP-FAST vs. elsewhere, and the confusion and fuss that was generated by
the two having the same EAP type. I'd prefer things like that not to
happen yet another time.

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

---

From: <[email-masked]>
Date: Fri, 3 Apr 2009 14:48:12 +0200

Hi Stephan, Sebastien,

The proposed changes are there BECAUSE there are issues with the current Diameter implementation. What you are saying is that the RFC3588 would remain with open issues (from the standard point of view) that would be fixed by some vendor-specific solutions in the operational network or not solved at all. So basically, how will the interoperatbility with a v1 implementation be properly ensured if you don't even know how excatly the remote v1 AAA entity behave?

I prefer to find some texts saying:
"sorry guys! Some mistakes were present in the first edition of the spec and here is the correct version of the specification, with the correct implementation!"

Instead of something like:
"The RFC3588 had some problems and a new version was created. But of course, you can still use the old version version and you are free to interwork with" 

The industry and other fora uses to handle protocol issues in that way. The version update is not the ONLY solution to fix protocol issues. Version update is always consider a carefully thought-out plan and a last resort solution.

BR,

Lionel

> De : Stefan Winter [mailto:[email-masked]] 
> Envoyé : vendredi 3 avril 2009 08:15
> À : Sebastien Decugis
> Cc : MORAND Lionel RD-CORE-ISS; [email-masked]
> > it is not interoperable with original RFC3588. The exact same 
> > questions apply. At least by bumping the version number, 
> the situation 
> > is easier to manage, IMHO.
> >   
> [...]
> > problem with saving these changes for a future revision (a real v2) 
> > and going with an interoperable version in rfc3588bis. I 
> think this is 
> > the reasonable approach that everyone supports in the WG.
> >   
> 
> I fully support Sebastien. If bis is not given a new version 
> number, there are different protocols in the wild which claim 
> to be the very same protocol. These protocols are not 
> interoperable with each other, and their differences are 
> subtle. I suspect implementation nightmares dead ahead.
> 
> these *are* two different protocols, and they *really really 
> should* be easily distinguishable from each other.
> 
> backwards-incompatible cleanups (those that were rejected 
> earlier for bis, and others) from happening: such a revision 
> simply can get version 3. The Version field is 8 bits - It's 
> not like we're running short of integers.
> 
> Greetings,
> 
> Stefan Winter
> 
> P.S.: Why am I reminded of the subtle differences of 
> MS-CHAPv2 in EAP-FAST vs. elsewhere, and the confusion and 
> fuss that was generated by the two having the same EAP type. 
> I'd prefer things like that not to happen yet another time.
> 
> --
> 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
> 
>

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 03 Apr 2009 09:34:09 -0400

Hi Sebastien,

> header field to some stupid value like 0x11 ? Would it release the

Hmmm ... I think we are really diverging from the core point of the 
discussion and the closure that I want to come to. So, pls see my 
comments below.

> interoperate? Especially in the case of several administrative domains...

I think that point is already obvious to anyone, right ? :) The point 
I'm trying to make is based on item (1) below. But I guess that is still 
not clear at this point :) ... so to re-iterate one more time, the 
options are:

1. Keep the old version number (v1) and revert/fix the changes that made 
bis non-interoperable with 3588. This keeps bis within the context of 
being a bug fix/patch instrument. This is why those changes were 
enumerated in the summary ... so if we choose this option then I think 
it is better on commenting on how to revert/fix the new changes instead 
of focusing on why the version number was invented. The reasons for 
going this directions are those enumerated on the summary.

2. Rev-up the version number to v2. We're free to make any changes we 
want but with the current state of bis and the dependencies of other 
work on that document, we really have to consider if this is a good 
approach at this point. Again, see the summary.

So, lets focus the discussion on these and hopefully we can come to a 
quick conclusion.

-- victor

---

From: Mark Jones <[email-masked]>
Date: Fri, 3 Apr 2009 10:24:45 -0400

> and their differences are subtle. I suspect implementation nightmares

Version 1 is already out in the wild and two independent implementations of RFC3588 may not interoperate. So we spent 18 months on bug fixes in 3588bis to greatly improve the odds that they can interoperate. Implementers finding contradictions or ambiguities in RFC3588 have been able to turn to 3588bis for clarification. Throughout that time Victor was strict in enforcing solutions that were backwards compatible.

Recently we discover two issues (TLS negotiation and capabilities update) and find we can not fix them without breaking backwards compatibility. Given that no one noticed these problems until now, I strongly suspect these are not critical features of the Diameter base protocol. For Capabilities Update, we chose to deprecate the feature in bis rather than fix it and Glen captured a solution in a separate draft. If offered the choice at that point, I believe the majority of delegates would have been preferred a similar approach for TLS negotiation rather than bump the version.

> easily distinguishable from each other.

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.

Regards
Mark

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 06 Apr 2009 10:19:55 +0900

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 deprecat…
This sounds reasonable to me, and I support this approach.

Although this issue with TLS *is* a security vulnerability and should
result in the Diameter protocol version 1 be deprecated quite soon to
the benefit of a secure version 2...

Best regards,
Sebastien.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 7 Apr 2009 09:54:06 +0300

Hi,

I fully agree what Mark said here. (Originally, I was for v2 but after  
some more thoughts, I think it was a premature conclusion).

Cheers,
	Jouni

On Apr 3, 2009, at 5:24 PM, Mark Jones wrote:

> Version 1 is already out in the wild and two independent  
> implementations of RFC3588 may not interoperate. So we spent 18  
> months on bug fixes in 3588bis to greatly improve the odds that they  
> can interoperate. Implementers finding contradictions or ambiguities  
> in RFC3588 have been able to turn to 3588bis for clarification.  
> Throughout that time Victor was strict in enforcing solutions that  
> were backwards compatible.
>
> Recently we discover two issues (TLS negotiation and capabilities  
> update) and find we can not fix them without breaking backwards  
> compatibility. Given that no one noticed these problems until now, I  
> strongly suspect these are not critical features of the Diameter  
> base protocol. For Capabilities Update, we chose to deprecate the  
> feature in bis rather than fix it and Glen captured a solution in a  
> separate draft. If offered the choice at that point, I believe the  
> majority of delegates would have been preferred a similar approach  
> for TLS negotiation rather than bump the version.
>
> 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.
>
> Regards
> Mark

---

From: Stefan Winter <[email-masked]>
Date: Tue, 07 Apr 2009 09:18:46 +0200

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 deprecat…

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

Tel: +352 424409 1
Fax: +352 422473

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 16 Apr 2009 10:53:39 -0400

If there are no more comments/objections/opinions, we will incorporate 
Mark's proposal into the next rev of bis. Here's a summary:

* Capabilities update will be kept in bis for backward compatibility but 
will be considered a 'noop' and text will be added that this feature is 
deprecated and that future work will properly cover this functionality.

* Fixes to TLS negotiation will be rolled back to retain backward 
compatibility but strong language regarding its vulnerability will be 
added. Additional text noting that fixes to this issue will be done in 
the new revision of diameter will be introduced.

regards,
victor

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 09:37:23 +0200

I can live with this proposal.

But I would definitly prefer to fix in this version existing issues that cause anyway interoperability or vulnerability problem.
There is no shame to say: "Sorry, we messed up!". And we can do it without changing the version number. Fixing bugs is something inherent to a protocol live cycle and this Bis version could be one them for Diameter. Increasing the version number should be reserved for functional protocol updates. Just "my humble opinion"...

BR,

Lionel

> Envoyé : jeudi 16 avril 2009 16:54
> À : [email-masked]
> If there are no more comments/objections/opinions, we will 
> incorporate Mark's proposal into the next rev of bis. Here's 
> a summary:
> 
> * Capabilities update will be kept in bis for backward 
> compatibility but will be considered a 'noop' and text will 
> be added that this feature is deprecated and that future work 
> will properly cover this functionality.
> 
> * Fixes to TLS negotiation will be rolled back to retain 
> backward compatibility but strong language regarding its 
> vulnerability will be added. Additional text noting that 
> fixes to this issue will be done in the new revision of 
> diameter will be introduced.
> 
> regards,
> victor
> 
> implementations of RFC3588 may not interoperate. So we spent 
> 18 months on bug fixes in 3588bis to greatly improve the odds 
> that they can interoperate. Implementers finding 
> contradictions or ambiguities in RFC3588 have been able to 
> turn to 3588bis for clarification. Throughout that time 
> Victor was strict in enforcing solutions that were backwards 
> compatible.
> >
> > Recently we discover two issues (TLS negotiation and 
> capabilities update) and find we can not fix them without 
> breaking backwards compatibility. Given that no one noticed 
> these problems until now, I strongly suspect these are not 
> critical features of the Diameter base protocol. For 
> Capabilities Update, we chose to deprecate the feature in bis 
> rather than fix it and Glen captured a solution in a separate 
> draft. If offered the choice at that point, I believe the 
> majority of delegates would have been preferred a similar 
> approach for TLS negotiation rather than bump the version.
> >
> >   
> > 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.
> >
> > Regards
> > Mark

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 17 Apr 2009 14:38:59 +0700

> the new revision of diameter will be introduced.

If these are really the only two problems, is such a drastic approach really
necessary?  It seems to me that the problems could be fairly easily solved
with appropriate weasel-wording - no, I mean clever usage of standards
language ;-).  For example, something like 

Implementations MAY {old way of doing X}; however, implementations SHOULD
{new way of doing X.

If one way or the other is required, say so w/a MUST.  Doesn't this work?

> implementations of RFC3588 may not interoperate. So we spent 18 months
> on bug fixes in 3588bis to greatly improve the odds that they can
> interoperate. Implementers finding contradictions or ambiguities in
> RFC3588 have been able to turn to 3588bis for clarification. Throughout
> that time Victor was strict in enforcing solutions that were backwards
> compatible.
> >
> strongly suspect these are not critical features of the Diameter base
> protocol. For Capabilities Update, we chose to deprecate the feature in
> bis rather than fix it and Glen captured a solution in a separate
> draft. If offered the choice at that point, I believe the majority of
> delegates would have been preferred a similar approach for TLS
> negotiation rather than bump the version.
> >
> >
> 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.
> >
> > Regards
> > Mark

---

From: <[email-masked]>
Date: Fri, 17 Apr 2009 10:53:09 +0200

> la part de Glen Zorn
> Envoyé : vendredi 17 avril 2009 09:39
> À : 'Victor Fajardo'; [email-masked]
> incorporate 
> compatibility 
> > but will be considered a 'noop' and text will be added that this 
> > feature is deprecated and that future work will properly cover this 
> > functionality.
> > 
> If these are really the only two problems, is such a drastic 
> approach really necessary?  It seems to me that the problems 
> could be fairly easily solved with appropriate weasel-wording 
> - no, I mean clever usage of standards language ;-).  For 
> example, something like 
> 
> Implementations MAY {old way of doing X}; however, 
> implementations SHOULD {new way of doing X.
> 

If keeping track of the previous way of doing is something foreseen, I would go for this approach.

I was assuming that having a new RFC number obsoleting the previous one had the same purpose. It is a hint for vendors for checking what should be fixed in their pre-existing Diameter implementation and up to them to do the necessary changes. And the Diameter vendor newbees, they are not bothered by "old stuff". At least, it was the way of doing for MIPv4 for instance that has been be updated something like four times, a standard solution without any version number...

Lionel

> > >> number, there are different protocols in the wild which 
> claim to be 
> > >> the very same protocol. These protocols are not 
> interoperable with 
> > >> each
> > other,
> > RFC3588 have been able to turn to 3588bis for clarification. 
> > protocol. For Capabilities Update, we chose to deprecate 
> the feature 
> > in bis rather than fix it and Glen captured a solution in a 
> separate 
> majority of 
> > >> incompatible changes in bis couldn't be upheld. But 
> regardless of 
> > >> that:
> > (Diameter

---

From: Victor Fajardo <[email-masked]>
Date: Fri, 17 Apr 2009 08:59:03 -0400

Hi,

> If keeping track of the previous way of doing is something foreseen, I would go for this approach.

I don't mind going with Glen's approach. It would work in our give case. 
Any other thoughts ?

-- victor

>>>>> and their differences are subtle. I suspect implementation
>>>>>           
>>> nightmares
>>>       
>>>>> dead ahead.
>>>>>
>>>>>
>>>>>           
>>> implementations of RFC3588 may not interoperate. So we 
>>>       
>> spent 18 months 
>>     
>>> compatibility. Given that no one noticed these problems 
>>>       
>> until now, I 
>>     
>>> strongly suspect these are not critical features of the 
>>>       
>> Diameter base 
>>     
>>> was not backwards compatible was our error. I vote we 
>>>       
>> deprecate this 
>>

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 20 Apr 2009 10:43:54 +0900

>
> I don't mind going with Glen's approach. It would work in our give
> case. Any other thoughts ?
Hi,

In my humble opinion, saying that an implementation MAY do A, but SHOULD
do B, when A and B are contradictory, is equivalent to saying nothing at
all. So basically you end up not specifying how TLS should be handled,
which is very not what I would expect from the spec...

My 2 cents
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Apr 2009 11:12:14 +0700

Sebastien Decugis [mailto://[email-masked]] writes

> all. 

Are you saying that "SHOULD" and "MAY" are equivalent, then?

> So basically you end up not specifying how TLS should be handled,

I don't understand: in actual point of fact, that is exactly what we are
saying...

...

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 20 Apr 2009 13:55:45 +0900

> Are you saying that "SHOULD" and "MAY" are equivalent, then?

No, I mean that the implementation can do A or B and claim to be
conformant; i.e. the specification does not restrict the possibilities.
In our case, a new implementation would do B since it's a SHOULD, but an
existing implementation that already do A will not need to be modified
to claim conformance.

Hence my conclusion...

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Apr 2009 13:43:10 +0700

> existing implementation that already do A will not need to be modified

I'm still not seeing the problem: that seems to me to be pretty much the
definition of "backward compatibility" ;-).  As long as both ways work, it
shouldn't matter WRT interoperability & hopefully, legacy implementations
would upgrade over time; in any case, v2 could deprecate the old behavior.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 20 Apr 2009 16:07:00 +0900

> would upgrade over time; in any case, v2 could deprecate the old behavior.
I'd say "backward compatibility" if an implementation that supports
Diameter v2 can also support v1.
Since we are not changing the version number, it is very difficult for
the implementation to determine if it is running in "old" or "new"
Diameter.
I think that we *will* end up with different implementations of Diameter
that are not able to talk together... Which I'd like to avoid, at least
at the specification step.

Of course I may be missing experience here, I'm just talking from my
implementation point of view...

Thank you for your patience ^_^

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Apr 2009 14:41:14 +0700

> the implementation to determine if it is running in "old" or "new"

This is how I think that it would work:

For TLS, it's pretty easy: if the peer connected to you on the new "special"
port, then TLS is already active; otherwise, you start it the old way.
For CER/CEA in the open state, it's not that bad, either, if we leave
Capabilities Update as a separate application.

Of course, since we're not taking anything out, new implementations would
have to support the old way of doing things (which implies that my
quick-and-dirty standards language mock-up might not be completely correct,
but I still think it may be doable...

> that are not able to talk together... 

I'd be very surprised if that wasn't true in any case.

> Which I'd like to avoid, at least

I would prefer to increment the version number, too; I'm just trying to
break the log jam here.

---

From: Sebastien Decugis <[email-masked]>
Date: Mon, 20 Apr 2009 17:01:28 +0900

[...]

Well, if the bis describes how to handle the interoperability with
"pure" rfc3588, and the solution is not very very dirty, then I'd agree
for this type of solution ^^
But I'd prefer to see the actual description, before saying it's
possible... To me it looks complex, especially for the initiator's side.

>> I think that we *will* end up with different implementations of
But if at least we don't know it before releasing the new specification,
it's better... Isn't it? ^^'

> I would prefer to increment the version number, too; I'm just trying to
Well, not pushing the change to TLS into the Bis version seemed a good
approach to me.
If the implementation must be backward-compatible with 3588, it will
remain open to the security vulnerability anyway...

I'd also rather see a *clean* version 2 where this vulnerability is
fixed; even if this version comes later with a new re-chartering or
i-don-t-know-what process to fix a vulnerability....

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Apr 2009 15:26:38 +0700

> possible... To me it looks complex, especially for the initiator's

Let's just take TLS, for simplicity's sake.  The old and new ways use two
different ports, right?  As long as an implementation knows which of the two
the connection came in on, it knows what to do (or not to do), right?  On
the initiator side, a new implementation would try the special port first
(because it's a "SHOULD") & if no answer then fall back to the old way
(because it's a "MAY", though we can specify this behavior more precisely).
That sounds fairly simple to me.  If we leave capabilities update as a
separate app, then we don't have to worry about that for bis.

...

> remain open to the security vulnerability anyway...

Not unless it actually practices the old way.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 20 Apr 2009 15:56:53 +0700

Sorry, I didn't realize that I had said "right?" twice in two sentences ;-)
-- reading it, it sounds a little confrontational which was not my intent.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Glen Zorn
> Sent: Monday, April 20, 2009 3:27 PM
> To: 'Sebastien Decugis'
> Cc: [email-masked]
> Subject: Re: [Dime] [SPAM] RE: rfc3588bis version number
> 
> > > I would prefer to increment the version number, too; I'm just
> trying
> > to
> > > break the log jam here.
> > >

---

From: Sebastien Decugis <[email-masked]>
Date: Tue, 21 Apr 2009 10:17:36 +0900

Hello again,
> On
> That sounds fairly simple to me. 
So the initiator has to try two protocols (SCTP, TCP) and two ports
(legacy, new TLS) when attempting a new connection... I would not call
this "fairly simple" ;)

I guess it's doable... Just adding even more complexity to Diameter.

In any case, these changes (TLS and CER/CEA) require at least precise
instructions in the draft, if we want to avoid multiple implementations
that are not interoperable.
Do we agree on this?

Best regards,
Sebastien.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 21 Apr 2009 10:49:40 +0700

Sebastien Decugis [mailto:[email-masked]] writes:

> (legacy, new TLS) when attempting a new connection... 

In the worst case, yes; however, I imagine that this would happen rarely
outside of conformance testing.  Diameter peers don't just connect "out of
the blue", so I would expect that in The Real World (TM) peers would either
be initially configured to use the right combination or (if they were smart)
remember the result of the discovery process.

> I would not call

I think that we can leave capabilities update out of bis: it would be harder
to maintain backward compatibility (since it would change the state machine)
and it works cleanly as a separate app.

> Do we agree on this?

Precise specification is almost always a good thing.