Subject: [smartpower-interest] Smart Grid Architecture Committee meeting 17 February

From: Fred Baker <[email-masked]>
Date: Wed, 17 Feb 2010 09:11:11 -0500

I am forwarding in case you folks have not seen this. It is the  
proposed IP architecture from NERC, which is a US regulatory body.

One important statement it makes is:

> A final note is that this document will not make the distinction  
> between IP version 4 or version 6 for the purpose of analysis or  
> standardization.  The point is simply to support IP with the version  
> number left to be an implementation detail determined by the utility  
> or service provider that would install the AMI network.  That being  
> said, any competent network planner can easily do the math - many  
> investor-owned utilities have literally millions of electric meters  
> installed (a distinct challenge in a version 4 environment), with  
> this "volume problem" being compounded by the presence of other  
> devices including some quantity of electric vehicles as potential  
> roaming users in the future.  That means the utility would either  
> have to use IPv4 very judiciously and replicate private IP space  
> over and over again, or move to IPv6 and address a greater number of  
> devices uniquely.

This is not as strong a statement re IPv6 as the IETF and ARIN have  
proposed, but is at least a sensible one in the near term.

The architecture doesn't say a lot about security, but does say this:

> The C12.22 protocol also includes AES-128 security mechanisms.  
> Additional IP transport security protocols may be provided to  
> enhance and preserve the upper layer security provisions but not as  
> a substitute of such.

Personally, I think that's an inadequate statement. The key issues are  
in identification, authentication, authorization, and confidentiality  
where appropriate. It would be really nice if http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 
  were approved as "suite b", and the architecture could specify the  
use of "suite b cryptographic standards". For those that don't know  
what that means, it refers to the use of elliptic curve public key  
cryptography without the IPR considerations that have crippled the  
industry's ability to use it. AES, while a very worthwhile technology,  
is symmetric key, which means in the AMI that the key is not in fact  
secret - it is known by and communicated among at least two parties.  
The lack of a key management infrastructure is a problem, which I  
would entertain useful proposals for.

The architecture focuses, surprisingly, not on the use of TCP/UDP and  
IP (v4 or v6), but on the place of the ANSI C12 series management  
applications. Given that those are in the most recent filing moved  
from "mandatory" to "should be considered", that is interesting. One  
thing that would help, perhaps, is a description of how NetConf could  
be used instead, and an openly-defined XML-based schema (from OASYS  
perhaps?) that could be exchanged using it. I'm not going to write  
that, but would entertain submissions.

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

---

From: Joe DiAdamo <[email-masked]>
Date: Wed, 17 Feb 2010 10:33:33 -0500

Fred, is the full document from NERC publically available?

On Wed, Feb 17, 2010 at 9:11 AM, Fred Baker <[email-masked]> wrote:

> I am forwarding in case you folks have not seen this. It is the proposed IP
> architecture from NERC, which is a US regulatory body.
>
>  A final note is that this document will not make the distinction between
>> IP version 4 or version 6 for the purpose of analysis or standardization.
>>  The point is simply to support IP with the version number left to be an
>> implementation detail determined by the utility or service provider that
>> would install the AMI network.  That being said, any competent network
>> planner can easily do the math - many investor-owned utilities have
>> literally millions of electric meters installed (a distinct challenge in a
>> version 4 environment), with this "volume problem" being compounded by the
>> presence of other devices including some quantity of electric vehicles as
>> potential roaming users in the future.  That means the utility would either
>> have to use IPv4 very judiciously and replicate private IP space over and
>> over again, or move to IPv6 and address a greater number of devices
>> uniquely.
>>
>
>
>  The C12.22 protocol also includes AES-128 security mechanisms. Additional
>> IP transport security protocols may be provided to enhance and preserve the
>> upper layer security provisions but not as a substitute of such.
>>
>
> Personally, I think that's an inadequate statement. The key issues are in
> identification, authentication, authorization, and confidentiality where
> appropriate. It would be really nice if
> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 were approved
> as "suite b", and the architecture could specify the use of "suite b
> cryptographic standards". For those that don't know what that means, it
> refers to the use of elliptic curve public key cryptography without the IPR
> considerations that have crippled the industry's ability to use it. AES,
> while a very worthwhile technology, is symmetric key, which means in the AMI
> that the key is not in fact secret - it is known by and communicated among
> at least two parties. The lack of a key management infrastructure is a
> problem, which I would entertain useful proposals for.
>
>
> The architecture focuses, surprisingly, not on the use of TCP/UDP and IP
> (v4 or v6), but on the place of the ANSI C12 series management applications.
> Given that those are in the most recent filing moved from "mandatory" to
> "should be considered", that is interesting. One thing that would help,
> perhaps, is a description of how NetConf could be used instead, and an
> openly-defined XML-based schema (from OASYS perhaps?) that could be
> exchanged using it. I'm not going to write that, but would entertain
> submissions.
>
>
>
>
> _______________________________________________
> smartpower-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smartpower-interest
>
>

-- 

<><><><><><><><><><><><><><>
Joe DiAdamo,P. Eng.
[email-masked]
416-300-1558

---

From: Fred Baker <[email-masked]>
Date: Wed, 17 Feb 2010 11:20:36 -0500

The document I forwarded is at http://collaborate.nist.gov/twiki-sggrid/bin/view/SmartGrid/PAP01InternetProfile 
. As to NERC supporting documentation, you would have to ask them.

On Feb 17, 2010, at 10:33 AM, Joe DiAdamo wrote:

> Personally, I think that's an inadequate statement. The key issues  
> are in identification, authentication, authorization, and  
> confidentiality where appropriate. It would be really nice if http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 
> industry's ability to use it. AES, while a very worthwhile  
> technology, is symmetric key, which means in the AMI that the key is  
> not in fact secret - it is known by and communicated among at least  
> two parties. The lack of a key management infrastructure is a  
> The architecture focuses, surprisingly, not on the use of TCP/UDP  
> and IP (v4 or v6), but on the place of the ANSI C12 series  
> management applications. Given that those are in the most recent  
> filing moved from "mandatory" to "should be considered", that is  
> interesting. One thing that would help, perhaps, is a description of  
> how NetConf could be used instead, and an openly-defined XML-based  
> schema (from OASYS perhaps?) that could be exchanged using it. I'm  
> not going to write that, but would entertain submissions.
>
>
>
>

---

From: Phil Roberts <[email-masked]>
Date: Wed, 17 Feb 2010 12:57:16 -0600

A few meta-questions:

- When you say it is proposed does that mean there is a possibility 
still to influence it at this point, and how does one go about doing that?
- Once this document is done, how will it be used and by whom?
- I'm not sure what to make of the ANSI C12.22 stuff, but I notice that 
it's $166 to get a copy of the standard, and there is some text 
recommending IETF and ANSI get together to create some common ground, 
specifically: "In both cases, it requires the ANSI standards and the 
IETF to come together and create this common ground."

Fred Baker wrote:
>> have to use IPv4 very judiciously and replicate private IP space over 
>> and over again, or move to IPv6 and address a greater number of 
>> devices uniquely.
>
>
>> Additional IP transport security protocols may be provided to enhance 
>> and preserve the upper layer security provisions but not as a 
>> substitute of such.
>
> where appropriate. It would be really nice if 
> http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 were 
> approved as "suite b", and the architecture could specify the use of 
> "suite b cryptographic standards". For those that don't know what that 
> means, it refers to the use of elliptic curve public key cryptography 
> without the IPR considerations that have crippled the industry's 
> ability to use it. AES, while a very worthwhile technology, is 
> symmetric key, which means in the AMI that the key is not in fact 
> ------------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Feb 2010 13:47:41 -0800

Fred,

On Feb 17, 2010, at 6:11 AM, Fred Baker wrote:

> I am forwarding in case you folks have not seen this. It is the proposed IP architecture from NERC, which is a US regulatory body.
> 
>> A final note is that this document will not make the distinction between IP version 4 or version 6 for the purpose of analysis or standardization.  The point is simply to support IP with the version number left to be an implementation detail determined by the utility or service provider that would install the AMI network.  That being said, any competent network planner can easily do the math - many investor-owned utilities have literally millions of electric meters installed (a distinct challenge in a version 4 environment), with this "volume problem" being compounded by the presence of other devices including some quantity of electric vehicles as potential roaming users in the future.  That means the utility would either have to use IPv4 very judiciously and replicate private IP space over and over again, or move to IPv6 and address a greater number of devices uniquely.
> 
> 
> This is not as strong a statement re IPv6 as the IETF and ARIN have proposed, but is at least a sensible one in the near term.

I would go further and say that this document is wrong in a number ways.  First this is an important issue that an "IP architecture" document have a clear recommendation on the version of IP to use. It should not be left as an implementation detail.   Secondly, anything short of an implementation MUST support IPv6 and may also support IPv4 will result in a painful and expensive transition as this system comes on line and starts to grow. Lastly, this approach defined in the document will defeat the main purpose of the the smart grid.  That is, that there be interoperability between all devices on the smart grid.  Not having a clear statement on IPv6 puts the whole program at risk.

Bob

>> The C12.22 protocol also includes AES-128 security mechanisms. Additional IP transport security protocols may be provided to enhance and preserve the upper layer security provisions but not as a substitute of such.
> 
> Personally, I think that's an inadequate statement. The key issues are in identification, authentication, authorization, and confidentiality where appropriate. It would be really nice if http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 were approved as "suite b", and the architecture could specify the use of "suite b cryptographic standards". For those that don't know what that means, it refers to the use of elliptic curve public key cryptography without the IPR considerations that have crippled the industry's ability to use it. AES, while a very worthwhile technology, is symmetric key, which means in the AMI that the key is not in fact secret - it is known by and communicated among at least two parties. The lack of a key management infrastructure is a problem, which I would entertain useful proposals for.
> 
> 
> The architecture focuses, surprisingly, not on the use of TCP/UDP and IP (v4 or v6), but on the place of the ANSI C12 series management applications. Given that those are in the most recent filing moved from "mandatory" to "should be considered", that is interesting. One thing that would help, perhaps, is a description of how NetConf could be used instead, and an openly-defined XML-based schema (from OASYS perhaps?) that could be exchanged using it. I'm not going to write that, but would entertain submissions.
> 
> <NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009.doc>
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 19 Feb 2010 12:29:20 -0500

Fred:

I have a few comments about IPv6 and security.

> I am forwarding in case you folks have not seen this. It is the proposed
> IP architecture from NERC, which is a US regulatory body.
> 
>> installed (a distinct challenge in a version 4 environment), with this
>> "volume problem" being compounded by the presence of other devices
>> including some quantity of electric vehicles as potential roaming
>> users in the future.  That means the utility would either have to use
>> IPv4 very judiciously and replicate private IP space over and over
>> again, or move to IPv6 and address a greater number of devices uniquely.
> 

This allows NAT upon NAT.  I would prefer NERC to more strongly advocate
IPv6.  NERC does not even say that IPv6 is the long-term solution.  I
wish they had gone that far.

> where appropriate.

I agree that these are the right security services to include as long as
you consider access control to be part of authorization.

> It would be nice if [...] the architecture could specify the use of "suite b
> refers to the use of elliptic curve public key cryptography without the
> IPR considerations that have crippled the industry's ability to use it.

Suite B is composed of algorithms that are publicly specified, and it is
defined here: http://www.nsa.gov/ia/programs/suiteb_cryptography.

Suite B includes:

Encryption:  AES with 128- and 256-bit keys

Key Exchange: Elliptic Curve One-Pass Diffie Hellman (called ECDH) using
the curves with 256- and 384-bit prime moduli

Digital Signature: Elliptic Curve Digital Signature Algorithm (called
ECDSA) using the curves with 256- and 384-bit prime moduli)

Hashing: SHA-256 and SHA-384

The smaller size in each of these choices seems quite reasonable for
Smart Grid.

There are intellectual property issues with Elliptic Curve Cryptography
(ECC), but McGrew seems to have found at least one way to implement
these algorithms that avoids the known patents.  See:
http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01

> [...] The lack of a key management
> infrastructure is a problem, which I would entertain useful proposals for.

As a starting point for this discussion, can we leverage the work done
by CableLabs and the WiMAX Forum.  Devices that follow the
specifications from these groups ship with an embedded private key and a
certificate.  This is not the complete answer, but it allows anyone to
authenticate the device.  At some point prior to installation, the
device still needs to be told some things about the network that it will
be connected.  This might be as simple as the insertion of some
configuration data that includes a trust anchor to validate certificates
from the utility.

Russ

---

From: Zach Shelby <[email-masked]>
Date: Mon, 22 Feb 2010 09:19:11 +0200

Hi,

> Encryption:  AES with 128- and 256-bit keys

Good to hear this. AES-128 is suitable for at least IEEE 802.15.4 based 6LoWPAN networks, as these radio chips include an AES-128 hardware engine which can often be accessed for general purposes as well. 

> configuration data that includes a trust anchor to validate certificates

This is also a big problem for constrained networks and device such as we see in 6LoWPAN (http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp). Luckily, it is an important topic in a new proposed working group called Constrained RESTful Environments (CoRE) which includes work items related to security bootstrapping and cooperation with the security area on finding suitable security methods. This is being done in cooperation with ZigBee Smart Energy 2.0 which is IPv6 based. Here are a couple related early drafts for those interested:

http://tools.ietf.org/html/draft-struik-6lowapp-security-considerations
http://www.ietf.org/id/draft-oflynn-6lowapp-bootstrapping-00.txt

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Paul Duffy <[email-masked]>
Date: Mon, 22 Feb 2010 23:06:41 -0500

The ANSI metering specifications.  Find ANSI C12.19 (IEEE 1377) here ...

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=661544&userType=inst

... and a pre-release draft of ANSI C12.22 attached (free!).

.19 is the data model transported around via .22

If you have time to examine, please share your thoughts.

Cheers

On 2/17/2010 1:57 PM, Phil Roberts wrote:
> - I'm not sure what to make of the ANSI C12.22 stuff, but I notice
> that it's $166 to get a copy of the standard, and there is some text

....

---

From: Greg Daley <[email-masked]>
Date: Tue, 23 Feb 2010 15:16:05 +1100

This is visible for people with existing IEEEXplore accounts.

Greg Daley

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Duffy
> Sent: Tuesday, 23 February 2010 3:07 PM
> To: Phil Roberts
> Cc: [email-masked]
> Subject: Re: [smartpower-interest] Smart Grid Architecture 
> Committee meeting 17 February
>

---

From: Greg Daley <[email-masked]>
Date: Tue, 23 Feb 2010 15:16:58 +1100

Apologies.

I have now opened the attachment :-/

Greg Daley

---

From: "Davis, Terry L" <[email-masked]>
Date: Tue, 23 Feb 2010 11:05:10 -0800

Russ

I agree with you 100% on both the v6 and the security solution; we looked at a similar concept for keying that I liked very much.

I don't think it was on the smartpower lists but on one of the others...  The North American grid system includes 300 million electric meters (just the meters not counting anything else).  That's at least 20 NAT zones to translate between if you use 10 space just for the meters.

I also might suggest that Suite B - circa 2011 be the target as it will have several major changes from NIST.

It might also be of value to actually start working on true vendor-to-vendor interoperability.  SmartGrid like aviation, will likely find that it will have to write into the proposals that simple to implement vendor-to-vendor IPSec/IKEv2 interoperability be provided.

They might also want to take a look at the ATA Spec 42 working on standardizing certificate formats.

Take care
Terry

> [mailto:[email-masked]] On Behalf Of 
> Russ Housley
> Sent: Friday, February 19, 2010 9:29 AM
> To: Fred Baker
> Committee meeting17 February
> 
> Fred:
>