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

From: "James Jing" <[email-masked]>
Date: Thu, 5 Feb 2004 09:06:27 +1100

Completely agree with Jari's elaboration of the inflexibility of using
IPSEC, and the way it may even cause complications in an intranet
environment, where the corporate LAN itself is constructed from segments
linked together by IPSEC tunnels. If a single Diameter is then used for
say external VPN access, there would be complications in configuring the
Diameter server to use IPSEC to communicate with the VPN access server.
 
I wonder why TLS was not chosen as the mandatory security implementation
for Diameter? 
 
The other practical difficulty is mandatory SCTP. Support and adoption
for SCTP isn't widespread enough at the moment.

James

  _____  

From: Jari Arkko [mailto:[email-masked]] 
Sent: Wednesday, February 04, 2004 7:39 PM
To: James Jing
Cc: [email-masked]
Subject: Re: [AAA-WG]: Question on the use of IPSEC with Diameter

James Jing wrote: 
> 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? 

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. 
This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Feb 2004 13:05:32 +0200

> I wonder why TLS was not chosen as the mandatory security implementation 

It is mandatory for some nodes. For the NAS, the primary problem at
the time was that there was support for IPsec for other reasons on
typical NASes, so it seemed like a natural solution. If the decision
were to be done today... we might end up with different requirements.

> The other practical difficulty is mandatory SCTP. Support and 
> adoption for SCTP isn't widespread enough at the moment.

I agree, though SCTP would be better suited for the kind of problem
we have at hand. Its a typical issue: should we specify something that
can be deployed fast and easily, no big increase in functionality? Or
should we specify something that pushes the envelope a little bit,
but may be deployed slower because it has additional requirements?

As a practical matter though, remember that there is no protocol
police. You need to make the decisions on what your products support
and when they come out, on what platform, and how they compare to what
your competition sells.

--Jari