Re: [secdir] Review of draft-ietf-avt-app-rtp-keepalive-05

<xavier.marjou@orange-ftgroup.com> Tue, 16 June 2009 12:52 UTC

Return-Path: <xavier.marjou@orange-ftgroup.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6454E28C146; Tue, 16 Jun 2009 05:52:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI20tSMjIbIG; Tue, 16 Jun 2009 05:52:02 -0700 (PDT)
Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 0748A3A6A76; Tue, 16 Jun 2009 05:52:01 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:51:09 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Jun 2009 14:51:06 +0200
Message-ID: <51D96D3F30495C4BAF8D190702F9B93316E6E1@ftrdmel1>
In-Reply-To: <4A35EF28.2090105@sun.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Review of draft-ietf-avt-app-rtp-keepalive-05
Thread-Index: AcnthctnXopTyER2QNC3nohaH+CJmgA+nAOg
References: <4A35EF28.2090105@sun.com>
From: xavier.marjou@orange-ftgroup.com
To: Shawn.Emery@Sun.COM
X-OriginalArrivalTime: 16 Jun 2009 12:51:09.0028 (UTC) FILETIME=[1EB72240:01C9EE81]
X-Mailman-Approved-At: Tue, 16 Jun 2009 06:01:48 -0700
Cc: aurelien.sollaud@orange-ftgroup.com, draft-ietf-avt-app-rtp-keepalive@tools.ietf.org, iesg@ietf.org, avt-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Review of draft-ietf-avt-app-rtp-keepalive-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 16 Jun 2009 12:52:03 -0000

> old peers, which don't understand the new keepalive message, will 
> appropriately drop the packet sent by its peer?
 
Yes exactly. An old peer "only" implements RFC3550, which mandates to "ignore packets with payload types that it does not understand". The new fallback keepalive message makes part of such non-understandable packets and will thus be ignored/discarded, as mentioned in section 4.6

> Editorial comment(s):
>
> Expand the first occurrences of "SDP" and "RTCP".
>
> s/needs support/needs to support/
>
> s/mux"attribute/mux" attribute/
 
Thank you for your careful review. 
 
Cheers,
Xavier & Aurélien 

-----Message d'origine-----
De : Shawn.Emery@Sun.COM [mailto:Shawn.Emery@Sun.COM] 
Envoyé : lundi 15 juin 2009 08:50
À : secdir@ietf.org; draft-ietf-avt-app-rtp-keepalive@tools.ietf.org; avt-chairs@tools.ietf.org; iesg@ietf.org
Objet : Review of draft-ietf-avt-app-rtp-keepalive-05


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 draft describes various ways for RTP applications to keep NAT mappings alive.  It goes on to detail individual keepalive methods and advantages/disadvantages of its approach.

Intended status of the draft is BCP.

I'm not for sure I understand the security considerations section, but I think what it's trying to say is that: old peers, which don't understand the new keepalive message, will appropriately drop the packet sent by its peer?  If so then please reword accordingly.

No additional security related issues beyond RTP itself discovered in this draft.

General comment(s):

I appreciate the use of a requirements section, this makes it easier to find out what is or is not in scope for the recommended solutions.

Editorial comment(s):

Expand the first occurrences of "SDP" and "RTCP".

s/needs support/needs to support/

s/mux"attribute/mux" attribute/

Shawn.
--