Realm-Based Redirection In Diameter
draft-ietf-dime-realm-based-redirect-13

[Ballot comment]
I support Stephen's discuss points.

Note that on #2 I was worried that this redirection might somehow break the emu cryptobinding protocols wrt a) to keys made that use the realm but the emu protocols just use diameter as a transport and don't use diameter's realm when they make keys b) they'd be redirecting the inner methods somewhere different - but that doesn't seem to be happening.

[Ballot comment]
Thanks for writing this spec. One small issue:

  Designers of new
  applications can incorporate the mechanism specified here into their
  application by normative reference to this document.

I think the reference alone is probably not sufficient to specify the app, and is definitely not sufficient for the application software... I'd suggest rewording:

  A new application specification can incorporate the mechanism specified here by
  making it mandatory for the application, and referencing this specification normatively.

[Ballot comment]
2:

  the restriction in [RFC6733] that the NAPTR
  replacement field SHOULD match the domain of the original query does
  not apply for realm-based redirect purposes.
 
Strike "SHOULD". It is a 6733 requirement, and one that is overridden by this document. Having it here could lead to confusion.

  ...support of realm-based redirection MUST be
  specified as part of functionality supported by a Diameter
  application.
 
  ...it cannot be performed by a redirect agent as
  defined in [RFC6733], but MUST be performed instead by an
  application-aware Diameter node...

These are not protocol requirements. Instead of "MUST", try "needs to".

[Ballot comment]
Just one non-blocking comment here:
The Abstract is way too long, and has lots of explanatory stuff that should be in the Introduction, not in the Abstract (having an Abstract that's longer than the Introduction is a good clue to this sort of thing).  The Abstract should just be enough to understand whether this is likely the document one needs to look at, and shouldn't be giving all the background explanation.

I suggest replacing the first three paragraphs of the Abstract with this, or something close to it, an moving the rest of the explanatory text to the Introduction (or eliminating it, because it's really covered in Section 2 anyway):

NEW
  The Diameter protocol includes a capability for message redirection,
  controlled by an application-independent "redirect agent".  In some
  circumstances, an operator may wish to redirect messages to an
  alternate domain without specifying individual hosts.  This document
  specifies an application-specific mechanism by which a Diameter server
  or proxy (node) can perform such a redirection when S-NAPTR is not
  used for dynamic peer discovery.  A node performing this new function
  is referred to as a "Realm-based Redirect Server".
END

A comment about the shepherd writeup (not for the authors):

In answer to Q12 in the writeup, the shepherd gave this:

  This is a requirements document and as such has not need for
  MIB Doctor, media type, and URI type reviews.

This is not a requirements document, and this was clearly copied from another writeup and not updated.  It makes me question the rest of the writeup: how much else is not correct for this document, and was copied from another?

[Ballot discuss]

(1) I don't see any "authorization" checks in section 13 of
6733 so I don't know how to enforce the MUST in this draft's
section 4. How does that work?

(2) Just checking. Are there any Diameter applications where
the client and server use the server's realm as input to a
cryptographic calculation that could be broken by this form
of re-direction? (Esp. if the re-direction happens at a
proxy.)

(3) Are you missing some security considerations? This form
of re-direction could lead to a client sending a sensitive
AVP to a new realm without the client knowing that. Or to a
client receiving a sensitive AVP from a new realm withouth
the client knowing that the re-direct has happened. If so,
then shouldn't those be noted as risks that the client is
unwittingly taking on? Why would that be ok? (Or maybe I'm
misreading this.)

[Ballot comment]

- (This is not for the authors, but for the IESG.) I note
that the IPR declaration section III lists "Director of
Licensing" as the IETF participant whose personal belief
triggered the disclosure. That seems unlikely. Are we ok with
that?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dime-realm-based-redirect-11.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following question: AVP Codes require Expert Review (as described in RFC 5226) for registration. Has this been reviewed by the designated expert?

IANA understands that, upon approval of this document there are two IANA actions which must be completed.

First, in the AVP Codes registry located at:

http://www.iana.org/assignments/aaa-parameters

IANA is to register a new AVP Code as follows:

AVP Code: [ TBD-at-registration ]
Attribute Name: Redirect-Realm
Reference: [ RFC-to-be ]

IANA Question --> The AVP Codes registry is managed through Expert Review as defined by RFC 5226. Has the request for the AVP Code been reviewed by the registry expert?

Second, in the Result-Code AVP Values (code 268) - Protocol Errors subregistry of the Authentication, Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters

a new AVP-Specific Value will be registered as follows:

AVP Value: [ TBD-at-registration ]
Attribute Name: DIAMETER_REALM_REDIRECT_INDICATION
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Realm-Based Redirection In Diameter) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Realm-Based Redirection In Diameter'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Message redirection is a basic capability provided by the Diameter
  base protocol.  In its conventional form, message redirection is
  performed by an application-independent "redirect agent", which
  returns one or more individual hosts to the message sender as
  possible destinations of the redirected message.

  However, in some circumstances an operator may wish to redirect
  messages to an alternate domain without specifying individual hosts.
  This document specifies an application-specific mechanism by which
  that can be achieved.  New applications may incorporate this
  capability by reference to the present document.

  Because the redirection mechanism is application-specific, it must be
  performed by a Diameter server or proxy rather than a basic redirect
  agent as defined in the Diameter base protocol.  A new term, "Realm-
  based Redirect Server", is introduced in this document to
  differentiate the application-specific nature of realm-based
  redirection from the conventional Diameter redirection performed by a
  basic redirect agent.

  This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to
  the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time
  AVPs.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1254/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,

    Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this

    type of RFC indicated in the title page header?



  The document aims for Proposed Standard as indicated in the title page.



(2) 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:



  The Diameter protocol allows a Diameter redirect agent to return to

  the message sender one or more individual hosts as destinations of

  the redirected message.  However, in some circumstances an operator

  may wish to redirect messages to an alternate domain without

  specifying individual hosts.  This document specifies a mechanism by

  which this can be achieved.  New applications may incorporate this

  capability by reference to the present document.



  This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to

  the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time

  AVPs.



Working Group Summary:



  The working group reached a consensus on the document. There are existing

Service requirements for such a mechanism and the document is the result

  of the discussion between Diameter experts. The document has been reviewed

  several times, with no major issues raised as soon as the document was

  stable.





Document Quality:



  The proposed mechanism is a slight modification of the existing mechanism

  defined in the Diameter base protocol (RFC3588). The technical content of

  this document relies then tightly to the existing standard specification.

  The problem statement has been discussed between experts inside a design

  team discussing Diameter enhancements and the resulting document is aligned

  with the output of this discussion. Several reviews of the document have

  been performed and the last version captures the technical agreement

  reached inside the Dime WG.



Personnel:



Who is the Document Shepherd? Who is the Responsible Area Director?



  Lionel MORAND is the document shepherd.

  The responsible area director is Benoit Claise.



(3) Briefly describe the review of this document that was performed by the Document

    Shepherd. If this version of the document is not ready for publication, please explain

    why the document is being forwarded to the IESG.



  The shepherd has reviewed the document and did not find issues that

  would prohibit forwarding the document to the IESG. The remaining

  possible editorial corrections could be addressed during the IETF LC.



(4) Does the document Shepherd have any concerns about the depth or breadth of the

    reviews that have been performed?



  The shepherd has no concern on the depth of the reviews so far.

  The document has already been reviewed thoroughly by several Diameter experts.



(5) Do portions of the document need review from a particular or from broader perspective,

    e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?

    If so, describe the review that took place.



  The document needs to be reviewed by OPS-DIR, SecDir and AAA-Doctors.

  None of these have not been initiated yet. The reviews should specifically

  be done from Diameter deployments point of view and keeping the existing

  Diameter security constraints in mind.



(6) Describe any specific concerns or issues that the Document Shepherd has with this

    document that the Responsible Area Director and/or the IESG should be aware of? For

    example, perhaps he or she is uncomfortable with certain parts of the document, or

    has concerns whether there really is a need for it. In any event, if the WG has

    discussed those issues and has indicated that it still wishes to advance the

    document, detail those concerns here.



  No concerns.



(7) Has each author confirmed that any and all appropriate IPR disclosures required for

    full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

    If not, explain why?



  Confirmed by the authors.



(8) Has an IPR disclosure been filed that references this document? If so, summarize any

    WG discussion and conclusion regarding the IPR disclosures.



  There is one IPR disclosure (ID# 1254). This IPR was disclosed after the version -02

  of the WG draft and no complain was raised. No further complain was received during

the final WGLC.



(9) 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?



  There is a WG level consensus behind the document.



(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so,

    please summarise the areas of conflict in separate email messages to the Responsible

    Area Director. (It should be in a separate email because this questionnaire is

    publicly available.)



  No.



(11) Identify any ID nits the Document Shepherd has found in this document.

    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).

    Boilerplate checks are not enough; this check needs to be thorough.



  The document passes the automated IDnits check.



(12) Describe how the document meets any required formal review criteria, such as the

    MIB Doctor, media type, and URI type reviews.



  This is a requirements document and as such has not need for

  MIB Doctor, media type, and URI type reviews.



(13) Have all references within this document been identified as either normative or

    informative?



  Yes.



(14) 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

    plan for their completion?



  There is a normative reference to the existing RFC 6733 defining the Diameter base protocol.



(15) Are there downward normative references (see RFC 3967)? If so, list these

    downward references to support the Area Director in the Last Call procedure.



  No.



(16) Will publication of this document change the status of any existing RFCs? Are those

    RFCs listed on the title page header, listed in the abstract, and discussed in the

    introduction? If the RFCs are not listed in the Abstract and Introduction, explain

    why, and point to the part of the document where the relationship of this document

    to the other RFCs is discussed. If this information is not in the document, explain

    why the WG considers it unnecessary.



  No.



(17) Describe the Document Shepherd's review of the IANA considerations section,

    especially with regard to its consistency with the body of the document. Confirm

    that all protocol extensions that the document makes are associated with the

    appropriate reservations in IANA registries. Confirm that any referenced IANA

    registries have been clearly identified. Confirm that newly created IANA registries

    include a detailed specification of the initial contents for the registry, that

    allocations procedures for future registrations are defined, and a reasonable name

    for the new registry has been suggested (see RFC 5226).



  This document defines a new AVP code value and a new Result-Code value within the

  IANA-managed registries created for the Diameter base protocol (RFC 3588).



(18) List any new IANA registries that require Expert Review for future allocations.

    Provide any public guidance that the IESG would find useful in selecting the IANA

    Experts for these new registries.



  None.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate

    sections of the document written in a formal language, such as XML code, BNF rules,

    MIB definitions, etc.



  None needed.