Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt

[Donald Eastlake <[e-mail]>]

Hi Eri,

Thanks for your comments. I agree that at least a reference to RFC
5881 should be added and probably some additional material on security
considerations.

I think you misunderstood my response to John Scudder where perhaps I
did not express myself clearly enough. I was just trying to say that,
as far as I can tell, the Security Directorate would not be concerned
that the material currently in the Security Considerations is in that
Section. I did not mean my comment to apply to any possible omission
from the Security Considerations section.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Mon, Jun 11, 2012 at 9:15 PM, Eric Gray <[e-mail]> wrote:
> Donald,
>
> I may regret weighing in on this, but I strongly agree with
> John's comment on the Security Considerations section below.
>
> The Security Considerations section needs an introduction
> that - at the very least - explains why the section only
> addresses authentication.  In fact, the section only talks
> about what authentication is to be used, without providing
> and indication of why.
>
> I personally doubt that the Security Directorate feels -
> as you say - that this is not significant.  The section
> should describe the security concerns associated with the
> protocol and/or encapsulations associated with this draft
> - either directly, or by reference.
>
> At the moment the section does not do this, even by giving
> a pointer to someplace else where some analysis has already
> been done.
>
> And this is not difficult to fix.  Minimally, the authors
> can point to Security Considerations in RFC 5881 (which,
> in turn, points to RFC 5880).
>
> RFC 5880, provides a very good analysis, IMO, and it makes
> sense for this analysis to be re-used by reference in this
> draft.
>
> --
> Eric
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of John G. Scudder
> Sent: Monday, June 11, 2012 5:03 PM
> To: Donald Eastlake
> Cc: Vishwas Manral; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt
>
> Hi Donald,
>
> Comments below only where I had something to say other than "OK". You can take that as read otherwise.
>
> On Jun 11, 2012, at 4:48 PM, Donald Eastlake wrote:
> ...
>>> Minor Issues:
> ...
>>> 4. In two places text like the following appears:
>>>
>>>  Is the M-bit in the TRILL Header non-zero? If so, discard the
>>>  frame.  TRILL support of multi-destination BFD Echo is beyond the
>>>  scope of this document.
>>>
>>> If multi-destination doesn't make sense in the context of TRILL, it
>>> is fine to exclude it by enforcing that the M-bit be zero. However,
>>> I normally parse "beyond the scope of this document" to mean
>>> something like "we may do it in the future but haven't worked it out
>>> yet". By forcing the M-bit to be zero, you're placing
>>> multi-destination *in* scope, inasmuch as you are actively
>>> forbidding it from being supported.
>>>
>>> Presumably the sentence about "beyond the scope" was meant to
>>> justify this decision. Perhaps the comment about "scope" should be
>>> dropped and a different justifying sentence used. (Or the sentence
>>> omitted altogether.)
>>
>> Multi-destination makes sense for TRILL. It is just not yet
>> standardized, as far as I know, for BFD. Perhaps the "beyond the
>> scope" verbage should be removed and a note added somewhere such as
>> "(Multi-destination BFD is a work in progress [...].)"
>
> By requiring the M-bit to be zero you effectively preclude the later introduction of multi-destination, do you not?
>
>>> 5. Presumably the Security Area reviewer may raise this, but the
>>> Security Considerations section seems to be misused. My
>>> understanding (confirmed by referring to RFC 3552 Section 5) is that
>>> the Security Considerations section is intended to be an analysis of
>>> issues that arise from the operation of the protocol defined in the
>>> rest of the document, including but not limited to the security
>>> features of that protocol.
>>>
>>> This document's Security Considerations section instead specifies
>>> how authentication is to be done, though it doesn't provide an
>>> analysis of it or of any broader issues. I presume the section
>>> should be retitled (e.g., to "Authentication") and a proper Security
>>> Considerations section added.
>>>
>>> (This would probably be a "major issue" if I were the Security Area
>>> reviewer, but I'm not.)
>>
>> As far as I can tell (and I'm a member of the Security Directorate),
>> the Security Area considers this a non-issue. However, I've got no
>> problem with moving this material to a new "Default Authentication"
>> section or the like.
>
> OK.
>
> (As an aside, if the Security Directorate considers this a non-issue, maybe it's time to revise RFC 3552? I say this as an occasional author of Security Considerations sections and not with regard to your draft.)
>
> --John