Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-behave-requirements-update

<mohamed.boucadair@orange.com> Mon, 15 February 2016 16:28 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD41A8A12 for <gen-art@ietfa.amsl.com>; Mon, 15 Feb 2016 08:28:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 bOZkj32-rb0i for <gen-art@ietfa.amsl.com>; Mon, 15 Feb 2016 08:28:52 -0800 (PST)
Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9C91A8A11 for <gen-art@ietf.org>; Mon, 15 Feb 2016 08:28:51 -0800 (PST)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id F2980C00DE; Mon, 15 Feb 2016 17:28:49 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id C03C81A0061; Mon, 15 Feb 2016 17:28:49 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Mon, 15 Feb 2016 17:28:49 +0100
From: mohamed.boucadair@orange.com
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART review of draft-ietf-tsvwg-behave-requirements-update
Thread-Index: AdFoDG1bAr2kmwOBSYap3KbgE7aDwwAAEJNw
Date: Mon, 15 Feb 2016 16:28:49 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008CE2C34@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <9904FB1B0159DA42B0B887B7FA8119CA6BF19524@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BF19524@AZ-FFEXMB04.global.avaya.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008CE2C34OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/ty_tMWR_Ht54B_2Je22005tYD9k>
Cc: "draft-ietf-tsvwg-behave-requirements-update.all@tools.ietf.org" <draft-ietf-tsvwg-behave-requirements-update.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-behave-requirements-update
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2016 16:28:54 -0000

Hi Dan,

Thank you for the review.

Please see inline.

Cheers,
Med

De : Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Envoyé : lundi 15 février 2016 17:18
À : General Area Review Team
Cc : draft-ietf-tsvwg-behave-requirements-update.all@tools.ietf.org
Objet : Gen-ART review of draft-ietf-tsvwg-behave-requirements-update


I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>



Document:  draft-ietf-tsvwg-behave-requirements-update-06

Reviewer: Dan Romascanu

Review Date: 2/15/16

IETF LC End Date: 2/16/16

IESG Telechat date:



Summary: This document is ready with minor issues.



Major issues:



None



Minor issues:



1.       The text in the second and third paragraphs in section 2.2 is rather confusing. Do these belong to updates, or should they be under Notes?



Ø  Admittedly, the NAT has to verify whether received TCP RST packets belong to a connection. This verification check is required to avoid off-path attacks.



Ø  If the NAT removes immediately the NAT mapping upon receipt of a TCP RST message, stale connections may be maintained by endpoints if the first RST message is lost between the NAT and the recipient.



If they belong to Updates 'Admittedly' needs to be dropped, 'has to verify' becomes 'SHOULD verify', etc.

Else, if these are rather notes they should be labeled Notes or Clarification



[Med] These are notes. What about making this change?



OLD:


      Admittedly, the NAT has to verify whether received TCP RST packets
      belong to a connection.  This verification check is required to
      avoid off-path attacks.

      If the NAT removes immediately the NAT mapping upon receipt of a
      TCP RST message, stale connections may be maintained by endpoints
      if the first RST message is lost between the NAT and the
      recipient.



NEW:



      Notes:

      *   Admittedly, the NAT has to verify whether received TCP RST packets

      belong to a connection.  This verification check is required to

      avoid off-path attacks.



      * If the NAT removes immediately the NAT mapping upon receipt of a

      TCP RST message, stale connections may be maintained by endpoints

      if the first RST message is lost between the NAT and the

      recipient.







2.       In section 5:



Ø  This update is compliant with the stateful NAT64 [RFC6146] that clearly specifies three binding information bases (TCP, UDP, ICMP).



As the focus of this document is NAT44, I do not believe that 'compliant' is the right word. Probably 'consistent' would be more appropriate.



[Med] I changed it to "consistent" in my local copy. Thank you for catching this.



3.       EIF is never expanded

[Med] Fixed.



Nits/editorial comments:


None.