Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.txt

[James Carlson <[e-mail]>]

On 04/01/11 09:20, William Allen Simpson wrote:
> On 3/31/11 11:37 AM, James Carlson wrote:
>> (In other words, there's no way I'm going to add any documentation about
>> IS-IS security issues.  That's *way* out of scope, and I'm simply
>> guaranteed to get it wrong.  If not now, then certainly over time.  But
>> references to RFC 1994 or 1968 or some such would be OK, though I think
>> it might be bordering on pedantic to force each new PPP RFC to direct
>> implementors to these documents.  Real implementors -- or at least
>> modestly competent ones -- know that they've got to look through more
>> than one RFC to do the job, depending on circumstances.)
>>
> You are certainly more parsimonious with references than I've ever been!
> Coming originally from an academic environment, I've always made
> reference to any "current" or even "interesting" related documents. :-)
> 
> Protocol specifications *should* be pedantic: "concerned with minute
> details or formalisms, especially in teaching."
> 
> In this case, I'd mention "... PPP authentication (see [RFC1661] section
> 3.5) and IS-IS authentication [RFC5304] mechanisms ...."

You've left out encryption.  Why?  Certainly, for *some* users, it's a
crucial part of making the overall system secure in a way that no mere
authentication mechanism could hope to achieve.

It seems sort of obvious that someone implementing the protocol
described in this document, which already has a normative reference to
RFC 1661, should read the references and, where necessary, pay heed to
them.  Thus, reiterating that section 3.5 of 1661 is useful seems, well,
silly.  It's almost as if to say, "ignore the rest of 1661, but pay
close attention to this one random section."

I can add a generic reference to authentication and encryption
mechanisms -- depending on context, implementors may need one, the
other, or both to accomplish their goals -- but I think that's the
extent of what can be reasonably done in this draft.

> Anyway, it's easy to add during the RFC-Editor phase, assuming there's no
> other reason to resubmit an internet-draft.

So why not point users towards NEBS requirements or other random things
they may need when implementing a real system?  I think this can go way
too far, and my concerns are:

  (a) I'm not an expert in IS-IS security issues, so it's almost
      a given that I'll get any directives here wrong.  I think
      it's worse to provide misleading information than to assume
      that implementors are required to have some domain expertise.

  (b) The security issues will undoubtedly change with time, and
      having random snapshots of the state-of-the-art buried into
      immutable RFCs simply makes the problem worse.  If someone
      wants to write a canonical "how to secure your IS-IS system"
      BCP, then I think that'd be great, and I'd be willing to
      point to the BCP number, since unlike RFCs, those *can* be,
      updated.  But it's not this document.

  (c) Neither am I a system security expert.  Undoubtedly, there
      are top-level network and system design issues that need to
      be considered in order to determine which features are
      _actually_ needed in order to provide an expected level of
      safety.  But I don't enough about those issues, and they are
      in any event well out of scope.

  (d) Plain old mission creep.  This is supposed to be a document
      describing how TRILL is mapped into PPP.  It's not an IS-IS
      tutorial.  It's not even a "how to build a PPP link layer"
      solution.

I fail to understand why at each minor revision of the document, I'm
being asked to increase the scope arbitrarily and bloat it out with only
tangentially related text.  I'm trying hard to be accommodating, but
this is really stretching the bounds, and I think the result is worse
for the wear.

-- 
James Carlson         42.703N 71.076W         <[e-mail]>