[openib-general] IPoIB Loading and Starting

[Michael Krause]

At 03:11 AM 9/29/2004, Hal Rosenstock wrote:
>On Tue, 2004-09-28 at 11:38, Roland Dreier wrote:
> >     Hal> At IBA 1.2, C15-0.1.22 is obsolete and has been replaced by
> >     Hal> C15-0.2.1.  C15-0.2.1: When a requester node sends a trusted
> >     Hal> request to SA, the requested data shall be returned. When a
> >     Hal> requester node sends a non-trusted request for data to SA
> >     Hal> that would provide information about a subject node, the SA
> >     Hal> shall return only data providing information about subject
> >     Hal> nodes for which the requester shares a P_Key, with exceptions
> >     Hal> noted below in C15-0.1.23.
> >
> > Hmm, this seems like the only difference from C15-0.1.22 is that it
> > talks about trusted requests.  C15-0.1.23 (below) still says that
> > MCMemberRecords don't provide information about any subject nodes, so
> > I guess the SM should not worry about P_Keys when returning the table
> > of multicast groups.
>
>You are correct about the IBA 1.1/1.2 compliance difference (and the
>trusted request part is not relevant to this discussion).
>
>C15-0.1.22 does, however, talk about PKey sharing which is relevant to
>this (and consistent with 15.4.1 below).
>
>The intent is that the SA only return information relative to the
>partitions that the port was part of. The below is from IBA 1.1 (and 1.2
>as well):
>
>15.4.1 Restrictions on Access
>There are two types of access restrictions involved in SA:
>Authenticating the requester of information, and restricting the data
>that the requester is allowed to receive. These are discussed below. The
>SA access restrictions described here are based on partition membership,
>and are intended to implement this rule: If access to data is allowed by
>partition membership, that access is granted; but if it is disallowed,
>the requester should remain unaware of the existence of that information
>and of the network elements containing that information. Additionally,
>in no event is authentication information made available to untrusted
>requests. That a node s PortInfo:M_Key and PortInfo:M_KeyProtectBits may
>prohibit access to some data by SMPs without a valid M_Key has no
>bearing on SA access restrictions.
>
> >     Roland> C15-0.1.23: [...] MCMemberRecords shall always be provided
> >     Roland> with the PortGID, Join- State and ProxyJoin components set
> >     Roland> to 0, except for the case of a trusted request, in which
> >     Roland> case the actual component contents shall be provided.
>
>You omitted the following:
>C15-0.1.23: Subnet Administration shall follow the following additional
>rules concerning data access:
>
>Perhaps it is the language which is confusing and somewhat
>contradictory:
>
>C15-0-1.22 (IBA 1.1) and C15-0.2.1 (IBA 1.2) state "Subnet Administrator
>shall return only data providing information about subject nodes for
>which the requester shares a P_Key, with exceptions noted below in
>C15-0.1.23:."
>
>whereas:
>C15-0.1.23 states "Subnet Administration shall follow the following
>additional rules concerning data access" and one of those rules concerns
>MCMemberRecord.
>
>My interpretation is that the Pkey sharing is the first level rule

P_Key sharing and access is the first rule - no endnode should be able to 
acquire information unless it is authorized.

Mike

>before the following is applied from C15-0.1.23:
>"MCMemberRecords shall always be provided with the PortGID, Join- State
>and ProxyJoin components set to 0, except for the case of a trusted
>request, in which case the actual component contents shall be provided."
>which is what you are citing to say you get all the multicast records.
>
>-- Hal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20040929/0f148c67/attachment.html>