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

Pradosh Mohapatra <pmohapat@cisco.com> Wed, 28 March 2012 17:06 UTC

Return-Path: <pmohapat@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441A221E82C6 for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 10:06:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.044
X-Spam-Level:
X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcUMotg1q5tW for <sidr@ietfa.amsl.com>; Wed, 28 Mar 2012 10:06:38 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9538821E82C0 for <sidr@ietf.org>; Wed, 28 Mar 2012 10:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pmohapat@cisco.com; l=2114; q=dns/txt; s=iport; t=1332954398; x=1334163998; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8RxhBljzdz/3xFUiGmmr0d80S7xv4AGCtrpAJKRuI0s=; b=Qu+ohj486sxphtP0FT5LQaBxPpr1YaDp0mmBkzGU9zD/IVTAiZeXE60p vuCqAtdB/4rmTZ+kcBf91TMHYYrUOvCtdCK9sUJQJHmFt1G8BsMGHjzsc QIK7Ha6nASxZfUTR4qvW8LjPSaxRyqWfgtw+doLJuXizMK41zU75Zcaoe s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAJ5Ec0+rRDoG/2dsb2JhbABFuGyBB4IJAQEBAwESASUCPxALRlcGJw6HYwSbfZ8kkC9jBIhYjQmORYFogweBNhc
X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="38054949"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Mar 2012 17:06:38 +0000
Received: from sjc-vpn6-894.cisco.com (sjc-vpn6-894.cisco.com [10.21.123.126]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2SH6cH6015521; Wed, 28 Mar 2012 17:06:38 GMT
Mime-Version: 1.0 (Apple Message framework v1075.2)
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
From: Pradosh Mohapatra <pmohapat@cisco.com>
In-Reply-To: <20336.45627.147578.984228@oz.mt.att.com>
Date: Wed, 28 Mar 2012 10:07:29 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <BD572005-FDF6-4E13-B9E4-B23F15EB1E4D@cisco.com>
References: <m2k427h2oa.wl%randy@psg.com> <20336.45627.147578.984228@oz.mt.att.com>
To: Jay Borkenhagen <jayb@braeburn.org>
X-Mailer: Apple Mail (2.1075.2)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-pfx-validate-04.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 17:06:39 -0000

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.

- Pradosh