Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 31 January 2014 11:56 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E21A0594 for <mmusic@ietfa.amsl.com>; Fri, 31 Jan 2014 03:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.551
X-Spam-Level:
X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTdmXD-RVwes for <mmusic@ietfa.amsl.com>; Fri, 31 Jan 2014 03:56:43 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCED1A0588 for <mmusic@ietf.org>; Fri, 31 Jan 2014 03:56:42 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-09-52eb8f757204
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C0.B7.23809.57F8BE25; Fri, 31 Jan 2014 12:56:38 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Fri, 31 Jan 2014 12:56:37 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: =?iso-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>, "draft-ietf-mmusic-udptl-dtls@tools.ietf.org" <draft-ietf-mmusic-udptl-dtls@tools.ietf.org>
Thread-Topic: draft-ietf-mmusic-udptl-dtls-03 review
Thread-Index: AQHPHcckatfvrQ/Cl0um0naW4oLZXpqeu1cg
Date: Fri, 31 Jan 2014 11:56:36 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D151248@ESESSMB209.ericsson.se>
References: <52EA60DD.9090402@ericsson.com>
In-Reply-To: <52EA60DD.9090402@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+JvjW5Z/+sggz+TOCwWHW9nsZi6/DGL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxfV8vc8Ej4YqVi7uZGxjP8ncxcnJICJhI vGi4zgphi0lcuLeerYuRi0NI4BCjxNrZU6GcxYwShztWsXQxcnCwCVhIdP/TBomLCMxjlFj4 eg5YN7OAjMSMs41MILawgLHEtsVfwGwRoA0Hm/YwQ9hGEisPnGUHmcMioCrR3SMKEuYV8JU4 vuAYWImQgLbEjPXb2UBsTgEdiduPV4DZjEDHfT+1hglilbjErSfzmSCOFpBYsuc8M4QtKvHy 8T+oZxQldp5tZ4ao15O4MXUKG4StLbFs4WtmiL2CEidnPmGZwCg2C8nYWUhaZiFpmYWkZQEj yypG9tzEzJz0cqNNjMAYObjlt+oOxjvnRA4xSnOwKInzfnjrHCQkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBMW2+6RxPpQ0Trt/04Tr25KTwtPmM8XpGbnvjnv0/dJLJKeT8F3uH8/+KRGcp rS7lsOFINv59R37ra/4DbQY/p4l51lofKHvdyuXiZmnAzXhvncWkaR5zL/OmHRIP8n3pFuH5 p5lV+Laq7Mr69bKNUntMH7RWRn3Jst0pUnWkyNu8+QTLHvu5SizFGYmGWsxFxYkAv0CLL18C AAA=
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 11:56:44 -0000

Hi Ari,

Thanks for your review! Comments inline.

> 1.  Introduction
>
>    This was mainly because of the challenges involved with
>    physical access to telephony equipment.
>
> s/physical access/malevolent physical access/ (or something else 
> saying that there's an unauthorized accessing for making an attack in
> question)

I will change as suggested.

>    This document specifies the transport of UDPTL over DTLS using the
>    DTLS record layer "application_data" packets [RFC6347].
>
> "application_data" is actually defined in the TLS RFC (5246) and 6347 
> doesn't mention that name (as such) at all. Maybe having both RFCs as 
> reference makes sense.

I suggest the following modification:

	"This document specifies the transport of UDPTL over DTLS using the
   	DTLS record layer "application_data" packets [RFC5246] [RFC6347]."


---------------------------

> 4.2.2.  Latching Control without ICE
>
>    and the passive MUST NOT wait for a STUN answer before sending its
>
> s/passive/passive side/

I will change as suggested.

> Moreover, the term "Latching" may not be obvious for everyone. Do you 
> mean the same as in draft-ietf-mmusic-latching? A sentence explaining 
> this could help or alternatively changing the title to more descriptive one.

I would rather suggest to change the section titles, as following:

4.2.1. NAT Traversal With ICE
4.2.2. NAT Traversal Without ICE

...because, the text doesn't really talk so much about latching per se, but more about the opening of pin holes etc.

---------------------------

> 4.2.3.  STUN Interaction
>    The UA MUST demultiplex packets arriving on the IP address and port
>    associated with the DTLS association as follows:
>
> Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)? 
> Maybe s/MUST/can/?

I suggest to add "e.g.", to show that the documented demux mechanism is only one way it can be done.

	"The UA MUST demultiplex packets arriving on the IP address and port
	associated with the DTLS association, e.g. as follows:"

---------------------------

> A.3.  Message Flow Of T.38 Fax Replacing Audio Media Stream in An
>       Existing Audio-Only Session
>
>    Traditionally, most session with non-secure transport of T.38 fax,
>    transported using UDPTL, are established by modifying an ongoing
>
> s/session/sessions/

I will change as suggested.

---------------------------

Thanks!

Regards,

Christer