Subject: Tsvart last call review of draft-ietf-perc-private-media-framework-08

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 04 Feb 2019 09:33:18 -0800

Reviewer: Gorry Fairhurst
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information. The authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

There are two other IETF drafts cited normally by this document, also in last call.

This document defines a security architecture based around an IETF transport, 
but does not itself propose updates to the transport mechanisms. I did
not find additional transport concerns, but have a number of general 
comments I'd like you to consider in the LC.

----

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.

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.

In 8.1, the text "could incorrectly assuming their packets..." probably ought to
read could incorrectly assume their packets..." 

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.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 16 Feb 2019 04:08:17 +0000

Gorry,

Thanks for your review.  Please see comment/questions in-line.

>be helpful to define these:

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?

>possibility of this being regarded as permissive.

Agreed. Changed as suggested.

>read could incorrectly assume their packets..."

Thanks. Fixed that and another small grammatical error there.

>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.

Thanks,
Paul

---

From: Ben Campbell <[email-masked]>
Date: Fri, 15 Feb 2019 23:47:21 -0600

I have a comment on one point, below:

> On Feb 15, 2019, at 10:08 PM, Paul E. Jones <[email-masked]> wrote:
> 
>> 
> 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?

Abbreviations should be expanded except for those listed as “well-known” by the RFC editor, whether or not they have a citation. The list is at https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt> . Well-known abbreviations are marked with an asterisk.

To save you from searching: SIP is marked as well-known. SRTP, RTCP, and SDP are not.

Thanks!

Ben.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 16 Feb 2019 07:06:35 +0000

Thanks, Ben.  I wasn't aware of this list.  I've expanded as appropriate 
in my local copy.  That should appear in the next version.

Paul

------ Original Message ------
From: "Ben Campbell" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>
Cc: "Gorry Fairhurst" <[email-masked]>; [email-masked]; 
[email-masked]; [email-masked]; 
[email-masked]
Sent: 2/16/2019 12:47:21 AM
Subject: Re: [Perc] Tsvart last call review of 
draft-ietf-perc-private-media-framework-08

>Abbreviations should be expanded except for those listed as 
>“well-known” by the RFC editor, whether or not they have a citation. 
>The list is at 
>https://www.rfc-editor.org/materials/abbrev.expansion.txt . Well-known 
>abbreviations are marked with an asterisk.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 16 Feb 2019 09:58:09 +0000

> 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.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
Best wishes,

Gorry

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 17 Feb 2019 02:54:32 +0000

Gorry,

>RFCs are read by people with many backgrounds for many reasons. With this in mind, I was just suggesting to expand the acconyms.

Understood, and done. It will appear that way in the next publication.

>>"While resource consumption attacks cannot be mitigated entirely, rate-limiting packets might help reduce the effectiveness of such attacks."
>>
>... I'd personally prefer to not suggest attacks are effective, but happy with some such words.

Sure, that change sounds good. I'm always the optimist, but optimism in 
the wrong direction isn't so positive. :)

Thanks!
Paul