Subject: Re: [tram] Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)

From: [email-masked]
Date: Thu, 1 Sep 2016 08:07:13 -0400

Sent from my iPhone

On Aug 31, 2016, at 3:02 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:

>> -----Original Message-----
>> From: Kathleen Moriarty [mailto:[email-masked]]
>> Sent: Monday, August 29, 2016 7:20 PM
>> To: The IESG <[email-masked]>
>> Cc: [email-masked]; Simon Perreault
>> <[email-masked]>; [email-masked]; [email-masked];
>> [email-masked]
>> Subject: Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-discovery-
>> 09: (with DISCUSS)
>> 
>> Kathleen Moriarty has entered the following ballot position for
>> draft-ietf-tram-turn-server-discovery-09: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discovery/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> This should be easy to resolve.  In reading the draft, it doesn't cover any
>> mechanism for the TURN server to limit what clients can discover it.
>> For the second and third method, it seems like there are possible ways to do
>> this.  Could these be added to the security considerations?  You'd need to
>> state that this isn't possible with the first method.  If there is a reason why it is
>> always okay to discover a TURN server, please let me know why this is not
>> appropriate to add.  Thanks.
> 
> I don't see a reason why TURN server discovery should be restricted only to specific clients. Please explain the scenarios for imposing such restrictions.

Hello Tiru,

Are there any cases where some domains or addresses should be restricted?  When you have open services, it's possible to attack them.  It could be from a design or implementation problem that makes an exploit possible or it might just be for network reconnaissance.  Is there something different about TURN servers that makes this point moot.

Thank you,
Kathleen 
> Cheers,
> -Tiru

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 7 Sep 2016 03:27:55 +0000

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, September 1, 2016 5:37 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> Simon Perreault <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Kathleen Moriarty's Discuss on draft-ietf-tram-turn-server-
> discovery-09: (with DISCUSS)
> 
> 
> 
> Sent from my iPhone
> 
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut
> >> this introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> >> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> This should be easy to resolve.  In reading the draft, it doesn't
> >> cover any mechanism for the TURN server to limit what clients can
> discover it.
> >> For the second and third method, it seems like there are possible
> >> ways to do this.  Could these be added to the security
> >> considerations?  You'd need to state that this isn't possible with
> >> the first method.  If there is a reason why it is always okay to
> >> discover a TURN server, please let me know why this is not appropriate to
> add.  Thanks.
> >
> > I don't see a reason why TURN server discovery should be restricted only to
> specific clients. Please explain the scenarios for imposing such restrictions.
> 
> Hello Tiru,
> 
> Are there any cases where some domains or addresses should be restricted?

Yes.

> When you have open services, it's possible to attack them.  It could be from a
> design or implementation problem that makes an exploit possible or it might
> just be for network reconnaissance.  Is there something different about TURN
> servers that makes this point moot.

Restricting access to use the TURN server seems more important than discovering the TURN server; will add more details that TURN servers deployed in DMZ must only process STUN requests from the trusted network and not from the external network. Similarly TURN server in access network must only process STUN requests only its subscribers. Access control can be provided by access-control lists, firewalls and/or by user authentication to the TURN server. We can also discuss other recommendations like per-subscriber quota limit, ingress filtering. 

Please share any other mechanisms you would like to use to discuss in the WG and include in the draft.

-Tiru

---

From: Karl Stahl <[email-masked]>
Date: Wed, 7 Sep 2016 23:22:18 +0200

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Tirumaleswar Reddy (tireddy)
Skickat: den 7 september 2016 05:28
Till: [email-masked]
Kopia: [email-masked]; Simon Perreault;
[email-masked]; The IESG;
[email-masked]
Ämne: Re: [tram] Kathleen Moriarty's Discuss on
draft-ietf-tram-turn-server-discovery-09: (with DISCUSS)

> Cc: The IESG <[email-masked]>;
[email-masked];

Yes.

> servers that makes this point moot.

Restricting access to use the TURN server seems more important than
discovering the TURN server; will add more details that TURN servers
deployed in DMZ must only process STUN requests from the trusted network and
not from the external network. Similarly TURN server in access network must
only process STUN requests only its subscribers. Access control can be
provided by access-control lists, firewalls and/or by user authentication to
the TURN server. We can also discuss other recommendations like
per-subscriber quota limit, ingress filtering. 

Please share any other mechanisms you would like to use to discuss in the WG
and include in the draft.

-Tiru

Hi Tiru,

For the use case of a network provided TURN server paralleling a firewall or
default gateway (like RFC 7478 (Web Real-Time Communication Use Cases and
Requirements) 2.3.5.1), shouldn't both usage and discovery be restricted to
the local users?

The Anycast method has this "built-in", but when it comes to the methods
using DNS, isn't it the intention of the draft that the DNS should be local
only? I.e. network provided TURN servers SHOULD not be deployed in public
DNS, where we don't want to find local IP addresses like 192.168.1.1 over
and over again (or don't we care)? I think it at least should be recommended
(even if a MUST may not be required).

/Karl

> > -Tiru

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: [email-masked]
Date: Wed, 7 Sep 2016 21:39:16 -0400

Hi Tiru,

Sent from my iPhone

> Please share any other mechanisms you would like to use to discuss in the WG and include in the draft.

That sounds good, thank you.  Since this draft is about discovery, the restrictions you are going to add would also prevent reconnaissance, so you might want to mention that as well.

If the other recommendations are in another draft, a punter to that would be good.  If not, adding them might be helpful and you can point to this text in the future.

Thank you,
Kathleen

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Sep 2016 02:22:55 +0000

> Sent: Thursday, September 8, 2016 7:09 AM
> >>>> When responding, please keep the subject line intact and reply to
> >>>> all email addresses included in the To and CC lines. (Feel free to
> >>>> cut this introductory paragraph, however.)
> >>>>
> >>>>
> >>>> Please refer to
> >>>> https://datatracker.ietf.org/doc/draft-ietf-tram-turn-server-discov
> >>>> er
> >>>> y/
> >>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>> DISCUSS:
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >> When you have open services, it's possible to attack them.  It could
> >> be from a design or implementation problem that makes an exploit
> >> possible or it might just be for network reconnaissance.  Is there
> >> something different about TURN servers that makes this point moot.
> >
> deployed in DMZ must only process STUN requests from the trusted network
> and not from the external network. Similarly TURN server in access network
> must only process STUN requests only its subscribers. Access control can be
> provided by access-control lists, firewalls and/or by user authentication to the
> TURN server. We can also discuss other recommendations like per-subscriber
> quota limit, ingress filtering.
> >
> That sounds good, thank you.  Since this draft is about discovery, the
> restrictions you are going to add would also prevent reconnaissance, so you
> might want to mention that as well.

Sure.

> 
> If the other recommendations are in another draft, a punter to that would be
> good.  If not, adding them might be helpful and you can point to this text in the
> future.

Other TURN drafts are not discussing the above restrictions, we will update the draft.

-Tiru