Subject: [AAA-WG]: DNS SRV Issues

From: David Frascone <[email-masked]>
Date: Tue, 5 Feb 2002 07:43:59 -0600

In draft-ietf-aaa-diameter-08.txt, Section 5.2, item 3, it defines how to
use DNS SRV to lookup diameter peers.

However, there is no way to specify security when locating a peer.  (And, you
need to know in advance if the peer is using TLS).  

So, I prepose the following text be added to the base draft to clarify using
DNS SRV.

_diameter._tls_sctp.domain.org
_diameter._tls_tcp.domain.org

Right now, there is just:

_diameter._tcp.domain.org
_diameter._sctp.domain.org

I have not looked into CMS closely, but there might be more additions for 
CMS.

Since IPSEC is done at the ip layer, I think we can ignore that.  (The tunnel
has to be set up by administrators prior to any connections being made)

Later,

-Dave

---

From: Allison Mankin <[email-masked]>
Date: Tue, 05 Feb 2002 10:44:37 -0500

Hi, David,

Good issues!

The SRV text in the Diameter base was modeled on SRV text that had
been reviewed for SIP by the IESG. However, a re-review of sip-srv has
caused major changes.  SIP and Diameter are the first major uses of
SRV to try to get published, so there's some discovery of the issues
going on by the ADs too.

A new sip draft contains the results of the new review.  The algorithm
is to use a NAPTR lookup (RFC 2915) to get the transport service and
then use SRV on the NAPTR result to get a choice of servers ready to
provide that srevice.  I am sure the IESG will require a version of
this from Diameter as well.  It has been reviewed by the DNS folks in
IESG and found satisfactory.

It is draft-ietf-sip-srv-04.txt.

sip-srv includes TLS(tcp) as a transport in the NAPTR design, but
several of us have pointed out that this is insecure.  The problem is
the ease of bid-down from TLS use to use of an unsecured transport.
DNSSEC is not out there, and will only deploy slowly.  It is too easy
for the reply from the DNS to be altered so that TLS is not chosen by
the client.  This is an insecure way to treat the TLS secure channel.

So they have just gotten my AD comments about changing to another
approach - it also involves the question of the special TLS port.  It
turns out that this usage is not accepted by IESG (though not for
security reasons) and so my guidance to Pat earlier that it was fine
was not correct.  I suggest to Diameter (as well as SIP) a form of
same-port TLS use where the URI provides the reference integrity:
sips: in the SIP case.

There is a TLS issue with failovers too - there does needs to be
memory in the packets that TLS was in use and required for that hop,
so that a TLS connection can be tried during a failover...from both
directions for the hop.

Allison