Subject: Re: [smartpowerdir] Heads Up: Need info on Release 1 standards / expected standards coming out of PAPs

From: Fred Baker <[email-masked]>
Date: Sat, 26 Jun 2010 21:53:06 -0700

Folks:

David is asking for a set of RFCs to include in the next iteration of NIST standards for the Smart Grid. Does anyone have a problem with or proposed changes to the following list?

http://www.ietf.org/rfc/rfc0768.txt
0768 User Datagram Protocol. J. Postel. August 1980. (Format: TXT=5896
     bytes) (Also STD0006) (Status: STANDARD)

http://www.ietf.org/rfc/rfc0791.txt
0791 Internet Protocol. J. Postel. September 1981. (Format: TXT=97779
     bytes) (Obsoletes RFC0760) (Updated by RFC1349) (Also STD0005)
     (Status: STANDARD)

http://www.ietf.org/rfc/rfc0792.txt
0792 Internet Control Message Protocol. J. Postel. September 1981.
     (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950,
     RFC4884) (Also STD0005) (Status: STANDARD)

http://www.ietf.org/rfc/rfc0793.txt
0793 Transmission Control Protocol. J. Postel. September 1981.
     (Format: TXT=172710 bytes) (Updated by RFC1122, RFC3168) (Also
     STD0007) (Status: STANDARD)

http://www.ietf.org/rfc/rfc2460.txt
2460 Internet Protocol, Version 6 (IPv6) Specification. S. Deering, R.
     Hinden. December 1998. (Format: TXT=85490 bytes) (Obsoletes RFC1883)
     (Updated by RFC5095, RFC5722, RFC5871) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4279.txt
4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS).
     P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160
     bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4301.txt
4301 Security Architecture for the Internet Protocol. S. Kent, K. Seo.
     December 2005. (Format: TXT=262123 bytes) (Obsoletes RFC2401)
     (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4347.txt
4347 Datagram Transport Layer Security. E. Rescorla, N. Modadugu.
     April 2006. (Format: TXT=56014 bytes) (Updated by RFC5746) (Status:
     PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4443.txt
4443 Internet Control Message Protocol (ICMPv6) for the Internet
     Protocol Version 6 (IPv6) Specification. A. Conta, S. Deering, M.
     Gupta, Ed.. March 2006. (Format: TXT=48969 bytes) (Obsoletes RFC2463)
     (Updates RFC2780) (Updated by RFC4884) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4785.txt
4785 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
     Transport Layer Security (TLS). U. Blumenthal, P. Goel. January 2007.
     (Format: TXT=9550 bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc5246.txt
5246 The Transport Layer Security (TLS) Protocol Version 1.2. T.
     Dierks, E. Rescorla. August 2008. (Format: TXT=222395 bytes)
     (Obsoletes RFC3268, RFC4346, RFC4366) (Updates RFC4492) (Updated by
     RFC5746, RFC5878) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc5281.txt
5281 Extensible Authentication Protocol Tunneled Transport Layer
     Security Authenticated Protocol Version 0 (EAP-TTLSv0). P. Funk, S.
     Blake-Wilson. August 2008. (Format: TXT=117059 bytes) (Status:
     INFORMATIONAL)

http://www.ietf.org/rfc/rfc5430.txt
5430 Suite B Profile for Transport Layer Security (TLS). M. Salter, E.
     Rescorla, R. Housley. March 2009. (Format: TXT=27586 bytes) (Status:
     INFORMATIONAL)

http://www.ietf.org/rfc/rfc5539.txt
5539 NETCONF over Transport Layer Security (TLS). M. Badra. May 2009.
     (Format: TXT=16073 bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc5763.txt
5763 Framework for Establishing a Secure Real-time Transport Protocol
     (SRTP) Security Context Using Datagram Transport Layer Security
     (DTLS). J. Fischl, H. Tschofenig, E. Rescorla. May 2010. (Format:
     TXT=81546 bytes) (Status: PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc5878.txt
5878 Transport Layer Security (TLS) Authorization Extensions. M.
     Brown, R. Housley. May 2010. (Format: TXT=44594 bytes) (Updates
     RFC5246) (Status: EXPERIMENTAL)

---

From: Vint Cerf <[email-masked]>
Date: Sun, 27 Jun 2010 05:49:21 -0400

should some form of broadcast or multicast be included (thinking about
wide propagation of pricing or demand status information)?

I know we haven't done much with either of these protocols but in the
context of either the SCADA environment or possibly the HAN, one might
imagine some convenience in not having to maintain a pt-pt connection
between the EMI and every device in the house?

v

---

From: Fred Baker <[email-masked]>
Date: Sun, 27 Jun 2010 04:17:20 -0700

Multicast is defined in both domains; however, as a transport, one could imagine

http://www.ietf.org/rfc/rfc5740.txt
5740 NACK-Oriented Reliable Multicast (NORM) Transport Protocol. B.
     Adamson, C. Bormann, M. Handley, J. Macker. November 2009. (Format:
     TXT=268831 bytes) (Obsoletes RFC3940) (Status: PROPOSED STANDARD)

Does that address your concerns?

What flies next is "what routing protocol..." I would imagine PIM, OSPF, IS-IS, RIPv2, AODV, or OLSR. The IETF is working on 6LowPAN and RPL but is done with neither. Your opinions?

>>     RFC5246) (Status: EXPERIMENTAL)

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

---

From: Vint Cerf <[email-masked]>
Date: Sun, 27 Jun 2010 07:26:11 -0400

Fred

Yes NORM seems a useful reference.

As to routing, that's a good question. Should we assume HaNs are stub
nets? We may need an IGP if several physical nets ae combined (eg
wired LAN and wireless).

V

On 6/27/10, Fred Baker <[email-masked]> wrote:
> What flies next is "what routing protocol..." I would imagine PIM, OSPF,
> IS-IS, RIPv2, AODV, or OLSR. The IETF is working on 6LowPAN and RPL but is
> done with neither. Your opinions?
>
>>> David is asking for a set of RFCs to include in the next iteration of
>>> NIST standards for the Smart Grid. Does anyone have a problem with or
>>> proposed changes to the following list?
>>>

-- 
Sent from my mobile device

---

From: Ralph Droms <[email-masked]>
Date: Sun, 27 Jun 2010 09:22:37 -0400

Depending on how far you want to go beyond IP routing, delivery and security:

http://www.ietf.org/rfc/rfc1035.txt
1035 Domain names - implementation and specification. P.V.
     Mockapetris. November 1987. (Format: TXT=125626 bytes) (Obsoletes
     RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348,
     RFC1876, RFC1982, RFC1995, RFC1996, RFC2065, RFC2136, RFC2181,
     RFC2137, RFC2308, RFC2535, RFC2845, RFC3425, RFC3658, RFC4033,
     RFC4034, RFC4035, RFC4343) (Also STD0013) (Status: STANDARD)

http://www.ietf.org/rfc/rfc2131.txt
2131 Dynamic Host Configuration Protocol. R. Droms. March 1997.
     (Format: TXT=113738 bytes) (Obsoletes RFC1541) (Updated by RFC3396,
     RFC4361, RFC5494) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc2132.txt
2132 DHCP Options and BOOTP Vendor Extensions. S. Alexander, R. Droms.
     March 1997. (Format: TXT=63670 bytes) (Obsoletes RFC1533) (Updated by
     RFC3442, RFC3942, RFC4361, RFC4833, RFC5494) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc3315.txt
3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms,
     Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003.
     (Format: TXT=231402 bytes) (Updated by RFC4361, RFC5494) (Status:
     PROPOSED STANDARD)

http://www.ietf.org/rfc/rfc4861.txt
4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E.
     Nordmark, W. Simpson, H. Soliman. September 2007. (Format: TXT=235106
     bytes) (Obsoletes RFC2461) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc4862.txt
4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten,
     T. Jinmei. September 2007. (Format: TXT=72482 bytes) (Obsoletes
     RFC2462) (Status: DRAFT STANDARD)

http://www.ietf.org/rfc/rfc5006.txt
5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong,
     Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format:
     TXT=26136 bytes) (Status: EXPERIMENTAL)
(Note: as you are likely aware, draft-ietf-6man-dns-options-bis-03 is Standards Track, defining ND options for a list of RDNSSs and a domain search list)

- Ralph

---

From: Russ Housley <[email-masked]>
Date: Sun, 27 Jun 2010 12:13:50 -0400

Why do you think RFC 5878 is needed here.  I'm only aware of two
implementations, and they use very different authorization data.

Russ

---

From: Vint Cerf <[email-masked]>
Date: Sun, 27 Jun 2010 14:45:41 -0400

David, et al,

perhaps it is appropriate for the Arch WG to suggest example stacks
drawm from the list??

v

On Sun, Jun 27, 2010 at 2:41 PM, Su, David H. <[email-masked]> wrote:
> To all,
> The long list make me think that to satisfy next week's reporting requirement for George, leaving the existing two entries, first one with a general statement "Internet Protocol Suite, including IPv6 and IPv4", and second one for Fred's core protocol document is sufficient for now.  What we need to add is the projected completion date of Fred's document.  I assume it will be an Information RFC, to be be completed by October 1, 2010. Is it reasonable?
>
> However, the long list of RFCs points to a problem I have.  FERC expects NIST to submit candidate standards for its rule making; it also expect justification on each standard and specify relevancy to smart grid by pointing to specific sections of the standard.  I don't know how to do this, and is looking for guidance from all of you. 1. Shall we submit anything at all? Does it mean anything to have a regulatory mandate for IP protocols? Or let the market place to determine the outcome is a better way?  2. If the answer is affirmative for submission, which one do we submit? Whatever we pick, I am afraid we'll miss something. May be Fred's core protocol document?
> David
>
>
>
> Dr. David H. Su
> Chief, Advanced Network Technologies Division
> Information Technology Laboratory
> National Institute of Standards and Technology
> 100 Bureau Drive, MS 8920
> Gaithersburg, MD 20899
> +1 301 975 6194
>
>
> -----Original Message-----
> From: Vint Cerf [mailto:[email-masked]]
> Sent: Sunday, June 27, 2010 5:49 AM
> To: Fred Baker
> Cc: Su, David H.; IETF SmartPower Directorate
> Subject: Re: [smartpowerdir] Heads Up: Need info on Release 1 standards / expected standards coming out of PAPs
>
> should some form of broadcast or multicast be included (thinking about wide propagation of pricing or demand status information)?
>
> I know we haven't done much with either of these protocols but in the context of either the SCADA environment or possibly the HAN, one might imagine some convenience in not having to maintain a pt-pt connection between the EMI and every device in the house?
>
> v
>
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 27 Jun 2010 15:24:20 -0700

The problem with submitting the core protocol document itself is that it is an internet draft, without an RFC number. I'm happy enough with Oct 1, but I think the real question here is what FERC wants.

The set I gave you is IPv4, IPv6, TCP, UDP, SCTP, NORM (a "reliable" multicast protocol, which is a protocol that improves the probability of delivery of multicast traffic), IPsec, and TLS/DTLS. To my mind, that is the set that should be normative; others may disagree with me.

From the IETF's perspective, I don't think we object to the Smart Grid using IPv4, as it does now in places, but we question the wisdom of that as a long term strategy. 

Others on the list may have other opinions...