Subject: [AAA-WG]: Question on the use of IPSEC with Diameter

From: "James Jing" <[email-masked]>
Date: Wed, 4 Feb 2004 17:53:02 +1100

Diameter transport profile mandates the use of IPSEC and requires
conforming implementation to support IPSEC.

My question is whether a Diameter server needs to be aware of IPSEC, as
my understanding is that IPSEC is a network layer protocol, and Diameter
is an application. More specifically, if a Diameter server is setup on a
host, with the host providing IPSEC security, would this be a conforming
configuration for Diameter?

Thanks.

James Jing

---

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 10:38:31 +0200

> configuration for Diameter?

Strictly speaking, I don't think it is required that Diameter is aware
of IPsec. However, the usage of IPsec is less flexible than TLS where
such awareness is easily available, and this can cause issues in the
configuration of suitable CAs and the simultaneous usage of TLS and
IPsec. In short, the independent host and application implementation
is conformant, but may not offer quite the same ease and flexibility
compared to the sole use of TLS or the ability of the application to be
aware of IPsec.

Here's some text from RFC 3588 that explains the issues in more
detail:

    As with any peer-to-peer protocol, proper configuration of the trust
    model within a Diameter peer is essential to security.  When
    certificates are used, it is necessary to configure the root
    certificate authorities trusted by the Diameter peer.  These root CAs
    are likely to be unique to Diameter usage and distinct from the root
    CAs that might be trusted for other purposes such as Web browsing.
    In general, it is expected that those root CAs will be configured so
    as to reflect the business relationships between the organization
    hosting the Diameter peer and other organizations.  As a result, a
    Diameter peer will typically not be configured to allow connectivity
    with any arbitrary peer.  When certificate authentication Diameter
    peers may not be known beforehand, and therefore peer discovery may
    be required.

    Note that IPsec is considerably less flexible than TLS when it comes
    to configuring root CAs.  Since use of Port identifiers is prohibited
    within IKE Phase 1, within IPsec it is not possible to uniquely
    configure trusted root CAs for each application individually; the
    same policy must be used for all applications.  This implies, for
    example, that a root CA trusted for use with Diameter must also be
    trusted to protect SNMP.  These restrictions can be awkward at best.
    Since TLS supports application-level granularity in certificate
    policy, TLS SHOULD be used to protect Diameter connections between
    administrative domains.  IPsec is most appropriate for intra-domain
    usage when pre-shared keys are used as a security mechanism.

    When pre-shared key authentication is used with IPsec to protect
    Diameter, unique pre-shared keys are configured with Diameter peers,
    who are identified by their IP address (Main Mode), or possibly their
    FQDN (Aggressive Mode).  As a result, it is necessary for the set of
    Diameter peers to be known beforehand.  Therefore, peer discovery is
    typically not necessary.

    The following is intended to provide some guidance on the issue.

    It is recommended that a Diameter peer implement the same security
    mechanism (IPsec or TLS) across all its peer-to-peer connections.
    Inconsistent use of security mechanisms can result in redundant
    security mechanisms being used (e.g., TLS over IPsec) or worse,
    potential security vulnerabilities.  When IPsec is used with
    Diameter, a typical security policy for outbound traffic is "Initiate
    IPsec, from me to any, destination port Diameter"; for inbound
    traffic, the policy would be "Require IPsec, from any to me,
    destination port Diameter".

    This policy causes IPsec to be used whenever a Diameter peer
    initiates a connection to another Diameter peer, and to be required
    whenever an inbound Diameter connection occurs.  This policy is
    attractive, since it does not require policy to be set for each peer
    or dynamically modified each time a new Diameter connection is
    created; an IPsec SA is automatically created based on a simple
    static policy.  Since IPsec extensions are typically not available to
    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 to IPsec-enabling a Diameter implementation.

    One implication of the recommended policy is that if a node is using
    both TLS and 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 usage.  Since Diameter uses the same port for TLS and
    non-TLS usage, where the recommended IPsec policy is put in place, a
    TLS-protected connection will match the IPsec policy, and both IPsec
    and TLS will be used to protect the Diameter connection.  To avoid
    this, it would be necessary to plumb peer-specific policies either
    statically or dynamically.

    If IPsec is used to secure Diameter peer-to-peer connections, IPsec
    policy SHOULD be set so as to require IPsec protection for inbound
    connections, and to initiate IPsec protection for outbound
    connections.  This can be accomplished via use of inbound and
    outbound filter policy.