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

<> Mon, 17 October 2016 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C847129495 for <>; Mon, 17 Oct 2016 16:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xzqf8FN3DhVb for <>; Mon, 17 Oct 2016 16:58:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 088B21299AF for <>; Mon, 17 Oct 2016 16:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1476748707; bh=sn1glpLY3LxY0P/rBtgF24cULdNjeRDQQcmjBz2lQ0w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UAKdg2nf7rx9G/ESR7wpNhTMZFl3oegdgiXkpII/OzHJRsBqlzOIuVKd20MDthsOezkcBZGCdZ9ljDF9lO15rPRY4NYnzBfvjh+dxQhdyM/5aP4mQJCOJhFFf1T7G5fovb/H47TQBCAeOcCAHQ66ZmVgIg0lQRjND3MIygieSXJ948XDtR0ell8vBsCMrtzWpylJpRCqWvlJbYZYte+/T8224uNdJ/KV6YIKb6SYBVTPgo04IGo1w7AxkIGSZXYX8cbQBqWIxZVFezv2/tCQGVojvRsyYUfvWAXWhVHXPcYdg651uucCvbrNv05etI32uUazNwUy7Vz9KBp9FWsj0w==
Received: from [] by with NNFMP; 17 Oct 2016 23:58:27 -0000
Received: from [] by with NNFMP; 17 Oct 2016 23:58:27 -0000
Received: from [] by with NNFMP; 17 Oct 2016 23:58:27 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: wKj6ZCgVM1n4480jkQ87hu8xYHZwlUuB52WVKJ6Hs8y1N10OG.pLvjYuiGqNJQN n20_HZQDh7NiQpW_EMLmlFoQAzt5cza29zKITqxpH0Mo..0efqahY_ipn7Va4FNDh0izhMbE3b9Q HrkFtvAzfdSbFELnkx08Aec2RsOL5DguOvvw1Zghj3axMHxhx6H0tkr1yj5trBJ4l8QbPtlHD6.s k54FSPNnACbzQZcBS3D0ugagVyQArXKo2VUia15SCQx0F_742Q_qrlh4qIUJN1cqSfPEHz4JXOoU ndOjjy4v8TbvkxUSOs6gWvs3ySql9ACTL6nsOLNPRdT2ua0DWZyP0ivUah81n97lmfp05I18PND1 qo5r4.AYGyEsGHkzuZAgAKcL59VbW28EHkBitMcbY6pVQESCtDk.uA3QOXIskkWd65D3wHiiLS7r S_eFg0cYHWwFf49w2xdF3YJh9FrUmu.Cfyjj7G9914.nufM8r3LpJt3jv3pgNUaB3bph6cnKk3jT UjO1XSe3WN7yCGSdYQIQTMFTdkwMc.zXRFsJkK2DoNmcJgF4vufo-
Received: from by; Mon, 17 Oct 2016 23:58:26 +0000; 1476748706.672
Date: Mon, 17 Oct 2016 23:58:26 +0000
To: Tero Kivinen <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-ippm-6man-pdm-option-05 : TimeBase
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Oct 2016 23:58:29 -0000


This note will summarize and answer the comments on timebase.

>> >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. 
>>What is the meaning of the section 4? 
>>It is good background information, and might be moved to the appendix, 
>>but I do not think it belongs here. It has text that mostly covers 
>>other formats, not the format used here. Also it does not really 
>>specify what does negative scaling values mean, and when are they used. 
>Let me review this again with one of my co-authors. 
>>so the range is definitely enough. The question is that if the scale is 
>>from -127 to 128, why do we even need the Time Base? 
>The time base is so that one does not have to be committed to picoseconds / 
>milliseconds, etc.    Even in your example, I believe you used "unit" or time 
>base.  Our thinking was that we wanted future proof so as to be able to 
>handle very small values and very large (as may be needed for DTN, for 
>example).   We can see if we can express years in picoseconds and see 
>what happens.   Then, the unit would always be picoseconds 

The issue is with the hardware. When we were first researching the "proper" or "best" time unit in which the PDM time differentials should be  measured, we found that different CPU hardware measure time very differently. Some CPUs are still measuring time in milliseconds and using multiple clocks to do it. 

Our plan was to have a CPU specify the time differential in its native time units, to reduce its processing time when communicating with another device that is at the same level.  One could say that the most logical solution is to use the time signature of the slowest device, so that all the time-adjustment calculations are performed on the device most capable of handling them quickly, and similarly, requiring the slowest device to adjust to the timing used by the fastest device would be forcing those calculations onto the device least capable of handling them quickly. Further, why make two devices that use the same clock unit to change to a different time scale on both ends of the conversation? If both use microseconds, why not let them specify their time differential in microseconds? 

That's the reasoning that we had about the timebase.

Of course, we are open to discussion. 

Nalini Elkins
Inside Products, Inc.
(831) 659-8360

----- Original Message -----
From: Tero Kivinen <>
Cc: "" <>; "" <>; "" <>
Sent: Monday, October 10, 2016 5:55 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05 writes:
> >There are most likely also other kind of attacks, and as this is
> >service as ESP provides, it is not for PDM to break it unless you
> >explictly spell it out that this is meant to break property of the
> >ESP. 
> OK. I am convinced. I will tell you though that some of us in IPPM,
> we were quite excited (possibly naively) about being able to get
> some performance metrics for ESP.

Why do you think you can performance metrics for ESP in that case? 

> I wonder if it would be acceptable to say that PDM could be put into
> the Destination Option which precedes ESP if it is for an enterprise
> customer who owns the infrastructure and wishes to manage the
> network that way. Otherwise, I can change to say that only the Dest
> Opt following ESP can be used.

I would recommend that if you use transport mode ESP (i.e., where the
flow information would be leaked out from the ESP if PDM is used) then
it must be put inside the ESP. If you use tunnel mode ESP, then there
migth be two PDM headers in the packet, one in the inner packet inside
the ESP header (which has full IP header + destination options
including PDM option), and another one in the outer header, in which
case it would only cover the ESP as one flow (i.e., each ESP SA
identified by the SPIs would get separate PDM option).

I.e. in the Tunnel mode ESP you want to defined the "5-tuple" as:


Btw, in the ICMP etc you do not have port numbers. Are ICMP frames
related to the TCP flows matching the "5-tuple" of the TCP flow or are
they counted as separate?

Anyways so if you define Tunnel mode ESP that way, then you can get
some performance metrics from the ESP processing also. Then if the
enterprice is willing to sacrifice the traffic flow confidentiality,
they can turn on the sa-per-flow option of the IPsec implementation,
which will create separate SA pair for each TCP/UDP etc flow, so then
they will get exact measurements.

In normal case the Tunnel mode ESP will just provide performance
metrics for combination of all traffic inside the tunnel, not per

When using the Transport Mode ESP, then putting the PDM option inside
still provides performance metrics for the host. 

> >so the range is definately enough. The question is that if the scale
> >is from -127 to 128, why do we even need the Time Base?
> The time base is so that one does not have to be committed to
>  picoseconds / milliseconds, etc. Even in your example, I believe
>  you used "unit" or time base. Our thinking was that we wanted
>  future proof so as to be able to handle very small values and very
>  large (as may be needed for DTN, for example). We can see if we can
>  express years in picoseconds and see what happens. Then, the unit
>  would always be picoseconds.

Having scale from -127 to 128 will provide quite good future proof,
for at least for this universum.

Even if you used attoseconds as base, you could express 10^13 years
which is still more than 1000 times longer than the current age of the

> >3.5 Implementation Considerations
> >   The PDM destination options extension header SHOULD be turned on by
> >   each stack on a host node. It MAY also be turned on only in case of
> >   diagnostics needed for problem resolution.
> > so it seems it is on by default. 
> Will change to say that it MUST be turned on only by the stack and
> default value should be OFF.
> "The PDM destination options extension header MUST be turned on only
>   by administrative action at each stack on a host node. The default
>   mode for PDM is OFF."


> >Key management packets are usually in clear, as they are there before
> >we have the actual keys we can use to protect the messages. Also it is
> >not very difficult to guess that 3rd and 4th message in port 500, are
> >the IKE AUTH packets, which will contain signatures.
> >Same thing with TLS.
> >Attackers will knows which packets contain signatures. Currently
> >attackers usually send those signature packets themselves, and measure
> >the time it takes for the device to calculate response. They can also
> >send garbage packets, and detect how far in checking the packets got
> >by checking how long it took for the other end to send error message
> >back.
> >All this kind of timing attacks are usually considered hard, as the
> >network delays cause big jitter on the timings, and they need to try
> >multiple times, and average the response times to get the information
> >they need.
> >This method will provide them easy way to bypass that issue. 
> OK.  So, are you saying that PDM is attack vector for TLS and not
> just for ESP?

Yes, timing attacks are possible against any crypto protocol. If the
protocol and algorithms used in the protocol are specifically written
so that they are protected against timing attacks, they will not work,
but lots of the implementations and protocols care more about the
speed, than for the timing attacks, especially as launching them over
longer distance gets harder and harder as other things add random
times to measurements.

If this allows easy way to get exact timing information from the node
without any issues from the network latencies and so on, this might
open completely new ways to attack implementations and protocols.
Those attacks were not feasible before, but now they might be. 

> No, obviously not. So, now I am not sure where we are. Is there a
> complete objection to this draft or are there changes which can be
> made which would make this acceptable?

Yes, I do not think there is anything that cannot be fixed, but there
are things that needs fixing (from the security point of view):

1) Location of the PDM in ESP transport mode traffic.
2) Make sure this is turned off by default, and you do not want node
   to respond incoming PDM options unless turned on by adminstrator.
3) Add to security considerations section aclear warnings about the
   new possibilities for timing attacks if PDM is turned on.

(not sure if I forgot something).