Message-Id: <200807261234.49003.paul.moore@hp.com>
Date:	Sat, 26 Jul 2008 12:34:48 -0400
From:	Paul Moore <paul.moore@...com>
To:	Joy Latten <latten@...tin.ibm.com>
Cc:	selinux@...ho.nsa.gov, gcwilson@...ibm.com, serue@...ibm.com,
	tjaeger@....psu.edu, linux-security-module@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [RFC 2/2] labeled ipsec internet drafts

On Friday 25 July 2008 1:55:13 pm Joy Latten wrote:
> 2nd internet draft for labeled ipsec based on IKEv2 and updated
> IPSec Architecture, rfc 4301.
>
> regards,
> Joy

Once again, I'm CC'ing the LSM and netdev lists.  Comments below.

> Network Working Group                                   J. Latten
> Internet-Draft                                          G. Wilson
> Intended Status: Standards Track                        S. Hallyn
> Expires: ?                                                    IBM
>                                                         T. Jaeger
>                                                        Penn State
>                                                         July 2008
>
>                     Security Label Addendum to IPsec
>                  draft-jml-ipsec-ikev2-security-label-00
>
>
> Status of This Memo
>
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six
> months and may be updated, replaced, or obsoleted by other documents
> at any time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress".
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on December, 2008.
>
> Copyright Notice
>
>    Copyright (C) The IETF Trust (2008)
>
> Abstract
>
>    This document describes the high-level requirements needed within
>    IPsec to support Mandatory Access Control (MAC) on network
>    communications. It describes the extensions to the Security
>    Architecture for the Internet Protocol [RFC4301] and the Internet
>    Key Exchange Protocol Version 2 [RFC4306]. It also describes the
>
>
>
> Latten, et al.             Expires ?                           [Page
> 1] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    negotiation of the security label for a particular Authentication
>    Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP)
>    [RFC4303] security association.
>
> 1. Introduction
>
>    In computer security, Mandatory Access Control usually refers to a
>    system in which all subjects and objects are labeled with a
> security context. The security context is comprised of a set of
> security attributes. The security contexts along with a system
> authorization policy determine access. Rules within the system
> authorization policy determine whether the access will be granted
> based on the security attributes of the subject and object.
>
>    Traditionally, MAC implied Multilevel Security (MLS) systems. MLS
>    utilizes a security context consisting of a sensitivity or
> security level and category. This document will refer to the security
> level and category as the security classiffication. In MLS, the use
> of a security classification allowed segregation of information thus
> facilitating data confidentiality.

See my previous comment in the other mail about "security label" 
versus "security context".

>    MAC systems have become more mainstream and is no longer just
>    associated with MLS. Within a strictly hierarchical system such as
>    MLS, often there are tasks that need to be exempt from the MLS
>    policy, thus leaving them exposed. However, methods such as Type
>    Enforcement (TE) are not hierarchical and allow precise rules to

I would recommend avoiding the "TE" acronym as many in the IETF already 
associate TE with Traffic Engineering.  If you don't mind calling it 
Domain Type Enforcement you can probably get away with "DTE".

>    be written about access using security attributes [MayMacCap]. TE
> can be used to control access these "exempt" tasks. A MAC system can
> employ both MLS and TE to control access. Such systems require
> additional security attributes besides the security classification
> used by MLS. For example, a domain type attribute may be used to
> control access in TE [MayMacCap].
>
>    These MAC systems concentrate on securing local objects and
>    resources but have no way of applying their security contexts to
>    network communications to ensure the same security when
>    communicating with homogenous systems.
>
>    Techniques such as IP Security Options (IPSO) allow IP datagrams
> to be labeled with a MLS security classification [RFC1108]. However,
> they do not accomodate additional security attributes such as the
> type in TE. MAC implementations requiring additional security
> attributes, such as SELinux, can use IPsec mechanisms to control
> access [LevIPsecMAC].

Once again, see my previous comments in the other mail.

>    This document will describe how IPsec mechanisms can support
>    MAC networking. It will also describe the additions to IKEv2 to
>    support communication of a security context during negotiations to
>
>
>
> Latten, et al.             Expires ?                           [Page
> 2] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    establish an AH and ESP security association.
>
>    Within this document, security label and security context refer to
>    the same thing. And MAC networking and labeled networking are
>    used interchangeably.
>
> 2. Terminology
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
> this document are to be interpreted as described in [RFC2119].
>
> 3. Labeled Networking
>
>    Within a MAC environment, the underlying security mechanism
> applies a security context to all the subjects and objects on the
> local system. The security context along with a MAC authorization
> policy determines whether a subject may access an object.
>
>    In labeled networking, a security context is applied to data
>    exported over the network. The MAC system can then use labeled
>    networking to make informed access decisions. Systems wishing to
>    communicate with each other must deploy the same MAC authorization
>    policy and security context for consistency.
>
>    IPsec mechanisms can support labeled networking whether implicit
> or explicit labels are being used.
>
>    Explicit labeling refers to transmitting the security context in
> the IP datagram, such as in IPSO. When explicit labeling is used the
> encryption and authentication services provided in IPsec can be used
> to authenticate the bindings between the security label in the IP
> header and payload and provide confidentiality [RFC2401].
>
>    In an implicit labeling scheme, the security context is not
>    transmitted as part of the IP datagram. IPsec provides implicit
>    labeling in that the security context is part of the IPsec
> Security Association and not transmitted with each packet.
>
> 3.1 Relationship Between a Security Association and Security Label
>
>    In MAC networking, the traffic between two systems may require
>    several different security contexts. For example, ftp and a mail
>    program may each label their data with a different security
> context. Recall that SAs exist in pairs, one for inbound and one for
> outbound.

It has been may years since my last in-depth reading the IPsec drafts, 
and most of them have been outdated anyway, but from what I remember 
there was no explicit requirement that SAs be created in pairs 
(inbound/outbound).  While this is certainly the common case for 
connection based protocols such as TCP, there is no bi-directional 
requirement for most connectionless protocols such as UDP.

> Each instance of a security label will require an SA pair. 

Question for you ... using the current SELinux implementation as a 
reference, when firefox makes a request to an apache server over 
labeled IPsec, what are the resulting SAs?  I would think that a 
firefox_t SA is created to convey the request from firefox to apache 
and an apache_t SA is created to convery the response from apache to 
firefox.  Is that the case?

If so, each instance of a security label only requires a single SA.

> Thus traffic between two systems may have several SA pairs with
> identical selectors except for the security context. If using a
> combination of

Considering both connectionless protocols and the above example, always 
requiring two SAs for each label seems wasteful.

> Latten, et al.             Expires ?                           [Page
> 3] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    ESP and AH, then there will be an ESP SA pair and an AH SA pair
> per instance of a security label.
>
> 3.2 Security Context Selector
>
>    [RFC4301] describes the Security Policy Database (SPD), and the
>    Security Association Database (SAD) and corresponding selectors.
>
>    MAC networking introduces an additional selector, the Security
>    Context selector. This selector is only required when MAC
>    networking is deployed.
>
>         - Security Context: MAC implementation's security context.
>           The security context can be an IPSO/CIPSO label when
>           IPsec is used to support explicit labels.

What happens in the case of traffic that is already explicitly labeled?  
Does the IPsec subsystem also apply an implicit IPsec label?  If so, is 
it derived from the explicit label?  What happens if the explicit label 
has a different DOI than what is configured in the SPD/SAD: 
translation, rejection, something else?

>    Recall, in MAC networking, multiple SAs may exist between two
>    systems differing only in their security labels. The Security
> Context selector ensures that the appropriate SA pair is used to
> secure a particular communication.

Just to clarify, this selector is only applied to outbound traffic, yes?  
The SPI and/or other network attributes still acts as the SA selector 
for inbound traffic, yes?

>    The Security Context selector within the SPD allows the system
>    administrator to specify which traffic streams will be authorized
>    to communicate within the system's MAC policy. It also specifies
>    which traffic streams will have labeled communications and which
>    will not.

This last sentence should be modified to make it clear that the SPD/SAD 
configuration only controls the use of implicit IPsec based labeling, 
unless you are talking about a departure from the current SELinux 
implementation.

> 3.3 Security Context Selector and PFP
>
>    [RFC4301] introduced and described Populate From Packet (PFP)
>    flags. When creating an SA, the PFP flag determines whether to
>    instantiate the corresponding selector in the new SA with
>    information from the packet that triggered the creation or from
>    information in the corresponding SPD entry.
>
>    In MAC implementations, the security context that will be
> associated with the new SA MUST NOT be the SPD entry's security
> context. The security contexts in the SPD entry and in the SA entry
> are to label two different objects respectively. The security context
> in the SPD entry controls access to the entry itself and it's IPsec
>    configuration information. Thus the SPD entry itself is considered
> an object. The SA's security context provides security attributes for
> the packet which can also indicate the security attributes of the
> sender or process. Keeping these separate allows a MAC implementation
> to control which packets may use a particular IPsec configuration.
>
>    Therefore, when using IPsec to provide implicit labels, the PFP
> flag must not be used to determine where to get the security context
> for the new SA.
>
>
> Latten, et al.             Expires ?                           [Page
> 4] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
> 3.4 Outbound Processing for MAC Networking
>
>    When consulting the SPD for an outbound policy, the data's
> security label is used to determine if it is authorized to access the
> particular SPD entry and use its configuration information for
> sending. This adds the additional check in that the outbound packet
> will not generate an SA pair that the policy entry does not allow. So
> for example, in an MLS implementation, a high secrecy process cannot
> generate an SA allowing it to send data to a low secrecy process.

The recent trend in the IETF, especially around security, is to leave 
nothing to chance; ambiguity in the specifications tend to be frowned 
upon.  I think there needs to be a more in-depth discussion of how 
security enforcement MUST (I use this in the RFC sense of the word) 
operate.  Of course this will be a bit tricky considering the flexible 
and arbitrary nature of type enforcement, but I think it is important 
if you hope to have a consistent labeled IPsec implementation across 
multiple platforms.

This applies to all of the traffic processing and enforcement sections 
of this document.

>    Similarly, when consulting the SAD to find an outbound SA, the
>    the data's security context is used to select the appropriate SA
> to send on.
>
>    In the case that a suitable outbound policy is found, but there
> isn't an SA, the message sent to the key management system to create
> an SA MUST contain the security label associated with the data. This
> allows for the key manager to create an SA pair with the correct
> security label for the data to be transmitted.
>
>    A MAC implementation MAY label it's interface and/or configured IP
>    address. If so, before forwarding the packet out to its
> destination, a check should be made that the outbound packet is
> authorized to send out on the interface and/or configured ip address
> [RFC2401].

Which IP address are you referring to, the source or destination?  Also, 
in the case of ESP tunnel mode, should the outer or inner IP header (or 
both) be checked?

> 3.4 Inbound Processing for MAC Networking
>
>    The use of the SPI to map IPsec protected packets to an SA ensures
>    we select the correct SA to process the inbound packet.
>
>    The MAC implementation MUST retain the binding between the data
>    received in the IPsec protected packet and the security label in
>    the SA used to process the packet. This is required so that
>    suitable MAC policy decisions can be made when delivering the data
>    to an application or when fowarding. The means for maintaining
> this binding are implementation specific. [RFC2401]

Once again, much more detail is needed here regarding the security 
enforcement mechanisms used.

>    A MAC implementation MAY label it's interface or configured IP
>    address. If so, the MAC implementation SHOULD check the inbound
>    packet's security label (as defined by the SA used to process the
>    packet) with the security label of the interface or configured IP
>    address before forwarding to upper-layer protocol or to
>    destination [RFC2401].

Same arguments as in the outbound case.

> 3.5 MAC Processing for Security Gateways
>
>    A security gateway enforcing MAC and using labeled SAs MUST follow
>
>
>
> Latten, et al.             Expires ?                           [Page
> 5] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    the inbound and outbound processing mentioned above as well as
> some additional processing particular to the intermediate protection
> of packets in a MAC environment [RFC2401].
>
>    A security gateway enforcing MAC MUST create and use appropriate
>    SAs to protect packets that it forwards for systems behind it.
>    [RFC2401] The systems behind the security gateway may or may not
> be using MAC. The gateway SHOULD utilize various attributes of the
> traffic and/or existing labels to determine the security labels for
> the SAs to be created and applied.
>
>    Similarly, such a gateway SHOULD accept and process inbound AH
>    and/or ESP packets and forward appropriately, utilizing various
>    attributes of the traffic and/or existing labels [RFC2401].

More explanation needed around how security policy is applied to traffic 
flowing through the gateway as well as how labeling is applied or 
removed based on network configuration.  This is way too vague for 
consistent implementations.

> 4. Security Context Transform
>
>    When the initiator requests a new SA to be created, the
>    security context is communicated in the information required for
>    the new IPsec SA. Security contexts are not communicated for
> IKE_SAs, only IPsec SAs.

I don't think you need the underscore.

>    The following transform definition is used to communicate a
> security context when creating the CHILD_SA in the IKE_AUTH exchange
> or when creating or rekeying an IPsec SA in the CREATE_CHILD_SA
> exchange.
>
>    The transform type value is:
>
>    Description        Transform Type      Used In
>    .................................................
>    Security Context       (?)6            ESP and AH
>
>    When using IPsec's implicit labelin, the existence of a security

I'd either add an apostrophe, "labelin'", or a "g", "labeling", ;)

>    context for the SPD entry indicates all SAs created by this entry
>    MUST be labeled. If an SPD entry does not have a security context,
>    then resulting SAs will not have a security context. Within MAC
>    it may be desireable that some network communications not be
> labeled and just protected by IPsec. For example, a security gateway
> enforcing MAC but the systems behind it do not. These SPD entries
> would not have a security context. However, when the security gateway
> talks to another security gateway, it may want to use implicit
> labeling. Therefore, the use of a security context with the ESP and
> AH protocols when MAC is enforced is optional.
>
>    Only one transform of type (?)6 is allowed per protocol. In other
>    words, you cannot communicate two different security contexts
> within a single SA payload being negotiated.
>
>
>
>
> Latten, et al.             Expires ?                           [Page
> 6] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    For Transform Type (?)6 (Security Context), the defined Transform
> IDs are:
>
>    Security Mechanism          Number
>    ...........................................
>    Reserved                     0
>    SELinux                      (?)1
>    Smack                        (?)2
>    Reserved to IANA             (?)3 - 1023
>    Private Use                  1024 - 65535

See my previous arguments about mechanism specific values.

>    The Transform Attribute Type:
>
>    Attribute Type       Value       Attribute Format
>    .......................................................
>    Security Context     (?)18             TLV
>
>    The attribute format is Type/Length/Value allowing for a variable
>    length security context.
>
>
>    The security context has the following format.
>
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    |     doi       |   security context (variable length)          |
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                   Figure 1: Security Context Format
>
>        - doi (1 octet) - The first octet contains the security
> label's domain of interpretation.
>
>          The domain of interpretation can be viewed as a group of
>          systems that agree on the meaning of particular values
> within the security label of a security mechanism.
>
>        Reserved        0
>        Default        (?)1
>        Private Use    (?)2 - 255

See my previous questions about the size of the DOI field.

>        - security context (variable length number of octets)
>          The actual content will be dependent on the security
> mechanism that is specified. Within IKE context, this is regarded as
> an opaque bit string.

See my previous comments about "bit string" versus "bit field".

> Latten, et al.             Expires ?                           [Page
> 7] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
> 4.1 Attribute Negotiation
>
>    The description of attribute negotiation in [RFC4306] is
> applicable also when using security contexts. In addition, only one
> security context transform (Type 6) is allowed per protocol. And if
> the initiator sends multiple proposals when negotiating an SA, each
> proposal MUST contain the same transform type and security context.
> In other words, a single SA negotiation should contain only one
> security context.

More detail about how to handle the negotiation would be an improvement, 
similar to my enforcement concerns.

> 4.3 CREATE_CHILD_SA Exchange
>
>    [RFC4306] describes the NO_ADDITIONAL_SAS notification.
>    This notification is sent by a responder who is unwilling to
> accept additional SAs on an IKE_SA or a minimal IPsec implementation.
>
>    Within MAC, the data transmitted between two systems may have
>    different security contexts. For example, ftp and telnet data may
>    each have their own security contexts. Each instance of a security
>    context requires an SA pair to support context granularity.
>    There may be multiple SAs with same selectors except for the
>    security context selector. A responder should be willing to accept
>    more than one SA on an IKE_SA in MAC networking.
>
> 4. Security Considerations
>
>    Some IPsec implementations may dynamically update the SPD.
>    If the responder does not have an SPD entry, the information
> within the SA payload is used to generate an SPD entry.
>
>    MAC networking may impose limitations on IPsec implementations
> that dynamically update the SPD. The security contexts associated
> with an SPD entry and an SA are for different purposes as described
> already in this document. Therefore, the security context in the SA
> should not be used as the security context for the SPD entry.
>
>    IPsec implementations that generate SPD entries during SA
>    negotiation and wish to enforce labeled networking will require a
>    mechanism for system administrators to specify the security
> context to be used for these SPD entries.

I think you need to specify how this would work.

>
>
>
>
>
>
>
>
>
>
>
> Latten, et al.             Expires ?                           [Page
> 8] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
> 5. IANA Considerations
>
>    This document contains several new numbers which are allocated
>    and maintained by the IANA registry.
>
>    - The Transform Type value for the security context.
>
>      Description             Transform type
>     -----------------------------------------
>      Security Context             (?)6
>
>    - The Transform IDs defined within the Security Context Transform
>      Type.
>
>      Name              Number
>     ---------------------------
>      Reserved              0
>      SELinux            (?)1
>      Smack              (?)2
>      Reserved to IANA   (?)3 - 1023
>      Private Use        1024 - 65535
>
>      Additional values may be assigned by IANA for the security
>      mechanisms requiring IKE to communicate its security label.
>
>    - The Security Context attribute type.
>
>      Attribute Type      Value      Attribute Format
>     -----------------------------------------------------
>      Security Context     (?)18           TLV
>
> 6. Acknowledgements
>
>    The authors would like to thank Stephen Smalley and James Morris
>    for their contributions during the initial design; and the members
>    of the SELinux community who have contributed to the development
>    and improvement of labeled ipsec and this specification.
>
> 7. References
>
> 7.1 Normative References
>
>    [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
>                 Requirement Level", BCP 14, RFC 2119, March 1997.
>
>    [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
>                 Internet Protocol", RFC 4301, December 2005.
>
>
>
> Latten, et al.             Expires ?                           [Page
> 9] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
>    [RFC4306]    Kaufman, Ed., "Internet Key Exchange (IKEv2)
> Protocol", RFC 4306, December 2005.
>
> 7.2 Informative References
>
>    [LevIPsecMAC]
>                 Jaeger, T., King, David., Butler, K., Hallyn, S.,
>                 Latten, J., Zhang, X., "Leveraging IPsec for
> Mandatory Per-Packet Access Control", 2006
>                
> http://www.cse.psu.edu/~tjaeger/papers/securecomm06.pdf
>
>    [MayMacCap]  Mayer, F., Macmillan K., Caplan D., SELinux by
> Example, Section 1.2.4, Prentice Hall, Upper Saddle River, NJ, 2007
>
>    [RFC1108]    Kent, S., "U.S. DoD Security Options for the Internet
>                 Protocol", RFC 1108, November 1991.
>
>    [RFC2401]    Kent, S., Atkinson, R., Security Architecture for the
>                 Internet Protocol, RFC 2401, November 1998.
>
>    [RFC4302]    Kent, S., "IP Authentication Header", RFC 4302,
>                 December 2005.
>
>    [RFC4303]    Kent, S. "IP Encapsulating Security Payload (ESP)",
>                 RFC 4303, December 2005.
>
>
> Authors' Addresses
>
> Joy Latten
> IBM
> email: latten@...tin.ibm.com
>
> George Wilson
> IBM
> email: gcwilson@...ibm.com
>
> Serge Hallyn
> IBM
> email: serue@...ibm.com
>
> Trent Jaeger
> Penn State
> email: tjaeger@....psu.edu
>
>
>
>
>
>
> Latten, et al.             Expires ?                          [Page
> 10] 
> Internet-Draft         IKEv2SecurityLabel                      June
> 2008
>
>
> Full Copyright Statement
>
>    Copyright (C) The IETF Trust (2008).
>
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
>
>    This document and the information contained herein are provided on
> an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
> WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
> RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
> PARTICULAR PURPOSE.
>
> Intellectual Property
>
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed
>    to pertain to the implementation or use of the technology
>    described in this document or the extent to which any license
>    under such rights might or might not be available; nor does it
>    represent that it has made any independent effort to identify any
>    such rights.  Information on the procedures with respect to rights
>    in RFC documents can be found in BCP 78 and BCP 79.
>
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use
>    of such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository
>    at http://www.ietf.org/ipr.
>
>    The IETF invites any interested party to bring to its attention
>    any copyrights, patents or patent applications, or other
>    proprietary rights that may cover technology that may be required
>    to implement this standard.  Please address the information to the
>    IETF at ietf-ipr@...f.org.
>
>
>
>
>
>
>
>
>
>
>
>
> Latten, et al.             Expires ?                          [Page
> 11] 

-- 
paul moore
linux @ hp
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists