< draft-ietf-suit-architecture-07.txt   draft-ietf-suit-architecture-08.txt >
SUIT B. Moran SUIT B. Moran
Internet-Draft Arm Limited Internet-Draft H. Tschofenig
Intended status: Informational M. Meriac Intended status: Informational Arm Limited
Expires: April 22, 2020 Consultant Expires: May 22, 2020 D. Brown
H. Tschofenig
Arm Limited
D. Brown
Linaro Linaro
October 20, 2019 M. Meriac
Consultant
November 19, 2019
A Firmware Update Architecture for Internet of Things Devices A Firmware Update Architecture for Internet of Things
draft-ietf-suit-architecture-07 draft-ietf-suit-architecture-08
Abstract Abstract
Vulnerabilities with Internet of Things (IoT) devices have raised the Vulnerabilities with Internet of Things (IoT) devices have raised the
need for a solid and secure firmware update mechanism that is also need for a solid and secure firmware update mechanism that is also
suitable for constrained devices. Incorporating such update suitable for constrained devices. Incorporating such update
mechanism to fix vulnerabilities, to update configuration settings as mechanism to fix vulnerabilities, to update configuration settings as
well as adding new functionality is recommended by security experts. well as adding new functionality is recommended by security experts.
This document lists requirements and describes an architecture for a This document lists requirements and describes an architecture for a
firmware update mechanism suitable for IoT devices. The architecture firmware update mechanism suitable for IoT devices. The architecture
is agnostic to the transport of the firmware images and associated is agnostic to the transport of the firmware images and associated
meta-data. meta-data.
This version of the document assumes asymmetric cryptography and a
public key infrastructure. Future versions may also describe a
symmetric key approach for very constrained devices.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 22, 2020. This Internet-Draft will expire on May 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 35 skipping to change at page 2, line 30
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Agnostic to how firmware images are distributed . . . . . 7 3.1. Agnostic to how firmware images are distributed . . . . . 8
3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 8 3.2. Friendly to broadcast delivery . . . . . . . . . . . . . 8
3.3. Use state-of-the-art security mechanisms . . . . . . . . 8 3.3. Use state-of-the-art security mechanisms . . . . . . . . 8
3.4. Rollback attacks must be prevented . . . . . . . . . . . 9 3.4. Rollback attacks must be prevented . . . . . . . . . . . 9
3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9 3.5. High reliability . . . . . . . . . . . . . . . . . . . . 9
3.6. Operate with a small bootloader . . . . . . . . . . . . . 9 3.6. Operate with a small bootloader . . . . . . . . . . . . . 9
3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10 3.7. Small Parsers . . . . . . . . . . . . . . . . . . . . . . 10
3.8. Minimal impact on existing firmware formats . . . . . . . 10 3.8. Minimal impact on existing firmware formats . . . . . . . 10
3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10 3.9. Robust permissions . . . . . . . . . . . . . . . . . . . 10
3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 11 3.10. Operating modes . . . . . . . . . . . . . . . . . . . . . 11
3.11. Suitability to software and personalization data . . . . 12 3.11. Suitability to software and personalization data . . . . 13
4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Communication Architecture . . . . . . . . . . . . . . . . . 13 5. Communication Architecture . . . . . . . . . . . . . . . . . 14
6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Device Firmware Update Examples . . . . . . . . . . . . . . . 18 7. Device Firmware Update Examples . . . . . . . . . . . . . . . 19
7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 18 7.1. Single CPU SoC . . . . . . . . . . . . . . . . . . . . . 19
7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 18 7.2. Single CPU with Secure - Normal Mode Partitioning . . . . 19
7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 18 7.3. Dual CPU, shared memory . . . . . . . . . . . . . . . . . 19
7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 18 7.4. Dual CPU, other bus . . . . . . . . . . . . . . . . . . . 19
8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Bootloader . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Mailing List Information . . . . . . . . . . . . . . . . . . 26 12. Mailing List Information . . . . . . . . . . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 28
14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 28 14.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
When developing IoT devices, one of the most difficult problems to When developing Internet of Things (IoT) devices, one of the most
solve is how to update the firmware on the device. Once the device difficult problems to solve is how to update firmware on the device.
is deployed, firmware updates play a critical part in its lifetime, Once the device is deployed, firmware updates play a critical part in
particularly when devices have a long lifetime, are deployed in its lifetime, particularly when devices have a long lifetime, are
remote or inaccessible areas where manual intervention is cost deployed in remote or inaccessible areas where manual intervention is
prohibitive or otherwise difficult. Updates to the firmware of an cost prohibitive or otherwise difficult. Updates to the firmware of
IoT device are done to fix bugs in software, to add new an IoT device are done to fix bugs in software, to add new
functionality, and to re-configure the device to work in new functionality, and to re-configure the device to work in new
environments or to behave differently in an already deployed context. environments or to behave differently in an already deployed context.
The firmware update process, among other goals, has to ensure that The firmware update process, among other goals, has to ensure that
- The firmware image is authenticated and integrity protected. - The firmware image is authenticated and integrity protected.
Attempts to flash a modified firmware image or an image from an Attempts to flash a modified firmware image or an image from an
unknown source are prevented. unknown source are prevented.
- The firmware image can be confidentiality protected so that - The firmware image can be confidentiality protected so that
attempts by an adversary to recover the plaintext binary can be attempts by an adversary to recover the plaintext binary can be
prevented. Obtaining the firmware is often one of the first steps prevented. Obtaining the firmware is often one of the first steps
to mount an attack since it gives the adversary valuable insights to mount an attack since it gives the adversary valuable insights
into used software libraries, configuration settings and generic into used software libraries, configuration settings and generic
functionality (even though reverse engineering the binary can be a functionality (even though reverse engineering the binary can be a
tedious process). tedious process).
This version of the document assumes asymmetric cryptography and a
public key infrastructure. Future versions may also describe a
symmetric key approach for very constrained devices.
While the standardization work has been informed by and optimised for
firmware update use cases of Class 1 (as defined in RFC 7228
[RFC7228]) devices, there is nothing in the architecture that
restricts its use to only these constrained IoT devices. Software
update and delivery of arbitrary data, such as configuration
information and keys, can equally be managed by manifests. The
solution therefore applies to more capable devices, such as network
storage devices, set top boxes, and IP-based cameras as well.
More details about the security goals are discussed in Section 5 and More details about the security goals are discussed in Section 5 and
requirements are described in Section 3. requirements are described in Section 3.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
- Manifest: The manifest contains meta-data about the firmware - Manifest: The manifest contains meta-data about the firmware
image. The manifest is protected against modification and image. The manifest is protected against modification and
provides information about the author. provides information about the author.
- Firmware Image: The firmware image, or image, is a binary that may - Firmware Image: The firmware image, or image, is a binary that may
contain the complete software of a device or a subset of it. The contain the complete software of a device or a subset of it. The
firmware image may consist of multiple images, if the device firmware image may consist of multiple images, if the device
contains more than one microcontroller. Often it is also a contains more than one microcontroller. Often it is also a
compressed archive that contains code, configuration data, and compressed archive that contains code, configuration data, and
even the entire file system. The image may consist of a even the entire file system. The image may consist of a
differential update for performance reasons. Firmware is the more differential update for performance reasons. Firmware is the more
universal term. The terms, firmware image, firmware, and image, universal term. The terms, firmware image, firmware, and image,
are used in this document and are interchangeable. are used in this document and are interchangeable.
- Software: The terms "software" and "firmware" are used
interchangeably.
- Bootloader: A bootloader is a piece of software that is executed - Bootloader: A bootloader is a piece of software that is executed
once a microcontroller has been reset. It is responsible for once a microcontroller has been reset. It is responsible for
deciding whether to boot a firmware image that is present or deciding whether to boot a firmware image that is present or
whether to obtain and verify a new firmware image. Since the whether to obtain and verify a new firmware image. Since the
bootloader is a security critical component its functionality may bootloader is a security critical component its functionality may
be split into separate stages. Such a multi-stage bootloader may be split into separate stages. Such a multi-stage bootloader may
offer very basic functionality in the first stage and resides in offer very basic functionality in the first stage and resides in
ROM whereas the second stage may implement more complex ROM whereas the second stage may implement more complex
functionality and resides in flash memory so that it can be functionality and resides in flash memory so that it can be
updated in the future (in case bugs have been found). The exact updated in the future (in case bugs have been found). The exact
skipping to change at page 8, line 41 skipping to change at page 8, line 49
Integrity protection ensures that no third party can modify the Integrity protection ensures that no third party can modify the
manifest or the firmware image. manifest or the firmware image.
For confidentiality protection of the firmware image, it must be done For confidentiality protection of the firmware image, it must be done
in such a way that every intended recipient can decrypt it. The in such a way that every intended recipient can decrypt it. The
information that is encrypted individually for each device must information that is encrypted individually for each device must
maintain friendliness to Content Distribution Networks, bulk storage, maintain friendliness to Content Distribution Networks, bulk storage,
and broadcast protocols. and broadcast protocols.
A manifest specification must support different cryptographic A manifest specification must support different cryptographic
algorithms and algorithm extensibility. Because of the nature of algorithms and algorithm extensibility. Due of the nature of
unchangeable code in ROM for use with bootloaders the use of post- unchangeable code in ROM for use with bootloaders the use of post-
quantum secure signature mechanisms, such as hash-based signatures quantum secure signature mechanisms, such as hash-based signatures
[I-D.ietf-cose-hash-sig], are attractive because they maintain
[I-D.ietf-cose-hash-sig], are attractive. These algorithms maintain
security in presence of quantum computers. security in presence of quantum computers.
A mandatory-to-implement set of algorithms has to be defined offering A mandatory-to-implement set of algorithms will be specified in the
a key length of 112-bit symmetric key or security or more, as manifest specification [I-D.ietf-suit-manifest]}.
outlined in Section 20 of RFC 7925 [RFC7925]. This corresponds to a
233 bit ECC key or a 2048 bit RSA key.
3.4. Rollback attacks must be prevented 3.4. Rollback attacks must be prevented
A device presented with an old, but valid manifest and firmware must A device presented with an old, but valid manifest and firmware must
not be tricked into installing such firmware since a vulnerability in not be tricked into installing such firmware since a vulnerability in
the old firmware image may allow an attacker to gain control of the the old firmware image may allow an attacker to gain control of the
device. device.
3.5. High reliability 3.5. High reliability
skipping to change at page 19, line 37 skipping to change at page 20, line 37
- the features to verify an image and a manifest, including digital - the features to verify an image and a manifest, including digital
signature verification or checking a message authentication code, signature verification or checking a message authentication code,
- a manifest parsing library, and - a manifest parsing library, and
- integration of the device into a device management server to - integration of the device into a device management server to
perform automatic firmware updates and to track their progress. perform automatic firmware updates and to track their progress.
(*) Because firmware images are often multiple kilobytes, sometimes (*) Because firmware images are often multiple kilobytes, sometimes
exceeding one hundred kilobytes, in size for low end IoT devices and exceeding one hundred kilobytes, in size for low end IoT devices and
even several megabytes large for IoT devices running full-fletched even several megabytes large for IoT devices running full-fledged
operating systems like Linux the protocol mechanism for retrieving operating systems like Linux, the protocol mechanism for retrieving
these images needs to offer features like congestion control, flow these images needs to offer features like congestion control, flow
control, fragmentation and reassembly, and mechanisms to resume control, fragmentation and reassembly, and mechanisms to resume
interrupted or corrupted transfers. interrupted or corrupted transfers.
All these features are most likely offered by the application, i.e. All these features are most likely offered by the application, i.e.
firmware consumer, running on the device (except for basic security firmware consumer, running on the device (except for basic security
algorithms that may run either on a trusted execution environment or algorithms that may run either on a trusted execution environment or
on a separate hardware security MCU/module) rather than by the on a separate hardware security MCU/module) rather than by the
bootloader itself. bootloader itself.
skipping to change at page 26, line 10 skipping to change at page 27, line 10
protecting the manifest. protecting the manifest.
- incentives for manufacturers to offer a firmware update mechanism - incentives for manufacturers to offer a firmware update mechanism
as part of their IoT products. as part of their IoT products.
12. Mailing List Information 12. Mailing List Information
The discussion list for this document is located at the e-mail The discussion list for this document is located at the e-mail
address suit@ietf.org [1]. Information on the group and information address suit@ietf.org [1]. Information on the group and information
on how to subscribe to the list is at on how to subscribe to the list is at
https://www1.ietf.org/mailman/listinfo/suit https://www1.ietf.org/mailman/listinfo/suit [2]
Archives of the list can be found at: https://www.ietf.org/mail- Archives of the list can be found at: https://www.ietf.org/mail-
archive/web/suit/current/index.html archive/web/suit/current/index.html [3]
13. Acknowledgements 13. Acknowledgements
We would like to thank the following persons for their feedback: We would like to thank the following persons for their feedback:
- Geraint Luff - Geraint Luff
- Amyas Phillips - Amyas Phillips
- Dan Ros - Dan Ros
skipping to change at page 27, line 19 skipping to change at page 28, line 19
- Kathleen Moriarty - Kathleen Moriarty
We would also like to thank the WG chairs, Russ Housley, David We would also like to thank the WG chairs, Russ Housley, David
Waltermire, Dave Thaler for their support and their reviews. Waltermire, Dave Thaler for their support and their reviews.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS) Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925, DOI Profiles for the Internet of Things", RFC 7925,
10.17487/RFC7925, July 2016, <https://www.rfc- DOI 10.17487/RFC7925, July 2016,
editor.org/info/rfc7925>. <https://www.rfc-editor.org/info/rfc7925>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-cose-hash-sig] [I-D.ietf-cose-hash-sig]
Housley, R., "Use of the HSS/LMS Hash-based Signature Housley, R., "Use of the HSS/LMS Hash-based Signature
Algorithm with CBOR Object Signing and Encryption (COSE)", Algorithm with CBOR Object Signing and Encryption (COSE)",
draft-ietf-cose-hash-sig-04 (work in progress), October draft-ietf-cose-hash-sig-06 (work in progress), November
2019. 2019.
[I-D.ietf-suit-information-model] [I-D.ietf-suit-information-model]
Moran, B., Tschofenig, H., and H. Birkholz, "Firmware Moran, B., Tschofenig, H., and H. Birkholz, "An
Updates for Internet of Things Devices - An Information Information Model for Firmware Updates in IoT Devices",
Model for Manifests", draft-ietf-suit-information-model-03 draft-ietf-suit-information-model-04 (work in progress),
(work in progress), July 2019. October 2019.
[I-D.ietf-suit-manifest]
Moran, B., Tschofenig, H., and H. Birkholz, "SUIT CBOR
manifest serialisation format", draft-ietf-suit-
manifest-01 (work in progress), October 2019.
[I-D.ietf-teep-architecture] [I-D.ietf-teep-architecture]
Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D. Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
Liu, "Trusted Execution Environment Provisioning (TEEP) Liu, "Trusted Execution Environment Provisioning (TEEP)
Architecture", draft-ietf-teep-architecture-03 (work in Architecture", draft-ietf-teep-architecture-03 (work in
progress), July 2019. progress), July 2019.
[LwM2M] OMA, ., "Lightweight Machine to Machine Technical [LwM2M] OMA, ., "Lightweight Machine to Machine Technical
Specification, Version 1.0.2", February 2018, Specification, Version 1.0.2", February 2018,
<http://www.openmobilealliance.org/release/LightweightM2M/ <http://www.openmobilealliance.org/release/LightweightM2M/
V1_0_2-20180209-A/ V1_0_2-20180209-A/OMA-TS-LightweightM2M-
OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf>. V1_0_2-20180209-A.pdf>.
[RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, DOI (AES) Key Wrap with Padding Algorithm", RFC 5649,
10.17487/RFC5649, September 2009, <https://www.rfc- DOI 10.17487/RFC5649, September 2009,
editor.org/info/rfc5649>. <https://www.rfc-editor.org/info/rfc5649>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/info/rfc6024>. 2010, <https://www.rfc-editor.org/info/rfc6024>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet
of Things Software Update (IoTSU) Workshop 2016", RFC of Things Software Update (IoTSU) Workshop 2016",
8240, DOI 10.17487/RFC8240, September 2017, RFC 8240, DOI 10.17487/RFC8240, September 2017,
<https://www.rfc-editor.org/info/rfc8240>. <https://www.rfc-editor.org/info/rfc8240>.
14.3. URIs 14.3. URIs
[1] mailto:suit@ietf.org [1] mailto:suit@ietf.org
[2] https://www1.ietf.org/mailman/listinfo/suit
[3] https://www.ietf.org/mail-archive/web/suit/current/index.html
Authors' Addresses Authors' Addresses
Brendan Moran Brendan Moran
Arm Limited Arm Limited
EMail: Brendan.Moran@arm.com EMail: Brendan.Moran@arm.com
Milosch Meriac
Consultant
EMail: milosch@meriac.com
Hannes Tschofenig Hannes Tschofenig
Arm Limited Arm Limited
EMail: hannes.tschofenig@arm.com EMail: hannes.tschofenig@arm.com
David Brown David Brown
Linaro Linaro
EMail: david.brown@linaro.org EMail: david.brown@linaro.org
Milosch Meriac
Consultant
EMail: milosch@meriac.com
 End of changes. 33 change blocks. 
82 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/