Internet Protocols for the Smart Grid
RFC 6272

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

(Tim Polk) Discuss

Discuss (2011-03-03 for -)
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.
Comment (2011-03-03 for -)
No email
send info
technical comments:

While it is popular to complain about the security of the Internet,
solutions to many popular Internet security problems have already exist.
While it is popular to complain about the security of the Internet,
it is important to distinguish between attacks on protocols and
attacks on user (e.g., phishing).  Attacks on users are largely independent
of protocol details, reflecting interface design issues or user education
problems, and are out of scope for this document. Security problems with
Internet protocols are in scope, of course, and can often be mitigated
using existing security features already specified for the protocol, or
by leveraging the security services offered by other IETF protocols.


Append to the paragraph beginning "A number of mechanisms":

Another mechanism, specifically targeting the reset attack cited above,
provides authentication services in TCP itself to ensure that fake resets
are rejected.


   It is important to highlight that in addition to the mentioned
   security tools every protocol often comes with additional, often
   unique security considerations that are very unique to the specific
   domain that protocol operates in.
   It is important to highlight that in addition to the mentioned
   security tools every protocol often comes with additional, often
   unique security considerations that are very unique to the specific
   domain that protocol operates in.  Many protocols include features
   specifically designed to mitigate these protocol-specific risks.  In
   other cases, the security considerations will identify security-relevant
   services that are required from other network layers to achieve
   appropriate levels of security.


[Note: The TLS section talks about negotiating parameters as suites, but the
IKE section is silent.  The following suggestion would be more complete
and provide some parallelism.}

   For the former step the Internet Key Exchange protocol version 2
   (IKEv2 [RFC5996]) is the most recent edition of the standardized
    For the former step, the Internet Key Exchange protocol version 2
   (IKEv2 [RFC5996]) is the most recent edition of the standardized
   protocol.  IKE negotiates each of the cryptographic algorithms that
   will be used to protect the data independently, somewhat like
   selecting items a la carte.

3.1.2 penultimate paragraph:
Please append:
Since ESP can also provide authenctication services, most recent
protocol development making use of IPsec only specify use of ESP
and do not use AH.


Adding a reference to RFC 6090 in 3.1.3 would be good, e.g.
"The basic cryptogaphic mechanims for ECC have been documented
in RFC 6090." That could be added to the end of the 2nd last
para in 3.1.3.


CMS paragraph: Please append the following:
CMS has been leveraged to supply security services in a variety of
protocols, including secure email [RFC5751], key management [RFC5958]
and [RFC6031], and firmware updates [RFC4108].

Digitally signed XML paragraph: Please append the following:
Digitally signed XML is a good choice where applications natively
support XML encoded data.  

Section 3.7

What about email, ftp, http?  Do these have any application in this space?

4. (current page 36)

Firewalls are also common on end-hosts as well.  This may be worth a mention
in this section.


editorial comments:

s/can recursively subdivided/can be recursively subdivided/


s/takes security serious/takes security seriously/

s/provides recommendations how/provides recommendations on how/


s/are round/exist/

3. (last sentence)

s/such analyzes/such analysis/


s/we outline of/outline a/


first sentence:
s/The term/While the term/

second Para:
s/prior to access a/prior to accessing a/

(Jari Arkko) Yes

Comment (2011-03-03 for -)
No email
send info
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)

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

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.

(Adrian Farrel) Yes

Comment (2011-03-02 for -)
No email
send info
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.

(David Harrington) (was Discuss) Yes

(Russ Housley) Yes

(Dan Romascanu) (was Discuss) Yes

Comment (2011-03-03)
No email
send info
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

(Peter Saint-Andre) (was No Objection) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Lars Eggert) No Objection

Comment (2011-03-03 for -)
No email
send info
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, 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

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

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


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, 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/

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2011-03-03)
No email
send info
#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 in 2.2.2 where it talks about TCP attacks/counter measures?  Also maybe pointing to 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,