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

[Phil Roberts <[e-mail]>]

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:
> 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
> ------------------------------------------------------------------------
>
> _______________________________________________
> smartpower-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/smartpower-interest