Re: [secdir] Security review of draft-ietf-rmcat-wireless-tests-08

[Mirja Kuehlewind <[e-mail]>]

Hi Hilarie,

Thanks for this review. Please see below.

> On 21. Jan 2020, at 07:19, Hilarie Orman <[e-mail]> wrote:
> 
>     Security review of Evaluation Test Cases for Interactive
>     Real-Time Media over Wireless Networks
> 	 draft-ietf-rmcat-wireless-tests-08
> 
> Do not be alarmed.  I generated this review of this document as part
> of the security directorate's ongoing effort to review all IETF
> documents being processed by the IESG.  These comments were written
> with the intent of improving security requirements and considerations
> in IETF drafts.  Comments not addressed in last call may be included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last call comments.
> 
> The focus of this document is the definition of test cases that can be
> used evaluate congestion control algorithms for cellular and Wi-Fi
> networks.  If the testing is done on isolated testbed networks, there
> are are few, if any, security considerations.
> 
> The Security Considerations section mentions safeguards to avoid
> "congestion collapse of the Internet" and "leaking non-responsive
> traffic from unproven congestion avoidance techniques onto the open
> Internet".  The former seems overly general (shouldn't all IETF
> protocols strive to avoid breaking the Internet?), and I am not at all
> sure what the latter means.

This document belongs to a set of two documents where the other one is draft-ietf-rmcat-eval-test. Both documents have the same text in the security considerations section and for draft-ietf-rmcat-eval-test we created this text based on the SECDIR review feedback. 

You are right that this text is rather general but the main purpose was to provide people the right pointers. And yes all protocol should not break the Internet; this is one thing we usually look for in TSV reviews, however, in this case it’s a bit a chicken and egg problem because the whole testing in this doc is about figuring out if the proposed congestion control is safe enough to test on the Internet or not.  

> 
> I would recommend that test setups use passwords and keys that are
> specific to the test environment, but that is a generic recommendation
> for all test environments.  It is probably not needed in this
> document.

I think that is really a point that is out of scope for this document. However, passwords and keys still don’t help if your test setup is wrongly configured and traffic can “escape”. We usually assume that test setups are used that are not connected to the internet at all, or only to ssh into the machines but all other traffic is by default blocked. That’s what’s meant with “avoid leaking”.

Mirja


> 
> Hilarie
> 
>