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

Tero Kivinen <kivinen@iki.fi> Thu, 06 April 2017 10:58 UTC

Return-Path: <kivinen@iki.fi>
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 0FD4012943E; Thu, 6 Apr 2017 03:58:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 yzBshJo8_eER; Thu, 6 Apr 2017 03:58:31 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BF0D12943B; Thu, 6 Apr 2017 03:58:30 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v36AwQFX000159 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 13:58:26 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36AwQOT005451; Thu, 6 Apr 2017 13:58:26 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22758.8018.819433.930944@fireball.acr.fi>
Date: Thu, 06 Apr 2017 13:58:26 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-6man-pdm-option.all@ietf.org
X-Edit-Time: 19 min
X-Total-Time: 18 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BAIkONwtaQvH2toiTY76Ic1cakA>
Subject: [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: Thu, 06 Apr 2017 10:58:33 -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 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