ANSI C12.22, IEEE 1703, and MC12.22 Transport Over IP
RFC 6142

Received changes through RFC Editor sync (changed abstract to 'This RFC provides a framework for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network.

This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working groups. It was created by participants in those groups, building on knowledge of several proprietary C12.22- over-IP implementations. The content of this document is an expression of a consensus aggregation of those implementations. This document is not an Internet Standards Track specification; it is published for informational purposes.')

[Ballot discuss]
Section 3.3 says:
  >
  > If a C12.22 IP Node is configured to accept IP broadcast and
  > multicast messages, it SHALL join the "All C1222 Nodes" multicast
  > group (see Section 2.6. IP Multicast), and SHALL use the default port
  > 1153.  In addition it SHALL accept IP Network directed or limited
  > (local scope) broadcast messages sent to port 1153.  Note that
  > successful communication using network directed broadcast requires
  > configuration of network routers, which by default are not supposed
  > to forward directed broadcasts as per RFC 2644 [19].
  >
  I interpret "not supposed to" as "SHOULD NOT". However, RFC 2644 says
  the following about routers:

      Directed Broadcast - a broadcast directed to the specified network
      prefix.  It MUST NOT be used as a source address.  A router MAY
      originate Network Directed Broadcast packets.  A router MAY have a
      configuration option to allow it to receive directed broadcast
      packets, however this option MUST be disabled by default, and thus
      the router MUST NOT receive Network Directed Broadcast packets
      unless specifically configured by the end user.

  and:

      A router MAY have an option to enable receiving network-prefix-
      directed broadcasts on an interface and MAY have an option to
      enable forwarding network-prefix-directed broadcasts.  These
      options MUST default to blocking receipt and blocking forwarding
      of network-prefix-directed broadcasts.

  Given the apparent contradiction, it seems that more needs to be
  said about the implications for routers that serve the C12.22 IP
  Node.

  Section 6.2 (Informative References) says:
  >
  > [Will be added as appropriate]
  >
  Please fill them in or remove this section.

[Ballot discuss]
I realize this is a  late discuss, but I understand that the document shepherd does not consider this document ready for IESG evaluation.  I am holding this discuss until the shepherd is happy as a process issue.

[Ballot comment]
Section 3.4.1., paragraph 1:
>    Service, of ANSI C12.22, this specification RECOMMENDEDS that the

  Rephrase RECOMMENDEDS with a valid RFC2119 term ("is RECOMMENDED").

[Ballot discuss]
[I'm moving one part of my comment to a discuss - I had somehow convinced
myself that this document was an Independent Submission, which it is not.]

Section 3.4.2., paragraph 1:
>    When sending a large C12.22 Message via UDP, whereby the ACSE PDU
>    size exceeds the UDP datagram maximum data length (65527 bytes), the
>    initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance
>    with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such
>    that each APDU segment fits within the UDP data field.

  You really want to use fragmentation already when the payload exceeds
  the path MTU, and not only when it is larger than the maximum possible
  UDP message size. See RFC5405 Section 3.2.

  More generally, however, this document is completely silent about how
  C12.22 communication is congestion-controlled when transmitted over
  UDP, what sort of retransmission schemes are used, etc. I don't think
  we can publish an IETF document without this. (See RFC2914 and RFC5405.)
  Do some C12.22 standards specify this behavior?

[Ballot comment]
I think this is an important specification and in relatively OK
shape technically, and we should move it forward. A couple of comments,
however:

First, I agree with Lars Eggert's discuss on 63K UDP packets and
fragmentation.

Second, I think the document is quite hard to read. Its partially that
I don't have C12.12 background and partially because of the writing
style and partially because much of the big picture is missing.

[Ballot discuss]
The document currently has an Informative References section with null content but marked as [Will be added as appropriate]. I would like the appropriate documents to be added to this section or the section taken out before approving this document.

[Ballot discuss]
Can IANA please confirm that the appropriate expert reviews have been made for the codepoint allocations:
- IPv6 multicast address allocation
- IPv4 multicast address (or is this asking for IESG approval?)

[Ballot discuss]
AES-128/EAX is the algorithm, key size, and mode used in the ANSI C12.22 security mechanism.  I do not have access to this document nor did the secdir reviewer.  Therefore, I have many questions about this mechanism:

1) As far as I can tell, this mode has not been specified before in an RFC so I've got to ask if the CFRG has ever considered it?

2) Why are we using a new mode as opposed to an existing/approved mode?

3) Is only one key size/mode supported?  Normally, I'd like to see one MUST and one SHOULD in case the MUST is shown to be insecure.

4) With the layering of C12.22 on top of IP networks may warrant a discussion about potential methods  to enhance C12.22 security? For example, could privacy be enhanced beyond what C12.22 offers through use of a transport network's confidentiality services?

[Ballot discuss]
Section 3.3 says:
  >
  > If a C12.22 IP Node is configured to accept IP broadcast and
  > multicast messages, it SHALL join the "All C1222 Nodes" multicast
  > group (see Section 2.6. IP Multicast), and SHALL use the default port
  > 1153.  In addition it SHALL accept IP Network directed or limited
  > (local scope) broadcast messages sent to port 1153.  Note that
  > successful communication using network directed broadcast requires
  > configuration of network routers, which by default are not supposed
  > to forward directed broadcasts as per RFC 2644 [19].
  >
  I interpret "not supposed to" as "SHOULD NOT". However, RFC 2644 says
  the following about routers:

      Directed Broadcast - a broadcast directed to the specified network
      prefix.  It MUST NOT be used as a source address.  A router MAY
      originate Network Directed Broadcast packets.  A router MAY have a
      configuration option to allow it to receive directed broadcast
      packets, however this option MUST be disabled by default, and thus
      the router MUST NOT receive Network Directed Broadcast packets
      unless specifically configured by the end user.

  and:

      A router MAY have an option to enable receiving network-prefix-
      directed broadcasts on an interface and MAY have an option to
      enable forwarding network-prefix-directed broadcasts.  These
      options MUST default to blocking receipt and blocking forwarding
      of network-prefix-directed broadcasts.

  Given the apparent contradiction, it seems that more needs to be
  said about the implications for routers that serve the C12.22 IP
  Node.

  Section 6.2 (Informative References) says:
  >
  > [Will be added as appropriate]
  >
  Please fill them in or remove this section.

[Ballot discuss]
I find this specification confusing because there is insufficient explanation of how the C1222 network interfaces to the IP network.

I find the TTL behavior described in Section 2.6 particularly confusing. Is there a TTL in the C1222 network, or only in the IP network? Does the TTL monotonically decrease? The TTL seems to need to be set to critical value, and it's not clear how this is know, or whether in needs to be changed during the operational lifetime of the network.

[Ballot comment]
Section 3.4.1., paragraph 1:
>    Service, of ANSI C12.22, this specification RECOMMENDEDS that the

  Rephrase RECOMMENDEDS with a valid RFC2119 term ("is RECOMMENDED").


Section 3.4.2., paragraph 1:
>    When sending a large C12.22 Message via UDP, whereby the ACSE PDU
>    size exceeds the UDP datagram maximum data length (65527 bytes), the
>    initiating C12.22 IP Node SHALL segment the ACSE PDU in accordance
>    with ANSI C12.22 Datagram Segmentation and Reassembly algorithm, such
>    that each APDU segment fits within the UDP data field.

  You really want to use fragmentation already when the payload exceeds
  the path MTU, and not only when it is larger than the maximum possible
  UDP message size. See RFC5405 Section 3.2.

[Ballot discuss]
AES-128/EAX is the algorithm, key size, and mode used in the ANSI C12.22 security mechanism.  I do not have access to this document nor did the secdir reviewer.  Therefore, I have many questions about this mechanism:

1) As far as I can tell, this mode has not been specified before in an RFC so I've got to ask if the CFRG has ever considered it?

2) Why are we using a new mode as opposed to an existing/approved mode?

3) Is only one key size/mode supported?  Normally, I'd like to see one MUST and one SHOULD in case the MUST is shown to be insecure.

4) With the layering of C12.22 on top of IP networks may warrant a discussion about potential methods  to enhance C12.22 security? For example, could privacy be enhanced beyond what C12.22 offers through use of a transport network's confidentiality services?

IANA comments:

ACTION 1:

Upon approval of this document, IANA will make the following
changes in the "PORT NUMBERS" registry located at
http://www.iana.org/assignments/port-numbers

OLD:

Keyword Decimal Description References
------- ------- ----------- ----------
c1222-acse 1153/tcp ANSI C12.22 Port
c1222-acse 1153/udp ANSI C12.22 Port

NEW:

Keyword Decimal Description References
------- ------- ----------- ----------
c1222-acse 1153/tcp ANSI C12.22 Port [RFC-c1222-transport-over-ip-03]
c1222-acse 1153/udp ANSI C12.22 Port [RFC-c1222-transport-over-ip-03]


ACTION 2:

Upon approval of this document, IANA will make the following
changes in the "IPv4 Multicast Address Space Registry" at
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml
sub-registry "AD-HOC Block I (224.0.2.0 - 224.0.255.255)"

OLD:

Address(s) | Description | Reference | Date Registered | Last Reviewed
224.0.2.4 | All C1222 Nodes | [draft-c1222-transport-over-ip] | 2009-08-28 |

NEW:
Address(s) | Description | Reference | Date Registered | Last Reviewed
224.0.2.4 | All C1222 Nodes | [RFC-c1222-transport-over-ip-03] |
2009-08-28 |


ACTION 3:

Upon approval of this document, IANA will make the following
changes in the "IPv6 Multicast Address Space Registry" located at
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
sub-registry "Variable Scope Multicast Addresses"

OLD:
Address(s) | Description | Reference | Date Registered | Last Reviewed
FF0X:0:0:0:0:0:0:204 | All C1222 Nodes | [draft-c1222-transport-over-ip]
| 2009-08-28 |

NEW:
Address(s) | Description | Reference | Date Registered | Last Reviewed
FF0X:0:0:0:0:0:0:204 | All C1222 Nodes |
[RFC-c1222-transport-over-ip-03] | 2009-08-28 |