Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action: draft-ietf-tram-turn-server-discovery-12.txt

[Karl Stahl <[e-mail]>]

Regarding (D)TLS: 

Brandon, the "explicit administrator choice" text in version -12 is the only
thing I have attributed to you as "I don’t think Brandon or anyone asked for
such impossibilities" and I think what you say below is just that. Let's not
make too much about that.


The real things about the STUN Authentication (in addition to introducing
this (D)TLS "impossibility use case" ) are:

1) (D)TLS mandate was thrown in during the DISCUSS and broke the -07 text
consensus, where STUN Authentication was not required for network provided
TURN servers in the local or access network (no (D)TLS was suggested - that
is for validation, not for authentication) 

2) The STUN Authentication downgrade was (correctly) declared first during
discuss (although it happened with version -07), and the "IP Authentication"
(that automatically the users belonging to the local or access network have,
was (correctly) spelled out during the discuss as "A TURN server in such
cases must be configured to only process STUN
   requests from the trusted local network or subscribers of the access
   network.  Operational measures must be taken in order protect the
   TURN server; some of these measures include, but not limited to,
   access control by means of access-lists, firewalls, subscriber quota
   limits, ingress filtering etc."
  
3) The (D)TLS mandate thrown in during the discuss does other things than
compensate for the STUN Authentication, and was later (by Authors) reduced
to fixing vulnerability for spoofing (-12 text), and the -12 text's
mandating (D)TLS in some situations.

4) However, for eliminating the spoofing vulnerability, introduced (D)TLS is
still not good (CPU hunger, thus DOD/DDOS vulnerable, trust anchor or
certificate seldom available), while Oleg's Dummy Authentication does the
job and has none of the drawbacks. 

This is introduced in the red-lined version -12 and is a way bring back
consensus if agreed upon.

/Karl




-----Ursprungligt meddelande-----
Från: Brandon Williams [mailto:[e-mail]] 
Skickat: den 12 februari 2017 17:25
Till: Karl Stahl; 'Tirumaleswar Reddy (tireddy)'; 'Simon Perreault';
'Spencer Dawkins at IETF'
Kopia: [e-mail]
Ämne: Re: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
draft-ietf-tram-turn-server-discovery-12.txt

Hi Karl,

Regarding the "explicit administrator choice" part of the text, I think 
the point is not that an application MUST NOT blindly fall back to 
cleartext, but instead MUST give the admin and/or user some control. 
There are a variety of ways this could be accomplished. Tiru's 
suggestion in the earlier e-mail is just one of those. I don't think the 
draft needs to describe a specific method; it's up to the application 
developer to choose a method that best meets user needs.

--Brandon

On 02/10/2017 08:20 AM, Karl Stahl wrote:
> Hi Tiru, below again
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 10 februari 2017 05:57
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail]
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Friday, February 10, 2017 6:53 AM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Tiru, please see [Karl] inlines after your inlines.
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 9 februari 2017 15:34
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail] <mailto:[e-mail]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> Please see inline
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Thursday, February 9, 2017 6:22 PM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Tiru,
>
>
>
> Each of your three sentences are incorrect.
>
>
>
> And,
>
>> updated in 12 version to say that (D)TLS is not mandatory to use if the
> network infrastructure can defend against the attacks discussed in
RFC5766.
>
>
>
> --- And in addition It breaks the version -07 consensus text regarding
> (D)TLS usage in this situation, by introducing “MUST” for (D)TLS usage
> under 9:
>
> ...and therefore MUST NOT be used for privacy sensitive communication.
>
> ...but MUST NOT fall back without explicit administrator choice.
>
> ...but MUST NOT fall back without explicit administrator choice.
>
> and my question how the “explicit administrator choice”  is supposed to
> happen in an enterprise environment or at an internet café is not
answered.
>
>
>
> [TR] Explicit administrator choice means the user is notified about the
> failure and fallback happens only after consent from the user (i.e. the
> user needs to know that fallback happens to a less secure mechanism).
>
> [Karl] I suggest “administrator” is then changed to “user” so it is not
> interpreted as the network administrator, in a version -13 of the draft.
>
>
>
> [TR2] Sure, I can update draft.
>
> [Karl2] But please notice, that this only clarifies the draft, it is
> still a nuisance for a user and a general webRTC browser (that will be
> used under such conditions) and that was not what Brandon or anyone else
> asked for. Recommending the STUN dummy authentication instead, resolves
> the (D)TLS break of consensus of the version -07 text, including the
> performance concerns raised by Pal-Erik and others, as well as other
> objections.
>
>
>
> - I don’t think Brandon or anyone asked for such impossibilities (which
> again seem to be created to make this specification unusable for its
> purpose).
>
>
>
> Please note that to my knowledge, (D)TLS usage is not mandated  for any
> usage of TURN servers anywhere, and (again) this draft – that should
> specify DISCOVERY – cannot MANDATE USAGE. None of the discovery methods
> do (and cannot)  use (D)TLS (that discussion is for USAGE, AFTER the
> DISCOVERY).
>
>
>
> [TR2] Other drafts do not mandate (D)TLS because RFC5766 mandates STUN
> authentication, this draft updates RFC5766 by saying STUN authentication
> is not mandatory hence it is mandating (D)TLS.
>
> [Karl2] Yes, we agree. It is only this draft, version -10 to -12 draft
> that suggests to mandate usage of (D)TLS (Please free us from that)
>
>
>
> [TR] No, (D)TLS is only mandated if the network infrastructure cannot
> defend against the attacks discussed in RFC5766.
>
> [Karl] That is already clear in the -12 version. My comment remains (In
> addition to being wrong, I meant it is also strange (and unnecessary,
> considering that dummy authentication can achieve it better) if this
> DISCOVERY draft would mandates (D)TLS for TURN server usage in a certain
> situation, when no other draft mandates (D)TLS for usage of TURN servers.)
>
>
>
> [TR2] I don’t agree with your comments and don’t plan to make any
> changes to (D)TLS related text in the draft unless I hear otherwise from
> other WG members and chairs.
>
>
>
> [Karl] While producing the above suggested -13 of the draft, I also
> suggest you also include all the redlining I proposed (and no one has
> objected against) and I think we will have a draft that can be accepted
> to become an RFC.
>
>
>
> [TR2] I reject your all your other proposed changes including anycast,
> don’t see any merit in your arguments
>
> [Karl2] … and ignoring Brandon’s:
>
>> It is true that you have provided a justification for the change.
>
>> My  point is that the small set of people…
>
> As responded to:
>
>>> [Karl Justification is in the (A), (B), (C) and (D) of
>
>>> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>
>>> where saying Binding instead Allocate, is necessary to achieve (A) and
(B), and improves (C) and (D).
>
>
>
> and will let the WG chairs decide how to proceed with the draft.
>
>
>
> [Karl2] Well, we need a specification that is defined and fulfill its
> purpose and thus can be made an RFC.
>
> Can you specify what and explain why any of the red lined suggestions to
> the version -12 text would go against this (or is there nothing)?
>
> (As a guidance to those you ask for “decide how to proceed with the
draft.”)
>
>
>
> /Karl
>
>
>
> -Tiru
>
>
>
> Thanks,
>
> Karl
>
>
>
> -Tiru
>
>
>
> The read lined -12 version is cleared from these and other flaws or
> mistakes.
>
>
>
> We should focus on whether the red lined version is anything but
> improvements and adds no drawbacks over version -12 of the draft.
>
>
>
> /Karl
>
>
>
> PS: Regarding the non working anycast method, **since I highlighted in
> August 8, 2016, all from the Author’s at the WG list is**:
>
> October 18, 2016 (from Prashanth to me and others during the discuss):
>  We intend to add the following to explain server behavior a little
better:
>
> “A TURN anycast server performs checks 1 to 7 discussed in Section 6.2
> of RFC5766. If all checks pass, the TURN anycast server MUST respond
> with a 300 (Try Alternate) error as described in [RFC5766];”
>
> November 15, 2016  (to something from Brandon): Agreed. -Tiru
>
> November 18, 2016 (to something from Brandon): +1, don't see a need for
> alternate mechanism. -Tiru
>
> December 22, 2016 Hi Karl, I don’t understand why the mechanism where
> TURN server has both anycast and unicast address for re-direction won’t
> work ? Cheers, -Tiru
>
> Now February 7, 8, 2016 See below
>
>
>
>
>
> *Från:*Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> *Skickat:* den 8 februari 2017 09:51
> *Till:* Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> *Kopia:* [e-mail] <mailto:[e-mail]>
> *Ämne:* RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> Hi Karl,
>
>
>
> We have gone over the same points over and over again and I don’t see a
> need to document the discussion b/w you and Simon, they are only
> operational considerations and have no impact on the protocol.
>
>
>
> Secondly, there is no consensus on your proposed new anycast mechanism
> and WG members have opposed your new anycast mechanism.
>
>
>
> Regarding (D)TLS, the draft is updated in 12 version to say that (D)TLS
> is not mandatory to use if the network infrastructure can defend against
> the attacks discussed in RFC5766. This update addresses comments
> received from Brandon.
>
>
>
> -Tiru
>
>
>
> *From:*Karl Stahl [mailto:[e-mail]]
> *Sent:* Wednesday, February 8, 2017 12:28 PM
> *To:* Tirumaleswar Reddy (tireddy) <[e-mail]
> <mailto:[e-mail]>>; 'Simon Perreault' <[e-mail]
> <mailto:[e-mail]>>; 'Spencer Dawkins at IETF'
> <[e-mail] <mailto:[e-mail]>>
> *Cc:* [e-mail] <mailto:[e-mail]>
> *Subject:* SV: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
> 1) The A)+B) method (that Simon and I discussed) is not specified in the
> draft -12 text and further referencing:
>
> [Tiru below]> "https://tools.ietf.org/html/rfc7094#section-3.4
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rf
c7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuad
q6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LE
hCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar mechanism" does not help:
>
> - It rather states issues coming from not knowing whether a server
> reached by anycast addressing, actually is at a unicast address or
> really is deployed at a anycast address (which I believe is rare).
>
>
>
> 2) Further, there are no deployment considerations for the A)+B) method
> in the –12 draft (compare the redlined version)
>
> It does not even discuss or list  RFC7478 (Web Real-Time Communication
> Use Cases and Requirements) that it is supposed to meet, but which the
> A)+B) method is in conflict with.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02314.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02314.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=JUvi1vp2Im171VnwziFnhFyKRHdWeOyx5urNi9JOG9w&e=>
> and https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>.
>
>
>
>
>
>
> 3) And if the (more complex) A)+B) method would be properly defined and
> described in some future revision, then remains (from
> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>):
>
> “(trying to) exemplify/clarify the high level (important) points why we
>
> need/want anycast discovery by saying Binding instead of Allocate. These
>
> points are:
>
>
>
> (A) We need an anycast discovery method for auto-discovering "a TURN
server"
>
> (not some special TURN server or arrangement of TURN servers "invented"
for
>
> being discoverable by a certain method)
>
>
>
> (B) We need an anycast discovery method for a TURN server that is
>
> setup/installed/configured for its USAGE (which is relaying traffic) - not
>
> requiring a special network configuration just for being discoverable.
(And
>
> more widely, it must be the goal of this specification to provide at least
>
> one discovery method that works for ALL network types and configurations,
>
> where a network provided TURN server may be useful - I see only anycast
>
> using Binding for querying *the TURN server's* unicast address fulfilling
>
> this.)
>
>
>
> (C) Robust (tolerant) deployment is highly preferable.
>
>
>
> (D) Ease of deployment is highly preferable.
>
>
>
> Saying Binding instead Allocate, is necessary to achieve (A) and (B), and
>
> improves (C) and (D).”
>
>
>
> 4) The (D)TLS text in version -12 does not have consensus either.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
> and
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>
> Against my red lined (D)TLS changes, I have heard no objections (just as
> with the red lined anycast method).
>
>
>
> /Karl
>
>
>
>
>
> -----Ursprungligt meddelande-----
> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
> Skickat: den 7 februari 2017 12:02
> Till: Karl Stahl; 'Simon Perreault'; 'Spencer Dawkins at IETF'
> Kopia: [e-mail] <mailto:[e-mail]>
> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D
> Action: draft-ietf-tram-turn-server-discovery-12.txt
>
>
>
>> -----Original Message-----
>
>> From: tram [mailto:[e-mail]] On Behalf Of Karl Stahl
>
>> Sent: Tuesday, February 7, 2017 4:02 PM
>
>> To: Tirumaleswar Reddy (tireddy) <[e-mail]
<mailto:[e-mail]>>; 'Simon Perreault'
>
>> <[e-mail] <mailto:[e-mail]>>; 'Spencer Dawkins at
IETF'
>
>> <[e-mail] <mailto:[e-mail]>>
>
>> Cc: [e-mail] <mailto:[e-mail]>
>
>> Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D
Action:
>
>> draft-ietf-tram-turn-server-discovery-12.txt
>
>>
>
>> Tiru,
>
>>
>
>> That does not make the version -12 text in the draft any clearer about
what
>
>> the draft's anycast method actually is. I am asking you the same question
as I
>
>> asked Simon before (and only he answered):
>
>
>
> I agree with the responses Simon has already provided to all the below
> questions. Further, I also don't see the need to discuss the below
> questions in the draft because they are only operational considerations
> (and have no impact on the actual protocol).
>
>
>
> -Tiru
>
>
>
>>
>
>> Does the draft assume:
>
>>
>
>> (A) a TURN server listening to TWO IP addresses (that are at different
>
>> subnets) that can respond error 300 or make an allocation, distinguished
by
>
>> whether the request was received on its anycast address or its unicast
>
>> address, OR
>
>>
>
>> (B) we really have TWO TURN servers to play with (the one at the anycast
>
>> address being configured to respond with the error 300, OR
>
>>
>
>> (C) the FIRST Allocate is responded to with error 300 and SUBSEQUENT
>
>> Allocates actually are making TURN allocations.
>
>>
>
>>
>
>> We cannot have an RFC, not even being clear about the method specified.
>
>>
>
>> /Karl
>
>>
>
>>
>
>> -----Ursprungligt meddelande-----
>
>> Från: Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>
>> Skickat: den 7 februari 2017 07:18
>
>> Till: Simon Perreault; Karl Stahl; 'Spencer Dawkins at IETF'
>
>> Kopia: [e-mail] <mailto:[e-mail]>
>
>> Ämne: RE: [tram] Chime in on attched redlined version-12 WAS: I-D Action:
>
>> draft-ietf-tram-turn-server-discovery-12.txt
>
>>
>
>> > -----Original Message-----
>
>> > From: Simon Perreault [mailto:[e-mail]]
>
>> > Sent: Friday, February 3, 2017 7:13 PM
>
>> > To: Karl Stahl <[e-mail] <mailto:[e-mail]>>;
'Spencer Dawkins
> at IETF'
>
>> > <[e-mail] <mailto:[e-mail]>>
>
>> > Cc: [e-mail] <mailto:[e-mail]>; Tirumaleswar Reddy (tireddy)
> <[e-mail] <mailto:[e-mail]>>
>
>> > Subject: Re: [tram] Chime in on attched redlined version-12 WAS: I-D
>
>> Action:
>
>> > draft-ietf-tram-turn-server-discovery-12.txt
>
>> >
>
>> > Karl,
>
>> >
>
>> > There is no consensus in the working group behind this new anycast
>
>> > mechanism. Therefore it can not be added to the draft, and the
>
>> > mechanism defined in RFC 5766 remains.
>
>>
>
>> Yup, https://tools.ietf.org/html/rfc7094#section-3.4
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rf
c7094-23section-2D3.4&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuad
q6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=LE
hCEnJWTs-58S-OzhGCxFlWFoO_AZ4jL2d87B7k3xQ&e=>
> also discusses similar
>
>> mechanism.
>
>> I don't see the need for a new anycast mechanism.
>
>>
>
>> -Tiru
>
>>
>
>> >
>
>> > Thanks,
>
>> > Simon
>
>> >
>
>> > Le 2017-02-02 à 18:23, Karl Stahl a écrit :
>
>> > > The -12 version of the draft does not include major remedies of
>
>> > > flaws that were un-addressed long before the DISCUSS, nor the latest
>
>> > > regarding the possible use of (D)TLS for auto discovered turn
>
>> > > servers provided the local or access network administrator, see
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02216.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02216.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=OR288fay15EdJ063J_GCuNOt-SScDC5CylZsleLjXbU&e=>
>
>> > >
>
>> > >
>
>> > >
>
>> > > For the latest discussed, see
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02279.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02279.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=B9ST_TVehqEC-PVjUMsDQsxLBNgTStctSmVvmqi39zo&e=>
>
>> > >
>
>> > >>> However, I think we need agreement on the justification for such a
>
>> > >
>
>> > >> change.
>
>> > >
>
>> > >> [Karl] Justification is in the (A), (B), (C) and (D) of
>
>> > >
>
>> > >> https://www.ietf.org/mail-archive/web/tram/current/msg02254.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02254.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=6wGc9_uIIPqbsHUbmZTBpKSjwodRuQSnNsTmPnRd33Q&e=>
>
>> > >
>
>> > >> where saying Binding instead Allocate, is necessary to achieve (A)
>
>> > >> and
>
>> > > (B), and improves (C) and (D).
>
>> > >
>
>> > >
>
>> > >
>
>> > > Brandon> It is true that you have provided a justification for the
>
>> change.
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02296.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02296.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=3U7eSkgvs4w6NXK3vLX4Dlc7ZAwSIBMZ3bMsJDzqlkc&e=>
>
>> > >
>
>> > > The (D)TLS mandating was Author's idea to throw into version -10
>
>> > > during the discuss and remains in this version -11, breaking the
>
>> > > consensus text since version -7.
>
>> > >
>
>> > >
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02297.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02297.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=i7d7dLfsouxgahM92augLVbvLcurGOxKgbJ6qnzCIZw&e=>
>
>> > >
>
>> > > STUN dummy authentication instead of (D)TLS as suggested by Oleg
>
>> > > Moskalenko
>
>> > >
>
>> > >
>
>> > >
>
>> > >
>
>> > >
>
>> > > I have inserted my (now edited and adopted to the latest) redlining,
>
>> > > removal of blue options etc. into the -12 draft text as attached,
>
>> > > for the author to copy from and paste.
>
>> > >
>
>> > >
>
>> > >
>
>> > > Without my red lining, current version -12 is in conflict with
>
>> > > RFC7478 (Web Real-Time Communication Use Cases and Requirements)
>
>> > > and does
>
>> > not
>
>> > > meet the need of [I-D.ietf-rtcweb-return] (Recursively Encapsulated
>
>> > > TURN) (see under redlined 7.2)
>
>> > >
>
>> > > and it does not do what was set out in the Charter and "Milestone 3:
>
>> > > TURN server auto-discovery mechanism for enterprise and ISPs"
>
>> > >
>
>> > >
>
>> > >
>
>> > > Further, the authors have in version -12 (compared to from before
>
>> > > DISCUSS)  changed the text "  6.  Discovery using Anycast " to:
>
>> > >
>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w
0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4
f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
>> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > > "IP anycast can also be used for TURN service discovery.  A packet
>
>> > >
>
>> > >    sent to an anycast address is delivered to the "topologically
>
>> > >
>
>> > >    nearest" network interface with the anycast address.  Using the
>
>> > > TURN
>
>> > >
>
>> > >    anycast address, the only two things that need to be deployed in
>
>> > > the
>
>> > >
>
>> > >    network for discovery are the two things that actually use TURN.
>
>> > >
>
>> > >
>
>> > >
>
>> > >    When a client requires TURN services, it sends a TURN allocate
>
>> > >
>
>> > >    request to the assigned anycast address.  A TURN anycast server
>
>> > >
>
>> > >    performs checks 1 to 7 discussed in Section 6.2 of [RFC5766].  If
>
>> > > all
>
>> > >
>
>> > >    checks pass, the TURN anycast server MUST respond with a 300 (Try
>
>> > >
>
>> > >    Alternate) error as described in Section 2.9 of [RFC5766]; The
>
>> > >
>
>> > >    response contains the TURN unicast address in the
>
>> > > ALTERNATE-SERVER
>
>> > >
>
>> > >    attribute.  For subsequent communication with the TURN server,
>
>> > > the
>
>> > >
>
>> > >    client uses the responding server's unicast address.  This has to
>
>> > > be
>
>> > >
>
>> > >    done because two packets addressed to an anycast address may
>
>> > > reach
>
>> > >
>
>> > >    two different anycast servers.  The client, thus, also needs to
>
>> > >
>
>> > >    ensure that the initial request fits in a single packet.  An
>
>> > >
>
>> > >    implementation may choose to send out every new TURN Allocation
>
>> > >
>
>> > >    request to the anycast address to discover the closest and the
>
>> > > most
>
>> > >
>
>> > >    optimal unicast address for the TURN server."
>
>> > >
>
>> > >
>
>> > >
>
>> > > The highlighted "A TURN anycast server"  isnothing known nor
>
>> > > described (in fact there would have to be TWO TURN servers, one
>
>> > > deployed at the anycast address and another TURN server deployed at
>
>> > > the unicast address, reacting differently to the Allocation request)
>
>> > > for this to work as clarified in WG discussions with Simon).
>
>> > >
>
>> > >
>
>> > >
>
>> > > The last sentence "An  implementation may choose to send out every
>
>> > > new TURN Allocation request to the anycast address to discover the
>
>> > > closest and the most optimal unicast address for the TURN server."
>
>> > > violates security and deployment considerations (see red lined
>
>> > > considerations in attached).
>
>> > >
>
>> > >
>
>> > >
>
>> > > Further, the authors have in version -12 (compared to from before
>
>> > > DISCUSS)  changed the text "7.2.  Recursively Encapsulated TURN " to:
>
>> > >
>
>> > > https://tools.ietf.org/rfcdiff?url1=draft-ietf-tram-turn-server-disc
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_rfcdiff
-3Furl1-3Ddraft-2Dietf-2Dtram-2Dturn-2Dserver-2Ddisc&d=DwMFAw&c=96ZbZZcaMF4w
0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4
f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=AMYCMt0k9_YCuab2JldMPgDJsb5neZZkNIlStXCjJGQ&e=>
>
>> > > ov ery-09.txt&url2=draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > > "WebRTC endpoints SHOULD treat any TURN server discovered through
>
>> > the
>
>> > >
>
>> > >    mechanisms described in this specification as an
>
>> > > enterprise/gateway
>
>> > >
>
>> > >    or access network server, in accordance with Recursively
>
>> > > Encapsulated
>
>> > >
>
>> > >    TURN [I-D.ietf-rtcweb-return]."
>
>> > >
>
>> > >
>
>> > >
>
>> > > The text is a contradiction, since the return draft deals with TURN
>
>> > > servers provided by the local or access network, not other TURN
>
>> > > servers discovered by this draft.
>
>> > >
>
>> > >
>
>> > >
>
>> > > *Current -12 draft cannot be considered to be an RFC!*
>
>> > >
>
>> > >
>
>> > >
>
>> > > I suggest the redline version of draft -12 attached is chimed into
>
>> > > now and quickly merged into a version -13, so we can avoid the
>
>> > > "Conflict Resolution and Appeals"process hinted about in
>
>> > >
>
>> > > https://www.ietf.org/mail-archive/web/tram/current/msg02202.html
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Dar
chive_web_tram_current_msg02202.html&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ
-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut
0vfDR2W-L4&s=d3MIEALshSLyuVc0Tp0U_RBYISTdX2sF-YW4oVWzUk4&e=>,
>
>> > > further delaying what is needed for Internet real-time communication
>
>> > > and especially for WebRTC.
>
>> > >
>
>> > >
>
>> > >
>
>> > > /Karl
>
>> > >
>
>> > >
>
>> > >
>
>> > > *Från:*tram [mailto:[e-mail]] *För *Spencer Dawkins at
>
>> > > IETF
>
>> > > *Skickat:* den 1 februari 2017 22:12
>
>> > > *Till:* Simon Perreault
>
>> > > *Kopia:* [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>;
> Tirumaleswar Reddy
>
>> > > (tireddy)
>
>> > > *Ämne:* Re: [tram] I-D Action:
>
>> > > draft-ietf-tram-turn-server-discovery-12.txt
>
>> > >
>
>> > >
>
>> > >
>
>> > > Hi, Simon,
>
>> > >
>
>> > >
>
>> > >
>
>> > > On Thu, Feb 2, 2017 at 6:00 AM, Simon Perreault <[e-mail]
>
>> > > <mailto:[e-mail]>> wrote:
>
>> > >
>
>> > > Le 2017-02-01 à 15:37, Spencer Dawkins at IETF a écrit :
>
>> > >> Dear TRAMsters,
>
>> > >>
>
>> > >> On Fri, Jan 13, 2017 at 12:59 PM, Tirumaleswar Reddy (tireddy)
>
>> > >> <[e-mail]
>
>> > >> <mailto:[e-mail]><mailto:[e-mail]
>
>> > > <mailto:[e-mail]>>> wrote:
>
>> > >>
>
>> > >>     This revision addresses comments from Brandon.
>
>> > >>
>
>> > >>     -Tiru
>
>> > >>
>
>> > >>
>
>> > >> How close are we to asking Terry to clear the (last remaining)
DISCUSS?
>
>> > >
>
>> > > Thanks for the reminder.
>
>> > >
>
>> > > If my co-chair and the authors have no objection, I think we're
ready.
>
>> > >
>
>> > >
>
>> > >
>
>> > > I'll give this 24 hours for people to chime in, but I do want to
>
>> > > ping Terry.
>
>> > >
>
>> > >
>
>> > >
>
>> > > It's a little-appreciated thing, but AD ballot positions go away
>
>> > > when ADs go away; this document has 12 yes/no objections now, and
>
>> > > you need
>
>> > > 10 for approval, and three are from ADs who are stepping down in
>
>> > > March
>
>> > > ;-)
>
>> > >
>
>> > >
>
>> > >
>
>> > > Spencer
>
>> > >
>
>> > >
>
>> > >
>
>> > > _______________________________________________
>
>> > > tram mailing list
>
>> > > [e-mail] <mailto:[e-mail]>
>
>> > > https://www.ietf.org/mailman/listinfo/tram
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler
_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>> > >
>
>> >
>
>> >
>
>> > --
>
>> > Simon Perreault
>
>> > Director of Engineering, Platform | Jive Communications, Inc.
>
>> > https://jive.com
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__jive.com&d=DwMFAw&c=96
ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=sqEvIjW
-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=6xMRYWWn81v-P_m3BZY8GMOvpo0ygL0wYykEs
xKd66Q&e=>
> | [phone] ext. 1241 | [e-mail]
> <mailto:[e-mail]>
>
>>
>
>> _______________________________________________
>
>> tram mailing list
>
>> [e-mail] <mailto:[e-mail]>
>
>> https://www.ietf.org/mailman/listinfo/tram
>
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_l
istinfo_tram&d=DwMFAw&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgw
bBVUJa4mZfmEIBXg&m=sqEvIjW-bn_4s0Ne4f7nTfFUk9gw5o1Ut0vfDR2W-L4&s=vmtm5H-2Ler
_5PEKhheo-ob_Eiz6enqyiOnHkAKZjxQ&e=>
>
>
>
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram
>

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.