Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt

Kannan Varadhan <> Sat, 31 March 2012 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4B1C21F86CA for <>; Fri, 30 Mar 2012 17:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CYJKsn5sDcVc for <>; Fri, 30 Mar 2012 17:14:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 40F8E21F86C3 for <>; Fri, 30 Mar 2012 17:14:24 -0700 (PDT)
Received: by pbbrq13 with SMTP id rq13so2402627pbb.31 for <>; Fri, 30 Mar 2012 17:14:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=E+KLmAddmfmJerMV/63a20dqV96pW5KLhr9kVEktXME=; b=LBD0JWVesMKAmfksIGzL7SuWwVxxkU21DN4QUj8oITroXjvmQ8b5erzDIshB+q1xOY qV64UU9Labzj1zJSeHgtL+kk643BW9jgxKRi5/no/HHr9Ap4JQ5SU/xhenenIFTFzMTV 9XZ1Rx4iBlbNt9rYJ9LqQxnzYms+pefm13QbwE9zEuwTQOdzdtJy7h/KB194XDM8Y/a4 npSHbXta0UwPyv8tkG1dW0tNPwGgQ1wPmrSuB5mTKKt1gfJAr2FxXzv+TJPd6x0TxA15 E0QCfRw/lyR1IJfrTaUWSIx5iqGfVQa1vNtNXbiPVbTc6ocsM3lVlyLJ2ZrDTh0SR51d UPTg==
Received: by with SMTP id rv3mr1428906pbc.65.1333152864119; Fri, 30 Mar 2012 17:14:24 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 6sm8396247pbh.65.2012. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 17:14:23 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Kannan Varadhan <>
In-Reply-To: <>
Date: Fri, 30 Mar 2012 17:14:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Pradosh Mohapatra <>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg list <>
Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 31 Mar 2012 00:14:25 -0000

On Mar 28, 2012, at 10:07 AM, Pradosh Mohapatra wrote:

> Hi Jay,
>>> at this afternoon's sidr ssion, i presented two open issue with
>>> draft-ietf-sidr-pfx-validate-04.txt
>>> 1 - Should updates learned via iBGP be marked?
>>> 2 - Should updates injected into BGP on this router be marked?
>>> i think yes because:
>>> o i want support of incremental deployment
>>> o i do not want to find out I am announcing garbage when my neighbor$,1ry(Bs
>>>   NOC calls, mis-originations should be stopped at the source
>>> there was fear that, if used at other than edge routers, this allowed
>>> creation of loops, as setting local pref etc, do.
>>> i think there was general agreement that this was ok on edge routers
>>> and the point of injection, as that is logically an edge router.
>>> would like to see convergence on this
>> I could not hear the discussion in the room today because the utter
>> webex fail prevented my remote participation.  So let me ask about
>> today's discussion.
>> Pre-RPKI, an ibgp policy can manipulate attributes elsewhere than just
>> at ingress edge routers, and if the policy is broken it can result in
>> loops.  It's something to watch out for when designing a policy, but I
>> am thankful that this kind of flexibility exists, because not all
>> policies that manipulate attributes other than at ingress edges are
>> broken.
>> Regarding pfx-validate:
>> I hope the agreement in the room was that a sane network design would
>> probably involve setting a local 'origin has been checked' community
>> on the first router inside the AS where that check occurred.
> like draft-ietf-sidr-origin-validation-signaling ?
>> I hope the agreement was _not_ that pfx-validate implementations
>> should be hard-coded to assess validation state only at the ingress
>> edge router.
> I couldn't go to IETF either. The argument is over what the default
> behavior should be (spec'ed). My vote is that origin validation should
> NOT be performed on IBGP learnt prefixes by default as there is potential
> for loops and inconsistency. For everything else, there are knobs.

Given that this is trying to enable "security" hooks, I'd argue that the default should be for a router to behave as if it would validate all prefixes at a router, including those learned via iBGP.  THis would allow for an implementation to work in conjunction with the origin-validation-signalling to optimize iBGP handling as appropriate.

This would allow not just the incremental deployment scenarios, but also behaves correctly if a router in the AS were misconfigured and leaked invalidated prefixes---in those cases, only the misconfigured router is affected, and all other routers would behave as expected.

The only scenario where I see the possibility for loops or other bad behaviors would be if a router learned of two prefixes, one known good and one bad according to its ROA database, and some of the other routers in the AS were not doing prefix validation.  In such as case, it seems to be a good thing to actually admit that scenario and correct for it.