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

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.).

---

  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?

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.