Problems with Labeled IPsec, IKE and ECN

Problems with Labeled IPsec, IKE and ECN

[Paul Moore]

Hello All,

Bill Sommerfeld, a Sun engineer looking into implementing Labeled IPsec, ran 
across a problem with Linux's Labeled IPsec implementation[1].  The problem 
is that the IKE/IPsec attribute used to pass the SELinux context is also used 
as part of the Explicit Congestion Notification (ECN) specification[2][3].  

The ipsec-tools package currently defines the SELinux context attribute value 
as "10" in src/racoon/ipsec_doi.h (taken from v0.7):

    #ifdef HAVE_SECCTX
    #define IPSECDOI_ATTR_SECCTX                 10 /* V */
    #endif

However, in RFC 3168 section 9.2.1.1 the ECN attribute value is also defined 
as "10":

    A new IPsec Security Association Attribute is defined to enable the
    support for ECN congestion notifications based on the outer IP header
    to be negotiated for IPsec tunnels (see [RFC2407]).  This attribute
    is OPTIONAL, although implementations that support it SHOULD also
    support the SAD field defined in Section 9.2.1.1.
 
    Attribute Type
 
            class               value           type
      -------------------------------------------------
      ECN Tunnel                 10             Basic
 
    The IPsec SA Attribute value 10 has been allocated by IANA to
    indicate that the ECN Tunnel SA Attribute is being negotiated; the
    type of this attribute is Basic (see Section 4.5 of [RFC2407]).  The
    Class Values are used to conduct the negotiation.  See [RFC2407,
    RFC2408, RFC2409] for further information including encoding formats
    and requirements for negotiating this SA attribute.

Needless to say this is a problem and we need to move away from using the 
IKE/IPsec attribute value of "10" as soon as possible.  Further, simply 
picking a new number is not a good solution, we should really petition IANA 
to get an attribute number assigned for this purpose.  However, doing so will 
most likely require documenting the Linux Labeled IPsec design and submitting 
it to the IETF as a draft specification for approval[4].  If this is not 
possible we will need to start investigating alternatives as "poaching" 
existing standards is not a viable, maintainable solution.

[1] http://blogs.sun.com/sommerfeld/entry/poaching_codepoints
[2] http://www.ietf.org/rfc/rfc3168.txt
[3] http://www.iana.org/assignments/isakmp-registry
[4] http://www.ietf.org/rfc/rfc2860.txt

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problems with Labeled IPsec, IKE and ECN

[James Morris]

On Mon, 19 Nov 2007, Paul Moore wrote:

> Needless to say this is a problem and we need to move away from using the 
> IKE/IPsec attribute value of "10" as soon as possible.  Further, simply 
> picking a new number is not a good solution, we should really petition IANA 
> to get an attribute number assigned for this purpose.  However, doing so will 
> most likely require documenting the Linux Labeled IPsec design and submitting 
> it to the IETF as a draft specification for approval[4].

How likely is this approach viable, given the moratorium on ISAKMP/IKE v1 
features?

>  If this is not 
> possible we will need to start investigating alternatives as "poaching" 
> existing standards is not a viable, maintainable solution.

Note (from http://www.iana.org/assignments/isakmp-registry)

"The values 32001-32767 are reserved for private use amongst
cooperating systems."

If we can't get an official number for use with IKEv1, then perhaps this 
will be our only option.


- James
-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Problems with Labeled IPsec, IKE and ECN

[Paul Moore]

On Tuesday 20 November 2007 3:32:57 pm James Morris wrote:
> On Mon, 19 Nov 2007, Paul Moore wrote:
> > Needless to say this is a problem and we need to move away from using the
> > IKE/IPsec attribute value of "10" as soon as possible.  Further, simply
> > picking a new number is not a good solution, we should really petition
> > IANA to get an attribute number assigned for this purpose.  However,
> > doing so will most likely require documenting the Linux Labeled IPsec
> > design and submitting it to the IETF as a draft specification for
> > approval[4].
>
> How likely is this approach viable, given the moratorium on ISAKMP/IKE v1
> features?

I have no idea.  Although I would presume that the Labeled IPsec folks would 
want to provide IKEv2 functionality at some point.

> >  If this is not
> > possible we will need to start investigating alternatives as "poaching"
> > existing standards is not a viable, maintainable solution.
>
> Note (from http://www.iana.org/assignments/isakmp-registry)
>
> "The values 32001-32767 are reserved for private use amongst
> cooperating systems."
>
> If we can't get an official number for use with IKEv1, then perhaps this
> will be our only option.

This is one of the things I had in mind as an "alternative" but I think we are 
better served trying to get an attribute reserved.

-- 
paul moore
linux security @ hp

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.