[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internet Draft for explicit security labels in IPv6.
Kais,
>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.
>
> > >>>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.
> >
>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.
In this example, I think it makes more sense to have the security
labels carried by the application, not IP. What you are creating is a
multi-level secure TCP connection to carry the file transfer traffic.
Each file has a level bound to it by the client OS and you need to
maintain that label at the server. Thus the server has a means to tag
entries in the file system and that seems like the right place to
make the labels visible. If the labels are per packet, and you rely
on the OS to keep the data separated, then you would be demuxing the
data stream into a lot of processes anyway, if you did it on a per
level and per category set basis, which is something you seem to
reject above.
Steve
References: