Subject: draft-stjohns-sipso-*

From: RJ Atkinson <[email-masked]>
Date: Thu, 05 Feb 2009 18:54:44 -0500

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-masked]

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 11 Feb 2009 18:46:48 -0500

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:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Feb 2009 07:26:18 -0500

> its natural 32 bit boundary.

First, please let me note that I am not religious about this.

Users are concerned about throughput lost due to overhead.[1]  This
option is already potentially large (example: when the bitmap field
is large).  Packets with this option are known to be used routinely
over lower bandwidth links (e.g. IP over 2.4 Kbps HF radio) where
2 bytes might matter.  Ordinary IPv6 is already operationally
challenging on such links (even with header compression), but
those link types are not going away (in fact, HF radio deployment
reportedly is growing these days, after a reported decline in
IP/HF deployments in the late 1990s).

So I can better understand your inputs, it would help to have
a bit of context:
	- Are you implementing this option ?
	- Do you have a MLS network deployment ?

Given the above, do you view the alignment question as a
show-stopper ?

Or can you live with the current alignment given the
very limited use of this option ?

> calipso option will be secured.

I assume you meant "Checksum field" above where you wrote "option".

The Checksum is present to provide integrity, not authentication.

As noted previously, IP packets containing this option are sent
routinely over low-bandwidth lossy radio links.  To be clear,
the links at issue are NOT mobile telephony links like GSM/LTE,
but instead military/emergency-service HF or VHF/UHF radio links.

IPv4 contains a header checksum that covers the existing MLS
label option(s).  Of course, IPv6 does not have a header checksum.
So the MLS users wanted to be sure that this option provided
its own integrity protection mechanism. [more discussion below]

> AH is present -> AH will detect the tampering as it covers the CALIPSO

Indeed, if used, AH would provide strong integrity and also
would provide authentication.

However, as the I-D notes already, operational experience with
existing IPv4 MLS deployments indicates that it is not
operationally viable to routinely use AH (or AH+ESP) end-to-end
to provide authentication & integrity to labelled MLS IP packets.
Since IPv6 IPsec and IPv4 IPsec areidentical, moving to IPv6
does not eliminate the operational issues (examples: crypto
processing overhead, key/SA management complexity) that impede
widespread use of AH (or ESP+AH) in MLS labelled network
deployments.

> recalculate the checkum and insert in the option

The checksum is present to improve the integrity of the option,
not to provide authentication.  Indeed, the selected checksum
is intentionally easy to compute, because users want the
checksum to always be present.  Implementers strongly preferred
to use an existing checksum that is not overly burdensome
computationally.

Requiring the checksum in all cases:
(1) simplifies software implementations slightly, but also
     simplifies the Verilog for a (potential future)
     hardware implementation of this option, [2]
(2) is not a significant computational burden for software
     implementations and has even less impact on (potential)
     hardware implementations of this option,
and
(3) makes the MLS user community happy.

> Section 9.2 IANA considerations

Please look at the -07 version of the draft, which was just
released late last week.  The IANA Considerations were
rewritten to completely follow inputs from an IESG member.

> range 0:0:0:1 to 0:255:255:255

That's a typo, but a very good catch.  The -07 version likely
has the same typo, which I will fix.

Thanks very much !

Yours,

Ran Atkinson
[email-masked]

[1] More user input and review has happened on this I-D over the
     past couple of years than I initially had expected.  I've had
     user inputs from a wide range of countries beyond North America
     -- multiple users in Europe and multiple users in Asia have
     provided very helpful review and input.

[2] As other notes to the IPv6 list indicate, the specification
     has been reviewed by, and is acceptable to, multiple actual
     implementers of this proposed label option.  As those folks
     also have implementations of the IPv4 label option(s), their
     inputs have been highly valuable.  The specification has
     also been reviewed by a specialist "packet processing"
     Verilog designer in the UK; he also is fine with the current
     specification in the I-D.

EOF

---

From: Ken Powell <[email-masked]>
Date: Mon, 16 Feb 2009 10:19:21 -0500

> very limited use of this option ?

The "Option Data" reference in the following text from the top
of draft-stjohns-sipso-07.txt page 27 may have caused some
confusion here.

    Following the nomenclature of RFC-2460, Section 4.2, the Option
    Data field of this option must have 4n alignment.[RFC-2460]

RFC 2460 describes option alignment requirements based on the
location of the Option Type field, not the Option Data field.

Ken

---

From: Ken Powell <[email-masked]>
Date: Mon, 16 Feb 2009 11:26:24 -0500

> location of the Option Type field, not the Option Data field.

Let me rephrase,

I've learned to expect alignment to be specified in terms of the
Option Type field per RFC 2460 page 10:

    The alignment requirement of an option is
    specified using the notation xn+y, meaning the Option Type must
    appear at an integer multiple of x octets from the start of the
    header, plus y octets.

I read your draft last week and thought there was a problem with
the "4n" alignment as well. I didn't realize you had specified
alignment in terms of "Option Data" until this morning.

Perhaps it would help if the text at the top of
draft-stjohns-sipso-07.txt page 27 said:

     Following the nomenclature of RFC-2460, Section 4.2, the Option
     Type field of this option must have 4n+2 alignment.[RFC-2460]

Ken

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 16 Feb 2009 11:43:14 -0500

>     Type field of this option must have 4n+2 alignment.[RFC-2460]

I am happy to make that edit.  It will appear in the next I-D version.
My apologies for the unconventional wording in the I-D until then.

Cheers,

Ran
[email-masked]