From Internet-Drafts@ietf.org Sun Jan 2 06:30:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5813A695C; Sun, 2 Jan 2011 06:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, 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 sB+aDIMuKaDx; Sun, 2 Jan 2011 06:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA243A6833; Sun, 2 Jan 2011 06:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110102143002.3021.66304.idtracker@localhost> Date: Sun, 02 Jan 2011 06:30:02 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operations Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-00.txt Pages : 7 Date : 2010-12-31 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-02062802.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Sun Jan 2 06:45:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FAD3A6971; Sun, 2 Jan 2011 06:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 XdOirNKDgGcg; Sun, 2 Jan 2011 06:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6843A696A; Sun, 2 Jan 2011 06:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110102144501.30542.89543.idtracker@localhost> Date: Sun, 02 Jan 2011 06:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-ghostbusters-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2011 14:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI Ghostbusters Record Author(s) : R. Bush Filename : draft-ietf-sidr-ghostbusters-00.txt Pages : 7 Date : 2010-12-31 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information to be signed (indirectly) by a resource-owning certificate. The data in the record are those of a severely profiled vCARD. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-ghostbusters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-02063054.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Jan 5 18:30:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E783A6C0B; Wed, 5 Jan 2011 18:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.279 X-Spam-Level: X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, 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 ncoLAibRFwbr; Wed, 5 Jan 2011 18:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49AE3A67E2; Wed, 5 Jan 2011 18:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110106023001.22586.54019.idtracker@localhost> Date: Wed, 05 Jan 2011 18:30:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-06.txt Pages : 21 Date : 2011-01-05 In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-05182751.I-D@ietf.org> --NextPart-- From randy@psg.com Wed Jan 5 18:34:36 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FEE3A6BB4; Wed, 5 Jan 2011 18:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599] 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 7E17IUFcXWkD; Wed, 5 Jan 2011 18:34:35 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5DA4C3A67B4; Wed, 5 Jan 2011 18:34:35 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PafiT-0009gx-45; Thu, 06 Jan 2011 02:36:41 +0000 Date: Thu, 06 Jan 2011 11:36:39 +0900 Message-ID: From: Randy Bush To: Internet-Drafts@ietf.org In-Reply-To: <20110106023001.22586.54019.idtracker@localhost> References: <20110106023001.22586.54019.idtracker@localhost> 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 Cc: sidr@ietf.org, i-d-announce@ietf.org Subject: Re: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:34:36 -0000 > Title : The RPKI/Router Protocol > Author(s) : R. Bush, R. Austein > Filename : draft-ietf-sidr-rpki-rtr-06.txt > Pages : 21 > Date : 2011-01-05 - A router establishes and keeps open an authenticated connection to a - cache with which it has a client/server relationship. It is - configured with a semi-ordered list of caches, and establishes a + A router establishes and keeps open an authenticated connection to + one or more caches with which it has client/server relationships. It + is configured with a semi-ordered list of caches, and establishes a connection to the most preferred cache, or set of caches, which - accepts one. + accept the connections. + + The router MUST choose the most preferred, by configuration, cache or + set of caches so that the operator may control load on their caches + and the Global RPKI. thanks to keyur and david for catching this gap randy From maureen.stillman@gmail.com Sat Jan 8 12:27:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879E33A681C for ; Sat, 8 Jan 2011 12:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 a-6vCcXCDRv4 for ; Sat, 8 Jan 2011 12:27:09 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C965A3A681B for ; Sat, 8 Jan 2011 12:27:09 -0800 (PST) Received: by iwn40 with SMTP id 40so19316807iwn.31 for ; Sat, 08 Jan 2011 12:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=sn71jMGQOdEcEk3BMjDzntvxR3K0qmuRItiwmEy3UxQ=; b=v7QD7mrP0sIho96rqIUxcBqwmqVlUgoOSbCbap+wmsXMOnFkbIwRn30t6ENfA5GLSa D2BpUSh/6ARvVDJ+LSLc7eg406WYefXjQX3UUkK3jYtqXzl6ty5KWMAOiL3O06uxC9Zb pprbtQzY5kL+PYhYErj2KYFueUlZvAGbfrt28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AZNUAl0glEfVhah+5L2ZFEW1qlbVSFsDAJ+PgCitq4LFwGg7rf8iz1JQPGO/WnwEnj lcCxvMJ/scu+N0TdjW4cbXloNrZFTn/DKNxcmnft58DrjmJHg5820adRUStWnhsrIxpo T9S1I44jVpXQOXfAW3mPVeRhL4wEwFWI5pjao= MIME-Version: 1.0 Received: by 10.231.39.200 with SMTP id h8mr26929528ibe.150.1294518556612; Sat, 08 Jan 2011 12:29:16 -0800 (PST) Received: by 10.231.167.193 with HTTP; Sat, 8 Jan 2011 12:29:16 -0800 (PST) Date: Sat, 8 Jan 2011 14:29:16 -0600 Message-ID: From: Maureen Stillman To: sidr@ietf.org Content-Type: multipart/alternative; boundary=0003255751eab8d94804995b96e5 Subject: [sidr] Comments on draft-sidr-origin-ops-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 20:27:11 -0000 --0003255751eab8d94804995b96e5 Content-Type: text/plain; charset=ISO-8859-1 This is an important document. I have 2 comments, 2 nits, one question and a comparison of this draft with draft-sidr-pfx-validate section 6 called "deployment considerations". I have reviewed Section 5 of draft-sidr- origin-ops only. Comment 1) The validation state terminology used in this draft is not consistent with the terminology of draft-sidr-pfx-validate. That draft uses states: valid, invalid, not found, whereas this draft uses states: valid, invalid, unknown. Do we want these to be consistent across i-ds? The 3 states are defined in draft-sidr-pfx-validate but are not defined here. We should either define them or point to the definition in draft-sidr-pfx-validate where they are defined. I will refer to this as state "not found" in the remainder of my comments. Comment 2) Some suggested text below for the opening of section 5. Section 5. Routing Policy Background Currently, the origin status information is not verified. With the incremental deployment of RPKI, we will transition to origin validation comprised of three states: valid, invalid and not found [see draft-sidr-pfx-validate]. We specify a relative preference associated with each state as follows: Announcements with valid origins SHOULD be preferred over those with *not found* or invalid origins. Announcements with *not found* origin SHOULD be preferred over those with invalid origins. Announcements with invalid origins MAY be used, but SHOULD be less preferred than those with valid or *not found*. During the RPKI transition period, relative preference is introduced to manage the uncertainty associated with a system in flux. As the RPKI transition moves forward, the number of origin validations with state "not found" will decrease. Nits: Section 5. Routing Policy 1) Reasonable application of local policy should be designed eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. Suggestion: Reasonable application of local policy should be designed *to* eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. 2) As origin validation will be rolled out over years coverage will be spotty for a long time. Hence a normal operator's policy should not be overly strict, perhaps preferring valid announcements and giving very low preference, but still using, invalid announcements. Suggestion: As origin validation will be rolled out *incrementally* coverage will be *incomplete* for a long time. Hence an *word deleted* operator's policy should not be overly strict, perhaps preferring valid announcements, *attaching a lower preference to but still using, not found announcements* and giving very low preference, but still using, invalid announcements. I deleted the word "normal" since I don't know what normal is. I think you need to point out here that they will use all three, valid, invalid and not found announcement. For some reason it is missing from this paragraph but is correctly included in the list below. Question: I'm not sure I understand this. "Reasonable application of local policy should be designed *to* eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies." What is ill-advised as opposed to incorrect? Does ill-advised means one kind of error and incorrect another? If they are really one problem, then just use one term. Comparison of draft-sidr-pfx-validate section 6 called "deployment considerations": I'm confused by the relationship of this draft to draft-sidr-pfx-validate section 6 called "deployment considerations". Is this the operational section and therefore should draft-sidr-pfx-validatereference draft-sidr-origin-ops? The deployment guidance is not the same in sidr-pfx-validate as it is in sidr-origin-ops in the sense that there are no SHOULDs or MUSTs. The deployment considerations in sidr-pfx-validate are just advice. Here is the specific text from draft-sidr-pfx-validate: 6. Deployment Considerations "Once a route is received from an EBGP peer it is categorized according the procedure given in section 2. Subsequently, routing policy as discussed in section 3 can be used to take action based on the validation state. Policies which could be implemented include filtering routes based on validation state (for example, rejecting all "invalid" routes) or adjusting a route's degree of preference in the selection algorithm based on its validation state. The latter could be accomplished by adjusting the value of such attributes as LOCAL_PREF. In some cases (particularly when the selection algorithm is influenced by the adjustment of a route property that is not propagated into IBGP) it could be necessary for routing correctness to propagate the validation state to the IBGP peer. This can be accomplished on the sending side by setting a community or extended community based on the validation state, and on the receiving side by matching the (extended) community and setting the validation state." Maureen --0003255751eab8d94804995b96e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is an important document.=A0

I have 2 = comments, 2 nits, one question and a comparison of this draft with=20 draft-sidr-pfx-validate section 6 called "deployment considerations&qu= ot;.=A0 I have reviewed Section 5 of draft-sidr- origin-ops only.

Comment 1) The validation state terminology used in this draft is not consistent with the terminology of=20 draft-sidr-pfx-validate.=A0 That draft uses states: valid, invalid, not=20 found, whereas this draft uses states: valid, invalid, unknown.=A0 Do we=20 want these to be consistent across i-ds?=A0 The 3 states are defined in=20 draft-sidr-pfx-validate but are not defined here.=A0 We should either=20 define them or point to the definition in draft-sidr-pfx-validate where=20 they are defined.=A0 I will refer to this as state "not found" in= the=20 remainder of my comments.

Comment 2) Some suggested te= xt below for the opening of section 5.

Section 5. Routing Poli= cy

Background

Currently, the origin status information is not verified.=A0 With the incremental=20 deployment of RPKI, we will transition to origin validation comprised of three states: valid, invalid and not found [see=20 draft-sidr-pfx-validate].=A0 We specify a relative preference associated=20 with each state as follows:=A0 
Announcements with valid origins SHOU=
LD be preferred over those with *not found* or invalid origins.
<=
br>
A=
nnouncements with *not found* origin SHOULD be preferred over those with in=
valid origins.
An=
nouncements with invalid origins MAY be used, but SHOULD be less preferred =
than those with valid or *not found*.
During the RPKI transition period, relative preference is introduced to manage the uncertainty associated with a system in flux.=A0 As the RPKI=20 transition moves forward, the number of origin validations with state=20 "not found" will decrease.=A0

Nits:

Section 5. Routing Policy
 1) Reasonable application of local policy should be designed eliminate the = threat of unroutability of prefixes due to ill-advised or
incorrect c= ertification policies.

Suggestion:
Reasona= ble application of local policy should be designed *to* eliminate the threa= t of unroutability of prefixes due to ill-advised or
incorrect certif= ication policies.

2) = As origin validation will be rolled out over years coverage will be spotty = for a long time. Hence a normal operator's policy should not
be = overly strict, perhaps preferring valid announcements and giving very low p= reference, but still using, invalid announcements.

Suggestion:
As origin validation will be rolled out *incrementally* c= overage will be *incomplete* for a long time. Hence an *word deleted* op= erator's policy
should not be overly strict, perhaps preferring valid announcements, *attac= hing a lower preference to but still using, not found announcements*
an= d giving very low preference, but still using, invalid announcements.=

I deleted the word "normal" since I don't know= what normal is. I think you need to point out here that they will use all= three, valid, invalid
and not found announcement. For some reason it is missing from this = paragraph but is correctly included in the list below.
Question:


I'm not sure I understand this.  

"Reasonable application of local policy should be designed =
*to* eliminate the threat of unroutability of prefixes due to ill-advised o=
r

incorrect certification policies."
What is ill-=
advised as opposed to incorrect?  Does ill-advised means one kind of error =
and incorrect another?  

If they are really one problem, then just use one term.
Comparison of draft-sidr-pfx-validate section 6 called "deploym=
ent considerations":

I'm=
 confused by the relationship of this draft to draft-sidr-pfx-validate sect=
ion 6 called "deployment considerations".  Is this

the operational section and therefore should draft-sidr-pfx-validate<=
/font> reference draft-sidr-origin-ops?  The deployment guidance is not 
the same in sidr-pfx-validate as it is in sidr-origin-ops in the sense that=
 there are no SHOULDs or MUSTs.  The deployment considerations
in sidr-p=
fx-validate are just advice.  Here is the specific text from <=
font style=3D"font-family: arial,helvetica,sans-serif;" size=3D"2">draft-si=
dr-pfx-validate:


6.  Deployment Considerations
"Once a route is received fr=
om an EBGP peer it is categorized
   according the procedure given in se=
ction 2.  Subsequently, routing

   policy as discussed in section 3 can be used=
 to take action based on
   the validation state.

   Policies whi=
ch could be implemented include filtering routes based on

   validation state (for example, rejecting all "invalid" routes)=
 or
   adjusting a route's degree of preference in the selection alg=
orithm
   based on its validation state.  The latter could be accomplish=
ed by

   adjusting the value of such attributes as LOCAL_PREF.

   In some =
cases (particularly when the selection algorithm is
   influenced by the=
 adjustment of a route property that is not
   propagated into IBGP) it =
could be necessary for routing correctness

   to propagate the validation state to the IBGP peer.  This can be
   accomplished on the sendi=
ng side by setting a community or extended

   community based on the validation state, and on the receiving side by   matching the (extended) community and setting the validation state.&quo=
t;


Maureen
--0003255751eab8d94804995b96e5-- From randy@psg.com Sat Jan 8 13:52:49 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6A03A68BB for ; Sat, 8 Jan 2011 13:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FZddHS4ADTTA for ; Sat, 8 Jan 2011 13:52:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D469F3A68B9 for ; Sat, 8 Jan 2011 13:52:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbgkQ-000MvQ-O2; Sat, 08 Jan 2011 21:54:55 +0000 Date: Sun, 09 Jan 2011 06:54:52 +0900 Message-ID: From: Randy Bush To: Maureen Stillman In-Reply-To: References: 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 Cc: sidr wg list Subject: Re: [sidr] Comments on draft-sidr-origin-ops-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 21:52:49 -0000 thank you, thank you, thank you, for your review. > Comment 1) The validation state terminology used in this draft is not > consistent with the terminology of draft-sidr-pfx-validate. That > draft uses states: valid, invalid, not found, whereas this draft uses > states: valid, invalid, unknown. Do we want these to be consistent > across i-ds? The 3 states are defined in draft-sidr-pfx-validate but > are not defined here. We should either define them or point to the > definition in draft-sidr-pfx-validate where they are defined. thanks. will do. are you happy with "not found?" i have had to sit through meetings with a bunch of folk discussing this until i had to leave the room, and definitely have lost any opinion i might have ever had on the subject. > I will refer to this as state "not found" in the remainder of my > comments. whack me now, as i will make the change after more coffee. > Comment 2) Some suggested text below for the opening of section 5. > > Section 5. Routing Policy > > Background > > Currently, the origin status information is not verified. With the > incremental deployment of RPKI, we will transition to origin > validation comprised of three states: valid, invalid and not found > [see draft-sidr-pfx-validate]. We specify a relative preference > associated with each state as follows: i am thinking of softening to s/We specify/In the absense of other designed policy, we recommend/ > Announcements with valid origins SHOULD be preferred over those with > *not found* or invalid origins. > > Announcements with *not found* origin SHOULD be preferred over those > with invalid origins. > > Announcements with invalid origins MAY be used, but SHOULD be less > preferred than those with valid or *not found*. > > During the RPKI transition period, relative preference is introduced > to manage the uncertainty associated with a system in flux. As the > RPKI transition moves forward, the number of origin validations with > state "not found" will decrease. thanks > Reasonable application of local policy should be designed *to* > eliminate the threat of unroutability of prefixes due to ill-advised > or incorrect certification policies. thanks > 2) As origin validation will be rolled out over years coverage will be > spotty for a long time. Hence a normal operator's policy should > not be overly strict, perhaps preferring valid announcements and > giving very low preference, but still using, invalid announcements. > > Suggestion: > As origin validation will be rolled out *incrementally* coverage will > be *incomplete* for a long time. Hence an *word deleted* operator's > policy should not be overly strict, perhaps preferring valid > announcements, *attaching a lower preference to but still using, not > found announcements* and giving very low preference, but still using, > invalid announcements. > > I deleted the word "normal" since I don't know what normal is. I > think you need to point out here that they will use all three, valid, > invalid and not found announcement. For some reason it is missing > from this paragraph but is correctly included in the list below. i pretty much agree with all this. but let me explain my weaseling and 'normal.' in the back of my mind, i have operators who do weird things such as security research, monitoring of the state of the validation world, ... who may do strange things such as prefer invalid. perhaps i should not be weaseling about that and stick to vanilla, chocolate, and strawberry? > "Reasonable application of local policy should be designed *to* > eliminate the threat of unroutability of prefixes due to ill-advised > or incorrect certification policies." > > What is ill-advised as opposed to incorrect? Does ill-advised means > one kind of error and incorrect another? If they are really one > problem, then just use one term. two problems. one is incorrect, erroneous, ... another is the set of issues devolving from the x.509 base requiring altrustic action by a chain of organizations. a significant number of operators, including me on odd days of the week, are extremely worried about ICANN, RIR, ... policies with regard to the RPKI. think things such as legacy space, RIR 'customers' in conflict with the RIR, ... > Comparison of draft-sidr-pfx-validate section 6 called "deployment > considerations": > > I'm confused by the relationship of this draft to > draft-sidr-pfx-validate section 6 called "deployment considerations". > Is this the operational section and therefore should > draft-sidr-pfx-validate reference draft-sidr-origin-ops? probably a reference from pfx-validate would be good. i'll have a talk with the authors :) > The deployment guidance is not the same in sidr-pfx-validate as it is > in sidr-origin-ops in the sense that there are no SHOULDs or > MUSTs. The deployment considerations in sidr-pfx-validate are just > advice. Here is the specific text from draft-sidr-pfx-validate: > > 6. Deployment Considerations > > "Once a route is received from an EBGP peer it is categorized > according the procedure given in section 2. Subsequently, routing > policy as discussed in section 3 > > can be used to take action based on the validation state. > > Policies which could be implemented include filtering routes based on > validation state (for example, rejecting all "invalid" routes) or > adjusting a route's degree of preference in the selection algorithm > based on its validation state. The latter could be accomplished by > adjusting the value of such attributes as LOCAL_PREF. > > In some cases (particularly when the selection algorithm is > influenced by the adjustment of a route property that is not > propagated into IBGP) it could be necessary for routing correctness > to propagate the validation state to the IBGP peer. This can be > accomplished on the sending side by setting a community or extended > community based on the validation state, and on the receiving side > by matching the (extended) community and setting the validation > state." i am not sure if this conflicts with or even overlays origin-ops. it is not suggesting policy, merely discussing mechanisms. clue bat please. and thanks again! randy From randy@psg.com Sat Jan 8 14:22:42 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742E53A68BD for ; Sat, 8 Jan 2011 14:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 KcrOtDaGaJos for ; Sat, 8 Jan 2011 14:22:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 9A7993A6842 for ; Sat, 8 Jan 2011 14:22:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PbhDN-000N8U-6K; Sat, 08 Jan 2011 22:24:49 +0000 Date: Sun, 09 Jan 2011 07:24:46 +0900 Message-ID: From: Randy Bush To: Maureen Stillman In-Reply-To: References: 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 Cc: sidr@ietf.org Subject: Re: [sidr] Comments on draft-sidr-origin-ops-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2011 22:22:42 -0000 > Currently, the origin status information is not verified. With the > incremental deployment of RPKI, we will transition to origin > validation comprised of three states: valid, invalid and not found > [see draft-sidr-pfx-validate]. hmmmm. formally, currently the origin status information is Not Found. randy From Internet-Drafts@ietf.org Sat Jan 8 20:30:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B2A43A68BA; Sat, 8 Jan 2011 20:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 hVrw8DXQtwW1; Sat, 8 Jan 2011 20:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844713A6817; Sat, 8 Jan 2011 20:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110109043002.9268.33182.idtracker@localhost> Date: Sat, 08 Jan 2011 20:30:02 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2011 04:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operations Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-01.txt Pages : 7 Date : 2011-01-08 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-08202250.I-D@ietf.org> --NextPart-- From maureen.stillman@gmail.com Sun Jan 9 18:17:27 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FED28C0E8 for ; Sun, 9 Jan 2011 18:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SMkSxLEu2abj for ; Sun, 9 Jan 2011 18:17:26 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2BFDF28C0E5 for ; Sun, 9 Jan 2011 18:17:26 -0800 (PST) Received: by iwn40 with SMTP id 40so20027293iwn.31 for ; Sun, 09 Jan 2011 18:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ClRg/BrN2pnadOC0WcHFQS00b1e4vjXD6US05qMn6z8=; b=Bv/DpVrWnhLZov1kO/aM5tHHG7KTAGHLFuLU/oc9WvMvvgRMyA5i4SdOPUXFjokSZ8 HmbY2y5vfZ1/GI1L6VCRSU55c44vxLuQFMmhTkxUIotRuFikx4xu2mpk7y0g2rfo5JZW h8r5R2lSxbE4dYZlJMWJFnYbcupw+79q3xdy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZoWtwZ+TF/2GFdNaq21bndk3kjLhdNK97WjxWkdYbUX3+q3/15+OJd+jz6yZTxRf3e MrSB+4MnBIRkK+ygsSi7u3UxgOjaeDR8nmm6HTIG7QqLgLbpjsSYVvqC8momZnkCQoPG YjtW+cuydDr9SONSF9B+DViXReIgD05DU47/4= MIME-Version: 1.0 Received: by 10.231.15.8 with SMTP id i8mr12111237iba.125.1294625978340; Sun, 09 Jan 2011 18:19:38 -0800 (PST) Received: by 10.231.167.193 with HTTP; Sun, 9 Jan 2011 18:19:38 -0800 (PST) In-Reply-To: References: Date: Sun, 9 Jan 2011 20:19:38 -0600 Message-ID: From: Maureen Stillman To: Randy Bush Content-Type: multipart/alternative; boundary=002215047c9b8e6102049974992e Cc: sidr wg list Subject: Re: [sidr] Comments on draft-sidr-origin-ops-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 02:17:27 -0000 --002215047c9b8e6102049974992e Content-Type: text/plain; charset=ISO-8859-1 See inline replies indicated with *** below. On Sat, Jan 8, 2011 at 3:54 PM, Randy Bush wrote: > thank you, thank you, thank you, for your review. > > > Comment 1) The validation state terminology used in this draft is not > > consistent with the terminology of draft-sidr-pfx-validate. That > > draft uses states: valid, invalid, not found, whereas this draft uses > > states: valid, invalid, unknown. Do we want these to be consistent > > across i-ds? The 3 states are defined in draft-sidr-pfx-validate but > > are not defined here. We should either define them or point to the > > definition in draft-sidr-pfx-validate where they are defined. > > thanks. will do. are you happy with "not found?" i have had to sit > through meetings with a bunch of folk discussing this until i had to > leave the room, and definitely have lost any opinion i might have ever > had on the subject. > *** I don't care which is used as long as it is the same in all internet drafts. > > > Comparison of draft-sidr-pfx-validate section 6 called "deployment > > considerations": > > > > I'm confused by the relationship of this draft to > > draft-sidr-pfx-validate section 6 called "deployment considerations". > > Is this the operational section and therefore should > > draft-sidr-pfx-validate reference draft-sidr-origin-ops? > > probably a reference from pfx-validate would be good. i'll have a talk > with the authors :) > *** Agree. > > > The deployment guidance is not the same in sidr-pfx-validate as it is > > in sidr-origin-ops in the sense that there are no SHOULDs or > > MUSTs. The deployment considerations in sidr-pfx-validate are just > > advice. Here is the specific text from draft-sidr-pfx-validate: > > > > 6. Deployment Considerations > > > > "Once a route is received from an EBGP peer it is categorized > > according the procedure given in section 2. Subsequently, routing > > policy as discussed in section 3 > > > > > can be used to take action based on the validation state. > > > > Policies which could be implemented include filtering routes based on > > validation state (for example, rejecting all "invalid" routes) or > > adjusting a route's degree of preference in the selection algorithm > > based on its validation state. The latter could be accomplished by > > adjusting the value of such attributes as LOCAL_PREF. > > > > In some cases (particularly when the selection algorithm is > > influenced by the adjustment of a route property that is not > > propagated into IBGP) it could be necessary for routing correctness > > to propagate the validation state to the IBGP peer. This can be > > accomplished on the sending side by setting a community or extended > > community based on the validation state, and on the receiving side > > by matching the (extended) community and setting the validation > > state." > > i am not sure if this conflicts with or even overlays origin-ops. it is > not suggesting policy, merely discussing mechanisms. clue bat please. > **** Well, frankly I think your text is just perfect and I prefer it to what is in the first paragraph of this deployment considerations section. (I'm ignoring the second paragraph for this discussion BTW.) By the use of the word SHOULD instead of MUST along with the ranking of the relative preference, you convey a strong sense of what the best practice is without mandating it. I think this is exactly the right way to do it. Notice above how they talk about throwing information away as an example "(for example, rejecting all invalid routes)", but your text points out why you might not want to do this in case there is some problem/error. The relative preference guidelines are a very clever way of handling this state information and I was convinced it was the best way to do it after reading your draft. As to whether or not the text (first paragraph above) conflicts or overlays what you have written: Since you did not use the word MUST, it does not conflict with it because you allow anything. They allow anything as well because they neither used MUST nor SHOULD. However, if your guidelines are taken (meaning the SHOULDs), I believe your guidelines are a subset of what is recommended above. The important point is that your recommendations are more specific and I feel like I have a better idea of what to do with the state information and the advice is both sound and clever. This is why I like what you wrote and think it should be referenced in this section of draft-sidr-pfx-validate so they don't miss it. Maureen > and thanks again! > > randy > --002215047c9b8e6102049974992e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable See inline replies indicated with *** below.

On Sat, Jan 8, 2011 at 3:54 PM, Randy Bush <randy@psg.com> wrote:
thank you, thank you, thank you, for your review.

> Comment 1) The validation state terminology used in this draft is not<= br> > consistent with the terminology of draft-sidr-pfx-validate. =A0That > draft uses states: valid, invalid, not found, whereas this draft uses<= br> > states: valid, invalid, unknown. =A0Do we want these to be consistent<= br> > across i-ds? =A0The 3 states are defined in draft-sidr-pfx-validate bu= t
> are not defined here. =A0We should either define them or point to the<= br> > definition in draft-sidr-pfx-validate where they are defined.

thanks. =A0will do. =A0are you happy with "not found?" =A0i= have had to sit
through meetings with a bunch of folk discussing this until i had to
leave the room, and definitely have lost any opinion i might have ever
had on the subject.

*** I don't care which is = used as long as it is the same in all internet drafts.
=A0

> Comparison of draft-sidr-pfx-validate section 6 called "deploymen= t
> considerations":
>
> I'm confused by the relationship of this draft to
> draft-sidr-pfx-validate section 6 called "deployment consideratio= ns".
> Is this the operational section and therefore should
> draft-sidr-pfx-validate reference draft-sidr-origin-ops?

probably a reference from pfx-validate would be good. =A0i'll hav= e a talk
with the authors :)

*** Agree.

> The deployment guidance is not the same in sidr-pfx-validate as it is<= br> > in sidr-origin-ops in the sense that there are no SHOULDs or
> MUSTs. The deployment considerations in sidr-pfx-validate are just
> advice. Here is the specific text from draft-sidr-pfx-validate:
>
> 6. Deployment Considerations
>
> =A0 "Once a route is received from an EBGP peer it is categorized=
> =A0 =A0according the procedure given in section 2. =A0Subsequently, ro= uting
> =A0 =A0policy as discussed in section 3
> =A0 =A0<http://tools.ietf.org/html/dr= aft-ietf-sidr-pfx-validate-00#section-3>
> =A0 =A0can be used to take action based on the valid= ation state.
>
> =A0 =A0Policies which could be implemented include filtering routes ba= sed on
> =A0 =A0validation state (for example, rejecting all "invalid"= ; routes) or
> =A0 =A0adjusting a route's degree of preference in the selection a= lgorithm
> =A0 =A0based on its validation state. =A0The latter could be accomplis= hed by
> =A0 =A0adjusting the value of such attributes as LOCAL_PREF.
>
> =A0 =A0In some cases (particularly when the selection algorithm is
> =A0 =A0influenced by the adjustment of a route property that is not > =A0 =A0propagated into IBGP) it could be necessary for routing correct= ness
> =A0 =A0to propagate the validation state to the IBGP peer. =A0This can= be
> =A0 =A0accomplished on the sending side by setting a community or exte= nded
> =A0 =A0community based on the validation state, and on the receiving s= ide
> =A0 =A0by matching the (extended) community and setting the validation=
> =A0 =A0state."

i am not sure if this conflicts with or even overlays origin-ops. =A0= it is
not suggesting policy, merely discussing mechanisms. =A0clue bat please.

**** Well, frankly I think your text is just perfect= and I prefer it to what is in the first paragraph of this deployment consi= derations section.=A0 (I'm ignoring the second paragraph for this discu= ssion BTW.)=A0 By the use of the word SHOULD instead of MUST along with the= ranking of the relative preference, you convey a strong sense of what the = best practice is without mandating it.=A0 I think this is exactly the right= way to do it.=A0 Notice above how they talk about throwing information awa= y as an example "(for example, rejecting all invalid routes)", bu= t your text=A0 points out why you might not want to do this in case there i= s some problem/error.=A0 The relative preference guidelines are a very clev= er way of handling this state information and I was convinced it was the be= st way to do it after reading your draft.=A0

As to whether or not the text (first paragraph above) conflicts or over= lays what you have written:=A0

Since you did not use the word MUST,= it does not conflict with it because you allow anything.=A0 They allow any= thing as well because they neither used MUST nor SHOULD.=A0=A0 However, if = your guidelines are taken (meaning the SHOULDs), I believe your guidelines = are a subset of what is recommended above.=A0 The important point is that y= our recommendations are more specific and I feel like I have a better idea = of what to do with the state information and the advice is both sound and c= lever.

This is why I like what you wrote and think it should be referenced in = this section of draft-sidr-pfx-validate so they don't miss it.

M= aureen


and thanks again!

randy

--002215047c9b8e6102049974992e-- From Internet-Drafts@ietf.org Wed Jan 12 14:45:03 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9D33A67EC; Wed, 12 Jan 2011 14:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 GJ0UUXBQX2+4; Wed, 12 Jan 2011 14:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007AB3A67C1; Wed, 12 Jan 2011 14:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110112224501.32552.66629.idtracker@localhost> Date: Wed, 12 Jan 2011 14:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-rtr-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 22:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : The RPKI/Router Protocol Author(s) : R. Bush, R. Austein Filename : draft-ietf-sidr-rpki-rtr-07.txt Pages : 21 Date : 2011-01-12 In order to formally validate the origin ASes of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers over ssh. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-rtr-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-12144430.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Jan 18 18:15:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86DB03A70AC; Tue, 18 Jan 2011 18:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 0g7Cdzl28Mog; Tue, 18 Jan 2011 18:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C983A70A9; Tue, 18 Jan 2011 18:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110119021501.9881.25010.idtracker@localhost> Date: Tue, 18 Jan 2011 18:15:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 02:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-02.txt Pages : 7 Date : 2011-01-18 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-18180446.I-D@ietf.org> --NextPart-- From Wesley.E.George@sprint.com Wed Jan 19 06:21:14 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2C63A7131 for ; Wed, 19 Jan 2011 06:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 SMm8TlIjjQWH for ; Wed, 19 Jan 2011 06:21:13 -0800 (PST) Received: from VA3EHSOBE009.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id B56C63A70F5 for ; Wed, 19 Jan 2011 06:21:12 -0800 (PST) Received: from mail182-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.8; Wed, 19 Jan 2011 14:23:52 +0000 Received: from mail182-va3 (localhost.localdomain [127.0.0.1]) by mail182-va3-R.bigfish.com (Postfix) with ESMTP id 83A754D84EC; Wed, 19 Jan 2011 14:23:52 +0000 (UTC) X-SpamScore: -5 X-BigFish: VS-5(zz4015L10d1Izz1202hzzz2fh2a8h668h34h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm1.corp.sprint.com; RD:smtpda1.sprint.com; EFVD:NLI Received: from mail182-va3 (localhost.localdomain [127.0.0.1]) by mail182-va3 (MessageSwitch) id 1295447031220181_16037; Wed, 19 Jan 2011 14:23:51 +0000 (UTC) Received: from VA3EHSMHS009.bigfish.com (unknown [10.7.14.238]) by mail182-va3.bigfish.com (Postfix) with ESMTP id 2B3DD290054; Wed, 19 Jan 2011 14:23:51 +0000 (UTC) Received: from pdaasdm1.corp.sprint.com (144.229.32.56) by VA3EHSMHS009.bigfish.com (10.7.99.19) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 19 Jan 2011 14:23:49 +0000 Received: from PDAWEH01.ad.sprint.com (PDAWEH01.corp.sprint.com [144.226.110.69]) by pdaasdm1.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0JE9ZKK026314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jan 2011 08:09:39 -0600 Received: from PDAWEH04.ad.sprint.com (144.226.111.59) by PDAWEH01.ad.sprint.com (144.226.110.69) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 19 Jan 2011 08:23:44 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH04.ad.sprint.com ([2002:90e2:6f3b::90e2:6f3b]) with mapi id 14.01.0270.001; Wed, 19 Jan 2011 08:23:44 -0600 From: "George, Wes E [NTK]" To: "sidr@ietf.org" Thread-Topic: comment on draft-ietf-sidr-origin-ops Thread-Index: Acu35HjqBvA/Fw2YQzu9DrwGB36FQw== Date: Wed, 19 Jan 2011 14:23:43 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E058985@PLSWM12A.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.20] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01CBB7BA.902BC9E0" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Subject: [sidr] comment on draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:21:14 -0000 ------=_NextPart_000_0048_01CBB7BA.902BC9E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Just reviewed the -02 version, and something occurred to me. I think it makes sense to include in this draft since it's basically an operational consideration, but it could also fit in the sidr-pfx-validate draft. Since we're recommending LocalPref as one of the ways to influence routing decisions using the RPKI validation data, we probably need something pointing out that care must be taken to avoid (or at least understand the significance of) LocalPref race conditions. That is, other route policies already in effect that change the LocalPref value on one or more routes may be in conflict with the values being set by the RPKI route policy. For example, if a provider listens to communities that allow eBGP peers to raise or lower the LocalPref on routes that they announce to that ASN, and if LocalPref values for RPKI validation are set improperly, it could have the side effect that someone could inject an invalid route tagged with the community to raise LocalPref to a level that it is still considered along with the rest of the valid routes, which would make the RPKI largely ineffective on that ASN. Or if LP is lowered by policy for certain ASNs because those routes are less preferable, only to have them raised again by RPKI validation, that may have undesired consequences in traffic flow across the network. Ultimately, the decision of what value to set in LocalPref for each policy (valid, invalid, unknown, plus any additional policies) and which "wins" in any race condition is up to the provider. During the rollout, it may even be desired behavior to allow customers to compensate for LocalPref changes being brought on by RPKI that suddenly redirect traffic to a different route on certain networks because of inconsistent participation in the RPKI, but we probably need to make it clear that this should be a temporary measure, or else it defeats the purpose of RPKI. It may be that those who use community-tag policies like this will need to make them more complex (integrate the RPKI policy into them) so that different LocalPref values are set based on the community being set PLUS the RPKI validity state, rather than two separate policies that can potentially fight each other. I don't know if we want to explicitly recommend that here or not, but it might be worth suggesting. Either way, I think we do need to cover this, both from the potential security angle and from the traffic engineering angle. Thanks, Wes George ------=_NextPart_000_0048_01CBB7BA.902BC9E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMTkxNDIzNDJaMCMGCSqGSIb3DQEJBDEWBBR6vmOGORdt 6fQ1JSfuZqBRgT/QFjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYBa2qJwMacJfsI3 jVZnC9VoA0joWmJUwQXToHlmeZ5H9GR59dANKdb9pYNxE7MKMM+7rS3XvP8K7LZgK/euI6J+dzHO dLZ7Q1I6rWwmRs8o8PYGgN5bX2F6ok/j10wBNeXSI/cpfp6T3nsSGGO9zhXH3e3ud9EfvBd0PYFK jZsVngAAAAAAAA== ------=_NextPart_000_0048_01CBB7BA.902BC9E0-- From randy@psg.com Wed Jan 19 23:54:11 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CECEB3A7094 for ; Wed, 19 Jan 2011 23:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 75+tOcBhlEsT for ; Wed, 19 Jan 2011 23:54:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id CFAC03A6DAD for ; Wed, 19 Jan 2011 23:54:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PfpNy-000ODl-Gn; Thu, 20 Jan 2011 07:56:50 +0000 Date: Thu, 20 Jan 2011 16:56:54 +0900 Message-ID: From: Randy Bush To: "George, Wes E [NTK]" In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E058985@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E058985@PLSWM12A.ad.sprint.com> 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 Cc: "sidr@ietf.org" Subject: Re: [sidr] comment on draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 07:54:12 -0000 intereting. how about When using a metric which is also influenced by other local policy, the operator should be careful not to create privilege upgrade vulnerabilities. E.g. if Local Pref is set depending on validity state, be careful that peer community signaling can not upgrade an invalid announcement to valid or better. randy From Wesley.E.George@sprint.com Thu Jan 20 10:11:04 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 338603A7011 for ; Thu, 20 Jan 2011 10:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.996 X-Spam-Level: X-Spam-Status: No, score=-3.996 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lHoJRDXKduoM for ; Thu, 20 Jan 2011 10:11:01 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by core3.amsl.com (Postfix) with ESMTP id 957D73A7041 for ; Thu, 20 Jan 2011 10:11:00 -0800 (PST) Received: from mail37-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.8; Thu, 20 Jan 2011 18:13:43 +0000 Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3-R.bigfish.com (Postfix) with ESMTP id 6A088A842B; Thu, 20 Jan 2011 18:13:43 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz542N1432N9371Pzz1202hzz8275dh1033ILz2fh2a8h668h34h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:pdaasdm2.corp.sprint.com; RD:smtpda2.sprint.com; EFVD:NLI X-FB-SS: 13, Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3 (MessageSwitch) id 1295547223237357_21521; Thu, 20 Jan 2011 18:13:43 +0000 (UTC) Received: from DB3EHSMHS005.bigfish.com (unknown [10.3.81.251]) by mail37-db3.bigfish.com (Postfix) with ESMTP id 37F5710C0094; Thu, 20 Jan 2011 18:13:43 +0000 (UTC) Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by DB3EHSMHS005.bigfish.com (10.3.87.105) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 20 Jan 2011 18:13:41 +0000 Received: from PDAWEH02.ad.sprint.com (PDAWEH02.corp.sprint.com [144.226.111.42]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.0.5/Sentrion-MTA-4.0.5) with ESMTP id p0KI6env011918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jan 2011 12:06:40 -0600 Received: from PLSWM12A.ad.sprint.com ([fe80::dd81:e8a1:cd6b:78f]) by PDAWEH02.ad.sprint.com ([2002:90e2:6f2a::90e2:6f2a]) with mapi id 14.01.0270.001; Thu, 20 Jan 2011 12:13:39 -0600 From: "George, Wes E [NTK]" To: Randy Bush Thread-Topic: comment on draft-ietf-sidr-origin-ops Thread-Index: AQHLuHefh6zZupyW9UmcQSNy6N9AiZPaKmHw Date: Thu, 20 Jan 2011 18:13:38 +0000 Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E059311@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E058985@PLSWM12A.ad.sprint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.27] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0084_01CBB8A3.D890A810" MIME-Version: 1.0 X-OriginatorOrg: sprint.com Cc: "sidr@ietf.org" Subject: Re: [sidr] comment on draft-ietf-sidr-origin-ops X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 18:11:04 -0000 ------=_NextPart_000_0084_01CBB8A3.D890A810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sounds ok to me. Would that go in the security considerations section, or in the main body? If in the main body, you might want at least a reference calling it out in the security considerations. Wes > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Thursday, January 20, 2011 2:57 AM > To: George, Wes E [NTK] > Cc: sidr@ietf.org > Subject: Re: comment on draft-ietf-sidr-origin-ops > > intereting. how about > > When using a metric which is also influenced by other local > policy, the operator should be careful not to create privilege > upgrade vulnerabilities. E.g. if Local Pref is set depending on > validity state, be careful that peer community signaling can not > upgrade an invalid announcement to valid or better. > > randy ------=_NextPart_000_0084_01CBB8A3.D890A810 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXHjCCBPYw ggPeoAMCAQICChTCbVgAAAAAAAUwDQYJKoZIhvcNAQEFBQAwcTEbMBkGA1UECxMSQ29weXJpZ2h0 IChjKSAyMDA3MRYwFAYDVQQLEw1TcHJpbnQgTmV4dGVsMTowOAYDVQQDEzFTcHJpbnQgTmV4dGVs IEVudGVycHJpc2UgSW50ZXJtZWRpYXRlIDEgQXV0aG9yaXR5MB4XDTA3MDcxNzE5NDIxNloXDTE1 MDcxNzE5NTIxNloweDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmlu dDESMBAGCgmSJomT8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2Ug SXNzdWluZyAxIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL95aoB4 LLMFIOaq8WTtWyNCb7m5xoKdM6oJKXsCx8k8GATPtiX7VPXKMjRNv+jMZXKF9U6RA4wjSKiKMOYg 48ioSpanTxp+7p6+00Nr/eEtjsY+21rDQbANaqFGfkRFv4m59jM53j+mEXIDybTttcQN/CdSvI0d XOD3KxQTPaG+h9uqZmkrdlk/rwvGbKhqmsl2BApItCDlUWt4rbv0GYQR4GP0w6c7e5prJBh89PEq y+NDtv14YqYl5zOBST4IoHX77uS9gZXqglhtpYKDfESgrgcMldsfKyjrOwiRlT7o8ez1iOyCULkp RcGLSe3wxZxx82bPEYjSWJf56V21FV0CAwEAAaOCAYcwggGDMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFAGPJVAshjSbwX6QH9mINbU/rwuJMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBRRAcgiA5nZbiss2II5eNyr GXZEcTBuBgNVHR8EZzBlMGOgYaBfhjBodHRwOi8vY3JsLmNvcnAuc3ByaW50LmNvbS9QUEtJV0Iw MS9QUEtJV0IwMS5jcmyGK2h0dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0IwMS9QUEtJV0IwMS5j cmwwgYUGCCsGAQUFBwEBBHkwdzA8BggrBgEFBQcwAoYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MDcGCCsGAQUFBzAChitodHRwOi8vY3JsLnNwcmludC5j b20vUFBLSVdCMDEvUFBLSVdCMDEuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCpeKWuin6cpun45r8E cmaxzwvYsNiZhC3iTS6sMIbUaSZZM7N0+UavCDZX04/9xlFUQNchlMezJDDlrM2EZyEZ2gDZDN65 22gWd8sJHyi5M8yruC42PHGePBdV8sY0EEB2dxuMsV+jQ1uBThyv1Oo8F38FjEuodYIlYuOWVxPY sDiWNAJ0K0wq+EzxHgxuYO3Afg6pc4TlmHH9ZkWhNC6Lb1MzQjlp+a0FUWAljzZe/QeYbZEINsHx swoQIO0/Uyg9ZUTK3K3mGWmWVdrPjYk3UJCfjOU3qLqIM5J17St7wd1o9Q9UDDJowUKgIZVXH6oY obBGb7rBuyi/SEG5pNHGMIIFkzCCA3ugAwIBAgIQRmQhybpKpLtIEeJdHD7ivzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTYyODI1 WhcNMjcwNTIyMTYzNTUyWjBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwggIi MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCXnrAnWxH9Pnu51vYiwtYe6Q6hcRrIZr84JcW+ 9ze9zfu5pE3+PcsMzk6q5roX7LnwU/omHSUlKCMpnu2D78I5+VsA+U3in/2T0qN3VEdo2jvO8WZH 7KPwVGqYsbJBPk1cNYiRSKG2CRxsdWTDFpn2ri5/rsfWd7U8ZrNPMlFG17kVKJpb5E3e4d4PP7E9 /snxYnG0PCgT8kTe6SVTLIR0nlWZ6J+MvqGiWu21yd5BNFNFzfTitSgDkGtQZ17HbjmXCBkv3ULr 7jM19TAt5ZFjVewmvJPIKZT9/9+7KT6QaQVe/Ao7Xc9tFKgaEBwMCxLRPLHsxEi4oCgr/0N7wyIe CoZropYeM3fxkFIRqa7hGSNQ0HLC51o/LpljxhrNjkoILnyL48mgevqdsER8jz7hlITqy3rHcyCM HLmlt0YlKEYTTr9REXNnoUXNBkvJQPJgyl44xdaUzm3n8ydPtO4Cl0grRouQ4CJ3fQ2Hfi90zYhc vs3hPI4YgccdUv9l2X++lRnazRME7FSGPd9RQh5eerR3bSWBukYo5KwgMGxyIU/hpraYHI38bbiA PZmmpZ8vFk6iP2zVXHTkH+PqatzYGNdSkHLYQG5NM3GZlrE3khygDpfBuNo/VFtzIXAqNfWPJq7y QM7AkGwbN5Y9uOalzh74O+Ej+nQUhVCuaZ46NQIDAQABo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU6o073JNr96Z42jmfdFu4WxRjgs0wEAYJKwYBBAGCNxUBBAMC AQAwDQYJKoZIhvcNAQEFBQADggIBAHIdGEzkUTJjPn1vyv/vL944OZ8hoVd6anmS1OMR+vRn9L5i fdfmos332+Y+TGGB74lLeMp6lsP1tRd9TgMhB2DvcShCoEpyX8lNdiVczo4cKkZ5zSbaQzlK8Cfr necuMFiFEk2Hi+T790l7DKSz4NbKfZGokZIx15grgrKlGK5ZQuTjfudKfguAXqFasFuxsLX4tcT1 2W2dcBjHdQxJy9LbwDJK39cgOuJlHj+VhwR07ZwS8by5JCm5JbOOrv40uyEWc1mnY6E8Jptq6iyf wpItMr1gAJ1bVkaKjHXfyEqb0OPgu5sbne9mSIJQlwxiiHYHIB4OJXY5bczKpb2OAyyb9jmF/jC6 LMBhl7SmM81ftBiD1HQctqirilaUTlKNtIaZN7dZBFltnQyqSZE6GtQ+xOgojNGyceE/MI9asIFJ jGVXYgUUX15Ri7OajEF+0E3DliTN2VZ2ECmdsuvGyz4AC+pWl8jZLPWUNsGfTgSR1S1+5iIRb6ia yAkpKanTWNTPOPbTGbcetg5oXuKaPywcr6znRysmh1e+spAviXR/o5wv5NyApPix5sxV4urovGJ5 cVu07fw8UPMI0/25cJ4P+owxoRMRMWuEO7K1AF0GuCPr84v0d+CZLb3FqoK3DNJBLTvqGPA8VnAZ ukt2co0Mcw8raOlCypTSGnYoWz0JMIIF2jCCA8KgAwIBAgIKYSGdxgAAAAAAAzANBgkqhkiG9w0B AQUFADBcMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsTDVNwcmludCBOZXh0 ZWwxJTAjBgNVBAMTHFNwcmludCBOZXh0ZWwgUm9vdCBBdXRob3JpdHkwHhcNMDcwNTIyMTk1MjQw WhcNMjAwNTIyMjAwMjQwWjBxMRswGQYDVQQLExJDb3B5cmlnaHQgKGMpIDIwMDcxFjAUBgNVBAsT DVNwcmludCBOZXh0ZWwxOjA4BgNVBAMTMVNwcmludCBOZXh0ZWwgRW50ZXJwcmlzZSBJbnRlcm1l ZGlhdGUgMSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCp5IX+RYNn IeUe+BkJ5VfMppHbxZlrSzd831LTblSkdTXQyi8+5A1p1ZObUSzm5mIW352SxStOtGvfSRTKcLg4 HBiZyArS+pQ8QvnXxdY70kzqfrN4+urXrHCol1y9LuUxfSShM0ZsFkC3DEtFj4zC0wi9I71Cb+8V 0rhVx6iTFCHo/KrDJJm/7twjmN39ZxaXZJFV+ofLEd+7wZijHuVlsKy6597etMor3CkeuwcMdp+1 lm/YAWZqmUY98LKKxKIet59OSDJPXP7L2nBJfwkkt6z4ibWQU1j4OJ1cZE5e/STDOXOR9by9FMh9 kDIAKyG/tGaHsxfrMY5miX8MywPlAgMBAAGjggGHMIIBgzAPBgNVHRMBAf8EBTADAQH/MB0GA1Ud DgQWBBRRAcgiA5nZbiss2II5eNyrGXZEcTALBgNVHQ8EBAMCAYYwEAYJKwYBBAGCNxUBBAMCAQAw GQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU6o073JNr96Z42jmfdFu4WxRj gs0wbgYDVR0fBGcwZTBjoGGgX4YwaHR0cDovL2NybC5jb3JwLnNwcmludC5jb20vUFBLSVdBMDEv UFBLSVdBMDEuY3JshitodHRwOi8vY3JsLnNwcmludC5jb20vUFBLSVdBMDEvUFBLSVdBMDEuY3Js MIGFBggrBgEFBQcBAQR5MHcwPAYIKwYBBQUHMAKGMGh0dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDA3BggrBgEFBQcwAoYraHR0cDovL2NybC5zcHJpbnQuY29t L1BQS0lXQTAxL1BQS0lXQTAxLmNydDANBgkqhkiG9w0BAQUFAAOCAgEAPnhPbwWBkx8lJuBkvFQZ +ndd5xT2WonpdzuqC1B7br4auN7RzovHVmC40RUrZfxf0mkNX9awG4naZaVjQzoMG0ijE8YEz/+X JxOadLsXiatSjljJWSuRp4w6cc9yH2Vc3wkCjSYYhawD6kBVV/j10CWLJVfQ5gLw2OXa/k8jSxoZ 7eyPinEM4bkJOJTNkwPW99MiKwua/qFWeoshPy0w1KlT6mgEQM65mZfIwZ16/AiWcAg1QKgr6YYY kzFu1M7cNEUhhohonAm/XPpsadSBIHKiQrW2rgWW56d5iDoUtoYXPaRZ7b/LaxqtuDrChaCYtYHA iD8LwynwNqNG1L541S/nfAoyQcSmYgx2mo2b23ZsYI6LIEDeAOFtlLOZN/cUeSYACO60y75j1aj1 j9mbfSTA9VfOyayfgVOadeNHdse6zM8pRQ4AJt1yC7mNPkmkON9k+16IqOMXgwa+M4derUwRy+tt QUOZe7iMtI7dgf8hsFteMSrXKkjNth0x2mEdGU8777WRCd4hFEKkGkJ2xTYGXDf8S6tmZM+OQ+Xt gBvxZWMnehlUiycJtDdNazacLowHaRND8C7L6zcFlyeAkCOHoYxcUK7hm5FMfYrr2KZDFcakrjIy AxYyTa/LlKv+spIBjxA+QOKJUYfrM8b+csCvy8vGhihP1EaxSv2J0xEwggarMIIFk6ADAgECAgo8 FVeJAAAAAZIPMA0GCSqGSIb3DQEBBQUAMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkwHhcNMDgwNTAxMTczNzE0WhcNMTEwNTAx MTczNzE0WjCBzzETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDES MBAGCgmSJomT8ixkARkWAmFkMRUwEwYDVQQLEwxEb21haW4gVXNlcnMxEDAOBgNVBAsTB01hbmFn ZWQxGzAZBgNVBAsTElN0YW5kYXJkLVRlY2huaWNhbDEbMBkGA1UEAxMSV2VzbGV5IEUgR2Vvcmdl IElWMSkwJwYJKoZIhvcNAQkBFhpXZXNsZXkuRS5HZW9yZ2VAc3ByaW50LmNvbTCBnzANBgkqhkiG 9w0BAQEFAAOBjQAwgYkCgYEArxfUh9TugEcsXY4OefFQTrGuaTRenLcZg0KCxZlTY7P9wMRCYd8p GJljwH1x4qn0Ejjyz+uX5UL8Biia13BSWRgiq7QYLKTZNKwEpBbeOf9lK/LrPsbFOgat/Zh/lPmx YzxeikU42X3KhyVSCmWdQhmWRu5kfUzsejaGWH9AyuUCAwEAAaOCA2EwggNdMAsGA1UdDwQEAwIF oDA2BgkqhkiG9w0BCQ8EKTAnMA0GCCqGSIb3DQMCAgE4MA0GCCqGSIb3DQMEAgE4MAcGBSsOAwIH MB0GA1UdDgQWBBTFSbrzJuajBSX9B63Y9r2TlgbU5DA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiBkugshNficv2LB4Xs/liCno8icYbjvkqEsfZAAgFkAgECMB8GA1UdIwQYMBaAFAGPJVAshjSb wX6QH9mINbU/rwuJMIIBXgYDVR0fBIIBVTCCAVEwggFNoIIBSaCCAUWGgeNsZGFwOi8vL0NOPVNw cmludCUyME5leHRlbCUyMEVudGVycHJpc2UlMjBJc3N1aW5nJTIwMSUyMEF1dGhvcml0eSxDTj1Q UEtJV0MwMSxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz1hZCxEQz1zcHJpbnQsREM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlv bkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludIYraHR0cDovL2NybC5z cHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNybIYwaHR0cDovL2NybC5jb3JwLnNwcmludC5j b20vUFBLSVdDMDEvUFBLSVdDMDEuY3JsMIGFBggrBgEFBQcBAQR5MHcwNwYIKwYBBQUHMAKGK2h0 dHA6Ly9jcmwuc3ByaW50LmNvbS9QUEtJV0MwMS9QUEtJV0MwMS5jcnQwPAYIKwYBBQUHMAKGMGh0 dHA6Ly9jcmwuY29ycC5zcHJpbnQuY29tL1BQS0lXQzAxL1BQS0lXQzAxLmNydDApBgNVHSUEIjAg BggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcKAwQwNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMEwGA1UdEQRFMEOgJQYKKwYBBAGCNxQCA6AX DBV3ZWcwMjIxQGFkLnNwcmludC5jb22BGldlc2xleS5FLkdlb3JnZUBzcHJpbnQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBYdUj2FTmOVS0X2fF+OYWXu9QoS6JWB8exD8kBPWVh28UilosoFwpVs2Ux K+V9NE1SC4QXDfwcjyMMV6WfXfy1foT6YAOcLt1z91ALCbTPlr1mazbAnOL6AzoTnq5V+TjvJvdN IYROS6PJC/YU5+w/NannnhC1zNFOtmxZZcrz50uRU8Q4mgITpxcnJXKUtKNaFTEhhtnP+hMVXYW0 eUyG7xjDTCyqsO5jcyI0IKJkNW1NXaKjHfmlAAiL5HVNl7cYL5uce6orHQQPMTSGRmTKCNjx7Yaz EHAorZUGmCTuihdhPDq+tOhGrIDE4XuiDxj+OVU6JXM5nsiKTjU968o4MYIDLTCCAykCAQEwgYYw eDETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBnNwcmludDESMBAGCgmSJomT 8ixkARkWAmFkMTUwMwYDVQQDEyxTcHJpbnQgTmV4dGVsIEVudGVycHJpc2UgSXNzdWluZyAxIEF1 dGhvcml0eQIKPBVXiQAAAAGSDzAJBgUrDgMCGgUAoIIB/DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMTAxMjAxODEzMzZaMCMGCSqGSIb3DQEJBDEWBBQ4JuIhyFjx Wz/S5FFMj2/yu2hwXjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG 9w0CBTCBlwYJKwYBBAGCNxAEMYGJMIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZzcHJpbnQxEjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRl bCBFbnRlcnByaXNlIElzc3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wgZkGCyqGSIb3DQEJ EAILMYGJoIGGMHgxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZzcHJpbnQx EjAQBgoJkiaJk/IsZAEZFgJhZDE1MDMGA1UEAxMsU3ByaW50IE5leHRlbCBFbnRlcnByaXNlIElz c3VpbmcgMSBBdXRob3JpdHkCCjwVV4kAAAABkg8wDQYJKoZIhvcNAQEBBQAEgYCZRP3ZMRVKoCvD YpqxK3R1x//95WFdQuRmZbPik5pR8OhIE8OMqpRlYLAI6UDKZ3mvFzcEzuQRXc9J8d0lpHipdD8X 9KXbbkM11CjrXpuizQcIlv3Q95JbQFGhLls+uRfN0WBM7UBqIJZgStDkZyKBk7Ux5xtXdIf8+LGP fAs5HwAAAAAAAA== ------=_NextPart_000_0084_01CBB8A3.D890A810-- From Internet-Drafts@ietf.org Thu Jan 20 13:45:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534D13A6831; Thu, 20 Jan 2011 13:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 dfGo4yJrBXZk; Thu, 20 Jan 2011 13:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D88B3A6832; Thu, 20 Jan 2011 13:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110120214501.23630.24038.idtracker@localhost> Date: Thu, 20 Jan 2011 13:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-03.txt Pages : 7 Date : 2011-01-20 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20133808.I-D@ietf.org> --NextPart-- From kotikalapudi.sriram@nist.gov Thu Jan 20 20:00:26 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585133A6895 for ; Thu, 20 Jan 2011 20:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cM7PkDlJ+LhV for ; Thu, 20 Jan 2011 20:00:25 -0800 (PST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by core3.amsl.com (Postfix) with ESMTP id 6A9B73A6890 for ; Thu, 20 Jan 2011 20:00:25 -0800 (PST) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id p0L433Gc009883; Thu, 20 Jan 2011 23:03:03 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 20 Jan 2011 23:02:57 -0500 From: "Sriram, Kotikalapudi" To: Pradosh Mohapatra Date: Thu, 20 Jan 2011 23:02:52 -0500 Thread-Topic: [sidr] I-D ACTION:draft-ietf-sidr-origin-validation-signaling-00.txt Thread-Index: AQHLuRsW+Sg/AkRokEyCQnM4EfxZiQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: kotikalapudi.sriram@nist.gov Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-origin-validation-signaling-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 04:00:26 -0000 I have a coupe of questions. Question 1: It seems this draft proposes Changes to the BGP Decision Process (Section 3). It is not clear that the decision process behavior described in this ID can be implemented by manipulation of the existing policy knobs. What is described seems to be an addition to the decision process, not just policy tricks. I am wondering if that is acceptable? Question 2: The I-D is proposing to explicitly work with "validation state" 0 (valid), 1 (not found), and 2 (invalid) in the BGP Decision Process. One thing I am not clear about the proposal is how can this proposed order of actions work? a. Validation step: "When comparing a pair of routes for a BGP destination, the route with the lowest "validation state" value is preferred." b. "the validation step MUST be performed prior to any of the steps defined in the decision process of [RFC4271]." As I see, at first the decision process has to select from available paths the candidates for best path (including policy considerations, etc.); it then makes an ordered list of the candidates; then it can apply the rule of "the lowest "validation state" value is preferred." Seems to me that it is not possible the other way round that the I-D seems to require (MUST)? Sriram From pmohapat@cisco.com Sun Jan 23 11:02:47 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505893A6932 for ; Sun, 23 Jan 2011 11:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ok5xs0FTnH0g for ; Sun, 23 Jan 2011 11:02:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 61CB23A6930 for ; Sun, 23 Jan 2011 11:02:46 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF8LPE2rR7Ht/2dsb2JhbACkaHOhf5ochVAEhHCGMA Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 23 Jan 2011 19:05:26 +0000 Received: from sjc-vpn5-324.cisco.com (sjc-vpn5-324.cisco.com [10.21.89.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0NJ5Qsn021670; Sun, 23 Jan 2011 19:05:26 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Pradosh Mohapatra In-Reply-To: Date: Sun, 23 Jan 2011 11:05:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1081) Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D ACTION:draft-ietf-sidr-origin-validation-signaling-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jan 2011 19:02:47 -0000 Hi Sriram, > Question 1: >=20 > It seems this draft proposes Changes to the BGP Decision Process = (Section 3). > It is not clear that the decision process behavior described in this = ID can be implemented=20 > by manipulation of the existing policy knobs. =20 > What is described seems to be an addition to the decision process, not = just policy tricks. > I am wondering if that is acceptable? The decision process changes in the draft are to define an automatic way = of preferring=20 valid routes for folks that do not want to do manual policy tricks. As = we have discussed=20 previously, the steps in origin validation are as follows: 1. Check against the origin AS database, 2. Mark the routes as one of {valid, not found, invalid} 3. [Policy tricks to match on the marking and change attributes] 4. [decision process change to automatically prefer valid > not found > = invalid] The last two steps are optional - they can both be executed or one of = them or none ;-) > Question 2: >=20 > The I-D is proposing to explicitly work with > "validation state" 0 (valid), 1 (not found), and 2 (invalid) > in the BGP Decision Process. >=20 > One thing I am not clear about the proposal is how can this proposed > order of actions work? > a. Validation step: "When comparing a pair of routes for a BGP = destination, the route > with the lowest "validation state" value is preferred." >=20 > b. "the validation step MUST > be performed prior to any of the steps defined in the decision > process of [RFC4271]." >=20 > As I see, at first the decision process has to select from available = paths > the candidates for best path (including policy considerations, etc.); > it then makes an ordered list of the candidates; then it can apply the = rule of > "the lowest "validation state" value is preferred." >=20 > Seems to me that it is not possible the other way round that the I-D = seems to require (MUST)? What (b) really says is that the validation state of a pair of routes = should be compared before the LOCAL_PREF comparison step (that comes first in the decision = process followed by AS_PATH length followed by origin etc.) - Pradosh= From kent@bbn.com Thu Jan 27 09:13:45 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D567A28C154 for ; Thu, 27 Jan 2011 09:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, 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 pt2tk-QhUxOa for ; Thu, 27 Jan 2011 09:13:45 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 0AB5128C13C for ; Thu, 27 Jan 2011 09:13:45 -0800 (PST) Received: from [192.1.255.194] (port=49199) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PiVSi-0003oV-OR; Thu, 27 Jan 2011 12:16:48 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 27 Jan 2011 12:16:46 -0500 To: sidr@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 17:13:46 -0000 Folks, I have posted an individual submission ( draft-kent-bgpsec-threats-00.txt) as a first cut at a threat model for BGP path secruity, based on use of the RPKI that this WG has developed, and based on the use of digital signatures applied to AS path info in BGP update messages. Since path secruity is the next topic that the WG is poised to address (as we complete work on the RPKI document set) it seemed like an appropriate time to submit a threat model of this sort. I'd like SIDR to consider adopting a threat model for BGP path secruity as a WG item, and offer this as a starting point for the discussion (if the WG agrees to pursue this topic). Steve From randy@psg.com Thu Jan 27 13:32:58 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E9428C184 for ; Thu, 27 Jan 2011 13:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 naRk9gGlFa0j for ; Thu, 27 Jan 2011 13:32:57 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id ADC073A6895 for ; Thu, 27 Jan 2011 13:32:57 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PiZVX-000Pn4-N0; Thu, 27 Jan 2011 21:36:00 +0000 Date: Fri, 28 Jan 2011 06:36:09 +0900 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: 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 Cc: sidr@ietf.org Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jan 2011 21:32:58 -0000 > I'd like SIDR to consider adopting a threat model for BGP path > secruity as a WG item, and offer this as a starting point for the > discussion (if the WG agrees to pursue this topic). support randy From maureen.stillman@gmail.com Fri Jan 28 11:07:53 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547923A694F for ; Fri, 28 Jan 2011 11:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 H9jqzomzaZxR for ; Fri, 28 Jan 2011 11:07:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6EC223A6946 for ; Fri, 28 Jan 2011 11:07:52 -0800 (PST) Received: by iwn40 with SMTP id 40so3701916iwn.31 for ; Fri, 28 Jan 2011 11:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5bJFolXdaWaaegHsyuXU7k0vKKo963Af7lSQJYEDOFQ=; b=P7N7Ip6qB5uWILGlU9ySqr1o6XohJD6OALAWQr22Mw2eFwUg3VMiXaXFSob5GqnOu0 DBvgGa4p6Dk+ay4hrd1qbkBjzHyXP6piDsrA8q1mmoHomnQSvyR9RDXaxrbr0SEJP1QO qDhfdS1FA7x5DhJnpz7tZwht8Xfd9MBZQAGpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mGlOKO7HVQZBcGdYSGaeTWc7Z0pGpgpdZg9BnwvvFIgsQGbHE6CrYSmIC8WBYb0vFy H5TcdF3IcerMbKn5Ty8K4bPwYOFEi5Y9NB/TDVHSQ4Y946/d4TClUw8vHkceb+T6Fg2x wqKLUaPaAigM8O0Fs1OKPRdfcQgrKTqeFF/jk= MIME-Version: 1.0 Received: by 10.231.206.206 with SMTP id fv14mr3123202ibb.75.1296241857341; Fri, 28 Jan 2011 11:10:57 -0800 (PST) Received: by 10.231.167.193 with HTTP; Fri, 28 Jan 2011 11:10:57 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Jan 2011 13:10:57 -0600 Message-ID: From: Maureen Stillman To: Stephen Kent , sidr@ietf.org Content-Type: multipart/alternative; boundary=90e6ba4fc232732987049aecd30c Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2011 19:07:53 -0000 --90e6ba4fc232732987049aecd30c Content-Type: text/plain; charset=ISO-8859-1 I support pursuit of the topic. I am in the process of reading the internet draft and will have comments later. Maureen On Thu, Jan 27, 2011 at 3:36 PM, Randy Bush wrote: > > I'd like SIDR to consider adopting a threat model for BGP path > > secruity as a WG item, and offer this as a starting point for the > > discussion (if the WG agrees to pursue this topic). > > support > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --90e6ba4fc232732987049aecd30c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support pursuit of the topic.=A0 I am in the process of reading the inter= net draft and will have comments later.

Maureen

On Thu, Jan 27, 2011 at 3:36 PM, Randy Bush <randy@psg.com> wrote:
> I'd like SIDR to consider adopting a threat model for BGP path > secruity as a WG item, and offer this as a starting point for the
> discussion (if the WG agrees to pursue this topic).

support

randy
__________________________________= _____________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--90e6ba4fc232732987049aecd30c-- From Internet-Drafts@ietf.org Sat Jan 29 02:45:02 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C401E3A695F; Sat, 29 Jan 2011 02:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, 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 MaxKnsonBOiw; Sat, 29 Jan 2011 02:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94953A6950; Sat, 29 Jan 2011 02:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110129104501.26061.78158.idtracker@localhost> Date: Sat, 29 Jan 2011 02:45:01 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 10:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-04.txt Pages : 8 Date : 2011-01-29 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-29023929.I-D@ietf.org> --NextPart-- From russ@cisco.com Sat Jan 29 09:52:48 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0433A6839 for ; Sat, 29 Jan 2011 09:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.429 X-Spam-Level: X-Spam-Status: No, score=-10.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] 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 eZbMpkqShzIP for ; Sat, 29 Jan 2011 09:52:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9195E3A6838 for ; Sat, 29 Jan 2011 09:52:47 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: signature.asc : 259 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH/jQ01AZnwM/2dsb2JhbACkd3OgKppuhU4EhROHDoNF Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Jan 2011 17:55:56 +0000 Received: from [10.116.137.181] (rtp-russwh-8714.cisco.com [10.116.137.181]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0THtuZA000899 for ; Sat, 29 Jan 2011 17:55:56 GMT Message-ID: <4D4454AE.6070304@cisco.com> Date: Sat, 29 Jan 2011 12:55:58 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sidr@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4D1C688B7B53C5ACB31F44C3" Subject: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2011 17:52:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4D1C688B7B53C5ACB31F44C3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable First, I will state for the record that I do _not_ think the SIDR working group should take this as a "baseline" draft for BGP AS Path validation without serious rework. Specific points: =3D=3D 3.3 As cryptographic payloads and loading on routers are likely to seriously increase, a BGPsec design may require use of new hardware. It must be possible to build routers that do BGPsec with within acceptable (to operators) bounds of cost and performance. This should be left out of any requirements document, and various proposed system compared based on their costs and deployment difficulty. =3D=3D 3.7 If message signing increases message size, the 4096 byte limit on BGP PDU size MAY be removed. Has anyone done any analysis of the impact of increasing the MTU size on all BGP speakers on the Internet at large? Before making such a blanket statement, I would like to hear from vendors and operators about the impact of such a change. =3D=3D 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple NLRIs in a single UPDATE, given the impossibility of splitting a signed message while preserving the signature. I'm not certain why this would be in a requirements document. Can anyone explain how this directly relates to the security of BGP? IE, what is the direct relationship between stating that packing is no longer needed in BGP, and improving the security of BGP itself? This should be completely removed from the requirements list, and left open as one point of consideration between competing proposed systems. =3D=3D 3.14 A BGPsec design MUST NOT require operators to reveal proprietary data. This includes peering, customer, and provider relationships, an ISP's internal infrastructure, etc. Though it is understood that some data are revealed to the savvy seeker by BGP, traceroute, etc. today. What sense does it make to say the only system which may be deployed is one that protects information already publicly available? This is a non-requirement, and must not be included in the requirements list. =3D=3D 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally determine that the UPDATE has traversed the AS path indicated in the UPADTE. Note that this is more stringent than showing that the path is merely not impossible. I've always thought requirements documents proposed a set of requirements, rather than a set of end goals. This entire "bullet" needs to be replaced with a realistic set of requirements concerning what can, and cannot, be proven about an AS Path in BGP, and then what we can actually require. What does "proving the AS Path the update has traversed," prove, precisely? Does receiving an update through a specific path prove traffic sent to that destination will traverse the path listed? Does receiving an update prove that all destinations listed are reachable along the path listed? Does receiving an update prove that every AS along that path has agreed to forward traffic transmitted to the destination indicated? It proves none of the above. The document needs justification, not assertions. =3D=3D 4.3 Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design MUST provide a mechanism to control the window of exposure to replay attacks. Again, this is an assumption which I completely and totally disagree with. What is the window size allowed in terms of time? Is it minutes, hours, days, weeks, months, or years? =3D=3D In short, this document does NOT accurately reflect the needs or requirements of BGP security, and should NOT be adopted as a WG document.= Russ --------------enig4D1C688B7B53C5ACB31F44C3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1EVLEACgkQER27sUhU9OSe5gCgz68Wki8Gd13smnhkSq5Zy79W 8dUAoNQednJcUga5rdl3NLzxKSY9aTEe =WMZV -----END PGP SIGNATURE----- --------------enig4D1C688B7B53C5ACB31F44C3-- From danny@tcb.net Sat Jan 29 20:54:07 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54BB3A6B09 for ; Sat, 29 Jan 2011 20:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.491 X-Spam-Level: X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VBeS1qt95Ten for ; Sat, 29 Jan 2011 20:54:06 -0800 (PST) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 9F5EC3A6B02 for ; Sat, 29 Jan 2011 20:54:06 -0800 (PST) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id p0U4rIBc012847 for ; Sat, 29 Jan 2011 23:53:18 -0500 Received: from DUL1WNEXMB06.vcorp.ad.vrsn.com ([10.170.12.250]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jan 2011 23:57:16 -0500 Received: from dul1dmchper-m1.vcorp.ad.vrsn.com ([10.100.0.9]) by DUL1WNEXMB06.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 29 Jan 2011 23:57:16 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Danny McPherson In-Reply-To: Date: Sat, 29 Jan 2011 23:57:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <99CD268F-9EFC-4D9A-862D-FF768271A311@tcb.net> References: To: sidr@ietf.org X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 30 Jan 2011 04:57:16.0799 (UTC) FILETIME=[2ABF08F0:01CBC03A] Subject: Re: [sidr] new draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 04:54:07 -0000 On Jan 27, 2011, at 12:16 PM, Stephen Kent wrote: >=20 > I'd like SIDR to consider adopting a threat model for BGP path = secruity > as a WG item, and offer this as a starting point for the discussion = (if > the WG agrees to pursue this topic). Thanks Steve for posting this, as many have noted path security=20 is necessary and very important to secure inter-domain routing. For the chairs,=20 As a point of order, are we agreeing now that the WG is going to address=20= path security? In resource certification repositories? or routing = protocols=20 themselves? Given that my _comments previously were constrained by=20 this, I do hope we agree addressing path security will now be in charter = and within scope of the WG - or perhaps we create a new WG that works on = items beyond resource certification and RPKI and focuses on routing protocols=20= - or if they're attempting to adapt current protocols (e.g., BGP) then = the=20 extensions be performed in those respective working groups (e.g., IDR)? That said, I do hope we don't assume that discussions of path security = in a=20 routing protocol should be constrained by the RPKI architecture itself. -danny From randy@psg.com Sun Jan 30 19:37:19 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1156E3A6B6C for ; Sun, 30 Jan 2011 19:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] 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 tZDJ7EwkgP+P for ; Sun, 30 Jan 2011 19:37:18 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 8A2E73A6B62 for ; Sun, 30 Jan 2011 19:37:17 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Pjkcu-000DpR-O3; Mon, 31 Jan 2011 03:40:29 +0000 Date: Mon, 31 Jan 2011 12:40:27 +0900 Message-ID: From: Randy Bush To: Russ White In-Reply-To: <4D4454AE.6070304@cisco.com> References: <4D4454AE.6070304@cisco.com> 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 Cc: sidr@ietf.org Subject: Re: [sidr] bgpsec-reqs-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jan 2011 03:37:19 -0000 hi russ, > 3.3 As cryptographic payloads and loading on routers are likely to > seriously increase, a BGPsec design may require use of new hardware. > It must be possible to build routers that do BGPsec with within > acceptable (to operators) bounds of cost and performance. > > This should be left out of any requirements document, and various > proposed system compared based on their costs and deployment > difficulty. i take your point. the intent was that compatibility with current hardware abilities is not a requirement that this document imposes on a solution. it is quite likely that provider routers will need crypto assist and more ram. though one hope that the stub customer edge will not. and the operators with whom we discussed (note that i am an operator, not a vendor with a bad habit of speaking for operators) this thought that this needed to be said from both ends of the scale. we did not want the future security constrained by a 7200, nor did we want an explosion in costs. as dollars are the bottom line in our capitalist culture, constraining them seems quite reasonable. and we will try to phrase better in the next version, we promise :) > 3.7 If message signing increases message size, the 4096 byte limit on > BGP PDU size MAY be removed. > > Has anyone done any analysis of the impact of increasing the MTU size > on all BGP speakers on the Internet at large? Before making such a > blanket statement, I would like to hear from vendors and operators > about the impact of such a change. i am trying really hard to sort out what you are trying to say and have failed. bgp is not carried over udp, but rather tcp. this is not a change in the mtu, it is a change in the bgp pdu carried over tcp. as bgp is next hop only, no transitive change in mtu would be needed anyway. > 3.9 If a BGPsec design uses signed NLRIs, it need NOT handle multiple > NLRIs in a single UPDATE, given the impossibility of splitting a > signed message while preserving the signature. > > I'm not certain why this would be in a requirements document. Can > anyone explain how this directly relates to the security of BGP? IE, > what is the direct relationship between stating that packing is no > longer needed in BGP, and improving the security of BGP itself? note the 'need not.' it does not say 'must not'. the point is that, if there is a signature over the bundled nlri, that signature can not survive the next bgp peer, who will unpack the nlris due to their routing policy not sending the whole bundle to their next peer. i.e. imagine R0 sends a bundle to its customer R1, and R1 selects some, but not all, routes from R0 and others from elsewhere to send to its customer, R2. and, btw, actual experimantal measurement has shown that unpacking nlri does not increase things unacceptably, even on small routers. > 3.14 A BGPsec design MUST NOT require operators to reveal proprietary > data. This includes peering, customer, and provider relationships, an > ISP's internal infrastructure, etc. Though it is understood that some > data are revealed to the savvy seeker by BGP, traceroute, etc. today. > > What sense does it make to say the only system which may be deployed > is one that protects information already publicly available? This is a > non-requirement, and must not be included in the requirements list. this is an absolute from many operators. there is information and there is information. basic security info hiding theory says that you can not absolutely protect anything, you can just raise the cost of getting it. this is one of the reasons for the failure of the IRR, many operators, especially some of the largest, just don't want to publish their customer lists because of sales poaching. it is not theory, but has happened. i have had the sales department come to me and ask me to do the bgp and traceroute research to tell them customer lists of competitors because the ones they were after were not in the IRR (uu, sprint, ...). i told them to foad, and the ceo backed me. [ and note that backup paths are not very visible in bgp or traceroute ] > 4.2 A BGPsec design MUST enable the recipient of an UPDATE to formally > determine that the UPDATE has traversed the AS path indicated in the > UPADTE. Note that this is more stringent than showing that the path > is merely not impossible. > > I've always thought requirements documents proposed a set of > requirements, rather than a set of end goals. This entire "bullet" > needs to be replaced with a realistic set of requirements concerning > what can, and cannot, be proven about an AS Path in BGP, and then what > we can actually require. the difference between requirements and goals is sufficiently subtle that you will have to write it up formally to get through to at least me. bottom line: when i recieve an update for prefix P with path D C B A, i want firm assurance that A passed P to B, B to C, C to D, and D to me. firm, verifiable, assurance. that some database says that *some* prefixes are allowed from A to B to C to D to me does not mean *all* are. there are vast differences in how different prefixes are handled by each hop on the route. think peer, provider, customer relationships. > What does "proving the AS Path the update has traversed," prove, > precisely? Does receiving an update through a specific path prove > traffic sent to that destination will traverse the path listed? no, see security section. locking down the data plane is the next high mountain. one at a time. of course if you have a solution which locks down both the control plane and the data plane, i *extremely eagerly* await your i-d. > Does receiving an update prove that all destinations listed are > reachable along the path listed? Does receiving an update prove that > every AS along that path has agreed to forward traffic transmitted to > the destination indicated? yes, agreed to. of course, we can not yet guarantee that they do not have an accidental packet-based acl en route, see security section on data plane vs control plane. [ i had this bug this last week, a packet acl in path. nasty. eagerly seeking prevention. send i-d. ] > 4.3 Replay of BGP UPDATE messages need not be completely prevented, > but a BGPsec design MUST provide a mechanism to control the window of > exposure to replay attacks. > > Again, this is an assumption which I completely and totally disagree > with. What is the window size allowed in terms of time? Is it minutes, > hours, days, weeks, months, or years? tunable, i hope. i am not much worried about my research prefixes being replayed. root name servers may be. > In short, this document does NOT accurately reflect the needs or > requirements of BGP security, and should NOT be adopted as a WG > document. opinions may differ. you and steve kent had your time in a wg which went nowhere for years. let's try not to repeat old arguments and let's move forward. thanks. i will be in your area 8-12 feb. glad to chat face to face. randy From Internet-Drafts@ietf.org Mon Jan 31 23:45:05 2011 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944C33A6ABD; Mon, 31 Jan 2011 23:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 jbr4SnMSaV1f; Mon, 31 Jan 2011 23:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C673A68BD; Mon, 31 Jan 2011 23:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201074502.15592.51882.idtracker@localhost> Date: Mon, 31 Jan 2011 23:45:02 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-origin-ops-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 07:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : R. Bush Filename : draft-ietf-sidr-origin-ops-05.txt Pages : 8 Date : 2011-01-31 Deployment of the RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-origin-ops-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-31233427.I-D@ietf.org> --NextPart--