Subject: [Dime] WG Action: RECHARTER: Diameter Maintenance and Extensions (dime)

From: IESG Secretary <[email-masked]>
Date: Tue, 24 Jan 2012 09:18:08 -0800 (PST)

The Diameter Maintenance and Extensions (dime) working group in the 
Operations and Management Area of the IETF has been rechartered.  For 
additional information, please contact the Area Directors or the working 
group Chairs.

Diameter Maintenance and Extensions (dime)
-----------------------------------------
Current Status: Active

Last Modified: 2012-01-19

Chairs:
    Lionel Morand <[email-masked]>
    Jouni Korhonen <[email-masked]>

Operations and Management Area Directors:
    Dan Romascanu <[email-masked]>
    Ronald Bonica <[email-masked]>

Operations and Management Area Advisor:
    Dan Romascanu <[email-masked]>

Mailing Lists:
    General Discussion: [email-masked]
    To Subscribe:       https://www.ietf.org/mailman/listinfo/dime
    Archive:
http://www.ietf.org/mail-archive/web/dime/current/maillist.html

Description of Working Group:

The Diameter Maintenance and Extensions WG will focus on maintenance and
extensions to the Diameter protocol required to enable its use for
authentication, authorization, accounting, charging in network access,
provisioning of configuration information within the network, and for
new AAA session management uses within the extensibility rules of the
Diameter base protocol. 

The DIME working group plans to address the following items:

- Maintaining and/or progressing, along the standards track, the
Diameter Base protocol and Diameter Applications. This includes
extensions to Diameter Base protocol that can be considered as enhanced
features or bug fixes.

- Diameter application design guideline. This document will provide
guidelines for design of Diameter extensions. It will detail when to
consider reusing an existing application and when to develop a new
application.

- Protocol extensions for the management of Diameter entities. This work
focuses on the standardization of Management Information Bases (MIBs) to
configure Diameter entities (such as the Diameter Base protocol or
Diameter Credit Control nodes). The usage of other management protocols
for configuring Diameter entities may be future work within the group.

- Protocol extensions for bulk and grouped AAA session management. The
aim of this work is to study and standardize a solution for handling
groups of AAA sessions within the Diameter base protocol context. The
solution would define how to identify and handle grouped AAA sessions in
commands and operations.

Additionally, Diameter-based systems require interoperability in order
to work. The working group, along with the AD, will need to evaluate any
potential extensions and require verification that the proposed
extension is needed, and is within the extensibility rules of Diameter
and AAA scope. Coordination with other IETF working groups and other
SDOs (e.g. 3GPP) will be used to ensure this.

Goals and Milestones:

Done     - Submit the following two Diameter Mobility documents to the
          IESG for consideration as a Proposed Standards:* 'Diameter 
          Mobile IPv6: Support for Home Agent to Diameter Server 
          Interaction' * 'Diameter Mobile IPv6: Support for Network 
          Access Server to Diameter Server Interaction'
Done     - Submit 'Diameter API' to the IESG for consideration as an
          Informational RFC
Done     - Submit 'Quality of Service Parameters for Usage with
          Diameter' to the IESG for consideration as a Proposed 
          Standard.
Done     - Submit 'Diameter QoS Application' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter Support for EAP Re-authentication
          Protocol' as DIME working group item
Done     - Submit 'Diameter User-Name and Realm Based Request Routing
          Clarifications' as DIME working group item
Done     - Submit 'Diameter Proxy Mobile IPv6' as DIME working group
          item
Done     - Submit 'Quality of Service Attributes for Diameter' to the
          IESG for consideration as a Proposed Standard
Done     - Submit 'Diameter Proxy Mobile IPv6' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter User-Name and Realm Based Request Routing
          Clarifications' to the IESG for consideration as a Proposed 
          Standard
Done     - Submit 'Diameter NAT Control Application' as DIME working
          group item
Done     - Submit 'Diameter Capabilities Update' as DIME working group
          item
Done     - Submit 'Diameter Credit Control Application MIB' to the
          IESG for consideration as an Informational RFC
Done     - Submit 'Diameter Base Protocol MIB' to the IESG for
          consideration as an Informational RFC
Done     - Submit 'Diameter Capabilities Update' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter Extended NAPTR' as DIME working group item
Done     - Submit 'Realm-Based Redirection In Diameter' as DIME
          working group item
Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized
          Routing' as DIME working group item
Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic
          Key Transport' as DIME working group item
Done     - Submit 'Diameter Priority Attribute Value Pairs' as DIME
          working group item
Done     - Submit 'Diameter IKEv2 PSK' as DIME working group item
Done     - Submit Revision of 'Diameter Base Protocol' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter Attribute-Value Pairs for Cryptographic
          Key Transport' to the IESG for consideration as a Proposed 
          Standard
Done     - Submit 'Diameter Priority Attribute Value Pairs' to the
          IESG for consideration as a Proposed Standard
Done     - Submit Revision of 'Diameter Network Access Server
          Application - RFC 4005bis' as DIME working group item
Done     - Submit 'Diameter NAT Control Application' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter IKEv2 PSK' to the IESG for consideration
          as a Proposed Standard
Done     - Submit 'Diameter Extended NAPTR' to the IESG for
          consideration as a Proposed Standard
Done     - Submit 'Diameter Support for Proxy Mobile IPv6 Localized
           Routing' to the IESG for consideration as a Proposed 
           Standard
Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG
            for consideration as a Proposed Standard
Mar 2012 - Submit Revision of 'Diameter Network Access Server
            Application - RFC 4005bis' to the IESG for consideration as
            a Proposed Standard
May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG
            for consideration as a BCP document Standard
Jul 2012 - Submit 'Diameter Support for EAP Re-authentication Protocol'
            to the IESG for consideration as a Proposed Standard
Aug 2012 - Submit 'problem statement and requirements for Diameter
            end-to-end security framework' as Dime working group item.
Aug 2012 - Submit a document on 'Protocol extension for bulk and group
            signaling' as a working group item
Dec 2012 - Submit 'problem statement and requirements for Diameter
            end-to-end security framework' to the IESG for
            consideration as an Informational RFC.
Aug 2013 - Submit a document on 'Protocol extension for bulk and group
            signaling' to the IESG for consideration as a Proposed
            Standard

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 Jan 2012 17:13:05 +0700

On 1/25/2012 12:18 AM, IESG Secretary wrote:

>             consideration as an Informational RFC.

It seems like a invitation to the same rat hole we went down with the
first attempt at e2e security.  I assume the problem is well understood
since it's been talked to death over at least the last 10 years, first
in the context of RADIUS and later Diameter; why not cut to the chase?.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Jan 2012 11:15:20 +0100

Glen,

Can you spell in more details what you propose by 'cut to the chase'? 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Glen Zorn
> Sent: Wednesday, January 25, 2012 12:13 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; The IESG
> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance
> andExtensions (dime)
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 Jan 2012 12:28:02 +0200

Glen,

Appreciate your views here.. since you were around those days and
probably have good recollection why things did not get done. Few
points still. You should have come up with arguments while this
part of the charter was still under discussion on IETF list. Another
point is that the problem statement may well conclude there is no
problem to solve or the solution is not worth the hassle (taking 
e.g. backward compatibility issues into account).

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 Jan 2012 18:31:52 +0700

On 1/25/2012 5:28 PM, jouni korhonen wrote:

> part of the charter was still under discussion on IETF list. 

I have a "special" folder for the IETF list (as, I'm sure, do many
others ;-) that I only open when I know that there is something in it of
interest to me; I wonder why this discussion didn't take place on the
dime list -- it does seem pertinent to the WG.

> Another
> problem to solve 

I'm that that is quite possible, given the apparent affection for
magical thinking on the part of certain vested interests.

> or the solution is not worth the hassle (taking 

That would betray a major lack of, well, just about everything on the
part of the WG and would be a major argument for dissolution, IMHO.

...

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 Jan 2012 18:34:18 +0700

> Can you spell in more details what you propose by 'cut to the chase'? 

Yes, I mean design a solution to the well-understood problem that is
simple and relatively easy to implement & requires virtually no changes
to Diameter.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Jan 2012 13:47:33 +0100

... or the other way - the WG may actually beat the schedule, and get
consensus earlier that the problem is well understood and on the
requirements of the solution, while in parallel work is being done on
the simple and relatively easy to implement solution hinted by Glen. The
wording of the charter is cautious enough not to make presumptions about
things going one way or the other, but does not preclude IMO any
scenario, including the very optimistic one. 

Regards,

Dan

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> jouni korhonen
> Sent: Wednesday, January 25, 2012 12:28 PM
> To: Glen Zorn
> Cc: [email-masked]; [email-masked];
> [email-masked]; The IESG
> Subject: Re: [Dime] WG Action: RECHARTER: Diameter Maintenance and
> Extensions(dime)
> 
> Glen,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Jan 2012 14:00:17 +0100

> ; I wonder why this discussion didn't take place on the

It did take place on the dime list - see message
http://www.ietf.org/mail-archive/web/dime/current/msg05001.html and the
following ones. 

The IETF and IESG mail lists were also copied because the document was
in external review. 

Regards,

Dan

Of
> Glen Zorn
> Sent: Wednesday, January 25, 2012 1:32 PM
> To: jouni korhonen
> Extensions (dime)

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 Jan 2012 15:14:21 +0200

Hi,

> the simple and relatively easy to implement solution hinted by Glen. The

I do not quite buy this being something that can be accomplished hands
down.. otherwise it would have been done during these 10 years time. Also,
it is, at least to me personally, an indication that the lack of Diameter
specific e2e security has not been an issue in real life so far.

> scenario, including the very optimistic one. 

Indeed.

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Thu, 26 Jan 2012 12:43:50 +0700

> http://www.ietf.org/mail-archive/web/dime/current/msg05001.html and the

Interesting: it appears that I received none of those messages.  Oh, well.

...

---

From: Glen Zorn <[email-masked]>
Date: Thu, 26 Jan 2012 13:07:41 +0700

On 1/25/2012 8:14 PM, jouni korhonen wrote:

...

> down.. otherwise it would have been done during these 10 years time. 

Seems like your next statement explains this one.

> Also,

If life in which networks are secured by claim alone is "real", then
it's certainly not an issue (nor is the use of any security measures
like TLS or IPsec).  It must be wonderful to live in the land of magic,
where do I get a ticket?  Not that I'm complaining: I've made quite a
bit of money off of organizations that claimed to the outside world (and
internally, as much as possible) that there networks were perfectly
secure just because they said so...

---

From: Glen Zorn <[email-masked]>
Date: Thu, 26 Jan 2012 13:17:09 +0700

> scenario, including the very optimistic one. 

Hmm.  OK, maybe I just can't read today, but

Aug 2012 	
Submit 'problem statement and requirements for Diameter end-to-end
security framework' as Dime working group item

and

Dec 2012 	
Submit 'problem statement and requirements for Diameter end-to-end
security framework' to the IESG for consideration as an Informational RFC

seem pretty specific to me, in particular assuming the creation of not
merely a "problem statement" and a requirements document but a
"framework" as well.  That would be three useless (in that, by
themselves, they do _nothing_ to change (let alone improve!) Diameter
security) things that we would spend a year creating.  Splendid!

...

---

From: jouni korhonen <[email-masked]>
Date: Thu, 26 Jan 2012 09:45:26 +0200

Glen,

> where do I get a ticket?  Not that I'm complaining: I've made quite a

;-)

> secure just because they said so...

As you know, this has been the case for quite some time.. and maybe the
"so far" part is about the end now. Still I do not see too many requests
coming from the field to fix the situation. That gives us some time to
work on a solution, though.

- Jouni

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jan 2012 09:40:37 +0100

Of
> Glen Zorn
> Sent: Thursday, January 26, 2012 8:17 AM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; jouni korhonen; lionel.morand@orange-
> ftgroup.com; [email-masked]; The IESG
> andExtensions(dime)
[[DR]] If the WG can reach consensus on the problem statement and
requirements in three months instead of eleven, we can add the work item
on the solution immediately. Let us just start doing this. 

Dan

---

From: Glen Zorn <[email-masked]>
Date: Mon, 30 Jan 2012 12:58:26 +0700

On 1/26/2012 3:40 PM, Romascanu, Dan (Dan) wrote:
...

> on the solution immediately. Let us just start doing this. 

Or not.  Problem statement: RFC 2477, Section 4.2.6.  Requirements: RFC
2989, Section 2.1.  Both seem veritable models of concision & clarity to
me; which part of the wheel do you want to re-invent first?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 30 Jan 2012 11:01:50 +0100

> From: Glen Zorn [mailto:[email-masked]]
> Sent: Monday, January 30, 2012 7:58 AM
> To: Romascanu, Dan (Dan)
> ftgroup.com; [email-masked]; The IESG; Glen Zorn

Hi Glen,

It is not about what I want but about what the WG and the community gets
consensus about. If understand you correctly, you believe that all
requirements are already clearly defined and you proposed a solution
that answers the requirements, the WG needs to confirm this. If the
requirements in 2477 and 2989 apply and are sufficient it's fine to
refer them. No wheels need to be re-invented if the existing ones still
fit and turn. 

Regards,

Dan

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Jan 2012 18:44:32 +0000

> work on a solution, though.

Not necessarily. There is a pattern where folks ignore known security
problems for as long as possible, and then get caught by some incident.
I don't know if that's the case here but I do suspect it might be.

S