[Dime] Review of draft-ietf-dime-realm-based-redirect-02

[jouni korhonen <[e-mail]>]

Hi,

I volunteered to do this review in the Hiroshima meeting. So here we go with my initial comments. Comments are prefixed with [JiK].


1.  Introduction

   The usual redirect indication as described in Section 6.1.7 and
   Sections 6.12-6.14 of [RFC3588] returns one or more individual host
   names to the upstream Diameter node.  However, consider the case
   where an operator has offered a specific service but no longer wishes
   to do so.  The operator has arranged for an alternative domain to
   provide the service.  To aid in the transition to the new
   arrangement, the original operator maintains a redirect server to
   indicate the alternative destination to upstream nodes.  However, the
   original operator has no interest in configuring a list of hosts in
   the alternative operator's domain, and would prefer simply to provide
   redirect indications to the domain as a whole.

[JiK] Do we actually have a real-world example of this kind of situation? Does not need to on Diameter.. I mean an analogy to some existing case would probably be nice. I find it surprising motivation that the "original operator" would be too phlegmatic to fix the situation along time.. unless someone is shipping brain dead devises with stuff hardcoded in their firmware that cannot be remotely upgraded.


   Within this specification, the term "realm-based redirection" is used
   to refer to a mode of operation where the redirect indication
   specifies a realm and the upstream Diameter node reroutes the message
   to the realm rather than an individual host.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  Realm-Based Routing Application

[JiK] Is it rather "Realm-Based Redirection" as used below?

   Because realm-based redirection is not part of base Diameter
   behaviour, support for realm-based redirection by the client cannot
   be guaranteed without advertisement at the application level.  This
   document therefore specifies a new application, Realm-Based Routing
   (code TBD), for that purpose.

[JiK] How is this supposed to work.. in detail? Does it mean that:
1) when a Diameter peer sees this Application-Id being advertised in during CER/CEA, it knows that all other applications can also benefit from realm-based redirect support, or
2) only application with a new application can benefit from realm-based redirection? In this case you cannot define just one new application but rather take the approach what draft-ietf-dime-nai-routing had.. and require a new application to reference the RFC..


3.  Realm-Based Redirection

   This section specifies an extension to [RFC3588] to achieve realm-
   based routing.  The elements of this solution are:

[JiK] s/realm-based routing/realm-based redirection


   o  a new result code, DIAMETER_REALM_REDIRECT_INDICATION (3011);

   o  one new attribute-value pair (AVP), Redirect-Realm; and

   o  associated behaviour at Diameter nodes implementing this
      specification.

3.1.  Behaviour of Diameter Nodes

3.1.1.  Behaviour at the Redirect Agent

   This specification modifies Section 2.7 of [RFC3588] to permit
   REDIRECT routing table entries to contain an alternative realm
   instead of individual home server identities.

   This specification modifies Section 6.1.7 of [RFC3588].  If the
   realm-based routing table for a request contains a realm rather than
   one or more home server identities, the redirect agent MUST set the
   Result-Code AVP to DIAMETER_REALM_REDIRECT_INDICATION rather than
   DIAMETER_REDIRECT_INDICATION.  Furthermore, the redirect agent MUST
   insert a Redirect-Realm AVP containing the realm from the routing
   table entry in its answer message instead of one or more Redirect-
   Host AVPs.  It SHOULD insert a Redirect-Max-Cache-Time AVP to
   indicate the scope and persistence of the redirection in upstream
   Diameter nodes' routing caches.  To prevent confusion at Diameter
   nodes receiving the answer message, the Result-Code AVP MUST include
   the Error-Reporting-Host AVP if the host setting the Result-Code AVP

[JiK] The Result-Code AVP cannot include Error-Reporting-Host AVP, right?


   is different from the identity encoded in the Origin-Host AVP, in
   conformity with Section 7.1 of [RFC3588].  All other aspects of
   Section 6.1.7 remain the same as for host-based redirection.

3.1.2.  Behaviour of Other Diameter Nodes

   A Diameter node conforming to this specification which receives an
   answer with the result code value DIAMETER_REALM_REDIRECT_INDICATION
   SHOULD attempt to reroute the request to the indicated realm using
   normal discovery procedures to find an appropriate destination host.
   The receiving Diameter node SHOULD update its cache of routing
   entries according to the direction provided by the Redirect-Max-
   Cache-Time AVP, if present.  The cache entry SHOULD be associated
   with a redirect usage of ALL_REALM.

[JiK] If the original "stale" realm was learned from DNS, then which caching time has preference: the TTL from DNS or Redirect-Max-Cache-Time? The caching time from the AVP can potentially be longer than the DNS one and all this fuzz might just be because of long TTLs with DNS response caching..


3.2.  The Redirect-Realm AVP

   The Redirect-Realm AVP (code TBD) is of type DiameterIdentity.  It
   specifies a realm to which a node receiving a redirect indication
   containing the result code value DIAMETER_REALM_REDIRECT_INDICATION
   and the Redirect-Realm AVP SHOULD route the original request.  The M
   and V flags for the Redirect-Realm AVP MUST NOT be set.

[JiK] Why this restriction of 'M' flag? In Section 2 you require a new application anyway, thus 'M' should not be an issue.

   Section 6.14 of [RFC3588] is modified to permit the Redirect-Max-
   Cache-Time AVP to be used also to specify the persistence of cache
   entries created by the Redirect-Realm AVP.


4.  Security Considerations

   Because real-based redirection implies a change in business
   relationships, the node acting on the redirect indication SHOULD
   verify that the new realm is authorized to perform the requested
   service.  Similarly the originator of the request SHOULD perform an
   authorization check of the path as described in Section 2.10 of
   [RFC3588].


5.  IANA Considerations

   This specification adds a new AVP code [286???]  Redirect-Realm in

[JiK] [286??] eh..?

   the AVP Code registry under Authentication, Authorization, and
   Accounting (AAA) Parameters.

   This specification allocates a new Result-Code value
   DIAMETER_REALM_REDIRECT_INDICATION (3011) in the Result-Code AVP
   Values (code 268) - Protocol Errors registry under Authentication,
   Authorization, and Accounting (AAA) Parameters.

   This specification defines a new Diameter application, Realm-Based
   Routing, in the Standards Track portion of the Diameter application
   identifier registry.

[JiK] as mentioned in Section 2 I think the application usage needs a bit more thought.


6.  Acknowledgements

   Glen Zorn, Sebastien Decugis, Wolfgang Steigerwald, Mark Jones, and
   Victor Fajardo contributed comments that helped to shape this
   document.


Cheers,
	Jouni