Hi Steve,
Thanks for the feed back.
Just to clarify the general compression principle: When a field is
compressed, it means that the field is not (or partially) sent on the wire.
However, the complete field has been used to generate the packet, and the
whole field MUST be decompressed by the receiving side to go further. The
idea beyond this principle is that we do not want to alterate the security
of the (non- compressed) protocol and we want to benefit from the security
analyze of the (non- compressed) protocol. In our case the protocol is
IPsec/ESP.
This means that SN is always the 32 bit Sequence Number of the ESP Packet (
64 bit if you use Extended Sequence Number). These two sizes are considered
for generation of the ICV as well as for the anti replay mechanism as
described in RFC4303. The compressed SN is a portion of the SN, that should
be enough to help retrieving the whole SN. If your are not able to retrieve
the whole SN, then there is little you can do, as the whole SN MUST be
retrieve for ICV check/ anti-replay attack.
This is the same case for the SPI.
The collision has not been documented in the current draft, and you are
right we will have to do that. I am not doing the analyze in that mail --
as I want to send the response before the wifi is done-- but I will respond
later. Thanks for the suggestion.
It is also true that collision involves more computation. However, in the
IoT world, computation versus sending is (to some extend of course) always
a win. Here is the example I have in mind.
- Computing: ranges from 0.5nJ per instruction for extremely
energy-efficient microcontrollers (such as CoolRisc or MSP430) to 200 nJ
per instruction for high-performance microprocessors (such as ARM9).
- Communication: from 100nJ to 1uJ per bit transmitted or received,
depending on modulation complexity and transmission power (we only consider
"low-power" radios, with transmit powers lower than about 10mW).
Roughly speaking, this means that, for the energy cost of exchanging 1 bit,
our system can alternatively compute 10-100 instructions. Therefore, there
is a high interest in compressing frames before transmitting them
Note that if that is not the case in some scenarios, or with some future
technologies. As we have the flexibility to define the compression, and as
compression does not impact the IPsec processing of the (decompress)
packet, one can always redefine the number of bytes to send.
BR,
Daniel
On Fri, Jul 25, 2014 at 6:26 PM, Stephen Kent <[email protected]> wrote:
> Daniel,
>
> Thanks for the explanation.
>
>> ...
>>
>>
>> The draft does not specify how matching between IV_i and packet i is
>> performed.
>> - 1) you may use the SN as the packet counter. Of course it is easier
>> if the SN increments for each packet. However SN are not part of the IV
>> generation.
>>
> which SN? the one from ESP? Doesn't Diet-ESP significantly reduce the
> sequence number space?
> if the SN space is small, then there may be ambiguity at the receiver.
>
> - 2) you may use the least significant bytes to determine which IV may
>> match.
>> This way of doing so differs in the current way of sending the IV as we
>> do not have the IV from the packet. In our case, the IV is not derived from
>> the packet, we need to generate a few number of IV in advance, and find out
>> which is the one matching a particular packet.
>>
> This sentence suggests that the least significant bytes above are from the
> "compressed"
> IV. Is that right? If the IV is pseudorandom, and it's compressed
> representation is small,
> e.g., 2 bytes, what is the likelihood that two IVs will have the same
> representation, within
> a receive window of, say 32 packets? (This is a drawing balls from an urn
> with replacement
> problem, I think). This might result in a frequency of collision that may
> be an issue, causing
> the receiver to have to do crypto processing on colliding packets.
>
> Motivation for doing so is that sending a byte in 6lo cost more than
>> doing a few thousand operations. In that sense, we are ready to implement
>> some more complex IV-to-i function.
>>
> Isn't the "lo" in 6lo, low power? Is it clear that the cycles vs.
> bandwidth tradeoff is always
> a win?
>
> Steve
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
