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.
Kais.
> --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 PROTECTED]
--------------------------------------------------------------------
