From congwang@cityu.edu.hk Mon Dec 9 09:06:12 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837531AE385 for ; Mon, 9 Dec 2013 09:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.578 X-Spam-Level: X-Spam-Status: No, score=-5.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 2GkCgvUC3X_c for ; Mon, 9 Dec 2013 09:06:10 -0800 (PST) Received: from smtp01.cityu.edu.hk (smtp01.cityu.edu.hk [144.214.4.70]) by ietfa.amsl.com (Postfix) with ESMTP id 053801ADFE0 for ; Mon, 9 Dec 2013 09:06:10 -0800 (PST) Received: from smtp01.cityu.edu.hk (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CBF3D3C248 for ; Tue, 10 Dec 2013 01:06:04 +0800 (HKT) Received: from lily02 (ausmtp.cityu.edu.hk [144.214.6.44]) by smtp01.cityu.edu.hk (Postfix) with ESMTP id 65C1A3C23E for ; Tue, 10 Dec 2013 01:06:03 +0800 (HKT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by ausmtp.cityu.edu.hk (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPSA id <0MXJ00MBCU604Y50@ausmtp.cityu.edu.hk> for dtls-iot@ietf.org; Tue, 10 Dec 2013 01:06:01 +0800 (HKT) Sender: congwang@cityu.edu.hk Received: by mail-wi0-f181.google.com with SMTP id hq4so4043809wib.2 for ; Mon, 09 Dec 2013 09:05:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=LohcgPTitWTQ7EAeQkmAMZOaFAY59yK+s8v83caBTFo=; b=WEOC2PLUaRZWzM9lJTp07JZfCtgkgBrzSvvVfJxX++UUYAI0nAZwcmzdwe1gyahWLF Q8O74vKAnOCF1YiIdgRwkfS3GB/gFMZvpYpJ1Lnj7Ho0kDwrtF3aCssNxuRTJXgbQPvG JF82klw8zXhpX1xAQsp+y2tVTrnoO0DuYvp4Nicru6j8cPCaGHnbN23LZlUej7/nt2Ec NJyBOeRJKJRYc8MZ2nZXRI+Al3nXeAlpfJ/hL/V2Au1kVbALIyXgTlZTN+MGJxfZcG7C YAJn79X3ZnCXrNBZ5lYqvl0n4I6dIyqDHDREhZ/x/jIGmu5x9oNUsINbbPzq5ZEsP3eC P02g== X-Received: by 10.194.175.133 with SMTP id ca5mr16572393wjc.19.1386608758860; Mon, 09 Dec 2013 09:05:58 -0800 (PST) MIME-version: 1.0 Received: by 10.227.232.5 with HTTP; Mon, 09 Dec 2013 09:05:38 -0800 (PST) From: Cong Wang Date: Tue, 10 Dec 2013 01:05:38 +0800 Message-id: <17642_1386608764_52A5F87B_17642_2030_1_CABq1=da=2ro0uEgZmusX+tsX+yuT4Smu0_Q+uyyVpdLwgO7SiQ@mail.gmail.com> To: dtls-iot@ietf.org Content-type: multipart/alternative; boundary=089e01493c5a83b45f04ed1d0219 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.9.165714 Subject: [Dtls-iot] CFP: IEEE Internet of Things Journal, SI on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:06:12 -0000 --089e01493c5a83b45f04ed1d0219 Content-Type: text/plain; charset=ISO-8859-1 Dear DICE Members, Please find below our call for paper for IEEE Internet of Things Journal Special Issue on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014). Online version is available under: < http://iot-journal.weebly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf>. We are looking forward for your submissions, and appreciate your further help in forwarding the CFP to your friends and colleagues. Thanks. Regards, Cong Wang # CALL FOR PAPERS # IEEE Internet of Things Journal Special Issue on Security for IoT: the State of the Art (deadline: Feb. 15th, 2014) A PDF version of this CFP can be downloaded at: < http://iot-journal.weebly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf > # Scope of Special Issue # The Internet is becoming more and more ubiquitous. One central element of this trend is the existence of a massive network of interconnected wired/wireless physical objects/things/sensors/devices, which can interact in a rich set of manners through a worldwide communication and information infrastructure and provide value added services. The vision of such an Internet of Things (IoT) system, supported by industrial companies and governments globally, has the potential to mark an evolution that will surely have a great impact on our environments and our lives. Yet, the realization of a ubiquitous IoT also poses a number of challenges where security is among the top concerns. The globally interconnected physical objects inevitably result in a potentially enormous attack surface that can be easily exploited if without adequate protection. To enable strong security foundations for the ubiquitous IoT, plenty of factors need to be taken into account. Examples are data security, privacy, access control, information assurance, trust management, secure services interoperability, seamless integration, system heterogeneity, scalability, and mobility. This special issue solicits high-quality original research results about IoT that pertain to state-of-the-art security and privacy issues in various pervasive and ubiquitous scenarios. We encourage submissions on theoretical, practical, as well as experimental studies, from both academia and industry, related to all aspects of security for IoT. Topics of interests include (but are not limited to) the following categories: - Secure IoT architecture - IoT access control and key management - Identification and privacy for IoT - Smart phone enabled secure smart systems - New cryptographic primitives for IoT - Manage trust for IoT service interoperability - Security on heterogeneous ecosystems - Context-aware security design - Data security and privacy in the IoT - Intrusion detection and defense for IoT - Joint security&privacy aware protocol design - Failure detection, prediction, and recovery - Secure data management within IoT - Trusted computing technology and IoT - Availability, recovery and auditing - IoT related web services security - Secure cyber-physical system - Biometrics for the IoT # Important Dates # - Submissions Deadline: February 15th, 2014 - First Reviews Due: May 15th, 2014 - Revision Due: June 15th, 2014 - Second Reviews Due/Acceptance letters: July 15th, 2014 - Final Manuscript Due: August 15th, 2014 - Publication Date: October 15th, 2014 # Submission Guidelines # The special issue seeks submission of papers that present novel original results and findings on Security for IoT. Solicited original submissions must not be currently under consideration for publication in other venues. Author guidelines and submission information can be found at < http://iot.ieee.org/journal>. All manuscripts should be submitted through Manuscript Central: # Guest Editors # - Kui Ren, University at Buffalo, SUNY - Pierangela Samarati, University of Milan - Peng Ning, NCSU, Raleigh & Samsung Mobile - Marco Gruteser, Rutgers University - Yunhao Liu, Tsinghua University SI Publicity Chair: Cong Wang, City University of Hong Kong < congwang@cityu.edu.hk> -- ~~~~~~~~~~~~~~~~~~~~~~ Cong WANG, PhD Assistant Professor Computer Science Department City University of Hong Kong Kowloon, Hong Kong Tel: +852 3442 2010; Fax: +852 3442 0503 Email: congwang@cityu.edu.hk URL: http://www.cs.cityu.edu.hk/~congwang/ ~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: This email (including any attachments) is for the use of the intended recipient only and may contain confidential information and/or copyright material. If you are not the intended recipient, please notify the sender immediately and delete this email and all copies from your system. Any unauthorized use, disclosure, reproduction, copying, distribution, or other form of unauthorized dissemination of the contents is expressly prohibited. --089e01493c5a83b45f04ed1d0219 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear DICE Members,=A0

Please find below our call f= or paper for IEEE Internet of Things Journal Special Issue on Security for = IoT: the State of the Art (deadline: Feb. 15th, 2014). Online version is av= ailable under: <http://iot-journal.weeb= ly.com/uploads/1/8/8/0/18809834/ieee_iot_journal_si_iot_security_cfp.pdf>. =A0

We are looking forward for your= submissions, and appreciate your further help in forwarding the CFP to you= r friends and colleagues. Thanks.=A0

Regards,=A0
Cong Wang




# Scope of Special Issue #
The Internet is becoming more and more ubiquitous. One central = element of this trend is the existence of a massive network of interconnect= ed wired/wireless physical objects/things/sensors/devices, which can intera= ct in a rich set of manners through a worldwide communication and informati= on infrastructure and provide value added services. The vision of such an I= nternet of Things (IoT) system, supported by industrial companies and gover= nments globally, has the potential to mark an evolution that will surely ha= ve a great impact on our environments and our lives. Yet, the realization o= f a ubiquitous IoT also poses a number of challenges where security is amon= g the top concerns. The globally interconnected physical objects inevitably= result in a potentially enormous attack surface that can be easily exploit= ed if without adequate protection. To enable strong security foundations fo= r the ubiquitous IoT, plenty of factors need to be taken into account. Exam= ples are data security, privacy, access control, information assurance, tru= st management, secure services interoperability, seamless integration, syst= em heterogeneity, scalability, and mobility. This special issue solicits hi= gh-quality original research results about IoT that pertain to state-of-the= -art security and privacy issues in various pervasive and ubiquitous scenar= ios. We encourage submissions on theoretical, practical, as well as experim= ental studies, from both academia and industry, related to all aspects of s= ecurity for IoT. Topics of interests include (but are not limited to) the f= ollowing categories:

- Secure IoT architecture
- IoT access contro= l and key management
- Identification and privacy for IoT
- Smart phone enabled secure smart systems
- New cryptographic= primitives for IoT
- Manage trust for IoT service interoperability
- Security o= n heterogeneous ecosystems
- Context-aware security design
<= div>- Data security and privacy in the IoT
- Intrusion detection = and defense for IoT=A0
- Joint security&privacy aware protocol design
- Failure= detection, prediction, and recovery=A0
- Secure data management = within IoT
- Trusted computing technology and IoT
- Ava= ilability, recovery and auditing
- IoT related web services security=A0
- Secure cyber-physic= al system
- Biometrics for the IoT


<= /div>
# Important Dates #=A0

- Submissions Dea= dline: February 15th, 2014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
- First Reviews Due: May 15th, 2014
- Revision Due: June 15t= h, 2014 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0
- Second Reviews Due/Acceptance lett= ers: July 15th, 2014=A0
- Final Manuscript Due: August 15th, 2014= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0
- Publication Date: October 15th, 2014=A0

# Submission Guidelines #

The special = issue seeks submission of papers that present novel original results and fi= ndings on Security for IoT. =A0Solicited original submissions must not be c= urrently under consideration for publication in other venues. Author guidel= ines and submission information can be found at <http://iot.ieee.org/journal>. All manuscripts shoul= d be submitted through Manuscript Central: <http://mc.manuscriptcentral.com/iot>=A0


# Guest Editors #=A0

- Kui Ren, University at Buffalo, SUNY <kuiren@buffalo.edu>=A0
- Pierangela Samarati, = University of Milan <pie= rangela.samarati@unimi.it>=A0
- Peng Ning, NCSU, Raleigh & Samsung Mobile <pning@ncsu.edu>=A0
- Marco Gruteser, Rutge= rs University <gruteser@w= inlab.rutgers.edu>=A0
- Yunhao Liu, Tsinghua University <yunhaoliu@gmail.com>=A0


SI Publicity Chair: Cong Wang, City University of Hong Kong <congwang@cityu.edu.hk>


--
~~~~~~~~~~~~~~~~~~~~~~
Cong W= ANG, PhD
Assistant Professor
Computer Science Department
City Univ= ersity of Hong Kong
Kowloon, Hong Kong
Tel: +852 3442 2010; Fax: +852= 3442 0503
Email: congwang@= cityu.edu.hk
URL: http://www.cs.cityu.edu.hk/~congwang/
~~~~~~~~~~~~= ~~~~~~~~~~

Disclaimer: This email (including any attachments) is for the use of the in= tended recipient only and may contain confidential information and/or copyr= ight material. If you are not the intended recipient, please notify the sen= der immediately and delete this email and all copies from your system. Any = unauthorized use, disclosure, reproduction, copying, distribution, or other= form of unauthorized dissemination of the contents is expressly prohibited= .


--089e01493c5a83b45f04ed1d0219-- From msj@nthpermutation.com Mon Dec 9 10:45:38 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AD31AE4A8 for ; Mon, 9 Dec 2013 10:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 wZQvy5ldBdT3 for ; Mon, 9 Dec 2013 10:45:35 -0800 (PST) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 61D451AE4A6 for ; Mon, 9 Dec 2013 10:45:35 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id ne12so3108232qeb.39 for ; Mon, 09 Dec 2013 10:45:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DJmvt9mmkhWu6xiM4dWN+3eQfFlLJYkKaXbWGFWM0H4=; b=IYnMV3K1RGZHitLv4L/PFGmeF6dQZtE1TPWBRnrJpUsBL7h/txrZF8eXGFut+Q6jrV kF99e8SwDQtRUcAPWS90ezYcpeZzKw5f0kaJ/Y9u57WXN2DqiMqzVhz0p2XTjrGmzv6E ypev5DpnaoMMi10fH3fHp4ba84P/spx6XBoNAPvDxtxOxjQ4kTqLNKlLfoM+1Xb/PPVH DSVhr32LGtIicrJ23KGQ3jU77QkLktxeuG92Z8WE3/lqUUZu4ms0FKjwi/mkWCboRrCc uZE051Sm+Uv5+lSdH1f8GKsUEhikzAFsNurGUrldaV0Kq+0e1gVDnWbndZ74uZ/FEHYq 9lAw== X-Gm-Message-State: ALoCoQlmo0rHEWaqF/XLcw6jeE3tlHDN/GWgyY9Mxpn2hzFnVFljXQtwaQBU8K4mI90yy1Lxmg1M X-Received: by 10.224.22.75 with SMTP id m11mr37568454qab.27.1386614730124; Mon, 09 Dec 2013 10:45:30 -0800 (PST) Received: from [192.168.1.112] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id p20sm34841017qay.0.2013.12.09.10.45.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 10:45:28 -0800 (PST) Message-ID: <52A60FC8.6080408@nthpermutation.com> Date: Mon, 09 Dec 2013 13:45:28 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Kumar, Sandeep" , "dtls-iot@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dtls-iot] Comments on draft-keoh-dice-multicast-security-01 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:45:38 -0000 Sorry for the delay in responding - holidays and other things intruded. On 11/20/2013 10:22 AM, Kumar, Sandeep wrote: > Dear Mike > > Thanks again for the detailed comments. See reply below > >> -----Original Message----- >> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael >> StJohns >> Sent: Tuesday, November 19, 2013 1:35 AM >> To: dtls-iot@ietf.org >> Subject: [Dtls-iot] Comments on draft-keoh-dice-multicast-security-01 >> >> This is mostly a recap of comments I made at the mike in the DICE >> meeting at the last IETF. >> >> There's always some confusion about what exactly is meant by multicast >> and whether it's necessary for any given application. >> For the purposes of this document, I'm assuming multicast is a L3 >> store and forward of IPv6 packets from neighbor to neighbor and that >> there is no required dependence on L2 broadcast. > [SK] You are right about this and we did explain is section 3.1 that it is based on IPv6 multicast. Since we intend to secure the CoAP group communication, more details of how the group communication works is referenced to I-D.ietf-core-groupcomm. We can make it more clear in the next version. >> In general, multicast is an attractive nuisance. Attractive, >> because it allows for a single transmitted message to be sent to many >> recipients without any special programming on the part of the sender. >> A nuisance because we don't actually understand the security >> limitations of multicast and unfortunately, this document doesn't advance that understanding. >> >> Multicast is useful as an information dissemination tool, IFF that >> information can be separately validated (e.g. application layer public >> key signatures or some other method). It *may* be useful as a tool >> for a control protocol, but symmetric key multicast security at the >> L3/L4 layer should NEVER be considered strong enough for >> cyber-physical systems that may have a health and welfare affect (e.g. >> power grid, medical, SCADA, automobile traffic management >> etc.). > [SK] Value your opinion. There are indeed stronger multicast security protocols defined at the IP layer and if devices have the resources, we would recommend using them. The current draft is for the constrained devices which already have DTLS for unicast (which is mandatory for CoAP) but does not have additional resources to implement yet another security protocol to secure the multicast communication. This is more to avoid that the multicast is left unsecured in such scenarios. I'm not convinced this is a viable approach for various reasons. First figure out *exactly* what your multicast applications are, figure out if they are control applications or information applications, etc. Then figure out how to secure the application. Don't just throw in multicast DTLS because you don't want to implement yet another security protocol. If the devices are too small for another protocol, then don't expect them to play in multicast either. >> Specific comments on the document: >> >> 1) The selection of the group key negotiation protocol. Over the >> years, there have been at least 3 of these submitted to the IETF. Two >> of them (including the one cited in this draft) are Informational. The other is standards track. >> There's no discussion of why RFC3740 was selected over >> RFC4535 GSAKMP. Ideally, there should be a group key management >> requirements document first before the group adopts an implementation >> proposal. > [SK] We do *not* recommend or select any specific key negotiation protocol in the draft. Section 2.2 (i) reads as if you're suggesting building on 3740 and 4046 - as if that path has already been decided. > The key management was unfortunately kept out of scope of the DICE charter. Indeed it would be ideal to reuse what IETF has already standardized if it fits the requirements. I agree we need to create a requirements document for the KMP before any implementation proposal for KMP. For the present draft, the keys are assumed to be on the devices out-of-band which needs to be replaced with the appropriate KMP. We will remove the existing small discussion on the KMP in the present draft in the new version to avoid any confusion of the present scope of the draft. > [SK] The discussion on KMP comes up again every so often and we think an extension of the scope of DICE is needed here. This probably requires a different discussion thread. Before we start getting to key management, let's ensure that multicast is actually required to meet the application needs. Given that most of what you're talking about is L3 store and forward multicast, then its unclear why the link layer keys between neighbors isn't sufficient security and why a multicast specific security mechanism is required. At the most (maybe useful for efficiency) having a sending node share a common key with each of its neighbors for any "multicast" packet it sends may be a reasonable tweak. >> 2) The key material should be bound to sender IP and port, not just sender. >> There's no requirement that a multicast group serve only a single >> application and you need a way of differentiating key material for multiple applications. >> > [SK] Agree for unicast. For multicast it should be bound to the destination IP and port. We will add the port which is missing now. Actually, why not bind it to source/destination address/port like all other security mechanisms? > >> 3) The security section needs to include a discussion about the perils >> of common or group keying with respect to integrity, origin >> authentication and participant compromise. The security section as written is a throw-away. >> Specifically, symmetric key protected multicast provides no origin >> authentication and the compromise of a single node compromises the >> entire protections of a multicast tree. If the tree is small enough - >> e.g. something like a single house with a common physical perimeter >> and common security domain - this is manageable. For something like >> an IOT of 10K or larger items, probably not manageable. > [SK] Agree, the security section needs more organization. Origin authentication issue and object based security solution has been already mentioned in the draft but we can make it more explicit in the security considerations section. >> 4) It's unclear that DTLS (or more specifically DTLS packet formats) >> are the proper fit for a secured multicast. I understand why this >> might be an attractive approach (e.g. not having to actually design >> the formats, reuse of code), but a poor fit is worse that doing it at >> all. As I noted during the discussion, at the very least, the >> assigned 16 bit ID imposes a number of limitations. > [ > [SK] The 16-bit provide for about 2^(16) unique senders (not members, they can be even larger) in a single multicast group. This is quite large for all use cases of number of devices sending in a single multicast group that require this security solution. We can make the scenarios more clear to make the choice of 2 byte Sender ID more clearer. That's one example, but not what I actually meant. DTLS has its own set of assumptions in its design and those assumptions do not necessarily stretch to cover multicast. Given that DTLS was pretty much crafted out of TLS which was definitely a two party protocol, its unclear DTLS should even be the starting point for a multicast based solution. Its probably overly optimistic to declare DTLS as the starting point and not expect substantial restructuring to actually accomplish the multicast goals. >> 5) During the session, the author cited David McGrew's AERO proposal. >> That proposal has some interesting properties, but also has >> significant limitations. Before going down that path, it would be >> better to understand the actual scope needed for a secure multicast >> design (if indeed it is actually >> needed) for the IOT. E.g. common or non-common security domain? Size >> of multicast group? Scope of the multicast group? Sparse or dense multicast? >> Can each hop be re-keyed (e.g. nodes only share keys with neighbors >> rather than all nodes in a multicast tree sharing a key). > [SK] The AERO proposal was more an open question to the WG since it was suggested in the review by John Foley. The final impression I got during the meeting is that there is a strong need to keep the solution flexible, independent of any single crypto suite, due to different regulations in different countries. > > [SK] Regarding the scope of the draft, a better description of the use cases and scenario in the next version should clarify the design decisions. Ideally, the next draft should not mention DTLS at all and instead focus on "Multicast requirements for IOT devices in small (5-50), medium (50-500) and large (500+) clusters" Just a thought - Mike >> >> >> Mike >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot > ________________________________ > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > From gerdes@tzi.de Wed Dec 11 05:49:07 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17641ADE7C; Wed, 11 Dec 2013 05:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] 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 SZ-07BSEa9s7; Wed, 11 Dec 2013 05:49:05 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 364A81ADDDA; Wed, 11 Dec 2013 05:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id rBBDksGc018161; Wed, 11 Dec 2013 14:46:55 +0100 (CET) Received: from [134.102.218.230] (dynamic-218-c.informatik.uni-bremen.de [134.102.218.230]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 7D110C4B; Wed, 11 Dec 2013 14:46:54 +0100 (CET) Message-ID: <52A86CCE.3090906@tzi.de> Date: Wed, 11 Dec 2013 14:46:54 +0100 From: Stefanie Gerdes User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "core@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: [Dtls-iot] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 13:49:08 -0000 Hi everybody, As a result of discussions in the CoRE WG in Berlin and Vancouver the new non-WG mailing list Authentication and Authorization for Constrained Environments (ace) was created. The purpose of this list is to organize interest in a group to define the charter for work on Authentication and Authorization for Constrained Environments. Our mailing list can be found at (1), existing work can be found at (2), and the draft charter can be found at (3). Please feel welcome to join the list and provide your feedback! Thanks, Kind Regards Kepeng & Stefanie (1)Mailing List https://www.ietf.org/mailman/listinfo/ace (2)Existing work: Use Cases: http://tools.ietf.org/id/draft-garcia-core-security http://tools.ietf.org/id/draft-greevenbosch-core-authreq http://tools.ietf.org/id/draft-seitz-core-sec-usecases Solutions http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration http://tools.ietf.org/id/draft-selander-core-access-control http://tools.ietf.org/id/draft-zhu-core-groupauth http://tools.ietf.org/id/draft-pporamba-dtls-certkey http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot http://tools.ietf.org/id/draft-seitz-core-security-modes (3)Draft Charter - Authentication and Authorization for Constrained Environment (ACE) The CoAP (Constrained Application Protocol) is a light-weight application layer protocol, especially suitable for applications such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of these applications, including a critical, unattended infrastructure and usage in the personal sphere, security and privacy protection are critical components. Currently, a problem with constrained devices is the realization of such secure communication. The devices only have limited resources such as memory, storage and transmission capacity. These constraints severely limit the security functions and communications the device can perform. Missing functionality includes authentication, which provides trust and ensures an entity is who it says it is, and authorization, which defines and enforces access rights for different clients. The ACE WG focuses on providing constrained devices with the necessary prerequisites to use REST operations in a secure way. Constrained devices will thus be enabled to authenticate communications from other (constrained or less-constrained) devices, to communicate securely with them and to verify their individual authorization to access specific resources. To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. The ACE WG has the following tasks: - Document the use cases and high-level requirements for secured communication between constrained devices. - Define certificate profiling (what kinds of certificates and which attributes are to be used). - Define a mechanism for authenticated and protected transfer of authorization information suitable for constrained device to constrained device communication. - Define an access ticket and authorization information format suitable for constrained devices. - Define bootstrapping for authorization information using the Resource Directory. From rstruik.ext@gmail.com Wed Dec 11 06:45:24 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8D1ADF81; Wed, 11 Dec 2013 06:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] 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 SdY_MpxXnw2h; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 581201ADF80; Wed, 11 Dec 2013 06:45:21 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id hk11so847716igb.0 for ; Wed, 11 Dec 2013 06:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=scWuz0UoFiPFuRINImNeTz68NxM7A/ZPXBXnVRbrz58=; b=ajoarEEUcuuSlhu4jc+Lmw7INGKir3YpySyrYDOd8no2qdbpDsLvPfvufjn+aILQm3 bfw/oVgUTzA9sp6u/plb//bwp0z97PMV5rqoEkxKJwVk7b6BvM1xNWhWzPlWOTlv8VvB jIULTafdkyroeMHxaGdbLkn9LjabYToAxK2t4t1bjGzod64ADaOvgOSQDvSeO8OMqKx7 YJyK4s0jUjdBfeE0giwEiapC2Y8DkLmxyXl/b2dWoSZDCcfD07XUd3ouj3Qd+aQsa97f c2acJiQmuW7reKDChnFPjoqsKeI7PHV6HMcjJ/DT2LgPFl6wnp+2VMp/YaPlxQpveDNN tXJA== X-Received: by 10.42.208.211 with SMTP id gd19mr1165897icb.15.1386773115664; Wed, 11 Dec 2013 06:45:15 -0800 (PST) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id k6sm9308420igx.8.2013.12.11.06.45.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 06:45:14 -0800 (PST) Message-ID: <52A87A6F.8030304@gmail.com> Date: Wed, 11 Dec 2013 09:45:03 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefanie Gerdes , "core@ietf.org" References: <52A86CCE.3090906@tzi.de> In-Reply-To: <52A86CCE.3090906@tzi.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org, dtls-iot@ietf.org, jose@ietf.org, oauth@ietf.org Subject: Re: [Dtls-iot] Invitation to New Non-WG Mailing List: Authentication and Authorization for Constrained Environments (ace) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 14:45:24 -0000 [apologies for replying to all the IETF lists in the original cc] Dear colleagues: I have some initial feedback on the potential draft charter. I believe it is really premature to write potential point solutions into = a draft charter, in casu definition of a less constrained device that can= be used to outsource computational, storage, or management functionality= to. (Does this imply one envisions to have to buy a separate box/single = point of failure to take on this task?) It would make much more sense to = look into this problem space in terms of requirements first, with an eye = towards scalability towards billion+ devices. This does not preclude this= potential solution direction, but questions as to what this entails in t= erms of usability, scalability, and communications impact need to be clea= r first. This is an ambitious undertaking and many efforts in the past ha= ve been far less successful than initially thought. There is also an unde= rcurrent in the draft charter text that there is a need for different "de= vice types", which is not a priori clear. To realize the full potential o= f constrained networks, one should reflect upon "trust" endowed upon sing= le nodes, of whatever type, and consider limiting the impact of violation= of this trust, should this occur, as an explicit design criterium. In the end, this may be an undertaking that would be suitable as an IAB w= ork item, considering potential scope. Best regards, Rene =3D=3D To achieve this, ACE will be able to employ an architecture with one or more trusted less-constrained devices which will relieve the constrained nodes from complex security related tasks (e.g. managing authorization policies and a large number of keys). ACE will use CoAP and employ security properties of DTLS whenever possible. On 12/11/2013 8:46 AM, Stefanie Gerdes wrote: > Hi everybody, > > As a result of discussions in the CoRE WG in Berlin and Vancouver the > new non-WG mailing list Authentication and Authorization for Constraine= d > Environments (ace) was created. > > The purpose of this list is to organize interest in a group to define > the charter for work on Authentication and Authorization for Constraine= d > Environments. > > Our mailing list can be found at (1), existing work can be found at (2)= , > and the draft charter can be found at (3). > > Please feel welcome to join the list and provide your feedback! > > Thanks, > > Kind Regards > Kepeng & Stefanie > > > (1)Mailing List > > https://www.ietf.org/mailman/listinfo/ace > > (2)Existing work: > > Use Cases: > http://tools.ietf.org/id/draft-garcia-core-security > http://tools.ietf.org/id/draft-greevenbosch-core-authreq > http://tools.ietf.org/id/draft-seitz-core-sec-usecases > > Solutions > http://tools.ietf.org/id/draft-gerdes-core-dcaf-authorize > http://tools.ietf.org/id/draft-kang-core-secure-reconfiguration > http://tools.ietf.org/id/draft-selander-core-access-control > http://tools.ietf.org/id/draft-zhu-core-groupauth > http://tools.ietf.org/id/draft-pporamba-dtls-certkey > http://tools.ietf.org/id/draft-schmitt-two-way-authentication-for-iot > http://tools.ietf.org/id/draft-seitz-core-security-modes > > (3)Draft Charter - Authentication and Authorization for Constrained > Environment (ACE) > > The CoAP (Constrained Application Protocol) is a light-weight > application layer protocol, especially suitable for applications such a= s > smart energy, smart home, building automation, remote patient monitorin= g > etc. Due to the nature of these applications, including a critical, > unattended infrastructure and usage in the personal sphere, security an= d > privacy protection are critical components. > > Currently, a problem with constrained devices is the realization of suc= h > secure communication. The devices only have limited resources such as > memory, storage and transmission capacity. These constraints severely > limit the security functions and communications the device can perform.= > Missing functionality includes authentication, which provides trust and= > ensures an entity is who it says it is, and authorization, which define= s > and enforces access rights for different clients. > > The ACE WG focuses on providing constrained devices with the necessary > prerequisites to use REST operations in a secure way. Constrained > devices will thus be enabled to authenticate communications from other > (constrained or less-constrained) devices, to communicate securely with= > them and to verify their individual authorization to access specific > resources. To achieve this, ACE will be able to employ an architecture > with one or more trusted less-constrained devices which will relieve th= e > constrained nodes from complex security related tasks (e.g. managing > authorization policies and a large number of keys). ACE will use CoAP > and employ security properties of DTLS whenever possible. > > The ACE WG has the following tasks: > - Document the use cases and high-level requirements for secured > communication between constrained devices. > - Define certificate profiling (what kinds of certificates and which > attributes are to be used). > - Define a mechanism for authenticated and protected transfer of > authorization information suitable for constrained device to constraine= d > device communication. > - Define an access ticket and authorization information format suitable= > for constrained devices. > - Define bootstrapping for authorization information using the Resource= > Directory. --=20 email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From stokcons@xs4all.nl Mon Dec 16 00:43:54 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24301AE1B0 for ; Mon, 16 Dec 2013 00:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538] autolearn=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 c1DQ0K86gczj for ; Mon, 16 Dec 2013 00:43:53 -0800 (PST) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by ietfa.amsl.com (Postfix) with ESMTP id B9A9B1AE19D for ; Mon, 16 Dec 2013 00:43:52 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube9.xs4all.net [194.109.20.207]) by smtp-vbr4.xs4all.nl (8.13.8/8.13.8) with ESMTP id rBG8hogd070936 for ; Mon, 16 Dec 2013 09:43:51 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 16 Dec 2013 09:43:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 2013 09:43:50 +0100 From: peter van der Stok To: dtls-iot@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org In-Reply-To: <52A60FC8.6080408@nthpermutation.com> References: <52A60FC8.6080408@nthpermutation.com> Message-ID: <0e9374360523b28dd80c52d41d13d25c@xs4all.nl> X-Sender: stokcons@xs4all.nl (bAqpdC1argLAHXvFJbdzActbC/CP4tnr) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Dtls-iot] Comments on draft-keoh-dice-multicast-security-01 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 08:43:55 -0000 Hi Mike, Just a small answer to the questions you ask about the necessity for multicast. In the Roll working group I submitted the expired draft draft-vanderstok-roll-mcreq-02. Also you find some motivation in the ietf-core-groupcomm draft. In short: multicast is needed by a sensor or switch to send commands over a wireless network to a group of nodes (lights for our purposes) Multicast source and MC destinations often are within the same wireless network. The end to end delay should be less than 250 ms. The source may be outside the wireless network and the request passes the border router before being distributed to all sources. Doing the multicast with a set of unicasts is not workable (takes too long, takes too many resources). With the right parameter settings MPL seems to do the job in networks where the number of hops is limited to 10. We intend to use CoAP/UDP for transport of the Multicast message. CoAP brings along the use of DTLS. Other multicast requirements come from the use of mDNS (but the time constraints and security constraints are different). Does this answer some of your concerns? Greetings, peter > I'm not convinced this is a viable approach for various reasons. First > figure out *exactly* what your multicast applications are, figure out > if they are control applications or information applications, etc. > Then figure out how to secure the application. Don't just throw in > multicast DTLS because you don't want to implement yet another > security protocol. If the devices are too small for another protocol, > then don't expect them to play in multicast either. > > Before we start getting to key management, let's ensure that multicast > is actually required to meet the application needs. Given that most > of what you're talking about is L3 store and forward multicast, then > its unclear why the link layer keys between neighbors isn't sufficient > security and why a multicast specific security mechanism is required. > At the most (maybe useful for efficiency) having a sending node share > a common key with each of its neighbors for any "multicast" packet it > sends may be a reasonable tweak. > > Ideally, the next draft should not mention DTLS at all and instead > focus on "Multicast requirements for IOT devices in small (5-50), > medium (50-500) and large (500+) clusters" > > Just a thought - > > Mike From mglt.ietf@gmail.com Tue Dec 17 12:42:31 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6001A1F3F for ; Tue, 17 Dec 2013 12:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Ze0xFI5zYZHC for ; Tue, 17 Dec 2013 12:42:30 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3924C1A1F19 for ; Tue, 17 Dec 2013 12:42:30 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w61so6716055wes.0 for ; Tue, 17 Dec 2013 12:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zaKrt0ZWg8TnpPInhsdlG4ZBMpNfLXTCTfURS8qBLoU=; b=smx0ThIW4GUu0X12Y8PCTxSiX4BIxVbwgyye7jm6Dfk//BVQnDyEP+Y985JT3QnA3u YseHa/ewIPOheiY1C+Oy6fxdnZC3XlzVZni/VIIfZEZVr28lRuHX2Y0j8i3T7n9t8fet O3khuH6tcZ1sHh99+d6FnSaFNLxZwueQDfPqyDxP1TveDThlGFlxpwoGYS+OkcFNOoKZ yVMN7KoFAve7SNtBzVyj4CxJSCxhnwLVA2WUnjhtupPF6vLVJieO70AcgZKc4mSY3efX csU6xPIOzQr3YbO0X4rHPieC9CJla8xm+07Kty1tNL6JjwT+DrsTXU3lQK/tV5iGZkPa phWw== MIME-Version: 1.0 X-Received: by 10.195.13.234 with SMTP id fb10mr21021509wjd.50.1387312948491; Tue, 17 Dec 2013 12:42:28 -0800 (PST) Received: by 10.194.41.138 with HTTP; Tue, 17 Dec 2013 12:42:28 -0800 (PST) Date: Tue, 17 Dec 2013 21:42:28 +0100 Message-ID: From: Daniel Migault To: dtls-iot@ietf.org Content-Type: multipart/alternative; boundary=047d7bb03afc7cbaf604edc0f79c Subject: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 20:42:31 -0000 --047d7bb03afc7cbaf604edc0f79c Content-Type: text/plain; charset=ISO-8859-1 Hi, Regular data structure in kernel (at least Linux) need a 32 bit alignment. As a result IPsec/ESP packet must be padded for example. UDP for example is 32 + 32 bits and transport header of 8, 16, 24, 40 bits could hardly be handled by kernels. Is there any requirements for IoT? If there is not be such requirements, then for IPsec/ESP this would mean, for example, that we could remove the padding. For UDP we could possibly compress it to a single byte. Just to clarify, we took the example of UDP to illustrate our question on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP. BR, Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bb03afc7cbaf604edc0f79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Regular data st= ructure in kernel (at least Linux) need a 32 bit alignment. As a result IPs= ec/ESP packet must be padded for example. UDP for example is 32 + 32 bits a= nd transport header of 8, 16, 24, 40=A0 bits could hardly be handled by ker= nels.

Is there any requirements for IoT?

If there is not = be such requirements, then for IPsec/ESP this would mean, for example, that= we could remove the padding.=A0 For UDP we could possibly compress it to a= single byte.

Just to clarify, we took the example of UDP to illustrate our que= stion on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP.=

BR,
Daniel




--
Daniel Migault
Orange= Labs -- Security
+33 6 70 72 69 58
--047d7bb03afc7cbaf604edc0f79c-- From hauke@hauke-m.de Tue Dec 17 13:38:50 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8041A1F7B for ; Tue, 17 Dec 2013 13:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 jkgGYp-2_eqA for ; Tue, 17 Dec 2013 13:38:49 -0800 (PST) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3402E1A1F48 for ; Tue, 17 Dec 2013 13:38:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 1AC2485EA; Tue, 17 Dec 2013 22:38:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFqnblLo2JxM; Tue, 17 Dec 2013 22:38:02 +0100 (CET) Received: from [IPv6:2001:470:1f0b:447:306f:8e3b:4500:93c5] (unknown [IPv6:2001:470:1f0b:447:306f:8e3b:4500:93c5]) by hauke-m.de (Postfix) with ESMTPSA id 60894857F; Tue, 17 Dec 2013 22:37:59 +0100 (CET) Message-ID: <52B0C42D.7040505@hauke-m.de> Date: Tue, 17 Dec 2013 22:37:49 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Daniel Migault , dtls-iot@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 21:38:51 -0000 On 12/17/2013 09:42 PM, Daniel Migault wrote: > Hi, > > Regular data structure in kernel (at least Linux) need a 32 bit > alignment. As a result IPsec/ESP packet must be padded for example. UDP > for example is 32 + 32 bits and transport header of 8, 16, 24, 40 bits > could hardly be handled by kernels. Alignments is not a problem of the kernel, but it is used to circumvent a restriction by some processors. Some 32 Bit processors have problems or are unable to read or write bytes at an offset which is not aligned by 4 bytes (address % 4 != 0). Normally your compiler takes care of that stuff and adds padding bytes to your c structs when needed. When the Linux kernel does an unaligned access on a MIPS CPU the CPU will send a exception to the kernel handler and this unaligned read will be emulated in software, which is way slower then an aligned read done by the CPU. The GCC for the MSP430 (16 Bit CPU) for example adds a 2 byte alignment to all data structures and extends the size to a 2 byte alignment as well by default. You should probably read this: http://en.wikipedia.org/wiki/Data_structure_alignment A UDP Package is nicely aligned when it starts at an aligned address, but when there is an aligned Ethernet frame header in front, which is 14 or 18 bytes long, then it is not aligned at an 4 bytes boundary any more, this is probably the problem your are talking about. > Is there any requirements for IoT? You could have the same problems in IoT, it depens on your processor. > If there is not be such requirements, then for IPsec/ESP this would > mean, for example, that we could remove the padding. For UDP we could > possibly compress it to a single byte. > > Just to clarify, we took the example of UDP to illustrate our question > on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP. > > BR, > Daniel From mglt.ietf@gmail.com Tue Dec 17 13:53:50 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5970B1AC4C1 for ; Tue, 17 Dec 2013 13:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 m0xauRGC5WB3 for ; Tue, 17 Dec 2013 13:53:48 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD381AC4A3 for ; Tue, 17 Dec 2013 13:53:48 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so6800474wgh.32 for ; Tue, 17 Dec 2013 13:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QKvbUiK1sLMpRFpyvq90QrWu1ioLhhUoenP7Ur2DNr4=; b=Tth7umBbRSAP8X0v/hQoyd/GYBp6BRMOqXgTUewI8olZC9VyJsrBfYUqnSSdxa1Rzc ZITy3SYMSCVG4JpkGltaEFxXquKStWg6E1jUazT8g9x0YL57r+Dv+d5pzhDqBMnPN+gZ qDO4rDuRQdIH94s6j/lM7ysmMqAqY452736HNv1WmeuruFl9kvLf4PT0UuyhtDDjF4FL 1hMqJYGK5BHJkIPS8VtCTzRnCvCeo5hL+SKf5V7YxFDkqjv2Xp2ubPxrROrK86VAqgjc 9Bbwwn6XhMhZLRXyS7+6EbobUfp6GgOircTZj36LokyYQzYnUPv3raXeTdfjeLhfv9wy G50Q== MIME-Version: 1.0 X-Received: by 10.194.57.243 with SMTP id l19mr14627649wjq.54.1387317226640; Tue, 17 Dec 2013 13:53:46 -0800 (PST) Received: by 10.194.41.138 with HTTP; Tue, 17 Dec 2013 13:53:46 -0800 (PST) In-Reply-To: <52B0C42D.7040505@hauke-m.de> References: <52B0C42D.7040505@hauke-m.de> Date: Tue, 17 Dec 2013 22:53:46 +0100 Message-ID: From: Daniel Migault To: Hauke Mehrtens Content-Type: multipart/alternative; boundary=047d7b8736a07c1bd704edc1f6a0 Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 21:53:50 -0000 --047d7b8736a07c1bd704edc1f6a0 Content-Type: text/plain; charset=ISO-8859-1 thanks a lot, that is the problem we were talking about. BR Daniel On Tue, Dec 17, 2013 at 10:37 PM, Hauke Mehrtens wrote: > On 12/17/2013 09:42 PM, Daniel Migault wrote: > > Hi, > > > > Regular data structure in kernel (at least Linux) need a 32 bit > > alignment. As a result IPsec/ESP packet must be padded for example. UDP > > for example is 32 + 32 bits and transport header of 8, 16, 24, 40 bits > > could hardly be handled by kernels. > > Alignments is not a problem of the kernel, but it is used to circumvent > a restriction by some processors. Some 32 Bit processors have problems > or are unable to read or write bytes at an offset which is not aligned > by 4 bytes (address % 4 != 0). Normally your compiler takes care of that > stuff and adds padding bytes to your c structs when needed. > > When the Linux kernel does an unaligned access on a MIPS CPU the CPU > will send a exception to the kernel handler and this unaligned read will > be emulated in software, which is way slower then an aligned read done > by the CPU. > > The GCC for the MSP430 (16 Bit CPU) for example adds a 2 byte alignment > to all data structures and extends the size to a 2 byte alignment as > well by default. > > You should probably read this: > http://en.wikipedia.org/wiki/Data_structure_alignment > > A UDP Package is nicely aligned when it starts at an aligned address, > but when there is an aligned Ethernet frame header in front, which is 14 > or 18 bytes long, then it is not aligned at an 4 bytes boundary any > more, this is probably the problem your are talking about. > > > Is there any requirements for IoT? > > You could have the same problems in IoT, it depens on your processor. > > > If there is not be such requirements, then for IPsec/ESP this would > > mean, for example, that we could remove the padding. For UDP we could > > possibly compress it to a single byte. > > > > Just to clarify, we took the example of UDP to illustrate our question > > on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP. > > > > BR, > > Daniel > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b8736a07c1bd704edc1f6a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
thanks a lot, that is the problem we were talking abo= ut.
BR
Daniel


On Tue, Dec 17, 2013 at 10:37 PM, Hauke Mehrtens <hau= ke@hauke-m.de> wrote:
On 12/17/2013 09:42 PM, Da= niel Migault wrote:
> Hi,
>
> Regular data structure in kernel (at least Linux) need a 32 bit
> alignment. As a result IPsec/ESP packet must be padded for example. UD= P
> for example is 32 + 32 bits and transport header of 8, 16, 24, 40 =A0b= its
> could hardly be handled by kernels.

Alignments is not a problem of the kernel, but it is used to circumve= nt
a restriction by some processors. Some 32 Bit processors have problems
or are unable to read or write bytes at an offset which is not aligned
by 4 bytes (address % 4 !=3D 0). Normally your compiler takes care of that<= br> stuff and adds padding bytes to your c structs when needed.

When the Linux kernel does an unaligned access on a MIPS CPU the CPU
will send a exception to the kernel handler and this unaligned read will be emulated in software, which is way slower then an aligned read done
by the CPU.

The GCC for the MSP430 (16 Bit CPU) for example adds a 2 byte alignment
to all data structures and extends the size to a 2 byte alignment as
well by default.

You should probably read this:
http://en.wikipedia.org/wiki/Data_structure_alignment

A UDP Package is nicely aligned when it starts at an aligned address,
but when there is an aligned Ethernet frame header in front, which is 14 or 18 bytes long, then it is not aligned at an 4 bytes boundary any
more, this is probably the problem your are talking about.

> Is there any requirements for IoT?

You could have the same problems in IoT, it depens on your processor.=

> If there is not be such requirements, then for IPsec/ESP this would > mean, for example, that we could remove the padding. =A0For UDP we cou= ld
> possibly compress it to a single byte.
>
> Just to clarify, we took the example of UDP to illustrate our question=
> on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP.<= br> >
> BR,
> Daniel




--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--047d7b8736a07c1bd704edc1f6a0-- From robert.cragie@gridmerge.com Wed Dec 18 01:38:57 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97511AE0CB for ; Wed, 18 Dec 2013 01:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 5pcpncr2INgc for ; Wed, 18 Dec 2013 01:38:55 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC1F1AE0A3 for ; Wed, 18 Dec 2013 01:38:55 -0800 (PST) Received: from [94.116.124.44] (helo=[10.38.243.201]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1VtDae-00019Q-FO for dtls-iot@ietf.org; Wed, 18 Dec 2013 09:38:52 +0000 Message-ID: <52B16D2D.1060608@gridmerge.com> Date: Wed, 18 Dec 2013 09:38:53 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <52B0C42D.7040505@hauke-m.de> In-Reply-To: <52B0C42D.7040505@hauke-m.de> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000600080907040406010604" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 09:38:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000600080907040406010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I don't think that is quite right. The issue I have come across is some=20 32-bit processors have problems reading or writing 16, 32 or 64-bit=20 values which are not aligned accordingly, i.e. address & 1 !=3D 0, addres= s=20 & 3 !=3D 0 and address & 7 !=3D 0 respectively and generate an address er= ror=20 exception. This is the reason a compiler adds padding bytes. Any=20 processor should be able to read an 8-bit value at any location and=20 therefore packed structures can be used safely if accesses are done on a = byte-by-byte basis, although this is inefficient of course. Robert On 17/12/2013 21:37, Hauke Mehrtens wrote: > On 12/17/2013 09:42 PM, Daniel Migault wrote: >> Hi, >> >> Regular data structure in kernel (at least Linux) need a 32 bit >> alignment. As a result IPsec/ESP packet must be padded for example. UD= P >> for example is 32 + 32 bits and transport header of 8, 16, 24, 40 bit= s >> could hardly be handled by kernels. > Alignments is not a problem of the kernel, but it is used to circumvent= > a restriction by some processors. Some 32 Bit processors have problems > or are unable to read or write bytes at an offset which is not aligned > by 4 bytes (address % 4 !=3D 0). Normally your compiler takes care of t= hat > stuff and adds padding bytes to your c structs when needed. > > When the Linux kernel does an unaligned access on a MIPS CPU the CPU > will send a exception to the kernel handler and this unaligned read wil= l > be emulated in software, which is way slower then an aligned read done > by the CPU. > > The GCC for the MSP430 (16 Bit CPU) for example adds a 2 byte alignment= > to all data structures and extends the size to a 2 byte alignment as > well by default. > > You should probably read this: > http://en.wikipedia.org/wiki/Data_structure_alignment > > A UDP Package is nicely aligned when it starts at an aligned address, > but when there is an aligned Ethernet frame header in front, which is 1= 4 > or 18 bytes long, then it is not aligned at an 4 bytes boundary any > more, this is probably the problem your are talking about. > >> Is there any requirements for IoT? > You could have the same problems in IoT, it depens on your processor. > >> If there is not be such requirements, then for IPsec/ESP this would >> mean, for example, that we could remove the padding. For UDP we could= >> possibly compress it to a single byte. >> >> Just to clarify, we took the example of UDP to illustrate our question= >> on 32 bit alignement. We do not work on UDP, but rather on IPsec/ESP. >> >> BR, >> Daniel > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > --------------ms000600080907040406010604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzEyMTgwOTM4NTNaMCMGCSqGSIb3DQEJBDEWBBREpJqjmkt3StGFJ5gVdaq+KdT+aDBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAJ6070gO773uIDcEZGaRs0+bIvqqdKkIPoAUNpUTAH1ZESl+ wyz9NM1UuCtA/CpCVS7wj9t3BhIN9i5WlBjUy1XVQosI4I1W4eLnTRONxFio220SykN1Hwgr kD2amAeAtx3yCs6BM5Lpc07dcdmMAWiRsdw40luNW/fp6t3GZEntDcUPXC4YJmMRoxGK7f/E oPcG4XWLCw1S0QLAuYltGRrj5EXRtHkXeS0F2OqRU6gZ+o6yMkqcSzdVIob/Ixdbra6aOiOv +kRp5HHrR98suS7ko4a6RTh6ZL8H8dlgasnMIxjb+k/6soec26ic831xTLfJe+oGqfxbYyF8 MYMTWVoAAAAAAAA= --------------ms000600080907040406010604-- From hauke@hauke-m.de Wed Dec 18 03:55:13 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0330F1AE373 for ; Wed, 18 Dec 2013 03:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311] autolearn=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 le31MB1uxSpk for ; Wed, 18 Dec 2013 03:55:11 -0800 (PST) Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id A8D091AE393 for ; Wed, 18 Dec 2013 03:55:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 397F28F62; Wed, 18 Dec 2013 12:55:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OELcPpYP0hFs; Wed, 18 Dec 2013 12:54:59 +0100 (CET) Received: from [IPv6:2001:638:708:30da:6981:7d63:73e:e739] (unknown [IPv6:2001:638:708:30da:6981:7d63:73e:e739]) by hauke-m.de (Postfix) with ESMTPSA id 8F165857F; Wed, 18 Dec 2013 12:54:59 +0100 (CET) Message-ID: <52B18D11.5010003@hauke-m.de> Date: Wed, 18 Dec 2013 12:54:57 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: robert.cragie@gridmerge.com, dtls-iot@ietf.org References: <52B0C42D.7040505@hauke-m.de> <52B16D2D.1060608@gridmerge.com> In-Reply-To: <52B16D2D.1060608@gridmerge.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 11:55:13 -0000 On 12/18/2013 10:38 AM, Robert Cragie wrote: > I don't think that is quite right. The issue I have come across is some > 32-bit processors have problems reading or writing 16, 32 or 64-bit > values which are not aligned accordingly, i.e. address & 1 != 0, address > & 3 != 0 and address & 7 != 0 respectively and generate an address error > exception. This is the reason a compiler adds padding bytes. Any > processor should be able to read an 8-bit value at any location and > therefore packed structures can be used safely if accesses are done on a > byte-by-byte basis, although this is inefficient of course. > > Robert Yes you are right. Hauke From mcr@sandelman.ca Wed Dec 18 07:23:49 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8481AE189 for ; Wed, 18 Dec 2013 07:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] 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 tfwv5AijXqm7 for ; Wed, 18 Dec 2013 07:23:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id DD2901AE022 for ; Wed, 18 Dec 2013 07:23:47 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 092DF201B0 for ; Wed, 18 Dec 2013 11:37:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7D79A63B89; Wed, 18 Dec 2013 10:23:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6D50763AED for ; Wed, 18 Dec 2013 10:23:34 -0500 (EST) From: Michael Richardson To: dtls-iot@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Wed, 18 Dec 2013 09:12:11 -0800 Subject: Re: [Dtls-iot] 32 bit alignment with IoT X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 15:23:49 -0000 As was said, the alignment goals in IPv6 (64-bits), are not related to a specific kernel requirement, but rather the result of optimizations in various processors. It's just faster to access 32-bit data on 32-bit alignment. This is true on x86 where unaligned access causes no exception, as well as on MIPS where it has to be emulated. The processor architect made a decision to favour the fast path at the cost of a very slow exceptional case. The origin of this has to do with L1 and L2 caches. They start on 64-bit (20 years ago) to 256 bit boundaries. When you touch anything on a cache line, you load everything else, so having structures that fit entirely in a cache line is a major boon. That's why we see the IPv6 extension header structured as it is. Padding sent as zeroes is pretty easy to compress out if one is compressing generically. I've advocated for doing sensible protocol design, leaving ourselves appropriate places to introduce new values, and look at what the byte count is after some naive, trivial compression as provided by 6lowpan HC and GHC. My experience with MSP470 and freescale ARM devices is that they don't have L1 or L2 caches or any alignment issues. While they often support 32-bit operations, they frequently have 16-bit internal buses, so there is essentially no penalty for unaligned access. There is also no penalty for aligned access. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [