Telechat Review of draft-ietf-ippm-6man-pdm-option-09
review-ietf-ippm-6man-pdm-option-09-secdir-telechat-kivinen-2017-04-06-00

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