Hi Ran,
Very interesting read. I just had a couple of comments.
Section 5.1 : Option format
The alignment requirement for this option should be 4n+2 and not 4n as
mentioned in the document. This is required to align the CALIPSO DOI on
its natural 32 bit boundary.
Section 5.1.7 : CALIPSO Checksum
I do not see the real need for this option. I see two cases where the
calipso option will be secured
AH is present -> AH will detect the tampering as it covers the CALIPSO
option
AH is not present -> Attacker can tamper with the option and then
recalculate the checkum and insert in the option
Section 9.2 IANA considerations
* It is not clear what allocation policy IANA needs to follow for this.
Is it first come first serve or expert review. Well known IANA policy
definitions are described in section 4.1 of RFC5226. Consider using one
of these values to clarify things.
* This text
"DOI values beginning with decimal 0:0:0 are reserved for
private use amongst consenting parties; values in this range"
does not match up with the initial values table above that reserves the
range 0:0:0:1 to 0:255:255:255
Thanks
Suresh
On 02/05/09 18:54, RJ Atkinson wrote:
All,
Bob Hinden suggested that I send a follow-up note with a bit
more context so that the WG can more quickly get context on
this document.
Historically, there have been several IPv4 sensitivity label
option specifications (e.g. RFC-1038, RFC-1108, and FIPS-188).
Those IPv4 labels have never appeared on the public/global
Internet, as near as I can tell. This proposed IPv6 option
ought not ever appear on the public/global Internet either.
So its use is quite narrow. A typical deployment has bulk
encryptors protecting all of the labelled traffic whenever
it is outside a protected room/building/space.
So far as I am aware, the only host implementations of those
IPv4 options have been in "Multi-Level Secure (MLS)" operating
systems (e.g. Trusted Linux, Trusted Solaris). MLS operating
systems have "clearances" associated with each user on the
system, and have "sensitivity labels" associated with each
object (e.g. file) on the system. The MLS implementations
ensure that a user cannot read something above their maximum
clearance, for example.
When connecting multiple MLS workstations, clients, and servers
together on a network, there needs to be a way to convey the
Sensitivity Label that belongs to information (user data)
being transmitted between the sender and the recipient.
The IPv4 sensitivity label options fill that need for IPv4
deployments.
There is one known router implementation of RFC-1108, Cisco
IOS ("Classic IOS", as it were :-). While the Cisco is not
an MLS OS, it is a "label-aware" router and so can use the
RFC-1108 labels as part of interface-oriented Access Control
Lists.
For users of these MLS distributed systems, IPv6 cannot be
deployed operationally until an IPv6 sensitivity label option
is defined. So this document tries to fill that (very)
narrow gap. Operational experience with the IPv4 labels
has indicated that they were probably under-specified, which
is one of the reasons that this specification is a bit
more detailed than those were. Also, most of those earlier
specifications were somewhat US-DoD oriented, while this
specification is quite deliberately generic enough to be
used by any country or organisation.
Bob asked why this is defined as a Hop-by-Hop option. Simply,
it is hoped/desired by users that an IPv6 label-aware router
might exist so they can use that as they use the label-aware
Cisco IOS routers today. In order for a router in the middle
to "see" the label so that a label-oriented ACL can be applied,
the label information needs to be in a hop-by-hop option.
We have ~16 years of operational experience that RFC-1108 use
does not cause problems in the (few) environments where IPv4
Sensitivity Labels are/have-been deployed. Since those IPv4
options have hop-by-hop behaviours, that experience indicates
this approach should not create any new issues for IPv6.
The document discusses typical deployment scenarios towards
the beginning. Any folks who might be interested in this topic
will probably find it helpful to read the document from the
beginning, as there is a fair bit of explanatory material in the I-D.
The document is not a specification for building an MLS operating
system or an MLS stack. The document does explicitly reference
various published documents that do tell one how to build an
MLS operating system, however.
If there are any specific questions, I'm happy to try to answer
those, either on list or off list.
Thanks very much,
Ran Atkinson
[email protected]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
