Subject: [Dime] Route-Record in CCA

From: Ravi <[email-masked]>
Date: Tue, 10 Mar 2009 22:52:00 +0530

Hi,
   As per RFC  4006, the CCA message has the following ABNF format

<Credit-Control-Answer> ::= < Diameter Header: 272, PXY >
                                  < Session-Id >
                                  { Result-Code }
                                  { Origin-Host }
                                  { Origin-Realm }
                                  { Auth-Application-Id }
                                  { CC-Request-Type }
                                  { CC-Request-Number }
                                  [ User-Name ]
                                  [ CC-Session-Failover ]
                                  [ CC-Sub-Session-Id ]
                                  [ Acct-Multi-Session-Id ]
                                  [ Origin-State-Id ]
                                  [ Event-Timestamp ]
                                  [ Granted-Service-Unit ]
                                 *[ Multiple-Services-Credit-Control ]
                                  [ Cost-Information]
                                  [ Final-Unit-Indication ]
                                  [ Check-Balance-Result ]
                                  [ Credit-Control-Failure-Handling ]
                                  [ Direct-Debiting-Failure-Handling ]
                                  [ Validity-Time]
                                 *[ Redirect-Host]
                                  [ Redirect-Host-Usage ]
                                  [ Redirect-Max-Cache-Time ]
                                 *[ Proxy-Info ]
                                 *[ Route-Record ]
                                 *[ Failed-AVP ]
                                 *[ AVP ]

What is the purpose of having Route-Record AVP in CCA message? What problem
does it solve? As far as I know, the route-record AVP can be present only in
requests.

---

From: "Gowda, Avinash" <[email-masked]>
Date: Tue, 10 Mar 2009 23:30:57 +0530

Hi Ravi,

Following section in RFC 3588 will answer your question.

2.10. Diameter Path Authorization

Similarly, the local Diameter agent, on receiving a Diameter response

authorizing a session, MUST check the Route-Record AVPs to make sure

that the route traversed by the response is acceptable. At each

step, forwarding of an authorization response is considered evidence

of a willingness to take on financial risk relative to the session.

A local realm may wish to limit this exposure, for example, by

establishing credit limits for intermediate realms and refusing to

accept responses which would violate those limits. By issuing an

accounting request corresponding to the authorization response, the

local realm implicitly indicates its agreement to provide the service

indicated in the authorization response. If the service cannot be

provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error

message MUST be sent within the accounting request; a Diameter client

receiving an authorization response for a service that it cannot

perform MUST NOT substitute an alternate service, and then send

accounting requests for the alternate service instead.

Thanks,

Avinash Gowda

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ravi
Sent: Tuesday, March 10, 2009 10:52 PM
To: [email-masked]
Subject: [Dime] Route-Record in CCA

Hi,

                                  < Session-Id >

                                  { Result-Code }

                                  { Origin-Host }

                                  { Origin-Realm }

                                  { Auth-Application-Id }

                                  { CC-Request-Type }

                                  { CC-Request-Number }

                                  [ User-Name ]

                                  [ CC-Session-Failover ]

                                  [ CC-Sub-Session-Id ]

                                  [ Origin-State-Id ]

                                  [ Event-Timestamp ]

                                  [ Granted-Service-Unit ]

                                  [ Cost-Information]

                                  [ Check-Balance-Result ]

                                  [ Validity-Time]

                                 *[ Redirect-Host]

                                  [ Redirect-Host-Usage ]

                                 *[ Proxy-Info ]

                                 *[ Route-Record ]

                                 *[ Failed-AVP ]

                                 *[ AVP ]

What is the purpose of having Route-Record AVP in CCA message? What
problem does it solve? As far as I know, the route-record AVP can be
present only in requests.

---

From: Rajith R <[email-masked]>
Date: Wed, 11 Mar 2009 10:12:49 +0530

IMHO, checking the Route-Record AVPs in response and deciding whether the
route is acceptable is needless b/c response path is same as request path
and server is anyways provisioned for checking the request path. Hence, no
need to have Route-Record AVP in responses.

The -bis draft probably shares this view & hence has removed this text.

Regards

Rajith

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gowda, Avinash
Sent: Tuesday, March 10, 2009 11:31 PM
To: Ravi; [email-masked]
Subject: Re: [Dime] Route-Record in CCA

Hi Ravi,

Thanks,
Avinash Gowda
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ravi
Sent: Tuesday, March 10, 2009 10:52 PM
To: [email-masked]
Subject: [Dime] Route-Record in CCA

Hi,

---

From: Ravi <[email-masked]>
Date: Wed, 11 Mar 2009 23:34:55 +0530

Even I had the same opinion that Route-Record need not be present in
the answer messages.

Then how do I explain this text from the bis 16.

"  A local realm may wish to limit this exposure, for example, by
   establishing credit limits for intermediate realms and refusing to
   accept responses which would violate those limits.  By issuing an
   accounting request corresponding to the authorization response, the
   local realm implicitly indicates its agreement to provide the service
   indicated in the authorization response.  If the service cannot be
   provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error
   message MUST be sent within the accounting request;"

If a local realm agent/node needs to refuse a response which traverses
intermediate realms, it needs to know the path the request has
traversed. How would the local node know that? Is this done using
Route-Record? Then should we not update section 6.2 "Diameter Answer
Processing" to say that server needs to add the Route-Record AVPs from
the request to the answer?

Another question on the same section....

"If the service cannot be provided by the local realm, then a
DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the
accounting request"

How is this done? Another AVP?

---

From: Ravi <[email-masked]>
Date: Wed, 18 Mar 2009 23:24:38 +0530

Does anyone have any opinion on the following points?

On Wed, Mar 11, 2009 at 11:34 PM, Ravi <[email-masked]> wrote:

> Even I had the same opinion that Route-Record need not be present in the answer messages.
>
> If a local realm agent/node needs to refuse a response which traverses intermediate realms, it needs to know the path the request has traversed. How would the local node know that? Is this done using Route-Record? Then should we not update section 6.2 "Diameter Answer Processing" to say that server needs to add the Route-Record AVPs from the request to the answer?
>
>
> "If the service cannot be provided by the local realm, then a DIAMETER_UNABLE_TO_COMPLY error message MUST be sent within the accounting request"
>
>> problem

---

From: Sebastien Decugis <[email-masked]>
Date: Thu, 19 Mar 2009 10:29:41 +0900

Hi,

> Does anyone have any opinion on the following points?
I agree that Route-Record in a Diameter Answer would bring additional
security (via tracability).

When the server sends the answer with a success result code, it
implicitly indicates that it trusts the path of the request (same as the
path of the answer).
When the local agent receive the answers, it contains the identity of
the sender.
One could assume that indirect trust is established:  local agent ->
home server -> path.

Anyway, if an untrusted relay receives the request and forges an answer,
it can fake the Origin-Host of the reply. The local agent has no mean to
detect this if no Route-Record is in the answer.

IMHO, the question is: in what extent do we trust the hop-by-hop
security mechanism (TLS or IPsec)?

Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: Ravi <[email-masked]>
Date: Sat, 21 Mar 2009 21:34:12 +0530

IMO there are two things which we are discussing

1) ABNF defined for some answer messages in some RFCs has Route-Record AVP
present in it
       for example CCA in 4006
                  The common understanding that we have now is that this is
needed for path authorization by the diameter home realm, though this is not
explicitly mentioned in the RFC. The procedures that need to be performed at
the diameter server are not defined in this case. Was this the original
intent of having a Route-Record AVP in the CCA message?

2) Extending the Route-Record AVP mechanism for path authorization by the
home realm. Do we need to add this to the 3588 bis?

I hope the experts can provide their opinions on this.