The Diameter Capabilities Update Application
draft-ietf-dime-capablities-update-07

[Ballot discuss]
The Gen-ART Review by Pete McCann on 19-Oct-2010 raised a question
  that needs to be answered.

  This document requests allocation of two separate command codes, TBD2
  and TBD3.  Pete believes these should actually be the same value.

[Ballot comment]
I am agreeing with Peter's DISCUSS.

Also:

  If the receiver of a CUR does not have any applications in common
  with the sender then it MUST return a Capabilities-Update-Answer
  (CUA) (Section 4.1.2) with the Result-Code AVP set to
  DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport

Can you please add a reference to RFC 3588 here (where DIAMETER_NO_COMMON_APPLICATION is defined)?

  layer connection; however, if active sessions are using the
  connection, peers MAY delay disconnection until the sessions can be
  redirected or gracefully terminated.


4.  Capabilities Update

  When the capabilities of a Diameter node conforming to this
  specification change, it MUST notify all of the nodes with which it
  has an open transport connection and have

I think you should insert "which" before "have", because support for this
extension needs to be advertised by peers, not the node.


  A Diameter node only issues a given command to those peers that have
  advertised support for the Diameter application that defines the
  command; a Diameter node must cache the supported applications in
  order to ensure that unrecognized commands and/or Attibute-Value

typo: Attribute-Value

  Pairs (AVPs) are not unnecessarily sent to a peer.

5.  Security Considerations

  The security considerations applicable to the Diameter Base Protocol
  [I-D.ietf-dime-rfc3588bis] are also applicable to this document.

This looks a bit weak, are you sure this extension doesn't raise new security issues?

[Ballot discuss]
This is a discuss-discuss.  To be clear, I am not asking for changes, just looking for clarification.

In section 4, it states:

  If the receiver of a CUR does not have any applications in common
  with the sender then it MUST return a Capabilities-Update-Answer
  (CUA) (Section 4.1.2) with the Result-Code AVP set to
  DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport
  layer connection

Given that the receiver of the CUR has an existing connection with the sender, doesn't that imply that
there were some capabilities in common at the time the connection was established?  It seems odd
that the capabilities update results in no applications in common.  Is this just for completeness?

This section continues:

                              however, if active sessions are using the
  connection, peers MAY delay disconnection until the sessions can be
  redirected or gracefully terminated.

If the update removed whatever applications were previously in common, how can the session continue?

[Ballot discuss]
I support this work in principle, but there are a few small points to
be addressed before I can ballot No Objection.

---

Although it is relatively obvious, before giving the message format in
section 4.1, you should state "using the BNF defined in
[I-D.ietf-dime-rfc3588bis]

---

I am not clear how the case of a peer not supporting receipt of a CUR
is handled. Section 3 is clear that nodes that do support CUR will
advertise the fact. I presume that "standard" Diameter processing
applies to the unexcpeted receipt of a CUR, but for clarity of
backward compatibility, it may be good to state it in one line.

---

Section 3 says that  is to be assigned for use be applications
that conform to this specification. But neither section 3 nor section
6.1 appears to give a name to this application ID (c.f. the name
Auth-Application-Id).

---

Is it possible to put the application I-D for applications conforming
to this specification in the CUR or CUA?

Can support for update be withdrawn?

[Ballot discuss]
The Gen-ART Review by Pete McCann on 19-Oct-2010 raised a question
  that needs to be answered.

  This document requests allocation of two separate command codes, TBD2
  and TBD3.  Pete believes these should actually be the same value.

[Ballot comment]
4.  Capabilities Update

  When the capabilities of a Diameter node conforming to this
  specification change, it MUST notify all of the nodes with which it
  has an open transport connection and have

I think you should insert "which" before "have", because support for this
extension needs to be advertised by peers, not the node.


  A Diameter node only issues a given command to those peers that have
  advertised support for the Diameter application that defines the
  command; a Diameter node must cache the supported applications in
  order to ensure that unrecognized commands and/or Attibute-Value

typo: Attribute-Value

  Pairs (AVPs) are not unnecessarily sent to a peer.

5.  Security Considerations

  The security considerations applicable to the Diameter Base Protocol
  [I-D.ietf-dime-rfc3588bis] are also applicable to this document.

This looks a bit weak, are you sure this extension doesn't raise new security issues?

[Ballot discuss]
If the receiver of a CUR does not have any applications in common
  with the sender then it MUST return a Capabilities-Update-Answer
  (CUA) (Section 4.1.2) with the Result-Code AVP set to
  DIAMETER_NO_COMMON_APPLICATION, and SHOULD disconnect the transport

Does this need to be registered with IANA, or is this already registered?

  layer connection; however, if active sessions are using the
  connection, peers MAY delay disconnection until the sessions can be
  redirected or gracefully terminated.

[Ballot comment]
Support Peter's discuss.

I also suggest being even more explicit about what an implementation should/could do if a peer tries to modify the things this document declares unmodifiable.

[Ballot comment]
I support Peter's discuss.


Section 1., paragraph 3:
>    Discussion of this draft may be directed to the dime Working Group of
>    the IETF (dime@ietf.org).

  Remove.


Section 4., paragraph 2:
>    order to ensure that unrecognized commands and/or Attibute-Value

  Nit: s/Attibute-Value/Attribute-Value/

[Ballot discuss]
1. Let me see if I understand this. The basic idea is that any two Diameter nodes can dynamically inform each other when their capabilities have changed, without forcing a reconnection. There are several kinds of capabilities that might change, such as (a) security mechanisms, (b) commands related to a particular application, and (c) the list of applications supported. It seems that several rules apply: (a) do not attempt to dynamically modify a security mechanism that is currently in use, because reconnection is required, (b) send updated commands related to a given application only to those peers which also support that application, and (c) send an updated list of supported applications to all peers [this seems to implicit].

Unfortunately, these rules are not explained very clearly, and certain matters are left unspecified:

a. Is it OK to dynamically inform peers about capabilities security mechanisms that are *not* currently in use for that connection?

b. When a node receives a Capabilities Update Request (CUR) from a peer, it needs to check if the two entities have any supported applications in common, and if not it SHOULD disconnect the transport connection. Why? Does this behavior protect against some unspecified threat? Does this behavior prevent two entities from exchanging a CUR that updates the list of supported applications (i.e., if they currently have no supported applications in common)?

c. Is the Capabilities Update Application limited to informing peers about new/changed capabilities, or does it also assume that based on communication of those new/changed capabilities a peer MAY/SHOULD/MUST take action based on those modified capabilities (e.g., "modifying the security mechanism")?

[Ballot discuss]
1) The last paragraph of 4.0 discusses the possibility of a peer being down, and sending an UNABLE-TO-Deliver error, which can trigger rerouting to an alternate peer.
section 4.1.1. says "Upon detection of a transport failure, this message MUST NOT be sent to an alternate peer."
Are these two statements in conflict?
2) when using SCTP, the request may contain multiple IP addresses. Can the authorization depend on the address? for example, could the peer only support ipv4 addresse bu tnot ipv6 addresses, or global but not private addresses? if so, how would the answer be indicated? If the peer did not support all the addresses, must it refuse the request? what if a transport connection for one of the addresses already existed, and the update was adding a new address that is not supported?
3) in the general case, what happens if the peer does not support the new capability?

Upon approval of this document, IANA understands that there are two IANA
actions that it must complete.

First, in the Application IDs subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-45

a new registration must be added:

Value Name Reference
----- ---------------------------------------- -----------
TBD Diameter Capabilities Update [RFC-to-be]

Second, in the Command Codes subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml#aaa-parameters-45

two new registrations must be added:

Code Value Name Reference
---------- --------------------------------------------- ---------
TBD Capabilities-Update-Request [RFC-to-be]
TBD Capabilities-Update-Answer [RFC-to-be]

IANA understands that these two actions are all the changes that need to
be made upon approval of this document.

(1.a) Who is the Document Shepherd for this document?

==> Lionel Morand

Has the Document Shepherd personally reviewed this version of
the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

==> Yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members?

==> Yes.

Does the Document Shepherd have any concerns about the depth
or breadth of the reviews that have been performed?

==> No.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

==> No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of?

==> No.

Has an IPR disclosure related to this document
been filed?

==> No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

==> This document was pushed mainly by the authors but
captures a solution
for a problem understood and agreed by the Dime WG.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent?

==> No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts
Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

==> The document was verified. No issue found.

(1.h) Has the document split its references into normative and
informative?

==> Yes.

Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion?

==> The draft has a normative reference to the
draft-ietf-dime-rfc3588bis that is not yet published as RFC.
However, this draft is under review process and should be soon
published.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document?

==> Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified?

==> Yes.
One new Diameter application id and two new Diameter command
code values are requested in the corresponding existing IANA registries.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

==> Yes.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document defines a new Diameter application and
associated
command codes. The Diameter Capabilities Update application
is intended to
allow the dynamic update of certain Diameter peer
capabilities while
the peer-to-peer connection is in the open state. This
application relies
on the exchange of the Capabilities-Update-Request/Answer
(CUR/CUA) messages
between peers supporting the Diameter Capabilities Update
application

Working Group Summary

There was consensus in the WG to publish the document.

Document Quality

This document has been reviewed and commented from key people
in the Dime WG.