Subject: [BEHAVE] [Fwd: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11]

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Oct 2007 10:59:55 +0200

I requested a review of STUNbis from the DNS directorate and here is the
review done by Peter Koch. Authors please respond to the comments he
provide.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

Subject: Re: DNS directorate review of draft-ietf-behave-rfc3489bis-11
From: Peter Koch <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: dns directorate <[email-masked]>, Magnus Westerlund <[email-masked]>
Date: Thu, 18 Oct 2007 23:59:00 +0200

On Fri, Oct 12, 2007 at 03:59:52PM +0300, Jari Arkko wrote:

> Magnus Westerlund wrote:

> > STUN (draft-ietf-behave-rfc3489bis-11) is using DNS to locate STUN
> > services for the desired protocol (UDP or TCP). Could you please have
> > the DNS directorate review what is written on this usage.

I have reviewed this draft for the DNS Directorate and therefore focused
on Section 9 "DNS Discovery of a Server" and the security considerations.
There are several issues with the use of SRV RRs that need to be addressed.

> 9.  DNS Discovery of a Server
> 
>    This section describes an optional procedure for STUN that allows a
>    client to use DNS to determine the IP address and port of a server.
>    A STUN usage must describe if and when this extension is used.  To
>    use this procedure, the client must have a domain name and a service
>    name; the usage must also describe how the client obtains these.

NIT: since it's not about the client's name but the servers: "the client
     must _know_ ..."; otherwise easy to mis-read.

>    When a client wishes to locate a STUN server in the public Internet
>    that accepts Binding Request/Response transactions, the SRV service
>    name is "stun".  STUN usages MAY define additional DNS SRV service
>    names.

This is in violation of RFC 2782. The port name assigned by IANA is
"nat-stun-port", so this should be the one used in SRV handling. Same for
the definition of additional service names.

>    The domain name is resolved to a transport address using the SRV
>    procedures specified in [RFC2782].  The DNS SRV service name is the
>    service name provided as input to this procedure.  The protocol in
>    the SRV lookup is the transport protocol the client will run STUN
>    over: "udp" for UDP, "tcp" for TCP, and "tls" for TLS-over-TCP.  If,

The introduction of "tls" as another string for the RFC 2782 "Proto" field
also violates that RFC, since it's not defined as an IP protocol in the
"protocol-numbers" registry.

>    in the future, additional SRV records are defined for TLS over other
>    transport protocols, those will need to utilize an SRV transport
>    token of the form "tls-foo" for transport protocol "foo".

Even more so, the "Proto" parameter isn't application specific, so the
draft under consideration is just the wrong place to make this reservation.

>    The procedures of RFC 2782 are followed to determine the server to
>    contact.  RFC 2782 spells out the details of how a set of SRV records
>    are sorted and then tried.  However, RFC2782 only states that the
>    client should "try to connect to the (protocol, address, service)"
>    without giving any details on what happens in the event of failure.

I'm not sure I understand this concern. Since RFC 2782's section on
"Usage rules" says that one should iterate over the sorted (according to
Priority and Weight) list until a "connection" succeeds, isn't that all
that's needed?

>    When following these procedures, if the STUN transaction times out
>    without receipt of a response, the client SHOULD retry the request to
>    the next server in the list of servers from the DNS SRV response.

Well, _ordered_ list as of RFC 2782.

>    Such a retry is only possible for request/response transmissions,
>    since indication transactions generate no response or timeout.
> 
>    The default port for STUN requests is 3478, for both TCP and UDP.
>    Administrators SHOULD use this port in their SRV records for UDP and
>    TCP, but MAY use others.  There is no default port for STUN over TLS,

I'd emphasize here that the administrator _of the STUN server_ is encouraged
to use port 3478 and then, subsequently, to use this port in the DNS,
not vice versa. I.e., the DNS SRV RR should reflect which port is actually
listened on.

>    however a STUN server SHOULD use a port number for TLS different from
>    3478 so that the server can determine whether the first message it
>    will receive after the TCP connection is set up, is a STUN message or
>    a TLS message.
> 
>    If no SRV records were found, the client performs an A or AAAA record
>    lookup of the domain name.  The result will be a list of IP

The change here is to allow AAAA in addition to A, the original fallback
mechanism already envisioned in RFC 2782.  However, it's time to move
forward and instead of extending a bad idea to v6 it should be terminated and
no "fallback" given.  Especially because this is not a legacy service that
existed before SRV was invented and RFC 3489 already included the SRV usage,
there's no need to address "old" v6 clients agnostic of SRV.  Operational
laziness shouldn't be encouraged.
At the very least, the fallback MUST be excluded for explicit "stop" SRV
RRs (those including the "." target).

>    addresses, each of which can be contacted at the default port using
>    UDP or TCP, independent of the STUN usage.  For usages that require
>    TLS, lack of SRV records is equivalent to a failure of the
>    transaction, since the request or indication MUST NOT be sent unless
>    SRV records provided a transport address specifically for TLS.

In the Security Considerations section the usual DNS caveats and threats
should be mentioned, especially since SRV provides a level of indirection
that can't be protected by use of TLS (you might end up to securely talk
to the perfectly authenticated - albeit wrong - server).
Also, even though the mechanism of obtaining the server's domain name
is not specified in the draft, I'd suggest to mention the risk of hardcoding
the domain name in the application software because of the chance to
"loose" a domain name (by accidental expiry, legal action and so on).

-Peter

PS: Unrelated to DNS, aren't there privacy concerns worth mentioning
    because of the opportunity to monitor application usage?
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Mon, 22 Oct 2007 13:41:17 -0400

I have given an initial response to some (but no all) of these points  
inline.

- Philip

On 19-Oct-07, at 04:59 , Magnus Westerlund wrote:

> Date: October 18, 2007 17:59:00  EDT (CA)

Yes. This would improve readability.

> the definition of additional service names.

The use of "stun" for this service was introduced in RFC 3489, and I  
believe that
there is already some deployment today.
As I see it, the problem is that IANA assigned a name of "nat-stun- 
port" for
the assigned port number for STUN, rather than simply "stun".
So my initial thought is to see if IANA has any objections to changing
the name of this port to "stun".

> "protocol-numbers" registry.

How do other protocols handle this issue (wanting to run over both TCP
and TLS over TCP)?

> Priority and Weight) list until a "connection" succeeds, isn't that  

This paragraph was added before I came on board as an author.
However, I believe the concern is as follows. RCC 2782 says:

                 for each address record found, try to connect to the
                (protocol, address, service).

This doesn't say what to do if the attempt fails. Since there are at  
least
conceivably a couple of ways this might be handled in STUN, it seems  
desirable
to be explicit. Thus the document says:
    When following these procedures, if the STUN transaction times out
    without receipt of a response, the client SHOULD retry the  
request to
    the next server in the list of servers from the DNS SRV response.
    Such a retry is only possible for request/response transmissions,
    since indication transactions generate no response or timeout.

> Well, _ordered_ list as of RFC 2782.
I think that you are suggesting that this be reworded as
"the next server in the order defined by RFC 2782".
This seems good.

> not vice versa. I.e., the DNS SRV RR should reflect which port is  

Yes. Good point.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 28 Oct 2007 20:38:43 -0400

Peter,

Thanks for the review. Some additional comments and responses inline:

> Yes. This would improve readability.

fixed.

> As I see it, the problem is that IANA assigned a name of "nat-stun-port" 
> for

I agree. Changing this to 'nat-stun-port' at this time would break 
backwards compatibility with rfc3489; something we have been trying to 
retain, at least for deployed functionality (including this).

> How do other protocols handle this issue (wanting to run over both TCP

The only other solutions I am aware of for this, would be to add NAPTR 
support as a layer on top, or add something akin to STARTTLS to stun, 
both of which I'd rather avoid. Hopefully there is a simpler alternative 
you can suggest.

> This doesn't say what to do if the attempt fails. Since there are at least

Right. This trend, of clarifying failure treatment, was something 
started in RFC 3263 and has carried into most of the DNS behaviors 
described in other RAI-related protocols.

> "the next server in the order defined by RFC 2782".

fixed.

>> not vice versa. I.e., the DNS SRV RR should reflect which port is 

Added a sentence saying this.

>> RRs (those including the "." target).

Its not so much about backwards compatibility as domains that simply 
elect not to deploy SRV. Unfortunately we've seen lots of cases where 
folks just deploy A records and don't use SRV at all. The fallback makes 
the client maximally interopreable.

>> "loose" a domain name (by accidental expiry, legal action and so on).

In fact the text used to describe these standard DNS attacks. However 
the draft was restructured and broken into this core document and into 
usages. As the security considerations section discusses, usages 
actually need to do the analysis to see what attacks apply. For example 
one stun usage doesn't use the DNS mechanism at all and so the attack 
doesnt apply. ICE does use it, and the attack you mention is described 
there.

I mentioned that the domain name should not be hard coded.

>>     because of the opportunity to monitor application usage?

STUN attacks whereby an attacker can intercept traffic to monitor it, 
are described as part of the usage. ICE disucsses this attack for example.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com