[sidr] draft-dickson-sidr-route-leak-solns-01.txt

Randy Bush <randy@psg.com> Mon, 26 March 2012 12:09 UTC

Return-Path: <randy@psg.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 C5A6021F86BA for <sidr@ietfa.amsl.com>; Mon, 26 Mar 2012 05:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.507
X-Spam-Level:
X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599]
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 8vhtD+SxMlc9 for <sidr@ietfa.amsl.com>; Mon, 26 Mar 2012 05:09:22 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 344D221F86AF for <sidr@ietf.org>; Mon, 26 Mar 2012 05:09:22 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SC8jh-000Csy-Ie for sidr@ietf.org; Mon, 26 Mar 2012 12:09:21 +0000
Date: Mon, 26 Mar 2012 14:09:20 +0200
Message-ID: <m2limnh8cv.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: sidr wg list <sidr@ietf.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Subject: [sidr] draft-dickson-sidr-route-leak-solns-01.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: Mon, 26 Mar 2012 12:09:22 -0000

[ let me save mic time and just say what i said to the idr list ]

i do not think this will fly in the long run, but let my try to at least
get it in the best light.

  o it could and should be said in a page or so in order that people can
    get it and think it is simple and not imposing

  o it assumes gao-rexford, which we know is an unsafe assumption, but
    wtf, it's good in enough cases that we can let it go for the moment

  o the relationship has to be per prefix not per link, as prefixes with
    different business models are often sent over the same link

  o the mark should be determined by the sender, and need not agree with
    the receiver's perception of the relationship

  o if the receiver does not like it they can call the sender on the
    phone, drop the announcement, whatever

  o this is a significant change to bgp, so idr should be asked to say
    it's cool before sidr tries to protect it by signing over it

  o if it is agreed by idr and it is well defined, we know how to sign
    it in bgpsec, it's like a few more bits on each hop in the as path

  o as with origin validation and path validation, the router should not
    do anything on its own, but rather should provide the operator the
    tools needed to apply policy based on the data

  o therefore, to use it, the router will have to give the operator some
    sort of expression over the catenation of the per-as policy markings

  o but what should an operator do when they see a 'violation' six hops
    away?

randy