Re: [tram] New Version Notification for draft-patil-tram-turn-serv-disc-01.txt

[Brandon Williams <[e-mail]>]

I would be more concerned about anycast timing out than DNS. If the dns 
server exists but has no answer, it will tell you. I think you would 
only need a timeout for non-existent DNS servers. On the other hand, the 
only way you know that the anycast address doesn't work is a timeout 
waiting for a response. You could use an ICMP ttl-exceeded response, but 
they aren't reliably sent or delivered.

I would argue strongly against MUST for supporting anycast, because of 
the security issues that have been raised. I would say SHOULD support, 
and those that do MUST allow users to define security policies that 
prohibit using anycast.

--Brandon

On 05/19/2014 07:05 AM, Karl Stahl wrote:
>> require a round-trip between...
> - I wasn't concerned about round-trips, but rather possible time-outs when
> there is nothing to find - I haven't really checked (concerned about that we
> don't specify something slow creating a need to trickle or something)
>
> Regarding multiple methods and TTL limitation, is the intention of this
> draft that it may/could be used by rtcweb as:
> "... webrtc browsers MUST use turn servers discovered by the anycast method
> in draft-patil-tram-turn-serv-disc-01.txt with TTL limitation set to 3..." ?
>
> /Karl
>
>
> -----Ursprungligt meddelande-----
> Från: tram [mailto:[e-mail]] För Brandon Williams
> Skickat: den 19 maj 2014 10:48
> Till: [e-mail]
> Ämne: Re: [tram] New Version Notification for
> draft-patil-tram-turn-serv-disc-01.txt
>
> I'm not sure how realistic it is to define a specific TTL limitation.
> That assumes a perhaps unrealistic degree of uniformity in both the local
> network implementation and the ISP network implementation.
>
> Regarding whether multiple methods should be in the spec, one other
> important question to answer is whether all of the proposed methods have
> identical security properties. There were some security limitations for
> anycast (at least the well-known-address version) discussed on the list.
> These security limitations still need some discussion in the draft.
>
> Regarding connect time, in what way is the anycast method faster than name
> resolution? Under some conditions it may be faster, but typically it will
> require an extra round-trip between the client and the anycast address just
> as name resolution will require a round-trip between the client and the DNS
> server.
>
> --Brandon
>
> On 05/18/2014 08:43 AM, Karl Stahl wrote:
>> I browsed through this document and to me it looks mature enough to be
>> pushed forward (hopefully soon) to get an IANA anycast address etc.,
>> so these things can be put into current WebRTC browsers. As we know,
>> many enterprises cannot use WebRTC at all today due to their
>> restrictive firewall policies - they need a TURN server on their LAN,
>> discovered and used by the WebRTC browsers to even begin using WebRTC.
>>
>> However, I raised a few questions and some suggestions
>> http://www.ietf.org/mail-archive/web/tram/current/msg00480.html
>> at the end of the previous version of this draft that never became
>> discussed and remain:
>>
>> A) Under 8.2 there is a suggested way to assure that the TURN server
>> returned by the anycast method, is provided by the network provider
>> (and not some far away TURN server that should not be trusted to use
>> without authentication): "... can set an IP TTL on their TURN requests
>> that limits how far they can travel into the public Internet."
>>
>> I suggest that this TTL limitation is specified (e.g. Don't look
>> further than 3 steps - local firewall + max 2 ISP routers) and brought
>> into section "5. Discovery using Anycast" of the draft.
>>
>> B) Shall we really have more than one method? If the Anycast method
>> can be used by everyone, why then also have DHCP and now a two more
> methods?
>>
>> I assume you intend that all webrtc browsers implement and can use all
>> methods? Or? (If a service provider e.g. deploys DHCP discovered TURN
>> servers, but some webrtc browser in some operating system don't
>> find/cannot use the TURN server, it would be bad.)
>>
>> In previous discussions, there were some fears that DHCP options are
>> not available in some common OSs. If so, I think the DHCP method
>> should be skipped.
>>
>> Also, if the other methods (other than anycast) may fail, why have them?
>> Are they better to deploy and provision for network service providers?
>>
>> And will webrtc browsers implement all these methods?
>>
>> Do we have input/feedback on these questions?
>>
>> Should the "connect speed factor" not also be considered? Even though
>> the auto discovery can be done in advance of a call, we should
>> consider the mobility use case. With a mobile client changing network,
>> LAN/LTE/public WiFi etc., we want to get up and run as soon as
>> possible, so the auto discovery of a new TURN server should not be a
>> tedious process
>>
>> And should the quick anycast auto discovery not be the first to be
>> tried/used (which it is not now in the draft)?
>>
>> C) I noticed that referenced I-D.ietf-geopriv-res-gw-lis-discovery
>> is now RFC7216.
>>
>> /Karl
>>
>>
>> -----Ursprungligt meddelande-----
>> Från: tram [mailto:[e-mail]] För Prashanth Patil
>> (praspati)
>> Skickat: den 2 maj 2014 12:02
>> Till: [e-mail]
>> Ämne: [tram] FW: New Version Notification for
>> draft-patil-tram-turn-serv-disc-01.txt
>>
>> A new revision of the TURN server discovery draft has been published.
>> Notable updates :
>>
>> * 300 (Try Alternate) response for anycast.
>> * Mechanism described in draft-kist-alto-3pdisc i.e. using the clients
>> own address to populate the DNS reverse zone (i.e., in-addr.arpa or
>> ip6.arpa) with appropriate NAPTR records pointing to the TURN server.
>> * Learning domain names from own identity.
>>
>> -Prashanth
>>
>>
>> On 5/2/14 3:25 PM, "[e-mail]"
>> <[e-mail]>
>> wrote:
>>
>>>
>>> A new version of I-D, draft-patil-tram-turn-serv-disc-01.txt
>>> has been successfully submitted by Prashanth Patil and posted to the
>>> IETF repository.
>>>
>>> Name:		draft-patil-tram-turn-serv-disc
>>> Revision:	01
>>> Title:		TURN Server Auto Discovery
>>> Document date:	2014-05-02
>>> Group:		Individual Submission
>>> Pages:		11
>>> URL:
>>> http://www.ietf.org/internet-drafts/draft-patil-tram-turn-serv-disc-0
>>> 1.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-patil-tram-turn-serv-disc/
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-patil-tram-turn-serv-disc-01
>>> Diff:
>>> http://www.ietf.org/rfcdiff?url2=draft-patil-tram-turn-serv-disc-01
>>>
>>> Abstract:
>>>     Current Traversal Using Relays around NAT (TURN) server discovery
>>>     mechanisms are relatively static and limited to explicit
>>>     configuration.  These are usually under the administrative control of
>>>     the application or TURN service provider, and not the enterprise or
>>>     the ISP, the network in which the client is located.  Enterprises and
>>>     ISPs wishing to provide their own TURN servers need auto discovery
>>>     mechanisms that a TURN client could use with no or minimal
>>>     configuration.  This document describes two such mechanisms for TURN
>>>     server discovery.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.