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

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 6 Oct 2016 20:44:46 -0500

Hi, Kathleen,

On Wed, Sep 7, 2016 at 9:22 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: Thursday, September 8, 2016 7:09 AM
> > To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> > Cc: The IESG <[email-masked]>; draft-ietf-tram-turn-server-
> [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)
> >
> > Hi Tiru,
> >
> >
> > Sent from my iPhone
> >
> > On Sep 6, 2016, at 11:27 PM, Tirumaleswar Reddy (tireddy)
> > <[email-masked]> wrote:
> >
> > >> -----Original Message-----
> > >> 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
> > >>
> > >> 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-discov
> > >>>> er
> > >>>> y/
> > >>>>
> > >>>>
> > >>>>
> > >>>> -------------------------------------------------------------------
> > >>>> --
> > >>>> -
> > >>>> 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?
> > >
> > > 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.
> >
> > 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
>
> >
> > Thank you,
> > Kathleen
> > >
> > > -Tiru
> > >
> > >>
> > >> Thank you,
> > >> Kathleen
> > >>>
> > >>> Cheers,
> > >>> -Tiru
> > >>>
> > >>>
>

Could you confirm that the additions to the Security Considerations section
in -10 address your Discuss?

Thanks!

Spencer