Subject: [core] FW: New Version Notification for draft-liu-core-coap-delay-attacks-01.txt

From: "Zhujintao (Julian)" <[email-masked]>
Date: Mon, 6 Nov 2017 06:16:35 +0000

Hi,

We submitted this draft for proposing an alternative mechanism to troubleshooting the Delay Attack issue in the CoAP.
Compared with the server-initiated 2-RTT challenge response mechanism specified in [I-D.mattsson-core-coap-actuators] and [Echo and Request-Tag], this new mechanism proposes a client-initiated 1-RTT mechanism.

We would like to hear a feedback from you on this draft.

Thank you and best regards,
Julian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, October 30, 2017 6:07 PM
To: Zhujintao (Julian) <[email-masked]>; Liuyan (Scarlett) <[email-masked]>; Zhujintao (Julian) <[email-masked]>
Subject: New Version Notification for draft-liu-core-coap-delay-attacks-01.txt

A new version of I-D, draft-liu-core-coap-delay-attacks-01.txt
has been successfully submitted by Jintao Zhu and posted to the IETF repository.

Name:		draft-liu-core-coap-delay-attacks
Revision:	01
Title:		Mitigating delay attacks on Constrained Application Protocol
Document date:	2017-10-30
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-liu-core-coap-delay-attacks-01.txt
Status:         https://datatracker.ietf.org/doc/draft-liu-core-coap-delay-attacks/
Htmlized:       https://tools.ietf.org/html/draft-liu-core-coap-delay-attacks-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-liu-core-coap-delay-attacks-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-liu-core-coap-delay-attacks-01

Abstract:
   Various attacks including delay attack have become a topic in the
   security of Internet of Things (IoT), especially for the constrained
   nodes utilizing sensors and actuators which connect and interact with
   the physical world.  [I-D.mattsson-core-coap-actuators] describes
   several serious delay attacks, discusses tougher requirements and
   then recommends mechanisms to mitigate the attacks.  It also
   specifies some disadvantages with the mechanisms.  This document
   proposes alternative mechanisms to address some of the disadvantages

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Göran Selander <[email-masked]>
Date: Mon, 13 Nov 2017 07:07:38 +0000

Hi Julian,

Thanks for continuing the discussion on time-based freshness. I provided
some direct feedback previously, here are some of the comments repeated on
the mailing list to allow discussion in a wider group.

1. What use cases are you have in mind? It is easy to appreciate the
problem statement that timing may be critical for making an actuation, but
what are the concrete use cases, in particular motivating the three modes
in 4.2.2?

2. Overall the draft assumes synchronised time between client and server,
or specifically that the client is aware of the time of the server. But
there is no consideration whatsoever in the draft about how that is
achieved and maintained. There are a number of issues related to that
considering e.g. initial synchronisation, time drifting,  rebooting
devices, daylight saving time, etc.

3. Your draft could be implemented as an application of CoAP, i.e. in the
CoAP payload. Considering that the freshness requirements may be very
specific depending on use cases, maybe some parts should be left to the
application?

As a summary, I agree that complementing the challenge-response based
freshness provided by Echo with components supporting time-based freshness
would be useful. These are two independent mechanisms and there is good
motivation for both. I think the next steps in time-based freshness could
include a) a presentation of the different use cases in scope, b) a
motivation of what part of the solution should be standardised and what
should be left to the application, and c) a proposal for solving to the
issues of time synchronisation in this context.

Göran

´

On 2017-11-06 07:16, "core on behalf of Zhujintao (Julian)"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi,
>
>We submitted this draft for proposing an alternative mechanism to
>troubleshooting the Delay Attack issue in the CoAP.
>Compared with the server-initiated 2-RTT challenge response mechanism
>specified in [I-D.mattsson-core-coap-actuators] and [Echo and
>Request-Tag], this new mechanism proposes a client-initiated 1-RTT
>mechanism.
>
>To: Zhujintao (Julian) <[email-masked]>; Liuyan (Scarlett)
><[email-masked]>; Zhujintao (Julian) <[email-masked]>
>URL:            
>https://www.ietf.org/internet-drafts/draft-liu-core-coap-delay-attacks-01.
>txt
>Status:         
>https://datatracker.ietf.org/doc/draft-liu-core-coap-delay-attacks/
>Htmlized:       
>https://tools.ietf.org/html/draft-liu-core-coap-delay-attacks-01
>Htmlized:       
>https://datatracker.ietf.org/doc/html/draft-liu-core-coap-delay-attacks-01
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-liu-core-coap-delay-attacks-01
>
>Abstract:
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 16:41:42 +0800

> specific depending on use cases, maybe some parts should be left to the

(That is actually true of the nonce-based freshness, too.
Application-layer is the way nonce-based freshness is done in the Web.
The Echo option proposal just reflects that there is an advantage in having a common way of doing this.)

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Mon, 13 Nov 2017 10:08:43 +0000

>having a common way of doing this.)

Correct. The intention with Echo is to provide a small generic solution
for nonce-based freshness which can be used by many applications. I would
like something similar with time-based freshness.

Göran