Subject: [tsv-area] Fwd: Secdir Review of draft-stjohns-sipso-05

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Oct 2008 16:55:05 +0300

FYI, this discussion on the main IETF list needs input from transport  
folks. Look at Section 7.3 of draft-stjohns-sipso-05.

Lars

Begin forwarded message:

> From: "ext Steven M. Bellovin" <[email-masked]>
> Date: October 2, 2008 16:31:29 GMT+03:00
> To: "Steven M. Bellovin" <[email-masked]>
> Cc: [email-masked], Sam Hartman <[email-masked] 
> >, [email-masked], [email-masked]
> Subject: Re: Secdir Review of draft-stjohns-sipso-05
>
> On Wed, 1 Oct 2008 22:12:17 -0400
> "Steven M. Bellovin" <[email-masked]> wrote:
>
>>>    Steven> Note 7.3.1 on
>>>    Steven> TCP considerations.  (Also note that 7.3.1 disagrees
>>>    Steven> with 793 on the treatment of security labels in section
>>>    Steven> 3.6 of 793.  At the least, this shoudl be noted.
>>>
>>> I had completely missed this.  I'll call out the section to the
>>> transport ADs
>>>
>> I should have added: I think the new document is in fact more correct
>> than 793 -- the 793 scheme would permit various forms of
>> high-bandwidth covert channels to be set up.  This is an issue that
>> was not nearly that well understood when 793 was written.  That said,
>> it is a change to TCP, and needs to be treated as such.
>>
> Thinking further -- I suspect that the right thing to do here is for
> someone to write a short, simple draft amending 793 -- it's handling  
> of
> the security option is simply wrong, independent of this draft.  I
> wonder -- what TCPs actually implement even 793?  NetBSD doesn't; I
> strongly suspect that no BSDs do.  Does Solaris?  Linux?
>
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Joe Touch <[email-masked]>
Date: Thu, 02 Oct 2008 10:24:06 -0700

Hi, Lars,

Are you suggesting we have that discussion there, or that they move this
issue here (e.g., to TCPM or TSVAREA)?

I would expect the latter would be more useful...

Joe

Lars Eggert wrote:
>> Cc: [email-masked], Sam Hartman
>> <[email-masked]>, [email-masked], [email-masked]
>> someone to write a short, simple draft amending 793 -- it's handling of

---

From: Lars Eggert <[email-masked]>
Date: Thu, 2 Oct 2008 21:36:40 +0300

I'd suggest over there. Or at least CC the folks that are on the  
current thread there, it's a pretty diverse set of people.

Lars

On 2008-10-2, at 20:24, ext Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi, Lars,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjlA7UACgkQE5f5cImnZrszXQCeNkIxxBZUmEjidZBxwF5RMaDg
> sgEAn3aoDE4kcBsV7kglGiXvKbRWZwK6
> =fiTu
> -----END PGP SIGNATURE-----

---

From: Lars Eggert <[email-masked]>
Date: Fri, 3 Oct 2008 10:15:00 +0300

Hi,

we've decided to migrate the discussion of draft-stjohns-sipso and its  
intersection with transport protocols to the SEC and TSV area lists.  
The draft is at http://tools.ietf.org/html/draft-stjohns-sipso:

	Common Architecture Label IPv6 Security Option (CALIPSO)

	This document describes an optional method for encoding
	explicit packet Sensitivity Labels on IPv6 packets. It is
	intended for use only within Multi-Level secure (MLS)
	networking environments that are both trusted and trustworthy.

For those of you who haven't followed the discussion so far on the  
main IETF list, Section 7.3 of this draft proposes that TCP and SCTP  
connections are now uniquely identified by a five-tuple consisting of  
source and destination IP addresses and ports as well as the  
sensitivity label. This is obviously a pretty significant  
architectural change that deserves discussion, especially since the  
deployment of this security label architecture is likely to be very  
limited.

Lars

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 06:58:13 -0700

Hi, all,

I've made several points on this matter on the original thread on the
main IETF list. I'll summarize a few below, in the context of Ran's
overview.

RJ Atkinson wrote:
> 
> On  3 Oct 2008, at 03:15, Lars Eggert wrote:
>> sensitivity label.
> There appear to be several points of confusion within Lars'
> note.  Please let me try to clarify what the draft actually
> says and doesn't say:
> 
> 0) Background about MLS operating systems:
>   I think a major point of confusion relates to multi-level
>   secure (MLS) operating systems, which most IETF folks have
>   never encountered and many have never even heard about.
>   In an MLS operating system, the OS provides mandatory
>   access controls that separate users and data according to
>   a lattice.  Users have "clearances", while data have
>   "sensitivity labels".   These labels primarily are two
>   dimensional.  One traditionally thinks of a vertical axis
>   consisting (bottom to top) as:  System Low, Unclassified,
>   Secret, Most Secret, System High.  One traditionally
>   thinks of a horizontal axis consisting of various compartments
>   (e.g. NATO, UK, RU).  The OS ensures that users with lower
>   clearances are not even aware of the existence of data
>   outside their clearance.

As noted in the draft, this is an update to the use of the IP security
option originally defined in RFC 791.

Interactions between that option and TCP were specified in RFC 793, and
this document changes that behavior very dramatically.

> 1) No change is proposed to TCP in general:
>   There is *no* proposal to change how TCP or SCTP connections
>   are identified or implemented for any system that does NOT
>   claim to implement this MLS label specification.

Granted that the IP security option is not *used* except on MLS
endpoints, but note that:

	- RFC 791 specifies that the IP security option must be
	implemented in all hosts and gateways; its _USE_ may
	be optional, but its *implementation* is not optional.

	- RFC 793 specifies current interaction with that
	option, and 1122 reinforces that interaction,
	which specifies behavior even when the option is
	not used in packets emitted by the host

There appears to be at least one change that might be required by all
Internet hosts; current behavior upon receipt of an IP packet at a
security level not supported is to send a TCP RST. This document
indicates that such hosts MUST silently drop such packets.

> 2) MLS operating systems have different requirements:
>   In turn, this specification *only* applies to Multi-Level
>   Secure (MLS) operating systems that choose to implement
>   this particular IPv6 labelling specification.  The draft
>   is very clear about this.

The draft does not appear to indicate how an MLS system would interact
with legacy systems that are not updated.

> 3) The MLS-specific proposal is accepted by long-term
>    members of the Transport community:
>    Please see Dave Borman's note to the IETF discuss
>    list from yesterday.  Dave has about as much TCP
>    experience as anyone.

I consider it very incomplete with regard to the impact of the changes
proposed on the architecture of MLS endpoints.

> 4) Nothing new is being proposed for the transport layer:
>   This shipped about 20 years ago.  So we have about 20
>   years of operational experience that the description in
>   this draft is correct for an MLS operating system.

I'm presuming that implementations prior to this update implemented the
IP option handling in RFC 793 and 1122. This document changes that quite
a bit.

...
> 5)  This draft doesn't propose to change the transport
>    architecture:

Section 7.3.1 requires that the transport architecture for MLS
endsystems uses a 5-tuple to identify TCP endpoints. That has
implications across the network architecture supported by MLS endsystems.

> 6) This draft has has broad review from users who have MLS
>    deployments and from implementers of MLS systems:

- ----

Overall, my concerns are that:

1. this document needs to address interactions with non-MLS updated
endpoints, and whether that needs to change

2. this document needs to explicitly indicate that it overrides RFCs
791, 793, and 1122 in allowing the implementation of changes to be
optional for hosts not *using* MLS

3. this document needs a much more extensive treatment of how it changes
the Internet architecture for MLS-updated hosts and gateways

I remain concerned that this last item is complex, and certainly
incomplete at this point.

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Oct 2008 10:40:04 -0400

> option originally defined in RFC 791.

More precisely, this is an IPv6 analogue to RFC-1038, RFC-1108
and CIPSO defined in FIPS-188, each of which caused that part
of RFC-791 to be deprecated.

Existing MLS operating systems generally support both
RFC-1108 and FIPS-188 for IPv4.  The goal of this draft
is to enable IPv6 to be supported in addition to IPv4
in an interoperable and openly-specified manner.

>        be optional, but its *implementation* is not optional.

To the extent that is true, that part of RFC-791 has been
ignored for more than 20 years by both host implementers
and router implementers.

So far as I am aware, no deployed IP implementation has ever
supported the RFC-791 security option.  (There might have
been some support in the early BBN routers or in MULTICS;
I'm not sure about details of either of those).

In the 1980s, RFC-1038 was created to support a specialised
security gateway called "BLACKER" because the RFC-791 definition
was not suitable.  (I believe all of the BLACKER systems have been
out-of-service for many many years now.)  Publishing RFC-1038
deprecated RFC-791's security option.

The only IP router that has had IP security option support
since about 1991 is Cisco IOS, which supports only RFC-1108
and (I am told and so far as I recall from looking at the
source code when I worked there) did not ever support the
RFC-791 definition of the security option.

On the host side, I am not aware of any non-MLS host that
ever had support for the RFC-791, RFC-1038, or RFC-1108
security options.

> indicates that such hosts MUST silently drop such packets.

*Nothing in the draft applies "to all Internet hosts".*

The draft is clear that nothing in the draft applies to any
system that does not claim to implement that specific draft.

I can repeat that scope comment in the document more times
if that helps, but it does already clearly say that in the
draft.

> with legacy systems that are not updated.

No changes to legacy systems are needed.

> I'm presuming that implementations prior to this update implemented  
> the IP option handling in RFC 793 and 1122.  This document changes  
> that quite a bit.

Those existing MLS implementations were the basis for the
current text in this document.  They did not follow either
RFC-793 or RFC-1122 in this narrow respect, to the best
of my knowledge.  (I have specific knowledge of kernel
internals for some, but not all, of the CMW products that
existed in the early 1990s.)

More broadly, (single-level OS) TCP and IP implementations
that are deployed today do not follow RFC-791, RFC-793, or
RFC-1122 in each and every detail.  For openers, I don't think
any implementations of the RFC-791 security option exist.

ASIDE:
   One of the reasons that the IETF hasn't produced either a
router requirements or a host requirements document for many
years is that the last attempts in those areas did not have
much impact, either on what implementers shipped or on what
operators deployed.

> implications across the network architecture supported by MLS  

The architecture is unchanged.  MLS TCP implementations do vary
somewhat, as Dave Borman already noted on the IETF discuss
mailing list.

When one has an MLS system, conceptually one has many concurrent
logically separate TCP implementations (one per sensitivity level).
This draft simply describes how one maps the existing (unchanged)
architecture onto an MLS OS implementation.

> endpoints, and whether that needs to change

I am happy to repeat in the draft that non-MLS systems
do not need to change.

> optional for hosts not *using* MLS

I can't parse that sentence, so I'm a bit confused.

I'm happy to edit the document text to repeat the note that
nothing in the document applies to any system that does not
claim to implement the document -- if that is what you are
asking for.

> the Internet architecture for MLS-updated hosts and gateways

This draft is not a specification for building an MLS operating
system, nor should it be.  Some relevant references on MLS
operating systems are included in the draft for those who
want to learn more about MLS operating systems.

Again, the Internet Architecture does not change.

What does change are some implementation details within an
MLS operating system (as compared with a traditional and
much more common single-level OS).

Yours,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Oct 2008 09:12:39 -0400

Hi,

   Circa 1992, MLS operating systems that implemented TCP
   in this way for IPv4 included at least:
	Digital Ultrix CMW
	IBM Trusted AIX
	SGI Trusted IRIX
	Sun CMW

   As of now, some of those folks have left the MLS OS
   business, but I believe existing MLS operating systems
   as of today that do this include at least:
	Trusted Linux (only if configured with an MLS policy)
	Sun Trusted Solaris

   I'm not as knowledgable about MULTICS as others here
   (e.g. Mike StJohns), but one imagines that MULTICS
   also had this approach within its TCP when MULTICS
   was deployed with an MLS policy enabled.

> This is obviously a pretty significant

   The draft simply describes how existing MLS operating systems
   implement multi-level security requirements within the
   existing transport-layer architecture.  This is the same
   implementation approach that it has been used for about
   2 decades now.

    The draft has existed for a couple of years now.  Comments
    on the draft from MLS-knowledgeable users have been received
    from many places on several continents.  Similarly, comments
    have been received from MLS-knowledgable implementers.
    Various changes have resulted from those comments and reviews.
    So within the MLS community there has already been significant
    review and consensus that this draft meets the needs for
    IPv6 deployments of MLS systems.

Yours,

Ran Atkinson
[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Oct 2008 07:32:44 -0700

> indicates that such hosts MUST silently drop such packets.

In a securely-configured MLS environment, systems not running an MLS
operating system will never receive a packet with an MLS label -- if
they did, that inherently means that an MLS system somewhere is
misconfigured and information is flowing in violation of the MLS policy.

It is IMHO not necessary to specify what a label-unaware system should
do with a labeled packet -- if they get one at all, it's a serious error
on the part of the sender.

> with legacy systems that are not updated.

are you asking about labeled or unlabeled interoperability?

the MLS systems I'm familiar with are configured with policy indicating
the clearances of other hosts.  That policy can indicate whether or not
packets to the other system should contain an explicit MLS label. 

non-MLS systems will typically never see a label.

> proposed on the architecture of MLS endpoints.

I have a modest amount of MLS implementation experience.  I believe the
spec is complete enough to publish in its current form.

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 08:10:43 -0700

Hi, Ran,

Thanks for the context below. Additional notes are interspersed.

...
> ever had support for the RFC-791, RFC-1038, or RFC-1108

It would be useful to understand "support". I would not expect most
deployed implementations to emit packets with that option, but I would
expect deployed implementations to check that option if it was received,
and match it as specified in RFC 793.

> if that helps, but it does already clearly say that in the

I expected to find that kind of phrase in any one of the following
locations, and did not (can you point it out if I missed it?):

	*- the abstract
	*- the intro
	*- intent and applicability
	*- definition of an endsystem
	*- definition of an intermediate system
	- architecture
	*- defaults
	- format

I didn't expect to see it in all locations, but certainly those with a *
above. AFAICT, the assertion is made only in sections 6.2 (end system
processing), and 6.3 (intermediate system processing), which is
insufficient IMO.

> No changes to legacy systems are needed.

It would be useful to note that in the *'d places above where the
limitations of the deployment would be stated.

> any implementations of the RFC-791 security option exist.

Agreed, but that doesn't mean these issues don't need to be addressed.

> much impact, either on what implementers shipped or on what

I'm not sure I agree with that. If that's the case, then why bother with
this document? I.e., if we're admitting that the Internet ignores the
IETF, we can spend more time golfing ;-)

> The architecture is unchanged.

I disagree - changing the endpoint IDs is a large change to the
architecture - even if scoped to affect only MLS systems, and this needs
to be addressed.

> MLS TCP implementations do vary

I'm asking that the document explain how MLS systems' view of 793 and
1122 rules for TCP change as well. Others pointed out the potential need
to "update" 793 regarding TCP changes; IMO this is needed for other
network architecture docs as well.

> want to learn more about MLS operating systems.

Agreed.

> Again, the Internet Architecture does not change.

I disagree; for MLS nodes, there are implications to ICMP processing at
least, and perhaps routing, that are not addressed. These are
architectural changes.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 08:13:01 -0700

> on the part of the sender.

Serious errors occur all the time. The expected behavior of the MLS in
interacting with a non-MLS endpoint should be explained *when* that happens.

> are you asking about labeled or unlabeled interoperability?

Both, since you brought it up, but I was originally thinking of unlabeled.

> non-MLS systems will typically never see a label.

Agreed, but (as above), this still needs to be explicit in this doc IMO.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 08:30:01 -0700

...
> spec is complete enough to publish in its current form.

If you follow the implications of " With respect to a given network,
each distinct Sensitivity Label represents a separate virtual network
which shares the same physical network.", and the way it impacts TCP,
can you explain how the current draft indicates how to similarly
virtualize any of the following?

- - ICMP handling
- - forwarding
- - routing
- - IPv6 neighbor discovery
- - IGMP
- - PIM
- - IPsec
- - IPIP tunnels
- - firewalls

All of these things use IP addresses as unique identifiers, and all are
affected by extending that space to use the pair [address, security
level] instead.

Even if these changes are limited to MLS endpoints, they either need to
be addressed, or the discussion of how MLS extends the endpoint needs to
be revised to avoid the idea that this virtualizes the network. If the
virtualization is limited to certain transport protocol connections,
then that should be stated explicitly (and only).

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 09:47:16 -0700

Steven M. Bellovin wrote:
> On Fri, 03 Oct 2008 08:30:01 -0700
> Joe Touch <[email-masked]> wrote:
> 
>> All of these things use IP addresses as unique identifiers, and all
>> are affected by extending that space to use the pair [address,
>> security level] instead.
>>
> Without trying to answer in detail, the basic rule is simple: no data
> with a given security label should ever be sent to or through an entity
> with a different label.  Routers and links are typically multi-label,
> so they can accept data within a range of levels.  A process will
> always be single-level, so it can only accept data -- TCP, ICMP
> replies, etc. -- at exactly the same level.  There are exceptions --
> IPsec boxes would (in that environment) be trusted to downgrade
> information, i.e., accept sensitive data, encrypt it, and send out the
> ciphertext packets with a different label.  IGMP poses a fascinating
> problem; I don't know that anyone has ever worked out the implications
> of doing that in an MLS environment.

Understood; the issue is that this document, if intended to extend MLS
into the architecture of MLS-enabled hosts, needs to be augmented
substantially to address these issues - even if to declare some out of
scope and not supported.

I don't know if it's tenable to assert that only the transport protocols
of interest are virtualized.

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Oct 2008 13:31:21 -0400

> and match it as specified in RFC 793.

I am not aware of any non-MLS TCP/IP implementation that checks
any flavour of the IPv4 security option (RFC-791, RFC-1038,
or RFC-1108).  So far as I know, non-MLS host implementations
don't even have code to parse any flavour of the IP Security
Option.

I am unaware of any non-MLS TCP/IP implementation that will
generate any flavour of that option.

According to Stevens in "TCP/IP Illustrated, Volume 2"
page 249, there is no support of any kind for the IP Security
options in BSD Net/3 and later.  He is silent on BSD
prior to Net/3 because that book is focused on Net/3
internals.  Of course, 4.4 BSD post-dates the Net/3
distribution.

Cisco routers running IOS do not check the option in their
default configuration.

All other routers that I am aware of can not do anything with
the option.  (There is a small possibility that the old
"Network Systems" brand routers could be configured to look
at RFC-1038 or RFC-1108 labels as part of a manually configured
ACL check, but there probably aren't any of those deployed now
or in recent years.)

Cisco routers running certain IOS versions that have been
explicitly configured to do so can use the RFC-1108 IP
Security Option as part of an Access Control List decision.

> locations, and did not

I am quite happy to add text to the Applicability
section clarifying this point.

> limitations of the deployment would be stated.

I am happy to make an edit along those lines.

> Agreed, but that doesn't mean these issues don't need to be addressed.

The broader question you raise of documenting which parts of
RFC-791 and RFC-793 are widely not implemented is far beyond
the very modest scope of this document.  Such a document
might well be useful, but it is well beyond the current
scope.

> I'm not sure I agree with that. If that's the case,
> then why bother with this document?

We have two specifications for IPv4 security options that
have some implementation and deployment (specifically
RFC-1108 and FIPS-188).  These have narrow deployments
in multiple geographies.  Those deployments normally
involve MLS operating systems.

We erroneously thought we would not need an equivalent
IPv6 option, but operational experience over the past
decade indicates that we do need an equivalent IPv6
option.

So this document fills that narrow gap (no openly specified
IPv6 sensitivity label option exists).

> I.e., if we're admitting that the Internet ignores the

The above is not what I said.

> network architecture docs as well.

I am confused how the above would translate into a specific edit.

> These are architectural changes.

We appear to have different definitions for "architectural",
which is perhaps not unusual for a community of this size.

Yours,

Ran Atkinson
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 3 Oct 2008 13:41:20 -0400

On  3 Oct 2008, at 12:47, Joe Touch wrote:
> into the architecture of MLS-enabled hosts, ...

It is not intended to do all that.

It is just trying to specify an IPv6 Sensitivity Label.
Certain implementation details need to be specified if
one wants to have interoperable MLS implementations.
This tries to specify only those that are really needed.

Cheers,

Ran
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Oct 2008 14:54:41 -0700

...
> I am confused how the above would translate into a specific edit.

You can't just redefine TCP's notion of an endpoint. You need to address
how this propagates through the protocol stack, notably:

	- ICMP handling
		does the ICMP carry the security level of the
		packet in its payload?

		does ICMP processing match the level of the
		incoming packet to the transport protocol?

	- forwarding
		should there be multiple forwarding entries,
		just as there are multiple TCPs for a socket pair?
		
		i.e., how much is the network really virtualized,
		or are you virtualizing only the host - and only
		for certain transport protocols
		(if so, then say that rather than virtualizing the net)

	- routing
		are there routing protocols that carry reachability
		only for certain levels? are those levels encoded in the
		routing protocol's packet headers, or in the
		routing protocol content (i.e., application data)
		itself?

	- similarly for multicast...

	- similarly for DHCP...

	- similarly for IPv6 neighbor discovery...

	- similarly for other items listed in response to Bill's
	email

I.e., if this is really a virtual network, there's a LOT of work left to
be done.

If this is restricted to only TCP, then ICMP needs to be addressed (or
else PMTUD won't work), at least (perhaps also DNS, e.g., SRV responses
might need to be at the appropriate level as well), and the description
of what is virtualized should be scoped down.

(I presume the latter is where you'd prefer to go with this, though
correct me if that's not the case).

Joe

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 3 Oct 2008 12:15:30 -0400

On Fri, 03 Oct 2008 07:32:44 -0700
Bill Sommerfeld <[email-masked]> wrote:

> do with a labeled packet -- if they get one at all, it's a serious
> error on the part of the sender.
> 
Actually, 793 disagrees:

  The security paramaters may be used even in a non-secure environment  
  (the values would indicate unclassified data), thus hosts in
  non-secure environments must be prepared to receive the security
  parameters, though they need not send them.

The question is how realistic that statement is.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 3 Oct 2008 12:41:48 -0400

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Oct 2008 10:38:23 -0700

> The question is how realistic that statement is.

As you probably would have guessed, I think it's entirely unrealistic.

						- Bill

---

From: Stephen Kent <[email-masked]>
Date: Mon, 6 Oct 2008 12:53:04 -0400

>misconfigured and information is flowing in violation of the MLS policy.

I'm not sure I agree with this statement, Bill.  A single-level or 
dedicated mode host MIGHT receive such packets IF an MLS hosts is 
configured to always send labelled packets.  Such hosts MIGHT be 
configured to accept and emit packets with a fixed secruity level, as 
part of an overall, local config policy.   Such systems, while not 
MLS, would not be label-unaware.  I am familiar with  plans that 
called for such behavior in the RFC 1108 context. Note that a BLACKER 
E2E crypto unit configured to support a single-level host would 
behave this way, but since the BLACKER was MLS (even though a host 
behind it might not be), that example does not exactly fit the 
description above.

Steve

---

From: Bill Sommerfeld <[email-masked]>
Date: Sun, 05 Oct 2008 17:40:18 -0400

> I.e., if this is really a virtual network, there's a LOT of work left to

All that behavioral description work is entirely independent of the
label encoding draft, and there is IMHO no rational reason to delay
publication of draft-stjohns-sipso-* (and the allocation of relelvant
codepoints by IANA) in order to document minutiae of behavior which are
better spelled out in separate drafts documenting the interaction of MLS
labeling and specific protocols.

						- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Oct 2008 10:38:23 -0700

- Bill

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 6 Oct 2008 21:53:25 -0400

On Sun, 05 Oct 2008 17:40:18 -0400
Bill Sommerfeld <[email-masked]> wrote:

> > I.e., if this is really a virtual network, there's a LOT of work
> > left to be done.
> 
> codepoints by IANA) in order to document minutiae of behavior which
> are better spelled out in separate drafts documenting the interaction
> of MLS labeling and specific protocols.
> 
I disagree -- I think there have been enough points raised on the
clarity of the threat model and some behavioral points that I think
more discussion is indicated.  Apart from that, it does prescribe
behavior at variance with the TCP standard.  (As I noted, I think this
document is more correct, but it nevertheless contradicts 793.)

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 03 Oct 2008 07:32:44 -0700

---

From: Joe Touch <[email-masked]>
Date: Mon, 06 Oct 2008 20:57:48 -0700

> document is more correct, but it nevertheless contradicts 793.)

I'm not entirely sure how to proceed. Here's the issue:

The goal of draft-stjohns-sipso-* appears to be limited to extending
endpoint identifiers primarily for transport protocols - TCP in
specific. I.e., it extends transport names (AFAICT).

That would make sense if there were security levels associated with
ports, as a TCP option. However, the draft is described as an extension
of IP, which implies a broader extension of the endpoint namespace (as
the document describes).

Here's the catch:

- - if the doc focuses only on TCP, then:
	a) the 'virtual network' description needs revision to focus
	on extending only the impact on transport, notably TCP

	b) ICMP needs to be addressed, i.e., either ICMP needs to be
	extended similarly, or the impact on TCP needs to be described.
	
	this means either:
		i) ICMPs would be potentially processed by the
		security level of the payload, not the header

	or	ii) TCP under MLS should assume ICMPs are black-holed,
		and thus should disable PMTUD.

	c) DNS needs to be addressed, notably how SRV records would
	work in this environment

- - if the doc really does need to extend the whole network to understand
MLS, then the impact on the whole network needs to be considered

	- this includes forwarding, routing, multicast, DNS, etc.

These are neither minutae nor can these issues be relegated to
supplemental documents. If you have a system based on what has been
written thus far, you're already making assumptions about the above
(some problematic, IMO), and you need to do more than just ignore these
elephants.

Joe