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

Radia Perlman <radiaperlman@gmail.com> Sun, 10 February 2019 06:23 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E4EBD128CE4; Sat, 9 Feb 2019 22:23:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id FDgFCnCx6Gko; Sat, 9 Feb 2019 22:23:24 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73E5130E79; Sat, 9 Feb 2019 22:23:23 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id v14-v6so6282628ljv.1; Sat, 09 Feb 2019 22:23:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=J0EWBIdPFU2SKSQD+sGmjdAuvAwtTFRvqFO6ExHLFAw=; b=tNOOPrK2qDHB39Yjct+DUKhdki0PMkVNIAJFcwNBEH7PL2XbrxOx/4exJEzhXKMcCK 5sC4Na2dolY3nEPs8X9IteRZrrPlK2G+1gnZ4SqFfzJjHQ/Mpu4ODJYlhf+p0bNet42m Ipv9vvu8023pNBi6AlesHgcp+F0MHL3CG/NdWsqq9J8hJVEd3wc5oifVMcb106sYXgtX fwatPLDOdP0eTvDxV4yfQlOye6VZyw6U98DHy3sxROMH5VVluDlweuL8TcOlGGiXcyad tOBYNR4VWuaNvhG19bHccGiNGKZaS+bYH3xEvlLceiuhc1eRg+wlr8JLFL7KFuBL0VfG jLHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J0EWBIdPFU2SKSQD+sGmjdAuvAwtTFRvqFO6ExHLFAw=; b=HSXAzEhIPfeV2dWU71nPicYd4pNCv+jse8E4Ys+Lm+mbHJaP7VqJbSb7h6MVpW39Fa ididiiQBlvMBuCksVh1ZiaAIlVcoJFzfTJ2oKx4EHJclsfq6HFL4qVb4/HHGN5hHiay7 iy9sQuJGVlueG8+DuQ3nvRqlCzgpvunIMjBFnPTMdt/2xfrX/JDdS/buchC1xGZQYAgt 611NUsDbVhANYWJqaroT6ET2+HUPF2NB25oIFTucRwf8FRqk2BCVr+PgxcmNrOoBnmei xKCHv0/di8pvRlLOXwisF+QF41TxkBkt0225wWuHx63OHkq/T1oALB+FzaljQgC994CM xQpw==
X-Gm-Message-State: AHQUAuZHGETrOnovyTo7swmDwU70ArYWV8GnaPcOqo8FNPckJ7IS9zW/ Er/SlhGSV1sUYOFXvwDDhPzi6LeWsW3ULSfKsUuox7bY
X-Google-Smtp-Source: AHgI3IYFabv8olA1b9vFT5J7ESEY/QLHQ18V1Cz1fwvJAF5YO+i9gqmJ0hGdWb9SGPLy7MMxXOd8aZ8bOblHjSWc3Fc=
X-Received: by 2002:a2e:6a13:: with SMTP id f19-v6mr18383355ljc.41.1549779801220; Sat, 09 Feb 2019 22:23:21 -0800 (PST)
MIME-Version: 1.0
From: Radia Perlman <radiaperlman@gmail.com>
Date: Sat, 9 Feb 2019 22:23:10 -0800
Message-ID: <CAFOuuo5+h8NnB9doM9hAVfSHmSneKZHBMGDFAUr3io-wBcXXFg@mail.gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-payload-flexible-fec-scheme.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008829120581843a1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/S02KEAK6lO8yBbBJIBKTvvk-95s>
Subject: [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: Sun, 10 Feb 2019 06:23:27 -0000

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.