NACK-Oriented Reliable Multicast (NORM) Transport Protocol
draft-ietf-rmt-pi-norm-revised-14

[Ballot comment]
General comments:
1) the use of the word "authentication": Unfortunately, the IPsec docs use the word authentication for 2 separate types of security protection: peer authentication and integrity-protection. This doc does also, and it's not always clear which type they're referring to.

2) The Authentication Header (AH) is referred to in the doc as "AF" instead of "AH".

3) Since NORM can be used with NAT, the doc should mention someplace that AH is not compatible with NAT.

4) The introduction states that NORM allows for "operation with minimal a priori coordination among senders and receivers" - IPsec would obviously impose additional requirements for communication/coordination beforehand. In addition, the doc allows for numerous alternative options (e.g., the EXT_AUTH vs. IPsec; numerous multicast key management protocols). Since the doc does not specify how the peers would agree on these choices, this represents additional "a priori" choices that would have to be agreed upon beforehand in some unspecified manner.

Section 7: Security Considerations

1) per-session keys: Do NORM sessions share IPsec SAs? If not, this shouldn't be a problem. If they do share SAs, who assigns and checks the "instance_id"? It's not a standard IPsec feature.

2) recommendations for app-level integrity-checking of data: This would normally be provided by IPsec, but NORM's non-standard use of SAs (keys shared by >2 peers) would negate this protection, necessitating app-level integrity checks.

Section 7.1.1: IPsec Approach

1) This section recommends use of the IPsec ESP SA "with the option for data origination." I assume they mean data origin authentication. This presents several challenges:

      a) In a transport-mode ESP SA, the sender address is not protected. If automated key management is used, this protection is indirectly provided, since the SA is established between 2 authenticated peers; use of the secret symmetric keys constitutes proof that the sender is the known peer. Manual establishment of keys with a transport-mode ESP SA would not provide data origin authentication.
     
      b) If keys are shared among >2 peers, data origin authentication is problematic, since any peer can masquerade as any other peer.

      c) How would NORM handle updating keys when members leave the group? This is not specificed anywhere. Allowing ex-members to possess keys would further compromise security, since you wouldn't even have the assurance that a sender was a current member of the group.

2) The SA used by receivers to send data to the sender is referred to a a unicast SA. However, as defined in this doc, it is not what IPsec normally refers to as a unicast SA. An IPsec unicast SA is between 2 peers, and can therefore provide replay protection, data origin authentication and integrity protection. The NORM "unicast" SA is a single SA that protects traffic sent by multiple receivers to the single sender. Replay protection is not possible, since you can't coordinate a replay counter among multiple senders. Also, all of the problems mentioned above for an SA with >2 parties would also apply here.

3) This section refers to an IPsec implementation that manages its replay protection on a per-source basis. I could be wrong, but this sounds like non-standard IPsec to me. I'm not sure such implementations exist, but even if they do, this could be an interop problem.

4) This section also suggests that NORM could maintain per-source sequence state. Once again, how would the peers know that this feature was enabled?

5) It is suggested that, for small groups, many-to-many IPsec protection would be possible. This should be further specified. Does this mean that each node would have 1 outbound multicast SA between it and all other nodes (the "sender" SA) and 1 inbound "unicast" SA from all other nodes to itself (the "receiver" SA)?

6) The last paragraph is this section mentions various alternative methods for retrieving or negotiating keys. Again, how would this be determined in an interoperable manner?

Section 7.1.2.3: Key Management

Since manual keying is allowed, somewhere in the Security Requirements it should mention that care is needed in selecting algorithms - some algorithms (e.g., counter-mode) are not suitable for use with manual keys.


Section 7.1.2.4: Security Policy

This section mentions encryption keys. This also applies to integrity-protection (a.k.a. authentication) keys.

[Ballot discuss]
Since this document has not been on a telechat yet, I decided it was acceptable (in my mind)
to move from No Objection to Discuss.

I do not believe the "Baseline Secure NORM Operation" described in section 7.1 is sufficient
for interoperable implementations.  The document does not indicate whether IPsec version
2 or 3 should be supported, or the appropriate version of IKE.  (The normative references
are for IPsec version 3, so perhaps the first decision has been made?)  Identifying three
automated key management schemes (GDOI, GSAKMP, and MIKEY) in 7.1.2.3 is helpful, but
an implementation is forced to support all three for interoperability.  Is there a reason that
we can't give more specific guidance?

I am also concerned that some of the changes could preclude use of off-the-shelf IPsec.
In particular, non-standard use of IPsec SAs may pose a problem.

I requested another review from an IETFer with more IPsec expertise.  My move to Discuss
was motivated by her response.  Her detailed review has been appended  as comments,
since I have not concluded which specific issues could be blocking.  I would like to see
feedback from the authors before I come to that conclusion.
--------

[Ballot discuss]
I wanted to talk about this on the IESG call today before
we approve the document:

The recommendations for generating source_id values are fairly
unspecific. Is there a need to specify something which is mandatory
to implement, and is there a need to clearly say what to do with
IPv6 addresses as well?

[Ballot comment]
I am entering this as a Comment since I missed this on my first review, but I would have
strongly considered a DIscuss if this was my initial review.

I do not believe the "Baseline Secure NORM Operation" described in section 7.1 is sufficient
for interoperable implementations.  The document does not indicate whether IPsec version
2 or 3 should be supported, or the appropriate version of IKE.  (The normative references
are for IPsec version 3, so perhaps the first decision has been made?)  Identifying three
automated key management schemes (GDOI, GSAKMP, and MIKEY) in 7.1.2.3 is helpful, but
an implementation is forced to support all three for interoperability.  Is there a reason that
we can't give more specific guidance?

BTW, I have requested another review from an IETFer with more IPsec expertise.  I will revise
my comment yet again if she identifies further interoperability problems...
add additional points

[Ballot comment]
Editorial from the Gen-ART Review by Vijay Gurbani:

  1) In S8, you may want to expand the acronym "DBS" (I think
    you mean Direct Broadcast Satellite, but I am not sure.)

  2) In S10, there is a phrase, "(and these are not Negative)" --
    is this a leftover from previous edit sessions?

[Ballot discuss]
This DISCUSS is trivial and can be cleared quickly.

I'm confused about the tense used in the IANA requirements section.  http://www.iana.org/assignments/norm-parameters doesn't exist now.  Is the wording in IANA requirements the final wording to be published, after IANA has created the appropriate registries?

[Ballot discuss]
I'm confused about the tense used in the IANA requirements section.  http://www.iana.org/assignments/norm-parameters doesn't exist now.  Is the wording in IANA requirements the final wording to be published, after IANA has created the appropriate registries?

[Ballot discuss]
I am still reading this document which seems well written, but it is not easy reading. I do want however to ask two questions and in case these remain the only questions I plan to clear my DISCUSS at the meeting or when I get clarifying answers.

1. What are the conclusions of the experiment that led the WG decide that it is appropriate to advance this document from the Experimental Status of RFC 3940 to Proposed Standard? The list of changes from RFC 3940 does not provide enough information on this respect. How widely was the protocol deployed? what are the conclusions about its scalability and reliability?

2. How is this protocol and in general the technology defined in the RMT working group going to be managed? This is related somehow to the first question, I would expect that around a protocol that was at Experimental for a number of years and is now going to Proposed standard have some information  gathered about its operational model and impact, and about the management methods and proocols that would be suitable to be used for various management operations.

[Ballot discuss]
I am still reading this document which seems well written, but it is not easy reading. I do want however to ask two questions and in case these remain the only questions I plan to clear my DISCUSS at the meeting or when I get clarifying answers.

1. What are the conclusions of the experiment that led the WG decide that it is appropriate to advance this document from the Experimental Status of RFC 3940 to Proposed Standard? The list of changes from RFC 3940 does not provide enough information on this respect. How widely was the protocol deployed? what are the conclusions about its scalability and reliability?

2. How is this protocol and in general the technology defined in the RMT working group going to be managed? This is related somehow to the first question, I would expect that around a protocol that was at Experimental for a number of years and is now going to Proposed standard have some information  gathered about its operational model and impact, and about the management that would be suitable to be used for various management operations.

[Ballot discuss]
Pretty thorough and easy-to-read (shame it is so long :-)

Appreciate the authors and WG going along the Experimental track and then advancing the work.

Discuss issues are relatively minor and should be simple to resolve.

---

The fact that the protocol specified is a *transport* protocol really
needs to be reflected in the document title. Viz:
        NACK-Oriented Reliable Multicast Transport Protocol
This may appear trivial (in which case, why not fix it? :-) but is, I
think criticial to disambiguate it from underlying multicast protocols.
(And, yes, I know that 3940 didn't say "transport" in the title.)

---

It would be nice if idnits was run cleanly before drafts are presented
for IESG review. In this case I see...
  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
    'SHOULD', or 'RECOMMENDED' is not an accepted usage according to
    RFC 2119.  Please use uppercase 'NOT' together with RFC 2119
    keywords (if that is what you mean).
(which is easliy fixed) and
  ** Downref: Normative reference to an Experimental RFC: RFC 4654
which I see *was* called out in IETF last call, but is not mentioned
in the ballot write-up. What is the conclusion of the last call, and
why does the WG and sponsoring author consider that we should accept
this downref?

---

Section 4.1
Please include a definition of the hel field in the variable-length
NORM header extension. Words, bytes, bits? Include het and hel?

This might help explain why the hel is a reserved field for het >= 128
Although, I suspect that you could use hel = 1 for these cases and
slightly simplify the processing for the receiving node.

---

Please discuss...
Suppose a receiver is subverted (or mis-implemented) so that it sends
NACK messages. Could this damage receipt for other receivers (sender's
buffers get full, sender holds off transmitting to the tree until
errant receiver has caught up, etc.)?
If so, shoud the security section discuss the policy for alerting or
pruning such receivers?

[Ballot comment]
I find language like "is designed to" rather timid! If you want this
to be a standard you need to be a bit more robust in your assertions.

---

The term NormNode is used in section 1.2 before its definition in
section 2.

---

Section 4.1
"source id"
s/the host IP/the host IPv4/

---

There are several uses of capitalised non-2119 language. No law against
this AFAIK, but may be helpful to convert to 2119. For example...
  *IMPORTANT NOTE: The "payload_len", "payload_msg_start" and
  "payload_offset" fields are present ONLY for objects of type
  "NORM_OBJECT_STREAM".
Could read
  *IMPORTANT NOTE: The "payload_len", "payload_msg_start" and
  "payload_offset" fields MUST NOT be present in any object except
  those of type "NORM_OBJECT_STREAM".

---

It would be really helpful if you collected together in a new section
all of the configurable elements of the protocol (timers, policies,
etc.).

---

IANA questions/comments:

- Do you want/need a registry for NORM Message Types?

- Do you want/need a registry for NORM_DATA Flags?

- Do you want/need a registry for NORM_CMD(CC) Flags?

- Do you want/need a registry for NORM_CMD(REPAIR_ADV) Flags?

- Do you want/need a registry for NORM_ACK messages?

- Do you want/need a registry for NORM_NACK form field?

- Do you want/need a registry for NORM_NACK flags?


Action 1 (Section 7.1.1):

Upon approval of this document, IANA will create the following
registry at
located at http://www.iana.org/assignments/norm-parameters

Registry NameL NORM Header Extension Types
Registration Procedures: Specification Required
Initial contents of this sub-registry will be:

+-------+------------+------------------------------+
| Value | Name | Reference |
+-------+------------+------------------------------+
| 0 | Unassigned | |
| 1 | "EXT_AUTH" | [RFC-rmt-pi-norm-revised-11] |
| 2 | Unassigned | |
| 3 | "EXT_CC" | [RFC-rmt-pi-norm-revised-11] |
| 4-63 | Unassigned | |
| 64 | "EXT_FTI" | [RFC-rmt-pi-norm-revised-11] |
| 65-127| Unassigned | |
| 128 | "EXT_RATE" | [RFC-rmt-pi-norm-revised-11] |
|129-255| Unassigned | |
+-------+------------+------------------------------+


Action 2 (Section 7.1.2):

Upon approval of this document, IANA will create the following
registry at
located at http://www.iana.org/assignments/norm-parameters

Registry Name: NORM Stream Control Codes
Registration Procedures: Specification Required
Initial contents of this sub-registry will be:

+--------+-------------------+------------------------------+
| Value | Name | Reference |
+--------+-------------------+------------------------------+
| 0 | "NORM_STREAM_END" | [RFC-rmt-pi-norm-revised-11] |
|1-65535 | Unassigned | [RFC-rmt-pi-norm-revised-11] |
+--------+-------------------+------------------------------+


Action 3 (Section 7.1.3):

Upon approval of this document, IANA will create the following
registry at
located at http://www.iana.org/assignments/norm-parameters

Registry Name: NORM_CMD Message Sub-types
Registration Procedures: Specification Required
Initial contents of this sub-registry will be:

+-------+-------------------------+------------------------------+
| Value | Name | Reference |
+-------+-------------------------+------------------------------+
| 0 | Reserved | [RFC-rmt-pi-norm-revised-11] |
| 1 | "NORM_CMD(FLUSH)" | [RFC-rmt-pi-norm-revised-11] |
| 2 | "NORM_CMD(EOT)" | [RFC-rmt-pi-norm-revised-11] |
| 3 | "NORM_CMD(SQUELCH)" | [RFC-rmt-pi-norm-revised-11] |
| 4 | "NORM_CMD(CC)" | [RFC-rmt-pi-norm-revised-11] |
| 5 | "NORM_CMD(REPAIR_ADV)" | [RFC-rmt-pi-norm-revised-11] |
| 6 | "NORM_CMD(ACK_REQ)" | [RFC-rmt-pi-norm-revised-11] |
| 7 | "NORM_CMD(APPLICATION)" | [RFC-rmt-pi-norm-revised-11] |
| 8-255 | Unassigned
+-------+-------------------------+------------------------------+


We understand the above to be the only IANA Actions for this document.

IANA comments/questions:

- Where is the registry where we need to define "ietf:rmt:norm"?

- Can you verify that value 0 is available for assignment?

- For extensibility purposes do you want to create registries for
your various NORM Commands and Command Messages?

- The EXT_AUTH extention is not mentioned until the Security
Considerations in Section 6 and never fully defined. Even though
that section says it's out of scope, it's probably not appropriate
to define it there.

Upon approval of this document, IANA will create the following registry at
http://www.iana.org/assignments/rmt-fec-parameters

Registry Name: NORM Header Extension Types
ietf:rmt:norm:extensions
Registration Procedures: Specification Required

Initial contents of this sub-registry will be:

+-------+------------+-----------------------------+
| Value | Name | Reference |
+-------+------------+-----------------------------+
| 0 | Available | [RFC-rmt-pi-norm-revised-09 |
| 1 | "EXT_AUTH" | [RFC-rmt-pi-norm-revised-09 |
| 2 | Available | [RFC-rmt-pi-norm-revised-09 |
| 3 | "EXT_CC" | [RFC-rmt-pi-norm-revised-09 |
| 4-63 | Available | [RFC-rmt-pi-norm-revised-09 |
| 64 | "EXT_FTI" | [RFC-rmt-pi-norm-revised-09 |
| 65-127| Available | [RFC-rmt-pi-norm-revised-09 |
| 128 | "EXT_RATE" | [RFC-rmt-pi-norm-revised-09 |
|129-255| Available | [RFC-rmt-pi-norm-revised-09 |
+-------+------------+-----------------------------+

We understand the above to be the only IANA Action for this document.

Document Shepherd Write-Up for draft-ietf-rmt-pi-norm-revised-07
intended for publication in the "Proposed Standard" category.

This writeup complies with RFC 4858


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Lorenzo Vicisano, who has reviewed this  document and believes
it is ready for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review by key WG members.  The document has been reviewed by multiple WG members and has been updated to reflect their comments.  There are non unresolved issues.  The Experimental RFC3940 upon which this revision is based was thoroughly reviewed.  The differences between this revision and the original document are relatively minor.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No concerns.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No discontent of significant concern have been raised about this
document.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

The document satisfies all ID nits.  The document indicates its intended status
to be published as a Proposed Standard RFC.

draft-ietf-rmt-pi-norm-revised-07 is intended for publication in the
"Proposed Standard" category.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and informative. The
normative reference are in RFC published status. None of the normative
reference is a downward reference with the exception of the normative
reference to Experimental RFC 4654.  The RFC 4654 "building block" describes
the techniques and rationale for a "TCP-Friendly Multicast Congestion
Control" mechanism.  The NORM document cites a normative reference to this
document because it fully specifies, as part of its protocol specification,
a congestion control mechanism that applies the techniques described in RFC
4654.  However, note that because the NORM document _fully_ specifies the
supporting congestion control messages and mechanisms, it is not strictly
dependent upon that document for specification purposes.  Although there  is
not a strict dependency, the  normative reference was maintained since RFC
4654, as a building block document, contains considerable supporting
rationale for the mechanisms described.  It is important to note that
extensive simulation studies were conducted by the IRTF RMRG and subsequent
work leading to the RFC 4654 and NORM specifications.  Additionally,
significant experience with NORM protocol operation has occurred in the 3+
years of the NORM Experimental RFC 3940 existence and has shown that the
congestion control mechanism can be safely deployed on operating networks.
It is expected that RFC 4654 may be revised, but it is believed that the
complete specification that the NORM specification provides for congestion
control is sufficient.  For these reasons, it is  requested that an
exception be allowed for this particular downard reference.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

The IANA consideration section exists.  IANA requirements are clearly
described and are consistent with the other documents requiring assignments
from the "ietf:rmt" name-space.  All assignment requests are in compliance
with RFC2434 and the appropriate IETF actions are specified.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

Document Announcement Write-Up for draft-ietf-rmt-pi-norm-revised-07 follows.

Technical Summary

  This document is an RMT Protocol Instantiation that completely specifies
  data and procedures useful for building a reliable multicast transport
  protocol based on negative-acknowledgment (NACK) feedback.  The protocol
  uses the Forward Error Correction (FEC) techniques and building blocks
  specified by the RMT Working Group and fully specifies a congestion
  control mechanism that allows safe deployment of the protocol on
  networks along with TCP and other compatible transport protocols.  The
  document builds upon the NACK based reliability techniques described
  in another RMT WG document, draft-ietf-rmt-bb-norm-revised.
 
  draft-ietf-rmt-pi-norm-revised-07 also includes a description of
  security considerations and fully describes a baseline approach
  for using IPSec mechanisms to provide protocol security.  Header
  extensions are also defined to allow alternative security mechanisms
  to be deployed if needed.

Working Group Summary

    There is consensus in the WG to publish this documents.

Document Quality

    The document is of high quality and has been subject to extensive
    review in its Internet Draft and Experimental RFC forms.  The
    revised draft represents a small number of changes from the original
    Experimental RFC 3940.
   
    A public domain, open source implementation of this NORM protocol
    specification is available for use from the U.S. Naval Research
    Laboratory.  This implementation has been widely used in a number of
    applications, including military and commercial systems. The protocol has
    successfully operated on a wide variety of network types.  The INRIA
    organization has an implementation in progress.  The JPEG 2000 Digital
    Cinema group is considering specifying the NORM protocol  for some content
    distribution purposes.

    The content of this document was already reviewed and approved for
    publication as experimental RFC 3940. This document contains minor
    technical modifications.

Personnel

    Lorenzo Vicisano is the Document Shepherd.
    Magnus Westerlund is the Responsible Area Director.