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

On 5/6/14 9:55 AM, Prashanth Patil (praspati) wrote:
>
>
> On 5/3/14 12:13 AM, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
>
>> There is another possible mechanism for retrieving a domain name for
>> service discovery that isn't mentioned. It is analogous to "From own
>> Identity". I guess I would call it "From target identity". In the case
>> of SIP it would be to use the domain name of the To-URI.
>>
>> This would be useful when a domain wants to make itself be reachable
>> even from clients that have no better way of discovering a TURN server.
>>
>> In general it is probably better to use one of the other techniques when
>> possible, because the result can be used to talk to any target. But this
>> is still a good option when the others fail. And it should be attractive
>> to servers that want to maximize their reachability.
>>
>> (I mentioned this one before, some time ago, but I guess it got lost
>> along the way.)
>>
>> Is there any reason not to include this as 4.1.4?
>
> The intent was to provide best possible means to discover TURN offered by
> your domain/network, 'from target identity' was hence not included.

I didn't see anything in the description of service discovery that 
limited it that way.

> Not necessarily within the scope of server discovery, but on what basis
> would the TURN server from target domain allow requests from unknown users?

What I had in mind was that this service could be provided by the target 
domain for the benefit of those attempting to reach it. The goal being 
to maximize its reachability, even from clients that cannot discover a 
turn service at the source end.

I guess what you are suggesting is that somebody might abuse this, 
discovering this TURN server and then using it to contact some unrelated 
party.

I haven't thought about it a lot, but perhaps it could arrange to only 
work when the other end is within the domain it supports.

	Thanks,
	Paul

> -Prashanth
>
>
>>
>> 	Thanks,
>> 	Paul
>>
>> On 5/2/14 6:02 AM, Prashanth Patil (praspati) wrote:
>>> 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, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
>>> 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-01.t
>>>> xt
>>>> 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
>>> tram@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tram
>>>
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>
>