Re: [secdir] Secdir review of draft-ietf-payload-flexible-fec-scheme-16

Giridhar Mandyam <mandyam@qti.qualcomm.com> Tue, 12 February 2019 17:06 UTC

Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4431292F1; Tue, 12 Feb 2019 09:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 2hfHVo7TP71o; Tue, 12 Feb 2019 09:06:48 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB23128B33; Tue, 12 Feb 2019 09:06:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1549991208; x=1581527208; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7fmMqPFEb6jLyjKktFs2jI8eeWmCNZVvCpwdrceMRWQ=; b=HIalgYSI4l2tHZOLUhZKGgWam3zscdSrZXQIkM9LTIGJGeCdt3liU3DH z+G5ZfK012VX/qr69xUpsHKMZf92ssCkCt/J9QAfy5IwEqYBvFdrAwdtm NDePysJ2ySxgoobLLQp17ngJaZWY68eAMV2K4Lc/HWU40XK2hNHRk3kKJ c=;
X-IronPort-AV: E=Sophos; i="5.58,362,1544515200"; d="scan'208,217"; a="27559373"
Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-01.qualcomm.com with ESMTP; 12 Feb 2019 09:06:47 -0800
Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 12 Feb 2019 09:06:47 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 12 Feb 2019 09:06:46 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Tue, 12 Feb 2019 09:06:46 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Radia Perlman <radiaperlman@gmail.com>, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>
Thread-Topic: Secdir review of draft-ietf-payload-flexible-fec-scheme-16
Thread-Index: AQHUwQkmOu8lZlcwNEKJvb4cVwdepqXcZhbQ
Date: Tue, 12 Feb 2019 17:06:45 +0000
Message-ID: <b34cee8a727a4e249767bfe27ed3b9f6@NASANEXM01C.na.qualcomm.com>
References: <CAFOuuo5+h8NnB9doM9hAVfSHmSneKZHBMGDFAUr3io-wBcXXFg@mail.gmail.com>
In-Reply-To: <CAFOuuo5+h8NnB9doM9hAVfSHmSneKZHBMGDFAUr3io-wBcXXFg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: multipart/alternative; boundary="_000_b34cee8a727a4e249767bfe27ed3b9f6NASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/ETDBg7XjPrfbq188av6LAg607zQ>
Subject: Re: [secdir] Secdir review of draft-ietf-payload-flexible-fec-scheme-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Feb 2019 17:06:51 -0000

Thank you for the review.

> Security Considerations mentions multiple ways that an RTP stream can be protected. I would quibble that the list includes TLS, which is probably not appropriate. TLS requires that all data packets be received and requests retransmission should packets be lost. That would remove any benefit from having FEC packets. Use of DTLS would be an appropriate protocol to use, however.

The editors agree and will update the text accordingly.

> It would be useful to publish information on losses experienced in actual use in order to help designers tune their parameters.

As examples of such work, please see https://tools.ietf.org/html/draft-singh-rmcat-adaptive-fec-03 or https://ieeexplore.ieee.org/document/7870757.

-Giri Mandyam

From: Radia Perlman <radiaperlman@gmail.com>
Sent: Saturday, February 9, 2019 10:23 PM
To: The IESG <iesg@ietf.org>; secdir@ietf.org; draft-ietf-payload-flexible-fec-scheme.all@ietf.org
Subject: Secdir review of draft-ietf-payload-flexible-fec-scheme-16


CAUTION: This email originated from outside of the organization.
I have reviewed 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 primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This specification defines a format for sending Forward Error Correction packets to allow occasional lost packets in a Real Time Protocol (RTP) stream to be recovered without retransmission. The format for these packets includes XORs of a series of packets which allows any one of the series to be recovered if the repair packet is received. To support the case of more than a single data packet being lost, it allows both horizontal and vertical parity to be computed over an n*m array of packets. This is important because the most frequent cause of packet loss is congestion, and congestion frequently loses multiple packets in succession.

There are more mathematically sophisticated algorithms that would permit recovery of more general sets of lost packets, but they would require more computation to recover and more debate to specify. Most standard FEC algorithms assume that a certain number of bits received are incorrect, where this algorithm assumes that packets are never received incorrectly but are sometimes not received at all. This algorithm is not designed to recover from security attacks or more complex failures.

Security Considerations mentions multiple ways that an RTP stream can be protected. I would quibble that the list includes TLS, which is probably not appropriate. TLS requires that all data packets be received and requests retransmission should packets be lost. That would remove any benefit from having FEC packets. Use of DTLS would be an appropriate protocol to use, however.

Other thoughts:

Given that most packet loss is caused by congestion, and very frequently congestion loses multiple packets from a stream, I'm surprised that sending repair packets based on an adjacent sequence of packets is effective (especially since sending those packets will increase congestion losses). Column based protection is more likely to be effective, but only if the rows are long enough that a sequence of packets lost due to congestion would all fit in a single row. On the other hand, lost packet recovery can take up to the amount of time to receive n*m packets, so that value must be small enough that the recovered packets are still useful given that this is a real time protocol. It would be useful to publish information on losses experienced in actual use in order to help designers tune their parameters.

Radia