Subject: fundamental concerns about draft-stjohns-sipso

From: Lars Eggert <[email-masked]>
Date: Thu, 5 Mar 2009 12:30:53 +0100

Hi,

I'm currently holding a discuss on draft-stjohns-sipso, because I  
fundamentally question if this is a document the IETF should publish.  
The discuss is not actionable, i.e., I don't see any way to "fix" the  
document, so I'm deliberating what to do. I'd appreciate your thoughts  
on this situation.

In short, draft-stjohns-sipso asks for an IPv6 hop-by-hop option  
number for use in Multi-Level Security (MLS) networking environments,  
i.e., mostly governmental and military networks that use IP technology  
but are not "the Internet". MLS networking is standardized outside the  
IETF, and (in my opinion) diverges significantly from the Internet  
architecture, to the point where IETF transport and application  
protocols cannot generally be used on an MLS network without changes,  
or without trusted proxies that translate protocol flavors.

Should the IETF allocate option numbers for extensions to our  
fundamental protocols (in this case, IPv6) that are targeted solely at  
private walled-garden networks? Note that in addition to draft-stjohns- 
sipso, we have been receiving liaison statements from the ITU-T, which  
would also like an IPv6 hop-by-hop option number for their walled  
garden, so our decision on draft-stjohns-sipso might set a precedent.

A secondary concern is that this document resurrects IPv4 technology  
that has been declared Historic for continued use with IPv6, and in  
the meantime, the IETF has designed better protocol mechanisms that  
would arguably address the same set of requirements (for example,  
L3VPN). I understand the argument that the MLS architecture  
specifications require this sort of approach, but the ITU-T  
architecture has also in the past been used to argue for inferior  
technical solutions, and the IETF has chosen to not pursue those.

I'd like to ask for your thoughts on what the IETF should do here.

(Also: Thank you, Ran, for already having taken the time to discuss  
this at some length. Much appreciated.)

Thanks,
Lars

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 05 Mar 2009 10:07:28 -0500

On  5 Mar 2009, at 06:30, Lars Eggert wrote:
> fundamental protocols (in this case, IPv6) that are targeted solely  
> at private walled-garden networks? Note that in addition to draft- 
> stjohns-sipso, we have been receiving liaison statements from the  
> ITU-T, which would also like an IPv6 hop-by-hop option number for  
> their walled garden, so our decision on draft-stjohns-sipso might  
> set a precedent.

All,

No.  That concern is misplaced.

The precedent that might be created is quite different,
and ought not be controversial, namely:

* As the standards body for IPv6, the IETF will consider and review
   proposals for IPv6 extensions (e.g. additional IPv6 options).

Approving this as an Informational RFC would NOT set a precedent
that the IETF would approve all such proposals for IPv6 extensions.
As all IPv6 options necessarily have different semantics and syntax,
the IETF community might well reach quite different (e.g. opposite)
conclusions about one proposal versus some other proposal.

If the IETF is the standards body for all IPv6 uses and extensions,
as it claims to be, it would be quite odd to refuse to consider
such IPv6-related proposals.

Moreover, there is an existing IETF precedent for using and
specifying explicit IP sensitivity labels; one that is over
20 years old.  RFC-791 contains a Sensitivity Label option,
which was subsequently evolved into RFC-1038 and then RFC-1108.
Several commercial products (e.g. Solaris, Ultrix, HPUX, AIX,
Linux, and Cisco IOS) supported at least RFC-1108 -- several
of these are still shipping.

RFC-1108 has always had limited deployment, and always will,
but that deployment has grown over the past decade, not declined.

Absence of an openly specified IPv6 Sensitivity Label is a serious
barrier to governmental deployment of IPv6 -- and this affects
a wide range of countries.  Failure to have a open specification
will have the undesirable result of forcing governments to continue
to grow IPv4 deployments, by preventing IPv6 migration.

One would imagine that both the IETF generally, and the IPv6/6MAN WG
particularly, would want to facilitate and encourage IPv6 migration,
rather than hinder/prevent it.

> that has been declared Historic for continued use with IPv6,

RFC-1108 was declared Historic over objections from the very few
IETF participants who know MLS users.

As the key issue operationally is having an open specification and
an IANA-assigned option number, for interoperability reasons,
moving RFC-1108 to Historic had little impact on anyone.  New
implementations of RFC-1108 have been begun even after that IESG action.

> and in the meantime, the IETF has designed better protocol mechanisms
> that would arguably address the same set of requirements (for example,
> L3VPN).

One of the Routing ADs already has explained to you and to the
other IESG members that L3VPNs *can not* meet the same set of
requirements as this proposal.  I have also discussed this at
length in conversations with individual ADs and the entire IESG.

So the claim above is simply not correct.

L3VPNs simply cannot address or solve these MLS issues.

> I understand the argument that the MLS architecture specifications
> require this sort of approach, but the ITU-T architecture has also
> in the past been used to argue for inferior technical solutions,
> and the IETF has chosen to not pursue those.

Frankly, there is no alternative MLS approach.  Because we lack
any concrete, and operationally viable, alternative for MLS
networks, it seems odd to charaterise this MLS label as an
"inferior" solution.

Using labelled IPsec was the original plan for IPv6 MLS networks,
as a check of the original IPsec RFCs (written by me) should reveal.
Since then, over the past ~13 years, various efforts have been made
to create/use a labelled IPsec approach for MLS environments.  Both
implementation experience and operational experience has shown that
my  (and the IPv6 WG's) earlier hope and belief (i.e. that labelled
IPsec would be a sufficient substitute for these labels) was incorrect.

(Much of this is already discussed in the I-D, as the result of
review/feedback from a range of folks, including Lars.)

> I'd like to ask for your thoughts on what the IETF should do here.

Just to be clear, the proposal to hand is that the
draft-stjohns-sipso-* would be published as an Informational RFC.

The MLS network user community simply wants to have an open
specification for these labels, and to have an official IPv6
option number (so that interoperability is feasible and that
use of this option would not interfere with other protential
IPv6 options).

There are ~3 MLS operating system suppliers who have told me
that they plan to support this option if an RFC is published.
(Some have already posted to the [email-masked] mailing list.)
MLS systems are used on nearly all continents, and by a wide
range of Asian, North American, South American, and European
countries, by a range of different organisations/governments.
So while the user base is small, it is geographically diverse.

As of this minute, no IP router vendor has told me whether
they plan to implement the ACL support for this IPv6 option or not.
(The MLS user community clearly hopes that will happen.)

Yours,

Ran Atkinson
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Thu, 5 Mar 2009 18:37:21 +0100

Hi, Ran,

thanks for the timely response.

>   proposals for IPv6 extensions (e.g. additional IPv6 options).

We have been considering and reviewing the proposal. But not all  
proposals end up getting approved.

> conclusions about one proposal versus some other proposal.

It would not set a precedent that the IETF is approving *all* such  
proposals, but it would set the precedent that the IETF has approved  
*one* such proposal. At that point, we're arguing about whether IPv6  
options for one kind of walled garden vs. another kind of walled  
garden are OK.

My personal opinion is that "profiling" (to use an ITU-T term) of core  
Internet protocols is counterproductive. They are what makes the  
Internet universally interoperable, and creating non-interoperable  
flavors is something the IETF should attempt to prevent and not foster.

(I'd be fully OK with MLS IPv6 moving to a separate EtherType, but I  
don't think that's on the table for discussion.)

> such IPv6-related proposals.

The IETF is this standards body, and it has considered the proposal.  
The question now is whether it should approve it.

> of these are still shipping.

If I got my history straight, the IPv4 sensitivity label dates back to  
DARPA days, i.e., to a time when the US government funded much of  
Internet research and deployment, and the resulting protocols reflect  
that to some degree. I question whether a 1:1 mapping of that  
technology into IPv6 is a good engineering choice today.

> rather than hinder/prevent it.

This is a very valid argument, and so far it is one of the few reasons  
that I have down on the "pro" side of my personal MLS tally sheet. If  
the community thinks that this is the killer argument that trumps all  
other concerns, I may reconsider. Please send your thoughts.

> IETF participants who know MLS users.

I didn't follow that process, but this decision did require and get  
IETF consensus, i.e., the IETF decided that the technology is obsolete  
for IPv4. You may disagree with this decision, but it was made.  
Because it was made, I question why it makes sense to resurrect  
obsolete technology in IPv6.

> implementations of RFC-1108 have been begun even after that IESG  

The IETF can't stop anyone from implementing obsoleted protocols, or  
any technology that we find problematic for other reasons.

What we can do, however, is come to consensus now whether we want to  
allocate a new codepoint for an IPv6 version of a protocol mechanism  
we've made Historic for IPv4. We're having this discussion right now.

> L3VPNs simply cannot address or solve these MLS issues.

OK, not being an MLS expert it is fully possible that I don't  
understand the requirements completely. But if none of the IETF's  
security solutions for the global Internet are applicable to these  
walled-garden deployments, that simply reinforces the point that these  
networks are in fact very different from the Internet.

> IPsec would be a sufficient substitute for these labels) was  

If this effort has failed and the plan now is to go back to IP-based  
MLS, I believe we should explicitly discuss whether the IETF community  
wants to go that way, rather than implicitly making it so by  
allocating a codepoint.

> use of this option would not interfere with other protential

Thanks for summarizing your viewpoint. I believe I have made mine  
sufficiently clear, too, so hopefully the community now understands  
our disagreement and can share their thoughts.

Thanks,
Lars

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 06 Mar 2009 11:50:24 -0500

On  5 Mar 2009, at 12:37, Lars Eggert wrote:
> It would not set a precedent that the IETF is approving *all*
> such proposals, but it would set the precedent that the IETF
> has approved *one* such proposal.

Please forgive me, but I disagree that the above is
a well formed concern.

Permitting one proposal to move forward as Informational has
NEVER implied that some different proposal needs to be approved
as either Informational or standards-track.

There is A LOT of IESG/IETF/WG history of approving one thing
and not approving another, for a wide range of protocols
in a variety of different IETF Areas for many many years now.

> At that point, we're arguing about whether IPv6 options
> for one kind of walled garden vs. another kind of walled garden are  
> OK.

I do not agree with this.

In particular, I don't think it is either accurate or descriptive
to call "MLS networking" a walled garden.  I agree it has significant
differences from the global Internet, but those differences are
fundamentally due to differences between any single-level OS
and any multi-level OS.

> My personal opinion is that "profiling" (to use an ITU-T term)
> of core Internet protocols is counterproductive. They are what
> makes the Internet universally interoperable, and creating
> non-interoperable flavors is something the IETF should attempt
> to prevent and not foster.

This isn't profiling, nor is it an ITU-T proposal, nor
(to the best of my knowledge) is this similar to any ITU-T concept.

Now, there is widespread profiling, particularly for IPv6.
Many countries, including but not nearly limited to the USA,
have national profiles for IPv6-related IETF standards.
The IETF has even engaged in profiling of its own specifications
sometimes.

> (I'd be fully OK with MLS IPv6 moving to a separate EtherType,
> but I don't think that's on the table for discussion.)

Well, if that happened, commercial vendors (for all IPv6 products,
not just MLS ones) likely would simply move all IPv6 traffic
to that new EtherType (or have implementations handle either
EtherType identically and using a common send/receive/forwarding
implementation).

In that outcome, if my guess is correct (and my guess might not be :-)
then the IETF's decision-making would be circumvented.  I don't think
that is really in the best interest of the IETF -- and I am trying
to look out for the IETF (speaking as someone who has been active
in IETF for a couple of decades now).

> The question now is whether it should approve it.

Yes, and just to be clear, but not "approve it as a standard",
rather "not object to publishing this option as an Informational RFC".

> If I got my history straight, the IPv4 sensitivity label dates
> back to DARPA days, i.e., to a time when the US government
> funded much of Internet research and deployment, and the resulting
> protocols reflect that to some degree.

At a high-level, that's about right...

DARPA did fund much of the Internet research from about 1970 through
much of the 1980s.  However, by 1990, most of the Internet research
was NOT DARPA funded, and nearly all of the development was done by
commercial firms (e.g. Cisco, 3COM, DEC, HP, and Sun).  DARPA was
still funding the BSD development part way into the early 1990s,
but 4 BSD wasn't a MLS system.

> I question whether a 1:1
> mapping of that technology into IPv6 is a good engineering choice  
> today.

If you have a concrete better proposal, people would like to read
the Internet-Draft.  This topic is NOT new.  It has been discussed
in various places in the IETF, off and on, for at least 8 years now.
So far, no concrete better proposal has appeared.

How long do we want to stall the IPv6 migration of MLS networks ?

> IETF consensus, i.e., the IETF decided that the technology is  
> obsolete for IPv4.

I contested then, and even now contest, that there was ever
any real IETF consensus either way on the topic of deprecating
RFC-1108.

> You may disagree with this decision, but it was made. Because it was  
> made, I question why it makes sense to resurrect obsolete technology  
> in IPv6.

Where is the I-D with a concrete proposal for an alternative solution ?

This current I-D has been out publicly for ~2 years now.  An IETF-wide
4 week last call was made last fall, with little feedback either way.

The comments that were received have been addressed by subsequent
edits to this I-D, including the comments made during the past month
or so on this list.

> MLS,
> I believe we should explicitly discuss whether the IETF community

Right.

This is why an IETF-wide 4 week last call was held last fall,
and this I-D was edited to address the (limited) feedback.  It is
also why this was explicitly discussed here more recently, again
with (limited) feedback that has now been addressed by recent
revisions of the I-D.

Frankly, much MORE discussion of this I-D has happened already
than EVER occurred on the IESG's deprecation of RFC-1108 a few
years back.

And the review for this I-D has already FAR exceeded the process
requirements of RFC-2026 as amended.

There is an old fishing expression,
	"It is time to either fish or cut bait."
and that is really where this topic is right now.

Yours,

Ran
[email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 11 Mar 2009 12:15:50 -0400

Ok, Lars, you're asking for opinions, I will give you one.  Remember,
you asked.

I think that, given how many times the IETF has added bizzare
standards track features to IPv6 in order to keep the 3G crew happy,
it is very strange to me that we should now balk at approving an
Informational document supporting a several-decade-old requirement
from one of the earliest adaptors of IPv4.  I almost fell out of my
chair laughing when I saw the reference to the US DoD as a walled
garden (which it is, of course, but pot, meet kettle...).

I think the IETF should get out of the way and let the MLS people have
their hop-by-hop option and Informational document.

Cheers,

--Rob

---

From: David Conrad <[email-masked]>
Date: Wed, 11 Mar 2009 15:38:44 -0700

> their hop-by-hop option and Informational document.

+1

Regards,
-drc

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Mar 2009 15:01:45 +0200 (EET)

> L3VPNs simply cannot address or solve these MLS issues.

Could you describe why L3VPNs or such are inadequate?  The discussion 
in S 1.1 of draft doesn't really help much to understand what are the 
actual problems with these.  It discusses unwillingness to implement 
L3VPNs on hosts but it's not clear why this is needed; and also not 
being able to carry sensitivity label in L3VPN but it's not clear why 
you couldn't just pick a localized approach to designate the labels or 
map them in some manner; etc.

FWIW, I wouldn't have a problem with this draft if it didn't add a 
hop-by-hop option (if there are problems with e.g. changing all 
transport protocols, at least those involve only end-hosts).  I don't 
want to add any burden on on-path implementations and I prefer to set 
a very high bar for adding new hop-by-hop options, and this doesn't 
reach that.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Mar 2009 09:36:38 -0400

On  12 Mar 2009, at 09:01, Pekka Savola wrote:
> L3VPNs on hosts but it's not clear why this is needed;

A critical purpose of the option is to enable the sender to
inform the receiver of the correct Sensitivity Label for
the data carried in that particular packet.  This is described
in the draft.

A single UDP/IP session (one example is ONC RPC, but that is
not the only example) between a pair of nodes might have
different packets with different Sensitivity Labels.  This
is also described in the draft.

So the labels are also used end-to-end, as the draft describes
in detail, not just in the middle, as the draft also describes.

In the special case where a node or link is not MLS, then the edge
router facing that non-MLS link inserts/removes the labels on behalf
of those (typically MS Windows) systems -- as described in the
document.

> and also not

L3 VPNs simply aren't, and never have been, an ACL mechanism
for drop/no-drop decisions on a per-packet basis.

If the label were a destination option, then routers would
be incapable of applying ACL rules (drop or not drop) based
on this option, and could not enable non-MLS end systems
to participate in the MLS deployment.

THe reasons a router wants to look at this option are:

1) to decide whether to drop the packet rather than forward it
out some interface or accept it in from some interface.  This
is also described in the document.  [Cisco even has some
documentation on this if one grep's for RFC-1108 in their IOS
manuals.]

and

2) to decide whether to insert/remove a label from a packet,
in the special case of packets from/to a non-labelled link,
as described in the draft.

> hop-by-hop option

The existing IP MLS label options all have hop-by-hop semantics,
as another goal is to have routers that will examine the labels
*only* (repeat *only*) for the purposes of ACLs.  This is also
described in the draft.  Cisco shipped RFC-1108 support in the
very early 1990s.  I think it is still present in (router) IOS
today.

Those MLS options have ~20 years of operational experience that
they do NOT cause any operational issues for operators or for
routers. So there is LOTS of actual experience that says having
this as a hop-by-hop option is NOT a problem for any party.  This
is not speculation or proof-by-assertion, but actual experimental
result from ~20 years of MLS network deployment with RFC-1038,
RFC-1108, and FIPS-188.

I build routers.  I built routers at Cisco in the middle 1990s.
I think I understand the generalised anxiety about things in
the middle of the network.  However, in this special case, we
have LOTS of experience that this kind of option is not problematic.
We also have spent ~15 years trying to make other approaches work
for MLS networks -- none of them could be made to work.

L3VPNs just are not an ACL mechanism.  No less than one of the
Routing ADs have said L3 VPNs cannot solve the requirements of
MLS networking, to the IESG, within the past month.

Yours,

Ran
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Mar 2009 16:24:25 +0200 (EET)

> is also described in the draft.

I took one of Lars' concerns as having essentially multiple different 
sessions (with different labels) under a single session as being a 
problematic.  I don't see why such approach is needed and this is the 
right place to handle this, and even done like this, why this could 
not be solved using other approaches (e.g. destination option).

> of those (typically MS Windows) systems -- as described in the

This breaks RFC 2460's assumption that boxes in the middle don't add 
or remove options or headers.  Problems caused by this are both 
architectural and technical; one technical issue not (AFAICS) 
addressed in the text happens if the packet size would exceed MTU when 
the option is added.

> for drop/no-drop decisions on a per-packet basis.

Access lists and various other access control mechanisms have been 
applied in almost every conceivable place in the architecture, 
however.

> to participate in the MLS deployment.

Not true.  Routers can have code that examines the content of the 
destination options of a packet.  I have a recollection that there are 
multiple implementations already capable of doing that.

Just to apply ACL rules, hop-by-hop option is not necessary, though 
from some perspective, it may be the simplest approach.

> documentation on this if one grep's for RFC-1108 in their IOS

Again, regular ACLs inspecting content are able to do that.

> as described in the draft.

This has issued mentioned above, but even if it is true, equally 
possible would be to do that insertion with dst options or some other 
marking.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 12 Mar 2009 14:01:54 -0400

> not be solved using other approaches (e.g. destination option).

I accept that you don't see it.

None the less, this problem has been studied for over 2 decades,
without any better approach being proposed.  There is also about
2 decades of deployed operational experience that the approach
proposed here works well, AND that it does not cause problems
operationally or for implementations.

Have you either used or implemented an MLS system ever ?
How familiar are you with MLS concepts ?

MLS is an odd universe, to be sure, but it has long-standing,
and (slightly) growing deployments in many different countries,
by many different organisations, on most continents of the globe.

> or remove options or headers.

A device that inserts/strips this unique option is a router,
in that it forwards IP packets.  However, it is also a highly
trusted device that is a kind of security gateway.

There is ample precedent, both in IPv4 MLS deployments and in
the deployed non-MLS global IPv4 and IPv6 Internet, for security
gateways to modify packets in transit under certain circumstances,
including modifying header bits and options.

> Problems caused by this are both
> architectural and technical;

You have identified several areas where you are concerned.

You have not yet demonstrated that any real problems exist.

Further, you haven't bothered to try to refute my several
comments that we have 2 decades of experience with this
type of option showing that it does work well, and does NOT
have problems (operational, architectural, or implementation).

> one technical issue not (AFAICS) addressed in the text happens
> if the packet size would exceed MTU when the option is added.

If you have proposed text, I am happy to make reasonable
clarifying edits.

> applied in almost every conceivable place in the architecture,

Which does not contradict my statement that L3 VPNs simply are
not an ACL mechanism and that L3 VPNs are not a solution.
I'd really suggest you go chat off-list with the Routing ADs
about this.  They are likely much more eloquent than I am.

> multiple implementations already capable of doing that.

I've talked with several IPv6 router vendors, who disagree with
your claim above, and further point to RFCs saying that routers
ought not examine any Destination Options on transit packets.

The several vendors that I've talked with have implementations
that can only look at Hop-by-Hop options, and some of those either
have already -- or are planning to add -- configuration options
to ignore all hop-by-hop options as well for transit packets.

(Frankly, I think having that particular configuration knob
makes a lot of sense, regardless of this proposal, just as having
an implementation that ignores all Destination Options on transit
packets makes sense.)

> from some perspective, it may be the simplest approach.

That is not consistent with what several vendors with shipping
IPv6 routers have said.

> Again, regular ACLs inspecting content are able to do that.

Your assertion is opposite to what I am told by several IPv6
router vendors with shipping products and deployments.

I'm the original author of Cisco's IPv6 code for router IOS.
I'm sure it has evolved since (and I hope they've fixed my
bugs by now), but I do have experience building IPv6 routers.

So far, I've worked on 4 different IPv6 implementations for
forwarding IPv6 packets (Net/2 BSD, 4.4 BSD, Cisco IOS, Extreme).
(I think that I'm tied with Margaret W for having worked on
the largest number of separate implementations.)

So I'm speaking from actual implementation experience here.

> possible would be to do that insertion with dst options or some other

Agree that insertion/deletion of one option is functionally
equivalent to another -- of either flavour.  That doesn't
address any of the reasons I have outlined why this really
does need to be a hop-by-hop option.

I also note that you deleted (without responding to) my
observations that we have 2 decades of operational experience
proving that a hop-by-hop semantic is NOT problematic for this
unique type of IP option.  I gather that means you either
agree with my statement, or have no contrary evidence to hand.

To be honest, I think that sra's generic comment of a day or two
ago (about the current set of "concerns" about this option being
misplaced given the IPv6 protocol history) was pretty on the mark.

The effective choice in front of the WG is whether to block
deployment of IPv6 MLS networks -- and force various governments
to keep expanding their IPv6 deployments instead.  I'd suggest
that is NOT in the best interest of the IPv6 community, or in
the best interest of the IETF.

Yours,

Ran
[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 12 Mar 2009 12:13:40 -0700

+1

   Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 13 Mar 2009 17:08:05 -0700

At Thu, 12 Mar 2009 14:01:54 -0400,

> including modifying header bits and options.

Hmm...I'm not sure what specifically the 'ample precedent' does
(against the IPv6 protocol standard), but regarding this specific
point I think I'm with Pekka.  I have no strong opinion either for or
against assigning a new IPv6 hop-by-hop option for some walled-garden,
non-IETF protocol (except that HbH options are relatively scarce
resource - but it doesn't matter much anyway, because we wouldn't
expect so many options to be defined).  However, I want that option to
conform to the standard rules, especially when it's defined in an IETF
document, i.e., RFC.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 14 Mar 2009 07:02:43 -0400

On  13 Mar 2009, at 20:08, JINMEI Tatuya / 神明達哉 wrote:
> I have no strong opinion either for or
> expect so many options to be defined).

OK.  Thanks.

> However, I want that option to conform to the standard rules,
> especially when it's defined in an IETF document, i.e., RFC.

I think there might be a big confusion here.

1) No router is ever required to add or remove this or any IPv6
option.  This document does NOT require that a router be capable
of adding or removing this option in any situation.  The document
is quite clear on this.  (Personally, I doubt that any commercial
off-the-shelf router implementer will even consider doing this --
because there likely is no business case for them to implement it.)

2) The document does say that if a security gateway (which happens
to be a device that forwards packets; this community calls any device
that forwards packets a router, even if it is really a security box)
chooses to include support for adding/removing this option (i.e.
to let a bunch of MS Windows or Apple MacOS X systems connect at
a single-level through a MLS network deployment), then that process
must be done in a particular manner.  The function is specified
only to ensure that appropriate Mandatory Access Control rules
get followed by such an implementation.  MAC rules are the central
fact of life in any MLS implementation or deployment, according
to the applicable ISO standards.

For ~2 decades now, in many IPv4 MLS networks, there are security
gateways (the one I've heard about was custom-built on Trusted
Solaris 8, and is not a commercial router nor is it commercially
available) that will add/remove RFC-1108/FIPS-188 Sensitivity Label
options to enable such single-level desktop systems to connect
to a MLS server through a MLS network deployment.  If someone wants
to call that an Application Layer Gateway, I won't object to the
words (because I don't really care what name we use for it :-),
but functionally what the device does is apply Mandatory Access
Controls and facilitate integration of single-level systems into
a multi-level secure environment.  If folks want me to edit the
draft to rename that function an Application Layer Gateway,
or Security Gateway, or use some different set of words,
I'm certainly open to such edits.

3) I'll note that this document will NOT be an IETF RFC, will not
be on the IETF standards-track, and is not an IPv6/6MAN WG document.
This is in fact an individual submission that is proposed to be
published as a non-IETF Informational RFC.  It is being reviewed
here because it proposes to allocate an IPv6 option number.

4) Separately, the RFC document series goes back to ~1970.  The
IETF was not even created until ~1985.  Each year many non-IETF
RFCs continue to be published.  Most usually these are individual
submissions with either Informational status or Experimental status.
Not all RFCs are IETF documents; this one will not be an IETF
document nor will it be an IPv6/6MAN WG document.  Bob Hinden
and some others here can likely provide more precise dates,
but the years just above are at least pretty close.

Yours,

Ran Atkinson
[email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Sat, 14 Mar 2009 21:59:11 +0100

> their hop-by-hop option and Informational document.

As long as there's no expectation that it works on the open Internet,
sure. 8-)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 Mar 2009 09:53:11 +0200 (EET)

> here because it proposes to allocate an IPv6 option number.

Actually, this is being proposed as an IETF RFC (as opposed to say, 
RFC-editor RFC) (you can see this by e.g. looking at the Evaluation 
record in the datatracker.). It seems to be an individual submission 
through an area director (Tim Polk).

The main difference is that (unless the rules have changed recently), 
rfc-editor RFC's get an "IESG Note" in the first page which says the 
document is not a product of the IETF, etc. which essentially 
disclaims any IETF endorsement of the protocol.  This draft would not 
have such a note.

(Personally I would have a much smaller problem with the publication 
of this document if it included an appropriate IESG note.)

The second difference in this case is that the allocation guidelines 
for IPv6 options of this type are basically undefined at the moment. 
I think this is interpreted so that some IETF approval for new 
codepoints is required.  It is not obvious why one couldn't just ask 
community the question "do we grant this codepoint for this purpose?" 
instead of "do we grant this codepoint for this purpose by approving 
this IETF RFC?"

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Mar 2009 12:16:42 -0400

> through an area director (Tim Polk).

Well, if that's true, and it is not obviously true to me,
then that wasn't our idea, but instead the IESG's idea.

For the record, the draft authors are quite happy for this to be
a non-IETF Informational RFC, since that's what we already thought
was happening.

Originally, the Security AD wanted to persue Proposed Standard,
which is how it got into I-D Tracker, and had an IETF-wide Last Call,
but then more recently the IESG consensus was that this was not
standards-track material, so now the document is intended to be
Informational.

The MLS community are simply, however, trying to be flexible. :-)

> disclaims any IETF endorsement of the protocol.  This draft would not

What words would you like to see added ? and where in the draft ?

(I find it more productive to discuss specific edits to the draft,
than hypothetical issues. :-)

Kindly note, at present, there are several *pages* of scoping text
(effectively these are a disclaimer that this option is not intended
for general use on the public Internet).

Now, the document keeps getting longer and longer, mainly due to people
wanting to add more and more text saying this option has limited utility
and that utility does not include the public Internet.  Most recently,
some other (non-MLS community) folks have started to complain to me
that the document is too repetitive on these points, which repetition
exists solely to respond to the earlier comments.

> of this document if it included an appropriate IESG note.)

While I don't necessarily object to some IESG note:
- the IESG have not proposed one,
- the IESG have not suggested that one was appropriate,
AND
- it isn't obvious to me what such a note might say, given
   the existing numerous pages of scoping text which are
   already a multi-page disclaimer.

(This seems pretty deep into the hypothetical to me right now.)

> for IPv6 options of this type are basically undefined at the moment.

(No comment from me; I can't speak for the IPv6/6MAN WG or the IESG.)

> codepoints is required.

(No comment; I can't speak for any of the Powers That Be.)

> It is not obvious why one couldn't just ask

In fact, I believe this IS roughly the question the IESG was hoping
to see answered, but perhaps with the sense inverted.

	"Does this WG object to granting this IPv6 option a codepoint ?"

> instead of "do we grant this codepoint for this purpose by approving

This second question you wrote (above) is not MY understanding
of this discussion/proposal on this mailing list.

To be really honest, I do not perceive a huge difference between
the two phrases you used.  I gather that to you there is a huge
difference there, and so I am partly confused.

BOTTOM LINE:

The MLS user community is seeking only 2 things, which frankly
I thought would be procedurally much simpler than it has been
so far (speaking as someone who has been active with the IETF
for 20+ years):

	1) an open specification; to achieve this,
	   nearly any form of RFC would suffice.
            The MLS community does NOT seek an IETF endorsement.

	2) an official code point for the IPv6 Option,
	   purely for interoperability reasons.

I've followed the various IESG instructions about how to proceed,
as best I understood them, and as those have evolved over time.
The most recent input seemed to say that this document ought to be
an individual submission Informational RFC (which we are quite
happy and comfortable with :-).

(Simply getting to version -11 of this I-D recently reflects the
large number of document edits that we've been making recently
based on various feedback.)

We are flexible about how to get to the two objectives that
I've outlined just above.   It would be helpful to understand
whether there are specific edits that would resolve your concern,
and if so what edits you are proposing for which part of the
draft.

Yours,

Ran Atkinson
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Mar 2009 13:08:32 +0200 (EET)

> What words would you like to see added ? and where in the draft ?

An IESG Note could be added on the front page of the draft and it 
could be e.g.:

IESG Note

       This RFC is not a candidate for any level of Internet Standard.
       The IETF disclaims any knowledge of the fitness of this RFC for
       any purpose and in particular notes that the decision to publish
       is not based on IETF review for such things as security,
       congestion control, or inappropriate interaction with deployed
       protocols.  The RFC Editor has chosen to publish this document at
       its discretion.  Readers of this document should exercise caution
       in evaluating its value for implementation and deployment.  See
       RFC 3932 for more information.

(From RFC3932 Section 4)

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 20 Mar 2009 14:53:34 -0400

>       RFC 3932 for more information.

The authors and the MLS community would have no objection to the IESG
adding the note that is indented and quoted above, should the IESG
choose to add it.

Yours,

Ran
[email-masked]

---

From: Tim Polk <[email-masked]>
Date: Sun, 22 Mar 2009 09:40:54 -0700

Lars & 6man,

(Sorry about the slow turn-around here... I spent last week attending  
to non-IETF business, I'm afraid.  Bad time for the boss to go  
skiiing...)

This document is an AD-sponsored individual submission, and is  
intended for publication as an Informational RFC on the IETF stream.

As you know, I originally wanted to publish this document on the  
standards track.  That was my preference; the authors were ambivalent  
with respect to Standards track vs. Informational.  Based on the  
results of the IETF Last Call, I was convinced that I had overstepped,  
and am now requesting publication as an Informational RFC.   
(Publication would be on the IETF stream, as opposed to an independent  
submission to the RFC Editor).

A question has also been raised regarding decisions made by the IESG  
on this document.  IMHO, the IESG has made no *decisions* with respect  
to this document.  Individual ADs have entered positions on this  
document, and a final decision is still pending.  My request for the  
last call in 6man is based on my *interpretation* of other ADs'  
comments and discusses, which
indicated that additional community input was needed before they would  
be entirely comfortable with this approach.  Based on the wg response,  
I hope that we will be able to resolve the outstanding concerns within  
the IESG and achieve consensus.

My apologies to the authors and the wg about the confusion... I  
suspect my imprecise use of 2026 language when describing the  
discussion on a telechat is at the heart of this confusion.  I am  
looking forward to the results of the wg's consideration of this  
specification.

Thanks,

Tim Polk

On Mar 16, 2009, at 9:42 AM, Lars Eggert wrote:

> Tim,
>
> can you please clarify to me and 6man what the status of this  
> document is? First it was AD-sponsored PS, then AD-sponsored Info,  
> and now Ran says it's not an IETF document at all anymore?
>
> Thanks,
> Lars
>
> Begin forwarded message:

---

From: Lars Eggert <[email-masked]>
Date: Wed, 25 Mar 2009 10:20:42 -0700

Hi,

after the mailing list discussion and the discussion at 6MAN  
yesterday, I changed my ballot from a discuss to an abstain. Thank you  
all for providing valuable feedback.

Lars