Re: [secdir] comments on draft-irtf-rrg-recommendation-14

Stephen Farrell <> Thu, 28 October 2010 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E1F43A695C; Thu, 28 Oct 2010 14:20:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.2
X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VqWjGmk+6VnU; Thu, 28 Oct 2010 14:20:45 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by (Postfix) with ESMTP id CE3E63A6860; Thu, 28 Oct 2010 14:20:44 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3ECB520E002; Thu, 28 Oct 2010 22:22:37 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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=1288300957; bh=G5Hud3yy9V51MO R0NQa9Rk3nqD0ZzcDqrLp3/XLWtmk=; b=3ww4seaiSO7zZmpb/Sv9wGg3r7sDsJ u4zbJZaYyPsWV5zNsCHgBEWLMGMg9a4oaEGOBIeR+OxhLXRbkOSluYTJFLQGWVXy XNNkpfpqJ68ro71DtVjS1SuMvVcSlKT5btc9p5Ut7NN2H1BBQx0MD9GBm766nR1R fpPI86ANJimFyd3PNCnmxarklhG+/D5BRrfYkyEKL5uDrmjH2jkWskSIHQy/Nw/+ 9JvktD/D2bjkHj3vEsPUklBpojpN7PMmZRCFywlxssjdVr8yX15QrViepYj8M5oo Id2mQFFKLrUldj7W7BRP0YS9CUX+yNg01/sNmV+wX2p/LLnU8nRVvNWQ==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id GlGEmJ6YXI-f; Thu, 28 Oct 2010 22:22:37 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id F35C420E001; Thu, 28 Oct 2010 22:22:33 +0100 (IST)
Message-ID: <>
Date: Thu, 28 Oct 2010 22:22:21 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8
MIME-Version: 1.0
To: Sandra Murphy <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Oct 2010 21:20:46 -0000

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

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


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