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

[[e-mail]]

Keith,

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

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

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

I agree - both of these should be done.

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

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.

> (Aside: MIB objects which are powerful enough to slow down the rate of
> 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 also found a number of editorial concerns:
>  
> I'll make all of your editorial suggestions.
> 
Great.

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