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

Geoff Huston <gih@apnic.net> Sat, 09 April 2011 15:11 UTC

Return-Path: <gih@apnic.net>
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 A34B83A68DC for <gen-art@core3.amsl.com>; Sat, 9 Apr 2011 08:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.704
X-Spam-Level:
X-Spam-Status: No, score=-94.704 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, RCVD_NUMERIC_HELO=2.067, 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 EgYumU2rrNgk for <gen-art@core3.amsl.com>; Sat, 9 Apr 2011 08:11:41 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 4CEB33A6835 for <gen-art@ietf.org>; Sat, 9 Apr 2011 08:11:40 -0700 (PDT)
Received: from 4.75.240.10.in-addr.arpa (m1f0436d0.tmodns.net [208.54.4.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 6D1B9B6826; Sun, 10 Apr 2011 01:13:23 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <4DA0525B.1010804@gmail.com>
Date: Sun, 10 Apr 2011 01:13:18 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B4E37B9-9A12-4A79-A43D-6DF16AC33E28@apnic.net>
References: <4DA0525B.1010804@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1084)
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: Sat, 09 Apr 2011 15:11:41 -0000

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)

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

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.




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


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.

regards,

  Geoff