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,

Thanks for your responses, please see my comments inline.

Yours,
Daniel



On Fri, Aug 31, 2018 at 3:12 AM Heinrich Singh <[e-mail]>
wrote:

> Hello Daniel,
>
> Text saying that you would loose some privacy by using fixed number of SPI
> does not absolve your responsibility. It should not recommend that.
>
> <mglt>
I got your point. Thanks. While fix SPI is permitted by  RFC4303, and the
document implicitly described it as an non recommended alternative, you
would like the guidance to be more explicit.  We can add text stating that
because of privacy, fix SPI is not recommended for generic purpose
implementations.

I believe that the point fo this document is to provide some implementation
guidance for specific implementation to implement ESP optimized for
specific use cases while remaining compatible to the standard ESP. As a
result, guidance may go beyond the once fits all use cases. Of course the
document should clarify the limitations.
</mglt>



> I do not know 802.15. Others can also say what they feel but from my
> experience simple monotonic sequence numbers are more easier than having a
> clocks. This I think is a not a good idea. Sender and receiver can easily
> get out of sync because your rate of sending packets is not proportional to
> time. The receiver would need to allow very large window. The sender would
> still need to store time to flash in-case there is need for sync after
> device reset.
>
<mglt>
First all of all, the draft clearly stated that the use of time is an
alternative ways which is not the most usual implemented mechanism. I
believe that similarly as the previous section, we could explicitly mention
that the recommended way to generate SSN is to increment it. We can also
add text the explicit text regarding the additional constraints, and
specify that such way is not recommended for a generic purpose
implementation.

Similarly we should clarify, the limitations for this specific mechanism,
so the mechanism could be chosen only when appropriated. Again, constraint
device have different constraints, and there specificities may allo one or
the other mechanisms to be used. There are many use cases where devices
sends informations are regular time interval and that the lost of a packet
will have a limited impact.

However I am happy you raises the discussion that can continue on the list.
Thank you.
</mglt>

>
> What you mean implementations must discard dummy packets? Even
> non-constrained implementations must discard dummy packets so what is new
> here?
>
> <mglt>
I meant packet with next header value set to 59.
</mglt>

Okay. the paper you send me is for linux kernel, not for constrained device.
>
> <mglt>
Thisis correct. I mentioned it as maybe a starting point for the specific
topic your mentioned.
</mglt>

> Ciao
> Heinrich
>
> On Wed, 29 Aug 2018 at 19:17, Daniel Migault <[e-mail]>
> wrote:
>
>> 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
>>>
>>>
>> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>