Subject: Re: Internet Draft for explicit security labels in IPv6.

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 01 Mar 2001 16:44:44 -0500

In message <[email-masked]>, Kais Belgaied writes:
>>>It mandates a guarantee that the label on the IPv6 is authentic before trust
>in
>>>g
>>>it. In a link-local scope, where the label is proposed to be carried in the
>>>destination header, ESP is mandatory and sufficient.
>>>On a wider scope, AH is necessary.
>>
>>Or it could be bound to the certificate and recreated at the far end.
>
>It could, with the scalability limitation of implicit labeling.
>
I'm afraid I don't see the limitation.  The certificate itself could 
contain the label.

There are two cases, transport mode IPsec and tunnel mode.  In tunnel 
mode, as Kent pointed out, there is an inner IP header, option fields, 
etc.; in this case, the receiving gateway may wish to verify the labels
in the inner header, but need do nothing.

Transport mode is end-to-end, in which case the machine receiving the 
packet is either the ultimate end point -- in which case it can extract 
the label from the certificate and pass them up to TCP together -- or 
it's a bump-in-the-{wire,stack} on that machine.  In such cases, it 
should be quite straightforward to add the certificate's label -- if 
nothing else, it's already reassembling the packet to combine the IP 
header and the body, which were separated by the IPsec header.

		--Steve Bellovin, http://www.research.att.com/~smb

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 02 Mar 2001 18:33:59 -0500

I'm not sure what problem you're trying to solve, but:

 - The assumption in the draft seems to be that SA's are heavy-weight
objects.  this is not the case and it is certainly my intent to ensure
that they are as lightweight as possible within Sun's ipsec
implementation..

 - I agree with what Steve Kent's analysis -- if you are exchanging
multi-level tagged data over an transport connection, the processes on
both end had better be highly trusted to bypass MLS and thus you
should be able to get by labelling the connection as "system high" (or
some other appropriate concept) and using application-layer tagging
for the data inside.

I'd hate to see what you'd need to do to a TCP implementation and API
to carry through security label markings on arbitrary byte boundaries
within the streams on both ends.

 - I can see a couple different ways to handle communicating the label
through IKE.  As Steve Bellovin suggested, the simplest way is for the
appropriate label to end up in the certificate.  That clearly doesn't
scale in the case of the trusted multi-level applications you
described; in that case, it makes sense for the certificate to
describe a range of possible labels, and for an additional attribute
to show up in the IKE phase 2 exchange containing a specific label to
use for the traffic.

					- Bill

---

From: Kais Belgaied <[email-masked]>
Date: Fri, 2 Mar 2001 11:06:26 -0800 (PST)

First, I a gree with S Kent,  J. Hardwood and S. Bellovin on the ESP tunnel
mode (Thank y'all). I shall update the  draft to reflect the the
2 possibilities, AH (+ESP) in transport mode, and  tunnel mode ESP with the
label on the h-b-h of the inner header.

> header and the body, which were separated by the IPsec header.
Yes, it is feasable, but my understanding is that the certificate attributes
cannot be easily changed without re-negotiating it.
The limitation is regarding situations like the following example:
A backup server being accessed from remote multilevel secure hosts using an NFS
mount. The client (system being backed up) will be using one TCP connection
to the server, and the filesystems on both sides will be using the services of
an RPC layer that share the use of that single connection.
The data in the  client packets can come from
files at a very wide range of labels, and need to be preserved at the backup
file system. We can have one instance of the NFS daemon per possible label,
and one tcp connection at each label between the client and server.
The label is retreived from the certificate, so one certificate per sensitivity
is needed.
A typical sensitivity label has a classification 16-bits wide, and 240
category bits, that can combine to a big number. I'm afraid maintaining that
number of contexts, or switching back and forth between them can be too costly.

	Kais.