Subject: [smartpower-interest] Fwd: Summary of Smart Power matters July 2010

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

I am tracking down a room for a meeting, as a number have expressed interest. I suspect it will come down to having dinner together Thursday night, details TBD. Open to suggestions.

The IAB has asked me to comment on the Smart Grid progress at dinner this (Sunday) evening; I just sent this to them as preparatory material. It represents the outcome of the SGIP PAP#1 meeting Thursday expressed from an IETF perspective. Happy to discuss, either in email or in the discussion when we have it.

Begin forwarded message:

> From: Fred Baker <[email-masked]>
> Date: July 25, 2010 5:54:07 AM GMT+02:00
> To: IAB <[email-masked]>
> Cc: IETF SmartPower Directorate <[email-masked]>
> Subject: Summary of Smart Power matters July 2010
> Reply-To: IETF SmartPower Directorate <[email-masked]>
> 
> 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.

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Mon, 26 Jul 2010 06:06:12 +0200

FYI - I had run my note yesterday past the 6lowpan chairs before sending it, but they had not seen it to reply. I got this from Geoff this morning; it is only fair to let him correct the record in these respects. Note that JP had in fact replied, and I had adjusted the comments on ROLL with respect to his comments.

Begin forwarded message:

> From: Geoff Mulligan <[email-masked]>
> Date: July 26, 2010 12:34:53 AM GMT+02:00
> To: Fred Baker <[email-masked]>
> Subject: Re: Fwd: Summary of Smart Power matters July 2010
> 
> Fred,
>  I think that this is basically ok.  I do take a few exceptions:
> 
> 1. Zigbee didn't demonstrate RESTful http over 6lowpan and 15.4 - I did
> it.  Now zigbee is planning on using it.
> 
> 2. paragraph a) - The HC and ND drafts are not being delayed by the
> 6lowpan chairs.  There have been fruitful and continuing discussions on
> both drafts.  I think that HC is now done and we will say so in the
> meeting on Monday.  The ND draft needs one for revision and will call it
> complete.  So again these are not waiting on the chairs.
> 
> 3. paragraph b) - JP and David Culler had started and promised a 6lowpan
> "arch" doc.  I volunteered to help, but nothing has come of it.  I do
> agree that it would be good and nice if there were some document the
> described IP over 15.4, but including how to pick a pan and channel and
> join a network is quite a bit of work.  I think that we are chartered to
> do this, but so far no one has stepped up (in 6lowpan) so zigbee is
> defining how to do it for zigbee.
> 
> 4. paragraph d) - I did not hold the bar bof to do anything in the time
> frame for zigbee or the smart grid, but to work on something that
> 6lowpan was supposed to do from the start - RFC4919 describes a network
> that is mesh under.
> 
> 5. paragrpah f) - The other demo I built - showing tcp/http running over
> a multi-hop network included 30+ nodes.
> 
> So basically right, but something thing just slightly askew.  If you
> talk to folks about this after the IAB meeting I hope that you can
> properly reflect these 5 points.
> 
> 	geoff
> 
> 
> On Sun, 2010-07-25 at 06:00 +0200, Fred Baker wrote:
>> What I actually sent.
>> 
>> Begin forwarded message:
>> 
>>> 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.
>>