Skip to main content

Internet Protocols for the Smart Grid
RFC 6272

Discuss


Yes

(David Harrington)
(Peter Saint-Andre)
(Russ Housley)

No Objection

(Gonzalo Camarillo)
(Robert Sparks)
(Stewart Bryant)

Note: This ballot was opened for revision 15 and is now closed.

Lars Eggert
No Objection
Comment (2011-03-03)
None of the comments below taken alone is discuss-worthy, but I do think at least several of them should really be addressed.

Section 2.1.2., paragraph 3:
>    For example, TCP will
>    reduce rate to avoid loss, while DCCP accepts some level of loss if
>    necessary to maintain timeliness.

  TCP doesn't really reduce its rate to avoid loss - it uses loss as an
  indication for congestion, and basic congestion control principles
  mandate a rate reduction. DCCP does the same - the difference is that
  DCCP will not bother to retransmit lost data while TCP will.


Section 3.2.2.3., paragraph 3:
>    In that research, the IETF imposed guidelines [RFC2357] on the
>    research community regarding what was desirable.  Important results
>    from that research include a number of papers and several proprietary
>    protocols including some that have been used in support of business
>    operations.  RFCs in the area include The Use of Forward Error
>    Correction (FEC) in Reliable Multicast [RFC3453], the Negative-
>    acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
>    [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
>    [RFC4410].  These are considered experimental.

  This section has outdated information. NORM is now PS (RFC 5401), and
  FLUTE is almost there (IETF LC of draft-ietf-rmt-flute-revised is
  imminent). Reliable multicast is not experimental anymore.


Section 3.3.2., paragraph 2:
>    it delivers data to its peer and provides acknowledgement to the
>    sender, or it dies trying.  It has extensions for Congestion Control
>    [RFC5681] and Explicit Congestion Notification [RFC3168].

  As well as many other extensions - it may be useful to cite RFC 4614
  here.


Section 3.3.2., paragraph 3:
>    For message-stream interfaces, we generally use the ISO
>    Transport Service on TCP [RFC1006][RFC2126] in the application.

  Who is "we"? Is anyone really using RFC1006 and RFC2126?


Section 3.3.2., paragraph 5:
>    Finally, note that TCP has been the subject of ongoing research and
>    development since it was written.  The End to End research group has
>    published a Roadmap for TCP Specification Documents [RFC4614] to
>    capture this history, to guide TCP implementors, and provide context
>    for TCP researchers.

  RFC 4614 did not come out of end-to-end, it was a WG document in TCPM.
  And while it does capture some of the history and research aspects,
  the motivation was very much to be a "start reading here" document for
  implementors, similar in spirit to this I-D.


Section 3.6.2., paragraph 8:
>    The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is
>    being developed in IETF with these goals in mind.

  I'm surprised to see that COAP is only mentioned under resource
  discovery. While that's one aspect of it, the broader aspect is as an
  application/transport protocol for constraint environments. IMO it
  would make more sense to discuss COAP under Section 3.3 or 3.3.1.


Section 4., paragraph 0:
> 4.  A simplified view of the business architecture

  At least to my mind, it would be a bit more logical to see this
  section merged into Section 2 or following it. (Also, it'd be nice to
  replace domain names and IP addresses in this section with ones from
  the "example" spaces.)


Section 5., paragraph 1:
>    This memo asks the IANA for no new parameters.

  Although this document makes no requests from IANA, I wonder if the
  smartgrid guys know about the role that IANA plays in the
  standardization and administration of the IPS. Is there an IANA
  overview document that you could cite here for them to read?


Section 8., paragraph 0:
> 8.  References

  Is there a logic to the split between normative and informative
  references?


Appendix A., paragraph 1:
>    This appendix provides a worked example of the use of the Internet
>    Protocol Suite in a network such as the Smart Grid's Advanced
>    Metering Infrastructure (AMI).  There are several possible models.

  I don't think this example is worked out enough to illustrate how the
  IPS can be applied here. There's a little bit of text about layer 3,
  and nothing at all about higher layers. I wonder if this material
  would be better split off into a standalone document for further
  development.

---

Section 2.2., paragraph 1:
>    solutions to many Internet security problems have already exist.

  Nit: s/have//


Section 2.2.1., paragraph 3:
>    For wirless transmission technologies eavesdropping on the

  Nit: s/wirless/wireless/


Section 3.2.3.1., paragraph 1:
>    Autoconfiguation enables various different models of network

  Nit: s/Autoconfiguation/Autoconfiguration/


Section 802.11, paragraph 0:
>    networks between various sensors in the home (e.g., betweeen the

  Nit: s/betweeen/between/
Tim Polk Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2011-03-03)
Two actionable discusses, one discuss-discuss:

Actionable 1: Please add a brief section 3.1.5 Key Management Infrastructures to cover PKI (PKIX) and Kerberos.
These are a very important building block in the security toolbox.  I would suggest mentioning the DANE work in this
section as well.

Actionable 2: Please add a brief section 3.1.6 secure shell.  This is another and widely used key building block.

Discuss-discuss: I would have expected to see some discussion of SRTP and SRTCP, but neither RTP nor RTCP
is mentioned.  Was there a specific decision not to include these protocols?  If so, excluding SRTP and SRTCP
makes perfect sense.
Adrian Farrel Former IESG member
Yes
Yes (2011-03-02)
Fine work.

I should have liked to see some forward reference to the Appendix from early in the document since (I assume) the readers will find the Appendix quite useful and (although it is mentioned in the ToC) there is no other hint that it is there.
Dan Romascanu Former IESG member
(was Discuss) Yes
Yes (2011-03-03)
1. [SmartGrid] - I am unconfortable to providing wikipedia references - not because I do not trust the principle of shared wisdom, but because they are unstable to my taste even for Informational References. If there is really nothing else around (even not from NIST?) I wouls suggest that at least we provide together with the reference a date when the quote was extracted from the wikipedia article
David Harrington Former IESG member
(was Discuss) Yes
Yes ()

                            
Jari Arkko Former IESG member
Yes
Yes (2011-03-03)
This is a very well written document. Thank you.

Just a couple of comments that you may consider at your own choosing.

There's a lot of technical material in this draft. I might have wanted to see a bit of business arguments at the beginning as well, e.g., why its useful to employ tools that are wide use, have open source implementations, can be used for multiple purposes, etc.

The document says:

   IPv6 neighbors identify each other's addresses using either Neighbor
   Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)
   [RFC3971].

Perhaps this would be better phrased as "... Neighbor Discovery (ND) [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to secure these operations."

Also, in Section 2.3.2:

   While the IP Protocol Suite does not have specific solutions for
   secure provisioning and configuration, these problems have been
   solved using IP protocols in specifications such as DOCSIS 3.0
   [SP-MULPIv3.0].

Not sure if this matches what was later said about SEND. Id prefer to say "... has lmited support secure provisioning and ..." Or did you mean to say "... for security provisioning"?

In Section 3.2.6. "Adaptation to lower layer networks and link layer protocols" and elsewhere 802.15.4
links are mentioned. As someone who has had cellular modems for my utility metering purposes
for five years, I wonder if you could have mentioned cellular link layers as well.

Peter Saint-Andre Former IESG member
(was No Objection) Yes
Yes (2011-03-15)

                            
Russ Housley Former IESG member
Yes
Yes ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2011-03-03)
#1) Politics layer is missing from Figure 1 ;)

#2) <nit alert>r/"host./"host."</nit alert>

#3) Could we point to SNMPv3 instead of v1? (i.e., something that's not historic)

#4) Is it worth mention HIP at all or the concept of splitting the identifier and locator?  It's experimental so maybe not.

#5) Is it worth adding an informative reference to https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-security/ in 2.2.2 where it talks about TCP attacks/counter measures?  Also maybe pointing to https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-security/ for IP attacks/counter measures would be helpful.

#6) Section 3.1.1: can we also add EAP-TLS:

   For access to remote
   networks, such as enterprise networks, the ability to utilize EAP
   within IKEv2 [RFC5996] and within TLS [RFC5216] have also
   been developed.

#7) While the Suite B IPsec profiles are near and dear to my heart, I'm not sure they need to be included in Sec 3.1.2.

#8) Sec 3.1.3: It's probably worth noting that TLS supports hop-by-hop security and depending on the architecture this might not be end-to-end (i.e., TLS isn't one size fits all).

#9) Sec 3.1.4: for truth in advertising:

  The CMS can support a variety of
   architectures for key management included: certificate-based key
   management, such as the one
   defined by the PKIX (Public Key Infrastructure using X.509) working
   group [RFC5280], or symmetric key management.

#10) Sec 3.1.4: Should also add that a variety of algorithms are supported:

  CMS supports a number of algorithms: RSA, DSA, DH, ECDSA,
   and ECDH as well as the SHA family of algorithms.


#11) Sections 3.1.2-3.1.4: When renaming 3.1.4 to "Application Security" makes me think that 3.1.2 should be called "Network Security" and 3.1.3 should be called "Transport Security".  Then put SSH in 3.1.3 (maybe no need for a new 3.1.6 as Tim suggests).  Could have two subsections.

#12) I think this needs to be updated:

  Note that since IPv4 free pool (the pool of available, unallocated
   IPv4 addresses) is almost exhausted,
Stewart Bryant Former IESG member
No Objection
No Objection ()