The IESG has approved the following document: - 'Common Architecture Label IPv6 Security Option (CALIPSO) ' <draft-stjohns-sipso-11.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stjohns-sipso-11.txt Technical Summary This document defines a new IPv6 Hop-by-Hop Option that will be used narrowly within multi-level secure network deployments. This option is used to enable mandatory access controls (e.g. to prevent a MOST SECRET packet from being forwarded out an UNCLASSIFIED interface). This option is related to prior IPv4 work in the same area, specifically RFC-1038, RFC-1108 (IPSO), and FIPS-188 (CIPSO). Those IPv4 options are deployed by many countries and several financial institutions to provide mandatory access controls for IPv4 packets. These IPv4 options are supported in some current commercial products. For example, Cisco IOS, Sun Trusted Solaris, and SE-Linux support RFC-1108; Sun Trusted Solaris, SGI IRIX, and SE-Linux also support FIPS-188. This must be an IPv6 Hop-by-Hop option because routers that have been enhanced to recognise this option are a critical point where mandatory access controls are applied. Because this option should never appear on the public global Internet, and because the option is part of a scheme for mandatory access controls, this option ought not create a denial-of-service issue for routers in the global Internet. Working Group Summary This document is an individual submission, not the product of an IETF working group. The document has been reviewed extensively by implementers at several different firms. It also has been reviewed by users at multiple operational sites in multiple countries and organisations. IETF Last Call highlighted some controversies. The document was Last Called for standards track, but is now being considered for Informational status as a result of comments on the IETF discussion list. Using a hop-by-hop suboption has also proven controverial. Document Quality There are no implementations of this specification as documented, but there is considerable implementation experience for the related IPv4 RFCs. There is also a proprietary solution for IPv6 that has been in deployment for several years. This document reflects the lessons learned from deployment experience with these solutions. This document is acceptable to the reviewers that have provided input to the document. No concerns about clarity have been received by the document editor or document shepherd. This specification is much more detailed than the previous IPv4 label option specifications were. Some Last Call comments indicated that additional background on Multi-Level Security (MLS) was needed, but that information was deemed out of scope by the editor and sponsoring AD. Personnel Randall Atkinson is the document shepherd, and is also the active document editor. Tim Polk is the sponsoring Area Director. IESG Note This RFC specifies the use of an IPv6 hop-by-hop option. The IESG notes that general deployment of protocols with hop-by-hop options are problematic, and the development of such protocols is consequently discouraged. After careful review, the IETF has determined that a hop-by-hop option is an appropriate solution for this specific limited environment and use case. Furthermore, the mechanism specified in this RFC is only applicable to closed IP networks. It is unsuitable for use and ineffective on the global public Internet. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
