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
>     >
>