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

[Eric Gray <[e-mail]>]

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