Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-09

<nalini.elkins@insidethestack.com> Fri, 07 April 2017 16:58 UTC

Return-Path: <nalini.elkins@insidethestack.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 4019112942F for <secdir@ietfa.amsl.com>; Fri, 7 Apr 2017 09:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.086
X-Spam-Level:
X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 NEepVlPUBSUy for <secdir@ietfa.amsl.com>; Fri, 7 Apr 2017 09:58:51 -0700 (PDT)
Received: from nm19-vm6.bullet.mail.gq1.yahoo.com (nm19-vm6.bullet.mail.gq1.yahoo.com [98.136.217.29]) (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 4CB3C1296CE for <secdir@ietf.org>; Fri, 7 Apr 2017 09:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1491584325; bh=3EH4+WiYUx7P1eDdXjR64jVp3waqH6Y0SpaNbG6YShk=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=AYhRVGnH6WrQf+8dHEyE24iJBDnJLHMn6V3Z6mEog687JRbbaasWrk3QYrIOpgG8iZuxxCNeHgU/dNKCbNd0Sz2H2Mv5mFdAsUyskKV5PcatMXk295VYlxoCOusOXYYRe6EB1+82Vp2DZODN1TybqHlggeUYTBJ0YdMgGWn0bbhDZvnpSchhtpjmbFPv/rx3E4P+54Vb0fwY+PyN86x7oNKOWHpoX6nJW4+PEK+D/IBoElKTkTFEcitU/5RmbG8RHdd8ehrOrQ4Mm3vzF2E4PJOLw3rJWUw3rgJNsb/bURCyy1UtCcvrATODK/fFXYT8QzqJOfFQDTGUbnhllijsvA==
Received: from [216.39.60.180] by nm19.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000
Received: from [98.137.12.200] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000
Received: from [127.0.0.1] by omp1008.mail.gq1.yahoo.com with NNFMP; 07 Apr 2017 16:58:45 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 783573.76315.bm@omp1008.mail.gq1.yahoo.com
X-YMail-OSG: jKjTSrsVM1kYyl8w.DlQPZkask7q85KK7u7jSY1n4kS6KWlrO3kzXrRUUJc0ifg hsskcZ0IVVo77GDy1jbXk_x0Yg0UkNtxmwJ1CV5H2.MTmcVeAl1G5WUmr3ZfagGWKBNuStupU3FZ mJdLn45pcHKrpd8t8uI.QsoRlfKYt6jiM9fs1YgcF2bHPH8eWUeZR94HJFajErt2dCqlU2WTaZZL 1uwDPI2TjrZ4Vp_QLDny1J4PYGUkhxBTvhUpeSNqiCKE16BwQoSHH3Vwo895tOj1Bnw0J1itlBCO SAAng9eVHZH.Im_uomjs6Bh.xHGPgBv7Txc9qcoa15hbu667JqHhZ73SnHNQSswibfwHuptJr78G fj19wCAfNdvpuSsbldoEvN5w86YKuL3hiWgCo3Ae1oa0TXHpWx5daLAyhnbPtrPPAHNGFNTPRSF. SgLVGbNkDU76wSDIWeAs8ZEpKbUFPNqlqOSUjd73z9tox8Oh3ZecUWlro7IudeUG03yYu97exwkb 6CEXTMeEBVj1QGXHiTcILTAYbeWVjWJ4qzsH5wZQI02bEDu4-
Received: from jws300042.mail.gq1.yahoo.com by sendmailws111.mail.gq1.yahoo.com; Fri, 07 Apr 2017 16:58:45 +0000; 1491584325.401
Date: Fri, 7 Apr 2017 16:58:45 +0000 (UTC)
From: <nalini.elkins@insidethestack.com>
Reply-To: <nalini.elkins@insidethestack.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-ippm-6man-pdm-option.all@ietf.org>, Tero Kivinen <kivinen@iki.fi>
Message-ID: <1819867131.2096808.1491584325084@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <1819867131.2096808.1491584325084.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.9272 YahooMailBasic Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/b23PLNMY2gTRD59T-fRvQlevexc>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Apr 2017 16:58:53 -0000

Tero,

Thanks for your review.

We have no problem with adding the text you suggest to the end of the appropriate paragraph in section 3.4.2

> In ESP case there is no 5-tuple available, as there is no port numbers, and that means that ESP flow should be
> identified only by using SADDR, DADDR and PROTOC. The SPI numbers SHOULD be ignored when considering what is the flow
> over which PDM information is measured.


Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

--------------------------------------------
On Thu, 4/6/17, Tero Kivinen <kivinen@iki.fi> wrote:

 Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-09
 To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-6man-pdm-option.all@ietf.org
 Date: Thursday, April 6, 2017, 3:58 AM
 
 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 is rereview of the performance and
 diagnostic metrics destination
 option document, and this version is
 much better than the previous
 one. The security considerations and
 the default settings are better
 now.
 
 I have one nit about the document. In
 the section 3.4.2 it talks about
 putting PDM header outside the ESP, and
 says that:
 
    As a completely new IP packet
 will be made, it means that PDM
    information for that packet
 does not contain any information from the
    inner packet, i.e. the PDM
 information will NOT be based on the
    transport layer (TCP, UDP, etc)
 ports etc in the inner header, but
    will be specific to the ESP
 flow. 
 
 This is fine, but it should note, that
 in this case there is no
 5-tuple available, as there is no SPORT
 or DPORT. With PDM option
 outside the ESP header, the system
 should use SADDR, DADDR and PROTC
 to identify the flow.
 
 In addition to that it could use the
 SPI pair to identify the flow.
 The problem with ESP is that there is
 really two unidirectional flows,
 i.e. one flow from node A to node B
 with SPI of X, and another flow
 from node B to node A with SPI of Y.
 Only one SPI value is stored in
 the packet, and it is not possible to
 know from the outside which SPI
 number X matches the SPI number Y, in
 case there are multiple ESP SAs
 between the peers.
 
 In case the PDM option processing is
 integrated to the ESP, then the
 PDM processing could consider the two
 unidirectional ESP flow as one
 bi-directional ESP flow, and combine
 the PDM information for them. The
 problem is that if PDM processing is
 not integrated in the ESP, it
 does not know the SPI numbers that form
 this pair, and if one end does
 this and other end does not (because
 its PDM processing is not
 integrated with ESP) then information
 not be that useful. 
 
 Because of this it is be better just to
 say that we do not use SPI
 numbers when creating the flows,
 meaning we combined all ESP SAs
 between the peers to one flow. This
 means that we will simply use
 SADDR, DADDR and PROTC as selectors for
 the PDM flow.
 
 If there is multiple ESP SAs between
 the peers, the IPsec users its
 own policy rules to pick which traffic
 ends up in which ESP SA, thus
 it is completely possible that one TCP
 stream from host behind the
 IPsec gateway will be split in multiple
 ESP SAs. If using combined
 PDM statistics for all ESP traffic,
 then it does not matter how the
 IPsec splits traffic over multiple
 tunnels.
 
 So I think it could be good idea to add
 text like this to end of the
 paragraph above in section 3.4.2:
 
     In ESP case there is
 no 5-tuple available, as there is no
     port numbers, and
 that means that ESP flow should be
     identified only by
 using SADDR, DADDR and PROTOC. The SPI
     numbers SHOULD be
 ignored when considering what is the flow
     over which PDM
 information is measured.
 
 In summary I think this document is
 ready with nits. 
 -- 
 kivinen@iki.fi