Subject: RE: [AAA-WG]: DNS SRV Issues - More of them

From: <[email-masked]>
Date: Wed, 20 Feb 2002 16:17:20 +0200

Hi Allison,

Jonathan R. has mentioned that SIP-SRV should be hitting a IETF-EDITORS
list near you today.  Do you recommend taking this as the basis for
Diameter as well?  As I understand, the SIP URI will change, when
using secured traffic.  It would look something like this:

	sips:user@host (sip + tls)
	sip:user@host  (sip)

in Diameter terms, this may become something like:

Diameter-Identity  = "aaa://" fqdn [ port ] [ transport ] [ protocol ] 

Diameter-Identity  = "aaas://" fqdn [ port ] [ transport ] [ protocol ] 
 -> with TLS

Is my understanding correct?

John

> -----Original Message-----
> From: ext Allison Mankin [mailto:[email-masked]]
> Sent: 05 February, 2002 17:45
> To: David Frascone
> Cc: [email-masked]
> Subject: Re: [AAA-WG]: DNS SRV Issues - More of them
> 
> 
> 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
>

---

From: Aki Niemi <[email-masked]>
Date: 21 Feb 2002 12:14:53 +0200

Hi, 

I was reading through the diameter base protocol -08, and found some
nits: 

- page 81: Chapter 8.0, first sentence "Diameter can provide two
different type of ..." s/type/types 

- page 81: Chapter 8.0, third paragraph "The Auth-Grace-Period AVP
contains ... the server will release an state information ..." s/an/all 

- page 82: first sentence, second line from top "... implies the maximum
length the session ..." s/length/length of 

- page 82: Chapter 8.1, first paragraph, third line "...implementations
that makes use ..." s/makes/make 

- page 102: Chapter 9.5, third paragraph, 6th line "When the initial
Accounting-Request is sent for a given session is sent, ..." get rid of
the first "is sent" 

Cheers,
Aki