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

[<[e-mail]>]

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
[phone]

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

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