Skip to main content

Last Call Review of draft-ietf-ippm-6man-pdm-option-05
review-ietf-ippm-6man-pdm-option-05-secdir-lc-kivinen-2016-09-22-00

Request Review of draft-ietf-ippm-6man-pdm-option
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-09-28
Requested 2016-09-15
Authors Nalini Elkins , Rob Hamilton , michael ackermann
I-D last updated 2016-09-22
Completed reviews Genart Last Call review of -05 by Jouni Korhonen (diff)
Secdir Last Call review of -05 by Tero Kivinen (diff)
Secdir Telechat review of -09 by Tero Kivinen (diff)
Opsdir Telechat review of -09 by Sheng Jiang (diff)
Genart Telechat review of -09 by Jouni Korhonen (diff)
Assignment Reviewer Tero Kivinen
State Completed
Request Last Call review on draft-ietf-ippm-6man-pdm-option by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 13)
Result Serious Issues
Completed 2016-09-22
review-ietf-ippm-6man-pdm-option-05-secdir-lc-kivinen-2016-09-22-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 document describes adding new IPv6 destination option header to
allow performance metrics calculations.

I think this document has serious issues.

It proposes that the new Destination option MUST be put before the ESP
so it is sent in clear. This will leak out the traffic information
from the ESP, allowing easy traffic analysis of encrypted packets, as
passive attacker can see which encrypted ESP packets belong to which
5-tuple flow. The PDM option header includes the incrementing sequence
numbers, so checking those will allow see which packet belongs to
which flow.

It claims that PDM MUST be placed before the ESP header in order to
work, which is untrue. This is destination option, thus it is meant to
be checked on the destination host, i.e., the packet capture after the
ESP decryption will allow seeing the PDM header values without issues.

--

Also the Time Base definations seem to be inconsistent. The section
3.2 says:

   That is, for a value of 00 in the Time Base field, a value of 1 in
   the DELTA fields indicates 1 microsecond.

Section 4.4 on other hand claims:

   That is, for a value of 00 in the Time Base field, a value of 1 in
   the DELTA fields indicates 1 picosecond.

On the other hand looking at the table in both 3.2 and 4.4 it seems
that time base value field value of 00 means milliseconds, not
microseconds or picoseconds.

Again section 4.5 says that "TimeBase of picosecond (or 00)", and
again I think picoseconds was supposed to be Time Base of 11...

The whole section 4 seems to be wierd. It is talking about different
encodings, and time units on different systems, and it also talks
about the limitations on TCP Timestamp Option, but this option uses
different encoding so I have no idea why this text is here. It would
be more useful to count what are the limits on the encoding method
used here (16 bit value, 7 bit signed scaling value), instead of what
some other option use.

In section 5.3 in the example it converts 4 seconds to hex value of
3A35 and scale of 25. On the other hand it is using milliseconds as
Time Base, so I think those values are wrong, i.e. 4 seconds in
milliseconds is 4000 milliseconds, thus FA0 with scale of 0 would be
correct represetnation. Same mistake in 5.4.

--

I skipped most of the section 6 and 7, so cannot say if similar
mistakes are in those sections.

--

The section 8 is wrong as it claims

	"PDM does not introduce any new security weakness."

while this will leak lots of information about the traffic flows
inside the encrypted transport mode ESP packets.

Also another thing the PDM leaks is exact host timings, i.e., it can
be used to launch timing attacks against crypto protocols. In general
those are hard as it is very hard to know how much of n ms rtt is
network delay and how much was the actual host processing the packet.
Now if we can see that that host used 123 nanoseconds to process the
signature verification packet, and next time it uses 1755 nanoseconds,
this might allow attacker to get information out from the key. The
actual round trip times might have been 123 ms in both cases, and the
1 microsecond difference in the processing time would have been lost
by the network latencies.

In addition to that the abstract is not very clear, it does not do
very good job of telling that this draft tries to do, and having the
Background section to duplicate most of that text does not still what
this document really tries to do. 
-- 
kivinen at iki.fi