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

From: <[email-masked]>
Date: Mon, 3 Oct 2016 15:39:07 +0000 (UTC)

Thanks, Tero.  Again, my comments inline. Nalini Elkins
Inside Products, Inc.www.insidethestack.com(831) 659-8360

      From: Tero Kivinen <[email-masked]>
 To: [email-masked] 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
 Sent: Wednesday, September 28, 2016 9:20 AM
 Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05
   
[email-masked] writes:
> Thanks for your comments.  We have posted a new draft with corrections at: 
> https://tools.ietf.org/html/draft-ietf-ippm-6man-pdm-option-06
> 
> Our responses inline.
>  
> Nalini Elkins
> 
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
> 
> 
> 
> ________________________________
> From: Tero Kivinen <[email-masked]>
> To: [email-masked]; [email-masked]; [email-masked] 
> Sent: Monday, September 19, 2016 7:12 AM
> Subject: Secdir review of draft-ietf-ippm-6man-pdm-option-05
> 
> >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 is not clear to me how knowing which ESP packets belong to which
> traffic flow helps a passive attacker.  The attacker still does not
> know what is in the packet - the contents of the payload.  Indeed,
> ESP would normally mask TCP or UDP ports.  With PDM you can tell
> that there ARE multiple flows but you don't know if they are TCP,
> UDP, ICMP or anything else.  Most importantly, you don't know what
> is in the payload.

>Sometimes that is only what is needed, and ESP tries to provide
>protection against traffic flow confidentiality, and this option
>breaks it.

>For example finding out that this flow of packets is the control
>traffic of the video stream, and this other flow of packets is the
>actual video stream, the attacker can for example block the control
>traffic, and make it so that user on the other end cannot stop the
>video feed.

>Or if there is 3 simultaneous video streams going out, it is much
>harder to identify which video stream is what TV-program. If you can
>separate them to 3 different video streams, it is much easier to
>identify the actual video being watched by checking the packet
>lengths.

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

> If one follows the thinking of your objection, isn't any encrypted
> flow over TCP or UDP a problem since a passive attacker knows the
> 5-tuple for such flows?  For example, all TLS flows can be analyzed
> for traffic in your sense.  So, a flow over TLS (without PDM)
> actually leaks more information than an ESP flow WITH PDM.  Because
> with TLS, we even know that the flow is TCP and the port number.
> Neither of which you know with PDM with ESP.

>Yes. And to fix that issue, people use IPsec which will hide the
>information about separate TCP and UDP flows.

>And now with PDM the IPsec will not provide that service anymore.
OK.  Pls see above.

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

>You did not respond to this part, i.e., why is the PDM header outside
>the ESP encrypted part, and why it is not inside the ESP?

>It is supposed to be destination option, which is only meaningful to
>the final destination of the packet, thus it can easily be inside the
>ESP protection, as the final destination do know the keys etc will see
>the decrypted option header.
Pls see above.

> >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.
> 
> Thanks.  Should now be fixed.

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

>If I understand correctly the actual timevalue conversion is so that

>   delta_time = delta_time_from_packet * 2^Scale

>where delta_time_from_packet is between 0x0000 and 0xffff, and scale
>is between -127 and 128, and the units are either milliseconds,
>microseconds, nanoseconds or picoseconds.

>So the smallist time we can express with this is

>delta_time_from_packet = 0x0001
>scale = -127
>unit = 11 = picoseconds

>   delta_time = 0.0000000000000000000000000000000000000058 picoseconds
>   = .0000000000000000000000000058 joktoseconds == 5.8 * 10^-51 seconds
  
>and the maximum value is

>delta_time_from_packet = 0xffff
>scale = 128
>unit = 00 = milliseconds

>   delta_time = 22300404916163702203072254898040929737768960 milliseconds
>   = 707141201045272139874183628172277 years...

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

> >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.
> 
> Please see above.

>Leaking this information is new security weakness for the protocol,
>which was designed to protect against those attacks. 
OK.

> >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.
> 
> 
> 
> 1. The intent of PDM is as a diagnostic feature.  PDM is OFF
> initially at the end hosts (client and server).  It is turned ON for
> diagnostics and then turned OFF afterwards.  If someone chooses to
> leave PDM ON always, then that is explicitly chosen.  Also, PDM is
> an OPTIONAL feature.  Either client or server operating system may
> choose not to implement it or use it.

>The draft disagrees with this. It says there is configuration option
>for it, but does not give default value for it, and says:

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

> 2. In your example above, it assumes that the signature verification
> packet (please let me know which exact packet and protocol you are
> referring to) is passing in the clear so that the attacker knows
> that it is the signature verification packet.  Possibly this is also
> a problem.

>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?
> 3.  Protocols often use blinding techniques to remove correlations
> between key and encryption time.  Other cryptographic algorithms
> can be implemented (or masked by a proxy) in a way that reduces or
> eliminates data dependent timing information.  So if timing
> information is being leaked, this is a flaw in the algorithm or the
> protocol.  In this case, we may be "blaming the messenger".  PDM is
> only reporting what is done.  The algorithm or protocol is the
> problem.

>Yes. This option makes it easy for the attacker to use those broken
>algorithms, protocols and implementations.

>This is again new security weakness that this option opens. It was
>harder before, after this it is easier. 
OK.

> >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. 
> 
> If you can give me a hint as to what is not clear or what you think
> this draft DOES propose, then we will be happy to rewrite the
> abstract / background section. 

>My current take is that this option proposes and attack vector against
>several different protocols, and as such it does quite good job...
Maybe I have missed my calling.   I should be designer of attack vectors!   (Just kidding.  HAHAHA.  Meant only as a  joke!)  

>I have a feeling that this is not for which this draft was meant to do. 
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?

-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 3 Oct 2016 15:44:39 +0000 (UTC)

I am resending this as the last post somehow got cut off in the middle.
 
Thanks,

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

________________________________
From: "[email-masked]" <[email-masked]>
To: Tero Kivinen <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, October 3, 2016 8:39 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05

Thanks, Tero.  Again, my comments inline.
 
Nalini Elkins

Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

OK.  Pls see above.

Pls see above.

  

OK.

OK.

-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 3 Oct 2016 16:16:05 +0000 (UTC)

Thanks,

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

 
Nalini Elkins

Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

OK.  Pls see above.

Pls see above.

  

OK.

OK.

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 10 Oct 2016 15:55:55 +0300

[email-masked] writes:
> 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. 

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

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

> OK.  So, are you saying that PDM is attack vector for TLS and not

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).
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 17 Oct 2016 23:54:30 +0000 (UTC)

Tero,

Thanks again so much for your comments.  I think they will really help to make the document better.   I am going to do some procedural things now so that we can move towards wrapping this up.

1.  I will make separate threads for each outstanding issue.  That way, we clean that up & then drop it.

2.  The outstanding issues that I see are:

--a.  Timebase issues

--b.  Location of PDM in ESP mode

--c.  Default configuration

--d.  Warnings about timing attacks

3.  Then, we need to respond to the gen-art comments.   (Quite a few! But that is another story.  And, not your problem but ours!)

 Thanks,

Nalini Elkins (for the co-authors)
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

----- Original Message -----
From: Tero Kivinen <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, October 10, 2016 5:55 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05

Good.

-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 17 Oct 2016 23:58:26 +0000 (UTC)

Tero,

This note will summarize and answer the comments on timebase.

>>specify what does negative scaling values mean, and when are they used. 
.... 
> 
>>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. 
 Thanks,

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

----- Original Message -----
From: Tero Kivinen <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, October 10, 2016 5:55 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05

Good.

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 18 Oct 2016 16:07:16 +0300

[email-masked] writes:
> 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.

Yep, but the problem is that if the implementation still need to be
able to cope with other devices using different time bases, this does
not help. 

> 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?

The problem is that some implementations measure time in 0.01 seconds
(10 ms), some implementations have timers which go up 60 times per
second, then there are implementations which have free running counter
running that full clock speed (or some fraction of clock speed or some
other very fast value, but not necessarely ms, µs, ns or ps).

So even if you have 4 time bases, there are lots of implementations
which need to convert their clock to something that is suitable for
the wireformat.

If we do not have time base, i.e. everything uses some common timebase
then you always need to do it, but on the other hand it is simple, as
there is no selection whether you should be using ms, µs, ns or ps are
your time base.

Having the 2^scale factor to the numbers will take care of being able
to represent any time value there, having two different ways of doing
scaling (both 2^scale factor and the time base) will just complicate
things. 

> Of course, we are open to discussion. 

I think it would be simplier to just have one fixed timebase, and it
might even be better to take the timebase so it is so small, that we
do not need negative exponents for scale, like attoseconds.

Attoseconds (10^-18) is so short that light can travel only 0.3 nm in
one attosecond, so that should be enough for PDM (until we get new way
of making transistors, and start measure latencies between
transistors).

If your clock is running milliseconds, you need to multiply the time
in ms with 0.88818 ((1000/1024)^5) to get time in attoseconds with
scale of 50. For microseconds the multiplier is 0.90949 with scale of
40, nanoseconds 0.93132 with scale of 30, picoseconds 0.95367 with
scale of 20, and femtoseconds 0.97656 with scale of 10.
-- 
[email-masked]

---

From: <[email-masked]>
Date: Tue, 18 Oct 2016 17:03:13 +0000 (UTC)

Tero,

Continuing the taking of issues 1 by 1.  
The discussion around Implementation Considerations boils down to two issues:

1.  Default value of PDM should be OFF

2.  It should not be possible to turn on PDM merely by receiving a packet with PDM in it.   

Current words:

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

Suggested changes:

"3.5 Implementation Considerations 

The PDM destination options extension header MUST be explicitly turned on by each stack on a host node by administrative action.  The default value of PDM is off.

PDM MUST NOT be turned on merely if a packet is received with a PDM header.  The received packet could be spoofed by another device."

Thanks,

Good.

-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 21:46:19 +0000 (UTC)

Tero,

Continuing to address the changes, this thread will discuss changes for Timing Attacks which may now be possible.

>Those attacks were not feasible before, but now they might be. 

Add to Section 8:

8.4 Timing Attacks

The fact that PDM can help in the separation of node processing time from network latency brings value to performance monitoring.  Yet, it is this very characteristic of PDM which may be misused to make certain new type of timing attacks against protocols and implementations possible.   Having said that, PDM is more likely to be used in response to an attack to find whether there are problems in the network or the node rather than its temporary use being exploited to mount an attack.  The normal use of PDM is likely to be for testing and diagnostics.  So, this is a short-term opportunity for an attacker.

Even so, if using PDM, we introduce the concept of user "Consent to be Measured" as a pre-requisite for using PDM.  Consent is common in enterprises and with some subscription services. So, if with PDM, we recommend that the user SHOULD consent to its use.

 Thanks,

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

----- Original Message -----
From: Tero Kivinen <[email-masked]>
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Monday, October 10, 2016 5:55 AM
Subject: Re: Secdir review of draft-ietf-ippm-6man-pdm-option-05

Good.

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2016 14:20:06 +0300

[email-masked] writes:
> diagnostics needed for problem resolution."
> 
> 
> Suggested changes:
> 
>  
> The PDM destination options extension header MUST be explicitly
> turned on by each stack on a host node by administrative action. The
> default value of PDM is off.
> 
> PDM MUST NOT be turned on merely if a packet is received with a PDM
> header. The received packet could be spoofed by another device."

That text looks good.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Oct 2016 14:36:26 +0300

[email-masked] writes:
> The fact that PDM can help in the separation of node processing time
> from network latency brings value to performance monitoring.  Yet,
> it is this very characteristic of PDM which may be misused to make
> certain new type of timing attacks against protocols and
> implementations possible.   Having said that, PDM is more likely to
> be used in response to an attack to find whether there are problems
> in the network or the node rather than its temporary use being
> exploited to mount an attack.  The normal use of PDM is likely to be
> for testing and diagnostics.  So, this is a short-term opportunity
> for an attacker. 
> 
> Even so, if using PDM, we introduce the concept of user "Consent to
> be Measured" as a pre-requisite for using PDM.  Consent is common in
> enterprises and with some subscription services. So, if with PDM, we
> recommend that the user SHOULD consent to its use. 

I think this text might need bit more text about the attacks. I.e. the
nature of these attacks is that they can leak out the long term
credentials of the device. So if attacker is able to make attack,
which causes the enterprice to turn on PDM to diagnose the attack,
then the attacker might use PDM during that debugging time to do
timing attack against the long term keying material used by the crypto
protocol. Immediately when they get the keying material out, they stop
the actual attack, which might then cause the defender to think that
nothing bad happend, and just disable PDM and go on, without realizing
that their long term keying material got stolen during the attack, and
that the visible attack was there only to cause them to turn on PDM...
-- 
[email-masked]

---

From: <[email-masked]>
Date: Mon, 24 Oct 2016 12:49:29 +0000 (UTC)

Tero,

> recommend that the user SHOULD consent to its use. 

[Tero's comments below]
>that the visible attack was there only to cause them to turn on PDM...

Tero, I am a bit reluctant to be completely specific as I think that will give people ideas that they might not have had before.

That is, before I say it, few people might think to launch such attacks but if I spell it out clearly that such attacks can be launched, then people who might not even have thought that this was possible, will now think that they can do it.

Let me think a bit about how to phrase this.

Nalini

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 25 Oct 2016 12:22:53 +0300

[email-masked] writes:
> Tero, I am a bit reluctant to be completely specific as I think that
> will give people ideas that they might not have had before.

Security by obscurity never works. Attackers have much more time to
think and plan about attacks than people who are implementing code for
something unrelated. If you are too vague, people who are implementing
PDM or the crypto protocols, thinks that those attacks are impossible.
It is better to spell them out for those implementing those so they
can make needed security measures for those.

One of those security measures could for example be that PDM is
enabled only for certain ip-addresses, or only for some ports. Another
would be to enable it for certain timeperiod (for example for 1 hour),
so it can be made sure that PDM is not accidently left on after
debugging has been done etc. 

> That is, before I say it, few people might think to launch such
> attacks but if I spell it out clearly that such attacks can be
> launched, then people who might not even have thought that this was
> possible, will now think that they can do it.

I think it is better to explain the attacks properly to the PDM
implementors, so they understand what kind of things they need to
think about when implementing PDM. Same thing for the people
implementing crypto protocols. They need to understand that with PDM
some things that used to be hard will be easy.

If you just give general warnings, that means that quite a lot of
implementors think that this text is just general text, not really
specific for this. So implementors might think it does not concern
them, and ignore the issue. 
-- 
[email-masked]

---

From: <[email-masked]>
Date: Thu, 27 Oct 2016 16:24:28 +0000 (UTC)

Tero,
I am trying to do the wording for ESP processing:
Below are your comments:
>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

>still provides performance metrics for the host. 
This is the old section 3.4
3.4 Header Placement Using IPSec ESP Mode

   IP Encapsulating Security Payload (ESP) is defined in [RFC4303] and
   is widely used.  Section 3.1.1 of [RFC4303] discusses placement of
   Destination Options Headers.   Below is the diagram from [RFC4303]
   discussing placement.  PDM MUST be placed before the ESP header in
   order to work.  If placed before the ESP header, the PDM header will
   flow in the clear over the network thus allowing gathering of
   performance and diagnostic data without sacrificing security.

                           BEFORE APPLYING ESP

             ---------------------------------------
       IPv6  |             | ext hdrs |     |      |
             | orig IP hdr |if present| TCP | Data |
             ---------------------------------------

                            AFTER APPLYING ESP
             ---------------------------------------------------------
       IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
             |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
             ---------------------------------------------------------
                                          |<--- encryption ---->|
                                          |<------ integrity ------>|

              * = if present, could be before ESP, after ESP, or both

New Section 3.4

3.4 Header Placement Using IPSec ESP Mode

   IPSec Encapsulating Security Payload (ESP) is defined in [RFC4303] and
   is widely used.  Section 3.1.1 of [RFC4303] discusses placement of
   Destination Options Headers.   
   The placement of PDM is different depending on if ESP is used in    tunnel or transport mode.

   3.4.1 Using Transport Mode
   Below is the diagram from [RFC4303] discussing placement of headers.   Note that Destination Options MAY be placed before or after ESP or   both.   In transport mode, PDM MUST be placed after the ESP header so   as not to leak information. 
                           BEFORE APPLYING ESP

             ---------------------------------------
       IPv6  |             | ext hdrs |     |      |
             | orig IP hdr |if present| TCP | Data |
             ---------------------------------------

                            AFTER APPLYING ESP
             ---------------------------------------------------------
       IPv6  | orig |hop-by-hop,dest*,|   |dest|   |    | ESP   | ESP|
             |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV|
             ---------------------------------------------------------
                                          |<--- encryption ---->|
                                          |<------ integrity ------>|

              * = if present, could be before ESP, after ESP, or both

3.4.2 Using Tunnel Mode
   Below is the diagram from [RFC4303] discussing placement of headers.   Note that Destination Options MAY be placed before or after ESP or   both in both the outer set of IP headers and the inner set of IP   headers.
   In tunnel mode, PDM MAY be placed before or after the ESP header    or both.

                             BEFORE APPLYING ESP
            ---------------------------------------
      IPv6  |             | ext hdrs |     |      |
            | orig IP hdr |if present| TCP | Data |
            ---------------------------------------

                     AFTER APPLYING ESP

            ------------------------------------------------------------
      IPv6  | new* |new ext |   | orig*|orig ext |   |    | ESP   | ESP|
            |IP hdr| hdrs*  |ESP|IP hdr| hdrs *  |TCP|Data|Trailer| ICV|
            ------------------------------------------------------------
                                |<--------- encryption ---------->|
                            |<------------ integrity ------------>|

            * = if present, construction of outer IP hdr/extensions and
                modification of inner IP hdr/extensions is discussed in
                the Security Architecture document.
 Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

Good.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Oct 2016 15:18:05 +0300

[email-masked] writes:
>    Below is the diagram from [RFC4303] discussing placement of headers.
> 
>    Note that Destination Options MAY be placed before or after ESP or
>    both.   In transport mode, PDM MUST be placed after the ESP header so
>    as not to leak information. 
> 
>                            BEFORE APPLYING ESP
> 
>    Below is the diagram from [RFC4303] discussing placement of headers.
> 
>    Note that Destination Options MAY be placed before or after ESP or
>    both in both the outer set of IP headers and the inner set of IP
>    headers.
> 

For tunnel mode you could add text noting, that as the sgw will make
completely new IP packet, 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 TCP ports etc in the
inner header, but will be specific to the ESP flow.

If you want to see PDM information for the inner packet, the original
host sending the inner packet needs to put PDM header in the tunneled
packet, and then the PDM information will be specific for that TCP
stream.

So if the PDM header is part of "new ext hdrs*" then it specifies the
ESP flow, and it will not be end to end, it will only between SGSs. If
the PDM is part of the "orig ext hdrs*", then it will be end to end
PDM header, and ESP processing does not modify it at all. This
location is only place, where you can get end to end information about
the flow.

The first PDM header which is part of the ESP, will not separate TCP
flows at all, as it is for the ESP packets, thus it might not be that
useful, especially as there is no relation between the inbound ESP
packet and outbound ESP packet. The inbound ESP packet might be TCP
packet, and the tunneled packet is sent forward to the inner network,
and then the next outbound ESP packet might be from some completely
different host in different stream, and might be for example UDP DNS
packet. Having PDM information between those packets does not really
help debuggin at all. 
-- 
[email-masked]