Re: [Tsv-art] Tsvart last call review of draft-ietf-perc-private-media-framework-08

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 16 February 2019 09:58 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D24812D4EF; Sat, 16 Feb 2019 01:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 4OWnmQEDfF9C; Sat, 16 Feb 2019 01:58:19 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2619D12D4E7; Sat, 16 Feb 2019 01:58:18 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0BB2F1B0023D; Sat, 16 Feb 2019 09:58:09 +0000 (GMT)
Message-ID: <5C67DEB1.6020204@erg.abdn.ac.uk>
Date: Sat, 16 Feb 2019 09:58:09 +0000
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Paul E. Jones" <paulej@packetizer.com>
CC: "Paul E. Jones" <paulej=40packetizer.com@dmarc.ietf.org>, tsv-art@ietf.org, ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org
References: <154930159870.28630.16457371613620717540@ietfa.amsl.com> <em99f9a1ec-e503-4a74-a0c9-0b58b55d0a1e@sydney>
In-Reply-To: <em99f9a1ec-e503-4a74-a0c9-0b58b55d0a1e@sydney>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/FMw1W-611YKXnOKoExPfvRXDPiE>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-perc-private-media-framework-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Feb 2019 09:58:22 -0000

On 16/02/2019, 04:08, Paul E. Jones wrote:
> Gorry,
>
> Thanks for your review.  Please see comment/questions in-line.
>
>> General comments
>>
>> Some keywords appear not defined before first used - whilst these are 
>> likely
>> to be well-known by the coimmunity of interest, it would none-the-less
>> be helpful to define these:
>>
>> SRTP; RTCP; SIP; SDP.
>
> Most of these have a reference that follows them (RTCP was the one 
> exception, I think). Are you saying we should fully state what SRTP 
> stands for, for example, or are you saying references were missing?
>
RFCs are read by people with many backgrounds for many reasons. With 
this in mind, I was just suggesting to expand the acconyms.
>
>> In section 8.1, there is a sentence starting "Off-path atttackers 
>> may" ... while this
>> is lower case, the authors may wish toi consider using "could" to 
>> remove any
>> possibility of this being regarded as permissive.
>
> Agreed. Changed as suggested.
>
>> In 8.1, the text "could incorrectly assuming their packets..." 
>> probably ought to
>> read could incorrectly assume their packets..."
>
> Thanks. Fixed that and another small grammatical error there.
>
>> In section 8.2.1. there is a dscription of a resource consumption 
>> attack, but
>> no miitigation is described. It could be possible to consider using  
>> rate-limiting
>> of requests to reduce the impact - a mthod commonly suggested in other
>> attacks on the transport endpoints
> Good point. We cannot stop this entirely, but there are certainly 
> implementation-specific approaches that could be employed.
>
> I appended that paragraph with the following:
>
> "While resource consumption attacks cannot be mitigated entirely, 
> rate-limiting packets might help reduce the effectiveness of such 
> attacks."
>
> I'm open to alternative wording, but I think that should suffice.
>
Maybe /effectiveness/ could be /impact/ ?
... I'd personally prefer to not suggest attacks are effective, but 
happy with some such words.
> Thanks,
> Paul
>
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
Best wishes,

Gorry