Subject: Re: [tram] Review of TURNbis-11

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 9 Feb 2018 11:53:44 +0000

Hi Marc,

Please see inline

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Marc Petit- 
> Huguenin
> Sent: Sunday, October 22, 2017 10:16 PM
> To: [email-masked]
> Subject: [tram] Review of TURNbis-11
> 
> This is the second part of my review of TURNbis-11, i.e. everything 
> but the dual allocation part.
> 
> - Section 2.1, last paragraph:
> 
> May be a reference to RFC 5764 and RFC 7983 can be useful here.  Same 
> in section 4, second paragraph and following.  Same at the beginning 
> of section 11.  Again in section 11.6 (if multiplexed, the message in 
> the reserved range is not necessarily discarded).

Even if the same host transport address is used for other protocols, incoming packets to the TURN channel can be identified by just examining the source address of the packet. 
May be I am missing something, I did not get a problem ?

> 
> - Section 2.2, first paragraph:
> 
> I think that an informative reference to RFC 7635 may be useful there, 
> as alternative to the STUN authentication mechanism.

Yes, updated. 

> 
> - Section 2.9:
> 
> The whole 2.9 section and subsections looks normative and so should be 
> moved after section 3, perhaps on their own top level section.

Done. 

> 
> - Section 4, 4th paragraph:
> 
> I would replace "For each allocation..." by "For each Allocate 
> request...", because of the dual allocation feature.

Fixed. 

> 
> - Section 4, 12th paragraph:
> 
> Should make clear clear that UDP covers also DTLS.

Yes, updated.

> 
> - Section 6.1, 2nd paragraph:
> 
> If the port is multiplexed with other protocols (RTP, WebRtc, etc..) 
> then it has to reuse an existing socket.  The document should explain this.

It's already covered in Section 2.1 (last paragraph). 

> 
> - Section 6.2, 3th paragraph:
> 
> Is it time to recommend DTLS instead of UDP?  In that case we need to 
> make DTLS mandatory in section 4 paragraph 11 (and I support that change).

No, DTLS has both advantages (e.g. dictionary attack)  and disadvantages (e.g. double encryption of application data). 

> 
> - Section 6.4, second bullet:
> 
> Replace "...SRV procedures)." with "...DNS resolution procedures)."

Any specific reason for the replacement ?

> 
> - Sections 14, 15 and 16:
> 
> These are no longer new methods and attributes.  See also the next 
> comment.

Fixed. 

> 
> - Section 19:
> 
> Here you need to update the existing methods, attributes and error 
> code so the IANA registries point to the RFC-to-be, then you request 
> allocation for the new attributes.  See section 17 of STUNbis on a way 
> to do that (that was done following a discussion with the IANA representative at an IETF meeting).

Thanks, updated draft. 

> 
> Note that ICMP should be comprehension-mandatory, not optional, as we 
> do not want an old client to reject a Data indication with an ICMP attribute.

If the indication contains unknown comprehension-required attributes, the behavior is the indication is discarded and processing ceases.

> 
> Also, I do not know what this SendErr method is.

Removed SendErr (stale entry from a previous version of the draft).

> 
> 
> Nits
> ----
> 
> Section 1:
> 
> s/connection to the Internet ./connection to the Internet./
> 
> Section 2.4, first paragraph:
> 
> The text switches between the words "mechanisms" and "way".  Choose 
> one.
> 
> Section 6.2, item 8:
> 
> s/ADDITIONAL- ADDRESS-FAMILY/ADDITIONAL-ADDRESS-FAMILY/
> 
> Section 12.1, "Preferred Behavior"
> 
> s/Label Field[RFC3697]/Label Field [RFC3697]/
> 
> Section 21:
> 
> s/ADDRESS-ERRR-CODE/ADDRESS-ERR-CODE/
> 
> Section 22:
> 
> s/orginal/original/

Thanks, fixed all above nits.

Cheers,
-Tiru

> 
> --
> Marc Petit-Huguenin
> Email: [email-masked]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 9 Feb 2018 05:23:51 -0800

Hi,

My responses inline.

> May be I am missing something, I did not get a problem ?

It was just an attempt to make TURN implementers aware of the demux issues.

> No, DTLS has both advantages (e.g. dictionary attack)  and disadvantages (e.g. double encryption of application data). 

OK.

> Any specific reason for the replacement ?

This is to not exclude NPATR procedures (RFC 5928).

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Fri, 9 Feb 2018 13:45:39 +0000

> Sent: Friday, February 9, 2018 6:54 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]
> Subject: Re: [tram] Review of TURNbis-11
> 
> Hi,
> 
> My responses inline.
> 
> > Even if the same host transport address is used for other protocols,
> incoming packets to the TURN channel can be identified by just examining
> the source address of the packet.

Got it, added the following line:
The algorithm of demultiplexing packets received from
multiple protocols is discussed in [RFC7983].

> >> I think that an informative reference to RFC 7635 may be useful
> >> there, as alternative to the STUN authentication mechanism.
> >
> > Yes, updated.
> >
> >>
> >> - Section 2.9:
> >>
> >> The whole 2.9 section and subsections looks normative and so should
> >> be moved after section 3, perhaps on their own top level section.
> >
> > Done.
> >
> >>
> > No, DTLS has both advantages (e.g. dictionary attack)  and disadvantages
> (e.g. double encryption of application data).
> 
> OK.
> 
> >
> >>

Updated second bullet.

Cheers,
-Tiru

> >> allocation for the new attributes.  See section 17 of STUNbis on a
> >> way to do that (that was done following a discussion with the IANA
> representative at an IETF meeting).
> >
> > Thanks, updated draft.
> >
> >>
> > If the indication contains unknown comprehension-required attributes, the
> behavior is the indication is discarded and processing ceases.
> >
> >>