Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 19 October 2016 23:57 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B76129497 for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 16:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sMpHVcelbjH for <idr@ietfa.amsl.com>; Wed, 19 Oct 2016 16:56:58 -0700 (PDT)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EE5129448 for <idr@ietf.org>; Wed, 19 Oct 2016 16:56:57 -0700 (PDT)
Received: by mail-lf0-x22b.google.com with SMTP id l131so48019591lfl.2 for <idr@ietf.org>; Wed, 19 Oct 2016 16:56:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l2eUCCoHo6Oa1CzGCpFJBdPEnMvOM7q54n7G/V0FYPg=; b=tJv3FAdH2yOOPfK4uyER4kusYNwJbXSSEAfXs/B0VNyvSBQgaDeJ+KMxgBbN3UvIOt OIwr+hRL8Qk5WMJdX3Z5PJVFO3Nd53knKxaHKSYpA2pW7uuuaf8jH+skC/YQbAcvBYZO 9erwoq7A/vMzFhnQEgY0gfDJvoZnCjgc/WkSx3TKl9+hksP598AW33Qtikh+8Rp+ptXC QrHxLbQPcBjstRWkP1X67NF2437BYh9gkXrtH0/F8s36GWSaQpV1Wy85JMxPZ8tAFFEI 7AhVsiAzXKIqjScH7N27TjK/Ug/VOdaUeWR4fjEHuS7B6jrritIeo8Nsro4XXWcEdr5Y nhCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l2eUCCoHo6Oa1CzGCpFJBdPEnMvOM7q54n7G/V0FYPg=; b=VG9RK+jWDb2hwh37NyTE303MBO55ZSRQHJ53hikq8IHr0bfwmpe5Zl1sDTqaWO3FfK zLp37Moxgsmsz6jgt52EOkmy80MHpHpcluW8MUkFcC/07fzxuXhJDWpE67+1kisxsDtZ bzGTyYxYAkE0vfCfzuN/qAwUqXMbJYg6YwWK4U/IN9GTVbwTLxxOwhXUicMlPgUVp2el +hZLoZR1GXJu0rLndabXKYhJzrj4pYbYLxVNXLzcEW09U7Cw12qccDWHC3pk3muvedLy 6BlAXa+pCDpbNuhUtIllY/l964iFza2LM49nQif+5tPegqanUJhb91eeqFChyPUP94Bi vC6Q==
X-Gm-Message-State: AA6/9Rn0eaYmpKjyVMHsDRMCt/kHG0htC69GjpCnBmy2QfrM9ILpZBStkadcjl0H3J0pRTaklmcTBKHmtG/bvQ==
X-Received: by 10.194.74.5 with SMTP id p5mr6476878wjv.92.1476921415129; Wed, 19 Oct 2016 16:56:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.203.207 with HTTP; Wed, 19 Oct 2016 16:56:53 -0700 (PDT)
In-Reply-To: <CA+b+ER=oyCTF24f1pAQQjA0ogMCtqw0rKWzT7+jcNpL4WjPjHQ@mail.gmail.com>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <CAH1iCirF_1ODLtLzeVhKmQPDeeGcczcQCSPXDcro=OQv2ipR3A@mail.gmail.com> <5807F3AF.9080200@foobar.org> <CA+b+ERn_7Bs8CeAgKrxSPiMPOCsE4pH9hoD+76tEDrWM-KYVRw@mail.gmail.com> <CAH1iCirF2C-83z3hYC4bBqMYW7zHs1eeofySVipyODo=8FNQxg@mail.gmail.com> <CA+b+ER=oyCTF24f1pAQQjA0ogMCtqw0rKWzT7+jcNpL4WjPjHQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 19 Oct 2016 16:56:54 -0700
Message-ID: <CAH1iCipd+wyFVwvunjVFxF1t52j3_sKm5efGXzNH8xwHLndaHQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary=047d7bd9111a4f6052053f40909f
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/G6oLc7KwjUlaE8z-M9lP-4Vg0ug>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Oct 2016 23:57:01 -0000

On Wed, Oct 19, 2016 at 4:28 PM, Robert Raszuk <robert@raszuk.net>; wrote:

> Brian,
>
> Regarding BGP OV I meant to use it as a database of valid ASNs - where it
> is present.. Nothing to do with actual prefixes in MP_REACH here.
>
> > So, I think the "unless policy is in place" is a red herring; whether
> policy is there or not,
> > and regardless of what policy there is, it is ALWAYS "allow any value".
>
> Well if my policy says drop junk it can not ALWAYS act as "allow any
> value".
>

Yes, the implementation should still "allow any value".

Given that BGP OV is not guaranteed to be the complete universe of ASNs,
and certainly excludes private use ASNs, then NO, use of such a database is
an unwise idea.

Even using a bogon list or other source of "up to date" ASNs, is not a good
idea, at least for on-router enforcement. The timeliness aspect of updates
to those has been shown to be a problem.
One need only look at any number of mailing lists, where "Please update
your bogon filter" messages are common.

The real problem is asymmetry. The entity that ends up on the bogon list is
harmed, while the action needed to remedy that harm is vast and
decentralized (operators), with no guaranteed, reliable speed of resolution
of problems.

It would be fine to have a configuration management system do mild
enforcement or alerting, to limit operator error; but there should always
be the ability to over-ride or ignore those protections.

Something similar to "re-type your email address" should be about the level
of enforcement of ASN values, to avoid fat-fingering things, IMHO.

At some point in the future, presuming some kind of better managed peering
DB and routing policy language, including publication of "locally well
known wide communities", protection mechanisms related to communities would
make sense.
But not until the preconditions are there (the bits after "presuming").

Brian




>
> Thx,
> R.
>
>
>
> On Thu, Oct 20, 2016 at 1:21 AM, Brian Dickson <
> brian.peter.dickson@gmail.com>; wrote:
>
>>
>>
>> On Wed, Oct 19, 2016 at 3:36 PM, Robert Raszuk <robert@raszuk.net>; wrote:
>>
>>> so summarising:
>>>>
>>>> - operators: you MUST use an ASN
>>>> - implementers: you MUST allow any value
>>>>
>>>
>>> ​IMHO this is too coarse simplification.
>>>
>>> For operators if we are getting into this here vs in companion GROW doc
>>> draft/rfc must define what sending vs receiving operator is expected to do.
>>>
>>> ​For implementation allowing any value unless policy is in place. And as
>>> such policy must be able to validate against BGP Origin Validation database
>>> if present and enabled on the router.
>>>
>>
>> You've lost me here. If I am sending prefix X, and I am ASN A, and the
>> community is B:C:V, the BGP OV will show A is allowed to originate X. There
>> are no other restrictions applicable from OV.
>> Also, the meaning of B:C:V is exclusively defined by ASN B, who may or
>> may not be a directly connected peer.
>>
>> Nobody except B is expected to "do" anything.
>> What B does, is a combination of:
>> - What B tells the world
>> - What B tells some subset of the world (e.g. via a customer portal which
>> has restricted access)
>> - What B uses to decide for whom each set of actions is permitted
>> - Any internal policies and procedures known only to B
>>
>> E.g. B may allow B:C:V from customers of B (including customers of
>> customers, etc.)
>> E.g. B may allow B:D:V from anyone for some set of values V and some
>> specific values of "D"
>> E.g. B may allow arbitrary automated functionality associated with
>> B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and
>> VN is a trigger for some particular behavior (filter, prepend, change MED)
>>
>> Every ASN "B" can choose whatever it wants as the methods, mechanisms,
>> values, etc., and those do not need to have any bearing on any other ASN's
>> choices.
>>
>> Some ASNs will choose not to use their own ASN:X:Y, but rather use
>> PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct
>> choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no
>> global meaning.)
>>
>> So, I think the "unless policy is in place" is a red herring; whether
>> policy is there or not, and regardless of what policy there is, it is
>> ALWAYS "allow any value".
>>
>>
>>>
>>> Again .. I assume we are all talking about first 4 octets only right ?
>>> Or also second 4 octets too ?
>>>
>>>
>> First 4 octets only.
>>
>> Brian
>>
>
>