Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload

Rafa Marin Lopez <rafa@um.es> Mon, 12 October 2015 18:41 UTC

Return-Path: <rafa@um.es>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF7D1B2B97; Mon, 12 Oct 2015 11:41:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 m0DdAUgiKttz; Mon, 12 Oct 2015 11:41:52 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id E71091B2B94; Mon, 12 Oct 2015 11:41:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 7C74736C0; Mon, 12 Oct 2015 20:41:50 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tiiscu4OC4gI; Mon, 12 Oct 2015 20:41:50 +0200 (CEST)
Received: from [192.168.1.44] (11.Red-79-144-178.dynamicIP.rima-tde.net [79.144.178.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 5A5ED36BC; Mon, 12 Oct 2015 20:41:47 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3094\))
From: Rafa Marin Lopez <rafa@um.es>
In-Reply-To: <56162F1A.5020503@ackl.io>
Date: Mon, 12 Oct 2015 20:41:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DEC84E1F-F40D-48C2-8CBD-8262FADD45B2@um.es>
References: <56162F1A.5020503@ackl.io>
To: Alexander Pelov <a@ackl.io>
X-Mailer: Apple Mail (2.3094)
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/ZX4rIsZFtY6NEjDnGMMgxAvrXgQ>
Cc: 6tisch@ietf.org, Dan Garcia <dan.garcia@um.es>, Rafa Marin Lopez <rafa@um.es>, ace@ietf.org
Subject: Re: [6tisch] [Ace] Optimizing EAP-over-CoAP payload
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 12 Oct 2015 18:41:54 -0000

Dear Alexander:

Thanks for your comments 

> El 8 oct 2015, a las 10:53, Alexander Pelov <a@ackl.io> escribió:
> 
> Dear Rafa,
> 
> I've been reading the latest version of your draft ( draft-marin-ace-wg-coap-eap-01.txt ), and I have a couple of questions regarding some of the payload options, which could be optimized even further:
> 
> 1) Use shorter name for the /auth resource
> 2) Mandate the use of zero-length CoAP token
> 
> The first, and the more simple one, is - would it be possible to change the name of the authentication resource from /auth to a shorter one (like /a)? Maybe it could be an option to change the name of this resource, based on the underlaying architecture, e.g. an RFC could mandate that in a specific network the resource could be named /a, whereas the default value could remain /auth?

[Rafa] I do not see any problem to shorten the resource name.

> 
> The second, which is a little bit more subtle. Tokens are used to match responses to requests, but during the authentication/authorization phase a single peer (endpoint) would communicate with a single authenticator. Moreover, the communication happens in a serial fashion, and responses are piggybacked. This falls in the case when zero-length token is also advised by RFC7252. Do you think that it would be appropriate to make the use of zero-length token mandatory for EAP-over-CoAP?

[Rafa] I guess you are referring to this text:  

"An empty token value is appropriate e.g., when
   no other tokens are in use to a destination, "or when requests are
   made serially per destination and receive piggybacked responses.”

I would say that using zero-length token is possible. What I am not sure is whether make it mandatory or not. I mean we could say that if the client sends a zero-length token the server can consider it OK as per the text above. If there is a non-zero length token value should be also fine.

What do you think?

Best Regards.

> 
> Best,
> Alexander
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------