Subject: [Dime] Detecting loops when redirecting

From: jouni korhonen <[email-masked]>
Date: Thu, 6 Oct 2011 13:13:27 +0300

Folks,

This came up recently with RFC3588 and RFC3588bis. Assume a network topology where a Diameter node A sends a request to a Diameter node B. The Diameter node B redirects A to a Diameter node C. And then again the Diameter node C redirects A back to B. There are other topologies with similar properties..

While this is a sad misconfiguration of the network & routing, we have no protocol means to detect such loop. No Route-Record gets added to requests in this case because B and C are not forwarding packets per se. Should we have a "fix" for this or just let implementations deal with it? At minimum text describing the issue could be put somewhere in some relevant document. One possibility could be a "TTL" AVP that gets decremented every time a request/reply gets sent somewhere, independent of being redirected/relayed/proxied. However, that obviously has some backward compatibility issues if added as a mandatory AVP to the base protocol.

Any views on this?

- Jouni

---

From: Stefan Winter <[email-masked]>
Date: Thu, 06 Oct 2011 16:23:40 +0200

Hi,

> While this is a sad misconfiguration of the network & routing, we have no protocol means to detect such loop. No Route-Record gets added to requests in this case because B and C are not forwarding…

Interestingly enough, we have been facing the exact same issue in good
old RADIUS, when using multiple proxy hops. It is - as you write - a sad
misconfiguration, but it happens more frequently than we'd like.

We have been disucssing a TTL attribute quite a lot for our eduroam
consortium. I've brought forward the idea to the IETF ages ago on my
first appearance (uh, Chicago?) but wasn't able to generate much
intertia towards IETF-wide creation of such an attribute. For a while we
thought about a VSA, but then again, it wasn't quite important enough
for us to bully RADIUS server implementations all over the place to
include an eduroam VSA dictionary; so at some point we learned to live
without it.

If there is sufficient interest for Diameter folks to move this ahead,
it would be nice to use one of the <256 attributes so that it could be
defined in the same way in RADIUS...

Greetings,

Stefan Winter

>
> Any views on this?
>
> - Jouni
> _______________________________________________
> DiME mailing list
> [email-masked]
> 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: +352 424409 1
Fax: +352 422473

---

From: Mark Jones <[email-masked]>
Date: Thu, 6 Oct 2011 10:26:32 -0400

Hi Jouni,

On Thu, Oct 6, 2011 at 6:13 AM, jouni korhonen <[email-masked]>wrote:

> Folks,
>
> This came up recently with RFC3588 and RFC3588bis. Assume a network
> topology where a Diameter node A sends a request to a Diameter node B. The
> Diameter node B redirects A to a Diameter node C. And then again the
> Diameter node C redirects A back to B. There are other topologies with
> similar properties..
>
> While this is a sad misconfiguration of the network & routing, we have no
> protocol means to detect such loop. No Route-Record gets added to requests
> in this case because B and C are not forwarding packets per se. Should we
> have a "fix" for this or just let implementations deal with it? At minimum
> text describing the issue could be put somewhere in some relevant document.

I would support describing the problem in bis (your example is clear) and
state that the client is responsible for detecting this type of
misconfiguration. If the client is an agent, presumably it MUST answer with
the Result-Code AVP set to DIAMETER_LOOP_DETECTED when such an event occurs.
Anything else we need to say?

> One possibility could be a "TTL" AVP that gets decremented every time a
> request/reply gets sent somewhere, independent of being
> redirected/relayed/proxied. However, that obviously has some backward
> compatibility issues if added as a mandatory AVP to the base protocol.
>
>
Nice idea....for Diameter v2. I would want to impact backwards compatibility
for this.

---

From: Mark Jones <[email-masked]>
Date: Thu, 6 Oct 2011 10:27:21 -0400

That should read "I would NOT want to impact backwards compatibility for
this".

/Mark

On Thu, Oct 6, 2011 at 10:26 AM, Mark Jones <[email-masked]> wrote:

> Nice idea....for Diameter v2. I would want to impact backwards
> compatibility for this.
>
>
>
>> Any views on this?
>>
>> - Jouni

---

From: Adam Roach <[email-masked]>
Date: Thu, 06 Oct 2011 09:30:10 -0500

On 10/6/11 9:26 AM, Mark Jones wrote:
>
>     One possibility could be a "TTL" AVP that gets decremented every
>     time a request/reply gets sent somewhere, independent of being
>     redirected/relayed/proxied. However, that obviously has some
>     backward compatibility issues if added as a mandatory AVP to the
>     base protocol.
>
>

I don't think you'd need to make it mandatory. If it were inserted and 
acted upon by nodes that understood it (and ignored by nodes that 
didn't) then loops would eventually be shut down as long as one of the 
nodes acting on the attribute was involved.

/a

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 6 Oct 2011 17:12:33 +0200

On Thu, Oct 6, 2011 at 4:30 PM, Adam Roach <[email-masked]> wrote:
>> One possibility could be a "TTL" AVP that gets decremented every time a request/reply gets sent somewhere, independent of being redirected/relayed/proxied. However, that obviously has some backward compatibility issues if added as a mandatory AVP to the base protocol.
>>
>
> Nice idea....for Diameter v2. I would want to impact backwards compatibility for this.
>
> I don't think you'd need to make it mandatory. If it were inserted and acted upon by nodes that understood it (and ignored by nodes that didn't) then loops would eventually be shut down as long as one of the nodes acting on the attribute was involved.

+1

Cheers,
-Victor

---

From: Glen Zorn <[email-masked]>
Date: Fri, 07 Oct 2011 12:04:17 +0700

>> Nice idea....for Diameter v2. I would want to impact backwards

Actually, I don't think that this that great of an idea: it could be
used to put an absolute limit upon hops traversed, but that doesn't seem
especially useful.  Why not just change Section 6.1.8 to allow redirect
agents to check for loops & a Route-Record AVP to be added to the
redirected message?  I think that, if phrased carefully, this would not
harm backward compatibility while still providing a way to solve the
problem.  In the same vein, bullet 4 under the heading "Local Action" says

      4.  REDIRECT - Diameter messages that fall within this category
          MUST have the identity of the home Diameter server(s)
          appended, and returned to the sender of the message.  See
          Section 6.1.8 for redirect guidelines.

Why is the identity of the home Diameter server appended & how does an
arbitrary redirect agent know what it is?

...

---

From: jouni korhonen <[email-masked]>
Date: Fri, 7 Oct 2011 10:24:17 +0300

> redirected message?  I think that, if phrased carefully, this would not

That would also be rather big change. Currently redirect agents do cause Route-Record to be added into requests, thus checking for Route-Record has really no effect.

> arbitrary redirect agent know what it is?

Our interpretation has been that the sentence implies one cannot place Redirect Agents anywhere else than in front of the "home server". That would mean topologies having Redirect Agents doing redirections to relays/proxies/redirects are wrong. "Identity of the home Diameter server(s) appended" means adding Redirect-Host AVPs according to our interpretation.

- Jouni