Subject: [Dime] Would realm-based redirection be a protocol error or an application error?

From: Tom Taylor <[email-masked]>
Date: Sun, 08 Jan 2012 15:20:07 -0500

I'm finally updating draft-ietf-dime-realm-based-redirect.

Given that realm-based redirection is defined at an application level, 
maybe the answer is obvious. What I am concerned with is whether the 
redirect server should clear the 'R' bit in the header to ensure that 
the response goes all the way back to the original requesting host 
(i.e., following on Figure 8 in section 7 of RFC 3588). The reason for 
doing this is the issue identified in the Security Considerations 
section of the realm-based-redirection I-D: a change of realm implies a 
change of business relationship that should be noted by the requesting 
host before the request is rerouted.

Tom Taylor

---

From: Glen Zorn <[email-masked]>
Date: Mon, 09 Jan 2012 14:00:42 +0700

On 1/9/2012 3:20 AM, Tom Taylor wrote:

> maybe the answer is obvious. 

Section 7 of RFC 3588 says

   There are two different types of errors in Diameter; protocol and
   application errors.  A protocol error is one that occurs at the base
   protocol level, and MAY require per hop attention (e.g., message
   routing error).  Application errors, on the other hand, generally
   occur due to a problem with a function specified in a Diameter
   application (e.g., user authentication, Missing AVP).

> What I am concerned with is whether the
> (i.e., following on Figure 8 in section 7 of RFC 3588). 

I don't understand: as I understand it, the 'R' bit has nothing to do
with error type; if it is cleared that just signifies that the message
is an answer, rather than a request (which would presumably be true of
any error response).

> The reason for
> change of business relationship 

I think that this is not necessarily true.  For example, consider a
large ISP with international operations; such an entity might have
multiple Diameter realms (europe.bigisp.com, asia.bigisp.com, etc.), no?

> that should be noted by the requesting
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Tom Taylor <[email-masked]>
Date: Mon, 09 Jan 2012 18:56:59 -0500

See below.

> is an answer, rather than a request (which would presumably be true of

[PTT] I don't think so. Section 7 makes a clear distinction between the 
routing for protocol error responses and application error responses 
(Figures 7 and 8 rtespectively) and ascribes the difference to the 
setting of the 'R' bit (text following Figure 8).
>> host before the request is rerouted.

[PTT] I think I've decided not to mention the 'R' bit. The result fits 
within the recommendations in the Security Considerations section.

---

From: jouni korhonen <[email-masked]>
Date: Tue, 10 Jan 2012 10:08:40 +0200

Tom,

On Jan 8, 2012, at 10:20 PM, Tom Taylor wrote:

> Given that realm-based redirection is defined at an application level, maybe the answer is obvious. What I am concerned with is whether the redirect server should clear the 'R' bit in the header to ensure that the response goes all the way

Clearing 'R' is normal behavior when sending any answer message. In the answer message the content of your Result-Code AVP then identifies what went wrong. However, in your draft you define a new Result-Code value DIAMETER_REALM_REDIRECT_INDICATION (3xxx TBD), which is a protocol error and therefore would require 'E' bit to be set and the specific error answer command ABNF to be used (see Sections 7.1.3 and 7.2 of RFC3588). As the error answer is sent back towards the originator of the request, each agent may take action on the message. Since the error is specific to redirection it is very unlikely any intermediate agent would take any action to the answer message.

- Jouni

>  back to the original requesting host (i.e., following on Figure 8 in section 7 of RFC 3588). The reason for doing this is the issue identified in the Security Considerations section of the realm-based-redirection I-D: a change of realm implies a change of business relationship that should be noted by the requesting host before the request is rerouted.
> 
> Tom Taylor

---

From: Tina TSOU <[email-masked]>
Date: Tue, 10 Jan 2012 15:11:10 +0000

DIAMETER_REALM_REDIRECT_INDICATION should be defined as an Application error.
I think the 5XXX class is appropriate.
The R-bit should be cleared (default for all Diameter answer messages) and E-bit should not be set.

Sent from my iPad

On Jan 9, 2012, at 5:57 PM, "Tom Taylor" <[email-masked]> wrote:

> [PTT] I don't think so. Section 7 makes a clear distinction between the routing for protocol error responses and application error responses (Figures 7 and 8 rtespectively) and ascribes the difference to the setting of the 'R' bit (text following Figure 8).
>> 
>>> The reason for
> [PTT] I think I've decided not to mention the 'R' bit. The result fits within the recommendations in the Security Considerations section.
> 
>>> 
>>> Tom Taylor

---

From: jouni korhonen <[email-masked]>
Date: Tue, 10 Jan 2012 23:00:47 +0200

A question. Taken that existing direct stuff uses protocol errors (3xxx) why should realm-based redirection behave differently? 

- Jouni

---

From: Glen Zorn <[email-masked]>
Date: Wed, 11 Jan 2012 17:51:38 +0700

On 1/10/2012 6:56 AM, Tom Taylor wrote:

...

> setting of the 'R' bit (text following Figure 8).

I think that there is a serious problem here, with my thinking, yours,
or with the RFC.  Figures 7 and 8 appear to me to diagram two entirely
different networks and both the figures and the accompanying text are
descriptive of the two cases, not comparative.  In other words, I not
only don't agree with you but can't understand where you get the idea
from.  For example, why do you think that the 'R' bit is set in one
response and cleared in the other?

...

---

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Jan 2012 11:18:06 -0500

I won't argue the point further. Section 7 is undoubtedly not the most 
authoritative section of the RFC, and I probably misinterpreted the 
text. It's just that when I saw it I thought there were subtleties to 
Diameter that I wasn't aware of, and I'd better take them into account.

---

From: Tina TSOU <[email-masked]>
Date: Wed, 11 Jan 2012 17:36:20 +0000

IMHO, Diameter base protocol mainly specifies routing procedure. In the base protocol, Redirect Agent currently returns the error on protocol layer. So it should be 3XX errors processed in Diameter protocol layer.

Tina

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: Wednesday, January 11, 2012 10:18 AM
> To: Glen Zorn
> Cc: [email-masked]
> Subject: Re: [Dime] Would realm-based redirection be a protocol error or
> an application error?
>

---

From: Glen Zorn <[email-masked]>
Date: Thu, 12 Jan 2012 13:32:52 +0700

> Diameter that I wasn't aware of, and I'd better take them into account.

That's fine; nevertheless, it seems to me that a section that can give
rise to two such wildly disparate interpretations to at least require
clarification, no?

...

---

From: Tina TSOU <[email-masked]>
Date: Fri, 13 Jan 2012 04:13:17 +0000

Existing DIAMETER_REDIRECT_INDICATION is at host level; so the forwarding decision can be taken at hop level; any node in the path of Diameter original request may forward it to the host specified by 3XXX response with DIAMETER_REDIRECT_INDICATION.

However DIAMETER_REALM_REDIRECT_INDICATION is at realm level (and need use the realm routing table of the request originator);
hence to avoid per hop handling of this error, I have suggested 5XXX.

Sent from my iPad