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

From: Tero Kivinen <[email-masked]>
Date: Thu, 6 Apr 2017 13:58:26 +0300

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. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Fri, 7 Apr 2017 16:58:45 +0000 (UTC)

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

Thanks,

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

--------------------------------------------
On Thu, 4/6/17, Tero Kivinen <[email-masked]> wrote:

 Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-09
 To: [email-masked], [email-masked], [email-masked]
 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. 
 -- 
 [email-masked]