From william.allen.simpson@gmail.com Fri Apr 1 06:18:55 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FAC3A6830 for ; Fri, 1 Apr 2011 06:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QY3Gy7Ikw3Og for ; Fri, 1 Apr 2011 06:18:54 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 8AD8C3A6819 for ; Fri, 1 Apr 2011 06:18:54 -0700 (PDT) Received: by iye19 with SMTP id 19so4082260iye.31 for ; Fri, 01 Apr 2011 06:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TwjSzk44KQimHrEvbdMb4P0lUHqelW5pYLQKOlrmk0c=; b=aJb3B2U9crR/OArdLKr0wCkfZjFlifunm5yM/LDf+a1L55lSaLXDgs/b1tz/pngjy1 /tM9qbZ/IUiCxhp/VUa5oH0ek3k99EDZtFkoUD6XZ5tUv8ugvwuekxPKTJ0z0GxAUjnj AZ6+4+E4fnAei/jHN7RKE3prqTyvPaIhpfiSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=DVd14QX7/WzHl5OEcJNg6/WB/9LDMXGmIM0aO6AKWTO0soIR6hY8L7/D8yWOTQgJ0b 9fsCVjGEfuaK0hT6MVYYnu0q8gE2RGtsc4apmUUve18GdRkzlgcWfmZ3IHgJ9Wby4HLq T417slhuWpjSYvtUk1NLaIjdI53Cv9TTy9+qY= Received: by 10.231.142.103 with SMTP id p39mr2615428ibu.178.1301664034600; Fri, 01 Apr 2011 06:20:34 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id i26sm1467100iby.24.2011.04.01.06.20.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 06:20:32 -0700 (PDT) Message-ID: <4D95D11F.602@gmail.com> Date: Fri, 01 Apr 2011 09:20:31 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: pppext@ietf.org References: <20110330194502.10758.85300.idtracker@localhost> <4D938FF9.7060607@workingcode.com> <4D9493E9.9050903@gmail.com> <4D949FD7.7000203@workingcode.com> In-Reply-To: <4D949FD7.7000203@workingcode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:18:55 -0000 On 3/31/11 11:37 AM, James Carlson wrote: > William Allen Simpson wrote: >> And there should probably be references to the >> appropriate RFCs in the security section, too. But those can be added by >> the RFC Editor. > > Adding a new NCP normally adds no additional security issues beyond the > usual "authenticate your links and/or encrypt traffic if the situation > warrants." Is that what you're referring to? If not, then please > provide more detailed references for what is "appropriate" here, and > I'll add them if they're reasonably in scope. > > (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 ...." Anyway, it's easy to add during the RFC-Editor phase, assuming there's no other reason to resubmit an internet-draft. From carlsonj@workingcode.com Fri Apr 1 06:58:28 2011 Return-Path: X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549B73A6836 for ; Fri, 1 Apr 2011 06:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USCHYaPqem5R for ; Fri, 1 Apr 2011 06:58:27 -0700 (PDT) Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 437A63A67FA for ; Fri, 1 Apr 2011 06:58:27 -0700 (PDT) Received: from [75.150.68.97] (carlson [75.150.68.97]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p31Dxx6F007642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2011 10:00:00 -0400 (EDT) Message-ID: <4D95DA5F.6000605@workingcode.com> Date: Fri, 01 Apr 2011 09:59:59 -0400 From: James Carlson User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 MIME-Version: 1.0 To: William Allen Simpson References: <20110330194502.10758.85300.idtracker@localhost> <4D938FF9.7060607@workingcode.com> <4D9493E9.9050903@gmail.com> <4D949FD7.7000203@workingcode.com> <4D95D11F.602@gmail.com> In-Reply-To: <4D95D11F.602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: carlson; whitelist Cc: pppext@ietf.org Subject: Re: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 13:58:28 -0000 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