top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Regarding RFC6942 Diameter Support for ERP

+3 votes
264 views

I was reading 6696 and 6942 (it's been awhile) and I need clarification:

1) It appears that 6942 does not support transportation of DSRK key. Only rRK and rMSK. Is that correct?

2) According to RFC 6696 - section 4.2:

RFC 6696: Section 4.2:

"The rRK MUST remain on the peer and the server that derived it and MUST NOT be transported to any other entity."

So why is 6942 transporting the rRK around?

posted Apr 9, 2014 by Kumar Mitrasen

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+1 vote

From the RFC 6733, it is clear that diameter session is identified bases on session-id, which has to be globally unique. Also in section 2.5 (Connections vs Sessions), its clearly mentioned that one connection can be used to multiplex multiple diameter sessions.

I have following questions related to diameter session -
Is there any implicit correlation between diameter session and origin-host? Does diameter standard allow different requests for the same session to have different origin-host value? Is there any possible problem if the value of Diameter Identity (part of recommended format for session-id) is different from those present in the request (like origin-host/origin-realm)?

+1 vote

I am studying RFC 3539. While I have some difficulties to understand "Appendix A - Detailed Watchdog Algorithm". Please provide some help.

1) Does AAA client or AAA Server (direct connection scenario) need to follow the algorithm?
In section 3.4 we have: "The watchdog is used in order to enable a AAA client or agent to determine when to resend on another connection." Does it mean the algorithm is only required in AAA client? Without following the algorithm AAA server would utilize the newly connected link earlier than AAA client, which would cause some AAA server initiated procedures, such as RAR, result in failure.

2) If the algorithm is required in AAA server, how to avoid the infinite loop when both AAA client and AAA server enter "REOPEN" phase?
If the "connection up" event indicates to AAA client and AAA server, both of them would send DWR to verify the link and enter "REOPEN" phase. While in this phase only DWA is allowed to be a signal to trigger the state machine going forward. It seems to me that both sides would discard the DWR sent by their peer and run into an infinite loop.

3) If the DWR was out of the scope of Non-DWA, how to avoid the inconsistent states between 2 AAA peers?
The total link verification time by the algorithm would be 2 x Tw + 3 x (time of DWA - time of DWR). If one side sets its Tw much longer than the other, it would run into the similar consequence of my question 1) - one side would utilize the newly connected link earlier than the other.

4) Is RFC 3539 so strictly binding to RFC 3588?
RFC 3588 has many statements referring to RFC 3539, especially in its transport description. I am quite confused about the coordination between the state machine logic in the Section 5.6 of RFC 3588 and that in the Appendix A of RFC 3539. I am wondering the strong binding is necessary to the application of AAA or very diameter application.

+3 votes

Some techies tell that diameter supports better roaming as compare to radius protocol. Can someone please explain why it is called ?

+1 vote

I have a very generic question. I took PCEF to describe my problem.
PGW supports multiple diameter based applications like Gx, Gy and Gz. When a message receives at PCEF from the peer diameter entities, how does PCEF come to know source of message and after that what PCEF does to forward this message to the proper application running at the PCEF.

My question is implementation specific. Please provide inputs in details.

I also want to know about session termination in Diameter protocol. Again, I am considering PCEF to describe my question. When a session is established between PCEF and PCRF ? either (CER and CEA) or (CCR and CCA) ?

...