[smartpower-interest] Fwd: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009

[Fred Baker <[e-mail]>]

FYI - this is the note I sent NIST.

Begin forwarded message:

> From: Fred Baker <[e-mail]>
> Date: February 17, 2010 10:08:19 AM EST
> To: Multiple recipients of list <[e-mail]>
> Subject: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009
> Reply-To: [e-mail]
>
>
> I have done a quick review on this. I hope you're on the [e-mail] 
>  list; if you are, you have already seen my comment to that list.
>
> I would have preferred that the document made a stronger statement  
> about IPv6; the current statement will, I fear, result in utilities  
> trying to push IPv4 usage in the near term, creating a need to  
> transition from IPv4 to IPv6 in the relatively near future.  
> Utilities would do better to go straight to IPv6 up front for  
> operational reasons, as transition is messy and can be expensive if  
> it means upgrading firmware with a new image that may not fit in the  
> target memory system. I would hope that the architecture would make  
> clear that IPv6 support is mandatory in products deployed in the  
> Smart Grid, even if the utility deploys IPv4 in the near term, to  
> overcome those issues.
>
> I also don't find the statement regarding security adequate. It says  
> that C12.22's use of AES-128 is fundamental, and overlooks the use  
> of Suite B technologies that enable IPR-free verifiable public key  
> authentication, such as one might find in http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc 
> . Symmetric key cryptography has its place, but I think public key  
> cryptography would be far more scalable. To give you an idea of the  
> implications, with symmetric key crypto, either every system in a  
> domain uses the same key (which is not very secure) or every pair of  
> systems shares a key, which means that central controllers have a  
> key for each meter that they might speak with. With public key,  
> every system including the central controller has a single key pair,  
> public and private, and either encrypts in its own private or its  
> peer's public key depending on the intent (does this prove that the  
> message came from a given system or is read by a given system, or  
> both?) or signs using its own private key. I also didn't see any  
> attention given to the process of changing keys, which will be an  
> issue. I further see no attention to threats at the Transport,  
> Network, or Data Link layers. In an IEEE 802.15.4g network such as  
> suggested by Zigbee, if I wanted to attack the system, I would  
> either generate a high power radio signal to drown out communication  
> or intercept/interdict exchanges on the "wire". I see no attention  
> to those issues.
>
> The thing I find most surprising is that it focuses not on TCP/UDP  
> over IPv4/IPv6, but on the use of the ANSI C12.19 and C12.22  
> standards, which are an application, and are in the January  
> standards document downgraded from "mandatory" to "we really aught  
> to think about these". I frankly think the industry would be better  
> served with a NetConf exchange of XML objects using an appropriate  
> schema, perhaps that suggested by OASYS.
>

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