Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Mališa Vučinić <malisa.vucinic@inria.fr> Wed, 27 March 2019 22:29 UTC

Return-Path: <malisa.vucinic@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6958912001E for <6tisch@ietfa.amsl.com>; Wed, 27 Mar 2019 15:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level:
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVSPo1HZ3JRi for <6tisch@ietfa.amsl.com>; Wed, 27 Mar 2019 15:29:40 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA8E120091 for <6tisch@ietf.org>; Wed, 27 Mar 2019 15:29:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,277,1549926000"; d="scan'208,217";a="300956712"
Received: from lfbn-1-4189-38.w92-169.abo.wanadoo.fr (HELO mp341-pro.home) ([92.169.181.38]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2019 23:29:02 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <B7DECDC9-5521-4A0B-9590-0620CF123CA7@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D6CFA8B-1208-42C0-9E85-67CE3035F2D0"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 27 Mar 2019 23:29:01 +0100
In-Reply-To: <20190327172921.GA9348@hephaistos.amsuess.com>
Cc: 6tisch@ietf.org
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
References: <20190327172921.GA9348@hephaistos.amsuess.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/1mS1WO3XnusIWL456P1DqJTQ2Vk>
Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Mar 2019 22:29:46 -0000

Hello Christian,

Thank you for summarizing the discussion we had and proposing these changes. I have modified the text in order to reflect the email below by:
- encoding additional info as a CBOR array allowing multiple parameters to be transported within
- removing the previous error code which explicitly was referring to the state of a request
- renaming of Error object to Diagnostic, if you have a better naming proposal, please let me know
- encapsulating the entire link layer key object(s) that is unsupported by a given pledge. I believe this is the simplest handling from the pledge implementation point of view as it can simply memcpy the byte string received

I also did some minor edits to align the text in the rest of the document, the related diff is available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff>

Please let me know if you see any issue with this resolution.

Mališa

> On 27 Mar 2019, at 18:29, Christian Amsüss <christian@amsuess.com> wrote:
> 
> Hello Mališa,
> 
> we've just talked about server state and the error codes sent with
> subsequent join requests in [1], especially Sections 8.4.1 and Section
> 8.4.5. (Working group, please be aware that I have not read and
> understood the full document but am responding to a particular question
> here).
> 
> My understanding is that the pledge POSTs its Join_Request to the
> server, initially without an Error, and receives a response. If it has
> trouble acting on the response, it sends another request that includes
> the original parameters plus an error object; the server may respond to
> that with a more final error ("Sorry, then I can't help you either") or
> by sending a different response ("OK, if you can't do X, here's a setup
> that works without that"). The question is as whether that agrees with
> the a RESTful design and to the stateless servers we aspire in CoRE.
> 
> The error handling as currently described requires the server to keep
> around information about the previous request. That is not per se a
> violation of the side effect rules of CoAP (as the request is a POST and
> the server may change state as a result), but has non-idempotent POST
> requests which are discouraged in CoRE, and could be avoided easily.
> 
> Suggestion: Chain errors in the requests
> ----------------------------------------
> 
> I suggest that only errors be sent in subsequent requests that are
> self-descriptive, and not so much indicate "what happened" but more
> "what the pledge can't do"; then the server does not need to remember
> the history of each pledge's requests.
> 
> If that is to be played back-and-forth (and I understand there are up to
> four attempts), this requires that the pledge can indicate more than one
> thing that went wrong. As long as there is only one error field, if
> (say) the client tells the server after the first round-trip that it
> doesn't support option X and the server offers option Y instead, the
> client could only indicate with the response that it won't support
> option Y, and the server would happily give it X again. Making the error
> field in the Join_Request a list would ease that, and might even allow
> for fewer round-trips if the pledge can issue complaints about several
> options in the first round-trip.
> 
> Having a list of errors does obviously increase complexity a little, and
> it requires the client to keep track of things that it dislikes about
> the server's previous responses. My impression is that pledges can
> probably afford that (it's state of size that's limited by the number of
> attempts it's willing to do, and is only kept during the joining
> process), freeing the serve of keeping around state of every pledge for
> some potentially-hard-to-tell time.
> 
> 
> Suggestion: Require errors to be self-descriptive
> -------------------------------------------------
> 
> With that alone, a stateless server can be constructed, though the
> conceptualization would be a bit convoluted (the precise rules of
> interpreting the error codes would be "Had I sent you this request with
> one less error, your response would trigger error X in me") --
> stateless, but not particularly elegant to think about or easy to act
> on.
> 
> If the error codes could be limited to statements that are valid truths
> irrespective of hypothetical answers, that would look cleaner but
> supports only error codes that state such valid truths. Conceptually, it
> would not so much be an "error" field but a "things I'm telling you in
> advance I can't do".
> 
> Of the list in Table 4, I'd say that
> 
> * 0 is not applicable (it's a server response)
> * 1 should not be expected to be recoverable, and in this model of
>  thought becomes very fuzzy. ("Give me that, but I know I can't act on
>  it...?")
> * 2 is fine as long as it relates to the number of the option it doesn't
>  understand but not the value (The statement would be "I don't support
>  option X" -- something the pledge could have even said in advance).
> * 3 is not good but can easily be fixed by indicating a key ID rather
>  than an index in a list whose indices will change when the server
>  tries to do better.
> * 4 is fine (that, like with 2, is something the pledge could even have
>  said in advance).
> 
> 
> 
> From the discussion before I take it that this is something that can
> easily be fixed; if you want me to look at the changes you'd make to
> accommodate this, I'd be happy to have a brief look. (Just please CC me,
> I'm not actively reading the 6tisch list).
> 
> Have a good flight
> Christian
> 
> 
> [1]: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom