Subject: Issues from -07 resolved (was Re: draft-stjohns-sipso-*)

From: Suresh Krishnan <[email-masked]>
Date: Tue, 03 Mar 2009 10:13:27 -0500

Hi Folks,
   The issues I raised on version 07 of this draft have been fixed in 
version 09 of the draft.

Cheers
Suresh

On 11/02/09 06:46 PM, Suresh Krishnan wrote:
> 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-masked]
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------