Re: [Lwip] [IPsec] The LWIG WG has placed draft-mglt-lwig-minimal-esp in state "Call For Adoption By WG Issued"

[Daniel Migault <[e-mail]>]

Hi Heinrich,

Thank you for reviewing the draft. Please find my response inline. I
believe your concerns are addressed in the draft within the scope of the
draft. The work you are mostly looking at would be an efficient TFC / dummy
packet policy. This would more probably be in scope of ipsecme WG.

Yours,
Daniel



On Thu, Aug 23, 2018 at 2:32 PM, Heinrich Singh <[e-mail]>
wrote:

> Hello IETF,
>
> I am new to LWIP/IPSEC. I read draft-mglt-lwig-minimal-esp. Here is my
> summary:
>
>
>    1. Don't use random SPI because getting randomness on small devices is
>    expensive. This will of course leak privacy. If a vendor/app uses fixed SPI
>    for his devices, then someone on the network can find out info of
>    vendor/app.
>
> <mglt>
This is correct and I believe this statement is provided in the draft. Is
there, in your opinion, anything we should add in the text below:

   The use of a limited number of fix SPI also come with security or
   privacy drawbacks.  Typically, a passive attacker may derive
   information such as the number of constrained devices connecting the
   remote peer, and in conjunction with data rate, the attacker may
   eventually determine the application the constrained device is
   associated to.  In addition, if the fix value SPI is fixed by a
   manufacturer or by some software application, the SPI may leak in an
   obvious way the type of sensor, the application involved or the model
   of the constrained device.  As a result, the use of a unpredictable
   SPI is preferred to provide better privacy.

   As far as security is concerned, revealing the type of application or
   model of the constrained device could be used to identify the
   vulnerabilities the constrained device is subject to.  This is
   especially sensitive for constrained device where patches or software
   updates will be challenging to operate.  As a result, these devices
   may remain vulnerable for relatively long period.  In addition,
   predictable SPI enable an attacker to forge packets with a valid SPI.
   Such packet will not be rejected due to an SPI mismatch, but instead
   after the signature check which requires more resource and thus make
   DoS more efficient, especially for devices powered by batteries.


</mglt>
 Also, why a device can generate random number for doing IKEv2, nonces etc.
but not for generating SPI?

<mglt>

I am reading your text as if the draft were recommending the use of non
random SPI, while you would expect the draft to recommend a random
generation of the SPI. I think the draft address your comment by
recommending a random generation of the SPI with the text below:

   It is RECOMMENDED to randomly generate the SPI indexing each inbound
   session.  A random generation provides a stateless way to generate
   the SPIs, while keeping the probability of collision between SPIs
   relatively low.  In case of collision, the SPI is simply re-
   generated.


We could have hardly go further for example by saying SPI MUST be randomly
generated as this is not required by RFC4303. Such requirement woudl have
been out of scope of the draft as the purpose of the draft is not to update
the standard ESP and become a replacement of RFC4303. instead, its purpose
is to implement a minimal version of RFC 4303. SPI randomness is not
required by RFC4303, so this document cannot mandate SPI generation to be
random.

The draft also clearly stated that non compromise on random generator
should mad for random used for cryptographic purpose. This is not the case
for SPI, and some device may, when necessary, use this to save cycles.

</mglt>

>
>    1. Storing sequence numbers is difficult so devices can use time.
>    Getting time on small devices is actually much harder. Also is there some
>    hard info that reading time is cheaper than reading sequence number from
>    memory? I can also look at packets much later and tell when you sent a
>    packet.
>
> <mglt>
We received this example from people following IEEE802.15. It would be good
you share your information why reading time is much harder, so the
discussion can happen on the mailing list. From my perspective the main
idea was to explain that you could take advantage of an already existing
"always increasing" function set on your device. Typically, the time is
shared across the device and can be used by ALL session, instead of having
multiple Sequence numbers.

As a side note, if your cases does not fit this, you do not necessarily
need to follow this implementation ;-). However, I am happy if your are
proposing text to make this more accurate.
</mglt>

>
>    1. Don't use Traffic Flow Confidentiality again loosing privacy.
>
> <mglt>
I believe this is what the current version of the draft says. However, as
mentioned before, this draft is not updating RFC4303 and as such cannot
make this feature mandatory.

In addition, TFC is *really* not the kind of feature we expect for a
minimal implementation in constrint devices. Typically it consists in
adding extra bytes while this is precisely the tasks that consumes the more
resource for most of the constraint devices. In addition, managing TFC to
avoid creating a new pattern is neither trivial, nor widely used. It woudl
be mostly based on statistics, and such functionalities are not expected to
be found on constraint device. It is not obvious also that such option
could introduce specific patterns which could also loose privacy.

Again if you find the text misleading, I am happy you propose text to
improve it.

   ESP [RFC4303 <https://tools.ietf.org/html/rfc4303>] also provides
Traffic Flow Confidentiality (TFC) as a
   way to perform padding to hide traffic characteristics, which differs
   from respecting a 32 bit alignment.  TFC is not mandatory and MUST be
   negotiated with the SA management protocol.  As a result, TFC is not
   expected to be supported by a minimal ESP implementation.  On the
   other hand, disabling TFC should be carefully measured and understood
   as it exposes the node to traffic shaping.  This could expose the
   application as well as the devices used to a passive monitoring
   attacker.  Such information could be used by the attacker in case a
   vulnerability is disclosed on the specific device.  In addition, some
   application use - such as health applications - may also reveal
   important privacy oriented informations.

   Some constrained nodes that have limited battery life time may also
   prefer avoiding sending extra padding bytes.  However the same nodes
   may also be very specific to an application and device.  As a result,
   they are also likely to be the main target for traffic shaping.  In
   most cases, the payload carried by these nodes is quite small, and
   the standard padding mechanism may also be used as an alternative to
   TFC, with a sufficient trade off between the require energy to send
   additional payload and the exposure to traffic shaping attacks.


</mglt>

>
>    1. Don't use dummy packets again loosing privacy.
>
> <mglt>
The draft does not prevent the use of dummy packets. Instead implementation
must be able to discard received dummy packet.. I believe the issue you are
raising is that RECOMMEND be changed in MUST. Thanks for raising this I
will update the draft. What the draft says is rather setting a widely used
policies for generating dummy packets, i.e. that is generating none. I do
not think we expect more from a minimal implementation.

Similarly, handling dummy packet is not obvious, and maybe not expected to
be treated correctly by constrained devices.  The draft also mention the
privacy issues associated to not generating dummy packets. Is there any
text you woudl like to propose ?

   The ability to generate and receive dummy packet is required by
   [RFC4303 <https://tools.ietf.org/html/rfc4303>].  For
interoperability, it is RECOMMENDED a minimal ESP
   implementation discards dummy packets.  Note that such recommendation
   only applies for nodes receiving packets, and that nodes designed to
   only send data may not implement this capability.

   As the generation of dummy packets is subject to local management and
   based on a per-SA basis, a minimal ESP implementation may not
   generate such dummy packet.  More especially, in constrained
   environments sending dummy packets may have too much impact on the
   device life time, and so may be avoided.  On the other hand,
   constrained nodes may be dedicated to specific applications, in which
   case, traffic pattern may expose the application or the type of node.
   For these nodes, not sending dummy packet may have some privacy
   implication that needs to be measured.




</mglt>

>
>    1. Reference rfc 8221 for IoT related crypto suites.
>
> <mglt>
The draft provide the reference at least 5 times.
</mglt>


>
>    1.
>
> I don't know why IETF would publish this document when they have rfc 6973.
>
I want to see some actual performance from a real ESP implementation where
privacy is protected and energy is saved by tweaking the TFC and how often
dummy packet is sent.

<mglt>
I agree that would be an interesting topic, but outside teh scope of
defining a minimal implementation for the current ESP. I believe the work
you are expecting is the definition of an efficient TFC / dummy packet
policies. This is currently more a research project. This may be a link of
interest:
https://www.researchgate.net/publication/224720331_Traffic_masking_in_IPsec_architecture_and_implementation

</mglt>

>
> Ciao
> Heinrich
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>