Subject: [AAA-WG]: Issue 81: Route-Record change

From: Pat Calhoun <[email-masked]>
Date: Fri, 22 Jun 2001 11:26:38 -0700

Jacques,

I have been trying to address this issue, and I cannot for the life of
me, figure out how this is to be done. Your issue states that this
removes checking for loops when a packet is received, but I believe
that this is incorrect. 

I agree that including the peer's identity instead of your own could be
valuable, and this is done upon receipt as opposed to prior to forwarding
a message. However, loop checks much still be done, and it is better for
the check to be done when it is received, as opposed to prior to sending
(I think).

Here's what I came up with, but it doesn't match your description of 
what needs to be changed:

5.1.3  Receiving Requests

  A relay or proxy agent MUST check for forwarding loops when receiving
  requests. A loop is detected if the server finds its own identity in
  a Route-Record AVP. When such an event occurs, the agent MUST answer
  with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

[...]

5.1.10  Relaying and Proxying Requests

   A relay or proxy agent MUST append a Route-Record AVP to all requests
   forwarded. The AVP contains the identity of the peer the request was 
   received from.

---

From: Barney Wolff <[email-masked]>
Date: Fri, 22 Jun 2001 15:14:55 -0400

Pat, presumably actual loops will be very rare and only persist until
a misconfiguration is corrected.  Thus it does no harm at all, imho,
to defer the check until one is about to forward the request.  That
way, the check is always done against ones own identity, with no
risk of encoding differences leading to false negatives.  It really
should not take half a page to express the equality-comparison
algorithm for Diameter identities, nor should one have to convert
every item in the recorded route to canonical form to do the comparison.

A server or any entity that is going to answer the request does not
need to do the loop check, as there is no risk of the loop's being
perpetuated.

Barney

---

From: Jacques Caron <[email-masked]>
Date: Sat, 23 Jun 2001 11:37:54 +0200

>removes checking for loops when a packet is received, but I believe

Nope, it says it removes the check that the last route-record must contain 
the same identity as that advertised by the host in a CER/CEA on that 
connection.

Loop checking must still be done at some point. Either you check all the 
route record against your identity on reception, or you check against the 
peer you're going to send it to before sending. I think the former is better.

>the check to be done when it is received, as opposed to prior to sending

Yep.

>    forwarded. The AVP contains the identity of the peer the request was

Looks good to me.

Jacques.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Jacques Caron <[email-masked]>
Date: Sat, 23 Jun 2001 12:05:57 +0200

>every item in the recorded route to canonical form to do the comparison.

Again, I think it should be stated that any DiameterIdentities used in all 
the loop-checking activities MUST be the value advertised in Origin-Host in 
CER/CEA, and should be treated as an opaque string. Then pure string 
matching (strcmp) would be enough.

>need to do the loop check, as there is no risk of the loop's being

There are issues with redirects, I think.

Jacques.

---

From: Pat Calhoun <[email-masked]>
Date: Mon, 25 Jun 2001 06:55:51 -0700

> matching (strcmp) would be enough.

so you compare what a peer had advertised with the Route-Record AVPs in
a message, effectively looking for loops for the peer?

PatC

---

From: Jacques Caron <[email-masked]>
Date: Mon, 25 Jun 2001 16:44:32 +0200

>a message, effectively looking for loops for the peer?

No, you compare against your own identity, but insert what the peer 
advertised in a Route-Record AVP.

[btw, order of the two above is dependent on whether you allow connections 
to yourself or not: if you do, then you need to insert then compare; if you 
don't, it doesn't matter]

Jacques.