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

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.
> 
> 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.

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 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.
> 
> <NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009.doc>
> 
> http://www.ipinc.net/IPv4.GIF
> 
> _______________________________________________
> smartpower-interest mailing list
> smartpower-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/smartpower-interest