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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
