Re: [Dime] Last Call: <draft-ietf-dime-realm-based-redirect-11.txt> (Realm-Based Redirection In Diameter) to Proposed Standard

[Stefan Winter <[e-mail]>]

Hello,

> The IESG has received a request from the Diameter Maintenance and
> Extensions WG (dime) to consider the following document:
> - 'Realm-Based Redirection In Diameter'
>   <draft-ietf-dime-realm-based-redirect-11.txt> as Proposed Standard

Sorry for bringing this up so late, but as I was writing my own dynamic
discovery draft for RADIUS, it occured to me that the usage of S-NAPTR
for Diameter brings a built-in support to signal realm-based redirect
*if* S-NAPTR discovery is used.

That only affects this document periphally; it describes realm-based
redirect for agent-based redirects, not for DNS-based; but still, the
wording in section 2 implies that using a realm-based-redirect-aware
Diameter agent is the only choice, and I think that should be rectified.

The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR
spec by allowing for "non-terminal" lookups; this is signalled by having
neither an "s" flag (for SRV targets) nor an "a" flag (for A/AAAA
targets); but instead an "" (empty) flag. The replacement string in the
NAPTR record is then the label of /another/ NAPTR lookup; that lookup is
then to be performed with the same service/protocol tag.

That makes the whole realm-based redirect problem very easy
protocol-wise. Consider a realm "foo.example" who wants to tell its
Diameter peers that its realm's application ID 123 is from now on served
from "example.com". It puts into DNS

foo.example.  43200   IN  NAPTR   100 10 "" "aaa+ap123:diameter.tls" ""
example.com

A client who got this answer would then query for

example.com NAPTR "aaa+ap123:diameter.tls"

and would get example.com's servers via SRV or A/AAAA records as
configured by the admins of example.com.

This is described in section 2.2.3 of RFC3958.

Now for the wording in the draft:

Sction 2: the first para needs a bit of a rewrite to factor in S-NAPTR's
capabilities.

I suggest something along the lines of:

"Realm-based redirection is implicitly a part of the Diameter base
protocol, but only where peer discovery using S-NAPTR is used (section
5.2 of [RFC6733], by using the non-terminal S-NAPTR flag). This allows
for both application-specific realm-based redirects, and for
application-agnostic (unconditional) realm-based redirects, and does not
require any Diameter agents.

For deployments which do not make use of S-NAPTR peer discovery, support
of realm-based redirection MUST be specified as part of functionality
supported by a Diameter application. (... continue with the rest of the
section ...)

Greetings,

Stefan Winter



> 
> 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
> [e-mail] mailing lists by 2013-08-27. Exceptionally, comments may be
> sent to [e-mail] 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/
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
> 


-- 
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: [phone]
Fax: [phone]