Re: [imss] imss WG Last Call: FC-SP MIB

[Keith McCloghrie <[e-mail]>]

I agree.

Bert, that's one less MIB module for you to review, and there will be a
number of editorial changes associated with removing T11-FC-SP-CERTS-MIB
-- is it worth me making those editorial changes before you continue
your review, so that your review will check that I found all the ones
in the parts that you haven't yet reviewed ?

Keith.
 
> Keith,
> 
> At this juncture, I favor approach 3:
> 
> > 3. Decide that the value of the one extra piece of information
> > (t11FcSpCertUsage) is not important enough for this MIB to have any
> sort
> > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at
> > the present time.
> 
> The extra information classifies a certificate as authentication
> (entity has private key) vs. trust anchor (used to verify certificates
> presented by other entities) and indicates which of the certificates
> is the default.  Both of these are generic to certificates (i.e.,
> there's nothing special to FC that requires them), and hence
> arguably belong in a certificate MIB somewhere as opposed to an FC
> MIB.  In addition, I expect that the PKIX folks will probably have
> things to say about how to do certificate usage "right" which won't
> have much resemblance to what's in the MIB ;-).  Finally, starting
> work on trust anchor management is on the PKIX agenda for Vancouver,
> and hence staying out of that entire area is probably a prudent step
> towards getting this MIB done in the nearer future.
> 
> Unless there's objection from anyone else on the mailing list, I
> think we should just drop the CERTS-MIB.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:[e-mail]] 
> > Sent: Monday, November 26, 2007 12:21 PM
> > To: [e-mail]
> > Cc: Keith McCloghrie; Black, David; [e-mail]; [e-mail]
> > Subject: Re: [imss] imss WG Last Call: FC-SP MIB
> > 
> > 
> > Here are three alternatives for what we could do:
> > 
> > 1. Continue with the "dependency" as-is, but with the additional
> > note on compliance that you suggest.
> > 
> > 2. Generalize the "dependency" so that it doesn't actually refer to
> > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead says something
> > like:
> > 
> >   Prior to the definition of the T11-FC-SP-CERTS-MIB, work had started
> >   in the IETF to specify a set of MIBs for managing IPsec/IKEv2.  The
> >   work was far enough along for the definition of FC-SP MIBs to
> >   leverage them as prior work, and to define a small extension of
> >   importance in the Fibre Channel environment.  However, the approval
> >   process for the IPsec/IKEv2 MIBs was delayed such that the 
> > definition
> >   of FC-SP MIBs caught-up with and was expected to overtake those for
> >   IPsec/IKEv2.  In order not to create a dependency, this document
> >   defines only the extension, and it does so in a generic manner so
> >   that the extension can be applied to any MIB for IPsec/IKEv2, either
> >   the completion of the previously-begun work or any alternative which
> >   might begin in the future.
> > 
> > I think a simple technical change is all that is required to make the
> > definitions (in T11-FC-SP-CERTS-MIB) generic.  Specifcially, I suggest
> > we change syntax of t11FcSpCertPointer to be an OID, such that it can
> > point to any table, i.e.,  not only into the ipsaCredentialTable, but
> > also into any other MIB's table.
> > 
> > I think the above would allow the references to be Informational.
> > 
> > 3. Decide that the value of the one extra piece of information
> > (t11FcSpCertUsage) is not important enough for this MIB to 
> > have any sort
> > of dependency, and to decide not to define the T11-FC-SP-CERTS-MIB at
> > the present time.
> > 
> > Keith.
> > 
> >  
> > > W.r.t.
> > > > > One thing I do see that may need some action is the 
> > fact that this 
> > > > > document has normative dependencies on these 2 documents:
> > > > > 
> > > > > [IPSP-IKE-ACTION]
> > > > >      Baer, M., Charlet, R., Hardaker, W., Story, R., 
> > and C. Wang,
> > > "IPsec
> > > > >      Security Policy IKE Action MIB", 
> > draft-ietf-ipsp-ikeaction-mib-
> > > > >      nn.txt, work-in-progress, 19 October 2006.
> > > > > 
> > > > > [IPSP-IPSEC-ACTION]
> > > > >      Baer, M., Charlet, R., Hardaker, W., Story, R., 
> > and C. Wang,
> > > "IPsec
> > > > >      Security Policy IPsec Action MIB",
> > > draft-ietf-ipsp-ipsecaction-mib-
> > > > >      nn.txt, work-in-progress, 19 October 2006.
> > > > > 
> > > > > 
> > > > > However, I do not see that any IMPORT is done for those 
> > 2 IPSP MIB 
> > > > > modules, so maybe the dependency is not really normative?
> > > > 
> > > > I agree that such a "dependency" is a little risky, because I 
> > > > too submitted some comments on those MIBs.  The reason that 
> > > > I'm using quotes around "dependency" is because it is not the 
> > > > definitions in this MIB which depend on any definitions in 
> > > > those MIBs, but rather the explanation of why this MIB has 
> > > > the set of (certificate-related) objects that it does.  
> > > > Without such explanations, the definitions in this MIB would 
> > > > appear incomplete, and it seems to me that making it complete 
> > > > requires either:
> > > > 
> > > > 1. the reference to the IPSP MIB modules that it currently 
> > > > has, or 2. definition of new MIB objects which 
> > > > duplicate/overlap with the IPSP MIB modules.
> > > > 
> > > > Given that the IPSP MIB modules are still expected to get 
> > > > approved (in the future), then I'd say #2 is at least 
> > > > undesirable, and probably unacceptable.
> > > > 
> > > 
> > > yep... that sounds unacceptable. At the other hand, you may
> > > end up having you approved I-D in the RFC-Editor queue for
> > > many years to come waiting for the dependent IPSP MIB module
> > > documents to come through (sorry... even though there
> > > was a message about the status of IPSP MIB modules in August
> > > this year, I have seen no activity since. I keep being
> > > very pessimistic about a reasonable result in this space).
> > > 
> > > Maybe one of the ADs (possibly security ADs) can say something
> > > about this issue or about the "dependency". As long as the
> > > docs are listed as normative references, your doc will get
> > > block at the RFC-Editor gates till those normative docs are
> > > ready to become an RFC as well.
> > > 
> > > 
> > > > So, if you can provide guidance on how to reference the IPSP 
> > > > MIB modules in a way which avoids creating normative 
> > > > dependencies, then please do.
> > > > 
> > > 
> > > If I read your section 4.6, then it seems that the 
> > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the
> > > ipiaCredMngCRLTable are needed to manage CAs and CRLs.
> > > So that to me seems quite a dependency. Are you guys aware
> > > of how your implementations will/might run without those
> > > tables? Have they currently been implemented in prorpietary ways?
> > > Or have pre-RFC implementations been fielded? 
> > > 
> > > >From sect 4.6, it seems that your MODULE-COMPLIANCE ought to state
> > > that those tables from IPSP MIB modules have to be supported in
> > > order to let your MIB modules/security-features work, no?
> > > 
> > > Bert
> > > > Keith.
> > > > 
> > > > 
> > > > > I will find out when
> > > > > I read the whole FC-SP MIB document. Sofar I did notice:
> > > > > 
> > > > > - 4.8.6.  The T11-FC-SP-CERTS-MIB Module
> > > > > 
> > > > >    This MIB module specifies extensions to IPSP MIBs 
> > > > [IPSP-IPSEC-ACTION]
> > > > >    and [IPSP-IKE-ACTION] which are specific to Fibre 
> > Channel.  In
> > > > >    particular, it specifies one table, t11FcSpCertsTable, 
> > > > with a row per
> > > > >    certificate indicating how that certificate is being 
> > used, and
> > > > >    containing the "name" of the certificate.  This "name" 
> > > > can be used to
> > > > >    obtain information, which is independent of FC-SP, about the
> > > > >    certificate from the ipsaCredentialTable (and from the
> > > > >    ipsaCredentialSegmentTable if the certificate is 
> > longer than 1024
> > > > >    bytes).
> > > > > 
> > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231:
> > > > > 
> > > > >            Since FC-SP leverages a subset of IPsec and 
> > > > IKEv2 (see RFC
> > > > >            4595), a subset of the management 
> > information defined for
> > > > >            the use of certificates with IPsec/IKEv2 is also 
> > > > applicable
> > > > >            to FC-SP.  Thus, this MIB module leverages 
> > RFC wwww and
> > > > >            RFC xxxx for the management of certificates, CAs 
> > > > and CRLs.
> > > > >    -- RFC Editor: replace wwww with actual RFC number for
> > > > >    -- [IPSP-IPSEC-ACTION], and replace xxxx with actual RFC 
> > > > number for
> > > > >    -- [IPSP-IKE-ACTION] & remove this note
> > > > > 
> > > > >            Specifically, the information defined in 
> > this MIB module
> > > > >            consists of a pointer into the IPsec/IKEv2 
> > MIB modules,
> > > > >            plus minimal additional item(s) of 
> > information which are
> > > > >            considered to be important in a Fibre Channel 
> > > > environment.
> > > > > 
> > > > > So it does sound normative. So I have a warning:
> > > > > 
> > > > > I have been reviewing those 2 IPSP documents a few times 
> > > > over the last 
> > > > > (mmmm probably) 2-3 or 2-4 years, and I must warn you that 
> > > > the cycle 
> > > > > times on those documents are EXTREMELY slow. The 
> > current revisions 
> > > > > are:
> > > > > 
> > > > >    draft-ietf-ipsp-ikeaction-mib-02.txt
> > > > >    draft-ietf-ipsp-ipsecaction-mib-02.txt
> > > > > 
> > > > > which showed up as I-D on 10 Nov 2006, and both are still 
> > > > in Revised 
> > > > > ID needed. Those MIB documents are also pretty complex, and 
> > > > so if/when 
> > > > > a new revision will eventually show up (if at all), then 
> > > > whoever needs 
> > > > > to re-review will need a serious block of time to 
> > actually do so.
> > > > > My personal experience is pretty bad/sad with those 2 
> > > > documents, and I 
> > > > > must admit that I am completely de- or un-motivated at this 
> > > > point in 
> > > > > time to re-review them a again if/when they do show up. But 
> > > > possibly 
> > > > > Dan can convince me otherwise at that time.
> > > > > 
> > > > > Anyway, I just wanted the authors/editors/wg-chair and WG 
> > > > members to 
> > > > > be aware of this risky normative dependency.
> > > > > 
> > > > > Bert Wijnen
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: [e-mail] [mailto:[e-mail]]
> > > > > > Sent: Wednesday, October 10, 2007 2:18 AM
> > > > > > To: [e-mail]
> > > > > > Cc: [e-mail]; [e-mail]
> > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB
> > > > > > Importance: High
> > > > > > 
> > > > > > This is to announce an imss WG Last Call on the following 
> > > > MIB draft:
> > > > > > 
> > > > > >             MIB for Fibre-Channel Security Protocols (FC-SP)
> > > > > >                    draft-ietf-imss-fc-fcsp-mib-00.txt
> > > > > > 
> > > > > > This WG Last Call will run through 12 midnight 
> > Eastern Time on 
> > > > > > Friday, October 26, 2007 (your WG chair hopes to deal 
> > > > with Last Call 
> > > > > > results during the week of October 29th and hopes that 
> > > > any revisions 
> > > > > > can be completed prior to the November 19th Internet Draft 
> > > > > > submission cutoff for the Vancouver meeting).
> > > > > > 
> > > > > > Technical comments *must* be sent to the imss mailing list.
> > > > > > Editorial comments may be sent directly to the draft 
> > editor (but 
> > > > > > please cc: me):
> > > > > > 
> > > > > > 		Keith McCloghrie [[e-mail]]
> > > > > > 
> > > > > > In order to try to set a good example, I have completed 
> > > > my WG chair 
> > > > > > review of the MIB prior to announcing this Last Call.
> > > > > > 
> > > > > > I found two technical concerns:
> > > > > > (1) The MIB defines precedence values for traffic selectors
> > > > > > 	as opposed to implicitly presenting them in order of
> > > > > > 	precedence.  I guess this is ok, but Section 4.7 should
> > > > > > 	explain why this approach was chosen.
> > > > > > (2) Section 4.9 defines rate control for Authentication
> > > > > > 	failures on a per-fabric granularity.  That strikes
> > > > > > 	me as overly coarse, and I wonder if per-SA would
> > > > > > 	be a more appropriate/useful granularity.
> > > > > > 
> > > > > > I also found a number of editorial concerns:
> > > > > > 
> > > > > > Section 1, 2nd paragraph.  Remove the sentence starting 
> > > > with "This 
> > > > > > latest draft" or insert an instruction to the RFC Editor 
> > > > to remove 
> > > > > > it before publication as an RFC.
> > > > > > 
> > > > > > Section 3.1 - Delete "The" at the start of the first 
> > paragraph.
> > > > > > 
> > > > > > Should Section 3.5 and subsequent subsections of 
> > Section 3 all be 
> > > > > > subsections of Section 3.4 Security?
> > > > > > 
> > > > > > Section 3.10 - "To provide better scaling, the Switch 
> > Connectivity
> > > > > >    Objects are not Fabric-wide information such that they are
> > > > > >    distributed only to where they are needed."
> > > > > > 
> > > > > > "information such that they are" -> information, but are"
> > > > > > 
> > > > > > Section 3.10 introduces "Active Zone Set" but does not 
> > > > explain what 
> > > > > > this term means.
> > > > > > 
> > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs to explain 
> > > > the concept 
> > > > > > of "restricted" - how does a "restricted" entity 
> > differ from the 
> > > > > > corresponding unrestricted entity?
> > > > > > 
> > > > > > Thanks,
> > > > > > --David
> > > > > > ----------------------------------------------------
> > > > > > David L. Black, Senior Technologist
> > > > > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > > > > [phone]             FAX: [phone]
> > > > > > [e-mail]        Mobile: [phone]
> > > > > > ----------------------------------------------------
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > imss mailing list
> > > > > > [e-mail]
> > > > > > https://www1.ietf.org/mailman/listinfo/imss
> > > > > > 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > imss mailing list
> > > > > [e-mail]
> > > > > https://www1.ietf.org/mailman/listinfo/imss
> > > > > 
> > > > 
> > > 
> > 
> > 
> 


_______________________________________________
imss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/imss