Subject: [smartpowerdir] Summary of Smart Power matters July 2010

From: Fred Baker <[email-masked]>
Date: Sun, 25 Jul 2010 05:54:07 +0200

Your chair has asked me to brief you on what's happening in the Smart Grid. I'm going to do so verbally at dinner this evening, but here is a note summarizing matters in case I miss a point or it doesn't make it across.

The electrical grid today is composed of a lot more than generators, transmission and distribution systems, and meters at homes. It also includes market entities, network operations similar to the operational issues of computer networks, and front end "electrical utilities" that primarily manage billing relationships with consumers. Like the Internet, these are often separate companies that work together through a system of established trust, and which depend on machine-to-machine communications to accomplish their daily tasks. Over the past two decades, SCADA systems have been developed that facilitate the management of various things, and standards have been developed (primarily through ANSI-acredited bodies and the IEC) for their interoperation. The grid is also being extended. Where in the past the grid has delivered electricity to consumers and any networks in it have been primarily for the purpose of managing that one-way flow, increasingly consumers are also producers of energy and share their production, via the grid, with their neighbors, which can be a good thing but also has dangers and operational problems. Home automation results in fundamental changes to the concept of an electrical switch and other common elements - where the switch used to make or break a contact, it now often sends a message to a computer that controls such things. And the electrical utilities have discovered that by appropriate planning they can achieve measurable (on the order of 30%) economies, especially if consumers will cooperate with them in supplying information and accepting temporary shutdowns or rate changes to manage load.

The problem with the grid is not that it lacks intelligence; it is that it is a cacophony of voices, speaking every possible language, often proprietary ones. I have spoken with utilities that use DECNET IV to run their SCADA systems. There are vendors that use ANSI C12.19 (a "MIB" by any other name) and C12.21/22 (an ACSE/ROSE-based communication protocol intended to facilitate secure communications between managers and managed systems) and either love it or hate it; many use just enough of C12.19 to be able to say they support it and place their attributes in the "proprietary extensions" tree, and I know of at most one or two full implementations. Some parts of the grid use application-on-Ethernet or other "interesting" architectures.

NIST's objective is to reduce the babble to a dull roar, and provide a way forward that facilitates communication. In the words of the NIST Roadmap, Version 1.0, September 2009, “…the Network should enable an application in a particular domain to communicate with an application in any other domain in the information network, with proper management control over who and where applications can be interconnected.” In my opinion, that is eminently doable using IPv4 or IPv6, and IPv6 should be chosen due to address space limitations. Many of the security issues ("how do you certifiably prevent script kiddies from attacking critical infrastructure in both the back office and the technical plant?") is readily handled by routing: "don't advertise the prefixes of critical infrastructure to folks that have no need to access it." For issues for which that is not adequate, strong mutual authentication/authorization and encryption is required.

My initial project in this was, in response to a request from NIST, to write a document that describes the Internet Architecture and its core protocols. This internet draft is Internet Protocols for the Smart Grid, by Monday morning in its -06 version, and probably due one or two more iterations. What I originally intended to describe included IPv4, IPv6, ICMP and ICMPv6, a handful of transports, and the use of IPsec and TLS for security purposes; in response to specific requests, it has grown to reference ~150 internet drafts and RFCs, and will likely add a few more surrounding network management. It has had review from the security directorate, which in essence said they didn't like it but have not responded with suggestions for how to improve it beyond "reference CMS" (of the 27 RFCs under that rubric, which, and saying what? Presumably at least 5275 and 5652...); the easy part of a review is to say something is wrong, but what I need is for someone to suggest text that is right. It has also had review from one of the Applications Area Directors, who didn't like the proposed model of the architecture; her suggestion for a way to improve it was "recommend RESTful HTTP". Neither has been, in my opinion, very helpful. The Smart Grid community has stated, however, that this document is useful to them and largely serves the purpose for which it was requested - but they hope for other documents that drill a level deeper into specific areas, such as making security recommendations. I hope to conclude the development of this draft in the near future and send it off for consideration as an Informational RFC. 

My sense, as I embarked on the project a year ago, was that given 6LowPAN and Roll, the IETF had little to do beyond this; the bits and pieces needed are in place and in use. In general, I continue to be of that opinion: much of the Smart Grid is very similar to any industry's back office. It uses the same equipment and software, and the real time automation used in the grid is well served by the tools at hand.

That said, the designers of IEEE 802.15.4 have not done the industry any favors. As a result there has been concern regarding the use of any protocol that uses half of the 128 byte MAC frame to encode the network protocols and the remainder for a paltry payload, and the reliability of delivery has been a problem as well. This has resulted in part in spinning up the CORE working group, whose primary effort has been CoAP, and demonstration efforts within Zigbee showing the technology operating perfectly well using standard SOAP or RESTful HTTP on TCP.

At this point, the folks working on the "Home Area Network" or HAN (which is to say people from the Zigbee Alliance) have identified several usability issues, which they are bringing back to the IETF through the usual ad hoc channels. They tell me that these revolve around:

a) getting 6LowPAN to publish some drafts that appear to be finished but await working group chair movement. 6lowpan-nd and -hc need to be completed.

b) 6lowpan WG has not produced a comprehensive "IP over 802.15.4" document that addresses all the 802.25.4-specific details about how to use the radios, how to pick a PAN, how to join a network, etc. Ideally, Zigbee should be able to say "use these RFCs", and can't.

c) Getting Roll to deliver a stable and functional protocol. This is political and controversial between the participants in the discussion. RPL provides two modes: one in which a router is expected to store a route table, and one in which it stores at most a few routes. The latter mode, until the recent reposting of the draft, only supported routing from a sensor to a router at the edge, not from the router back to the sensor. In this edition, WGLC to complete 29 July, RPL's low memory mode depends on source routing (which in turn depends on two drafts submitted to 6man that it has not yet accepted) from the edge router, which may have IPR issues - which has led Zigbee to assert that it is only interested in networks small enough to use the "stored route table" model. Zigbee gave Roll a hard deadline for a stable protocol, 29 July; at the moment, the alternative on the table is DYMO, and there are in my mind issues with that as well.

d) Meanwhile, Geoof Mulligan organized a Bar BOF at the Anaheim meeting and is proposing one in this meeting, toward designing a mesh-under routing protocol. Requirements development for such a protocol is within the 6lowpan charter. I have made some suggestions along the furrows plowed by Paul Tsuchiya's Landmark Routing algorithm; there are also other possible approaches. Given the "we need something now" mentality, I suspect the question is coming up too late.

e) For service location purposes, Zigbee proposes to use Multicast DNS, which has been taking too long and which only returns link-local addresses (if I am at the utility and need to talk with the Energy Management System [EMS] in a home, I want to be able to get a global address in response to a DNS translation). One could argue for Dynamic DNS with the DNS server in the Energy Management System (which may be part of or sitting next to the meter), or for a more static solution. I'm not sure where the service location protocol might fit in this; its security issues may make it useless. CoAP offers a "resource discovery" feature that may obviate the need for M-DNS and service discovery.

f) Regarding CORE/CoAP: it would be good if the Zigbee Alliance could get some numbers to support or disprove the statement "HTTP/TLS/TCP will meet our performance requirements for SEP 2.0 in networks of fewer than 30 nodes".  There's a concern that CoAP will result in a walled garden of SEP 2.0 nodes, where any CoAP/HTTP gateway will stifle application development. There is also good reason to be concerned about making Secure Energy Profile 2.0 dependent on Yet Another RFC from a WG that is just now getting started. Note that CoAP is seen as the backup in case HTTP/TLS/TCP turns out for naught, not a primary requirement. And CoAP is experiencing mission creep...

g) Open standards for cryptography can and should be used.  Current work suggests that standard mechanisms like TLS and PKIX are suitable for use in SG's constrained environments, given some modest profiling that fits into Internet standards rather than changing those standards (AES-CCM, Cert Compression).   Cryptographic algorithms can and should use open specifications that predate specialized methods (Fundamental ECC).   

h) PANA relay

i) As you may be aware (I was not), security in the HAN is at the moment being derived from 802.1X using EAP-TLS (RFC 5216) at the link layer. In short, devices that enter the HAN should be those that are authorized access. A comment I got from a NIST security architect (Justin Searles) said that was the best security available today. It gives me some concern, however, as the fact that one is authorized to use a network doesn't mean one is authorized to do anything in particular in the network - the fact that I can attach my laptop doesn't mean I can reconfigure the routers, for example. I'd be interested in other views...

j) NIST is asking questions about secure network management. I have suggested Netconf, and there is review happening both by the relevant chairs and by a NIST consultant along those lines. Depending on the analysis, Netconf may have some things to address - at this point TBD.

---

From: Zach Shelby <[email-masked]>
Date: Sun, 25 Jul 2010 11:44:51 +0200

Hi Fred,

> At this point, the folks working on the "Home Area Network" or HAN (which is to say people from the Zigbee Alliance) have identified several usability issues, which they are bringing back to the IE…

On much of that mail I agree with you! I have a different impression on some of the ZigBee IP issues though (be careful as there are tons of politics over there). Would be a good idea for us to discuss the CoRE related issues as well sometime before the SmartPower Directorate meeting? 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Jul 2010 06:32:59 -0400

>>>>> "Fred" == Fred Baker <[email-masked]> writes:

    Fred> i) As you may be aware (I was not), security in the HAN is at
    Fred> the moment being derived from 802.1X using EAP-TLS (RFC 5216)
    Fred> at the link layer. In short, devices that enter the HAN should
    Fred> be those that are authorized access. A comment I got from a
    Fred> NIST security architect (Justin Searles) said that was the
    Fred> best security available today. It gives me some concern,
    Fred> however, as the fact that one is authorized to use a network
    Fred> doesn't mean one is authorized to do anything in particular in
    Fred> the network - the fact that I can attach my laptop doesn't
    Fred> mean I can reconfigure the routers, for example. I'd be
    Fred> interested in other views...

Fred, can you point me at documents discussing this in more detail?
So far I've been unable to determine:

* Where device certificates come from and how they are chained back to a
  trust anchor that the EAP server knows

* How the EAP server gets a certificate that chains back to a trust
  anchor that the device knows

* How the EAP server authorizes devices

* How the device authorizes EAP servers

I'll admit that eap-tls seems at first glance like a singular
inapplicable technology in this space. That may well be my iniability to
imagine how this is all going to be deployed, so any assistance in
understanding would be greatly appreciated.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 25 Jul 2010 13:48:07 +0200

Fred,

Thank you for the report.

A few comments inline:

Your
chair has asked me to brief you on what's happening in the Smart Grid.
I'm going to do so verbally at dinner this evening, but here is a note
summarizing matters in case I miss a point or it doesn't make it across.

The electrical grid
today is composed of a lot more than generators, transmission and
distribution systems, and meters at homes. It also includes market
entities, network operations similar to the operational issues of
computer networks, and front end "electrical utilities" that primarily
manage billing relationships with consumers. Like the Internet, these
are often separate companies that work together through a system of
established trust, and which depend on machine-to-machine
communications to accomplish their daily tasks. Over the past two
decades, SCADA systems have been developed that facilitate
the management of various things, and standards have been developed
(primarily through ANSI-acredited bodies and the IEC) for their
interoperation. The grid is also being extended. Where in the past the
grid has delivered electricity to consumers and any networks in it have
been primarily for the purpose of managing that one-way flow,
increasingly consumers are also producers of energy and share their
production, via the grid, with their neighbors, which can be a good
thing but also has dangers and operational problems. Home automation
results in fundamental changes to the concept of an electrical switch
and other common elements - where the switch used to make or break a
contact, it now often sends a message to a computer that controls such
things. And the electrical utilities have discovered that by
appropriate planning they can achieve measurable (on the order of 30%)
economies, especially if consumers will cooperate with them in
supplying information and accepting temporary shutdowns or rate changes
to manage load.

The problem with the
grid is not that it lacks intelligence; it is that it is a cacophony of
voices, speaking every possible language, often proprietary ones. I
have spoken with utilities that use DECNET IV to run their SCADA
systems. There are vendors that use ANSI C12.19 (a "MIB" by any other
name) and C12.21/22 (an ACSE/ROSE-based communication protocol intended
to facilitate secure communications between managers and managed
systems) and either love it or hate it; many use just enough of C12.19
to be able to say they support it and place their attributes in the
"proprietary extensions" tree, and I know of at most one or two full
implementations. Some parts of the grid use application-on-Ethernet or
other "interesting" architectures.

NIST's objective is
to reduce the babble to a dull roar, and provide a way forward that
facilitates communication.

This indeed very much a necessary action.

In the words of
the NIST Roadmap, Version 1.0, September 2009, “…the Network should enable an application in a particular domain to
communicate with an application in any other domain in the information network, with proper management control over who and where applications can be
interconnected.” In my opinion, that is eminently doable using IPv4 or
IPv6, and IPv6 should be chosen due to address space limitations. Many
of the security issues ("how do you certifiably prevent script kiddies
from attacking critical infrastructure in both the back office and the
technical plant?") is readily handled by routing: "don't advertise the
prefixes of critical infrastructure to folks that have no need to
access it." For issues for which that is not adequate, strong mutual
authentication/authorization and encryption is required.

My initial project
in this was, in response to a request from NIST, to write a document
that describes the Internet Architecture and its core protocols. This
internet draft is Internet Protocols for the Smart Grid, by Monday morning in its -06 version, and
probably due one or two more iterations. What I originally intended to
describe included IPv4, IPv6, ICMP and ICMPv6, a handful of transports,
and the use of IPsec and TLS for security purposes; in response to
specific requests, it has grown to reference ~150 internet drafts and
RFCs, and will likely add a few more surrounding network management. It
has had review from the security directorate, which in essence said
they didn't like it but have not responded with suggestions for how to
improve it beyond "reference CMS" (of the 27 RFCs under that rubric,
which, and saying what? Presumably at least 5275 and 5652...); the easy
part of a review is to say something is wrong, but what I need is for
someone to suggest text that is right.

I think some of this growth was justified, but there has to be a limit.
I think we need to push back on how long the list of core communication
mechanisms are. Ultimately, all sane IETF RFCs are usable in some
context, but you do not want to reference everything. I think your
approach to looking at layers in the document is rational and I would
resist attempts to add more information. I am sure that more
information is needed, but you can also do that in future documents
that might look at higher layers or specific problem areas.

It has also had
review from one of the Applications Area Directors, who didn't like the
proposed model of the architecture; her suggestion for a way to improve
it was "recommend RESTful HTTP". Neither has been, in my opinion, very
helpful. The Smart Grid community has stated, however, that this
document is useful to them and largely serves the purpose for which it
was requested - but they hope for other documents that drill a level
deeper into specific areas, such as making security recommendations. I
hope to conclude the development of this draft in the near future and
send it off for consideration as an Informational RFC.

I don't think your document currently talks about layers above
transport, correct? If so, I would leave it at that and make another
document that recommends core/restful http. Maybe "Recommendations for
Application and Middleware Protocol Toolkits for Low-Powered
Networking".

My sense, as I
embarked on the project a year ago, was that given 6LowPAN and Roll, the IETF had little to do beyond this; the
bits and pieces needed are in place and in use. In general, I continue
to be of that opinion: much of the Smart Grid is very similar to any
industry's back office. It uses the same equipment and software, and
the real time automation used in the grid is well served by the tools
at hand.

I think we have the base and with the base we have little to do. That
being said, I do believe that on higher layers there will be more work.
There will be optimizations, middleware protocol designs, etc that
tailor to some subset of the 10,000 smart grid applications.

That said, the
designers of IEEE 802.15.4 have not done the industry any favors. As a
result there has been concern regarding the use of any protocol that
uses half of the 128 byte MAC frame to encode the network protocols and
the remainder for a paltry payload, and the reliability of delivery has
been a problem as well. This has resulted in part in spinning up the CORE working group, whose primary effort has been CoAP, and demonstration efforts within Zigbee
showing the technology operating perfectly well using standard SOAP or
RESTful HTTP on TCP.

OK

At this point, the
folks working on the "Home Area Network" or HAN (which is to say people
from the Zigbee Alliance) have identified several usability issues,
which they are bringing back to the IETF through the usual ad hoc
channels. They tell me that these revolve around:

a) getting 6LowPAN
to publish some drafts that appear to be finished but await working
group chair movement. 6lowpan-nd and -hc need to be completed.

This is serious, and we are following up on this. Ralph has heard the
complaints from several directions.

b) 6lowpan WG has
not produced a comprehensive "IP over 802.15.4" document that addresses
all the 802.25.4-specific details about how to use the radios, how to
pick a PAN, how to join a network, etc. Ideally, Zigbee should be able
to say "use these RFCs", and can't.

Indeed.

c) Getting Roll to
deliver a stable and functional protocol. This is political and
controversial between the participants in the discussion. RPL provides two
modes: one in which a router is expected to store a route table, and
one in which it stores at most a few routes. The latter mode, until the recent
reposting of the draft, only supported routing from a sensor to a
router at the edge, not from the router back to the sensor. In this
edition, WGLC to complete 29 July, RPL's low memory mode depends on
source routing (which in turn depends on two drafts submitted to 6man
that it has not yet accepted) from the edge router, which may have IPR
issues - which has led Zigbee to assert that it is only interested in
networks small enough to use the "stored route table" model. Zigbee
gave Roll a hard deadline for a stable protocol, 29 July; at the
moment, the alternative on the table is DYMO, and there are in my mind
issues with that as well.

Yes.

I'll add that I have had concerns in the Roll space due highly
optimized complex requirements and the desire to mix application layer
and routing logic. Asking for IPv6 extensions is also a big request.
They may make sense, but my overall advice would be to ship something
that works even if it may be suboptimal in some sense.

d) Meanwhile, Geoof
Mulligan organized a Bar BOF at the Anaheim meeting and is proposing
one in this meeting, toward designing a mesh-under routing protocol.
Requirements development for such a protocol is within the 6lowpan
charter. I have made some suggestions along the furrows plowed by Paul
Tsuchiya's Landmark Routing algorithm; there are also other possible
approaches. Given the "we need something now" mentality, I suspect the
question is coming up too late.

I'll note that the working group has existed for a number of years and
it is still unclear exactly what architecture they are doing. At the
same time, while the complex ND optimizations have depended on the
architecture questions, the working group has not progressed simple
specifications that other bodies were waiting for.

e) For service
location purposes, Zigbee proposes to use Multicast DNS, which has been
taking too long and which only returns link-local addresses (if I am at
the utility and need to talk with the Energy Management System [EMS] in
a home, I want to be able to get a global address in response to a DNS
translation). One could argue for Dynamic DNS with the DNS server in
the Energy Management System (which may be part of or sitting next to
the meter), or for a more static solution. I'm not sure where the
service location protocol might fit in this; its security issues may
make it useless. CoAP offers a "resource discovery" feature
that may obviate the need for M-DNS and service discovery.

This is an issue.

f) Regarding
CORE/CoAP: it would be good if the Zigbee Alliance could get some
numbers to support or disprove the statement "HTTP/TLS/TCP will meet
our performance requirements for SEP 2.0 in networks of fewer than 30
nodes".  There's a concern that CoAP will result in a walled garden of
SEP 2.0 nodes, where any CoAP/HTTP gateway will stifle application
development. There is also good reason to be concerned about
making Secure Energy Profile 2.0 dependent on Yet Another RFC from a WG
that is just now getting started. Note that CoAP is seen as the backup
in case HTTP/TLS/TCP turns out for naught, not a primary requirement.
And CoAP is experiencing mission creep...

OK

g) Open standards for
cryptography can and should be used.  Current work suggests that
standard mechanisms like TLS and PKIX are suitable for use in SG's
constrained environments, given some modest profiling that fits into
Internet standards rather than changing those standards (AES-CCM, Cert Compression).   Cryptographic
algorithms can and should use open specifications that predate
specialized methods (Fundamental ECC).

Absolutely.

h) PANA relay

?

i) As you may be
aware (I was not), security in the HAN is at the moment being derived
from 802.1X using EAP-TLS (RFC 5216) at the link layer. In short,
devices that enter the HAN should be those that are authorized access.
A comment I got from a NIST security architect (Justin Searles) said
that was the best security available today. It gives me some concern,
however, as the fact that one is authorized to use a network doesn't
mean one is authorized to do anything in particular in the network -
the fact that I can attach my laptop doesn't mean I can reconfigure the
routers, for example. I'd be interested in other views...

I think you are right.

j) NIST is asking
questions about secure network management. I have suggested Netconf,
and there is review happening both by the relevant chairs and by a NIST
consultant along those lines. Depending on the analysis, Netconf may
have some things to address - at this point TBD.

OK

Jari

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 28 Jul 2010 11:13:31 -0400

Quick comment: As far as I've been following this (and it seems to be very much in flux), the resource discovery in CORE is still multicast, with the usual problems of scaling beyond the local network. This doesn't seem inherently superior to m-DNS (besides maybe shipping before that document does, succeeding Duke Nukem Forever...).

Henning

---

From: Zach Shelby <[email-masked]>
Date: Wed, 28 Jul 2010 18:58:12 +0200

Hi,

This really isn't an issue. Currently CoRE is not specified for use by the ZigBee IP SE2.0 profile for data transfer, nor for discovery. The newest internal ZigBee IP specification uses mDNS to discover HTTP SE2.0 services. There are some references for *future* use of CoRE in ZigBee where it is appropriate (tbd). It was obviously just a misunderstanding that there was a problem here. 

Zach