Re: [secdir] comments on draft-irtf-rrg-recommendation-14
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 29 October 2010 14:49 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9293A6A13; Fri, 29 Oct 2010 07:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.589
X-Spam-Level:
X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 av-tn+ZwQ5QB; Fri, 29 Oct 2010 07:49:18 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 5608A3A689D; Fri, 29 Oct 2010 07:49:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 563743E415D; Fri, 29 Oct 2010 15:51:10 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1288363870; bh=Z0su8k/EN+Bj/F HSD+mrYvCVIgx3+7Xa9DUAQvTu+3Y=; b=Dc0ok9tNDVjfbgkxAU9qw7+tybCq9J 5MO8MAIKtb0lwXn9KSf2an/qkI9QMgC02LY83mz2ryFUeF1m6dMT0RbSbtBcJotO wL9yBubDfLg8lELybyoR3wO9kK4eiYxTS4Nry7d5sm0s0q92eQQ0qJmhxkm5nfuN WNJ2o0wrHtz3H0ZHohQGi3gmhi31rWZwxRsoVjeCKWYVjcGRbdytCYKs+G7P4Pf1 dzopnGShLs6fN4iWICnjDq3k2LFtCPCd3c9XkIKIf5Jsd6/DvbAZbYfGg792Ptsr YPtdkSfbCLJy1QYRZLfhP5P0JvaRgY30uBvuCE17kiZRbpMVDjU9ducg==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id VXk+HwHjSBgl; Fri, 29 Oct 2010 15:51:10 +0100 (IST)
Received: from [10.87.48.4] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 39E0F3E415C; Fri, 29 Oct 2010 15:51:08 +0100 (IST)
Message-ID: <4CCADF5A.3060704@cs.tcd.ie>
Date: Fri, 29 Oct 2010 15:51:06 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8
MIME-Version: 1.0
To: "Polk, William T." <william.polk@nist.gov>
References: <C8EF9885.1F4B7%wpolk@nist.gov>
In-Reply-To: <C8EF9885.1F4B7%wpolk@nist.gov>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "tony.li@tony.li" <tony.li@tony.li>, Sandra Murphy <Sandra.Murphy@sparta.com>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 14:49:19 -0000
On 29/10/10 02:15, Polk, William T. wrote: > Stephen, > > We have not changed the process. There was a tools error That's grand. I just wanted to call it out, in case. Cheers, S. > - the draft > ended up on the agenda as an informational RFC on the IETF stream. I > actually pointed this out to the secretariat so that the document was > moved to the right part of the agenda, but I did not notice that this > document got assigned for a secdir review. Sandy was diligent and did > the review before the telechat. > > We need to figure out why the tools error is occurring and get this > corrected. Adding a manual step for irtf stream filtering would be a > real burden for Sam. > > Thanks, > > Tim > > > On 10/28/10 5:22 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote: > > > > Not really for Sandy, more for the ADs/Sam W: > > Why are we doing a secdir review of an IRTF draft? That's > not required by any process I know of (speaking as an IRTF > RG chair). > > Unless maybe the RRG asked for it, in which case, ignore > this. > > Otherwise we should try filter the assignments for > irtf drafts since this is not the 1st time this has > happened. (Last time, I spotted it before someone did a > review.) > > Ta, > Stephen. > > On 28/10/10 18:27, Sandra Murphy wrote: > > > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > IESG. > > These comments were written primarily for the benefit of the security > > area directors. Document editors and WG chairs should treat these > > comments just like any other last call comments. > > > > I unfortunately was off-net for a few days and got to this assignment > > rather late. The document is long and covers a broad swath of material > > and I was not able to cover it deeply. > > > > This document is a product of the rrg IRTF working group. It > summarizes > > 15 different proposals for a new routing and addressing > architecture for > > the Internet, with short summaries, critiques and rebuttals for each, > > and gives a final recommendation to the IETF for future direction. > > > > With the breadth of scope of the document, there is no way for me to > > review each proposal's documents for security considerations. > > > > The security considerations of *this* document itself is quite terse: > > > > 20. Security Considerations > > > > All solutions are required to provide security that is at least as > > strong as the existing Internet routing and addressing architecture. > > > > Given the widely reported weakness of the "existing Internet > routing and > > addressing architecture", this is a low bar indeed. There are attempts > > in progress to attempt to improve the security of the Internet routing > > and addressing architecture. I do not know what to suggest if these > > improvements leave the Internet with stronger security than is provided > > by these proposals. > > > > The summaries of the different proposals devote little attention to the > > infrastructure security ramifications of the proposal. Given the > stated > > goal, perhaps no attention was necessary. > > > > Many of these proposals include an encapsulation system, presenting the > > expected difficulties with end system authentication, filtering systems > > at boundaries, etc. Some proposals addressed these concerns. I am not > > sure if the security considerations section meant that the proposals > > were required to avoid weakening the end-host security protections > > already provided (ipsec, NAT, whatever). > > > > The rrg wg came to consensus that a fundamental architectural > feature is > > a separation of locator and identifier for any node. Many of the > > discussed alternatives include a mapping system that produce a locator > > for a given destination identifier. > > > > The mapping system would seem to be a very likely point of > > vulnerability, permitting traffic redirection for data exposure or > > blackholing, etc. Many proposals suggest a hierarchic architecture of > > the mapping system for scaling purposes. I would presume that an > > authorization scheme for the mapping system would be essential, and > that > > the hierarchy would be an important aspect of that scheme. Of > course, I > > can't tell much at this level of detail about how and if each proposals > > addresses this. (One of the recommendations suggests communicating > > mapping info through bgp - I can not say at this point whether the SIDR > > suggestions for improving bgp security would be applicable.) > > > > --Sandy > > > > Nits: > > > > PMTUD Path Maximum Transmission Unit Discovery: The process or > > mechanism that determines the largest packet that can be sent > > between a given source and destination with being either i) > > fragmented (IPv4 only), or ii) discarded (if not fragmentable) > > because it is too large to be sent down one link in the path from > > the source to the destination. > > > > It should say "*without* being either", right? A long sentence so > I may > > have lost my place. > > > > > > Several of the comments start using terms that are part of the wg > > deliberations, I'm sure. But it makes reading the discussions and > > critiques obtuse. In particular, "Core-Edge Separation" and "Core-Edge > > Elimination" seems to a well understood concept in the wg. It needs to > > be defined somewhere. A web search found references in some conference > > papers and in rrg mailing lists. > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > > >
- Re: [secdir] comments on draft-irtf-rrg-recommend… Polk, William T.
- [secdir] comments on draft-irtf-rrg-recommendatio… Sandra Murphy
- Re: [secdir] comments on draft-irtf-rrg-recommend… Stephen Farrell
- Re: [secdir] comments on draft-irtf-rrg-recommend… Stephen Farrell
- Re: [secdir] comments on draft-irtf-rrg-recommend… Samuel Weiler
- Re: [secdir] comments on draft-irtf-rrg-recommend… Tony Li