Common Architecture Label IPv6 Security Option (CALIPSO)
draft-stjohns-sipso-11

[Ballot comment]
To me it appears that existing L3VPN technology, while widely deployed and therefore also widely implemented, is really not a great fit for the problem that this document is trying to solve. To a large extent L3VPNs rely on the service providers to correctly configure which sites go into which VPNs. This is great for L3VPNs (relieving private networks of significant effort), but seems wrong for what this document is doing. This is part of my motivation for entering a "no objection" vote.

[Ballot discuss]
The IPv6 community has discussed the topic of hop-by-hop options
in general, and in this case there has no been no discussions about
this specific proposal in the 6MAN WG. This should be a requirement
for moving forward.

I also share the same general concerns others have on this document.

[Ballot discuss]
What are the rules for providing IPv6 Options? I can't find anything specifying the rules. Could they just send in a registration request and not publish the document? I don't understand how IANA evaluates request when there are no rules.

I would like the IESG to discuss this issue.

[Ballot discuss]
I support Lars's and Ron's discusses.

From the discussion so far, I also get the impression that we might
not have IETF Consensus for the approach proposed in this document.

Adding to Lars's concern about transport protocols: In this draft,
there can be multiple simultaneous TCP connections with the same
five-tuple (proto, src, dst, src port, dst port).  That probably
means updating every middlebox in the network that uses the five-tuple
for its state -- and possibly many protocols that use addresses/port
numbers to identify connections (anything from RSVP to SDP to ICE to
BGP flow specs to RADIUS NAS-Filter-Rule attributes). That sounds bad.

[Ballot discuss]
I'll shortly summarize my points from the discussion in Minneapolis. First, I believe that creating IP options (esp. a hop-by-hop options) for walled-gardens is inappropriate. We've been pushing back when other SDOs wanted to do this. I see no reason why this case is different. A second concern is that this proposal resurrects historic IPv4 technology for IPv6, when we have better protocol mechanisms available that would address the same set of requirements (cf. Ron's comment on VPN). Third, this draft is not just asking for an IP option number. It changes many more pieces of the architecture, e.g., how applications interact with transport protocols. Finally, there was no serious attempt to engage the IETF community on their strong last call comments. Pretty much the only change was to move the document to Informational, which is essentially irrelevant, because what matters is that an IP option number will be allocated by an IESG approval.

I'd like to discuss these issues on the call, to see if I'm on the rough side of the consensus here. I'll move to an abstain afterwards.

[Ballot discuss]
The Gen-ART Review by Elwyn Davies was posted on 28-Jan-2009.  The
  IANA related comment must be addressed before the document can be
  approved.  The other comments deserve consideration as well.

  s9.2: The authors have requested IESG assistance with the IANA
  considerations section. The section does not currently have a well
  defined allocation policy (it is sort of FCFS with expert review
  on the side).

IANA Last Call comments:

IESG Note: Expert Assignment Required for Action 2.

Action 1 (Section 9.1):

Upon approval of this document, the IANA will make the following assignments
in the "Internet Protocol Version 6 (IPv6) Parameters" registry located at
http://www.iana.org/assignments/ipv6-parameters
sub-registry "5.b. Options Types"

HEX act chg rest
--- --- --- -----
[TBD] 00 0 [TBD] CALIPSO [RFC-stjohns-sipso-05]


Action 2 (Section 9.1):

Upon approval of this document, the IANA will create the
registry "CALIPSO DOI Values" at http://www.iana.org/assignments/TBD

Registration Procedures:

DOI Value Organisation or Use


======================= ============================


0:0:0:0 Null DOI; MUST NOT be used
on any network at any time.
0:0:0:1 to 0:255:255:255 For private use among
consenting parties within
private networks; for reasons
of interoperability, these
DOI values MUST NOT ever
appear on the global public
Internet.
1:0:0:0 to 254:255:255:255 For assignment by IANA to
organisations following the
guidelines in the paragraph
below.
255:0:0:0 to 255:0:0:0 Reserved to the IETF for
future use by possible
revisions of this specification.

For the CALIPSO DOI values registry, IANA is requested to
issue a new DOI value to any organisation that requests it.
Any assignments made will be publicly available from the IANA
website.

DOI values beginning with decimcal 0:0:0 are reserved for
private use amongst consenting parties; values in this range
will not be allocated by IANA to any particular user or user
community. For reasons of interoperability, these DOI values
MUST NOT ever appear on the global public Internet.

A commercial organisation will normally only be assigned
at most two DOI values.

A single national government or multi-national treaty
organisation (e.g. NATO, UN) normally may be assigned up
to 10 CALIPSO DOI values, if that is requested. If a given
national government has NOT requested a set of national values,
then different government departments (e.g. Ministry of Defence,
Department of Energy, Department of Homeland Security) or
different states/provinces (e.g. Queensland, New South Wales)
within that given national government each normally may
independently request up to 2 different CALIPSO DOI values.

DOI values beginning with decimal 255 are reserved to
the IETF for use in future versions of this specification.
IESG approval is required for allocation of DOI values
within that range.

With respect to delegation in unclear circumstances, IANA
may ask the IESG to appoint "Designated Experts" to provide
advice.

Initial contents of this registry will be:

DOI Value Organization or Use Reference
--------- ------------------- ---------

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

Summary of draft-stjohns-sipso-05.txt;
Submitted on 11 September 2008.


1A>  Who is the Document Shepherd ?

  Randall Atkinson, who is also the active document editor.

1A>  Has the document Shepherd personally reviewed this
  version of the document and, in particular does s/he
  believe this version is ready for forwarding to the IESG
  for publication ?

  Yes.  Yes.

1B> Has the document had adequate review both from key WG
  members and from key non-WG members ?

  There is no related WG.  The document has had extensive
  review by both implementers and users.  There are no known
  unresolved issues.

1B> Does the Document Shepherd have concerns about the depth
  or breadth of the reviews that have been performed ?

  No.

1C> Does the document shepherd have concerns that the document
  needs more review from a particular or broader perspective ?
 
  No.

1D> Does the document shepherd have any specific concerns or issues
  with this document that the Responsible AD or IESG should be
  aware of ?

  No.

1E> How solid is the WG consensus behind this document ?

  This is an individual submission, not a WG document.

  The document shepherd believes that among the reviewers
  there is clear consensus that this document is adequate.

1F> Has anyone threatened an appeal or otherwise indicated
  extreme discontent ?

  No.

1G> Has the document shepherd personally verified that the
  document satisfies all I-D Nits ?

  Yes.  The document does not have an "intended status"
  text because that is a decision for the Sponsoring AD
  and IESG as a whole.

1H> Has the document split references into Normative and
  Informative subsections ?

  Yes.

1H> Are there normative references to documents that are
  in an unclear state or otherwise not ready for advancement ?

  No.

1H> Are there normative references that are downward references ?

  No.

1I> Has the document shepherd verified that the document's IANA
  Considerations section exists and is consistent with the body
  of the document ?

  Yes.  Yes. The IANA Considerations was last revised following
  guidance from the sponsoring AD (Tim Polk).

1I> Are the IANA registries clearly identified ?

  Yes.

1I> If the document creates a new registry, does it define the
  proposed initial contents and an allocation procedure ?

  Yes.

1I> Does it suggest a reasonable name for the new registry ?

  Yes.

1I>  If the document describes an expert review process,
  has shepherd conferred with the responsible AD so the IESG
  can appoint the needed expert during the IESG evaluation ?

  Yes.  Proposal is for Ran Atkinson to be the primary
  designated expert for questionable cases, with Mike
  StJohns as the designated backup expert.

1J> Has the document shepherd verified that sections of the
  document specified in a formal language validate correctly ?

  Not applicable. 

1K> Please provide a Document Announcement Write-Up.

  Please see bottom.

1K> Are there any existing implementations of this protocol ?

  No. 

  Several vendors have indicated interest in implementing
  this option as part of their mandatory access control
  features for hosts or routers.  It is believed likely that
  at least one open source operating system will implement
  this specification.  At least one router implementer has
  evaluated implementing support for this option in silicon,
  and is satisfied that this would be practical to do.


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. 
 

Document Quality
 
  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.

Personnel

  Randall Atkinson is the document shepherd, and is also
  the active document editor.
 
  Tim Polk is the sponsoring Area Director.


EOF