top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Does IPsec is mandatory for diameter protocol ?

0 votes
541 views
Does IPsec is mandatory for diameter protocol ?
posted Sep 9, 2014 by Neelam

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
No its not, IPSEC is for transport layer security and optional completely depends on the need of the network.
commented Sep 10, 2014 by Salil Agrawal

2 Answers

+2 votes

IPSec 'MAY' be used, but Diameter (especially new RFC 6733) prefers TLS (DTLS for SCTP). If IPSec is used it is transparent at the transport layer. RFC says that Diameter SHOULD be secured by TLS or DTLS - which essentially means that it is strongly recommended.
In practice, since lot of Diameter traffic is within single network (billing, policy etc), we see that vendors/operators don't secure Diameter traffic.

answer Sep 10, 2014 by Rathnakumar Kayyar
0 votes

If I am correct, it is not necessary having IPsec . Please go through RFC-6733.

answer Sep 10, 2014 by Harshita
Similar Questions
+2 votes
DIAMETER: Does Proxy Agent validate presence of a mandatory field for an incoming diameter message ?

Please find the description of the problem:
A diameter client and server communicates in the network through Proxy Agent.
Here, I have assumed PCEF is a diameter client and PCRF is a diameter server. Interface between the PCEF and the PCRF is known as Gx.

Does Proxy agent, which sits between PCEF and PCRF, need to support Gx application ?
Does Proxy agent validate presence of any mandatory or optional AVP when it receives a message from a diamter client (PCEF) before forwarding it to diameter server (PCRF) ?

Can someone please provides the detailed behavior of a proxy agent ?

+1 vote
Diameter Protocol: Redirection for one RatingGroup while keeping session active for another RG.

We have a single GPRS session with two Rating Groups (e.g. 53 for a specific service and 54 for any service). OCS will send a FUI with redirection when Package reaches credit limit (4012) only for navigation through RG 54 (redirection based on Rating Group).

If OCS answers 4012 and sends FUI with redirection to SGSN for this session, then the user chooses to keep wholesale navigation at the redirection portal, the SGSN sends de ReAuth request only for RG 54 but OCS keeps waiting for RAR for RG 53 and it is needed to re-establish a new session to keep navigating through RG 53. How can we make it to keep navigation in RG 53 after redirection with another RG?

+3 votes
SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733

I have a query on SCTP guidelines for Diameter base protocol specified in section 2.1.1 of RFC 6733 as :

"A Diameter agent SHOULD use dedicated payload protocol identifiers (PPIDs) for clear text and encrypted SCTP DATA chunks instead of only using the unspecified payload protocol identifier (value 0). For this purpose, two PPID values are allocated: the PPID value 46 is for Diameter messages in clear text SCTP DATA chunks, and the PPID value 47 is for Diameter messages in protected DTLS/SCTP DATA chunks."

RFC doesn't specify the behavior if the connected diameter peer doesn't use PPID as 46/47 for diameter message transport over SCTP or DTLS/SCTP. What if diameter messages are received with PPID set to value other than 46/47 or default 0 value? Should the messages be ignored or respond with error diameter message back to peer with same PPID set ? Please comment on this behavior.

...