headers
RJ Atkinson | 4 Feb 2009 16:16
Favicon

draft-stjohns-sipso-*

Hi,

The quoted note below was sent out to IETF-Announce back
in late September.  Looking back retrospectively, the
6MAN WG list probably should have been explicitly BCC'd
by the powers that be, back then, for the benefit of any
folks who aren't on the IETF-Announce mailing list,
since this relates to a (special purpose and limited use)
IPv6 option proposal.

(It is entirely likely that (most) folks here read the
original IESG announcement below back in September.  So,
perhaps, there is little news in this note. :-)

As far as I know, the IESG have not reached a decision on
this matter as of yet.

I made edits in early December in response to the sundry
Last Call comments received.  I am planning to make another
editing pass this weekend, so if there are questions or
suggested edits it is not too late.

As I am not on the 6MAN WG mailing list myself, I'd be
greatly obliged if folks could please explicitly copy
me on any comments that they might have on this draft.

Thanks very much,

Ran Atkinson
rja <at> exxtremenetworks.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
RJ Atkinson | 6 Feb 2009 00:54
Favicon

draft-stjohns-sipso-*

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Ed Jankiewicz | 6 Feb 2009 15:57

Statement supporting publication of draft-stjohns-sipso-* as Proposed Standard

Regarding draft 
http://www.ietf.org/internet-drafts/draft-stjohns-sipso-06.txt, I 
believe some of the folks I support would be quite interested in seeing 
this published to provide an IETF standards-based definition for MLS in 
IPv6.  This provides parity with an obscure but important IPv4 
capability.  Parity with IPv4 capabilities (i.e. first do no harm) is a 
stated pre-requisite for some organizational policy on deciding when it 
is permissible to transition to IPv6. 

As always, I am expressing my own opinion, not speaking authoritatively 
for my employer or customer, and this should not be construed as a 
statement of intent to implement the capability described in the draft, 
but rather support for its publication as an individual submission RFC. 

Ed Jankiewicz

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Jarrett Lu | 11 Feb 2009 02:26
Picon

voice for support the IPv6 sipso draft

I have read this document, 
http://www.ietf.org/internet-drafts/draft-stjohns-sipso-06.txt ,
and I support publishing it as an RFC. My employer, Sun Microsystems, 
has shipped
products supporting this feature in IPv4 (as documented in FIPS-188) for 
well over a
decade, initially in Trusted Solaris and now in OpenSolaris Trusted 
Extensions. Our
customers have requested multilevel security (MLS) support in IPv6, and 
they want it
as an open standards, not a proprietary implementation. As a vendor of 
MLS technology,
we are likely to be an early adopter in implementing this specification 
in OpenSolaris.

Thanks.

Jarrett

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
rfc-editor | 11 Feb 2009 03:25
Favicon

RFC 5453 on Reserved IPv6 Interface Identifiers


A new Request for Comments is now available in online RFC libraries.

        
        RFC 5453

        Title:      Reserved IPv6 Interface Identifiers 
        Author:     S. Krishnan
        Status:     Standards Track
        Date:       February 2009
        Mailbox:    suresh.krishnan <at> ericsson.com
        Pages:      6
        Characters: 11754
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-6man-reserved-iids-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5453.txt

Interface identifiers in IPv6 unicast addresses are used to identify
interfaces on a link.  They are required to be unique within a
subnet.  Several RFCs have specified interface identifiers or
identifier ranges that have a special meaning attached to them.  An
IPv6 node autoconfiguring an interface identifier in these ranges
will encounter unexpected consequences.  Since there is no
centralized repository for such reserved identifiers, this document
aims to create one.  [STANDARDS TRACK]

This document is a product of the IPv6 MIB Working Group of the IETF.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason.Weil | 11 Feb 2009 21:24

W


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Thomas Narten | 11 Feb 2009 22:52
Picon
Favicon

Re: Standard status of RFC 3879

> I think that simply reclassifying 3879 as DS would be a Good Thing
> and requires minimal effort. 

Um, what would the interoperability test (required for advancing a
spec) actually contain?

Right. I thought so.  :-)

3879 is weird in that implementations don't have to actually do
anything... Partly, it was designed that way, as I recall, so that
existing implementations wouldn't become non-compliant. Also, you
don't "support" site locals, you just support addresses. There isn't
special code to handle them... (That was in fact, one of the problems
with them... you needed special code to handle them "right", which we
didn't fully specified, and no one in their right mind would
implemented anyway...)

The meat of 3879 (in terms of what is actionable) is:

   4.  Deprecation

   This document formally deprecates the IPv6 site-local unicast prefix
   defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10.  The
   special behavior of this prefix MUST no longer be supported in new
   implementations.  The prefix MUST NOT be reassigned for other use
   except by a future IETF standards action.  Future versions of the
   addressing architecture [RFC3513] will include this information.

   However, router implementations SHOULD be configured to prevent
   routing of this prefix by default.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian E Carpenter | 11 Feb 2009 23:36
Picon

Re: Standard status of RFC 3879

Well, yes, the "minimal effort" consists of writing an interop
report for something that sort of outlaws interoperation :-)

[Brian's standard gripe about RFC2026 being broken fits here.]

I still think it would be good to do, but not if it requires
non-trivial effort.

   Brian

On 2009-02-12 10:52, Thomas Narten wrote:
>> I think that simply reclassifying 3879 as DS would be a Good Thing
>> and requires minimal effort. 
> 
> Um, what would the interoperability test (required for advancing a
> spec) actually contain?
> 
> Right. I thought so.  :-)
> 
> 3879 is weird in that implementations don't have to actually do
> anything... Partly, it was designed that way, as I recall, so that
> existing implementations wouldn't become non-compliant. Also, you
> don't "support" site locals, you just support addresses. There isn't
> special code to handle them... (That was in fact, one of the problems
> with them... you needed special code to handle them "right", which we
> didn't fully specified, and no one in their right mind would
> implemented anyway...)
> 
> The meat of 3879 (in terms of what is actionable) is:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Suresh Krishnan | 12 Feb 2009 00:46
Picon
Favicon

Re: draft-stjohns-sipso-*

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"
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Moore | 12 Feb 2009 01:29
Picon
Favicon

In support of SIPSO/CALIPSO

Hello,

I wanted to send a quick note to the list in support of the latest 
SIPSO/CALIPSO draft.  I've been reviewing several versions of this 
specification and feel it addresses an important (albeit small) need for an 
IPv6 security label specification.  I would gladly support publishing the 
CALIPSO specification as an RFC so that the labeled security community has a 
well defined, interoperable spec it can use to move forward with IPv6.

As the labeled networking maintainer for the Linux Kernel I've been 
responsible for the implementation and support of IPv4 labeled networking 
protocols, FIPS-188 aka CIPSO, and I know how important this functionality is 
for the labeled security mechanisms (SELinux, Smack) which rely on it.  Linux 
currently lacks an interoperable form of labeled networking for IPv6 due to a 
lack of a recognized specification; the SIPSO/CALIPSO spec could change that 
if published.  I have started a prototype implementation of the CALIPSO spec 
with the intent of adding it to future Linux Kernel releases, assuming the 
spec is published.

Thanks.

--

-- 
paul moore
linux  <at>  hp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane