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

["Koodli, Rajeev" <[e-mail]>]

 

-----Original Message-----
From: Koodli, Rajeev 
Sent: Wednesday, February 17, 2010 6:13 PM
To: '[e-mail]'
Cc: '[e-mail]'
Subject: RE: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009


Hi,

On the topic of addressing (end of section 1):

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

This is a good example to illustrate an instance of "mobility".

However,

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

equates IPv6 simply to private IPv4 management, which has not been done
by providers (at least in the US) up until now. And, it (perhaps
inadvertently) assumes that you could manage roaming users with re-used
private addresses. Managing a roaming user's session with non-unique
private IPv4 is *way* different from what we can easily do with IPv6. 
 
I reckon when scale and mobility are in question, the case for IPv6 can
be made better in the document.

-Rajeev
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Fred 
> Baker
> Sent: Wednesday, February 17, 2010 7:08 AM
> To: Multiple recipients of list
> Subject: NIST_PAP_01-IP_in_Smart_Grid_v.1.0-Oct_30th_2009
> 
> 
> 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.
> 
>