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

From: Keith McCloghrie <[email-masked]>
Date: Wed, 10 Oct 2007 14:38:02 -0700 (PDT)

David,

> 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.

Thanks for your review. 

> 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.

This point has a bearing on two issues related to the use of Precedence
objects in an INDEX clause.  First, the question of whether an object
containing a Precedence value should be in an INDEX clause or not.
There are pros and cons:

pro: having a Precedence object in a table's INDEX clause allows the
     table's rows to be retrieved (by SNMP getNext/getBulk) in order
     of Precedence.
con: in a read-write/create table, objects which are not in the INDEX
     clause can be modified with a single PDU (SNMP setRequest), but an
     object in an INDEX clause can only be changed by deleting its row(s)
     and creating new row(s); this is not only two SNMP PDUs, but also
     there is a "gap", a time-period between the two, and for a Security
     MIB during such a gap, there is either too much or too little
     security, where "too little" is likely a security hole.

Note that the "con" applies only to read-write/create tables, and so
having t11FcSpSaTSelNegOutPrecedence in the INDEX clause of the
(read-only) t11FcSpSaTSelNegOutTable table is justified by the pro.

There are two other xxxPrecedence objects, t11FcSpSaTSelDrByPrecedence
and t11FcSpSaTSelPropPrecedence, which are both in read-write/create
tables, but one of them is in an INDEX clause and the other is not.
As far as I can remember, this difference was created inadvertently,
and I'm unable (at present) to think of any reason to justify the
inconsistency.

The second issue is that, when a Precedence object is used in an INDEX
clause, its value serves not only as an indication of precedence, but
also to distinguish one traffic selector from another.  In other words,
Precedence values in INDEX clauses in this MIB have two functions:
"Traffic Selector index" and "Precedence vaue".  So, the choice of
whether such an object is called a "Precedence" or a "TrafSelectorIndex"
is a terminology issue, not a structural issue.   Its use in the INDEX
clauses clearly indicates its purpose as an index, without it being
so named explicitly.  Thus, I think a greater increase in clarity is
achieved by naming it as xxxPrecedence.

So, I think the document should be changed in two ways:

1. t11FcSpSaTSelDrByPrecedence and t11FcSpSaTSelPropPrecedence should
be made consistent, either have both in their respective table's INDEX
clause, or, neither in their respective table's INDEX clause.  Further,
I'll make a suggestion based on my expectation of the likely usage of
this MIB; specifically, that the majority of the expected usage of this
MIB will be for read-only monitoring, with 
its capability for read-write configuration rarely implemented, and
even more rarely used.  Thus, I recommend that we optimize for reading,
not for writing.  Thus, I recommend we combine the semantics of
t11FcSpSaTSelPropPrecedence and t11FcSpSaTSelPropIndex with the former
taking the latter's place in the INDESX clause of the
t11FcSpSaTSelPropTable table.

2. that I add words (a subset of the above) to section 4.7 so as to
provide an explanation of the use of Precedence values in INDEX clauses.

> (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 think the question here is whether it's likely that authentication
failures will occur on many SA's at the same time -- if it is likely,
then per-Fabric rate control allows for plenty of notifications in
isolated cases without getting overloaded when many SA's have the
problem.  But, if there's no correlation between occurrences on
different SA's, then the odds of many SA's having the problem at the
same time is presumably negligible, and I agree that per-SA would be
better.

(Aside: MIB objects which are powerful enough to slow down the rate of
Authentication failures is, unfortunately, wishful thinking :-).

> I also found a number of editorial concerns:
 
I'll make all of your editorial suggestions.

Keith.

> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 

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

---

From: [email-masked]
Date: Thu, 11 Oct 2007 01:23:09 -0400

Keith,

> achieved by naming it as xxxPrecedence.

I appreciate the explanation, and agree with your line of reasoning.

> taking the latter's place in the INDEX clause of the

I agree - both of these should be done.

> same time is presumably negligible, and I agree that per-SA would be

I think this also revolves around the number of SAs.  I would expect
FC-SP SA usage to be more akin to a site-to-site VPN (small number of
SAs carrying large amounts of traffic) than a remote access VPN
(large number of SAs carrying smaller amounts of traffic).  That
should limit the size of a one-per-SA notification burst in practice.

I definitely agree with your concern about overload, as authentication
failures are relatively cheap to generate (e.g., attacker need not do
any crypto calculations), and hence causing a large number of such
failures in a short time period could be a denial of service attack
based on the work involved in generating the notifications.

OTOH, this text:

   For t11FcSpSaNotifyAuthFailure, rate control is achieved by
   specifying that it is generated only for the first occurrence of an
   Authentication failure on a particular Fabric within a time window.

strikes me as providing unwarranted help for an attacker trying
to cover her tracks - she opens an SA to the victim, generates
an authentication failure, thereby generating the first notification,
and can then attack other SAs for the same fabric within the time
window, since their notifications are suppressed.

Perhaps what's appropriate is a 2-level rate limiting structure:
- At most one notification per SA in the (settable) time window.
- At most <n> (new settable value) notifications per fabric in
	the same (settable) time window.

> Authentication failures is, unfortunately, wishful thinking :-).

That's my mistake - I meant to write "rate control for Authentication
failure notifications", but nonetheless, an authentication failure rate
limiting mechanism in this sort of situation involving many independent
authentications seems like a fine candidate for an April 1st RFC in the
tradition of the "evil bit" (RFC 3514).

> I'll make all of your editorial suggestions.
Great.

Thanks,
--David

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 11 Oct 2007 20:51:28 -0700 (PDT)

> ...

That sounds fine to me.

(FYI - I'm going to keep track of the changes we agree upon, and do all
the editing after the end of the Last Call.)

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 15 Oct 2007 11:54:47 -0700 (PDT)

Hi Bert,
 
> I am starting to take a look at this document.

Thanks.

> Will take a while. It has 249 pages and 6 MIB modules.

Understood, but the hope is that it will take less time/effort than
the cumulative time/effort of reviewing 6 separate documents.

> 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.

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.

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: [email-masked] [mailto:[email-masked]] 
> > Sent: Wednesday, October 10, 2007 2:18 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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 [[email-masked]]
> > 
> > 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.
> > 
> > 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.10 introduces "Active Zone Set" but does not 
> > explain what this term means.
> >