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

[Tero Kivinen <[e-mail]>]

[e-mail] 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:

SADDR, DADDR, PROTC (=ESP), SPI-IN, SPI-OUT

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
flow.

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
universe...

> >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."

Good.

> >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).
-- 
[e-mail]