RFC 3588:Diameter Base Protocol
RFC-Ref

IPsec


Click on the red underlined text to get to the source

... While [RFC3162prop] defines the use of IPsec with RADIUS, support for IPsec ...
... use of IPsec with RADIUS, support for IPsec is not required. Since within [IKE] authentication occurs ...
... IKE] authentication occurs only within Phase 1 prior to the establishment of IPsec SAs in Phase 2, it is typically not possible to define separate trust ...
... authorization schemes for each application. This limits the usefulness of IPsec in inter-domain AAA applications (such as ...
... inter-domain AAA deployments, IPsec support is mandatory in Diameter, and TLS ...
... within embedded devices, given improvements in processor speeds and the widespread availability of embedded IPsec and TLS implementations. ...
... End-to-End Security TLS and IPsec provide hop-by-hop security, or security across a ...


... Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism ...
... MUST NOT be used without any security mechanism (TLS or IPsec). It is suggested that IPsec ...
... IPsec). It is suggested that IPsec can be used primarily at the edges and in intra-domain ...
... would primarily use TLS. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage. ...
... destination realm. For example, where TLS or IPsec transmission- level security is sufficient, there may be no need for end-to-end security ...
... security to be used on each connection (TLS or IPsec). Therefore, each connection is authenticated ...


... Accounting protocol message MAY be compressed, in order to reduce network bandwidth usage. If IPsec and IKE are used to secure the Diameter ...


... Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security mechanism is acceptable in ...
... Diameter servers MUST support TLS and IPsec. Diameter implementations MUST use transmission-level security ...
... implementations MUST use transmission-level security of some kind (IPsec or TLS) on each connection. ...
... If a Diameter connection is not protected by IPsec, then the CER/CEA exchange MUST include an Inband-Security ...
... state. It is suggested that IPsec be used primarily at the edges for intra- domain ...
... inter-domain exchanges, TLS is recommended. See Sections 13.1 and 13.2 for more details on IPsec and TLS usage. ...
... IPsec Usage ...
... All Diameter implementations MUST support IPsec ESP [IPsec] in transport mode ...
... confidentiality, and MUST support the replay protection mechanisms of IPsec. Diameter ...
... security associations, and key management, using the IPsec DOI [IPSECDOI]. Diameter implementations MUST support peer ...
... connections. Since IPsec acceleration hardware may only be able to handle a limited number of active ...
... be required. Note that IPsec is considerably less flexible than TLS when it comes to configuring root ...
... identifiers is prohibited within IKE Phase 1, within IPsec it is not possible to uniquely configure trusted root CAs ...
... connections between administrative domains. IPsec is most appropriate for intra-domain usage when pre-shared keys ...
... When pre-shared key authentication is used with IPsec to protect Diameter, unique pre-shared keys ...
... It is recommended that a Diameter peer implement the same security mechanism (IPsec or TLS) across all its peer-to-peer connections ...
... security mechanisms being used (e.g., TLS over IPsec) or worse, potential security vulnerabilities. When IPsec ...
... IPsec) or worse, potential security vulnerabilities. When IPsec is used with Diameter, a typical security policy ...
... security policy for outbound traffic is "Initiate IPsec, from me to any, destination port Diameter"; for inbound ...
... Diameter"; for inbound traffic, the policy would be "Require IPsec, from any to me, destination port Diameter ...
... Diameter". This policy causes IPsec to be used whenever a Diameter peer initiates a connection ...
... connection is created; an IPsec SA is automatically created based on a simple ...
... SA is automatically created based on a simple static policy. Since IPsec extensions are typically not available to the sockets API ...
... the sockets API on most platforms, and IPsec policy functionality is implementation dependent, use of a simple static policy is the often the simplest route ...
... implementation dependent, use of a simple static policy is the often the simplest route to IPsec-enabling a Diameter implementation. ...
... node is using both TLS and IPsec, there is not a convenient way in which to use either TLS or IPsec ...
... IPsec, there is not a convenient way in which to use either TLS or IPsec, but not both, without reserving an additional port for TLS ...
... TLS and non-TLS usage, where the recommended IPsec policy is put in place, a TLS-protected connection ...
... TLS-protected connection will match the IPsec policy, and both IPsec and TLS ...
... TLS-protected connection will match the IPsec policy, and both IPsec and TLS will be used to protect the Diameter ...
... statically or dynamically. If IPsec is used to secure Diameter peer-to-peer connections ...
... Diameter peer-to-peer connections, IPsec policy SHOULD be set so as to require IPsec protection for inbound ...
... connections, IPsec policy SHOULD be set so as to require IPsec protection for inbound connections, and to initiate IPsec protection ...
... IPsec protection for inbound connections, and to initiate IPsec protection for outbound connections. This can be accomplished via use of inbound and ...



Google
Web
RFC-Ref