I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines an IPV6 option for labeling the sensitivity of packets on trusted networks. The idea is that all of the components that handle these sensitive packets must support this option. Each component that handles a packet in this architecture needs to be trusted to apply appropriate security policy and not to disclose the packet in environments where the packet is outside of the appropriate sensitivity range. summary: This document is basically ready for publication as an informational document. However significant concerns are present if the IESG plans to continue with its current course of publishing on the standards track. Fixing these concerns will require work, but is definitely doable if there is sufficient consensus. process concern: This document is being sponsored as a proposed standard. However as indicated by the last paragraph in section 1 before section 1.1 this document is a follow-on to RFC 1108, which the IETF deprecated and moved to historic. As that paragraph points out, this option has been in *limited deployment* throughout the history of the internet. While this specification does not specifically invoke the language of RFC 2026 regarding applicability statements, I think that the applicability level "limited use" maps well onto the language of section 1 of this draft. It seems that RFC 2026 recommends against standards-track for technical specifications that have an applicability of "limited use," and I wonder if there is adequate consensus within the IETF community that has considered this RFC 2026 recommendation to overturn that BCP recommendation. I specifically call this issue out for community discussion and recommend that the IESG consider it when evaluating this document. There is a second, less serious process issue. As the draft points out, we chose to move RFC 1108 to historic; has there been adequate discussion to overrule that consensus or otherwise determine it does not apply to the current TS? I consider this less serious because a plausible rationale is presented in the document: we believed IPsec would make these labels unnecessary but now have operational experience that is not the case. If this document is going to be published on the standards track, I think it needs significant revision to come in line with current security best practice BCPs. It's poor form for the security community to enforce these BCPs on other areas' documents but not to meet our own standards; see major comments below. Major Comments: The security of the mechanism described in this document depends critically on participants being trustworthy and trusted. I think the document would be improved significantly by a prominent definition of trustworthy that made specific reference to the Internet threat model and explained how the threat model here differs from that model. Section 8 proposes that AH is the mandatory-to-implement security mechanism for this option. Do we still believe that is appropriate given RFC 4301's move away from AH as a mandatory-to-implement service? This document does not provide a mandatory to implement automated key management solution as required by RFC 4107. It seems like IKE or IKEV2 would be the best mechanism to recommend. If you recommend IKE, be sure to follow the guidance of draft-bellovin-useipsec; if you require IKEV2 be sure to follow similar guidelines. As we know, BCP 61 requires a strong mandatory-to-implement security mechanism for Internet protocols. That mechanism needs to be sufficient for use over the open Internet. We have been very reluctant to accept weaker security mechanisms because some standards-track protocol is not intended for use on the open Internet; BCP 61 says we have consensus that is not how we do things. I question whether AH is sufficient as a BCP 61 mandatory-to-implement mechanism. The entire point of this IPV6 option is to limit disclosure of confidential and classified information. In order to meet that security objective on the open Internet, some confidentiality mechanism is required. I strongly recommend that if this TS is published on the standards track,ESP with confidentially be required. This document referrs to SIPSO-IPsec interactions in a number of places, but never outlines processing rules for systems that implement both IPsec and SIPSO. Does the label go inside or outside of IPsec? (presumably the label should be protected) Section 1.3 discusses deployment involving systems that are not aware of the option. It proposes that the last intermediate system needs to strip the label. Why? It's in an ignore-if-you-don't-understand option. The document requires that if there is a label inside and outside an AH header, that these labels must be the same. Why is this a valid use of a 2119 MUST? What security or interoperability problem results if for example the outer label dominates the inner label? As far as I can tell this requirement gets in the way of tunneling arbitrary IP traffic. The document describes several times how to compare labels. I really hope these explanations are all consistent; as best I can tell they are. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf