Subject: [smartobjectdir] Call for Review of draft-iab-smart-object-architecture-04.txt, "Architectural Considerations in Smart Object Networking"

From: IAB Chair <[email-masked]>
Date: Wed, 27 Aug 2014 14:18:35 -0400

This is a call for review of "Architectural Considerations in Smart Object Networking" prior to potential approval as an IAB stream RFC.

The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/

The Call for Review will last until 24 September 2014.  Please send comments to [email-masked].

On behalf of the IAB,
   Russ Housley
   IAB Chair

---

From: "George, Wes" <[email-masked]>
Date: Wed, 27 Aug 2014 15:55:28 -0400

I made the following comment (in part) on -03. I'm making it again,
because it still applies to -04.

"It seems odd to me that this document is silent on the architectural
considerations that IPv4 exhaustion may have on Smart Object networking.
RFC 6272 discusses support for both protocols, but partially because it
was written in 2011, it treats them equally (no recommendation to support
one protocol over another). I think we’re doing smart object implementers
a disservice by not discussing the increasing likelihood that access to
IPv4 addresses will be challenging and costly, especially for something at
the scale of Smart Object networking."

At the time, the feedback from Hannes was that discussing a specific
protocol was too low-level for this document, but I argued that the lack
of IPv4 address availability, the potential order of magnitude of the
deployment of devices in applications like this, and their limitations
(power, etc) make IPv4 vs IPv6 very much an interoperability consideration
and an architectural consideration. If your architecture doesn't take into
account the fact that we're out of IPv4 addresses, then it's not much of
an architecture. Adding a discussion about IPv4's limitations and a
recommendation for IPv6 isn't a discussion of a protocol for the sake of
compare and contrast, as much as it is acknowledging the reality of the
situation.
I don't believe that smart object networking is viable at any real scale
without IPv6. There simply aren't enough addresses, even taking into
account RFC1918. I see this *today* in my own network with deployments
like large-scale WiFi and cell tower deployment, set-top-boxes, etc. I
think that's the right sort of scale to observe as an analog for smart
object networks -- they could potentially be orders of magnitude bigger.
The more clearly we say that smart object networks and their supporting
systems should assume IPv6, and possibly IPv6-only because of IPv4's
inherent scaling limitation, the better off we're going to be.

So in terms of smart objects, especially those that are severely resource
constrained, I think the recommendations are- First support IPv6, whether
it's full IPv6, or something like 6LoPAN. Any interworking or other issues
that arise from that choice can be addressed on the far side where there
isn't such a resource constraint or scaling issue, eg placing an ALG or
NAT64 in front of the IPv6-only devices to make them reachable by legacy
IPv4 clients and management systems.
Even if you assume that smart object deployments aren't going to be
largely greenfield (which in a lot of cases they are, because the
infrastructure doesn't exist today), it's almost always going to be easier
to make changes to the network and other systems to get those to support
IPv6 than it is to add transition technologies, support dual-stack, or
retrofit smart object networks from IPv4 to IPv6 later. This is due to the
scale of deployment and the resource constraints of the device class.
That's an architectural consideration that drives toward a recommendation
of single-stack whenever possible.

Several IAB folks, including two of the authors agreed that this is
something that should be added, but it has not been addressed in this
version. In fact, section 2.1 presents IP version as if it is still open
for discussion on each design, and the other mention of single stack vs
dual stack in section 4.2 appears to have been removed. I'm hoping that
this was merely an oversight rather than a conscious decision.

Thanks,

Wes George

On 8/27/14, 2:18 PM, "IAB Chair" <[email-masked]> wrote:

>This is a call for review of "Architectural Considerations in Smart
>Object Networking" prior to potential approval as an IAB stream RFC.
>
>The document is available for inspection here:
>https://datatracker.ietf.org/doc/draft-iab-smart-object-architecture/
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Aug 2014 07:07:53 -0400

I agree 100% with the observations Wes makes and his recommendation that text be added to the document to the effect that IPv6 is strongly recommended for use in Smart Objects

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Aug 2014 07:12:43 -0400

The security section is especially handwavey ... especially considering security is probably more important for smart objects while there are fewer resources available for implementing security in smart objects than elsewhere.

Here's a useful take on the security issue that might provide some guidance for additional tet in the security section: http://trac.tools.ietf.org/wg/ace/trac/wiki/Questions

If the IAB is not prepared to undertake recommendations on security at this time, in my opinion security should be tagged as a topic for future work in addition to the pointers to earlier work.

- Ralph

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 29 Aug 2014 01:31:04 +0200

I agree with George which shows one important point missing, while
IMHO there may be more missing important points. However, I just read the
title and abstract and I see that this document is not specifying its
objectives, just it is general information. I don't see clear points of the
importance of this document while considering IParchitecture. I don't think
its structure fulfilling its title's aim.

------ OLD Title -----

Architectural Considerations in Smart Object Networking.

------ NEW Title -----

Architectural Design Considerations for networking Smart Objects
within the Internet of Things.

------ OLD Abstract -----

  Following the theme "Everything that can be connected will be
connected", engineers and researchers designing smart object networks
need to decide how to achieve this in practice.

This document offers guidance to engineers designing Internet
connected smart objects.

  ------ NEW Abstract ----

Following the theme "Everything that can be connected will be
connected", engineers
and researchers designing smart object networks need to decide how to
achieve this in practice. That can be done by considering architectural
issues and design guidance.

This document offers recommendations of designing Internet connected
smart objects.

Best Regards,

AB

On Wednesday, August 27, 2014, George, Wes wrote:

> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.
>

---

From: Steve Crocker <[email-masked]>
Date: Fri, 29 Aug 2014 07:27:55 -0400

Another “security” dimension that’s increasingly relevant is whether the design, configuration or operation might lead to unintended storms.  For a recent example of such a problem, see:

http://www.washingtonpost.com/blogs/capital-weather-gang/wp/2014/08/26/national-weather-service-website-taken-down-by-overzealous-android-app/

In February this year, the US National Science Foundation sponsored a workshop on Interdisciplinary Pathways towards a More Secure Internet.  The report included several recommendation, two of which seem relevant here.

Create a Framework for Managing Software Updates

The Internet of Things will challenge our current channels for distributing security updates. An environment must be developed for distributing security patches that scales to a world where almost everything is connected to the Internet and many “things” are largely unattended.

Enhance the Security of the Internet of Things by Identifying Enclaves

The security challenges posed by the emerging Internet of Things should be addressed now, to prepare before it is fully upon us. By identifying specific use segments, or “enclaves,” Internet of Things infrastructure stakeholders can address the security requirements and devise event remediations for that enclave.
Steve