Re: [Gen-art] Gen-ART LC review of draft-ietf-sidr-roa-validation-10.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 10 April 2011 07:34 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 018F73A69DB for <gen-art@core3.amsl.com>; Sun, 10 Apr 2011 00:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.539
X-Spam-Level:
X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 CJ5j1mQOkMPM for <gen-art@core3.amsl.com>; Sun, 10 Apr 2011 00:34:05 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 8DEA13A6868 for <gen-art@ietf.org>; Sun, 10 Apr 2011 00:34:04 -0700 (PDT)
Received: by wyb29 with SMTP id 29so4458976wyb.31 for <gen-art@ietf.org>; Sun, 10 Apr 2011 00:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KE93f50Jmt3mq2w9GoXmmyTJmLd3BAHRSnphaulWCkE=; b=DhysG/bvfUeof2nJ07n3pbUD/qu1AlcfKXxlZH8Mj5bIef5O1ZkYmh2Gme7JhEPZu4 3lb/a2myeAcoiBAT7zRJ1G2ooql9cTr7fRgPQdq1YGqOmEZNOIkayN0s+k6PNrI7ZPWX GNQyLUO4K4gVJX17Z1FiPCyQeXEXZ71cQQ2/A=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=fdWWy0I6njDuUKPQA3tljgjUnX9rqBLoBBW1PbziJI12awrlLlwK0ibmDUCeVjq/9j 5hkzW/2TJsscVK6wt+fYHMh4MR3hvKz5wIa531W2aWwBBIzwEzBRqNSoSi4+JpxNxadj kQDMjsl03pf1yD50/VvIK10yub3Uagoj+92y8=
Received: by 10.227.176.135 with SMTP id be7mr4056025wbb.0.1302420950570; Sun, 10 Apr 2011 00:35:50 -0700 (PDT)
Received: from [192.168.1.65] (host81-159-213-38.range81-159.btcentralplus.com [81.159.213.38]) by mx.google.com with ESMTPS id o23sm2657595wbc.27.2011.04.10.00.35.48 (version=SSLv3 cipher=OTHER); Sun, 10 Apr 2011 00:35:49 -0700 (PDT)
Message-ID: <4DA15DD1.7020407@gmail.com>
Date: Sun, 10 Apr 2011 19:35:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Geoff Huston <gih@apnic.net>
References: <4DA0525B.1010804@gmail.com> <6B4E37B9-9A12-4A79-A43D-6DF16AC33E28@apnic.net>
In-Reply-To: <6B4E37B9-9A12-4A79-A43D-6DF16AC33E28@apnic.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-sidr-roa-validation.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-sidr-roa-validation-10.txt
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2011 07:34:06 -0000

On 2011-04-10 03:13, Geoff Huston wrote:
> On 09/04/2011, at 10:34 PM, Brian E Carpenter wrote:
> 
>> Please see attached review.
>>
>> <draft-ietf-sidr-roa-validation-10-carpenter.txt>
> 
> 
> 
> Thanks Brian,
> 
> I'm not sure as to the appropriate form of response, but let me respond to the two minor issues you identified in this review (many thanks for the review, by the way)

This is just fine... the gen-art archive is public, so replying here
is on the record.

>> 3.  Applying Validation Outcomes to Route Selection
> ...
>>      "valid" is to be preferred over
>>      "unknown", which is to be preferred over
>>      "invalid".
> ...
>>   It is a matter of local routing policy as to the actions to be
>>   undertaken by a routing entity in processing those routes with
>>   "unknown" validity states.
> 
> you commented that: 
> 
> That seems to leave open the possibility that an aggregated route (which
> is by definition "unknown") would be rejected. Assuming that the various
> separate routes that were aggregated together never reached this particular
> router, the result would be a black hole. At the least, it seems that this
> should be mentioned, even if it is an intentional possibility.
> 
> But the next sentence in the document states:
> 
>    Due to considerations of partial use of
>    ROAs in heterogeneous environments, such as in the public Internet,
>    it is advised that local policy settings should not result in
>    "unknown" validity state outcomes being considered as sufficient
>    grounds to reject a route outright from further consideration as a
>    local "best" route.

Yes, indeed, and all I was thinking of was adding a sentence here saying
that the "unknown" category might include aggregates. It's a direct implication
of the earlier text but I tend to assume that not all readers will
notice all implications.

> Also, given the current proposal in the IDR WG to deprecate the use
> of AS Sets (and by implication deprecate the (rarely used if ever)
> practice of proxy aggregation, I am unsure of the need to call out 
> proxy aggregation in this context.

I won't get into that debate ;-)

>> 5.  Route Validation Lifetime
>>
>>   The "lifetime" of a validation outcome refers to the time period
>>   during which the original validation outcome can be still applied.
>>   The implicit assumption here is that when the validation lifetime
>>   expires the routing object should be re-tested for validity.
> 
> you commented that:
> 
> OK, but shouldn't a previously "valid" route be downgraded to
> "unknown" after the lifetime expires and until the validity has
> been re-tested?
> 
> Not necessarily. When a route is validated, the validation lifetime refers
> to the validation time of the EE cert used to sign that ROA. When the
> ROA is no longer valid the route should be re-tested for validity. It it
> possible that there is another ROA that still validates the route, or in the
> absence of the ROA that previously validated the route, the route may 
> be considered invalid (i.e. there is an AS 0 ROA still extant that encompasses
> this prefix). For this reason the text specifically indicates that the
> appropriate action is to retest the route for validity in the context of the
> current local cache of valid ROAs.

Yes, but I have no sense of the timing - would the time taken to revalidate
the route leave a long enough gap for some kind of security exposure while
an expired route was still marked as valid? Maybe I am worrying about
nothing.

> 
> 
> At this stage I am unsure if changes to the draft are warranted, as
> I believe that the issues you highlight here are addressed in the
> document as it stands.

Sure, these were minor comments, unless your shepherd feels differently.

   Brian