From eosterweil@verisign.com  Sun Apr  1 12:27:07 2012
Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1F321F88CD for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:27:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9vg2A4TyIJw for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:27:07 -0700 (PDT)
Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id B831D21F88D5 for <sidr@ietf.org>; Sun,  1 Apr 2012 12:27:05 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKT3isBVL7llFytS/oOFjotunrGZeAyQw/@postini.com; Sun, 01 Apr 2012 12:27:06 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q31JQvV8000499; Sun, 1 Apr 2012 15:26:57 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.142]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 15:26:56 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net>
Date: Sun, 1 Apr 2012 12:26:54 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0738056F-6524-4EE7-8A72-59DC5B960604@verisign.com>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <A76204B3-5EF3-4212-9136-B8E3266C7D17@tcb.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:26:56.0547 (UTC) FILETIME=[66AFF730:01CD103D]
Cc: sidr@ietf.org
Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 19:27:07 -0000

On Mar 29, 2012, at 12:04 PM, Rob Austein wrote:

> At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote:
>>=20
>> i don't think the rsync scale issues surprise anyone that was paying
>> attention.  If we're already considering new architectures,
>> substrates, et al., here perhaps we shouldn't be so quick on the
>> trigger for Standards Track work and move this and related
>> "investigation" to the IRTF, or at least ensure they're only
>> Experimental until broader experience is gained.
>=20

<snip>

>=20
> For the record, this presentation was originally targeted at the IEPG,
> as a direct follow-up to multiple suggestions received at a previous
> IEPG meeting that it might be interesting to see how BitTorrent works
> in this environment.  I presented this at the SIDR WG meeting because
> the chairs thought it might be of interest to the WG.
>=20


So, I just want to wade in here very quickly: in the sidr wg we are =
constantly facing packed agendas, multiple sessions, and now interim =
meeting extravaganzas... I feel like there is no shortage of feedback =
that people try to give to many of the drafts (during sessions and =
obviously on the list), but the session agendas often seem to require =
the chairs to cut the mic lines (imho) way too early.  This has made =
feedback harder to give.  I (for one) was a little surprised to see the =
bittorrent work presented at both the iepg and again during the wg =
considering the amount of feedback that often comes from pretty much =
_any_ given draft on the agenda.  I am not claiming it is bad work, =
inappropriate, or anything like that.  Simply, an interesting scheduling =
choice...

With all due respect (honestly, I know this can't be easy), I really =
feel this is symptomatic of a disconnect between the session agendas and =
the level of comfort that the overall wg members have with some of the =
drafts.  I really think fewer/more focused sets of presentations are =
critical to moving forward and I think I've heard _several_ people on =
the list push very hard for us to return our focus to solid requirements =
analysis (which I think very much should include drafts like the req's =
draft, Steve's threats draft, etc) so that we can evaluate the nature of =
the work we are all trying to do separately from how implementations and =
designs are being fleshed out.  Getting the wg members on the same page =
wrt what we are trying to do would likely make a number of points of =
friction smoother.  I really think this does _not_ necessarily =
invalidate work that has already been done (though we may still need to =
examine some of it carefully).  For example, Danny's questions to Rob et =
al about the scaling requirements that the protocol was aimed at is very =
apropos of us proceeding in an orderly fashion towards a feasible =
security system.  Lessons learned from experiments can be used to inform =
evolving requirements.  That is, this isn't necessarily the waterfall =
software lifecycle ( http://en.wikipedia.org/wiki/Waterfall_model ), =
which only goes forward without feedback loops.  Personally, I would =
find it helpful to see less packed, more focused, and a return to reqs =
in future sessions if possible...  And, yes, we should strive for world =
peace too...

Thanks,

Eric


From eosterweil@verisign.com  Sun Apr  1 12:44:36 2012
Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EB121F8A25 for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljpVA2SoXXyQ for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:44:35 -0700 (PDT)
Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id C957421F8A23 for <sidr@ietf.org>; Sun,  1 Apr 2012 12:44:06 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKT3iwBop/Z9PdZVJLjFJCPEmFfy4g7K55@postini.com; Sun, 01 Apr 2012 12:44:07 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q31Ji5Wo000843; Sun, 1 Apr 2012 15:44:05 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.142]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 15:44:03 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <20120330181017.A9BE46EFC01@minas-ithil.hactrn.net>
Date: Sun, 1 Apr 2012 12:44:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <939E1E56-C9EE-4210-81EC-DDE124BAE9E1@verisign.com>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <A76204B3-5EF3-4212-9136-B8E3266C7D17@tcb.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net> <1DC0A868-0B15-448E-93E6-C61CC89AB6A6@lacnic.net> <4F75B916.6000807@gmail.com> <20120330181017.A9BE46EFC01@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:44:04.0825 (UTC) FILETIME=[CB96BC90:01CD103F]
Cc: sidr@ietf.org
Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 19:44:36 -0000

Hey Rob,

One more meta-comment on this thread: we (as designers) should not =
expect to be prescribing exactly how operators will run their systems.  =
Here in the very early stages we are seeing the early adopters deploy in =
ways that make _their_ operations easy.  imho, this is always going to =
be the bottom line/starting point.  If a solution requires a specific =
operational model (when others are technically correct), and the overall =
system scalability can suffer this way, I think we have a fundamental =
problem. =20

More succinctly, operators shouldn't need to know why you want their =
certs in a hierarchy.  Rather, we should recognize that they are telling =
us that flat structures make their lives easier, and we should use that =
to reengineer what _they_ need.

Just my 0.02,

Eric

On Mar 30, 2012, at 11:10 AM, Rob Austein wrote:

> While I will admit to some astonishment that the following explanation
> could possibly be news to long-time participants in this WG (given how
> much time I've spent whining about this issue over the last five years
> or so both in public and in private), let me quote from the slides:
>=20
>    * How efficient [fetching RPKI repositories using rsync] is
>      depends heavily on how the publication repositories are
>      organized.
>=20
>    * In an efficiently organized repository, filesystem hierarchy
>      follows X.509 certificate hierarchy, so that one can pick up
>      significant subtrees with a single rsync connection.
>=20
>    * To date, the RIRs have chosen to deploy flat hierarchies where
>      there is no relationship at all between filesystem hierarchy
>      within the repository and certificate hierarchy.
>=20
> To make that more concrete, here's an example.  Let's assume we have
> the following trivial hierarchy: Bob and Betty are issued by Alice,
> Carol and Carl are issued by Bob, Dave, and Dana are issued by Carol,
> Dara is issued by Carl, and and all of these are hosted in a single
> repository.
>=20
> In an inefficient, "flat" repository, the publication points for
> objects issued by these entities would look something like this:
>=20
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Betty/
>    rsync://example.org/rpki/Bob/
>    rsync://example.org/rpki/Carl/
>    rsync://example.org/rpki/Carol/
>    rsync://example.org/rpki/Dana/
>    rsync://example.org/rpki/Dara/
>    rsync://example.org/rpki/Dave/
>=20
> In a hierarchical repository, the same publication points would look
> more like this:
>=20
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Alice/Betty/
>    rsync://example.org/rpki/Alice/Bob/
>    rsync://example.org/rpki/Alice/Bob/Carl/
>    rsync://example.org/rpki/Alice/Bob/Carl/Dara/
>    rsync://example.org/rpki/Alice/Bob/Carol/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dana/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dave/
>=20
> Assuming top-down tree walk (the normal case), retrieving objects
> issued by this set of entities takes eight rsync connections with the
> flat repository, as opposed to one rsync connection with the
> hierarchical repository.
>=20
> In practice one might want a slightly more complex structure to limit
> the size of individual directories, but it doesn't matter so long as
> the filesystem hierarchy is organized in such a way that picking up
> an issuer's publication point picks up a non-trivial number of its
> subjects' publication points automatically.   It doesn't have to be
> perfect, just has to do enough better than the flat model to amortize
> the cost of setting up and tearing down the rsync connection over a
> significantly larger number of files.
>=20
> This is not about PKI, it's purely an rsync efficiency issue.
>=20
> Presumably there are scaling limitations to the hierarchical approach,
> but anecdotal evidence among the people I've asked ("I tried ... and
> it worked") suggests that, if the underlying networks and filesystems
> are in good shape, a single rsync connection ought to be able to
> handle up to at least 10,000 small files, perhaps a lot more than
> that.  Note that this is just talking about rsync itself: mileage
> might vary significantly if the underlying networks or filesystems are
> seriously broken.  Also note that these anecdotal estimates have not
> been tested in any rigorous fashion as far as I know, so that's
> another entry on my list of things we ought to be measuring.
>=20
> Hope this helps to clarify the change I've been suggesting.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


From eosterweil@verisign.com  Sun Apr  1 12:56:48 2012
Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF4721F8800 for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:56:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.299
X-Spam-Level: 
X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd17YW7QWitp for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 12:56:48 -0700 (PDT)
Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id BD6D921F87BF for <sidr@ietf.org>; Sun,  1 Apr 2012 12:56:45 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT3iy++UKLifJadqu6odkUu8EfuA3+NSi@postini.com; Sun, 01 Apr 2012 12:56:47 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q31Jug8S001092; Sun, 1 Apr 2012 15:56:42 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.142]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 15:56:41 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <20120329081625.GA9609@slice>
Date: Sun, 1 Apr 2012 12:56:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C80C23B3-C6D9-44CA-A020-144890CA0274@verisign.com>
References: <20120328081939.GA19843@slice> <CA796250-4EA9-468D-BB4A-4C1187D2148F@tcb.net> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice>
To: Jeffrey Haas <jhaas@pfrc.org>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 19:56:41.0569 (UTC) FILETIME=[8EA4B510:01CD1041]
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 19:56:48 -0000

On Mar 29, 2012, at 1:16 AM, Jeffrey Haas wrote:

> Jakob,
>=20
> On Thu, Mar 29, 2012 at 03:51:10AM -0400, Jakob Heitz wrote:
>> Could we not put a freshness indication into the BGP update?
>> Then everyone that receives the new update would know to invalidate =
the less fresh paths.
>=20
> Just to be clear, this is not a route freshness mechanism I am
> recommending.  What I am recommending is a signal that a repository =
has
> newer data that may be needed for validation.
>=20
> Given such a mechanism, we may be able to reduce the work upon the
> repository mirroring system (distributed or not) by not having to =
regularly
> poll for new objects frequently unless the repository indicates there =
is new
> data present.


The RPKI and BGP have orthogonal data and distribution models though.  =
The RPKI is disseminating certs and ROAs that reflect the _policy_ of =
resource allocations and holders.  BGP is disseminating reachability and =
routing information.  While the former is being used to semantically =
inform the latter, they do not have a tight coupling.  In fact, the =
loose coupling between them is currently only oneway (cache to router if =
I'm not mistaken).  IIRC, once the RPKI data has been cached, it is an =
unsigned, unverifiable tuple that gets pushed to a router.  How can we =
start from there and get secure information flowing the other way, =
exactly?

The idea of adding freshness to the RPKI does not have anything to do =
with the reachability of BGP[SEC].  I think this is actually hitting on =
a new requirement that needs to be documented: the _resource =
certification system (RPKI)_ must provide a freshness model.  I would =
suggest that this stay as far from BGP as we can get it.  BGP is a great =
soft-state protocol (where some may define ``great'' differently), but I =
don't currently tweet or update my fb status over it.

Eric=

From robert@raszuk.net  Sun Apr  1 13:57:08 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE5C21F89DB for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 13:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0Gy4YkhEXyt for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 13:57:07 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 59F1F21F89DA for <sidr@ietf.org>; Sun,  1 Apr 2012 13:57:07 -0700 (PDT)
Received: (qmail 4144 invoked by uid 399); 1 Apr 2012 20:57:06 -0000
Received: from unknown (HELO ?10.0.1.3?) (pbs:robert@raszuk.net@213.160.13.154) by mail1310.opentransfer.com with ESMTPM; 1 Apr 2012 20:57:06 -0000
X-Originating-IP: 213.160.13.154
Message-ID: <4F78C121.50902@raszuk.net>
Date: Sun, 01 Apr 2012 22:57:05 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Eric Osterweil <eosterweil@verisign.com>
References: <20120328081939.GA19843@slice> <CA796250-4EA9-468D-BB4A-4C1187D2148F@tcb.net> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <C80C23B3-C6D9-44CA-A020-144890CA0274@verisign.com>
In-Reply-To: <C80C23B3-C6D9-44CA-A020-144890CA0274@verisign.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 20:57:08 -0000

Hi Eric,

 > BGP is a great soft-state protocol (where some may define
 > ``great'' differently), but I don't currently tweet or update my fb
 > status over it.

While I agree with 99% of what you said today on the list (especially 
pointing out need for solid requirements to document what sidr is trying 
to achieve) I am not sure why you call BGP soft-state.

For me soft-state protocol is RSVP which requires refresh otherwise 
state invalidates. BGP does not require refresh.

If that would not be enough BGP is soon to become completely "hard 
state" if one would implement 
http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01

Best,
R.


From eosterweil@verisign.com  Sun Apr  1 14:12:55 2012
Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8021F8849 for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 14:12:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.732
X-Spam-Level: 
X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIowp4NFVMTk for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 14:12:54 -0700 (PDT)
Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 3634F21F8848 for <sidr@ietf.org>; Sun,  1 Apr 2012 14:12:53 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT3jE0+z32n+sMKS+FKVoBSLQai2j0Ka5@postini.com; Sun, 01 Apr 2012 14:12:54 PDT
Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q31LCmOt002573;  Sun, 1 Apr 2012 17:12:48 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.142]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 17:12:47 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <4F78C121.50902@raszuk.net>
Date: Sun, 1 Apr 2012 14:12:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D5ABED8-0A30-4839-8C6B-D7E0D638D77E@verisign.com>
References: <20120328081939.GA19843@slice> <CA796250-4EA9-468D-BB4A-4C1187D2148F@tcb.net> <20120329072236.GA7311@slice> <61C7DEFD-B03F-42B2-B0FC-878E84C32629@ericsson.com> <20120329081625.GA9609@slice> <C80C23B3-C6D9-44CA-A020-144890CA0274@verisign.com> <4F78C121.50902@raszuk.net>
To: robert@raszuk.net
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 01 Apr 2012 21:12:48.0540 (UTC) FILETIME=[30C52DC0:01CD104C]
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Injecting idea of "freshness of repository data" into BGP
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 21:12:55 -0000

On Apr 1, 2012, at 1:57 PM, Robert Raszuk wrote:

> Hi Eric,
>=20
> > BGP is a great soft-state protocol (where some may define
> > ``great'' differently), but I don't currently tweet or update my fb
> > status over it.
>=20
> While I agree with 99% of what you said today on the list (especially =
pointing out need for solid requirements to document what sidr is trying =
to achieve)

Great, thanks!  I don't want to lose that high order bit!  But, I don't =
want to ignore ya either.  I'll send an off-list response for the below. =
:)

Eric

> I am not sure why you call BGP soft-state.
>=20
> For me soft-state protocol is RSVP which requires refresh otherwise =
state invalidates. BGP does not require refresh.
>=20
> If that would not be enough BGP is soon to become completely "hard =
state" if one would implement =
http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01
>=20
> Best,
> R.
>=20


From danny@tcb.net  Sun Apr  1 18:22:18 2012
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E9411E80AE for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 18:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.74
X-Spam-Level: 
X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77Pvvjlcc2Hq for <sidr@ietfa.amsl.com>; Sun,  1 Apr 2012 18:22:18 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4953A11E80AD for <sidr@ietf.org>; Sun,  1 Apr 2012 18:22:18 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id E536526806D; Sun,  1 Apr 2012 19:22:17 -0600 (MDT)
Received: from new-host-4.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for sidr@ietf.org; Sun, 01 Apr 2012 19:22:17 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=49864; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1257)
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com>
Date: Sun, 1 Apr 2012 21:22:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <4315F042-CB35-4A42-9571-D1D51F5EEC09@tcb.net>
References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> <D7A0423E5E193F40BE6E94126930C49308E9E3552F@MBCLUSTER.xchange.nist.gov> <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> <D7A0423E5E193F40BE6E94126930C49308EE1E84C3@MBCLUSTER.xchange.nist.gov> <CAL9jLaYRi1Uj1g1OXVt9O10ZCWWtoCm646fyqGsYrJkJG99HxQ@mail.gmail.com> <CAH1iCipDYJpWmMpmvdX+Z4AW7cg0QarJbaAmf1JeEBq0rGHiAw@mail.gmail.com> <CAL9jLaaZ2z+WfXJCgaa2ob71t4Qk_khC12UZrr8XT9OzCEs8FA@mail.gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0391@Hermes.columbia.ads.sparta.com>, <CAH1iCiqk4cgPwQGi4751mZCNes2J4B6z7BeRJ0AD0+An8M_DNg@mail.gmail.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E0625@Hermes.columbia.ads.sparta.com>
To: "sidr@ietf.org list" <sidr@ietf.org>
X-Mailer: Apple Mail (2.1257)
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 01:22:18 -0000

On Mar 31, 2012, at 12:12 AM, Murphy, Sandra wrote:

>=20
> Origin validation is strictly and only judging whether the origin has =
the authority to originate announcements of the prefix.  Origin =
validation does not ensure that the authorized AS is actually making the =
announcement.

Indeed!  It's not actually "validation" at all, it's more "policy =
enforcement".  I.e., is the origin AS in the AS_PATH of the received =
update an origin AS that the resource holder said was "authorized" to =
originate the prefix in question.

I suppose it's really no different than static AS filter lists except =
that rtr-rpki is router-wide and storage is soft-state (akin to ORF, =
though it's in-band per-peer, or flow spec, for that matter) v. =
persistent static configuration most folks employ today for policy.

> It is bgpsec path validation that ensures that the announcement is =
currently and authentically being announced by the AS.  That's the =
"signed injection" you mention.

This reminds me -- we don't have a signing certificate and validation =
certificate router on-boarding protocol defined yet for BGPSEC (I assume =
rtr-rpki is the basis, though it currently does not support this), I =
think we need to begin working that out sooner rather than later as I =
suspect the operational implications are far more complex and they will =
markedly impact RPKI system design as well.

Finally, to R.'s point in a different thread:

"If that would not be enough BGP is soon to become completely "hard =
state" if one would implement =
http://tools.ietf.org/html/draft-uttaro-idr-bgp-persistence-01"

I suspect we're going to end up with =
draft-foo-rtr-rpki--proto-persistence-* at some point as well (or we =
could use BGP itself for on-boarding RPKI data :-)

-danny=

From tim@ripe.net  Mon Apr  2 07:41:37 2012
Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79021F84D1; Mon,  2 Apr 2012 07:41:36 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cscTQwQFmdr; Mon,  2 Apr 2012 07:41:36 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5121F84CF; Mon,  2 Apr 2012 07:41:27 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SEiRf-0003bx-70; Mon, 02 Apr 2012 16:41:24 +0200
Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SEiRf-0007dv-1q; Mon, 02 Apr 2012 16:41:23 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20120329092910.150E66EDFC8@minas-ithil.hactrn.net>
Date: Mon, 2 Apr 2012 16:41:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D1F81DC-1B22-4362-BBBC-A6E2DC80C7C1@ripe.net>
References: <20120312205331.1904.65803.idtracker@ietfa.amsl.com> <CAL9jLaZ9=L0oZjThygnd-2D7naOetcrKPJ45-5ToUNYcRUCkiA@mail.gmail.com> <20120329092910.150E66EDFC8@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071939087299476dd9cbd1ee307fefef1b7a
Cc: sidr@ietf.org, sidr-chairs@ietf.org, Samuel Weiler <weiler@watson.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 14:41:37 -0000

Hi,

On 29 Mar 2012, at 11:29, Rob Austein wrote:

> At Wed, 28 Mar 2012 08:57:19 -0400, Christopher Morrow wrote:
>>=20
>> Draft Author Ship Steerers,
>> This we didn't chat about at the meeting(s), but are there =
outstanding
>> bits/pieces or should this be sent along for WGLC in the near future?
>=20
> Not ready yet.  A few year's experience of using this protocol
> suggests the need for an additional message type, to let the RPKI
> engine monitor what the publication server has on file for it.  We've
> seen a few cases where, for whatever reason (bug, system crash, ...)
> the two can get out of sync, and while it's theoretically possible for
> the RPKI engine to determine what's in the publication repository by
> fetching as if it were a relying party, it'd probably be easier just
> to let the RPKI engine ask the publication server directly.

All this sounds very reasonable.

Furthermore I expect that the current discussion on rpki retrieval can =
have implications for this protocol as well. For example, if it is =
decided that consistent delta sets should be supported (as I argued for =
in another thread), then I think we will need some transaction logic in =
this protocol: BEGIN, publish, publish, withdraw ... COMMIT (i.e. begin =
and commit pdus, or probably better: one big pdu containing all updates, =
instead of sending the publish and withdraw pdus separately).

Tim





From wwwrun@rfc-editor.org  Tue Apr  3 11:26:43 2012
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E3221F8618 for <sidr@ietfa.amsl.com>; Tue,  3 Apr 2012 11:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.187
X-Spam-Level: 
X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaV4cxpiAYZ3 for <sidr@ietfa.amsl.com>; Tue,  3 Apr 2012 11:26:42 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5642221F860B for <sidr@ietf.org>; Tue,  3 Apr 2012 11:26:42 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 92C0072E004; Tue,  3 Apr 2012 11:26:31 -0700 (PDT)
To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, stbryant@cisco.com, adrian@olddog.co.uk, Sandra.Murphy@sparta.com, morrowc@ops-netman.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120403182631.92C0072E004@rfc-editor.org>
Date: Tue,  3 Apr 2012 11:26:31 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, sidr@ietf.org
Subject: [sidr] [Technical Errata Reported] RFC6487 (3174)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 18:26:43 -0000

The following errata report has been submitted for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3174

--------------------------------------
Type: Technical
Reported by: David Mandelberg <dmandelb@bbn.com>

Section: 5

Original Text
-------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed.

Corrected Text
--------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  The Authority Key
   Identifier extension MUST follow the same restrictions as in
   Section 4.8.3 above.  RPs MUST be prepared to process CRLs with
   these extensions.  No other CRL extensions are allowed.

Notes
-----
RFC 6487 doesn't specify any restrictions on the format of the AKI extension in CRLs.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From gih@apnic.net  Tue Apr  3 16:27:34 2012
Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC08321F860E for <sidr@ietfa.amsl.com>; Tue,  3 Apr 2012 16:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.929
X-Spam-Level: 
X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+eXiquAOsn4 for <sidr@ietfa.amsl.com>; Tue,  3 Apr 2012 16:27:34 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 0214B21F85D0 for <sidr@ietf.org>; Tue,  3 Apr 2012 16:27:29 -0700 (PDT)
Received: from [202.158.221.120] (unknown [202.158.221.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A860EB67A2; Wed,  4 Apr 2012 09:27:27 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <20120403182631.92C0072E004@rfc-editor.org>
Date: Wed, 4 Apr 2012 09:27:25 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B52207B-078C-4651-BEB2-3A667934E6B7@apnic.net>
References: <20120403182631.92C0072E004@rfc-editor.org>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.1257)
Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, ggm@apnic.net
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3174)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 23:27:35 -0000

I'm tending to a "reject". Section 4.8.3 does not precisely apply to =
CRLs, so to accept this would then require a further errata notice to =
amend this errata to narrow down the scope of the AIA further.=20

Given that the text already says:  "The algorithm used in CRLs issued =
under this profile is specified in [RFC6485]." then I'm not not what =
futerhe specification is required here.

regards,

    Geoff







On 04/04/2012, at 4:26 AM, RFC Errata System wrote:

>=20
> The following errata report has been submitted for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D3174
>=20
> --------------------------------------
> Type: Technical
> Reported by: David Mandelberg <dmandelb@bbn.com>
>=20
> Section: 5
>=20
> Original Text
> -------------
>   An RPKI CA MUST include the two extensions, Authority Key Identifier
>   and CRL Number, in every CRL that it issues.  RPs MUST be prepared =
to
>   process CRLs with these extensions.  No other CRL extensions are
>   allowed.
>=20
> Corrected Text
> --------------
>   An RPKI CA MUST include the two extensions, Authority Key Identifier
>   and CRL Number, in every CRL that it issues.  The Authority Key
>   Identifier extension MUST follow the same restrictions as in
>   Section 4.8.3 above.  RPs MUST be prepared to process CRLs with
>   these extensions.  No other CRL extensions are allowed.
>=20
> Notes
> -----
> RFC 6487 doesn't specify any restrictions on the format of the AKI =
extension in CRLs.
>=20
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --------------------------------------
> Title               : A Profile for X.509 PKIX Resource Certificates
> Publication Date    : February 2012
> Author(s)           : G. Huston, G. Michaelson, R. Loomans
> Category            : PROPOSED STANDARD
> Source              : Secure Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG





From dmandelb@bbn.com  Wed Apr  4 10:21:19 2012
Return-Path: <dmandelb@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD31011E807F for <sidr@ietfa.amsl.com>; Wed,  4 Apr 2012 10:21:19 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMzEuLRVySMK for <sidr@ietfa.amsl.com>; Wed,  4 Apr 2012 10:21:19 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4DD11E8072 for <sidr@ietf.org>; Wed,  4 Apr 2012 10:21:19 -0700 (PDT)
Received: from mail.bbn.com ([128.33.0.48]:52142) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <dmandelb@bbn.com>) id 1SFTt7-000F9g-8M; Wed, 04 Apr 2012 13:20:53 -0400
Received: from dhcp89-089-068.bbn.com ([128.89.89.68]) by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <dmandelb@bbn.com>) id 1SFTtM-0000d9-Ln; Wed, 04 Apr 2012 13:21:08 -0400
Message-ID: <1333560064.10619.36.camel@titan>
From: David Mandelberg <dmandelb@bbn.com>
To: Geoff Huston <gih@apnic.net>
Date: Wed, 04 Apr 2012 13:21:04 -0400
In-Reply-To: <0B52207B-078C-4651-BEB2-3A667934E6B7@apnic.net>
References: <20120403182631.92C0072E004@rfc-editor.org> <0B52207B-078C-4651-BEB2-3A667934E6B7@apnic.net>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.2.2- 
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
Cc: Sandra.Murphy@sparta.com, morrowc@ops-netman.net, sidr@ietf.org, RFC Errata System <rfc-editor@rfc-editor.org>, ggm@apnic.net
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3174)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2012 17:21:19 -0000

On Wed, 2012-04-04 at 09:27 +1000, Geoff Huston wrote:
> I'm tending to a "reject". Section 4.8.3 does not precisely apply to CRLs, so to accept this would then require a further errata notice to amend this errata to narrow down the scope of the AIA further.

AKI, not AIA. I just meant that the CRL AKI should have the same format
and meaning as in 4.8.3, i.e. it should use the SHA-1 hash of the
issuer's public key with neither authorityCertIssuer nor
authorityCertSerialNumber fields present. Maybe the errata should be
rejected and resubmitted with text copied and edited from 4.8.3, instead
of referencing 4.8.3?


> Given that the text already says:  "The algorithm used in CRLs issued under this profile is specified in [RFC6485]." then I'm not not what futerhe specification is required here.

What part of RFC6485 says anything about CRL AKIs? The closest I can
find is in Section 2:

         NOTE: The exception to the above hashing algorithm is the use
         of SHA-1 [SHS] when Certification Authorities (CAs) generate
         authority and subject key identifiers [RFC6487].

That maybe could be interpreted as saying that CRL AKIs should use
SHA-1, but it doesn't say that authorityCertIssuer and
authorityCertSerialNumber must be absent. It also doesn't explicitly say
what to take the SHA-1 of when generating a CRL AKI.

-- 
David Mandelberg
Wed Apr 4 13:07:37 EDT 2012


From internet-drafts@ietf.org  Fri Apr  6 05:59:09 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2E221F85D1; Fri,  6 Apr 2012 05:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.403
X-Spam-Level: 
X-Spam-Status: No, score=-102.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4icvdEwDxXUw; Fri,  6 Apr 2012 05:59:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A580C21F850F; Fri,  6 Apr 2012 05:59:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120406125908.15904.94824.idtracker@ietfa.amsl.com>
Date: Fri, 06 Apr 2012 05:59:08 -0700
Cc: sidr@ietf.org
Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-04.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 12:59:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Secure Inter-Domain Routing Working G=
roup of the IETF.

	Title           : Securing RPSL Objects with RPKI Signatures
	Author(s)       : Robert Kisteleki
                          Brian Haberman
	Filename        : draft-ietf-sidr-rpsl-sig-04.txt
	Pages           : 13
	Date            : 2012-04-06

   This document describes a method to allow parties to electronically
   sign RPSL-like objects and validate such electronic signatures.  This
   allows relying parties to detect accidental or malicious
   modifications on such objects.  It also allows parties who run
   Internet Routing Registries or similar databases, but do not yet have
   RPSS-like authentication of the maintainers of certain objects, to
   verify that the additions or modifications of such database objects
   are done by the legitimate holder(s) of the Internet resources
   mentioned in those objects.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-04.txt


From achi@bbn.com  Fri Apr  6 07:26:56 2012
Return-Path: <achi@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7EA21F853F for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 07:26:56 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYOs4dOHqfJt for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 07:26:55 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9B3821F853E for <sidr@ietf.org>; Fri,  6 Apr 2012 07:26:55 -0700 (PDT)
Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:64782 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1SGA7V-0006QK-H8; Fri, 06 Apr 2012 10:26:33 -0400
Message-ID: <4F7EFD25.5020709@bbn.com>
Date: Fri, 06 Apr 2012 10:26:45 -0400
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Shane Amante <shane@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net>
In-Reply-To: <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 14:26:56 -0000

On 3/29/2012 9:04 AM, Shane Amante wrote:
>Regardless, I think
> that its best to acknowledge, in this draft, that there is a threat of
> DoS to the availability of the BGP control plane

Maybe I'm missing something.

Intermediate routers or MITM entities can always drop updates.  If 
BGPSEC is enabled, then forging an AS4_PATH or modifying 
BGPSEC_PATH_Signature achieves no more than dropping the update.

Can you give a specific example of DoS that applies only to 
BGPSEC-enabled routers?

-Andrew


From shane@castlepoint.net  Fri Apr  6 08:21:14 2012
Return-Path: <shane@castlepoint.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3195321F85C6 for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 08:21:14 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moxWgjS-ao4J for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 08:21:11 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1B21F857A for <sidr@ietf.org>; Fri,  6 Apr 2012 08:21:07 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 67E25268063; Fri,  6 Apr 2012 09:21:06 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 06 Apr 2012 09:21:06 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=65525; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <4F7EFD25.5020709@bbn.com>
Date: Fri, 6 Apr 2012 09:21:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com>
To: Andrew Chi <achi@bbn.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 15:21:14 -0000

On Apr 6, 2012, at 8:26 AM, Andrew Chi wrote:
> On 3/29/2012 9:04 AM, Shane Amante wrote:
>> Regardless, I think
>> that its best to acknowledge, in this draft, that there is a threat =
of
>> DoS to the availability of the BGP control plane
>=20
> Maybe I'm missing something.
>=20
> Intermediate routers or MITM entities can always drop updates.  If =
BGPSEC is enabled, then forging an AS4_PATH or modifying =
BGPSEC_PATH_Signature achieves no more than dropping the update.
>=20
> Can you give a specific example of DoS that applies only to =
BGPSEC-enabled routers?


RFC 4271, Section 9.1.2, "Phase 2: Route Selection":
---snip---
   If the AS_PATH attribute of a BGP route contains an AS loop, the BGP
   route should be excluded from the Phase 2 decision function.  AS loop
   detection is done by scanning the full AS path (as specified in the
   AS_PATH attribute), and checking that the autonomous system number of
   the local system does not appear in the AS path.  Operations of a BGP
   speaker that is configured to accept routes with its own autonomous
   system number in the AS path are outside the scope of this document.
---snip---

So, what if there's a "bad actor" and he/she forges and AS4_PATH and/or =
BGPSEC_Path_Signature with the intent of making *another* AS, which is =
'playing by the rules of BGP and/or BGPSEC', drop the UPDATE?  As I said =
previously, there's two things to think about here:
a)  BGP performs loop detection on the AS_PATH attribute *before* =
verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, =
thus causing a DoS because you're not propagating what *may* be =
legitimate reachability info further downstream.
b)  BGP performs loop detection on the AS_PATH attribute only /after/ =
verifying the BGPSEC_Path_Signature is valid, in which case there is a =
/potential/ for another type of DoS, because there will always be a =
limited amount of crypto verifications/sec that can be performed.  =
There's also the concern that this will slow down propagation of =
reachability information, because it first needs to be crypto-verified =
before it's used/propagated.  Note, this is unlikely to be a problem =
during "steady-state", but is more likely to appear during some amount =
of churn in BGP due to link and/or router failures, for example.

Note, there is likely no easy answer here, but it would be good for the =
WG to think about the problem and see if it could recommend a "best =
practice" to operators ...

In addition, I believe there is a substantially larger question here for =
the WG: is SIDR planning to, eventually, change RFC4271 so that AS loop =
detection is no longer performed on the AS_PATH attribute and, instead, =
is going to be performed only on the BGPSEC_Path_Signature attribute?  =
If so, is SIDR "allowed" to make that change or will this change be made =
within the IDR WG?

-shane


From achi@bbn.com  Fri Apr  6 09:20:44 2012
Return-Path: <achi@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B378E21F853E for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 09:20:44 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu+eM0e3O6eu for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 09:20:44 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D5B6E21F851E for <sidr@ietf.org>; Fri,  6 Apr 2012 09:20:43 -0700 (PDT)
Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:64899 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1SGBtd-0009lY-6h; Fri, 06 Apr 2012 12:20:21 -0400
Message-ID: <4F7F17D0.7020901@bbn.com>
Date: Fri, 06 Apr 2012 12:20:32 -0400
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Shane Amante <shane@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com> <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net>
In-Reply-To: <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 16:20:44 -0000

On 4/6/2012 11:21 AM, Shane Amante wrote:
> a)  BGP performs loop detection on the AS_PATH attribute *before* verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus causing a DoS because you're not propagating what *may* be legitimate reachability info further downstream.

Right, I'm familiar with loop detection and K/P.

If someone has modified AS_PATH to cause another AS to drop it, then 
they inserted someone else's AS.  This no longer counts as "legitimate 
reachability info", and therefore it should be dropped, and the sooner 
the better.

It sounds like there's another issue mixed up in here (but perhaps not 
in scope of the -bgpsec-threats document): you're trying to resolve the 
ambiguity on what to do with AS_PATH, as Matt notes at the end of the 
following section.

http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5

    EDITOR'S NOTE: Text will be inserted here for dealing with the
    AS_PATH attribute.  Note that the BGPGSEC_Path_Signatures attribute
    now contains all of the information needed to construct the AS_PATH
    attribute.  Therefore, there seem to be two options.  One option the
    BGPSEC speaker checks the AS_PATH attribute against the information
    in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the
    two do not match.  The other option is that the BGPSEC speaker
    discards anything in the AS_PATH attribute and reconstructs the
    AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
    believe that there are no interoperability problems if the choice
    between these two options is left up to the BGPSEC speaker.


> b)  BGP performs loop detection on the AS_PATH attribute only /after/ verifying the BGPSEC_Path_Signature is valid, in which case there is a /potential/ for another type of DoS, because there will always be a limited amount of crypto verifications/sec that can be performed.  There's also the concern that this will slow down propagation of reachability information, because it first needs to be crypto-verified before it's used/propagated.  Note, this is unlikely to be a problem during "steady-state", but is more likely to appear during some amount of churn in BGP due to link and/or router failures, for example.

Yes, this is true -- there's always DoS by feeding garbage to your 
neighbor, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a 
BGP router is mentioned briefly at the end of 4.1 -- would you like more 
text?


From shane@castlepoint.net  Fri Apr  6 10:03:07 2012
Return-Path: <shane@castlepoint.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE7A21F85D6 for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 10:03:07 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVHlOhi-9Gmf for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 10:03:07 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8221F85DB for <sidr@ietf.org>; Fri,  6 Apr 2012 10:03:06 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 81739268063; Fri,  6 Apr 2012 11:03:06 -0600 (MDT)
Received: from [10.1.68.101] (machine77.Level3.com [209.244.4.106]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Fri, 06 Apr 2012 11:03:06 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=209.244.4.106; client-port=33790; syn-fingerprint=65535:54:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <4F7F17D0.7020901@bbn.com>
Date: Fri, 6 Apr 2012 11:02:36 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <667584CE-B72C-4D66-8FE1-E19CDE6779BD@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com> <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net> <4F7F17D0.7020901@bbn.com>
To: Andrew Chi <achi@bbn.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 17:03:08 -0000

On Apr 6, 2012, at 10:20 AM, Andrew Chi wrote:
> On 4/6/2012 11:21 AM, Shane Amante wrote:
>> a)  BGP performs loop detection on the AS_PATH attribute *before* =
verifying any BGPSEC_Path_Signature, in which case you drop the UPDATE, =
thus causing a DoS because you're not propagating what *may* be =
legitimate reachability info further downstream.
>=20
> Right, I'm familiar with loop detection and K/P.
>=20
> If someone has modified AS_PATH to cause another AS to drop it, then =
they inserted someone else's AS.  This no longer counts as "legitimate =
reachability info", and therefore it should be dropped, and the sooner =
the better.

But the problem is: how do you know it's *not* "legitimate reachability =
info" if you've (only) based the decision to drop the UPDATE based on =
unverified info in the AS_PATH attribute?  If you do, that's a _threat_ =
of a DoS attack, which presumably the whole point of BGPSEC is designed =
to protect against.

At some point in the future, the SIDR WG will resolve *how* it's going =
to prescribe that BGP loop detection is supposed to work.  Either way, =
it needs to acknowledge there are two types of potential threats:
a)  Use unverified AS_PATH info for loop detection; or,
b)  Use verified BGPSEC_Path_Signature info for loop detection.
Ultimately, if the SIDR WG prescription *eventually* resolves that loop =
detection is only going to be performed on the BGPSEC_Path_Signature =
attribute, then the text in sidr-threats can be modified, at that future =
point in time, to say something like:
- Attacks against BGP loop detection are mitigated by only using =
verified info on the path from reconstruction of the path in =
BGPSEC_Path_Signature; however,
- This has the potential to introduce a DoS on the BGP control plane =
itself, either through normal operation (high churn) or an operator =
injecting false UPDATE's, into the system, which exceed the capacity of =
routers to perform crypto verification fast enough ...


> It sounds like there's another issue mixed up in here (but perhaps not =
in scope of the -bgpsec-threats document): you're trying to resolve the =
ambiguity on what to do with AS_PATH, as Matt notes at the end of the =
following section.
>=20
> =
http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5
>=20
>   EDITOR'S NOTE: Text will be inserted here for dealing with the
>   AS_PATH attribute.  Note that the BGPGSEC_Path_Signatures attribute
>   now contains all of the information needed to construct the AS_PATH
>   attribute.  Therefore, there seem to be two options.  One option the
>   BGPSEC speaker checks the AS_PATH attribute against the information
>   in the BGPSEC_Path_Signatures attribute and returns "Not Good" if =
the
>   two do not match.  The other option is that the BGPSEC speaker
>   discards anything in the AS_PATH attribute and reconstructs the
>   AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I
>   believe that there are no interoperability problems if the choice
>   between these two options is left up to the BGPSEC speaker.

Given the above, then I suggest the next revision of =
draft-ietf-sidr-bgpsec-protocol explicitly says: "Updates: RFC 4271" and =
that future updates of draft-ietf-sidr-bgpsec-protocol start to be =
shared with IDR WG mailing list, (particularly in light of discussions =
at the recent IDR WG meeting where the SIDR co-chairs have pointed out =
the need for cooperation between SIDR & IDR).  I do not believe that the =
SIDR WG is in a position to make a call as to whether, or to what =
extent, there are going to be interoperability concerns with legacy, =
non-BGPSEC capable routers wrt AS_PATH loop detection ... IMO, that =
should be the responsibility and call of the IDR WG.


>> b)  BGP performs loop detection on the AS_PATH attribute only /after/ =
verifying the BGPSEC_Path_Signature is valid, in which case there is a =
/potential/ for another type of DoS, because there will always be a =
limited amount of crypto verifications/sec that can be performed.  =
There's also the concern that this will slow down propagation of =
reachability information, because it first needs to be crypto-verified =
before it's used/propagated.  Note, this is unlikely to be a problem =
during "steady-state", but is more likely to appear during some amount =
of churn in BGP due to link and/or router failures, for example.
>=20
> Yes, this is true -- there's always DoS by feeding garbage to your =
neighbor, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a =
BGP router is mentioned briefly at the end of 4.1 -- would you like more =
text?

Yes.  I think the text "... DoS attacks against BGP routers" is =
extremely vague, because there are two things that come to mind:
a)  A packet DDoS attack against the router, which may not have anything =
to do with the BGP control plane itself -- i.e.: some attacker trying to =
overwhelm links with too much traffic causing [severe] packet loss; and,
b)  A DoS attack against the actual BGP _control_plane_ itself.  More =
specifically, threats that either:
    i)  overwhelm the I/O, CPU (and/or, memory) capabilities of the BGP =
router; and,
    ii) in the future, overwhelm a new component, namely, the crypto =
verification capabilities of the BGP protocol.

I care about the latter (b), in the context of the SIDR WG, and I =
believe that is what the current text in Section 4.1 is attempting to =
say, just not well enough, yet.

Thanks,

-shane=

From Sandra.Murphy@sparta.com  Fri Apr  6 11:11:20 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4321F85E6 for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 11:11:20 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xS+0unNzZtIC for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 11:11:18 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 58AB721F85A0 for <sidr@ietf.org>; Fri,  6 Apr 2012 11:11:18 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q36IAucc028624; Fri, 6 Apr 2012 13:10:56 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q36IArvH011133; Fri, 6 Apr 2012 13:10:53 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) with mapi id 14.01.0355.002; Fri, 6 Apr 2012 14:10:52 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Shane Amante <shane@castlepoint.net>, Andrew Chi <achi@bbn.com>
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: AQHNDayD9TpKhIJ2FUS/epMAdTcr65aOKkuAgAAPLoCAABCcAIAAC8EA///BOqY=
Date: Fri, 6 Apr 2012 18:10:52 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E4163@Hermes.columbia.ads.sparta.com>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com> <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net> <4F7F17D0.7020901@bbn.com>, <667584CE-B72C-4D66-8FE1-E19CDE6779BD@castlepoint.net>
In-Reply-To: <667584CE-B72C-4D66-8FE1-E19CDE6779BD@castlepoint.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 18:11:20 -0000

Speaking as regular ol' member=0A=
=0A=
Shane, I'm having some trouble following your argument.=0A=
=0A=
Here's what I think you are saying.=0A=
=0A=
You are exploring options for dropping an update based on detecting a loop =
- whether the loop detection should be before or after the check of the pat=
h signatures.=0A=
=0A=
If you do the loop detection first, you say, that's a potential dos attack,=
 because....=0A=
=0A=
    "But the problem is: how do you know it's *not* "legitimate reachabilit=
y info"=0A=
    if you've (only) based the decision to drop the UPDATE based on unverif=
ied info =0A=
    in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS attack=
, which =0A=
    presumably the whole point of BGPSEC is designed to protect against."=
=0A=
=0A=
And that's where I lose you.  I don't see why detecting the loop first prov=
ides a dos attack=0A=
=0A=
Case 1: If the update has actually looped, then dropping the update because=
 of loop detection is just fine.=0A=
=0A=
Case 2: If the update has not actually looped, then someone has managed to =
inject an AS (yours) into the AS_PATH *illegitimately* (the update did not =
actually go trough your AS).  So dropping the update is just fine here also=
, because this is an attack.=0A=
=0A=
In this case, testing the bgpsec signatures will necessarily fail.  So drop=
ping the update because of loop detection is not a denial of service.  Whet=
her you do loop detection first or bgpsec signature test first, the update =
will be dropped.=0A=
=0A=
So where's the dos attack?=0A=
=0A=
(Do note that the bgpsec signatures would detect this at the first point th=
at checked the signatures, so your neighbor would have spotted the injectio=
n - unless it was the source of the injection.)=0A=
=0A=
--Sandy, regular ol' member=0A=
________________________________________=0A=
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Shane Aman=
te [shane@castlepoint.net]=0A=
Sent: Friday, April 06, 2012 1:02 PM=0A=
To: Andrew Chi=0A=
Cc: sidr wg list=0A=
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &   =
     lengthening=0A=
=0A=
On Apr 6, 2012, at 10:20 AM, Andrew Chi wrote:=0A=
> On 4/6/2012 11:21 AM, Shane Amante wrote:=0A=
>> a)  BGP performs loop detection on the AS_PATH attribute *before* verify=
ing any BGPSEC_Path_Signature, in which case you drop the UPDATE, thus caus=
ing a DoS because you're not propagating what *may* be legitimate reachabil=
ity info further downstream.=0A=
>=0A=
> Right, I'm familiar with loop detection and K/P.=0A=
>=0A=
> If someone has modified AS_PATH to cause another AS to drop it, then they=
 inserted someone else's AS.  This no longer counts as "legitimate reachabi=
lity info", and therefore it should be dropped, and the sooner the better.=
=0A=
=0A=
But the problem is: how do you know it's *not* "legitimate reachability inf=
o" if you've (only) based the decision to drop the UPDATE based on unverifi=
ed info in the AS_PATH attribute?  If you do, that's a _threat_ of a DoS at=
tack, which presumably the whole point of BGPSEC is designed to protect aga=
inst.=0A=
=0A=
At some point in the future, the SIDR WG will resolve *how* it's going to p=
rescribe that BGP loop detection is supposed to work.  Either way, it needs=
 to acknowledge there are two types of potential threats:=0A=
a)  Use unverified AS_PATH info for loop detection; or,=0A=
b)  Use verified BGPSEC_Path_Signature info for loop detection.=0A=
Ultimately, if the SIDR WG prescription *eventually* resolves that loop det=
ection is only going to be performed on the BGPSEC_Path_Signature attribute=
, then the text in sidr-threats can be modified, at that future point in ti=
me, to say something like:=0A=
- Attacks against BGP loop detection are mitigated by only using verified i=
nfo on the path from reconstruction of the path in BGPSEC_Path_Signature; h=
owever,=0A=
- This has the potential to introduce a DoS on the BGP control plane itself=
, either through normal operation (high churn) or an operator injecting fal=
se UPDATE's, into the system, which exceed the capacity of routers to perfo=
rm crypto verification fast enough ...=0A=
=0A=
=0A=
> It sounds like there's another issue mixed up in here (but perhaps not in=
 scope of the -bgpsec-threats document): you're trying to resolve the ambig=
uity on what to do with AS_PATH, as Matt notes at the end of the following =
section.=0A=
>=0A=
> http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-5=
=0A=
>=0A=
>   EDITOR'S NOTE: Text will be inserted here for dealing with the=0A=
>   AS_PATH attribute.  Note that the BGPGSEC_Path_Signatures attribute=0A=
>   now contains all of the information needed to construct the AS_PATH=0A=
>   attribute.  Therefore, there seem to be two options.  One option the=0A=
>   BGPSEC speaker checks the AS_PATH attribute against the information=0A=
>   in the BGPSEC_Path_Signatures attribute and returns "Not Good" if the=
=0A=
>   two do not match.  The other option is that the BGPSEC speaker=0A=
>   discards anything in the AS_PATH attribute and reconstructs the=0A=
>   AS_PATH from the data in the BGPSEC_Path_Signatures attribute.  I=0A=
>   believe that there are no interoperability problems if the choice=0A=
>   between these two options is left up to the BGPSEC speaker.=0A=
=0A=
Given the above, then I suggest the next revision of draft-ietf-sidr-bgpsec=
-protocol explicitly says: "Updates: RFC 4271" and that future updates of d=
raft-ietf-sidr-bgpsec-protocol start to be shared with IDR WG mailing list,=
 (particularly in light of discussions at the recent IDR WG meeting where t=
he SIDR co-chairs have pointed out the need for cooperation between SIDR & =
IDR).  I do not believe that the SIDR WG is in a position to make a call as=
 to whether, or to what extent, there are going to be interoperability conc=
erns with legacy, non-BGPSEC capable routers wrt AS_PATH loop detection ...=
 IMO, that should be the responsibility and call of the IDR WG.=0A=
=0A=
=0A=
>> b)  BGP performs loop detection on the AS_PATH attribute only /after/ ve=
rifying the BGPSEC_Path_Signature is valid, in which case there is a /poten=
tial/ for another type of DoS, because there will always be a limited amoun=
t of crypto verifications/sec that can be performed.  There's also the conc=
ern that this will slow down propagation of reachability information, becau=
se it first needs to be crypto-verified before it's used/propagated.  Note,=
 this is unlikely to be a problem during "steady-state", but is more likely=
 to appear during some amount of churn in BGP due to link and/or router fai=
lures, for example.=0A=
>=0A=
> Yes, this is true -- there's always DoS by feeding garbage to your neighb=
or, BGPSEC or not, but crypto lets you waste more CPU.  DoS on a BGP router=
 is mentioned briefly at the end of 4.1 -- would you like more text?=0A=
=0A=
Yes.  I think the text "... DoS attacks against BGP routers" is extremely v=
ague, because there are two things that come to mind:=0A=
a)  A packet DDoS attack against the router, which may not have anything to=
 do with the BGP control plane itself -- i.e.: some attacker trying to over=
whelm links with too much traffic causing [severe] packet loss; and,=0A=
b)  A DoS attack against the actual BGP _control_plane_ itself.  More speci=
fically, threats that either:=0A=
    i)  overwhelm the I/O, CPU (and/or, memory) capabilities of the BGP rou=
ter; and,=0A=
    ii) in the future, overwhelm a new component, namely, the crypto verifi=
cation capabilities of the BGP protocol.=0A=
=0A=
I care about the latter (b), in the context of the SIDR WG, and I believe t=
hat is what the current text in Section 4.1 is attempting to say, just not =
well enough, yet.=0A=
=0A=
Thanks,=0A=
=0A=
-shane=0A=
_______________________________________________=0A=
sidr mailing list=0A=
sidr@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/sidr=0A=

From achi@bbn.com  Fri Apr  6 12:21:43 2012
Return-Path: <achi@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC7D21F8422 for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 12:21:43 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jevcDwxVTHpq for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 12:21:42 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E684C21F8418 for <sidr@ietf.org>; Fri,  6 Apr 2012 12:21:41 -0700 (PDT)
Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:65188 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1SGEik-000ERl-Jw; Fri, 06 Apr 2012 15:21:18 -0400
Message-ID: <4F7F423B.9090604@bbn.com>
Date: Fri, 06 Apr 2012 15:21:31 -0400
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com> <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net> <4F7F17D0.7020901@bbn.com>, <667584CE-B72C-4D66-8FE1-E19CDE6779BD@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E4163@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6E4163@Hermes.columbia.ads.sparta.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 19:21:43 -0000

On 4/6/2012 2:10 PM, Murphy, Sandra wrote:
> So where's the dos attack?
>
> (Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)

So I think I finally see what Shane's getting at.  Let's say:

- I'm a bad actor (A)
- Bob is my neighbor (B)
- Charlie is Bob's neighbor (C)

A is trying to cause B and C to have different views of the world.  In 
addition, we must assume:

- B's router ignores AS_PATH and just uses BGPSEC_Path_Signature
- C's router checks both AS_PATH and BGPSEC_Path_Signature

As the bad actor, A injects C into the AS_PATH (malicious), but 
processes BGPSEC_Path_Signature normally, and sends the update to B.

- B verifies BGPSEC_Path_Signature only, passes it to C
- C detects a loop in AS_PATH and drops the update

A has just caused B to accept an update while simultaneously causing C 
to drop it silently.  While not a very strong attack (B could always 
filter the route anyway), I could imagine it being a starting point for 
causing confusion.

This is solved by prescribing that AS_PATH/AS4_PATH is ignored when 
BGPSEC is enabled, but Shane has a good point that we might need to 
coordinate with IDR on this.  I defer to the WG chairs on that coordination.

-Andrew


From achi@bbn.com  Fri Apr  6 12:36:18 2012
Return-Path: <achi@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC711E80A2 for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 12:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.49
X-Spam-Level: 
X-Spam-Status: No, score=-5.49 tagged_above=-999 required=5 tests=[AWL=-1.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfyDSB-vvS1k for <sidr@ietfa.amsl.com>; Fri,  6 Apr 2012 12:36:18 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 728C311E8099 for <sidr@ietf.org>; Fri,  6 Apr 2012 12:36:18 -0700 (PDT)
Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:65206 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <achi@bbn.com>) id 1SGEwy-000Eky-5X; Fri, 06 Apr 2012 15:36:00 -0400
Message-ID: <4F7F45B0.2020700@bbn.com>
Date: Fri, 06 Apr 2012 15:36:16 -0400
From: Andrew Chi <achi@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Murphy, Sandra" <sandra.murphy@sparta.com>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <4F7EFD25.5020709@bbn.com> <6D97C133-3EFD-4FD5-98B3-942530BD543C@castlepoint.net> <4F7F17D0.7020901@bbn.com> <667584CE-B72C-4D66-8FE1-E19CDE6779BD@castlepoint.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6E4163@Hermes.columbia.ads.sparta.com> <4F7F423B.9090604@bbn.com>
In-Reply-To: <4F7F423B.9090604@bbn.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Apr 2012 19:36:18 -0000

Oops:  s/BGPSEC_Path_Signature/BGPSEC_Path_Signatures/


From kotikalapudi.sriram@nist.gov  Sun Apr  8 09:07:10 2012
Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0963E21F851D for <sidr@ietfa.amsl.com>; Sun,  8 Apr 2012 09:07:10 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsu-dpLL0y-j for <sidr@ietfa.amsl.com>; Sun,  8 Apr 2012 09:07:09 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 13DCB21F8518 for <sidr@ietf.org>; Sun,  8 Apr 2012 09:07:08 -0700 (PDT)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 8 Apr 2012 12:07:07 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Sun, 8 Apr 2012 12:06:18 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Andrew Chi <achi@bbn.com>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, Shane Amante <shane@castlepoint.net>, Matt Lepinski <mlepinski@bbn.com>
Date: Sun, 8 Apr 2012 12:06:16 -0400
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: AQHNFaDEHY+BQd3OrEu3OCHpXNmb0Q==
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
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
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Apr 2012 16:07:10 -0000

Andrew,

There isn't a reason for the problem as you point out to arise.
Your analysis assumes that there a conventional BGP-4 AS_PATH field and then there is
is BGPSEC_Path_Signatures from which AS path info can be inferred separately.
This is not true in the latest BGPSEC update format as Matt presented it in Paris.
Please see slide 8 of the BGPSEC Protocol presentation:
https://datatracker.ietf.org/meeting/83/materials.html 
Matt stated in his presentation that there will soon be an -03 version of the draft
which will include this update format.

What the latest BGPSEC update format has is a field upfront (outside of the BGPSEC_Path_Signatures) 
that provides the sequence of ASNs and their respective pCounts.
Matt has called it the Secure Path (see Slide 8).
Corresponding to each AS in the Secure Path there must be one signature present (in the Sig Block)
in order for the BGPSEC update to be considered well-formed (otherwise it is malformed).
Referring to your example, B is simply not in a position to do what you say he does, namely,
"ignores AS_PATH and just uses BGPSEC_Path_Signatures."
B is required to look at the Secure Path (i.e., ASNs and pCounts) first;
then B expects to see one signature for each AS in the Secure Path;
B finds that this is violated because he sees C's ASN in the Secure Path 
but no signature for it (per your description); 
now B declares that the BGPSEC update from A is malformed.
B would neither verify nor propagate the update any further.
So C does not even get the update.

The good thing about the update format (slide 8) is that
if some AS inserted an AS in the "Secure Path" (without a signature for it),
then the next hop AS knows (even before any signature verification)
that the update is malformed.

I hope this clarification helps.

Sriram
 
> ________________________________________
> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] On Behalf Of Andrew Chi [achi@bbn.com]
> Sent: Friday, April 06, 2012 3:21 PM
> To: Murphy, Sandra
> Cc: sidr wg list
> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &        lengthening
>
> On 4/6/2012 2:10 PM, Murphy, Sandra wrote:
>> So where's the dos attack?
>>
>> (Do note that the bgpsec signatures would detect this at the first point that checked the signatures, so your neighbor would have spotted the injection - unless it was the source of the injection.)
>
> So I think I finally see what Shane's getting at.  Let's say:
>
> - I'm a bad actor (A)
> - Bob is my neighbor (B)
> - Charlie is Bob's neighbor (C)
>
> A is trying to cause B and C to have different views of the world.  In
> addition, we must assume:
>
> - B's router ignores AS_PATH and just uses BGPSEC_Path_Signature
> - C's router checks both AS_PATH and BGPSEC_Path_Signature
>
> As the bad actor, A injects C into the AS_PATH (malicious), but
> processes BGPSEC_Path_Signature normally, and sends the update to B.
>
> - B verifies BGPSEC_Path_Signature only, passes it to C
> - C detects a loop in AS_PATH and drops the update
>
> A has just caused B to accept an update while simultaneously causing C
> to drop it silently.  While not a very strong attack (B could always
> filter the route anyway), I could imagine it being a starting point for
> causing confusion.
>
> This is solved by prescribing that AS_PATH/AS4_PATH is ignored when
> BGPSEC is enabled, but Shane has a good point that we might need to
> coordinate with IDR on this.  I defer to the WG chairs on that coordination.
>
> -Andrew
>

From robert@raszuk.net  Mon Apr  9 00:19:12 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DF811E8080 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 00:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OngZuH5L2kYM for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 00:19:11 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 764F711E8076 for <sidr@ietf.org>; Mon,  9 Apr 2012 00:19:11 -0700 (PDT)
Received: (qmail 6015 invoked by uid 399); 9 Apr 2012 07:19:10 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.9.57) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 07:19:10 -0000
X-Originating-IP: 83.9.9.57
Message-ID: <4F828D6D.10907@raszuk.net>
Date: Mon, 09 Apr 2012 09:19:09 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: sidr@ietf.org
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 07:19:12 -0000

> Your analysis assumes that there a conventional BGP-4 AS_PATH field
> and then there is is BGPSEC_Path_Signatures from which AS path info
> can be inferred separately. This is not true in the latest BGPSEC
> update format as Matt presented it in Paris.

How an optional attribute replace well-known mandatory one ?

Sorry but for such step formal IDR WG approval is necessary if you 
choose to propose BGPSEC_Path_Signatures as mandatory attribute. This is 
major BGP protocol change.

Documentation of partial deployment is required as well as two 
interoperable implementations ;).

RFC4271:

5.1.2.  AS_PATH

    AS_PATH is a well-known mandatory attribute.  This attribute
    identifies the autonomous systems through which routing information
    carried in this UPDATE message has passed.  The components of this
    list can be AS_SETs or AS_SEQUENCEs.


draft-ietf-sidr-bgpsec-protocol-02.txt

    This document specifies a new optional (non-transitive) BGP path
    attribute, BGPSEC_Path_Signatures.


Best regards,
R.


From jakob.heitz@ericsson.com  Mon Apr  9 00:27:11 2012
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A2E21F8568 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 00:27:10 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmm5h7Ih0TTL for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 00:27:10 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 20EF621F855A for <sidr@ietf.org>; Mon,  9 Apr 2012 00:27:10 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q397R4pp026480; Mon, 9 Apr 2012 02:27:05 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 9 Apr 2012 03:26:58 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Andrew Chi <achi@bbn.com>
Date: Mon, 9 Apr 2012 03:27:49 -0400
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: Ac0WIiWSBRYcqzQ/TQOCCbJgGmoLwQ==
Message-ID: <6FFE5C6D-D73F-45F3-8223-89D5CACA29E0@ericsson.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 07:27:11 -0000

IEIncyByb3V0ZXIgaWdub3JlcyBBU19QQVRIDQpIb3cgY2FuIHlvdSBhc3N1bWUgdGhpcz8NCg0K
LS0NCkpha29iIEhlaXR6Lg0KDQoNCk9uIEFwciA4LCAyMDEyLCBhdCA5OjA3IEFNLCAiU3JpcmFt
LCBLb3Rpa2FsYXB1ZGkiIDxrb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PG1haWx0bzprb3Rp
a2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292Pj4gd3JvdGU6DQoNCkFuZHJldywNCg0KVGhlcmUgaXNu
J3QgYSByZWFzb24gZm9yIHRoZSBwcm9ibGVtIGFzIHlvdSBwb2ludCBvdXQgdG8gYXJpc2UuDQpZ
b3VyIGFuYWx5c2lzIGFzc3VtZXMgdGhhdCB0aGVyZSBhIGNvbnZlbnRpb25hbCBCR1AtNCBBU19Q
QVRIIGZpZWxkIGFuZCB0aGVuIHRoZXJlIGlzDQppcyBCR1BTRUNfUGF0aF9TaWduYXR1cmVzIGZy
b20gd2hpY2ggQVMgcGF0aCBpbmZvIGNhbiBiZSBpbmZlcnJlZCBzZXBhcmF0ZWx5Lg0KVGhpcyBp
cyBub3QgdHJ1ZSBpbiB0aGUgbGF0ZXN0IEJHUFNFQyB1cGRhdGUgZm9ybWF0IGFzIE1hdHQgcHJl
c2VudGVkIGl0IGluIFBhcmlzLg0KUGxlYXNlIHNlZSBzbGlkZSA4IG9mIHRoZSBCR1BTRUMgUHJv
dG9jb2wgcHJlc2VudGF0aW9uOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5n
LzgzL21hdGVyaWFscy5odG1sDQpNYXR0IHN0YXRlZCBpbiBoaXMgcHJlc2VudGF0aW9uIHRoYXQg
dGhlcmUgd2lsbCBzb29uIGJlIGFuIC0wMyB2ZXJzaW9uIG9mIHRoZSBkcmFmdA0Kd2hpY2ggd2ls
bCBpbmNsdWRlIHRoaXMgdXBkYXRlIGZvcm1hdC4NCg0KV2hhdCB0aGUgbGF0ZXN0IEJHUFNFQyB1
cGRhdGUgZm9ybWF0IGhhcyBpcyBhIGZpZWxkIHVwZnJvbnQgKG91dHNpZGUgb2YgdGhlIEJHUFNF
Q19QYXRoX1NpZ25hdHVyZXMpDQp0aGF0IHByb3ZpZGVzIHRoZSBzZXF1ZW5jZSBvZiBBU05zIGFu
ZCB0aGVpciByZXNwZWN0aXZlIHBDb3VudHMuDQpNYXR0IGhhcyBjYWxsZWQgaXQgdGhlIFNlY3Vy
ZSBQYXRoIChzZWUgU2xpZGUgOCkuDQpDb3JyZXNwb25kaW5nIHRvIGVhY2ggQVMgaW4gdGhlIFNl
Y3VyZSBQYXRoIHRoZXJlIG11c3QgYmUgb25lIHNpZ25hdHVyZSBwcmVzZW50IChpbiB0aGUgU2ln
IEJsb2NrKQ0KaW4gb3JkZXIgZm9yIHRoZSBCR1BTRUMgdXBkYXRlIHRvIGJlIGNvbnNpZGVyZWQg
d2VsbC1mb3JtZWQgKG90aGVyd2lzZSBpdCBpcyBtYWxmb3JtZWQpLg0KUmVmZXJyaW5nIHRvIHlv
dXIgZXhhbXBsZSwgQiBpcyBzaW1wbHkgbm90IGluIGEgcG9zaXRpb24gdG8gZG8gd2hhdCB5b3Ug
c2F5IGhlIGRvZXMsIG5hbWVseSwNCiJpZ25vcmVzIEFTX1BBVEggYW5kIGp1c3QgdXNlcyBCR1BT
RUNfUGF0aF9TaWduYXR1cmVzLiINCkIgaXMgcmVxdWlyZWQgdG8gbG9vayBhdCB0aGUgU2VjdXJl
IFBhdGggKGkuZS4sIEFTTnMgYW5kIHBDb3VudHMpIGZpcnN0Ow0KdGhlbiBCIGV4cGVjdHMgdG8g
c2VlIG9uZSBzaWduYXR1cmUgZm9yIGVhY2ggQVMgaW4gdGhlIFNlY3VyZSBQYXRoOw0KQiBmaW5k
cyB0aGF0IHRoaXMgaXMgdmlvbGF0ZWQgYmVjYXVzZSBoZSBzZWVzIEMncyBBU04gaW4gdGhlIFNl
Y3VyZSBQYXRoDQpidXQgbm8gc2lnbmF0dXJlIGZvciBpdCAocGVyIHlvdXIgZGVzY3JpcHRpb24p
Ow0Kbm93IEIgZGVjbGFyZXMgdGhhdCB0aGUgQkdQU0VDIHVwZGF0ZSBmcm9tIEEgaXMgbWFsZm9y
bWVkLg0KQiB3b3VsZCBuZWl0aGVyIHZlcmlmeSBub3IgcHJvcGFnYXRlIHRoZSB1cGRhdGUgYW55
IGZ1cnRoZXIuDQpTbyBDIGRvZXMgbm90IGV2ZW4gZ2V0IHRoZSB1cGRhdGUuDQoNClRoZSBnb29k
IHRoaW5nIGFib3V0IHRoZSB1cGRhdGUgZm9ybWF0IChzbGlkZSA4KSBpcyB0aGF0DQppZiBzb21l
IEFTIGluc2VydGVkIGFuIEFTIGluIHRoZSAiU2VjdXJlIFBhdGgiICh3aXRob3V0IGEgc2lnbmF0
dXJlIGZvciBpdCksDQp0aGVuIHRoZSBuZXh0IGhvcCBBUyBrbm93cyAoZXZlbiBiZWZvcmUgYW55
IHNpZ25hdHVyZSB2ZXJpZmljYXRpb24pDQp0aGF0IHRoZSB1cGRhdGUgaXMgbWFsZm9ybWVkLg0K
DQpJIGhvcGUgdGhpcyBjbGFyaWZpY2F0aW9uIGhlbHBzLg0KDQpTcmlyYW0NCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogc2lkci1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzpzaWRyLWJvdW5jZXNAaWV0Zi5vcmc+IFtzaWRyLWJvdW5jZXNAaWV0Zi5vcmc8
bWFpbHRvOnNpZHItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBBbmRyZXcgQ2hpIFth
Y2hpQGJibi5jb208bWFpbHRvOmFjaGlAYmJuLmNvbT5dDQpTZW50OiBGcmlkYXksIEFwcmlsIDA2
LCAyMDEyIDM6MjEgUE0NClRvOiBNdXJwaHksIFNhbmRyYQ0KQ2M6IHNpZHIgd2cgbGlzdA0KU3Vi
amVjdDogUmU6IFtzaWRyXSBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXRocmVhdHMtMDI6IFBhdGgg
c2hvcnRlbmluZyAmICAgICAgICBsZW5ndGhlbmluZw0KDQpPbiA0LzYvMjAxMiAyOjEwIFBNLCBN
dXJwaHksIFNhbmRyYSB3cm90ZToNClNvIHdoZXJlJ3MgdGhlIGRvcyBhdHRhY2s/DQoNCihEbyBu
b3RlIHRoYXQgdGhlIGJncHNlYyBzaWduYXR1cmVzIHdvdWxkIGRldGVjdCB0aGlzIGF0IHRoZSBm
aXJzdCBwb2ludCB0aGF0IGNoZWNrZWQgdGhlIHNpZ25hdHVyZXMsIHNvIHlvdXIgbmVpZ2hib3Ig
d291bGQgaGF2ZSBzcG90dGVkIHRoZSBpbmplY3Rpb24gLSB1bmxlc3MgaXQgd2FzIHRoZSBzb3Vy
Y2Ugb2YgdGhlIGluamVjdGlvbi4pDQoNClNvIEkgdGhpbmsgSSBmaW5hbGx5IHNlZSB3aGF0IFNo
YW5lJ3MgZ2V0dGluZyBhdC4gIExldCdzIHNheToNCg0KLSBJJ20gYSBiYWQgYWN0b3IgKEEpDQot
IEJvYiBpcyBteSBuZWlnaGJvciAoQikNCi0gQ2hhcmxpZSBpcyBCb2IncyBuZWlnaGJvciAoQykN
Cg0KQSBpcyB0cnlpbmcgdG8gY2F1c2UgQiBhbmQgQyB0byBoYXZlIGRpZmZlcmVudCB2aWV3cyBv
ZiB0aGUgd29ybGQuICBJbg0KYWRkaXRpb24sIHdlIG11c3QgYXNzdW1lOg0KDQotIEIncyByb3V0
ZXIgaWdub3JlcyBBU19QQVRIIGFuZCBqdXN0IHVzZXMgQkdQU0VDX1BhdGhfU2lnbmF0dXJlDQot
IEMncyByb3V0ZXIgY2hlY2tzIGJvdGggQVNfUEFUSCBhbmQgQkdQU0VDX1BhdGhfU2lnbmF0dXJl
DQoNCkFzIHRoZSBiYWQgYWN0b3IsIEEgaW5qZWN0cyBDIGludG8gdGhlIEFTX1BBVEggKG1hbGlj
aW91cyksIGJ1dA0KcHJvY2Vzc2VzIEJHUFNFQ19QYXRoX1NpZ25hdHVyZSBub3JtYWxseSwgYW5k
IHNlbmRzIHRoZSB1cGRhdGUgdG8gQi4NCg0KLSBCIHZlcmlmaWVzIEJHUFNFQ19QYXRoX1NpZ25h
dHVyZSBvbmx5LCBwYXNzZXMgaXQgdG8gQw0KLSBDIGRldGVjdHMgYSBsb29wIGluIEFTX1BBVEgg
YW5kIGRyb3BzIHRoZSB1cGRhdGUNCg0KQSBoYXMganVzdCBjYXVzZWQgQiB0byBhY2NlcHQgYW4g
dXBkYXRlIHdoaWxlIHNpbXVsdGFuZW91c2x5IGNhdXNpbmcgQw0KdG8gZHJvcCBpdCBzaWxlbnRs
eS4gIFdoaWxlIG5vdCBhIHZlcnkgc3Ryb25nIGF0dGFjayAoQiBjb3VsZCBhbHdheXMNCmZpbHRl
ciB0aGUgcm91dGUgYW55d2F5KSwgSSBjb3VsZCBpbWFnaW5lIGl0IGJlaW5nIGEgc3RhcnRpbmcg
cG9pbnQgZm9yDQpjYXVzaW5nIGNvbmZ1c2lvbi4NCg0KVGhpcyBpcyBzb2x2ZWQgYnkgcHJlc2Ny
aWJpbmcgdGhhdCBBU19QQVRIL0FTNF9QQVRIIGlzIGlnbm9yZWQgd2hlbg0KQkdQU0VDIGlzIGVu
YWJsZWQsIGJ1dCBTaGFuZSBoYXMgYSBnb29kIHBvaW50IHRoYXQgd2UgbWlnaHQgbmVlZCB0bw0K
Y29vcmRpbmF0ZSB3aXRoIElEUiBvbiB0aGlzLiAgSSBkZWZlciB0byB0aGUgV0cgY2hhaXJzIG9u
IHRoYXQgY29vcmRpbmF0aW9uLg0KDQotQW5kcmV3DQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpzaWRyIG1haWxpbmcgbGlzdA0Kc2lkckBpZXRmLm9y
ZzxtYWlsdG86c2lkckBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vc2lkcg0K

From kotikalapudi.sriram@nist.gov  Mon Apr  9 09:15:20 2012
Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3021F876A; Mon,  9 Apr 2012 09:15:20 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCdc+QxR3wly; Mon,  9 Apr 2012 09:15:19 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id CC34A21F8659; Mon,  9 Apr 2012 09:15:18 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 12:15:15 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 12:15:17 -0400
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: "robert@raszuk.net" <robert@raszuk.net>, "sidr@ietf.org" <sidr@ietf.org>
Date: Mon, 9 Apr 2012 12:15:15 -0400
Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: Ac0WIP7poYzIWIsYQjeyKyGlcjPvLQAQ5cwg
Message-ID: <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net>
In-Reply-To: <4F828D6D.10907@raszuk.net>
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
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 16:15:20 -0000

The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned).
In either case, the update necessarily has AS-path info.
If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it.
If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it. 
The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}.
Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris.
The Secure Path is semantically equivalent to the BGP-4 AS_PATH.
When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island. 
Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times,
and any transparent route server ASN (with pCount=0) in BGPSEC will be removed.
Is this semantic equivalence (of the Secure Path) and 
the guarantee of convertibility to BGP-4 AS_PATH not enough?
Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way)
in addition to the Secure Path, albeit at the cost of duplication and associated 
processing cost/confusion? Just a honest question seeking people's opinion.

Sriram  

>-----Original Message-----
>From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Robert
>Raszuk
>Sent: Monday, April 09, 2012 3:19 AM
>To: sidr@ietf.org
>Cc: idr@ietf.org List
>Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
>
>
>> Your analysis assumes that there a conventional BGP-4 AS_PATH field
>> and then there is is BGPSEC_Path_Signatures from which AS path info
>> can be inferred separately. This is not true in the latest BGPSEC
>> update format as Matt presented it in Paris.
>
>How an optional attribute replace well-known mandatory one ?
>
>Sorry but for such step formal IDR WG approval is necessary if you choose to
>propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP
>protocol change.
>
>Documentation of partial deployment is required as well as two interoperable
>implementations ;).
>
>RFC4271:
>
>5.1.2.  AS_PATH
>
>    AS_PATH is a well-known mandatory attribute.  This attribute
>    identifies the autonomous systems through which routing information
>    carried in this UPDATE message has passed.  The components of this
>    list can be AS_SETs or AS_SEQUENCEs.
>
>
>draft-ietf-sidr-bgpsec-protocol-02.txt
>
>    This document specifies a new optional (non-transitive) BGP path
>    attribute, BGPSEC_Path_Signatures.
>
>
>Best regards,
>R.

From robert@raszuk.net  Mon Apr  9 09:29:44 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF821F8735 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 09:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level: 
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPFbv7I23V37 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 09:29:43 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3567021F872E for <sidr@ietf.org>; Mon,  9 Apr 2012 09:29:43 -0700 (PDT)
Received: (qmail 20314 invoked by uid 399); 9 Apr 2012 16:29:42 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 16:29:42 -0000
X-Originating-IP: 83.9.123.224
Message-ID: <4F830E75.70606@raszuk.net>
Date: Mon, 09 Apr 2012 18:29:41 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>
In-Reply-To: <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 16:29:44 -0000

Hi Sriram,

 > When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
 > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge
 > of the BGPSEC island.

What happens in the opposite direction ? How AS_PATH/AS4_PATH can be 
converted to BGPSEC_Path_Signatures without all necessary information 
present at the ASBR at any arbitrary Autonomous System ? Are you going 
to propose NULL signatures ?

How are you planning on a flag date where all ASBRs in the Internet are 
BGPSEC complaint ?

Why one needs to upgrade also all P routers (intra domain BGP speakers) 
to be BGPSEC complaint provided he is not using BGP as an overlay today?

If you think removal of AS_PATH/AS4_PATH is helpful in any way the much 
simpler would be to define new set of AFIs and call it "SECURED" leaving 
current AFI 1 and AFI 2 unchanged BGP protocol wise.

Thx,
R.


> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e., unsigned).
> In either case, the update necessarily has AS-path info.
> If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandatory) in it.
> If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Path" in it.
> The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k, pCount-k}.
> Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris.
> The Secure Path is semantically equivalent to the BGP-4 AS_PATH.
> When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
> then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of the BGPSEC island.
> Any prepend ASN that was collapsed in BGPSEC will be repeated pCount number of times,
> and any transparent route server ASN (with pCount=0) in BGPSEC will be removed.
> Is this semantic equivalence (of the Secure Path) and
> the guarantee of convertibility to BGP-4 AS_PATH not enough?
> Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in a pristine way)
> in addition to the Secure Path, albeit at the cost of duplication and associated
> processing cost/confusion? Just a honest question seeking people's opinion.
>
> Sriram
>
>> -----Original Message-----
>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of Robert
>> Raszuk
>> Sent: Monday, April 09, 2012 3:19 AM
>> To: sidr@ietf.org
>> Cc: idr@ietf.org List
>> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&  lengthening
>>
>>
>>> Your analysis assumes that there a conventional BGP-4 AS_PATH field
>>> and then there is is BGPSEC_Path_Signatures from which AS path info
>>> can be inferred separately. This is not true in the latest BGPSEC
>>> update format as Matt presented it in Paris.
>>
>> How an optional attribute replace well-known mandatory one ?
>>
>> Sorry but for such step formal IDR WG approval is necessary if you choose to
>> propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP
>> protocol change.
>>
>> Documentation of partial deployment is required as well as two interoperable
>> implementations ;).
>>
>> RFC4271:
>>
>> 5.1.2.  AS_PATH
>>
>>     AS_PATH is a well-known mandatory attribute.  This attribute
>>     identifies the autonomous systems through which routing information
>>     carried in this UPDATE message has passed.  The components of this
>>     list can be AS_SETs or AS_SEQUENCEs.
>>
>>
>> draft-ietf-sidr-bgpsec-protocol-02.txt
>>
>>     This document specifies a new optional (non-transitive) BGP path
>>     attribute, BGPSEC_Path_Signatures.
>>
>>
>> Best regards,
>> R.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>


From Sandra.Murphy@sparta.com  Mon Apr  9 10:07:20 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840C621F8773; Mon,  9 Apr 2012 10:07:20 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkAvo1U6JYvs; Mon,  9 Apr 2012 10:07:19 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8115F21F876C; Mon,  9 Apr 2012 10:07:19 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q39H7HE1013235; Mon, 9 Apr 2012 12:07:17 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q39H7G1a025926; Mon, 9 Apr 2012 12:07:16 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 13:07:16 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "robert@raszuk.net" <robert@raszuk.net>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Thread-Topic: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
Thread-Index: AQHNFm38jP+kiH4DhkCDobXjHWi/RJaSt/9z
Date: Mon, 9 Apr 2012 17:07:16 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net>
In-Reply-To: <4F830E75.70606@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 17:07:20 -0000

speaking as regular ol' member=0A=
=0A=
There is no reverse direction.=0A=
=0A=
Incoming paths that are unsigned are not propagated by bgpsec speakers as s=
igned paths.=0A=
=0A=
And intradomain BGP speakers do not use bgpsec (ebgp sessions only).=0A=
=0A=
And AS4_PATH is not needed in bgpsec speakers - who are assumed to be 4-byt=
e aware.=0A=
=0A=
So no need to worry about ASBRs, flag days, etc.  Don't worry, no problem.=
=0A=
=0A=
--Sandy, speaking as regular ol' member.=0A=
=0A=
=0A=
________________________________________=0A=
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Robert Ras=
zuk [robert@raszuk.net]=0A=
Sent: Monday, April 09, 2012 12:29 PM=0A=
To: Sriram, Kotikalapudi=0A=
Cc: idr@ietf.org List; sidr@ietf.org=0A=
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortenin=
g &  lengthening=0A=
=0A=
Hi Sriram,=0A=
=0A=
 > When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A=
 > then the Secure Path is easily converted to BGP-4 AS_PATH at the edge=0A=
 > of the BGPSEC island.=0A=
=0A=
What happens in the opposite direction ? How AS_PATH/AS4_PATH can be=0A=
converted to BGPSEC_Path_Signatures without all necessary information=0A=
present at the ASBR at any arbitrary Autonomous System ? Are you going=0A=
to propose NULL signatures ?=0A=
=0A=
How are you planning on a flag date where all ASBRs in the Internet are=0A=
BGPSEC complaint ?=0A=
=0A=
Why one needs to upgrade also all P routers (intra domain BGP speakers)=0A=
to be BGPSEC complaint provided he is not using BGP as an overlay today?=0A=
=0A=
If you think removal of AS_PATH/AS4_PATH is helpful in any way the much=0A=
simpler would be to define new set of AFIs and call it "SECURED" leaving=0A=
current AFI 1 and AFI 2 unchanged BGP protocol wise.=0A=
=0A=
Thx,=0A=
R.=0A=
=0A=
=0A=
> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or BGP-4 (i.e=
., unsigned).=0A=
> In either case, the update necessarily has AS-path info.=0A=
> If the update is BGP-4 (i.e., unsigned), it has the BGP-4 AS_PATH (mandat=
ory) in it.=0A=
> If the update is BGPSEC (i.e., signed), then it MUST have the "Secure Pat=
h" in it.=0A=
> The Secure Path is in the form of {ASN1, pCount1, ASN2, pCount2, ...., AS=
N-k, pCount-k}.=0A=
> Please refer to slide 8 in Matt's presentation (BGPSEC Protocol) in Paris=
.=0A=
> The Secure Path is semantically equivalent to the BGP-4 AS_PATH.=0A=
> When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A=
> then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of =
the BGPSEC island.=0A=
> Any prepend ASN that was collapsed in BGPSEC will be repeated pCount numb=
er of times,=0A=
> and any transparent route server ASN (with pCount=3D0) in BGPSEC will be =
removed.=0A=
> Is this semantic equivalence (of the Secure Path) and=0A=
> the guarantee of convertibility to BGP-4 AS_PATH not enough?=0A=
> Should we really require in BGPSEC that the BGP-4 AS_PATH be carried (in =
a pristine way)=0A=
> in addition to the Secure Path, albeit at the cost of duplication and ass=
ociated=0A=
> processing cost/confusion? Just a honest question seeking people's opinio=
n.=0A=
>=0A=
> Sriram=0A=
>=0A=
>> -----Original Message-----=0A=
>> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of =
Robert=0A=
>> Raszuk=0A=
>> Sent: Monday, April 09, 2012 3:19 AM=0A=
>> To: sidr@ietf.org=0A=
>> Cc: idr@ietf.org List=0A=
>> Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening& =
 lengthening=0A=
>>=0A=
>>=0A=
>>> Your analysis assumes that there a conventional BGP-4 AS_PATH field=0A=
>>> and then there is is BGPSEC_Path_Signatures from which AS path info=0A=
>>> can be inferred separately. This is not true in the latest BGPSEC=0A=
>>> update format as Matt presented it in Paris.=0A=
>>=0A=
>> How an optional attribute replace well-known mandatory one ?=0A=
>>=0A=
>> Sorry but for such step formal IDR WG approval is necessary if you choos=
e to=0A=
>> propose BGPSEC_Path_Signatures as mandatory attribute. This is major BGP=
=0A=
>> protocol change.=0A=
>>=0A=
>> Documentation of partial deployment is required as well as two interoper=
able=0A=
>> implementations ;).=0A=
>>=0A=
>> RFC4271:=0A=
>>=0A=
>> 5.1.2.  AS_PATH=0A=
>>=0A=
>>     AS_PATH is a well-known mandatory attribute.  This attribute=0A=
>>     identifies the autonomous systems through which routing information=
=0A=
>>     carried in this UPDATE message has passed.  The components of this=
=0A=
>>     list can be AS_SETs or AS_SEQUENCEs.=0A=
>>=0A=
>>=0A=
>> draft-ietf-sidr-bgpsec-protocol-02.txt=0A=
>>=0A=
>>     This document specifies a new optional (non-transitive) BGP path=0A=
>>     attribute, BGPSEC_Path_Signatures.=0A=
>>=0A=
>>=0A=
>> Best regards,=0A=
>> R.=0A=
> _______________________________________________=0A=
> Idr mailing list=0A=
> Idr@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/idr=0A=
>=0A=
>=0A=
=0A=
_______________________________________________=0A=
sidr mailing list=0A=
sidr@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/sidr=0A=

From robert@raszuk.net  Mon Apr  9 10:22:26 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364A921F87AA for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 10:22:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.492
X-Spam-Level: 
X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bryhC5pfvyZ8 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 10:22:25 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEE921F87A5 for <sidr@ietf.org>; Mon,  9 Apr 2012 10:22:24 -0700 (PDT)
Received: (qmail 24973 invoked by uid 399); 9 Apr 2012 17:22:23 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 17:22:23 -0000
X-Originating-IP: 83.9.123.224
Message-ID: <4F831ACE.8090903@raszuk.net>
Date: Mon, 09 Apr 2012 19:22:22 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 17:22:27 -0000

Hi Sandy,

> There is no reverse direction.

What do you mean there is no reverse direction ?

Sriram said:

"When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of
the BGPSEC island."

That means that there is EBGP peering at the two ASes which on one side
supports BGPSEC on the other does not.

In order to establish any form of bidirectional communication sites on
the left need to know how to reach sites on the right and vice versa.

So your below "Don't worry, no problem" directly means "no 
reachability". I am afraid there is slight problem with that.

Best regards,
R.


> speaking as regular ol' member
>
> There is no reverse direction.
>
> Incoming paths that are unsigned are not propagated by bgpsec
> speakers as signed paths.
>
> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
>
> And AS4_PATH is not needed in bgpsec speakers - who are assumed to be
> 4-byte aware.
>
> So no need to worry about ASBRs, flag days, etc.  Don't worry, no
> problem.
>
> --Sandy, speaking as regular ol' member.
>
>
> ________________________________________ From: sidr-bounces@ietf.org
> [sidr-bounces@ietf.org] on behalf of Robert Raszuk
> [robert@raszuk.net] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,
> Kotikalapudi Cc: idr@ietf.org List; sidr@ietf.org Subject: Re: [sidr]
> [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&
> lengthening
>
> Hi Sriram,
>
>> When the update is to leave a BGPSEC island to go to a BGP-4 only
>> AS, then the Secure Path is easily converted to BGP-4 AS_PATH at
>> the edge of the BGPSEC island.
>
> What happens in the opposite direction ? How AS_PATH/AS4_PATH can be
> converted to BGPSEC_Path_Signatures without all necessary
> information present at the ASBR at any arbitrary Autonomous System ?
> Are you going to propose NULL signatures ?
>
> How are you planning on a flag date where all ASBRs in the Internet
> are BGPSEC complaint ?
>
> Why one needs to upgrade also all P routers (intra domain BGP
> speakers) to be BGPSEC complaint provided he is not using BGP as an
> overlay today?
>
> If you think removal of AS_PATH/AS4_PATH is helpful in any way the
> much simpler would be to define new set of AFIs and call it "SECURED"
> leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.
>
> Thx, R.
>
>
>> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or
>> BGP-4 (i.e., unsigned). In either case, the update necessarily has
>> AS-path info. If the update is BGP-4 (i.e., unsigned), it has the
>> BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e.,
>> signed), then it MUST have the "Secure Path" in it. The Secure Path
>> is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k,
>> pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC
>> Protocol) in Paris. The Secure Path is semantically equivalent to
>> the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to
>> go to a BGP-4 only AS, then the Secure Path is easily converted to
>> BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN
>> that was collapsed in BGPSEC will be repeated pCount number of
>> times, and any transparent route server ASN (with pCount=0) in
>> BGPSEC will be removed. Is this semantic equivalence (of the Secure
>> Path) and the guarantee of convertibility to BGP-4 AS_PATH not
>> enough? Should we really require in BGPSEC that the BGP-4 AS_PATH
>> be carried (in a pristine way) in addition to the Secure Path,
>> albeit at the cost of duplication and associated processing
>> cost/confusion? Just a honest question seeking people's opinion.
>>
>> Sriram
>>
>>> -----Original Message----- From: sidr-bounces@ietf.org
>>> [mailto:sidr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:
>>> Monday, April 09, 2012 3:19 AM To: sidr@ietf.org Cc: idr@ietf.org
>>> List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path
>>> shortening&   lengthening
>>>
>>>
>>>> Your analysis assumes that there a conventional BGP-4 AS_PATH
>>>> field and then there is is BGPSEC_Path_Signatures from which AS
>>>> path info can be inferred separately. This is not true in the
>>>> latest BGPSEC update format as Matt presented it in Paris.
>>>
>>> How an optional attribute replace well-known mandatory one ?
>>>
>>> Sorry but for such step formal IDR WG approval is necessary if
>>> you choose to propose BGPSEC_Path_Signatures as mandatory
>>> attribute. This is major BGP protocol change.
>>>
>>> Documentation of partial deployment is required as well as two
>>> interoperable implementations ;).
>>>
>>> RFC4271:
>>>
>>> 5.1.2.  AS_PATH
>>>
>>> AS_PATH is a well-known mandatory attribute.  This attribute
>>> identifies the autonomous systems through which routing
>>> information carried in this UPDATE message has passed.  The
>>> components of this list can be AS_SETs or AS_SEQUENCEs.
>>>
>>>
>>> draft-ietf-sidr-bgpsec-protocol-02.txt
>>>
>>> This document specifies a new optional (non-transitive) BGP path
>>> attribute, BGPSEC_Path_Signatures.
>>>
>>>
>>> Best regards, R.



From dougm@nist.gov  Mon Apr  9 10:48:25 2012
Return-Path: <dougm@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6FA21F8796; Mon,  9 Apr 2012 10:48:25 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OP6Nv7JZ38e; Mon,  9 Apr 2012 10:48:24 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAFE21F8793; Mon,  9 Apr 2012 10:48:23 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 13:48:20 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 9 Apr 2012 13:48:22 -0400
From: "Montgomery, Douglas" <dougm@nist.gov>
To: "robert@raszuk.net" <robert@raszuk.net>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Date: Mon, 9 Apr 2012 13:48:08 -0400
Thread-Topic: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
Thread-Index: Ac0WeNTw+xkeBDfiTiWJaKyynRKoYw==
Message-ID: <CBA8984B.A6215%dougm@nist.gov>
In-Reply-To: <4F831ACE.8090903@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 17:48:25 -0000

On 4/9/12 1:22 PM, "Robert Raszuk" <robert@raszuk.net> wrote:

>Hi Sandy,
>
>> There is no reverse direction.
>
>What do you mean there is no reverse direction ?
>
>Sriram said:
>
>"When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
>then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of
>the BGPSEC island."
>
>That means that there is EBGP peering at the two ASes which on one side
>supports BGPSEC on the other does not.

Right.  BGPSEC doesn't support partially signed PATHS.  Thus a update
either starts off signed, or it is not signed at all.

You can take a signed path, strip the PATH-SIG, reconstruct the AS-PATH
and transmit it to a non-BGPSEC speaker.  But from that point on, the PATH
remains unsigned.

A path that starts off unsigned, will always remain unsigned.

Dougm


From robert@raszuk.net  Mon Apr  9 11:02:18 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16BE21F8672 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 11:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.51
X-Spam-Level: 
X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQbNr0XLZgek for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 11:02:18 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id CD8FC21F87CB for <sidr@ietf.org>; Mon,  9 Apr 2012 11:02:14 -0700 (PDT)
Received: (qmail 12797 invoked by uid 399); 9 Apr 2012 18:02:14 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 18:02:14 -0000
X-Originating-IP: 83.9.123.224
Message-ID: <4F832424.1090104@raszuk.net>
Date: Mon, 09 Apr 2012 20:02:12 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: "Montgomery, Douglas" <dougm@nist.gov>
References: <CBA8984B.A6215%dougm@nist.gov>
In-Reply-To: <CBA8984B.A6215%dougm@nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 18:02:19 -0000

Hi,

> A path that starts off unsigned, will always remain unsigned.

Do you mean that:

"A path that starts off unsinged or transits via at least one non BGPSEC 
enabled BGP router (edge or core) will always remain unsigned."

?

Many thx,
R.







From Sandra.Murphy@sparta.com  Mon Apr  9 11:12:37 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C0D21F87B3; Mon,  9 Apr 2012 11:12:37 -0700 (PDT)
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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpR7RA2X-2-x; Mon,  9 Apr 2012 11:12:36 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D9DFB21F8764; Mon,  9 Apr 2012 11:12:35 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q39ICYrM014152; Mon, 9 Apr 2012 13:12:34 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q39ICXUq028551; Mon, 9 Apr 2012 13:12:33 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 9 Apr 2012 14:12:33 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "robert@raszuk.net" <robert@raszuk.net>
Thread-Topic: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
Thread-Index: AQHNFnVVP+4RrE3i6E+YFR9dt0xcTpaSxY54
Date: Mon, 9 Apr 2012 18:12:32 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2586@Hermes.columbia.ads.sparta.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>, <4F831ACE.8090903@raszuk.net>
In-Reply-To: <4F831ACE.8090903@raszuk.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 18:12:37 -0000

still speaking as regular ol' member=0A=
=0A=
by "no reverse direction",  it was in answer to your question "What happens=
 in the opposite direction ? ".  I should have used your words exactly.=0A=
=0A=
I meant what I said in the second line I wrote.  "Incoming paths that are u=
nsigned are not propagated by bgpsec speakers as signed paths.".    They ar=
e propagated as unsigned paths.=0A=
=0A=
So there's no need to try to produce signatures for unsigned paths.  Routes=
 that come in unsigned, stay unsigned.=0A=
=0A=
There is no loss of reachability, because the routes are propagated.=0A=
=0A=
--Sandy, speaking as regular ol' member=0A=
=0A=
________________________________________=0A=
From: Robert Raszuk [robert@raszuk.net]=0A=
Sent: Monday, April 09, 2012 1:22 PM=0A=
To: Murphy, Sandra=0A=
Cc: Sriram, Kotikalapudi; idr@ietf.org List; sidr@ietf.org=0A=
Subject: Re: [Idr] [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortenin=
g &  lengthening=0A=
=0A=
Hi Sandy,=0A=
=0A=
> There is no reverse direction.=0A=
=0A=
What do you mean there is no reverse direction ?=0A=
=0A=
Sriram said:=0A=
=0A=
"When the update is to leave a BGPSEC island to go to a BGP-4 only AS,=0A=
then the Secure Path is easily converted to BGP-4 AS_PATH at the edge of=0A=
the BGPSEC island."=0A=
=0A=
That means that there is EBGP peering at the two ASes which on one side=0A=
supports BGPSEC on the other does not.=0A=
=0A=
In order to establish any form of bidirectional communication sites on=0A=
the left need to know how to reach sites on the right and vice versa.=0A=
=0A=
So your below "Don't worry, no problem" directly means "no=0A=
reachability". I am afraid there is slight problem with that.=0A=
=0A=
Best regards,=0A=
R.=0A=
=0A=
=0A=
> speaking as regular ol' member=0A=
>=0A=
> There is no reverse direction.=0A=
>=0A=
> Incoming paths that are unsigned are not propagated by bgpsec=0A=
> speakers as signed paths.=0A=
>=0A=
> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).=0A=
>=0A=
> And AS4_PATH is not needed in bgpsec speakers - who are assumed to be=0A=
> 4-byte aware.=0A=
>=0A=
> So no need to worry about ASBRs, flag days, etc.  Don't worry, no=0A=
> problem.=0A=
>=0A=
> --Sandy, speaking as regular ol' member.=0A=
>=0A=
>=0A=
> ________________________________________ From: sidr-bounces@ietf.org=0A=
> [sidr-bounces@ietf.org] on behalf of Robert Raszuk=0A=
> [robert@raszuk.net] Sent: Monday, April 09, 2012 12:29 PM To: Sriram,=0A=
> Kotikalapudi Cc: idr@ietf.org List; sidr@ietf.org Subject: Re: [sidr]=0A=
> [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening&=0A=
> lengthening=0A=
>=0A=
> Hi Sriram,=0A=
>=0A=
>> When the update is to leave a BGPSEC island to go to a BGP-4 only=0A=
>> AS, then the Secure Path is easily converted to BGP-4 AS_PATH at=0A=
>> the edge of the BGPSEC island.=0A=
>=0A=
> What happens in the opposite direction ? How AS_PATH/AS4_PATH can be=0A=
> converted to BGPSEC_Path_Signatures without all necessary=0A=
> information present at the ASBR at any arbitrary Autonomous System ?=0A=
> Are you going to propose NULL signatures ?=0A=
>=0A=
> How are you planning on a flag date where all ASBRs in the Internet=0A=
> are BGPSEC complaint ?=0A=
>=0A=
> Why one needs to upgrade also all P routers (intra domain BGP=0A=
> speakers) to be BGPSEC complaint provided he is not using BGP as an=0A=
> overlay today?=0A=
>=0A=
> If you think removal of AS_PATH/AS4_PATH is helpful in any way the=0A=
> much simpler would be to define new set of AFIs and call it "SECURED"=0A=
> leaving current AFI 1 and AFI 2 unchanged BGP protocol wise.=0A=
>=0A=
> Thx, R.=0A=
>=0A=
>=0A=
>> The updates in a BGPSEC island can be BGPSEC (i.e., signed) or=0A=
>> BGP-4 (i.e., unsigned). In either case, the update necessarily has=0A=
>> AS-path info. If the update is BGP-4 (i.e., unsigned), it has the=0A=
>> BGP-4 AS_PATH (mandatory) in it. If the update is BGPSEC (i.e.,=0A=
>> signed), then it MUST have the "Secure Path" in it. The Secure Path=0A=
>> is in the form of {ASN1, pCount1, ASN2, pCount2, ...., ASN-k,=0A=
>> pCount-k}. Please refer to slide 8 in Matt's presentation (BGPSEC=0A=
>> Protocol) in Paris. The Secure Path is semantically equivalent to=0A=
>> the BGP-4 AS_PATH. When the update is to leave a BGPSEC island to=0A=
>> go to a BGP-4 only AS, then the Secure Path is easily converted to=0A=
>> BGP-4 AS_PATH at the edge of the BGPSEC island. Any prepend ASN=0A=
>> that was collapsed in BGPSEC will be repeated pCount number of=0A=
>> times, and any transparent route server ASN (with pCount=3D0) in=0A=
>> BGPSEC will be removed. Is this semantic equivalence (of the Secure=0A=
>> Path) and the guarantee of convertibility to BGP-4 AS_PATH not=0A=
>> enough? Should we really require in BGPSEC that the BGP-4 AS_PATH=0A=
>> be carried (in a pristine way) in addition to the Secure Path,=0A=
>> albeit at the cost of duplication and associated processing=0A=
>> cost/confusion? Just a honest question seeking people's opinion.=0A=
>>=0A=
>> Sriram=0A=
>>=0A=
>>> -----Original Message----- From: sidr-bounces@ietf.org=0A=
>>> [mailto:sidr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent:=0A=
>>> Monday, April 09, 2012 3:19 AM To: sidr@ietf.org Cc: idr@ietf.org=0A=
>>> List Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path=0A=
>>> shortening&   lengthening=0A=
>>>=0A=
>>>=0A=
>>>> Your analysis assumes that there a conventional BGP-4 AS_PATH=0A=
>>>> field and then there is is BGPSEC_Path_Signatures from which AS=0A=
>>>> path info can be inferred separately. This is not true in the=0A=
>>>> latest BGPSEC update format as Matt presented it in Paris.=0A=
>>>=0A=
>>> How an optional attribute replace well-known mandatory one ?=0A=
>>>=0A=
>>> Sorry but for such step formal IDR WG approval is necessary if=0A=
>>> you choose to propose BGPSEC_Path_Signatures as mandatory=0A=
>>> attribute. This is major BGP protocol change.=0A=
>>>=0A=
>>> Documentation of partial deployment is required as well as two=0A=
>>> interoperable implementations ;).=0A=
>>>=0A=
>>> RFC4271:=0A=
>>>=0A=
>>> 5.1.2.  AS_PATH=0A=
>>>=0A=
>>> AS_PATH is a well-known mandatory attribute.  This attribute=0A=
>>> identifies the autonomous systems through which routing=0A=
>>> information carried in this UPDATE message has passed.  The=0A=
>>> components of this list can be AS_SETs or AS_SEQUENCEs.=0A=
>>>=0A=
>>>=0A=
>>> draft-ietf-sidr-bgpsec-protocol-02.txt=0A=
>>>=0A=
>>> This document specifies a new optional (non-transitive) BGP path=0A=
>>> attribute, BGPSEC_Path_Signatures.=0A=
>>>=0A=
>>>=0A=
>>> Best regards, R.=0A=
=0A=
=0A=

From robert@raszuk.net  Mon Apr  9 11:50:09 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AB021F8762 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 11:50:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level: 
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8T5gs+9yUb0k for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 11:50:08 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8430421F8495 for <sidr@ietf.org>; Mon,  9 Apr 2012 11:50:08 -0700 (PDT)
Received: (qmail 19889 invoked by uid 399); 9 Apr 2012 18:50:08 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.9.123.224) by mail1310.opentransfer.com with ESMTPM; 9 Apr 2012 18:50:08 -0000
X-Originating-IP: 83.9.123.224
Message-ID: <4F832F5E.9030903@raszuk.net>
Date: Mon, 09 Apr 2012 20:50:06 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>, sidr wg list <sidr@ietf.org>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: [sidr] No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Apr 2012 18:50:09 -0000

Hi,

> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).

I do not understand. How a BGP Update will transit via an AS where each 
router is a real BGP speaker and where as some proposed BGP mandatory 
AS_PATH attribute is not present ?

Are you assuming each AS today is BGP Free with full mesh of MPLS/IP 
tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected 
directly or indirectly (RRs) via IBGP.

As you proposing to remove AS_PATH selection criteria from best path for 
updates which come over IBGP ? What happens if you need to compare paths 
received over EBGP and IBGP on a given BGP speaker ?

Many thx,
R.


From kent@bbn.com  Mon Apr  9 18:35:40 2012
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A17411E807F; Mon,  9 Apr 2012 18:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.516
X-Spam-Level: 
X-Spam-Status: No, score=-106.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azqEToXjsI37; Mon,  9 Apr 2012 18:35:40 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id D602811E8079; Mon,  9 Apr 2012 18:35:39 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:57555 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SHPzM-0009FY-D2; Mon, 09 Apr 2012 21:35:21 -0400
Mime-Version: 1.0
Message-Id: <p06240800cba934a958f7@[10.5.23.166]>
In-Reply-To: <4F830E75.70606@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net>
Date: Mon, 9 Apr 2012 20:52:46 -0400
To: robert@raszuk.net
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: "idr@ietf.org List" <idr@ietf.org>, "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr] draft-ietf-sidr-bgpsec-threats-02: Path shortening &	lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 01:35:40 -0000

At 6:29 PM +0200 4/9/12, Robert Raszuk wrote:
>Hi Sriram,
>
>>  When the update is to leave a BGPSEC island to go to a BGP-4 only AS,
>>  then the Secure Path is easily converted to BGP-4 AS_PATH at the edge
>>  of the BGPSEC island.
>
>What happens in the opposite direction ?

you can't go in the opposite direction, i.e., from unsigned to signed.

Steve

From kent@bbn.com  Mon Apr  9 19:23:05 2012
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A562021F8681 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 19:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.534
X-Spam-Level: 
X-Spam-Status: No, score=-106.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC19mvp1-uPQ for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 19:23:05 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F82221F8671 for <sidr@ietf.org>; Mon,  9 Apr 2012 19:23:05 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:46358 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SHQjH-0009cX-3t; Mon, 09 Apr 2012 22:22:47 -0400
Mime-Version: 1.0
Message-Id: <p06240809cba947b7d040@[172.31.27.154]>
In-Reply-To: <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net>
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net>
Date: Mon, 9 Apr 2012 22:20:37 -0400
To: Shane Amante <shane@castlepoint.net>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 02:23:05 -0000

At 3:04 PM +0200 3/29/12, Shane Amante wrote:
>Steve,
>
>Thanks for the response.  First, a high-level comment before more 
>specific responses below.

Shane,  sorry to be so late in replying.  I think you and Andrew have 
already discussed a number of the issues you raised below, so I'll 
just make a few, brief comments.

First, as Sriram noted, BGPSEC carries only the secure AS path info, 
not the old
As path attribute. So there cannot be a mismatch between the two, and 
loop detection should work. Because of the signature requirements, no 
bogus ASN's can appear in the secured path, no hops can be stripped, 
etc. It's an implementation decision as to whether a router checks 
the secured path data before validating the sigs to detect a loop. 
One might do this to avoid wasting cycles on crypto.

>...
>There is text about MITM threat in Section 4.2; however, that seems 
>to relate to crypto security between two adjacent routers over, say, 
>a directly connected link.  However, what about MITM attacks that 
>create what appear to be valid BGPSEC_Path_Signature attribute that 
>would pass verification by downstream parties?

I still do not understand. Unless a MITM has access to the private 
keys for the BGP routers in question, it cannot generate sigs that 
will validate when checked by downstream parties.'

Steve

From kent@bbn.com  Mon Apr  9 19:23:07 2012
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5BD11E8074 for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 19:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.54
X-Spam-Level: 
X-Spam-Status: No, score=-106.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqVbiqMzGaLw for <sidr@ietfa.amsl.com>; Mon,  9 Apr 2012 19:23:07 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 312E021F8752 for <sidr@ietf.org>; Mon,  9 Apr 2012 19:23:07 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:46358 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SHQj9-0009cX-8a; Mon, 09 Apr 2012 22:22:40 -0400
Mime-Version: 1.0
Message-Id: <p06240807cba945654510@[172.31.27.154]>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9@EUSAACMS0701.eamcs.ericsson.se >
References: <64B29EFD-5C6E-4D0C-8E4F-92A2B5A86279@castlepoint.net> <p06240803cb99d283e548@[10.108.69.44]> <8D2985D4-07C3-42EE-A694-DAF24D34F84A@castlepoint.net> <7309FCBCAE981B43ABBE69B31C8D21391B3EBFDFD9@EUSAACMS0701.eamcs.ericsson.se >
Date: Mon, 9 Apr 2012 22:12:56 -0400
To: Jakob Heitz <jakob.heitz@ericsson.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-878097901==_ma============"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path shortening & lengthening
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 02:23:07 -0000

--============_-878097901==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 9:46 AM -0400 3/29/12, Jakob Heitz wrote:
>Let's just require that BGPSEC capable routers
>also support 4 byte AS. Then we don't need to worry
>about AS4_PTH.
>
>--
>Jakob Heitz.

This is already a requirement. See the BGPSEC protocol spec, page 4:

  By indicating support for receiving BGPSEC update messages, a BGP 
speaker is, in particular, indicating that the following are true:

    o  The BGP speaker understands the BGPSEC_Path_Signatures 
attribute (see Section 3).

    o  The BGP speaker supports 4-byte AS numbers (see RFC 4893).
--============_-878097901==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [sidr] draft-ietf-sidr-bgpsec-threats-02: Path
shorten</title></head><body>
<div>At 9:46 AM -0400 3/29/12, Jakob Heitz wrote:</div>
<blockquote type="cite" cite><font face="Lucida Console" size="-1"
color="#800080">Let's just require that BGPSEC capable
routers</font></blockquote>
<blockquote type="cite" cite><font face="Lucida Console" size="-1"
color="#800080">also support 4 byte AS. Then we don't need to
worry</font></blockquote>
<blockquote type="cite" cite><font face="Lucida Console" size="-1"
color="#800080">about AS4_PTH.</font><br>
</blockquote>
<blockquote type="cite" cite><font face="Arial"
size="-1">--</font></blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">Jakob
Heitz.</font></blockquote>
<div><br></div>
<div>This is already a requirement. See the BGPSEC protocol spec, page
4:</div>
<div><br></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;By
indicating support for receiving BGPSEC update messages, a BGP speaker
is, in particular, indicating that the following are
true:</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
<div><font face="Courier" size="+2" color="#000000">&nbsp;&nbsp; o&nbsp;
The BGP speaker understands the BGPSEC_Path_Signatures attribute (see
Section 3).</font></div>
<div><font face="Courier" size="+2" color="#000000"><br>
&nbsp;&nbsp; o&nbsp; The BGP speaker supports 4-byte AS numbers (see
RFC 4893).</font></div>
</body>
</html>
--============_-878097901==_ma============--

From christopher.morrow@gmail.com  Mon Apr  9 21:59:11 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707D21F875E; Mon,  9 Apr 2012 21:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXtvQmKir76b; Mon,  9 Apr 2012 21:59:11 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5499421F875B; Mon,  9 Apr 2012 21:59:11 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so7609817obb.31 for <multiple recipients>; Mon, 09 Apr 2012 21:59:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KTgEja/96FzWQIz6Qo1OvhIb8X2TJIWJDcmvmAiyeUQ=; b=dWsO+3vAnfwyd6YIthp2xIou2MuOvQ39BMzacFNJFAVmUJQw9D1y4zZBVc2TQ8My6l xbEsIIOwtFEs1YrRMwov+i3GY0alMKbRm6y67vhgSzOjrW8EPK6k1R4TjGIlMYnysbNG WM0oDQGIxLPGNMjhJmmaY4882MEjHFeyStWRWzjgRE1kwciTixqOptvbiS8xIFyuLc03 dF6KQ5YTPog8W8aTgpM40MLkSc+V5Oo5AHv7dJDbpBs3IJgiv4CquRN/biZ+mXtWzXdD sVnMkq6ZQgLWryT2Dnr01jUErBirXulJekw3B+7iC1k4jMnPVZhAs9yTqZWQcQgPdVO4 JVig==
MIME-Version: 1.0
Received: by 10.182.159.41 with SMTP id wz9mr13759348obb.69.1334033950934; Mon, 09 Apr 2012 21:59:10 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Mon, 9 Apr 2012 21:59:10 -0700 (PDT)
In-Reply-To: <4F832F5E.9030903@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net>
Date: Tue, 10 Apr 2012 00:59:10 -0400
X-Google-Sender-Auth: uJVQJ9W_HRLVn57atFNG5YoK38c
Message-ID: <CAL9jLaa5J9iJ_EBGQDr3mOG4eHoNvu4t_NERFxoF-UCB4rgLTg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, "Murphy, Sandra" <Sandra.Murphy@sparta.com>, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 04:59:12 -0000

On Mon, Apr 9, 2012 at 2:50 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Hi,
>
>> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
>
>
> I do not understand. How a BGP Update will transit via an AS where each
> router is a real BGP speaker and where as some proposed BGP mandatory
> AS_PATH attribute is not present ?

The last sentence, it doesn't parse quite clearly for me... could you
re-state it?

>
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP tunnel
> ASBR to ASBR as transport ? Even in this case ASBRs are connected directly
> or indirectly (RRs) via IBGP.

no assumption was made of this sort.

> As you proposing to remove AS_PATH selection criteria from best path for
> updates which come over IBGP ? What happens if you need to compare paths

no

> received over EBGP and IBGP on a given BGP speaker ?

I think what you want is actually sort of discussed in:
<http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-protocol-02#section-4>

-chris

From morrowc@ops-netman.net  Tue Apr 10 08:26:31 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33111E80F1; Tue, 10 Apr 2012 08:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-5MBnOu4Yjr; Tue, 10 Apr 2012 08:26:30 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 9517711E80DF; Tue, 10 Apr 2012 08:26:29 -0700 (PDT)
Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 4524D3202D1; Tue, 10 Apr 2012 15:26:27 +0000 (UTC)
Message-ID: <4F845123.60803@ops-netman.net>
Date: Tue, 10 Apr 2012 11:26:27 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>,  sidr wg <sidr@ietf.org>, sidr-ads@tools.ietf.org
References: <4F844D15.90402@ops-netman.net>
In-Reply-To: <4F844D15.90402@ops-netman.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 15:26:31 -0000

(bcc: iesg-secretary)

SIDR folk,

A draft agenda for the April 30, 2012 meeting is below:

0900-1200 deployment discussion (walkthrough/document/discuss deployment
   scenarios)

1300-1600 o router/prefix/roa/crl - rpki repository data freshness

1600-1700 prefix validate discussion

This will also appear (shortly) at:
  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
  (sidr wiki page)

-Chris
<co-chair>
(if the iesg-secretary folk have no action here... then I'll NOT add
them in the future)

From warren@kumari.net  Tue Apr 10 09:07:09 2012
Return-Path: <warren@kumari.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9A721F85FD; Tue, 10 Apr 2012 09:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pZ1IskKCj52; Tue, 10 Apr 2012 09:07:08 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id C27E621F85F9; Tue, 10 Apr 2012 09:07:08 -0700 (PDT)
Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id CFF9A1B40018; Tue, 10 Apr 2012 12:07:07 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <4F832F5E.9030903@raszuk.net>
Date: Tue, 10 Apr 2012 12:07:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net>
To: "sidr@ietf.org list" <sidr@ietf.org>
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 16:07:09 -0000

On Apr 9, 2012, at 2:50 PM, Robert Raszuk wrote:

> Hi,
>=20
>> And intradomain BGP speakers do not use bgpsec (ebgp sessions only).
>=20
> I do not understand. How a BGP Update will transit via an AS where =
each router is a real BGP speaker and where as some proposed BGP =
mandatory AS_PATH attribute is not present ?


I must admit I'm having a hard time parsing the question. I'll take a =
stab though... This answer may be unrelated to what you are asking...

When an update leaves a BGPSEC speaker destined for a "legacy" speaker =
the BGPSEC bits are removed

>=20
> Are you assuming each AS today is BGP Free with full mesh of MPLS/IP =
tunnel ASBR to ASBR as transport ? Even in this case ASBRs are connected =
directly or indirectly (RRs) via IBGP.

Nope, not assuming that at all. The devices on the edge of the AS (those =
that do eBGP) need to speak BGPSEC, and if the AS is small, they will =
probably be in a full mesh. If the AS is not small (or has planned ahead =
:-)) they will talk to a RR or be part of a confed. If they talk through =
a RR (or set of RRs), these should also speak BGPSEC. If you prefer the =
confed flavor of scaling, well, the devices on the edge of the confed =
are kinda like eBGP speakers, and inside the confed they all mesh (or =
talk through a RR (see previous :-)))

>=20
> As you proposing to remove AS_PATH selection criteria from best path =
for updates which come over IBGP ?

Goodness, no....


> What happens if you need to compare paths received over EBGP and IBGP =
on a given BGP speaker ?
>=20
> Many thx,
> R.
>=20

P.S: Crossposting left in, as it seems like that is what was wanted, =
but....

> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>=20


From robert@raszuk.net  Tue Apr 10 09:34:43 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D664C11E812A for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 09:34:43 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izTkwhIyy7D2 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 09:34:43 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id AA0B111E8129 for <sidr@ietf.org>; Tue, 10 Apr 2012 09:34:42 -0700 (PDT)
Received: (qmail 21358 invoked by uid 399); 10 Apr 2012 16:34:42 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 16:34:42 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F846121.2050408@raszuk.net>
Date: Tue, 10 Apr 2012 18:34:41 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: sidr@ietf.org, "idr@ietf.org List" <idr@ietf.org>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov>, <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net>
In-Reply-To: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sidr] No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 16:34:44 -0000

Hi Warren,

Many thx for your comment. It clarifies my question very well.

So you are effectively confirming that as long as there is one ASBR, one 
RR or one confederation edge which does not yet speak BGPSEC anywhere in 
the UPDATE path the peer sending to him over ebgp or ibgp will convert 
BGP_SIGNED_PATH to AS_PATH/AS4_PATH attributes and from now on that path 
will remain unsigned.

Likewise each RR/confed peer will need to convert BGP_SIGNED_PATH to set 
of AS_PATH/AS4_PATH attributes when sending to "legacy" BGP speakers.

I do not know what is the rationale for recommendation of not sending 
mandatory BGP attributes any longer even if their content could be 
already contained with new BGP_SIGNED_PATH attribute.

Anyhow my doubt has been answered and I stay by my opinion that not 
sending AS_PATH and AS4_PATH is a terrible idea.

Perhaps one could depreciate it in 20 years when world is upgraded to 
BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not 
helpful for any even potential BGPSEC deployment model.

Best regards,
R.


> Nope, not assuming that at all. The devices on the edge of the AS
> (those that do eBGP) need to speak BGPSEC, and if the AS is small,
> they will probably be in a full mesh. If the AS is not small (or has
> planned ahead :-)) they will talk to a RR or be part of a confed. If
> they talk through a RR (or set of RRs), these should also speak
> BGPSEC. If you prefer the confed flavor of scaling, well, the devices
> on the edge of the confed are kinda like eBGP speakers, and inside
> the confed they all mesh (or talk through a RR (see previous :-)))


From christopher.morrow@gmail.com  Tue Apr 10 09:53:04 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464F621F8661; Tue, 10 Apr 2012 09:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqodVhTnhPuP; Tue, 10 Apr 2012 09:53:01 -0700 (PDT)
Received: from mail-yw0-f52.google.com (mail-yw0-f52.google.com [209.85.213.52]) by ietfa.amsl.com (Postfix) with ESMTP id 920E821F8684; Tue, 10 Apr 2012 09:52:59 -0700 (PDT)
Received: by yhpp61 with SMTP id p61so2388946yhp.25 for <multiple recipients>; Tue, 10 Apr 2012 09:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UduqRddfpLr69NErUcQy3z7+FsvHQAP3D4UEUAkJ7YY=; b=wTbczWO+zQKLMaEq3YGz6ZiKYqVKP/SsWTqVBq7lWWJad6Wzz/ED6c2nVC3/FdFFUV p0zX9IGbWnDRTY403Af3Z2TTX38HyQeXMcFthHMHB+G8FtvqFlXD/ks4sn/Rauqi0Ykd WxvMLnc138JwJOE12FEQ1zdPN7LhlNjpYtRLWIC87x5di1vLGvECY5L1yH2AJjjXdsgg Pkz6TZMH/MSZNoNrwbJODLJ3cYu1esps5oyGszb0XCHM8ogkNRWM5xoHsYO/8GFuRuHD gkNGBllAa44Os1DqjAHWOiC/69nlDDjbiie8mO+xnqGXKwbUH+H0sJRaLNuvc7OYYxgd r3cg==
MIME-Version: 1.0
Received: by 10.60.24.201 with SMTP id w9mr16750567oef.49.1334076777708; Tue, 10 Apr 2012 09:52:57 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 09:52:57 -0700 (PDT)
In-Reply-To: <4F846121.2050408@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net>
Date: Tue, 10 Apr 2012 12:52:57 -0400
X-Google-Sender-Auth: GgUjAXP7ezF2eMb3pb8xanU6NFo
Message-ID: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 16:53:04 -0000

On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net> wrote:
> Anyhow my doubt has been answered and I stay by my opinion that not sending
> AS_PATH and AS4_PATH is a terrible idea.

So... we can send the data along, but in the case of BGPSEC speakers
the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
Carrying extra bits isn't actually helpful is it? (the implementers
drove the design decision here I believe)

> Perhaps one could depreciate it in 20 years when world is upgraded to
> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
> helpful for any even potential BGPSEC deployment model.

is it helpful for the folks that write bgp code though? "Hey, you will
need to re-synthesize the as-path at sec->non-sec boundaries. you need
to also create sec-path at none->sec boundaries."

-chris

From robert@raszuk.net  Tue Apr 10 10:00:39 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D203011E8102 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:00:39 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcUtESGrAsVj for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:00:39 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1701A11E80F3 for <sidr@ietf.org>; Tue, 10 Apr 2012 10:00:39 -0700 (PDT)
Received: (qmail 31084 invoked by uid 399); 10 Apr 2012 17:00:38 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:00:38 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F846736.2060604@raszuk.net>
Date: Tue, 10 Apr 2012 19:00:38 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Christopher Morrow <morrowc.lists@gmail.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:00:40 -0000

 > So... we can send the data along, but in the case of BGPSEC speakers
 > the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

So far I have always heard that BGPSEC is just providing the hint to the 
operator and does not change how BGP works.

Here you are saying that now AS_PATH length should be calculated from 
completely different (and optional) attribute.

You are also saying that now multipath code which computes which path 
are eligible to be multipath needs to look/parse/decrypt totally 
different attribute.

All BGP monitoring tools need to be upgraded to now understand BGPSEC 
attribute too. And surprise .. here BMP will not convert it like it will 
to "legacy" speakers.

You may think that if we stuff all "data" in the new attribute and drop 
the other one everything else will work. This may be so in theory, but 
it is clearly not a case in practice.

Regards,
R.


> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<robert@raszuk.net>  wrote:
>> Anyhow my doubt has been answered and I stay by my opinion that not sending
>> AS_PATH and AS4_PATH is a terrible idea.
>
> So... we can send the data along, but in the case of BGPSEC speakers
> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> Carrying extra bits isn't actually helpful is it? (the implementers
> drove the design decision here I believe)
>
>> Perhaps one could depreciate it in 20 years when world is upgraded to
>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
>> helpful for any even potential BGPSEC deployment model.
>
> is it helpful for the folks that write bgp code though? "Hey, you will
> need to re-synthesize the as-path at sec->non-sec boundaries. you need
> to also create sec-path at none->sec boundaries."
>
> -chris
>
>


From warren@kumari.net  Tue Apr 10 10:37:38 2012
Return-Path: <warren@kumari.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37221F866D; Tue, 10 Apr 2012 10:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pktSovE8s6J; Tue, 10 Apr 2012 10:37:38 -0700 (PDT)
Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id E499221F866B; Tue, 10 Apr 2012 10:37:37 -0700 (PDT)
Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id AB4391B402FA; Tue, 10 Apr 2012 13:37:36 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
Date: Tue, 10 Apr 2012 13:37:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1084)
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:37:38 -0000

On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:

> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net> =
wrote:
>> Anyhow my doubt has been answered and I stay by my opinion that not =
sending
>> AS_PATH and AS4_PATH is a terrible idea.
>=20
> So... we can send the data along, but in the case of BGPSEC speakers
> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> Carrying extra bits isn't actually helpful is it? (the implementers
> drove the design decision here I believe)

I think that sone of the biggest issues to keep in mind with carrying =
the "same" data in two places is what to do when you suddenly discover =
that they are not actually the same?

There has been much good work in IDR to better handle bugs / =
implementations issues, and these considerations probably had much to do =
with this...

For example, I'm a BGPSEC speaker. In the BGPSEC bits I see:

AS1 AS2 AS3 AS4 AS5  All this checks out, the magic crypto says all is =
happy, etc.
but, in the AS_PATH I see:
AS1 AS 100 AS17 AS6

What do I do here? Do I a: drop the update or b: ignore the issue or c: =
reset the session or d: prefer the singed or unsigned or e: nasal =
demons? =20
Someone who's opinion I really respect once said: Never test for an =
error condition you don't know how to handle.

This idea extends this by simply not allowing the error condition to =
occur.

You have all of the information to recreate the AS_PATH / AS4_PATH when =
you leave a BGPSEC domain, and because it is only in one place, you =
sidestep all sorts of weird error corner cases...

W


>=20
>> Perhaps one could depreciate it in 20 years when world is upgraded to
>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO =
not
>> helpful for any even potential BGPSEC deployment model.
>=20
> is it helpful for the folks that write bgp code though? "Hey, you will
> need to re-synthesize the as-path at sec->non-sec boundaries. you need
> to also create sec-path at none->sec boundaries."
>=20
> -chris
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>=20


From dougm@nist.gov  Tue Apr 10 10:42:52 2012
Return-Path: <dougm@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0D21F86E8; Tue, 10 Apr 2012 10:42:52 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQz79bWQ8W6D; Tue, 10 Apr 2012 10:42:51 -0700 (PDT)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id AC26321F86E4; Tue, 10 Apr 2012 10:42:51 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Apr 2012 13:42:35 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 10 Apr 2012 13:42:50 -0400
From: "Montgomery, Douglas" <dougm@nist.gov>
To: Warren Kumari <warren@kumari.net>, Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 10 Apr 2012 13:42:47 -0400
Thread-Topic: [sidr] [Idr]  No BGPSEC intradomain ?
Thread-Index: Ac0XQTaVmbg3QKfCRI6aryVBbFegkg==
Message-ID: <CBA9E89F.A697E%dougm@nist.gov>
In-Reply-To: <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.10.0.110310
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:42:52 -0000

On 4/10/12 1:37 PM, "Warren Kumari" <warren@kumari.net> wrote:

>
>On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:
>
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net>
>>wrote:
>>> Anyhow my doubt has been answered and I stay by my opinion that not
>>>sending
>>> AS_PATH and AS4_PATH is a terrible idea.
>> 
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>
>I think that sone of the biggest issues to keep in mind with carrying the
>"same" data in two places is what to do when you suddenly discover that
>they are not actually the same?

Do the same thing you do when you find that the that a PATH_SIG SKI points
to a CERT for an ASN that does not match the ASN in the PATH_SIG.

Proceed from there ... Problem is no different... The data meant to
validate the PATH, does not match the PATH.
Dougm


From christopher.morrow@gmail.com  Tue Apr 10 10:47:42 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9119D21F860D; Tue, 10 Apr 2012 10:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.299
X-Spam-Level: 
X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2n-IBLSlahd; Tue, 10 Apr 2012 10:47:42 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E510E21F85D4; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so42186yhk.31 for <multiple recipients>; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cBnrA/Wo6JIm9UjLbxhntEM57Seu6uN3YCHKKGUGkp8=; b=Ry+2fyXX3i3NghZTpncbbFLRHWHV/6nggINkRezL/EKShs7Fhkxx1cm8Ng+U3w8kGm V5oa6o4lwckyV3/HLRwGQ/nG3cMnnUuAQWLHdKG47Wr3bxc3V0j+220FOEjY3NNXemoE ZjXsqdZ/14WQZNZdwTtuCcSr6Ol3vVELYSgt7rwablWyQRUsB6YwLe1dfL5r5peDtleC Y8rM2lI0UzpPTPPAKgFRVLoRipaumgzsrFs+2pmOkwHKOVJqKWm2dcP7C6boVGXeHQix EoTiiG9C5a9wupfxsqqqChPT3zsAUFN4TKqLlFvVDZBuTmAxXzvUaIWKGvPnSyV1pSrL Bplw==
MIME-Version: 1.0
Received: by 10.60.24.201 with SMTP id w9mr17022206oef.49.1334080061340; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 10:47:41 -0700 (PDT)
In-Reply-To: <4F846736.2060604@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <4F846736.2060604@raszuk.net>
Date: Tue, 10 Apr 2012 13:47:41 -0400
X-Google-Sender-Auth: 07VGFi-0uDlgB4aozWUDOSBeoh8
Message-ID: <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:47:42 -0000

On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>
> So far I have always heard that BGPSEC is just providing the hint to the
> operator and does not change how BGP works.

ok.

> Here you are saying that now AS_PATH length should be calculated from
> completely different (and optional) attribute.

to the operator (and the implementation) there's not a difference....

> You are also saying that now multipath code which computes which path are
> eligible to be multipath needs to look/parse/decrypt totally different
> attribute.

I didn't say anything about multipath. I presume it'd do the right
thing with the meta-attribute it knows about way deep inside bgp
processing on platforms that do bgp processing.

> All BGP monitoring tools need to be upgraded to now understand BGPSEC
> attribute too. And surprise .. here BMP will not convert it like it will =
to
> "legacy" speakers.

sure, they'd have to do that anyway, or they just are
'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
other words, tomorrow for them is the same as today, the world keeps
on going round.

> You may think that if we stuff all "data" in the new attribute and drop t=
he
> other one everything else will work. This may be so in theory, but it is
> clearly not a case in practice.

maybe? so far you've not convinced me... you can feel free to keep
trying though? email is cheap.

>
> Regards,
> R.
>
>
>
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<robert@raszuk.net> =A0wr=
ote:
>>>
>>> Anyhow my doubt has been answered and I stay by my opinion that not
>>> sending
>>> AS_PATH and AS4_PATH is a terrible idea.
>>
>>
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>>
>>> Perhaps one could depreciate it in 20 years when world is upgraded to
>>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
>>> helpful for any even potential BGPSEC deployment model.
>>
>>
>> is it helpful for the folks that write bgp code though? "Hey, you will
>> need to re-synthesize the as-path at sec->non-sec boundaries. you need
>> to also create sec-path at none->sec boundaries."
>>
>> -chris
>>
>>
>

From robert@raszuk.net  Tue Apr 10 10:49:27 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4893911E80F4 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:49:27 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAxrMfmDBud3 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:49:26 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 70CEB21F86F1 for <sidr@ietf.org>; Tue, 10 Apr 2012 10:49:26 -0700 (PDT)
Received: (qmail 12845 invoked by uid 399); 10 Apr 2012 17:49:25 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:robert@raszuk.net@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:49:25 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F8472A5.5000700@raszuk.net>
Date: Tue, 10 Apr 2012 19:49:25 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Warren Kumari <warren@kumari.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
In-Reply-To: <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]    No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:49:27 -0000

Hi Warren,

Not seeing the problem/error does not mean it is not there.

I would in fact encourage in the initial years of deployment to use both 
to easily detect bugs and inconsistency issues.

In my view we should do all BGP processing based on "legacy" attributes 
and BGPSEC should be a hint to the local operator on how to treat the 
update.

Actually I am of the opinion (I think similar to some research voices in 
US) that secured BGP (or for that matter even origin validation) should 
be handled by few BGP Route Controllers providing AS based overlay 
certificate processing rather then by each individual BGP speaker in the 
network. BGP should be able to transport it as purely opaque information 
which could after automatic detection be used as best path 
decision/preference factor in a given AS.

Regards,
R.


> On Apr 10, 2012, at 12:52 PM, Christopher Morrow wrote:
>
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk<robert@raszuk.net>  wrote:
>>> Anyhow my doubt has been answered and I stay by my opinion that not sending
>>> AS_PATH and AS4_PATH is a terrible idea.
>>
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>
> I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?
>
> There has been much good work in IDR to better handle bugs / implementations issues, and these considerations probably had much to do with this...
>
> For example, I'm a BGPSEC speaker. In the BGPSEC bits I see:
>
> AS1 AS2 AS3 AS4 AS5  All this checks out, the magic crypto says all is happy, etc.
> but, in the AS_PATH I see:
> AS1 AS 100 AS17 AS6
>
> What do I do here? Do I a: drop the update or b: ignore the issue or c: reset the session or d: prefer the singed or unsigned or e: nasal demons?
> Someone who's opinion I really respect once said: Never test for an error condition you don't know how to handle.
>
> This idea extends this by simply not allowing the error condition to occur.
>
> You have all of the information to recreate the AS_PATH / AS4_PATH when you leave a BGPSEC domain, and because it is only in one place, you sidestep all sorts of weird error corner cases...
>
> W
>
>
>>
>>> Perhaps one could depreciate it in 20 years when world is upgraded to
>>> BGPSEC, but recommending this in BGPSEC protocol draft now is IMHO not
>>> helpful for any even potential BGPSEC deployment model.
>>
>> is it helpful for the folks that write bgp code though? "Hey, you will
>> need to re-synthesize the as-path at sec->non-sec boundaries. you need
>> to also create sec-path at none->sec boundaries."
>>
>> -chris
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>


From robert@raszuk.net  Tue Apr 10 10:57:47 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F127B11E810C for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69VGsjQzfMOn for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 10:57:46 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5AE11E8103 for <sidr@ietf.org>; Tue, 10 Apr 2012 10:57:46 -0700 (PDT)
Received: (qmail 26923 invoked by uid 399); 10 Apr 2012 17:57:45 -0000
Received: from unknown (HELO ?192.168.1.57?) (pbs:m42@mojaklasa.info@83.31.51.142) by mail1310.opentransfer.com with ESMTPM; 10 Apr 2012 17:57:45 -0000
X-Originating-IP: 83.31.51.142
Message-ID: <4F847499.9040105@raszuk.net>
Date: Tue, 10 Apr 2012 19:57:45 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Christopher Morrow <morrowc.lists@gmail.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <4F846736.2060604@raszuk.net> <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
In-Reply-To: <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 17:57:47 -0000

>> All BGP monitoring tools need to be upgraded to now understand BGPSEC
>> attribute too. And surprise .. here BMP will not convert it like it will to
>> "legacy" speakers.
>
> sure, they'd have to do that anyway, or they just are
> 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
> other words, tomorrow for them is the same as today, the world keeps
> on going round.

No. You are breaking things. BMP is not ibgp nor it is ebgp ! The 
station which works today and get's BGP sessions over BMP will now be 
useless as AS_PATH will not be there.

I assumed you know, but BMP idea is to replay what you are receiving (as 
verbatim as implementation allows).

> maybe? so far you've not convinced me... you can feel free to keep
> trying though? email is cheap.

I am not sure there is point in "convincing". Removing mandatory path 
attribute from BGP would be something IDR WG has to formally approve. 
And it will be an interesting precedence in any case ;)

Cheers,
R.




From jakob.heitz@ericsson.com  Tue Apr 10 11:22:32 2012
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F311E80D9; Tue, 10 Apr 2012 11:22:32 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b2rU8Rf8wjk; Tue, 10 Apr 2012 11:22:31 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 01BD111E80B8; Tue, 10 Apr 2012 11:22:30 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3AIMA24028002; Tue, 10 Apr 2012 13:22:28 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 14:22:26 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, "robert@raszuk.net" <robert@raszuk.net>
Date: Tue, 10 Apr 2012 14:22:25 -0400
Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ?
Thread-Index: Ac0XOnGsHWavn2A9Q7i3S2WmYqcpNwACgtBQ
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 18:22:32 -0000

On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote:

> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net>
> wrote:=20
>> Anyhow my doubt has been answered and I stay by my opinion that not
>> sending AS_PATH and AS4_PATH is a terrible idea.
>=20
> So... we can send the data along, but in the case of BGPSEC speakers
> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
> Carrying extra bits isn't actually helpful is it? (the implementers
> drove the design decision here I believe)

I think it was along the lines of:
2 AS paths will create the opportunity for an error if they differ
and we don't want to go around the error-handling block again.

I agree with Robert. Today, there are many tools that interact
with BGP messages. If the AS_PATH disappears, they will all break.

--=20
Jakob Heitz.=

From alexb@ripe.net  Tue Apr 10 11:59:10 2012
Return-Path: <alexb@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554FF11E812F for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 11:59:10 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XZVpybANttf for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 11:59:09 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 66B9411E80F2 for <sidr@ietf.org>; Tue, 10 Apr 2012 11:59:09 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <alexb@ripe.net>) id 1SHgHT-0005ym-DI for sidr@ietf.org; Tue, 10 Apr 2012 20:59:08 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-70.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from <alexb@ripe.net>) id 1SHgHT-0005yo-9H for sidr@ietf.org; Tue, 10 Apr 2012 20:59:07 +0200
From: Alex Band <alexb@ripe.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_611F7FE4-8262-4BB6-8131-46AADDC4A4CE"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Tue, 10 Apr 2012 20:59:06 +0200
Message-Id: <A3B56E55-1A10-4304-8561-A51D9260BAEB@ripe.net>
To: sidr@ietf.org
Mime-Version: 1.0 (Apple Message framework v1257)
X-Mailer: Apple Mail (2.1257)
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: ddd0bbf11d1e21354000f5f053f5ae697bef3aea1e194107d0b460a0da8d098a
Subject: [sidr] New RIPE NCC RPKI Validator released
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 18:59:10 -0000

--Apple-Mail=_611F7FE4-8262-4BB6-8131-46AADDC4A4CE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

We just released a new version of our relying party software, RIPE NCC =
RPKI Validator 2.0.4:
=
http://www.ripe.net/lir-services/resource-management/certification/tools-a=
nd-resources

We improved the way errors and warnings are displayed, they now have a =
separate page with (hopefully) clear explanations.=20
Also, we improved the rsync data fetching reliability. If a trust anchor =
is unavailable momentarily or for prolonged periods of time, the tool =
will now reschedule fetching as needed.=20

We would really like you to try it out and report back on the stability =
and reliability from different parts of the world, especially when =
running it for longer periods of time.

As always, the Validator requires no configuration and has no =
dependencies other than Java 1.6 and rsync available on your system.=20
Simply download, unzip and run ./bin/rpki-validator from the base =
directory and browse to http://localhost:8080

Cheers and thanks,

Alex=

--Apple-Mail=_611F7FE4-8262-4BB6-8131-46AADDC4A4CE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGgDCCBnww
ggVkoAMCAQICChKdl94AAAAAAFswDQYJKoZIhvcNAQEFBQAwYDETMBEGCgmSJomT8ixkARkWA25l
dDEUMBIGCgmSJomT8ixkARkWBHJpcGUxFjAUBgoJkiaJk/IsZAEZFgZzaW5nZWwxGzAZBgNVBAMT
EnNpbmdlbC1DSEFLT1RBWS1DQTAeFw0xMTEyMTMyMTA5MzhaFw0xMjEyMTIyMTA5MzhaMIGcMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRQwEgYKCZImiZPyLGQBGRYEcmlwZTEWMBQGCgmSJomT8ixkARkW
BnNpbmdlbDERMA8GA1UECxMIYWNjb3VudHMxETAPBgNVBAsTCFRyYWluaW5nMRIwEAYDVQQDEwlB
bGV4IEJhbmQxHTAbBgkqhkiG9w0BCQEWDmFsZXhiQHJpcGUubmV0MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDEPiQlF+TQYCvPJ8cVUc5MTbdE5KuQhIH1kM/YDCjpT5WG/RmPThZjsSI9+9ks
W96XNTOwYR5QIkoFb3B66x5H5KfjdI663R9EUA5h0UDla5vnELCyBeDKSxRx+ikmPHEvv0McZTyX
OrJ6sECyQ4NpVKIn8ATB8MLzlKG8w8WcRQIDAQABo4IDfTCCA3kwFwYJKwYBBAGCNxQCBAoeCABV
AHMAZQByMB0GA1UdDgQWBBR9//WoWoR6weYwP9Sxkl3PNJTmFjAOBgNVHQ8BAf8EBAMCBaAwHwYD
VR0jBBgwFoAUcUDZm8Q8qhTSJLIBxWByJ++A64AwggEgBgNVHR8EggEXMIIBEzCCAQ+gggELoIIB
B4aBwWxkYXA6Ly8vQ049c2luZ2VsLUNIQUtPVEFZLUNBLENOPWNoYWtvdGF5LENOPUNEUCxDTj1Q
dWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXNp
bmdlbCxEQz1yaXBlLERDPW5ldD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0
Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGQWh0dHA6Ly9jaGFrb3RheS5zaW5nZWwucmlwZS5u
ZXQvQ2VydEVucm9sbC9zaW5nZWwtQ0hBS09UQVktQ0EuY3JsMIIBNQYIKwYBBQUHAQEEggEnMIIB
IzCBuAYIKwYBBQUHMAKGgatsZGFwOi8vL0NOPXNpbmdlbC1DSEFLT1RBWS1DQSxDTj1BSUEsQ049
UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1z
aW5nZWwsREM9cmlwZSxEQz1uZXQ/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRp
ZmljYXRpb25BdXRob3JpdHkwZgYIKwYBBQUHMAKGWmh0dHA6Ly9jaGFrb3RheS5zaW5nZWwucmlw
ZS5uZXQvQ2VydEVucm9sbC9jaGFrb3RheS5zaW5nZWwucmlwZS5uZXRfc2luZ2VsLUNIQUtPVEFZ
LUNBLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYDVR0R
BDkwN6AlBgorBgEEAYI3FAIDoBcMFWFsZXhiQHNpbmdlbC5yaXBlLm5ldIEOYWxleGJAcmlwZS5u
ZXQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsO
AwIHMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4IBAQAGOufDj5XGO0zZMii/HBsEGTypqDoV
THQwLtzZcofpTHPjgxVkzKEF6xcVflRA/XktZfpMP4/H9xGzRRIYT/ociFeScJBA1vwG1ZP2lKA/
92To0hn9RiPPBEpZMv3cVOsQlVwkrzyY/3yo6K9KuduY5MCzeLrVmYk9m6EONO6HUe5E0fmnNoeT
kJfter/8DuUjvRxWIbpNf4fW/xJWnWm4+qhT1zYut+60w5t8vZQ8OxA1nOrIiJDFqwzArrRFZCa0
B5waOV3rlxrJdAnE8nmPVPgwJnjEIxc/kkFxVjPX/jWtMAmtXUzKLbHYwLbmB8Y/1QyXJNtngY1I
XVnYlukeMYICdTCCAnECAQEwbjBgMRMwEQYKCZImiZPyLGQBGRYDbmV0MRQwEgYKCZImiZPyLGQB
GRYEcmlwZTEWMBQGCgmSJomT8ixkARkWBnNpbmdlbDEbMBkGA1UEAxMSc2luZ2VsLUNIQUtPVEFZ
LUNBAgoSnZfeAAAAAABbMAkGBSsOAwIaBQCgggFdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw
HAYJKoZIhvcNAQkFMQ8XDTEyMDQxMDE4NTkwN1owIwYJKoZIhvcNAQkEMRYEFDkhbWjn0XKq2aOY
rBqU34UEh5WlMH0GCSsGAQQBgjcQBDFwMG4wYDETMBEGCgmSJomT8ixkARkWA25ldDEUMBIGCgmS
JomT8ixkARkWBHJpcGUxFjAUBgoJkiaJk/IsZAEZFgZzaW5nZWwxGzAZBgNVBAMTEnNpbmdlbC1D
SEFLT1RBWS1DQQIKEp2X3gAAAAAAWzB/BgsqhkiG9w0BCRACCzFwoG4wYDETMBEGCgmSJomT8ixk
ARkWA25ldDEUMBIGCgmSJomT8ixkARkWBHJpcGUxFjAUBgoJkiaJk/IsZAEZFgZzaW5nZWwxGzAZ
BgNVBAMTEnNpbmdlbC1DSEFLT1RBWS1DQQIKEp2X3gAAAAAAWzANBgkqhkiG9w0BAQEFAASBgA4c
bWwtvb1SUqHejQXmXVFM1qwMccA3XC6eQ+x8wne4kNH1w6gcyripgAKUKS+QmMMfbW1WgTDlPkIz
IiNVNELHFmRBKWBeCykm5spq4RbBi49ZZZBiH1UMgQ5wYPUGekEQQ7Us6zS5+SB6j9ZqUyFpL6ql
pq/5rJJGpzSnUsqeAAAAAAAA

--Apple-Mail=_611F7FE4-8262-4BB6-8131-46AADDC4A4CE--

From christopher.morrow@gmail.com  Tue Apr 10 13:56:55 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768EC21F860D; Tue, 10 Apr 2012 13:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level: 
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgA6Y97dBAc6; Tue, 10 Apr 2012 13:56:54 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9902B21F85AF; Tue, 10 Apr 2012 13:56:54 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so291481obb.31 for <multiple recipients>; Tue, 10 Apr 2012 13:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fElM47FuFncv6UBiXHR3Dj4MgwXLI0iRMX2mQKu3mmk=; b=ixWH8J8mQXxc5Q72zIElcdkLTLuRNmllZ02BDN7oworjjoMfkAMAXGKu4ACvaHkgWe 1gEwWVV9gmVnFp5vVMrnKqswTY+49dyRRVuaN2Khxwn0svGDoS05hfVeOaSJmBFtTkz0 YkZwBXW8U2rTRb6JKxXEKZKyOggrg2N4OotoksXf4wNpu4kjiVM4vj4IBZHLsaB63vJA ejkD61q2njEMf3oh7/DPkmYyRNIkEmrGUsolCurPkSADCwy66DLRs71oQWWjHTelzumx PuPQhQXAaXy8C2RwUAL9pKq7wd5ZDN1CqGEBFX1j8kRkeGUEv7SgKltJwOk8LxWJjI2F gXAg==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr18335719obp.49.1334091414230; Tue, 10 Apr 2012 13:56:54 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 13:56:54 -0700 (PDT)
In-Reply-To: <4F8472A5.5000700@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <4F8472A5.5000700@raszuk.net>
Date: Tue, 10 Apr 2012 16:56:54 -0400
X-Google-Sender-Auth: j6ngf-_FLcXWGSJxXO0unxwQWi4
Message-ID: <CAL9jLaYFqPLeedxycM_OmACJ+fa1_4AuY4hY_-6pueWs2w4prQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 20:56:55 -0000

On Tue, Apr 10, 2012 at 1:49 PM, Robert Raszuk <robert@raszuk.net> wrote:
> In my view we should do all BGP processing based on "legacy" attributes and
> BGPSEC should be a hint to the local operator on how to treat the update.

i think that's the point of the current spec though... inbound updates
(on BGPSEC capable bgp sessions) which include BGPSEC information get
validated by the local router and 'colored' by route-map/policy as the
operator sees fit.
  route-map in-cust permit 10
    match bgpsec valid
    add community 2914:valid

this is the functionality you are asking for, yes?

From christopher.morrow@gmail.com  Tue Apr 10 14:04:35 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485A311E8154; Tue, 10 Apr 2012 14:04:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.239
X-Spam-Level: 
X-Spam-Status: No, score=-103.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b1EXNzWDUZd; Tue, 10 Apr 2012 14:04:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D606C11E8149; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so299308obb.31 for <multiple recipients>; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XyCcvNNjWVn0i12Aadq51jNhmVDwqGmlC960LF2KPMo=; b=HAPzioIanN0ippIjbqRpAlYnOuVWVK8XMdjd8mvLHVgtU/J/Rq1i6sH0nHmGX8nMYg x564Ssx67swdiFcFKTUu+BBhVpXaPNazVaBOhzL+iqEEmEzGypt1Lg/qPVQTZYGLnPL2 NRJ07oK4SyirQXzZQRXQxjDlf7le/7iDH65ROZ2pRUjTKzhmMvokOfB8xqBiSAKGwlEJ X7UxZLSjOau7SIg3e8d9iQjX8xQdO4pVDOECmf/cOhCCERgtoBObkCVwkR/kVk3uhmnO 9jQ7zMF3EvfZv8LGOghOF/C4xupV+Kjzz40GqdFw4fFAZn7/WeV7ZZ22gCpIKs5BOZBd K3Lg==
MIME-Version: 1.0
Received: by 10.182.74.4 with SMTP id p4mr11080644obv.79.1334091829513; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:03:49 -0700 (PDT)
In-Reply-To: <4F847499.9040105@raszuk.net>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <4F846736.2060604@raszuk.net> <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com> <4F847499.9040105@raszuk.net>
Date: Tue, 10 Apr 2012 17:03:49 -0400
X-Google-Sender-Auth: FqFpbysZ4c5069eYSxJ9q-eg_SU
Message-ID: <CAL9jLabH9OZEfFoitONOZ36wDW6V3_Vd8ubKQzt3KiDLG3eAew@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: robert@raszuk.net
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 21:04:36 -0000

On Tue, Apr 10, 2012 at 1:57 PM, Robert Raszuk <robert@raszuk.net> wrote:
>
>>> All BGP monitoring tools need to be upgraded to now understand BGPSEC
>>> attribute too. And surprise .. here BMP will not convert it like it will
>>> to
>>> "legacy" speakers.
>>
>>
>> sure, they'd have to do that anyway, or they just are
>> 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
>> other words, tomorrow for them is the same as today, the world keeps
>> on going round.
>
>
> No. You are breaking things. BMP is not ibgp nor it is ebgp ! The station
> which works today and get's BGP sessions over BMP will now be useless as
> AS_PATH will not be there.

great, so ... bmp can either:
  1) be treated as a non-BGPSEC speaker (synthesize on the output to
bmp listener)
  2) be updated to include the BGPSEC relevant data in payload

downstream tools using the BMP stream(s) of course would have to be
updated. This doesn't seem like a huge deal though, and certainly is
expected.

> I assumed you know, but BMP idea is to replay what you are receiving (as
> verbatim as implementation allows).

sure, so it has to know about new bits/pieces, nothing new here. If
you catch larry you might get this change/addition into his
final/final version before rfc-editor cuts the rfc.

>
>> maybe? so far you've not convinced me... you can feel free to keep
>> trying though? email is cheap.
>
>
> I am not sure there is point in "convincing". Removing mandatory path
> attribute from BGP would be something IDR WG has to formally approve. And it
> will be an interesting precedence in any case ;)

sure... once things settle out on the SIDR side, I'm positive we'll
have this discussion in IDR. You seem to be working through the
machinations of 'how do I deploy bgpsec in a network', is that the
case? would you be willing to document/presentation-style (or wiki or
...) the process for this? It seems like something other folks are
going to want to reference/use/discuss as well, so having a few worked
examples would be nice.

-chris

From christopher.morrow@gmail.com  Tue Apr 10 14:05:07 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587DB11E8154; Tue, 10 Apr 2012 14:05:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.499
X-Spam-Level: 
X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ6T9ysqvlqr; Tue, 10 Apr 2012 14:05:06 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46111E814B; Tue, 10 Apr 2012 14:05:01 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so300604obb.31 for <multiple recipients>; Tue, 10 Apr 2012 14:05:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pc3SLTC8lbIAIiJBVG86JKWNtWQoMima21Vve0j5x68=; b=DlaUX5A7Q+eA/90XIrSxQ1UqZoCH3YW+YCV336AAmbPvpFHmb3Qq4ImC6NTenoSqkq u5EbDOOCSlH3LVK6+0xi4j9vGuPoo1RF9M1Jv4jTMVRK5eHevDw9/BdaMdTPFhKVd8Jy IjcQ5/VaA8nuEuqvLJsJI4AaCxAZEnVTFmnGAQ+sYzn8wiG8WEZKa5GkSqHVrLNk/BsR HdLc6jjPMryuxe+y0dSegUUzE29puoHQUvDezkz95knf1Sz7v47i9XSko+ygGns89Pgq TvfOvQX61i2q0wcImpuNyq397CS0q0IqjpuibHPsHCCOax3BP5uAWUH9h5LGELy4t00R fAEQ==
MIME-Version: 1.0
Received: by 10.182.159.41 with SMTP id wz9mr17995065obb.69.1334091900958; Tue, 10 Apr 2012 14:05:00 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 14:05:00 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se>
Date: Tue, 10 Apr 2012 17:05:00 -0400
X-Google-Sender-Auth: RkJR20gO2KACrvNk4MCNaJqaQPQ
Message-ID: <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 21:05:07 -0000

On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote:
>
>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net>
>> wrote:
>>> Anyhow my doubt has been answered and I stay by my opinion that not
>>> sending AS_PATH and AS4_PATH is a terrible idea.
>>
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)
>
> I think it was along the lines of:
> 2 AS paths will create the opportunity for an error if they differ
> and we don't want to go around the error-handling block again.
>
> I agree with Robert. Today, there are many tools that interact
> with BGP messages. If the AS_PATH disappears, they will all break.

aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker.
If the tools in question are updated to understand BGPSEC (and
negotiate that capability with the bgp speaker) then ... they'd
obviously have to know how to deal with this situation, right?

-chris

From jakob.heitz@ericsson.com  Tue Apr 10 14:51:37 2012
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90111E80DF; Tue, 10 Apr 2012 14:51:36 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k31aGmiBXMZQ; Tue, 10 Apr 2012 14:51:35 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB7811E80D2; Tue, 10 Apr 2012 14:51:35 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3ALpV3l009585; Tue, 10 Apr 2012 16:51:32 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 10 Apr 2012 17:51:26 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 10 Apr 2012 17:51:24 -0400
Thread-Topic: [Idr] [sidr] No BGPSEC intradomain ?
Thread-Index: Ac0XXpPBlalJJAgKTW6BRADxpxuq2gABNbSg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
In-Reply-To: <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 21:51:37 -0000

On Tuesday, April 10, 2012 2:05 PM, Christopher Morrow <> wrote:

> On Tue, Apr 10, 2012 at 2:22 PM, Jakob Heitz
> <jakob.heitz@ericsson.com> wrote:=20
>> On Tuesday, April 10, 2012 9:53 AM, Christopher Morrow <> wrote:
>>=20
>>> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net>
>>> wrote:
>>>> Anyhow my doubt has been answered and I stay by my opinion that not
>>>> sending AS_PATH and AS4_PATH is a terrible idea.
>>>=20
>>> So... we can send the data along, but in the case of BGPSEC speakers
>>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).
>>> Carrying extra bits isn't actually helpful is it? (the implementers
>>> drove the design decision here I believe)
>>=20
>> I think it was along the lines of:
>> 2 AS paths will create the opportunity for an error if they differ
>> and we don't want to go around the error-handling block again.
>>=20
>> I agree with Robert. Today, there are many tools that interact
>> with BGP messages. If the AS_PATH disappears, they will all break.
>=20
> aspath doesn't disappear if I'm only speaking to a non-BGPSEC speaker.
> If the tools in question are updated to understand BGPSEC (and
> negotiate that capability with the bgp speaker) then ... they'd
> obviously have to know how to deal with this situation, right?
>=20
> -chris

This will be a hurdle on the way to adoption.
I can see the network operator now: "My tools won't run. Let's
not turn BGPSEC on today".

The error-checking excuse looks real lame to me.

--=20
Jakob Heitz.=

From randy@psg.com  Tue Apr 10 16:20:37 2012
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACE721F85DD; Tue, 10 Apr 2012 16:20:37 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anKx0xWEgiGl; Tue, 10 Apr 2012 16:20:36 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 85C4321F85BB; Tue, 10 Apr 2012 16:20:36 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SHkMT-000E0s-WC; Tue, 10 Apr 2012 23:20:34 +0000
Date: Wed, 11 Apr 2012 08:20:32 +0900
Message-ID: <m2wr5nuqbj.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.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: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 23:20:37 -0000

> On Tue, Apr 10, 2012 at 12:34 PM, Robert Raszuk <robert@raszuk.net> wrote:
>> So... we can send the data along, but in the case of BGPSEC speakers
>> the data isn't used (it's replicated in the BGPSEC_SIGNED_PATH).

it might help if the poster actually read the drafts

>> Carrying extra bits isn't actually helpful is it? (the implementers
>> drove the design decision here I believe)

this is considered a feature, not a bug

randy

From randy@psg.com  Tue Apr 10 16:22:25 2012
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0821F8630; Tue, 10 Apr 2012 16:22:25 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnBn2ILaV+aV; Tue, 10 Apr 2012 16:22:24 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A40C521F862F; Tue, 10 Apr 2012 16:22:24 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SHkOE-000E1S-1i; Tue, 10 Apr 2012 23:22:22 +0000
Date: Wed, 11 Apr 2012 08:22:20 +0900
Message-ID: <m2vcl7uq8j.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se>
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: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Apr 2012 23:22:25 -0000

> I can see the network operator now: "My tools won't run. Let's
> not turn BGPSEC on today".

perhaps a good implementation will present the bgpsec as-path to the
operator in the traditional manner?

randy

From danny@tcb.net  Tue Apr 10 17:48:20 2012
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD7521F8565 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 17:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.134
X-Spam-Level: 
X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQA7RiX43Svb for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 17:48:19 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 8B91221F8564 for <sidr@ietf.org>; Tue, 10 Apr 2012 17:48:19 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 264C1268063; Tue, 10 Apr 2012 18:48:19 -0600 (MDT)
Received: from new-host.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 10 Apr 2012 18:48:19 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=62841; syn-fingerprint=65535:49:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <4F845123.60803@ops-netman.net>
Date: Tue, 10 Apr 2012 20:48:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net>
To: Chris Morrow <morrowc@ops-netman.net>
X-Mailer: Apple Mail (2.1257)
Cc: sidr-ads@tools.ietf.org, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 00:48:20 -0000

Chris,=20
Can you expand on these, I'm not sure I know what to read or propose in =
order to prepare.. =20

Also, are we collecting requirements for these (e.g., object scale, RPs, =
etc..)?  Basing these discussions on requirements that exist somewhere =
already?  Or simply discussing solutions that have already been =
developed and deployment experience?  If the latter, then we can we =
ensure we reference and prepare to discuss what requirements drive to =
the development of those solutions?

Also, it looks to me like we're in dire need of a charter update...

-danny

On Apr 10, 2012, at 11:26 AM, Chris Morrow wrote:

> (bcc: iesg-secretary)
>=20
> SIDR folk,
>=20
> A draft agenda for the April 30, 2012 meeting is below:
>=20
> 0900-1200 deployment discussion (walkthrough/document/discuss =
deployment
>   scenarios)
>=20
> 1300-1600 o router/prefix/roa/crl - rpki repository data freshness
>=20
> 1600-1700 prefix validate discussion
>=20
> This will also appear (shortly) at:
>  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>  (sidr wiki page)
>=20
> -Chris
> <co-chair>
> (if the iesg-secretary folk have no action here... then I'll NOT add
> them in the future)
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


From christopher.morrow@gmail.com  Tue Apr 10 17:56:26 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D015211E813E for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 17:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.513
X-Spam-Level: 
X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWTOSk6Vtcn7 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 17:56:26 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEE2B11E8081 for <sidr@ietf.org>; Tue, 10 Apr 2012 17:56:25 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so568602obb.31 for <sidr@ietf.org>; Tue, 10 Apr 2012 17:56:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fC34jYiftZgC8kXxcWlpWbThoJJ3+g5GdM7gfY90FIU=; b=Dhaw9EeYD1lLMuPU71C6vtTcQfr16tJpGgcPP0gDvBut1srz1X9M9E9+ykKUp/ZGR7 yYMbkwHcwq/xNjURBDqnZZxuUPMhb1FbN+Kdwnh0clWcRp+SuAb/aXjCeAw4o025hIP1 27pYCFbE2UcyDV1JN240JzR1jvr/5/RYNrlmhWut7siF93un9zWM4bv9+KiMCaPj8YLI cANURbbATpieWRi+sYdu/kcy7sGW+pQI6SK45uYQtd7FaTWYqiDzzAIoy2vD0HHmk5fJ OvBslXNWnSPO6i9uSaKwbKc5Vl6t8fua+Cam3DQ9ZAGAK5S6EYZapbTxZheuRdc58DgS DtoA==
MIME-Version: 1.0
Received: by 10.182.52.104 with SMTP id s8mr18787733obo.59.1334105785499; Tue, 10 Apr 2012 17:56:25 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Tue, 10 Apr 2012 17:56:25 -0700 (PDT)
In-Reply-To: <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net>
Date: Tue, 10 Apr 2012 20:56:25 -0400
X-Google-Sender-Auth: HVNAZLferFDORnnKEFRdpC968Ms
Message-ID: <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr wg <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 00:56:26 -0000

On Tue, Apr 10, 2012 at 8:48 PM, Danny McPherson <danny@tcb.net> wrote:
>
> Chris,
> Can you expand on these, I'm not sure I know what to read or propose in o=
rder to prepare..

yes, my goal was to have updated the wiki today at the office, work
intruded... tomorrow I'll do that with some more content for each
item, and hopefully better coordinates as well for the location.

>
> Also, are we collecting requirements for these (e.g., object scale, RPs, =
etc..)? =A0Basing these discussions on requirements that exist somewhere al=
ready? =A0Or simply discussing solutions that have already been developed a=
nd deployment experience? =A0If the latter, then we can we ensure we refere=
nce and prepare to discuss what requirements drive to the development of th=
ose solutions?
>

I think the only bit in the 3 that has a current 'requirements'
discussion is the 'freshness' (item 2). The first item 'deployment
discussion' is really a discussion of:
  "Should there be some document that describes the top N (3?)
deployment scenarios && where should that document/presentation/etc
live?" (I suppose implicit in that is 'requirements for format,
content, intended audience')

> Also, it looks to me like we're in dire need of a charter update...

for which? (I didn't think that any of the 3 items was actually
outside of the current charter)

-chris

> -danny
>
> On Apr 10, 2012, at 11:26 AM, Chris Morrow wrote:
>
>> (bcc: iesg-secretary)
>>
>> SIDR folk,
>>
>> A draft agenda for the April 30, 2012 meeting is below:
>>
>> 0900-1200 deployment discussion (walkthrough/document/discuss deployment
>> =A0 scenarios)
>>
>> 1300-1600 o router/prefix/roa/crl - rpki repository data freshness
>>
>> 1600-1700 prefix validate discussion
>>
>> This will also appear (shortly) at:
>> =A0<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>> =A0(sidr wiki page)
>>
>> -Chris
>> <co-chair>
>> (if the iesg-secretary folk have no action here... then I'll NOT add
>> them in the future)
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

From danny@tcb.net  Tue Apr 10 18:16:00 2012
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DC011E8139 for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 18:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.989
X-Spam-Level: 
X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fELrmtPz+sLl for <sidr@ietfa.amsl.com>; Tue, 10 Apr 2012 18:16:00 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 7789F11E811A for <sidr@ietf.org>; Tue, 10 Apr 2012 18:16:00 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 48232268063; Tue, 10 Apr 2012 19:16:00 -0600 (MDT)
Received: from new-host.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 10 Apr 2012 19:16:00 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=63754; syn-fingerprint=65535:49:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com>
Date: Tue, 10 Apr 2012 21:15:44 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 01:16:01 -0000

On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:

> yes, my goal was to have updated the wiki today at the office, work
> intruded... tomorrow I'll do that with some more content for each
> item, and hopefully better coordinates as well for the location.

Thanks.

>> Also, are we collecting requirements for these (e.g., object scale, =
RPs, etc..)?  Basing these discussions on requirements that exist =
somewhere already?  Or simply discussing solutions that have already =
been developed and deployment experience?  If the latter, then we can we =
ensure we reference and prepare to discuss what requirements drive to =
the development of those solutions?
>>=20
>=20
> I think the only bit in the 3 that has a current 'requirements'
> discussion is the 'freshness' (item 2). The first item 'deployment
> discussion' is really a discussion of:
>  "Should there be some document that describes the top N (3?)
> deployment scenarios && where should that document/presentation/etc
> live?" (I suppose implicit in that is 'requirements for format,
> content, intended audience')

I was thinking more simply along the lines of "a fully deployed RPKI =
today would have o objects and r RPs a c churn and we ought to ensure =
our designs accommodate that" -- only then can we have a reasonable =
discussion on, e.g., data freshness?  What have we based these design =
goals on thus far - do we have a stable reference for this?

=46rom there, we can discuss the issue of, for example, HOW TO onboard =
and purge signing and validating certificates to routers from the RPKI =
-- [I suspect the intention was to use rpki-rtr protocol for this, but =
it doesn't currently support it, nor are the security implications =
clear]. =20

Only when we get to that point will we really begin to understand the =
dynamics of RPKI and it's employment for secure routing (well beyond =
"authorized" origin policy configuration), and the impact of rate+state =
in both the RPKI and it's effectuating in the routing system, and =
perhaps most importantly, the inter-dependencies between the two (even =
basic stuff like the rate of updates from an RPKI cache to a router in a =
fully loaded system given today's RPKI object counts).

>> Also, it looks to me like we're in dire need of a charter update...
>=20
> for which? (I didn't think that any of the 3 items was actually
> outside of the current charter)

I meant the goals and milestones, apologies for not being clear.

-danny=

From robert@raszuk.net  Wed Apr 11 00:25:33 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CEA21F85D7 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 00:25:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.528
X-Spam-Level: 
X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9Iuoav5h2Km for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 00:25:33 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id ED50321F85D4 for <sidr@ietf.org>; Wed, 11 Apr 2012 00:25:32 -0700 (PDT)
Received: (qmail 30968 invoked by uid 399); 11 Apr 2012 07:25:32 -0000
Received: from unknown (HELO ?192.168.1.55?) (pbs:robert@raszuk.net@83.9.118.191) by mail1310.opentransfer.com with ESMTPM; 11 Apr 2012 07:25:32 -0000
X-Originating-IP: 83.9.118.191
Message-ID: <4F8531F5.7010805@raszuk.net>
Date: Wed, 11 Apr 2012 09:25:41 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: Jakob Heitz <jakob.heitz@ericsson.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaaOOTURBUQsMSW6HRwu+j9r3f6MKLYMoPvS4WXNt9jdgA@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE04140@EUSAACMS0701.eamcs.ericsson.se> <m2vcl7uq8j.wl%randy@psg.com>
In-Reply-To: <m2vcl7uq8j.wl%randy@psg.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 07:25:33 -0000

On 4/11/2012 1:22 AM, Randy Bush wrote:
>> I can see the network operator now: "My tools won't run. Let's
>> not turn BGPSEC on today".
>
> perhaps a good implementation will present the bgpsec as-path to the
> operator in the traditional manner?
>
> randy

perhaps it would be great if poster would recognize that we are no 
longer in the screen scraping era, and got familiar with BMP draft.

r.


From aservin@lacnic.net  Wed Apr 11 02:09:37 2012
Return-Path: <aservin@lacnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F7121F86DC for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 02:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level: 
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWCTVxWBwIfu for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 02:09:36 -0700 (PDT)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3821F85A2 for <sidr@ietf.org>; Wed, 11 Apr 2012 02:09:35 -0700 (PDT)
Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.70]) by mail.lacnic.net.uy (Postfix) with ESMTP id 7D75C30845F; Wed, 11 Apr 2012 06:09:21 -0300 (UYT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Arturo Servin <aservin@lacnic.net>
In-Reply-To: <4F845123.60803@ops-netman.net>
Date: Wed, 11 Apr 2012 11:09:15 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <95B27602-208A-4CA1-8A0D-92A8D5341FFD@lacnic.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net>
To: Chris Morrow <morrowc@ops-netman.net>
X-Mailer: Apple Mail (2.1257)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck: 
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
Cc: sidr-ads@tools.ietf.org, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 09:09:37 -0000

	May be is somewhere and I could not find it, but, what is the timezone?

Thanks!
.as

On 10 Apr 2012, at 17:26, Chris Morrow wrote:

> (bcc: iesg-secretary)
> 
> SIDR folk,
> 
> A draft agenda for the April 30, 2012 meeting is below:
> 
> 0900-1200 deployment discussion (walkthrough/document/discuss deployment
>   scenarios)
> 
> 1300-1600 o router/prefix/roa/crl - rpki repository data freshness
> 
> 1600-1700 prefix validate discussion
> 
> This will also appear (shortly) at:
>  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>  (sidr wiki page)
> 
> -Chris
> <co-chair>
> (if the iesg-secretary folk have no action here... then I'll NOT add
> them in the future)
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


From christopher.morrow@gmail.com  Wed Apr 11 06:36:10 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C793C21F85FF for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 06:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.524
X-Spam-Level: 
X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k17YGIbot90V for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 06:36:10 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09721F85FD for <sidr@ietf.org>; Wed, 11 Apr 2012 06:36:10 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1449717obb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 06:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=90eQ9fP4v2GJ1KyzPaYab5oLfBWWQyF9hehr4twsKQE=; b=lacVJ7/YpdVPlsutXxrXsSnyHJQ4D6G5pG4gcdJtGSZjpFOxBRr5n4oGooNI/jRqiR anGR4u8Wg3F/wqrop12N957ajQXJaMg9YIzhSiB/U6JZLNk3DUAN9T8Lev0qhVPz/zyF xI27dr9T0tkx5HoHLPhk0KWYqssRgy3LiFmzL/E64Nbu8KAJtVHQsz81DL9/NWwOBTlf zYYR6iN7Vy5xt/qlfWi3sK5CDXprQwr4l8G/htTbzc70BsyvSNMiFeMdVqF/Dnc4hPx9 USwTjzVDaZE1vG8Uxd9iqPcmJWYZ8wdQCS5TMTRNKL8d9hiA/dAbAW83/07TwfVhO/JX kAdg==
MIME-Version: 1.0
Received: by 10.60.22.138 with SMTP id d10mr2418752oef.69.1334151369705; Wed, 11 Apr 2012 06:36:09 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 06:36:09 -0700 (PDT)
In-Reply-To: <95B27602-208A-4CA1-8A0D-92A8D5341FFD@lacnic.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <95B27602-208A-4CA1-8A0D-92A8D5341FFD@lacnic.net>
Date: Wed, 11 Apr 2012 09:36:09 -0400
X-Google-Sender-Auth: BtFMeXmRvOysEmu2B34bFBDA99E
Message-ID: <CAL9jLaaMx8hp_1yTMHeqYXaN++LVVPLeUiyMdhndyoKODfZq0A@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Arturo Servin <aservin@lacnic.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr wg <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 13:36:10 -0000

On Wed, Apr 11, 2012 at 5:09 AM, Arturo Servin <aservin@lacnic.net> wrote:
>
> =A0 =A0 =A0 =A0May be is somewhere and I could not find it, but, what is =
the timezone?
>

wait, not everyone is in Hawaii time? :)

EDT is the TZ, I should have added that, it IS on the wiki page now.

thanks!
-chris

> Thanks!
> .as
>
> On 10 Apr 2012, at 17:26, Chris Morrow wrote:
>
>> (bcc: iesg-secretary)
>>
>> SIDR folk,
>>
>> A draft agenda for the April 30, 2012 meeting is below:
>>
>> 0900-1200 deployment discussion (walkthrough/document/discuss deployment
>> =A0 scenarios)
>>
>> 1300-1600 o router/prefix/roa/crl - rpki repository data freshness
>>
>> 1600-1700 prefix validate discussion
>>
>> This will also appear (shortly) at:
>> =A0<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>> =A0(sidr wiki page)
>>
>> -Chris
>> <co-chair>
>> (if the iesg-secretary folk have no action here... then I'll NOT add
>> them in the future)
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

From paul@jakma.org  Wed Apr 11 07:12:15 2012
Return-Path: <paul@jakma.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9521F8584 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 07:12:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuwhpnzJdz42 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 07:12:13 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6234721F84B9 for <sidr@ietf.org>; Wed, 11 Apr 2012 07:12:13 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so3875864wib.13 for <sidr@ietf.org>; Wed, 11 Apr 2012 07:12:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:x-x-sender:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version:content-type:x-gm-message-state; bh=CKGanJvoWtC7L9hg13kYwnMgGXwv69duiC13Zbn/0kU=; b=edbHru1/rjLplzs8Nm1Gl1ZKer8WuUb818lhUjmV21+Yvvs7n9QTGaMZoKYkSVvQ9C fVtsQYv4gLBEVcBnXCGiri4JvDr2slldfMwu5g0uBv9N2i51O14mbk1LpCWf38lYY9FP AKLuSFTfd4vQJnUEMyBFxzFSYybb5nh4GB/3/Ib1/EOCjyTRJTxVtlbu/nvNNMqGEigd i67TTyJRjAuMxojsv7YI/YqMCaVYiPcmtZb1Hg3z8pgl4TjcSQu0+Bjb69yIHIhkyMWv 4SxdIfJH9Un/2+UKJ39zgREB2Lk2780fsf8ptIFKOfXtJ+swGgJK9FBUrIf0euUUeRY4 xr9A==
Received: by 10.216.145.209 with SMTP id p59mr8985334wej.50.1334153532577; Wed, 11 Apr 2012 07:12:12 -0700 (PDT)
Received: from jamaica.dcs.gla.ac.uk (jamaica.dcs.gla.ac.uk. [130.209.244.4]) by mx.google.com with ESMTPS id fz9sm45180121wib.3.2012.04.11.07.12.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 07:12:09 -0700 (PDT)
Date: Wed, 11 Apr 2012 15:12:08 +0100 (BST)
From: Paul Jakma <paul@jakma.org>
X-X-Sender: paul@jamaica.dcs.gla.ac.uk
To: Jakob Heitz <jakob.heitz@ericsson.com>
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se>
Message-ID: <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Gm-Message-State: ALoCoQk1iK4SwIIFoy70qBajDhXgbexfR5gQdMXKZvwwpZd+nyiJmDiDxgS3M3EJSarDhju2HrhK
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 14:12:15 -0000

On Tue, 10 Apr 2012, Jakob Heitz wrote:

> I agree with Robert. Today, there are many tools that interact with BGP 
> messages. If the AS_PATH disappears, they will all break.

Indeed. If mandatory, well-known attributes are removed, then the BGP 
protocol version number needs to be bumped.

There's near-0-cost in doing that for those interested in implementing the 
new functionality, and it avoids a world of hurt for all the various tools 
(sometimes in-house/home-grown) out there that believe they know what 
they're getting when the version says 4.

regards,
-- 
Paul Jakma  paul@jakma.org  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
Genius may have its limitations, but stupidity is not thus handicapped.
 		-- Elbert Hubbard

From jhaas@slice.pfrc.org  Wed Apr 11 07:20:54 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666BA11E809C; Wed, 11 Apr 2012 07:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.215
X-Spam-Level: 
X-Spam-Status: No, score=-101.215 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhdU2jfulXh; Wed, 11 Apr 2012 07:20:53 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BC85521F8584; Wed, 11 Apr 2012 07:20:53 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 15CDD1703D7; Wed, 11 Apr 2012 10:20:53 -0400 (EDT)
Date: Wed, 11 Apr 2012 10:20:53 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Warren Kumari <warren@kumari.net>
Message-ID: <20120411142053.GA1283@slice>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 14:20:54 -0000

I'm not at my usual spot in the week to catch up on IETF mail, but this
thread is noisy enough that it's caught my attention anyway. :-)

On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote:
> I think that sone of the biggest issues to keep in mind with carrying the "same" data in two places is what to do when you suddenly discover that they are not actually the same?

The apparent issue in this thread is basically, "what happens to AS_PATH?"
Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not thoroughly reading
it), there's commentary about what should be done with the AS_PATH.  That
commentary is mostly correct in the sense that all of the path loop
detection is already present.  (And the mostly is important.)  

IMO, there are two specific issues with regard to removing the AS_PATH and
one with keeping it.

1. What do you do about confederations?  These ASes are not only typically
internal but would have to use some sort of internal certs if we decided to
cover the confederation case.  Additionally, the current encoding format
doesn't include AS_PATH segment type as part of the signature.  

Note in particular that confederation segments MUST be stripped when
crossing an eBGP boundary.

2. More generally, what do you do about incremental deployment *within* the
AS?  One presumption I've been working on that I *thought* was shared by the
WG was that BGPSEC procedures only had to be done at eBGP edges.  While this
is primarily true for signature validation purposes, a desired side effect
of having the signature as a optional,transitive that paralleled the AS_PATH
was that iBGP speakers don't have to even be BGPSEC aware.  This lets you
upgrade your network from the outside first and get benefit.

As John Scudder likes to say, "a hard, crunchy shell". :-)

IMO, we should keep the AS_PATH.

3. Which brings us to the third point - what do we do when the signature and
the AS_PATH disagree with each other?  Note that this was also a problem for
4-byte ASes (RFC 4893).  That spec chose to simply trust the 4-byte path
beyond a certain point.  (I don't necessarily agree with it, but that's what
consensus was.)  Exactly what we do here needs to be specified, and some of
that specification will come from deciding what we want to do about some things.

For example, we want to prevent the path from being shortened.  As long as
the ASes involved in both signature and path are congruent, we can use the
length in the signature if the number of ASes in the path are shorter than
the signature.

In the case where the paths are still congruent but the AS_PATH has a longer
prepend (see my ingress prepending use case from a few sessions back), it
may be fine to use the AS_PATH (and its length for route selection
purposes).  Yes, I understand there isn't consensus here.

In the case where the paths are not congruent (which shouldn't happen unlike
the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across other BGP), we
probably have some sort of hard error case.  One reasonable assumption is
that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP speaker
doing path manipulations for policy.  IMO, the proper behavior here is to
*not* propagate the route at a BGPSEC ASBR boundary; any BGP speaker that
manipulates the AS_PATH in such a way as to break the congruency of ASes
between AS_PATH and signature MUST be a BGPSEC speaker.

The above still doesn't deal with common deployment considerations such as
as-override, replace-as and remove-private.  I see there's a thread about
proxy signing and perhaps that discussion is over there.  I'll hopefully get
to it in a few days.

(And if you're not familiar with those three features and their deployment
scenarios, please take some time to become familiar.  Not dealing with them
will be a significant deployment hurdle.)

-- Jeff


From christopher.morrow@gmail.com  Wed Apr 11 08:22:41 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21E821F8565; Wed, 11 Apr 2012 08:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.532
X-Spam-Level: 
X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6QfyogJ6jql; Wed, 11 Apr 2012 08:22:40 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 340F221F8564; Wed, 11 Apr 2012 08:22:40 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so572925ghb.31 for <multiple recipients>; Wed, 11 Apr 2012 08:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Cjty43SZKN9D/BGuS/UdOIRdSnjEXRRYQv0Atn3IDSQ=; b=pCGyERgCMuKcizXjIbXtgqv3WZ5DQqQtnKgZAiOONKRFYaTCSjQ+5J5K6vb2fkZI/y tZBZ+1CpBtUis+QzPYQ0LfXiqLTJgvPBaVo78JVFPk5OqQIXfg1Ls2nXypjVtmnuOSgf XfEjxOi3o8Lk3qT9ug86UVmsZO2ePkiGZfKEtv933ZFV0/erYYHK32o69T3oSGOVbazP IbynM11ulClGEskVIiN8hIV1Wb/TglN/b886J7Mcubz4faa0Xpzt8X1afkyegvbzFgK1 SwIj2Kp0n7Fpqtj6GQNiRisoXKXOrJwWKJSNIyVEFtpWtw9Fnl0r8XgU5sPxgESbjhET yOiw==
MIME-Version: 1.0
Received: by 10.60.22.138 with SMTP id d10mr3059397oef.69.1334157759726; Wed, 11 Apr 2012 08:22:39 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 08:22:39 -0700 (PDT)
In-Reply-To: <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk>
Date: Wed, 11 Apr 2012 11:22:39 -0400
X-Google-Sender-Auth: 0A1hMHoSzC92RA-AWvo3URoOZ6Y
Message-ID: <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Paul Jakma <paul@jakma.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 15:22:41 -0000

On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma <paul@jakma.org> wrote:
> On Tue, 10 Apr 2012, Jakob Heitz wrote:
>
>> I agree with Robert. Today, there are many tools that interact with BGP
>> messages. If the AS_PATH disappears, they will all break.
>
>
> Indeed. If mandatory, well-known attributes are removed, then the BGP
> protocol version number needs to be bumped.
>
> There's near-0-cost in doing that for those interested in implementing the
> new functionality, and it avoids a world of hurt for all the various tools
> (sometimes in-house/home-grown) out there that believe they know what
> they're getting when the version says 4.

"if you don't ask for the 'bgpsec capability' then ... you get what
you get today."

also

"if you ask for the 'bgpsec capabiltiy' then ... you get (and can
presumably handle) the changes"

so, everything you do today, ought to just keep right on working, or
that's the plan.

From jakob.heitz@ericsson.com  Wed Apr 11 09:17:47 2012
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07A311E8083; Wed, 11 Apr 2012 09:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.2
X-Spam-Level: 
X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.400,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK9+If0m5X38; Wed, 11 Apr 2012 09:17:46 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 25EDC11E8074; Wed, 11 Apr 2012 09:17:46 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q3BGHhSj008408; Wed, 11 Apr 2012 11:17:45 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 11 Apr 2012 12:17:41 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Warren Kumari <warren@kumari.net>
Date: Wed, 11 Apr 2012 12:17:40 -0400
Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
Thread-Index: Ac0X7mp45WFSp501Qb+tTgo50fNyTwADu/SQ
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice>
In-Reply-To: <20120411142053.GA1283@slice>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 16:17:47 -0000

Confeds are out of scope.

VPN address families are out of scope.

If the BGPSEC path does not match the AS_PATH, the update
is invalid.

The validity of an update is used as an input to route selection.
If you have been replace/override/removing ASNs, you are free to
use that information in route selection too.

IOW, the BGPSEC validity of an update does not necessarily
prevent you from using the update if you have inside knowledge
about AS path mucking. How you use the BGPSEC validity in
your route selection is a private matter.

On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:

> I'm not at my usual spot in the week to catch up on IETF mail, but
> this=20
> thread is noisy enough that it's caught my attention anyway. :-)
>=20
> On Tue, Apr 10, 2012 at 01:37:34PM -0400, Warren Kumari wrote:
>> I think that sone of the biggest issues to keep in mind with
>> carrying the "same" data in two places is what to do when you
>> suddenly discover that they are not actually the same? =20
>=20
> The apparent issue in this thread is basically, "what happens to
> AS_PATH?" Glancing at draft-ietf-sidr-bgpsec-protocol-02 (and not
> thoroughly reading=20
> it), there's commentary about what should be done with the AS_PATH.=20
> That commentary is mostly correct in the sense that all of the path
> loop=20
> detection is already present.  (And the mostly is important.)
>=20
> IMO, there are two specific issues with regard to removing the
> AS_PATH and=20
> one with keeping it.
>=20
> 1. What do you do about confederations?  These ASes are not only
> typically internal but would have to use some sort of internal certs
> if we decided to cover the confederation case.  Additionally, the
> current encoding format doesn't include AS_PATH segment type as part
> of the signature.=20
>=20
> Note in particular that confederation segments MUST be stripped when
> crossing an eBGP boundary.
>=20
> 2. More generally, what do you do about incremental deployment
> *within* the=20
> AS?  One presumption I've been working on that I *thought* was shared
> by the=20
> WG was that BGPSEC procedures only had to be done at eBGP edges.=20
> While this=20
> is primarily true for signature validation purposes, a desired side
> effect=20
> of having the signature as a optional,transitive that paralleled the
> AS_PATH was that iBGP speakers don't have to even be BGPSEC aware.=20
> This lets you upgrade your network from the outside first and get
> benefit.=20
>=20
> As John Scudder likes to say, "a hard, crunchy shell". :-)
>=20
> IMO, we should keep the AS_PATH.
>=20
> 3. Which brings us to the third point - what do we do when the
> signature and the AS_PATH disagree with each other?  Note that this
> was also a problem for 4-byte ASes (RFC 4893).  That spec chose to
> simply trust the 4-byte path=20
> beyond a certain point.  (I don't necessarily agree with it, but
> that's what consensus was.)  Exactly what we do here needs to be
> specified, and some of that specification will come from deciding
> what we want to do about some things.=20
>=20
> For example, we want to prevent the path from being shortened.  As
> long as=20
> the ASes involved in both signature and path are congruent, we can
> use the length in the signature if the number of ASes in the path are
> shorter than=20
> the signature.
>=20
> In the case where the paths are still congruent but the AS_PATH has a
> longer prepend (see my ingress prepending use case from a few
> sessions back), it=20
> may be fine to use the AS_PATH (and its length for route selection
> purposes).  Yes, I understand there isn't consensus here.
>=20
> In the case where the paths are not congruent (which shouldn't happen
> unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across
> other BGP), we probably have some sort of hard error case.  One
> reasonable assumption is=20
> that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP
> speaker doing path manipulations for policy.  IMO, the proper
> behavior here is to *not* propagate the route at a BGPSEC ASBR
> boundary; any BGP speaker that manipulates the AS_PATH in such a way
> as to break the congruency of ASes between AS_PATH and signature MUST
> be a BGPSEC speaker.=20
>=20
> The above still doesn't deal with common deployment considerations
> such as as-override, replace-as and remove-private.  I see there's a
> thread about=20
> proxy signing and perhaps that discussion is over there.  I'll
> hopefully get=20
> to it in a few days.
>=20
> (And if you're not familiar with those three features and their
> deployment scenarios, please take some time to become familiar.  Not
> dealing with them will be a significant deployment hurdle.)
>=20
> -- Jeff

--=20
Jakob Heitz.=

From christopher.morrow@gmail.com  Wed Apr 11 09:28:33 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD18721F8593; Wed, 11 Apr 2012 09:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.139
X-Spam-Level: 
X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r7LTCFjecVF; Wed, 11 Apr 2012 09:28:33 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4E21F8547; Wed, 11 Apr 2012 09:28:33 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1654283obb.31 for <multiple recipients>; Wed, 11 Apr 2012 09:28:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=N8UNhmj6U9DlOJtoltE8HaCjvzXuXR+prNCujyh5JBA=; b=M8Lnm72CXn/wZi12YnwBdAoliTXcXIGlDWJU4xgy0hucmu1TLkdzKz91Vdbdh21+gL iw6d/PA3DsQGpjdmouc4KtfL3K3vznJVCgnbWDB80UPjJWrCD3dVTOq/S5hIAX4nJlCw TGiTW4vf/i2mLtjHX3itQo2Yo+EML2KnMHrypRKr+8GvSrqZEqZNY+cleQHZKUKnX2+C Rq9l3EZtdCNj8G8T9t3FXaGtmpd4RdAaWZNC/VtmJQiQbrsHzG+lZ253sP7uI8aAjUAN 11BgwcbCeusG8EAjVwNu0DkoGSpjXGdiXld3OuxFfHL7s1bnpAlmVJ+mS5UCKSszWu10 F0pg==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr20797593obp.49.1334161712752; Wed, 11 Apr 2012 09:28:32 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 09:28:32 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
Date: Wed, 11 Apr 2012 12:28:32 -0400
X-Google-Sender-Auth: yGCbaCBHjo8XcEXtaTjHEamy0Dg
Message-ID: <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 16:28:33 -0000

On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
> Confeds are out of scope.

how are confeds out of scope?
if you want path validation for ibgp/originated-by-you routes and the
originating router is in one of the confed sub-ases you have that
router sign with the confed-external/public asn, no? I'm fairly
certain we planned to support this sort of activity... though I could
be missing the part which is out-of-scope?

> IOW, the BGPSEC validity of an update does not necessarily
> prevent you from using the update if you have inside knowledge
> about AS path mucking. How you use the BGPSEC validity in
> your route selection is a private matter.

yes, which is, I think, nice.

From brian.peter.dickson@gmail.com  Wed Apr 11 09:41:01 2012
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C47D11E809A; Wed, 11 Apr 2012 09:41:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level: 
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvweNEz+lYTy; Wed, 11 Apr 2012 09:41:00 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42911E8089; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so727435wgb.13 for <multiple recipients>; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ic4sarfmTwxzIqasiM4WyQ3ROK/JqUSaHXk1gq1/I2g=; b=YT+cMSaCx/7E7YKalpUIAOdJ5pirfaTQ9tVcfLS7WjQ2GFmYAHlXEapK27hQD/FxEW 1YjPYRg2kfCCGrZEpMapIT85+6fFL4vSLmvyLFKDIjmcuczFUwKam+ZO0/pSQbdWBHe8 mc5hGcu0tigs4zMVpWuE3Sq2BJlTbz7tZPAdNeGFkyxmiepaO5vyW8VXr1zcRvNuDAYN LLU+5FOfYxQpMq34lXeJtXgmKZoBv+mUHuz0g4lZBPLt6dsDisBbjzP9WcjPocH9pwwc XAjgWVmrtYKwckNqRMrtTAumS2gZkeJRANKCQMIgRO432bOGpUz0x1ZnDBkhDgWHHdle yXsw==
MIME-Version: 1.0
Received: by 10.216.132.6 with SMTP id n6mr9578669wei.26.1334162459060; Wed, 11 Apr 2012 09:40:59 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Wed, 11 Apr 2012 09:40:58 -0700 (PDT)
In-Reply-To: <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <4F846736.2060604@raszuk.net> <CAL9jLaa4d+teV0xwgtMVfVfAKK89AwWkk3OQxGaT_sw6psuDiQ@mail.gmail.com>
Date: Wed, 11 Apr 2012 12:40:58 -0400
Message-ID: <CAH1iCirzcsbaLihcogSNJJHLi-1fsx3PX9-gp=O94=U6w9z5Vw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary=0016e6d784fd71e86704bd69e7f5
Cc: "idr@ietf.org List" <idr@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 16:41:01 -0000

--0016e6d784fd71e86704bd69e7f5
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 10, 2012 at 1:47 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk <robert@raszuk.net> wrote:
>


> > All BGP monitoring tools need to be upgraded to now understand BGPSEC
> > attribute too. And surprise .. here BMP will not convert it like it will
> to
> > "legacy" speakers.
>
> sure, they'd have to do that anyway, or they just are
> 'non-bgpsec-speakers' (an e|ibgp neighbour without security foo). In
> other words, tomorrow for them is the same as today, the world keeps
> on going round.
>
> > You may think that if we stuff all "data" in the new attribute and drop
> the
> > other one everything else will work. This may be so in theory, but it is
> > clearly not a case in practice.
>
> maybe? so far you've not convinced me... you can feel free to keep
> trying though? email is cheap.
>
>
Okay, I'll bite...

Suppose someone wants to take an existing tool which speaks BGP, and writes
out full tables and updates to files. Call it "bgpmon". :-)

The obvious thing to do for that tool, would be for it to advertise that it
speaks BGPSEC, and record the updates that come from BGPSEC speakers.

Clearly, this tool is not a router, nor does it need to do validation. In
fact, you *don't* want to validate, since you want to record all updates,
*including* invalid updates.

The ability to do quick-and-dirty comparisons between BGP-vanilla and
BGPSEC data, from archived data, would be significantly hampered if the
AS_PATH had to be reconstructed from this data.

Duplicate bits should really not be a huge deal.

Perhaps, at minimum, there should be a negotiated option on whether or not
the AS_PATH is included in updates, on a per-neighbor basis?

That would allow both sides to win, and even better, provide some measure
of interoperability testing, including possibly passing the opaque
attribute through non-believers to far-end systems that want to see *all*
the BGPSEC data, even when it has crossed outside of the BGPSEC bubble.

In particular, this would be very helpful during the incremental deployment
phases, where there are *multiple* islands of BGPSEC.

Brian

--0016e6d784fd71e86704bd69e7f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 10, 2012 at 1:47 PM, Christo=
pher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:morrowc.lists@gmail.com=
">morrowc.lists@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div class=3D"im">On Tue, Apr 10, 2012 at 1:00 PM, Robert Raszuk &lt;<a hre=
f=3D"mailto:robert@raszuk.net">robert@raszuk.net</a>&gt; wrote:<br></div></=
blockquote><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"></div><div class=3D"im">
&gt; All BGP monitoring tools need to be upgraded to now understand BGPSEC<=
br>
&gt; attribute too. And surprise .. here BMP will not convert it like it wi=
ll to<br>
&gt; &quot;legacy&quot; speakers.<br>
<br>
</div>sure, they&#39;d have to do that anyway, or they just are<br>
&#39;non-bgpsec-speakers&#39; (an e|ibgp neighbour without security foo). I=
n<br>
other words, tomorrow for them is the same as today, the world keeps<br>
on going round.<br>
<div class=3D"im"><br>
&gt; You may think that if we stuff all &quot;data&quot; in the new attribu=
te and drop the<br>
&gt; other one everything else will work. This may be so in theory, but it =
is<br>
&gt; clearly not a case in practice.<br>
<br>
</div>maybe? so far you&#39;ve not convinced me... you can feel free to kee=
p<br>
trying though? email is cheap.<br>
<div class=3D"im HOEnZb"><br></div></blockquote><div><br></div><div>Okay, I=
&#39;ll bite...</div><div><br></div><div>Suppose someone wants to take an e=
xisting tool which speaks BGP, and writes out full tables and updates to fi=
les. Call it &quot;bgpmon&quot;. :-)</div>
<div><br></div><div>The obvious thing to do for that tool, would be for it =
to advertise that it speaks BGPSEC, and record the updates that come from B=
GPSEC speakers.</div><div><br></div><div>Clearly, this tool is not a router=
, nor does it need to do validation. In fact, you *don&#39;t* want to valid=
ate, since you want to record all updates, *including* invalid updates.</di=
v>
<div><br></div><div>The ability to do quick-and-dirty comparisons between B=
GP-vanilla and BGPSEC data, from archived data, would be significantly hamp=
ered if the AS_PATH had to be reconstructed from this data.</div><div><br>
</div><div>Duplicate bits should really not be a huge deal.</div><div><br><=
/div><div>Perhaps, at minimum, there should be a negotiated option on wheth=
er or not the AS_PATH is included in updates, on a per-neighbor basis?</div=
>
<div><br></div><div>That would allow both sides to win, and even better, pr=
ovide some measure of interoperability testing, including possibly passing =
the opaque attribute through non-believers to far-end systems that want to =
see *all* the BGPSEC data, even when it has crossed outside of the BGPSEC b=
ubble.</div>
<div><br></div><div>In particular, this would be very helpful during the in=
cremental deployment phases, where there are *multiple* islands of BGPSEC.<=
/div><div><br></div><div>Brian</div></div>

--0016e6d784fd71e86704bd69e7f5--

From morrowc@ops-netman.net  Wed Apr 11 10:22:37 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5611E808D for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Level: 
X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8boy9T5oBfXj for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:22:37 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1D911E8089 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:22:35 -0700 (PDT)
Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 7C6DF32008D; Wed, 11 Apr 2012 17:22:25 +0000 (UTC)
Message-ID: <4F85BDD1.20500@ops-netman.net>
Date: Wed, 11 Apr 2012 13:22:25 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>,  sidr wg <sidr@ietf.org>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:22:38 -0000

Howdy folks,
For those interested in the Apr 30 Interim meeting, we updated the wiki:
  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>

to include as much as we currently can say about the
location/agenda/remote-participation-foo. I believe that the intent is
to run the meeting as a completely virtual meeting, with some folks
localized in space/time as space permits.

We attempted to expound on the questions Arturo and Danny had in the
draft-agenda announcement with the wiki content. If there are further
questions please ask.

-chris
<co-chair>

From Sandra.Murphy@sparta.com  Wed Apr 11 10:28:38 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9E11E80AE for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.239
X-Spam-Level: 
X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGvfjq5rk6bP for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:28:38 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4691711E809B for <sidr@ietf.org>; Wed, 11 Apr 2012 10:28:38 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3BHSaEr002504; Wed, 11 Apr 2012 12:28:36 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3BHSZKj027204; Wed, 11 Apr 2012 12:28:36 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 11 Apr 2012 13:28:35 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Danny McPherson <danny@tcb.net>, Christopher Morrow <morrowc.lists@gmail.com>
Thread-Topic: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
Thread-Index: AQHNFy5TCu5SgJPdUUyf+17SUhXGHJaVDjAAgAACWICAAAVlAIAAyhcK
Date: Wed, 11 Apr 2012 17:28:34 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2B63@Hermes.columbia.ads.sparta.com>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com>, <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net>
In-Reply-To: <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sidr-ads@tools.ietf.org" <sidr-ads@tools.ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:28:39 -0000

speaking as regular ol' member=0A=
=0A=
On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [danny@tcb.net] said:=
=0A=
=0A=
>From there, we can discuss the issue of, for example, HOW TO onboard =0A=
>and purge signing and validating certificates to routers from the RPKI -- =
=0A=
>[I suspect the intention was to use rpki-rtr protocol for this, but it doe=
sn't =0A=
>currently support it, nor are the security implications clear].=0A=
=0A=
I can not  understand your comment.  What do you mean by "signing certifica=
tes"?   =0A=
=0A=
I can guess that "validating certificates" means the certs carrying public =
keys used to validate signatures, but the "signing certificates" part has m=
e stumped.=0A=
=0A=
--Sandy=0A=
=0A=
=0A=
________________________________________=0A=
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh=
erson [danny@tcb.net]=0A=
Sent: Tuesday, April 10, 2012 9:15 PM=0A=
To: Christopher Morrow=0A=
Cc: sidr wg; sidr-chairs@tools.ietf.org; sidr-ads@tools.ietf.org=0A=
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201=
2)=0A=
=0A=
On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:=0A=
=0A=
> yes, my goal was to have updated the wiki today at the office, work=0A=
> intruded... tomorrow I'll do that with some more content for each=0A=
> item, and hopefully better coordinates as well for the location.=0A=
=0A=
Thanks.=0A=
=0A=
>> Also, are we collecting requirements for these (e.g., object scale, RPs,=
 etc..)?  Basing these discussions on requirements that exist somewhere alr=
eady?  Or simply discussing solutions that have already been developed and =
deployment experience?  If the latter, then we can we ensure we reference a=
nd prepare to discuss what requirements drive to the development of those s=
olutions?=0A=
>>=0A=
>=0A=
> I think the only bit in the 3 that has a current 'requirements'=0A=
> discussion is the 'freshness' (item 2). The first item 'deployment=0A=
> discussion' is really a discussion of:=0A=
>  "Should there be some document that describes the top N (3?)=0A=
> deployment scenarios && where should that document/presentation/etc=0A=
> live?" (I suppose implicit in that is 'requirements for format,=0A=
> content, intended audience')=0A=
=0A=
I was thinking more simply along the lines of "a fully deployed RPKI today =
would have o objects and r RPs a c churn and we ought to ensure our designs=
 accommodate that" -- only then can we have a reasonable discussion on, e.g=
., data freshness?  What have we based these design goals on thus far - do =
we have a stable reference for this?=0A=
=0A=
>From there, we can discuss the issue of, for example, HOW TO onboard and pu=
rge signing and validating certificates to routers from the RPKI -- [I susp=
ect the intention was to use rpki-rtr protocol for this, but it doesn't cur=
rently support it, nor are the security implications clear].=0A=
=0A=
Only when we get to that point will we really begin to understand the dynam=
ics of RPKI and it's employment for secure routing (well beyond "authorized=
" origin policy configuration), and the impact of rate+state in both the RP=
KI and it's effectuating in the routing system, and perhaps most importantl=
y, the inter-dependencies between the two (even basic stuff like the rate o=
f updates from an RPKI cache to a router in a fully loaded system given tod=
ay's RPKI object counts).=0A=
=0A=
>> Also, it looks to me like we're in dire need of a charter update...=0A=
>=0A=
> for which? (I didn't think that any of the 3 items was actually=0A=
> outside of the current charter)=0A=
=0A=
I meant the goals and milestones, apologies for not being clear.=0A=
=0A=
-danny=0A=
_______________________________________________=0A=
sidr mailing list=0A=
sidr@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/sidr=0A=

From morrowc@ops-netman.net  Wed Apr 11 10:31:00 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E511E8094 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.275
X-Spam-Level: 
X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qSl4ZJLTFXx for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:30:59 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id BCE6B11E808D for <sidr@ietf.org>; Wed, 11 Apr 2012 10:30:59 -0700 (PDT)
Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 89F6E320091; Wed, 11 Apr 2012 17:30:58 +0000 (UTC)
Message-ID: <4F85BFD2.4050707@ops-netman.net>
Date: Wed, 11 Apr 2012 13:30:58 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com>, <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2B63@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2B63@Hermes.columbia.ads.sparta.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>, "sidr-ads@tools.ietf.org" <sidr-ads@tools.ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:31:00 -0000

On 04/11/2012 01:28 PM, Murphy, Sandra wrote:
> speaking as regular ol' member
> On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [danny@tcb.net]
> said:
>> From there, we can discuss the issue of, for example, HOW TO
>> onboard and purge signing and validating certificates to routers
>> from the RPKI 

> I can guess that "validating certificates" means the certs carrying
> public keys used to validate signatures, but the "signing
> certificates" part has me stumped.

router ee-cert ... I believe he means (what signs outbound for this ASN
on the router doing eBGP)

From christopher.morrow@gmail.com  Wed Apr 11 10:35:31 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AFE21F854B for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.208
X-Spam-Level: 
X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1MZLaC5EwOn for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:35:30 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 929F521F853D for <sidr@ietf.org>; Wed, 11 Apr 2012 10:35:30 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1734626obb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZxZnXUmWFePePAlGvk1xnvQqvI4e4M0U45e6AP1N+hc=; b=VZ6pUoUuA7NikLZxg9bUtYCYdcHZEJiVZZ4qZkDRhSXXMUTD3YXFO9bzXYszw1tTvg KXIJHct7fj1W8wZpXipNJ3wMmd4i1Y1+bBzYvYuuWd+3XFnor/pInjNs9OOdbTfFxGLL i8J60UDEZ7YD/bmIF4NQx0foTNDf0Zt2UHqpNmDc1xcg0YDXxMWi8sVXeEAsF+qSxU26 KqXUS/RkTnfC11bF0mzz9lYmSK/vmnKuG/5CV9QhvOakazgPNGfS5u5aWC+YfGbFqcZK DdqOO3/b/pfj7QURLN+04W//081zO1Hw3z5ApXkuUoV/oupxiAir1zbFmQgdTVS5nHHD 36qQ==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr21195117obp.49.1334165726817; Wed, 11 Apr 2012 10:35:26 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 10:35:26 -0700 (PDT)
In-Reply-To: <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net>
Date: Wed, 11 Apr 2012 13:35:26 -0400
X-Google-Sender-Auth: nxjCQSCkwlnhYI5ccz-_cR0yjcE
Message-ID: <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:35:31 -0000

On Tue, Apr 10, 2012 at 9:15 PM, Danny McPherson <danny@tcb.net> wrote:
>
> On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:
>
>> yes, my goal was to have updated the wiki today at the office, work
>> intruded... tomorrow I'll do that with some more content for each
>> item, and hopefully better coordinates as well for the location.
>
> Thanks.

I think the 2 above items are done... please have a look when you get
some time, comments/questions welcome.

>>> Also, are we collecting requirements for these (e.g., object scale, RPs=
, etc..)? =A0Basing these discussions on requirements that exist somewhere =
already? =A0Or simply discussing solutions that have already been developed=
 and deployment experience? =A0If the latter, then we can we ensure we refe=
rence and prepare to discuss what requirements drive to the development of =
those solutions?
>>>
>>
>> I think the only bit in the 3 that has a current 'requirements'
>> discussion is the 'freshness' (item 2). The first item 'deployment
>> discussion' is really a discussion of:
>> =A0"Should there be some document that describes the top N (3?)
>> deployment scenarios && where should that document/presentation/etc
>> live?" (I suppose implicit in that is 'requirements for format,
>> content, intended audience')
>
> I was thinking more simply along the lines of "a fully deployed RPKI toda=
y would have o objects and r RPs a c churn and we ought to ensure our desig=
ns accommodate that" -- only then can we have a reasonable discussion on, e=
.g., data freshness? =A0What have we based these design goals on thus far -=
 do we have a stable reference for this?
>

hopefully this is captured in the wiki update.

> From there, we can discuss the issue of, for example, HOW TO onboard and =
purge signing and validating certificates to routers from the RPKI -- [I su=
spect the intention was to use rpki-rtr protocol for this, but it doesn't c=
urrently support it, nor are the security implications clear].
>

The rtr cert/ee-cert part was never planned/designed to be done via rpki-rt=
r.
Ideally at provisioning time your ee-cert is dropped onto the box,
similar to base-config today. Potentially your fav vendor has a
methodology in their plan for this. I can't imagine it's too tough,
nor that it's exact specification needs to be in an IETF doc (since it
seems implementation specific). Could be wrong though.

> Only when we get to that point will we really begin to understand the dyn=
amics of RPKI and it's employment for secure routing (well beyond "authoriz=
ed" origin policy configuration), and the impact of rate+state in both the =
RPKI and it's effectuating in the routing system, and perhaps most importan=
tly, the inter-dependencies between the two (even basic stuff like the rate=
 of updates from an RPKI cache to a router in a fully loaded system given t=
oday's RPKI object counts).
>

sure, some modelling seems like a good thing here, I think this was
asked for at the mic in PAR as well, no? (in response to some
discussions with Sriram?)

>>> Also, it looks to me like we're in dire need of a charter update...
>>
>> for which? (I didn't think that any of the 3 items was actually
>> outside of the current charter)
>
> I meant the goals and milestones, apologies for not being clear.

we can chat about that on-list or in the meeting... I suppose there's
a slew of milestones which are 'complete', there aren't really any
changes (that I planned) from an 'adding things' perspective. The
ops-documentation (see wiki) to me is probably NOT an ietf document,
again happy to talk at the meeting about that though.

-chris

From danny@tcb.net  Wed Apr 11 10:45:16 2012
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6030C21F855B for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT2l1QRwPGwc for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:45:15 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 149B821F8564 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:45:14 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 87A86268063; Wed, 11 Apr 2012 11:45:13 -0600 (MDT)
Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 Apr 2012 11:45:13 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=50286; syn-fingerprint=65535:53:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_DDD369C8-4DC1-4445-830B-52EB8E88A7AD"
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com>
Date: Wed, 11 Apr 2012 13:45:09 -0400
Message-Id: <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:45:16 -0000

--Apple-Mail=_DDD369C8-4DC1-4445-830B-52EB8E88A7AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1


On Apr 11, 2012, at 1:35 PM, Christopher Morrow wrote:
>=20
>=20
>> =46rom there, we can discuss the issue of, for example, HOW TO =
onboard and purge signing and validating certificates to routers from =
the RPKI -- [I suspect the intention was to use rpki-rtr protocol for =
this, but it doesn't currently support it, nor are the security =
implications clear].
>>=20
>=20
> The rtr cert/ee-cert part was never planned/designed to be done via =
rpki-rtr.
> Ideally at provisioning time your ee-cert is dropped onto the box,
> similar to base-config today. Potentially your fav vendor has a
> methodology in their plan for this. I can't imagine it's too tough,
> nor that it's exact specification needs to be in an IETF doc (since it
> seems implementation specific). Could be wrong though.

It has huge implications on the scale and operations, particularly when =
considering how rollovers and other such changes are effectuated.  Also, =
decoupling these entirely from validating certificates means I've got =
two mechanisms now for on-boarding [just] these things.  I'd prefer not =
to leave this to "magic happens" given that it's foundational to pretty =
much everything else that's being built.

> sure, some modelling seems like a good thing here, I think this was
> asked for at the mic in PAR as well, no? (in response to some
> discussions with Sriram?)

Yep!

> we can chat about that on-list or in the meeting... I suppose there's
> a slew of milestones which are 'complete', there aren't really any
> changes (that I planned) from an 'adding things' perspective. The
> ops-documentation (see wiki) to me is probably NOT an ietf document,
> again happy to talk at the meeting about that though.


I'd be interested in lining out the longer-term deliverables for the =
group on the list..

-danny


--Apple-Mail=_DDD369C8-4DC1-4445-830B-52EB8E88A7AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On Apr 11, 2012, at 1:35 PM, Christopher Morrow =
wrote:</div><blockquote type=3D"cite"><div><font =
class=3D"Apple-style-span" color=3D"#000000"><br></font><br><blockquote =
type=3D"cite">=46rom there, we can discuss the issue of, for example, =
HOW TO onboard and purge signing and validating certificates to routers =
from the RPKI -- [I suspect the intention was to use rpki-rtr protocol =
for this, but it doesn't currently support it, nor are the security =
implications clear].<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br>The rtr cert/ee-cert part was never =
planned/designed to be done via rpki-rtr.<br>Ideally at provisioning =
time your ee-cert is dropped onto the box,<br>similar to base-config =
today. Potentially your fav vendor has a<br>methodology in their plan =
for this. I can't imagine it's too tough,<br>nor that it's exact =
specification needs to be in an IETF doc (since it<br>seems =
implementation specific). Could be wrong =
though.<br></div></blockquote><div><br></div>It has huge implications on =
the scale and operations, particularly when considering how rollovers =
and other such changes are effectuated. &nbsp;Also, decoupling these =
entirely from validating certificates means I've got two mechanisms now =
for on-boarding [just] these things. &nbsp;I'd prefer not to leave this =
to "magic happens" given that it's foundational to pretty much =
everything else that's being built.</div><div><br></div><div><blockquote =
type=3D"cite"><div>sure, some modelling seems like a good thing here, I =
think this was<br>asked for at the mic in PAR as well, no? (in response =
to some<br>discussions with =
Sriram?)<br></div></blockquote><div><br></div>Yep!</div><div><br></div><di=
v><blockquote type=3D"cite"><div>we can chat about that on-list or in =
the meeting... I suppose there's<br>a slew of milestones which are =
'complete', there aren't really any<br>changes (that I planned) from an =
'adding things' perspective. The<br>ops-documentation (see wiki) to me =
is probably NOT an ietf document,<br>again happy to talk at the meeting =
about that =
though.<br></div></blockquote></div><br><div><br></div><div>I'd be =
interested in lining out the longer-term deliverables for the group on =
the =
list..</div><div><br></div><div>-danny</div><div><br></div></body></html>=

--Apple-Mail=_DDD369C8-4DC1-4445-830B-52EB8E88A7AD--

From christopher.morrow@gmail.com  Wed Apr 11 10:49:41 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E109211E808D for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.491
X-Spam-Level: 
X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgLued1MxvLw for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:49:41 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67A21F8570 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:49:41 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so702247ghb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zfsrjRD6vTP0bamtZ1npvHZGHmgmG92XPrQTsnCRNdo=; b=ynaiJAzzEUVB2uguz0S/JxJKl9iLtEUJ/QWndrYiSUpbAqSD7bPYvbzsNP7rsqMMRP alEKaPpI5uk3JxlosCsZMcgAsV5IVFnXFV69he/40M5KMgGb+C+kJzBo3WTqWbr1ycuj 0Vq4g+orQPOlxZEfAGZ+rXTPr14dyH3ZCGtv7hVtPTQopplgcItQfI5GtQ3/0LAuEKc1 3F+0wRMhk+Iq8OUF0y02bSihTPAI+BMCgfXGl3d5c0s7HN5xvowtHbyI4Ct2+6Z84Y9O Rh0yGzq0rj0tQGIv9O2gA4Q4PIKjNlq3MbKmtaiFG7mobZKzC35tpOeEOi4lTJRaNNZL 64sQ==
MIME-Version: 1.0
Received: by 10.60.24.201 with SMTP id w9mr23203064oef.49.1334166580337; Wed, 11 Apr 2012 10:49:40 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 10:49:40 -0700 (PDT)
In-Reply-To: <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net>
Date: Wed, 11 Apr 2012 13:49:40 -0400
X-Google-Sender-Auth: Il4It1KICxDf3Me-3KW6VWhIx5o
Message-ID: <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Danny McPherson <danny@tcb.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:49:42 -0000

On Wed, Apr 11, 2012 at 1:45 PM, Danny McPherson <danny@tcb.net> wrote:
>
> On Apr 11, 2012, at 1:35 PM, Christopher Morrow wrote:
>
>
>
> From there, we can discuss the issue of, for example, HOW TO onboard and
> purge signing and validating certificates to routers from the RPKI -- [I
> suspect the intention was to use rpki-rtr protocol for this, but it doesn=
't
> currently support it, nor are the security implications clear].
>
>
>
> The rtr cert/ee-cert part was never planned/designed to be done via
> rpki-rtr.
> Ideally at provisioning time your ee-cert is dropped onto the box,
> similar to base-config today. Potentially your fav vendor has a
> methodology in their plan for this. I can't imagine it's too tough,
> nor that it's exact specification needs to be in an IETF doc (since it
> seems implementation specific). Could be wrong though.
>
>
> It has huge implications on the scale and operations, particularly when

right: "Dear vendor, if you do this with a GUI only option I will stab
you in the eye"

I suppose, to me this looks like any other configuration thing you do
today on routers... beating the vendor over the head to support sane
(netconf? maybe?) methods for provisioning, is already done.

> considering how rollovers and other such changes are effectuated. =A0Also=
,

rollovers =3D=3D acl-updates =3D=3D routing-policy-updates =3D=3D ntp serve=
r
reconfig =3D=3D .... normal router configuration processes.

> decoupling these entirely from validating certificates means I've got two
> mechanisms now for on-boarding [just] these things. =A0I'd prefer not to =
leave

or another configuration bit to sling, yes.

> this to "magic happens" given that it's foundational to pretty much
> everything else that's being built.

copy my comment to vendors, into your rfp.

>
> sure, some modelling seems like a good thing here, I think this was
> asked for at the mic in PAR as well, no? (in response to some
> discussions with Sriram?)
>
>
> Yep!
>

ok, so ... got proposal? I think Sriram is itching/looking for how to
get a more reasoned approach to this (or that seemed to be his intent
at the mic).

> we can chat about that on-list or in the meeting... I suppose there's
> a slew of milestones which are 'complete', there aren't really any
> changes (that I planned) from an 'adding things' perspective. The
> ops-documentation (see wiki) to me is probably NOT an ietf document,
> again happy to talk at the meeting about that though.
>
>
>
> I'd be interested in lining out the longer-term deliverables for the grou=
p
> on the list..

sure, shoot.

From danny@tcb.net  Wed Apr 11 10:57:45 2012
Return-Path: <danny@tcb.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983FE21F8513 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.441
X-Spam-Level: 
X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgOW84chxloj for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 10:57:45 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4FE21F8510 for <sidr@ietf.org>; Wed, 11 Apr 2012 10:57:45 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id 0CC8E268063; Wed, 11 Apr 2012 11:57:45 -0600 (MDT)
Received: from dul1dmcphers-m2.vcorp.ad.vrsn.com (nat1.corp-fo.iad1.verisign.com [216.168.230.7]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 11 Apr 2012 11:57:44 -0600 (MDT) (envelope-from danny@tcb.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=216.168.230.7; client-port=61655; syn-fingerprint=65535:53:1:64:M1460,N,W1,N,N,T,S MacOS 10.4.8; data-bytes=0
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com>
Date: Wed, 11 Apr 2012 13:57:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 17:57:45 -0000

> I suppose, to me this looks like any other configuration thing you do
> today on routers... beating the vendor over the head to support sane
> (netconf? maybe?) methods for provisioning, is already done.

So how we onboard, update, or purge information from RPKI and sign stuff =
on n routers in z locations that 10's of thousands of others will =
evaluate in millions of routers to determine reachability of our =
information is relegated to "out of scope" of SIDR?

Gotcha - done here....

-danny=20



From morrowc@ops-netman.net  Wed Apr 11 11:08:35 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3471E11E80C5 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.183
X-Spam-Level: 
X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.103,  BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95z9QCcx6a3d for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:08:34 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 77A6F11E80BA for <sidr@ietf.org>; Wed, 11 Apr 2012 11:08:34 -0700 (PDT)
Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 955043200A1; Wed, 11 Apr 2012 18:08:32 +0000 (UTC)
Message-ID: <4F85C89D.3040307@ops-netman.net>
Date: Wed, 11 Apr 2012 14:08:29 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: Danny McPherson <danny@tcb.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net>
In-Reply-To: <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: sidr-chairs@tools.ietf.org, sidr wg <sidr@ietf.org>, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 18:08:35 -0000

On 04/11/2012 01:57 PM, Danny McPherson wrote:
> 
> 
>> I suppose, to me this looks like any other configuration thing you
>> do today on routers... beating the vendor over the head to support
>> sane (netconf? maybe?) methods for provisioning, is already done.
> 
> So how we onboard, update, or purge information from RPKI and sign

I think there are 2 things here:
  1) router-signing-cert (ee-cert?)
  2) rpki-digested-data (prefix + origin + cert-sig/etc)

they don't have to get to the router in the same way, do they? (I
suppose they COULD, but that isn't necessarily mandatory and isn't how
it's currently spec'd)

> stuff on n routers in z locations that 10's of thousands of others
> will evaluate in millions of routers to determine reachability of our

wait, now you added a 3rd item:
  3) rpki data repository/publication-point

> information is relegated to "out of scope" of SIDR?

nope, I think the part I was talking about was JUST #1 above. you put
that cert on your router in some implementation-specific manner. Does
the IETF have to (should it?) state there are some operational security
concerns with this? ie: "It is probably a bad idea to copy/paste an
unencrypted private key on a telnet session across the open Internet to
the router."  (that sort of thing could be placed in the bgpsec-ops doc,
it's not there as near as I can tell today).

-chris

From christopher.morrow@gmail.com  Wed Apr 11 11:09:39 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3299A11E8098 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.342
X-Spam-Level: 
X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NET030h3qYQM for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:09:37 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0611E808D for <sidr@ietf.org>; Wed, 11 Apr 2012 11:09:37 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1773480obb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 11:09:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZuZ8ny4k+lHcjtqSjjeaYuSxWWepx3A4bu/PCXST39Q=; b=MZ7ncLHmiYVjMLJg/vZ4X9NYhoRUfnPbBchobK1uLOduCjCkKJGoWDl7YYtsEjbJ0d DR0oDYXsQexHhnMspWkNaE1srcikrO7n8+9s8iqKT/HPXw0Qhz43TfsMuTM8G5A2HU1L 1cJ1I/i4hGRsLOhBCY/ihktG5jLCoi4K/+yvTNHW8Bh/GULhnPmKY8M2TzK1cupvhvgN GIJg6YO9vxbalVF5zWB2beakErFsT9y/rSVpTebQY/u0JwSRvGyenTXrkwjUcaqG1akh NLvYado7/OvuKHpankG5bD4v2jQ8qM+yHnupJwrtj6PTBEyCcDX6BXvbuY20Ih/G2uio OrPA==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr21398339obp.49.1334167773782; Wed, 11 Apr 2012 11:09:33 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 11:09:33 -0700 (PDT)
In-Reply-To: <4F85C89D.3040307@ops-netman.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net> <4F85C89D.3040307@ops-netman.net>
Date: Wed, 11 Apr 2012 14:09:33 -0400
X-Google-Sender-Auth: DWKVk3adZtUmgNBRgCY-FMRNdgw
Message-ID: <CAL9jLabk7vwzySYJ3hGv+0LnbKSHCKVh5LA5U2Y-yrejcdUg-g@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: sidr@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: sidr-ads@tools.ietf.org, sidr-chairs@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 18:09:39 -0000

(-home-email ... never should have started that:( )

On Wed, Apr 11, 2012 at 2:08 PM, Chris Morrow <morrowc@ops-netman.net> wrot=
e:
>
>
> On 04/11/2012 01:57 PM, Danny McPherson wrote:
>>
>>
>>> I suppose, to me this looks like any other configuration thing you
>>> do today on routers... beating the vendor over the head to support
>>> sane (netconf? maybe?) methods for provisioning, is already done.
>>
>> So how we onboard, update, or purge information from RPKI and sign
>
> I think there are 2 things here:
> =A01) router-signing-cert (ee-cert?)
> =A02) rpki-digested-data (prefix + origin + cert-sig/etc)
>
> they don't have to get to the router in the same way, do they? (I
> suppose they COULD, but that isn't necessarily mandatory and isn't how
> it's currently spec'd)
>
>> stuff on n routers in z locations that 10's of thousands of others
>> will evaluate in millions of routers to determine reachability of our
>
> wait, now you added a 3rd item:
> =A03) rpki data repository/publication-point
>
>> information is relegated to "out of scope" of SIDR?
>
> nope, I think the part I was talking about was JUST #1 above. you put
> that cert on your router in some implementation-specific manner. Does
> the IETF have to (should it?) state there are some operational security
> concerns with this? ie: "It is probably a bad idea to copy/paste an
> unencrypted private key on a telnet session across the open Internet to
> the router." =A0(that sort of thing could be placed in the bgpsec-ops doc=
,
> it's not there as near as I can tell today).
>
> -chris

From brian.peter.dickson@gmail.com  Wed Apr 11 11:23:52 2012
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6526B11E80D0 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.283
X-Spam-Level: 
X-Spam-Status: No, score=-3.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nA62M95gJNTA for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:23:48 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCB011E80CB for <sidr@ietf.org>; Wed, 11 Apr 2012 11:23:45 -0700 (PDT)
Received: by wibhr17 with SMTP id hr17so4258516wib.1 for <sidr@ietf.org>; Wed, 11 Apr 2012 11:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJRYOh62qTOJbOCvewWAJGlPVWuEFNgsFiZdA4kloMc=; b=EYx1+3sCKkv90MCnX7Htpbv3e7ohUEx/xSadTiRm0AQXxOFKBRhZWDvEEMCF1Z+5Ua siKZ+CaqBOXhmii+A/HBWdRxq96YTnJowqPWo9RZcwjVZ1TiWjYVrPiWlVMlcc3R66u4 aujZzfVu85BLuuBV1lYaDgp2x6adng13LuAOYJCEYfZ9R8+QzgUMT4RRxS9rUuGBpV8n j3v6alX8T/12fixjGTlkpOx3gz3ipPSUneJbgk58KNCupCOjAff3sLOod/FRqHhIvU0d SY+Em4YdriCOL/qetMp+adZOOjz4l8vgDajrbVY/IQr+gXFrI+biIsPS5ukHUnFFU6d6 196A==
MIME-Version: 1.0
Received: by 10.180.105.69 with SMTP id gk5mr10338663wib.3.1334168624066; Wed, 11 Apr 2012 11:23:44 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Wed, 11 Apr 2012 11:23:43 -0700 (PDT)
In-Reply-To: <4F85C89D.3040307@ops-netman.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net> <4F85C89D.3040307@ops-netman.net>
Date: Wed, 11 Apr 2012 14:23:43 -0400
Message-ID: <CAH1iCirHuAnf99-3Gg0kBf0vVaHs3oBCJv10m0Z2r9jLnqs57A@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Chris Morrow <morrowc@ops-netman.net>
Content-Type: multipart/alternative; boundary=f46d04426f14e8710604bd6b5673
Cc: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 18:23:52 -0000

--f46d04426f14e8710604bd6b5673
Content-Type: text/plain; charset=ISO-8859-1

My understanding is, that at least for the origination aspect, the
"freshness" argument is that the keys get rolled periodically.
And this has to occur on all the routers, with new keys published along
with the key roll, and possibly a unique key per router.

So, the key roll frequency alone, there are operational scalability things
to be concerned about.

The keys in question (which go into ee-cert?) have to have private keys on
routers, and public keys in RPKI, right?

This isn't a "do it once when you build the router" thing, this is a live
update of all aspects of the whole system (router + RPKI).

As in, we should probably take at least some of the time allotted for the
meta-discussion of, is private/public key really what we should be doing
here?
And if so, what are the ways that that can be done, with some analysis of
scaling factors (order of magnitude at a minimum).

E.g. it is one thing to say "sort the data", and quite another thing to say
"When you sort the data, be aware that bubble-sort is really a bad idea,
and quicksort is what you should use for N>6".

(Some thought should be given to comparative analysis of non-PKI crypto
mechanisms, such as hashing (SHA-256), including security, performance, and
whether onboarding-offboarding-purging are needed.)

Brian

On Wed, Apr 11, 2012 at 2:08 PM, Chris Morrow <morrowc@ops-netman.net>wrote:

>
>
> On 04/11/2012 01:57 PM, Danny McPherson wrote:
> >
> >
> >> I suppose, to me this looks like any other configuration thing you
> >> do today on routers... beating the vendor over the head to support
> >> sane (netconf? maybe?) methods for provisioning, is already done.
> >
> > So how we onboard, update, or purge information from RPKI and sign
>
> I think there are 2 things here:
>  1) router-signing-cert (ee-cert?)
>  2) rpki-digested-data (prefix + origin + cert-sig/etc)
>
> they don't have to get to the router in the same way, do they? (I
> suppose they COULD, but that isn't necessarily mandatory and isn't how
> it's currently spec'd)
>
> > stuff on n routers in z locations that 10's of thousands of others
> > will evaluate in millions of routers to determine reachability of our
>
> wait, now you added a 3rd item:
>  3) rpki data repository/publication-point
>
> > information is relegated to "out of scope" of SIDR?
>
> nope, I think the part I was talking about was JUST #1 above. you put
> that cert on your router in some implementation-specific manner. Does
> the IETF have to (should it?) state there are some operational security
> concerns with this? ie: "It is probably a bad idea to copy/paste an
> unencrypted private key on a telnet session across the open Internet to
> the router."  (that sort of thing could be placed in the bgpsec-ops doc,
> it's not there as near as I can tell today).
>
> -chris
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

--f46d04426f14e8710604bd6b5673
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

My understanding is, that at least for the origination aspect, the &quot;fr=
eshness&quot; argument is that the keys get rolled periodically.<div>And th=
is has to occur on all the routers, with new keys published along with the =
key roll, and possibly a unique key per router.</div>
<div><br></div><div>So, the key roll frequency alone, there are operational=
 scalability things to be concerned about.</div><div><br></div><div>The key=
s in question (which go into ee-cert?) have to have private keys on routers=
, and public keys in RPKI, right?</div>
<div><br></div><div>This isn&#39;t a &quot;do it once when you build the ro=
uter&quot; thing, this is a live update of all aspects of the whole system =
(router + RPKI).</div><div><br></div><div>As in, we should probably take at=
 least some of the time allotted for the meta-discussion of, is private/pub=
lic key really what we should be doing here?</div>
<div>And if so, what are the ways that that can be done, with some analysis=
 of scaling factors (order of magnitude at a minimum).</div><div><br></div>=
<div>E.g. it is one thing to say &quot;sort the data&quot;, and quite anoth=
er thing to say &quot;When you sort the data, be aware that bubble-sort is =
really a bad idea, and quicksort is what you should use for N&gt;6&quot;.</=
div>
<div><br></div><div>(Some thought should be given to comparative analysis o=
f non-PKI crypto mechanisms, such as hashing (SHA-256), including security,=
 performance, and whether onboarding-offboarding-purging are needed.)</div>
<div><br></div><div>Brian<br><br><div class=3D"gmail_quote">On Wed, Apr 11,=
 2012 at 2:08 PM, Chris Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:morr=
owc@ops-netman.net">morrowc@ops-netman.net</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im"><br>
<br>
On 04/11/2012 01:57 PM, Danny McPherson wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; I suppose, to me this looks like any other configuration thing you=
<br>
&gt;&gt; do today on routers... beating the vendor over the head to support=
<br>
&gt;&gt; sane (netconf? maybe?) methods for provisioning, is already done.<=
br>
&gt;<br>
&gt; So how we onboard, update, or purge information from RPKI and sign<br>
<br>
</div>I think there are 2 things here:<br>
 =A01) router-signing-cert (ee-cert?)<br>
 =A02) rpki-digested-data (prefix + origin + cert-sig/etc)<br>
<br>
they don&#39;t have to get to the router in the same way, do they? (I<br>
suppose they COULD, but that isn&#39;t necessarily mandatory and isn&#39;t =
how<br>
it&#39;s currently spec&#39;d)<br>
<div class=3D"im"><br>
&gt; stuff on n routers in z locations that 10&#39;s of thousands of others=
<br>
&gt; will evaluate in millions of routers to determine reachability of our<=
br>
<br>
</div>wait, now you added a 3rd item:<br>
 =A03) rpki data repository/publication-point<br>
<div class=3D"im"><br>
&gt; information is relegated to &quot;out of scope&quot; of SIDR?<br>
<br>
</div>nope, I think the part I was talking about was JUST #1 above. you put=
<br>
that cert on your router in some implementation-specific manner. Does<br>
the IETF have to (should it?) state there are some operational security<br>
concerns with this? ie: &quot;It is probably a bad idea to copy/paste an<br=
>
unencrypted private key on a telnet session across the open Internet to<br>
the router.&quot; =A0(that sort of thing could be placed in the bgpsec-ops =
doc,<br>
it&#39;s not there as near as I can tell today).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
-chris<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
sidr mailing list<br>
<a href=3D"mailto:sidr@ietf.org">sidr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/sidr</a><br>
</div></div></blockquote></div><br></div>

--f46d04426f14e8710604bd6b5673--

From christopher.morrow@gmail.com  Wed Apr 11 11:31:57 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC00111E8098 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.337
X-Spam-Level: 
X-Spam-Status: No, score=-103.337 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm4xzEyyE6yN for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 11:31:56 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C74221F8483 for <sidr@ietf.org>; Wed, 11 Apr 2012 11:31:53 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1797883obb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 11:31:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=/tIPlFjIR8ymEdVg7VPNR33Mp5L3s0EwQRwlTHuO+Bk=; b=pyTOp71IG5clH/PGrcUyjvuFg79b4Sc1NMK96VjOqBAYOj/gRZeN9DZVBSwVJkTdmw U06CnvAPuI8xtLG3/si8Sa2hUVGkqPXaybfO4ZJkdVN2R6kb2qgsiRO+WbFf80kEwfwD BaVnFiGcVxQBkT8jDRGSsfIrH35RGkbnL67JtXvBPlZwXCvQ3eEVRX4f5BMPklchhmhA 4aWZUKMclWhjvTpVQSQfvxMDUIqMsVQ2aBjMW03pA4H9GyTlmgShcpszP/+st2UCliJP 7p7CIf4rU80jh00PkxtF/m4GqH52kiVX5ZVFgKzBJUcpWRweij3w+t9AJggGNj5QAguF VvKw==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr21525291obp.49.1334169112841; Wed, 11 Apr 2012 11:31:52 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 11:31:52 -0700 (PDT)
In-Reply-To: <CAH1iCirHuAnf99-3Gg0kBf0vVaHs3oBCJv10m0Z2r9jLnqs57A@mail.gmail.com>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net> <4F85C89D.3040307@ops-netman.net> <CAH1iCirHuAnf99-3Gg0kBf0vVaHs3oBCJv10m0Z2r9jLnqs57A@mail.gmail.com>
Date: Wed, 11 Apr 2012 14:31:52 -0400
X-Google-Sender-Auth: b7Xk5ZLKfZaDJcapwEHg6ukidM0
Message-ID: <CAL9jLaZyibH92y_SoeuBe21T6aPTy5CSNTyHVL=mS23ODNpP7A@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: sidr wg <sidr@ietf.org>, sidr-chairs@tools.ietf.org, sidr-ads@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 18:31:57 -0000

(if the ads want off this train, speak up)

On Wed, Apr 11, 2012 at 2:23 PM, Brian Dickson
<brian.peter.dickson@gmail.com> wrote:
> My understanding is, that at least for the origination aspect, the
> "freshness" argument is that the keys get rolled periodically.

they can get rolled periodically, sure. That could be as often as 1/yr
or 1/N yrs... your (operators) choice, within reason... which the mic
discussion also spun around in PAR.

> And this has to occur on all the routers, with new keys published along w=
ith
> the key roll, and possibly a unique key per router.

could be per router? per POP? per METRO? per REGION? per Continent?
per Country? per ASN?

> So, the key roll frequency alone, there are operational scalability thing=
s
> to be concerned about.

Sure, just like updating prefix-lists for all your customers today...
which L(3) does ~4x/day? NTTA does ~6x/day?

> The keys in question (which go into ee-cert?) have to have private keys o=
n
> routers, and public keys in RPKI, right?
>

Sure, you are updating 2 things here, potentially. Or pulling data
from a single store to put in 2 places (depends on your perspective
and systems/OSS I suppose).

> This isn't a "do it once when you build the router" thing, this is a live
> update of all aspects of the whole system (router + RPKI).

there are 2 systems there... with potentially very different
operational requirements.

we already all manage routers in the field ... this is just another
'prefix-list' or 'acl' or ... (or I hope it's just like that anyway -
see 'stab in eye' vendor comment)

> As in, we should probably take at least some of the time allotted for the
> meta-discussion of, is private/public key really what we should be doing
> here?
> And if so, what are the ways that that can be done, with some analysis of
> scaling factors (order of magnitude at a minimum).
>
> E.g. it is one thing to say "sort the data", and quite another thing to s=
ay
> "When you sort the data, be aware that bubble-sort is really a bad idea, =
and
> quicksort is what you should use for N>6".
>
> (Some thought should be given to comparative analysis of non-PKI crypto
> mechanisms, such as hashing (SHA-256), including security, performance, a=
nd
> whether onboarding-offboarding-purging are needed.)

I think that ship sailed... but it seems like a fun list discussion.

-chris

> Brian
>
> On Wed, Apr 11, 2012 at 2:08 PM, Chris Morrow <morrowc@ops-netman.net>
> wrote:
>>
>>
>>
>> On 04/11/2012 01:57 PM, Danny McPherson wrote:
>> >
>> >
>> >> I suppose, to me this looks like any other configuration thing you
>> >> do today on routers... beating the vendor over the head to support
>> >> sane (netconf? maybe?) methods for provisioning, is already done.
>> >
>> > So how we onboard, update, or purge information from RPKI and sign
>>
>> I think there are 2 things here:
>> =A01) router-signing-cert (ee-cert?)
>> =A02) rpki-digested-data (prefix + origin + cert-sig/etc)
>>
>> they don't have to get to the router in the same way, do they? (I
>> suppose they COULD, but that isn't necessarily mandatory and isn't how
>> it's currently spec'd)
>>
>> > stuff on n routers in z locations that 10's of thousands of others
>> > will evaluate in millions of routers to determine reachability of our
>>
>> wait, now you added a 3rd item:
>> =A03) rpki data repository/publication-point
>>
>> > information is relegated to "out of scope" of SIDR?
>>
>> nope, I think the part I was talking about was JUST #1 above. you put
>> that cert on your router in some implementation-specific manner. Does
>> the IETF have to (should it?) state there are some operational security
>> concerns with this? ie: "It is probably a bad idea to copy/paste an
>> unencrypted private key on a telnet session across the open Internet to
>> the router." =A0(that sort of thing could be placed in the bgpsec-ops do=
c,
>> it's not there as near as I can tell today).
>>
>> -chris
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

From randy@psg.com  Wed Apr 11 12:06:58 2012
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC1821F8484 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 12:06:58 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4aJOPDuIDna for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 12:06:57 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id A270521F847E for <sidr@ietf.org>; Wed, 11 Apr 2012 12:06:57 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SI2sa-0003ED-88; Wed, 11 Apr 2012 19:06:56 +0000
Date: Thu, 12 Apr 2012 04:06:55 +0900
Message-ID: <m2wr5m141c.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Chris Morrow <morrowc@ops-netman.net>
In-Reply-To: <4F85C89D.3040307@ops-netman.net>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net> <4F85C89D.3040307@ops-netman.net>
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 <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 19:06:58 -0000

> nope, I think the part I was talking about was JUST #1 above. you put
> that cert on your router in some implementation-specific manner.

draft-ymbk-bgpsec-rtr-rekeying-00.txt

randy

From christopher.morrow@gmail.com  Wed Apr 11 12:10:27 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1D321F848C for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 12:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.491
X-Spam-Level: 
X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHYnXa5aDn4s for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 12:10:27 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5202521F848B for <sidr@ietf.org>; Wed, 11 Apr 2012 12:10:27 -0700 (PDT)
Received: by yhkk25 with SMTP id k25so760814yhk.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 12:10:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=slU2K2ob93F+ArAN00KRlK2bt1vjBptgdwdn6w0FrtA=; b=QOHrivesLRclL2KKFM8SDVWhX0SuOO14lzLdh6Cb/1v6JdcgoPDGjt8NGD9ueOKlTE drNCjyq73kQ4vK8V0oaUzprxqIV2FDbNQSLP9rspu2f66AuYmNEUpvmkep0/ZLUm+CLy mTN4eFJPZSWlWScybYIRSTPE4YFWp/BMf5dSXl1+1pb5nCevaoIbltZYiClFvAC9Sedh s38hIb+aoSjFW9bDVtMiQa4DpIYF12SUCBPiiapNT4wQWeeSBKjC5ucOhJ+upMHIyUvI +tu4O/u1mYhMb0FiZHZdKGIWLPdbwh9PGwKHMBaHl0uaGht6JGJQlZMFN3tj8Yw6sFpD WPyQ==
MIME-Version: 1.0
Received: by 10.60.24.201 with SMTP id w9mr23629862oef.49.1334171426785; Wed, 11 Apr 2012 12:10:26 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 12:10:26 -0700 (PDT)
In-Reply-To: <m2wr5m141c.wl%randy@psg.com>
References: <4F844D15.90402@ops-netman.net> <4F845123.60803@ops-netman.net> <3A499D67-D964-44A7-B1F5-BD103EBC67EE@tcb.net> <CAL9jLaZdVOW1YDm9cZEtfWQFgY=Qdc-_Be-gS8-FgRQiUxzw0A@mail.gmail.com> <CC95A8E0-4FA8-4FDF-BC53-E93340D62D64@tcb.net> <CAL9jLaaRV+W+C-amPAT3ALLd-QMr1XsoD_KLoDMYganTD-AGdg@mail.gmail.com> <C533B89C-F817-4111-A532-0165EC5D6786@tcb.net> <CAL9jLabTf8SHADEiKHJd0g6mKnG0T+mcjpydHjFEbHq16aOfxg@mail.gmail.com> <FFB084C8-960A-48DF-AF10-0CE08C09F819@tcb.net> <4F85C89D.3040307@ops-netman.net> <m2wr5m141c.wl%randy@psg.com>
Date: Wed, 11 Apr 2012 15:10:26 -0400
X-Google-Sender-Auth: f_Mr6xhSi9Jn39qqBskHJHCFdN4
Message-ID: <CAL9jLaYu0fnpK2SD0AVUkma3vL91y5vTQRmhzGqOphJST9GkhQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Randy Bush <randy@psg.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 19:10:28 -0000

On Wed, Apr 11, 2012 at 3:06 PM, Randy Bush <randy@psg.com> wrote:
>> nope, I think the part I was talking about was JUST #1 above. you put
>> that cert on your router in some implementation-specific manner.
>
> draft-ymbk-bgpsec-rtr-rekeying-00.txt

oh hai!

From jhaas@slice.pfrc.org  Wed Apr 11 12:48:10 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BC11E80C6; Wed, 11 Apr 2012 12:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.278
X-Spam-Level: 
X-Spam-Status: No, score=-101.278 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9J3mfEM2I1w; Wed, 11 Apr 2012 12:48:09 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B7F0C11E80B8; Wed, 11 Apr 2012 12:48:09 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 42F78170234; Wed, 11 Apr 2012 15:48:09 -0400 (EDT)
Date: Wed, 11 Apr 2012 15:48:09 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
Message-ID: <20120411194809.GE1283@slice>
References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "sidr@ietf.org" <sidr@ietf.org>, "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 19:48:10 -0000

On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote:
> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.heitz@ericsson.com> wrote:
> > Confeds are out of scope.
> 
> how are confeds out of scope?
> if you want path validation for ibgp/originated-by-you routes and the
> originating router is in one of the confed sub-ases you have that
> router sign with the confed-external/public asn, no? I'm fairly
> certain we planned to support this sort of activity... though I could
> be missing the part which is out-of-scope?

Functionally, confed segments are stripped prior to the global AS being
added to the path.  The box performing this function is the one that needs
to amend the BGPSEC signature, not some box in the middle of the
confederation.

-- Jeff

From jhaas@slice.pfrc.org  Wed Apr 11 12:52:48 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7711E8075; Wed, 11 Apr 2012 12:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.315
X-Spam-Level: 
X-Spam-Status: No, score=-101.315 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbqubd5z2X6Z; Wed, 11 Apr 2012 12:52:46 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id BA67521F8458; Wed, 11 Apr 2012 12:52:45 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 857461703E4; Wed, 11 Apr 2012 15:52:45 -0400 (EDT)
Date: Wed, 11 Apr 2012 15:52:45 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Message-ID: <20120411195245.GF1283@slice>
References: <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 19:52:48 -0000

On Wed, Apr 11, 2012 at 12:17:40PM -0400, Jakob Heitz wrote:
> Confeds are out of scope.
> 
> VPN address families are out of scope.

Meaning that the AS_PATH has to be present.  No?

(I suspect you mean yes.  That's the matter at hand.)

> If the BGPSEC path does not match the AS_PATH, the update
> is invalid.

You mean a 1:1 match of ASes including prepend counts?  If so, that's at
least an opinion. :-)

> The validity of an update is used as an input to route selection.
> If you have been replace/override/removing ASNs, you are free to
> use that information in route selection too.

That depends on path validity.  If you require that the AS_PATH and the
signature are identical (or potentially accommodate transparent ASes of
length 0), you can't do a number of those things without rendering the route
invalid.  Again, deployment issues.

> IOW, the BGPSEC validity of an update does not necessarily
> prevent you from using the update if you have inside knowledge
> about AS path mucking. How you use the BGPSEC validity in
> your route selection is a private matter.

In general, I agree.  The particulars have consequences.

-- Jeff

From christopher.morrow@gmail.com  Wed Apr 11 12:53:37 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE7311E80E8; Wed, 11 Apr 2012 12:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level: 
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ4KazCy2Nmy; Wed, 11 Apr 2012 12:53:36 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A59D111E80DB; Wed, 11 Apr 2012 12:53:33 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1889345obb.31 for <multiple recipients>; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z9X+ISKgcZEcinaxXemvKeEcjS20OX6a4Iat8jE8fiM=; b=wtuvnjVePlNbEMjl1PtNB9OYGfn1EsUBWXMIiZSFvgRIcr7ZcJ4Tfvrmpz4MKkbfRH BPNSuKmBulA0bOjmmJ6H2d2LGEaCCr/drRIwJlrelV1i4m9YSHWHM0qxwwmAvCFwRk8u kWvsCoLnLsIpCf68FxxaEiAT5nbaS65aiWtwXMQtfqxz+Egv9MCu4FWndDR8dvRjAUZL ystCn70mDBO5CHADl0128Lz2KhRkTheyUiZ0KVxpL2C2WfLUTObEnva3WaXVs3neFGkE dvXoidmqLQHjFM5Gm4rtdDriZk+O++EtYDUN0BLTkkcr8RDp/66C1a/0fQUqt8wWFVB9 FzfQ==
MIME-Version: 1.0
Received: by 10.182.52.104 with SMTP id s8mr21500861obo.59.1334174009075; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 12:53:29 -0700 (PDT)
In-Reply-To: <20120411194809.GE1283@slice>
References: <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com> <20120411194809.GE1283@slice>
Date: Wed, 11 Apr 2012 15:53:29 -0400
X-Google-Sender-Auth: -o3XdKshdP1Mca-PvcfhsWqipzw
Message-ID: <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 19:53:37 -0000

On Wed, Apr 11, 2012 at 3:48 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Wed, Apr 11, 2012 at 12:28:32PM -0400, Christopher Morrow wrote:
>> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.heitz@ericsson.com>=
 wrote:
>> > Confeds are out of scope.
>>
>> how are confeds out of scope?
>> if you want path validation for ibgp/originated-by-you routes and the
>> originating router is in one of the confed sub-ases you have that
>> router sign with the confed-external/public asn, no? I'm fairly
>> certain we planned to support this sort of activity... though I could
>> be missing the part which is out-of-scope?
>
> Functionally, confed segments are stripped prior to the global AS being
> added to the path. =A0The box performing this function is the one that ne=
eds
> to amend the BGPSEC signature, not some box in the middle of the
> confederation.

I suppose you could re-sign... the case I was thinking of was
attempting to validate inside your domain a prefix supposedly
originated by an iBGP speaker inside your domain.

From aservin@lacnic.net  Wed Apr 11 14:26:18 2012
Return-Path: <aservin@lacnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2221F84B9 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 14:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.429
X-Spam-Level: 
X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_SORBS_WEB=0.619,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkMBt7T+BfRl for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 14:26:18 -0700 (PDT)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3431621F84B5 for <sidr@ietf.org>; Wed, 11 Apr 2012 14:26:15 -0700 (PDT)
Received: from [192.168.41.86] (unknown [195.57.48.82]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3CEE7308455; Wed, 11 Apr 2012 18:26:05 -0300 (UYT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Arturo Servin <aservin@lacnic.net>
In-Reply-To: <4F85BDD1.20500@ops-netman.net>
Date: Wed, 11 Apr 2012 23:25:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net>
References: <4F85BDD1.20500@ops-netman.net>
To: Chris Morrow <morrowc@ops-netman.net>
X-Mailer: Apple Mail (2.1257)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck: 
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
Cc: "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2012 21:26:19 -0000

Chris,

	For the agenda item: "Deployment Discussion -> Discuss the need, =
and publication location/method, for documentation that details rollout =
of SIDR technologies in an operational network." Are we going to discuss =
what Tim suggested in his e-mail on March 30th (subject:  rpki =
repository and validation issues). I think he pointed out three valid =
points to discuss (at least start with the first 2 as he suggested):

	"(1) enumerate the problems that we see, and (2) refine a list =
of requirements for improvement, and then (3) find ways forward to =
address these requirements, without breaking the existing =
infrastructure".

	Is that the intention of the agenda item? Or are you planning to =
discuss something else?

Cheers,
.as


On 11 Apr 2012, at 19:22, Chris Morrow wrote:

> Howdy folks,
> For those interested in the Apr 30 Interim meeting, we updated the =
wiki:
>  <http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>=20
> to include as much as we currently can say about the
> location/agenda/remote-participation-foo. I believe that the intent is
> to run the meeting as a completely virtual meeting, with some folks
> localized in space/time as space permits.
>=20
> We attempted to expound on the questions Arturo and Danny had in the
> draft-agenda announcement with the wiki content. If there are further
> questions please ask.
>=20
> -chris
> <co-chair>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


From randy@psg.com  Wed Apr 11 18:15:44 2012
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A3811E8108 for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 18:15:44 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnzinLO9ItJM for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 18:15:43 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B6AD711E80FD for <sidr@ietf.org>; Wed, 11 Apr 2012 18:15:43 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SI8dS-0004wf-Hm; Thu, 12 Apr 2012 01:15:42 +0000
Date: Thu, 12 Apr 2012 10:15:41 +0900
Message-ID: <m2ehrtzr5u.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Arturo Servin <aservin@lacnic.net>
In-Reply-To: <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net>
References: <4F85BDD1.20500@ops-netman.net> <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net>
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 <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki	updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 01:15:44 -0000

> For the agenda item: "Deployment Discussion -> Discuss the need, and
> publication location/method, for documentation that details rollout of
> SIDR technologies in an operational network." Are we going to discuss
> what Tim suggested in his e-mail on March 30th

this is indeed of interest, and very few are actually measuring and
testing, as opposed to blathering on, about it.  but, as i said
previously, i do not think this is an urgent item as we have
considerable time to work on it and the current documented methods will
hold us for a while.

i am more interested in questions about incremental deployment of origin
validation and bgpsec, possible loose ends (confeds, as migration), and
misunderstandings (not by those who clearly have not actually read the
docs).

randy

From christopher.morrow@gmail.com  Wed Apr 11 19:16:10 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3271721F848A for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 19:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.481
X-Spam-Level: 
X-Spam-Status: No, score=-103.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHJnG1KuKYbl for <sidr@ietfa.amsl.com>; Wed, 11 Apr 2012 19:16:09 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 756CA21F8483 for <sidr@ietf.org>; Wed, 11 Apr 2012 19:16:09 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so2337444obb.31 for <sidr@ietf.org>; Wed, 11 Apr 2012 19:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZcrGaRD5+ogwFB7h9ns61yCMcOK/PnjPU6DRsLRBAMA=; b=bVrIhr4Ik0J0W5+1XvFAWu+epQ0cqW+nBxMuvaJUZnIDriArujI4fSFL3zmqWiY6JX ITTEQBficoQ5cfIbqgGIlQ+UMSY5N9pNJh0BSyvZQr2UYoMR6B5pYRhY6RQGHUIdQNmb bjrOKr7jp+TKc6FXtbZleeQy59skb5OESfxFwASgmUP1KtXongqq1ekokjFNjvF1nrxJ mmERyyFQA9NVi3x+PnnFZCn6DhPBSZb88eh0SerG9D3tWuyCPnDaytC5F+5Jft/KboRc HQ7zgWu1sDMa46kiFKpgIl6w2zcBh1zvaJOREqnjDOPOJU6vjwLYUPIYF/tVNEKoJRxN nlXQ==
MIME-Version: 1.0
Received: by 10.60.22.138 with SMTP id d10mr646271oef.69.1334196969055; Wed, 11 Apr 2012 19:16:09 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Wed, 11 Apr 2012 19:16:09 -0700 (PDT)
In-Reply-To: <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net>
References: <4F85BDD1.20500@ops-netman.net> <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net>
Date: Wed, 11 Apr 2012 22:16:09 -0400
X-Google-Sender-Auth: 5NEktxpPxiERQN36g5isGVBAjB0
Message-ID: <CAL9jLab8TAJkm8_kbu4nfM-9n2fQdRk1z0kcvELy5ST_Q=5yBQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Arturo Servin <aservin@lacnic.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 02:16:10 -0000

On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <aservin@lacnic.net> wrote:
> Chris,
>
> =A0 =A0 =A0 =A0For the agenda item: "Deployment Discussion -> Discuss the=
 need, and publication location/method, for documentation that details roll=
out of SIDR technologies in an operational network." Are we going to discus=
s what Tim suggested in his e-mail on March 30th (subject: =A0rpki reposito=
ry and validation issues). I think he pointed out three valid points to dis=
cuss (at least start with the first 2 as he suggested):
>

Actually no, Tim wanted to be able to present/be-in-person so the next
time he can do that is the coincident meeting with IETF in Vancouver,
BC.

This is really:
  "Do we need some documentation about deployment, is that an IETF
document? a BCOP/etc from some *nog, something hosted on
psg.com/rpki.net/as701.net/geocities.com"

and:
  "What is the content of this? three basic deployment walk-throughs?
FAQ about each part of a deployment? Something else?"

or, is the answer much shorter: "This is all quite simple, people will
just figure it out... done." (this I think is unlikely, but... who
knows)

-Chris

> =A0 =A0 =A0 =A0"(1) enumerate the problems that we see, and (2) refine a =
list of requirements for improvement, and then (3) find ways forward to add=
ress these requirements, without breaking the existing infrastructure".
>
> =A0 =A0 =A0 =A0Is that the intention of the agenda item? Or are you plann=
ing to discuss something else?
>
> Cheers,
> .as
>
>
> On 11 Apr 2012, at 19:22, Chris Morrow wrote:
>
>> Howdy folks,
>> For those interested in the Apr 30 Interim meeting, we updated the wiki:
>> =A0<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430>
>>
>> to include as much as we currently can say about the
>> location/agenda/remote-participation-foo. I believe that the intent is
>> to run the meeting as a completely virtual meeting, with some folks
>> localized in space/time as space permits.
>>
>> We attempted to expound on the questions Arturo and Danny had in the
>> draft-agenda announcement with the wiki content. If there are further
>> questions please ask.
>>
>> -chris
>> <co-chair>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

From wesley.george@twcable.com  Thu Apr 12 05:08:35 2012
Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1669421F865A; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.777
X-Spam-Level: 
X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[AWL=0.686,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19jnQzTYnrq9; Thu, 12 Apr 2012 05:08:34 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53821F85C2; Thu, 12 Apr 2012 05:08:34 -0700 (PDT)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="366668100"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:07:09 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 12 Apr 2012 08:07:43 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Paul Jakma <paul@jakma.org>
Date: Thu, 12 Apr 2012 08:07:43 -0400
Thread-Topic: [sidr] [Idr]  No BGPSEC intradomain ?
Thread-Index: Ac0X9vKgDybfDBfvSGCdfgxGGidh+AAQtH5A
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
In-Reply-To: <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 12:08:35 -0000

Thanks,

Wes

Wesley George
Time Warner Cable
ATG Technology Development
office: 703-561-2540 | mobile: 703-864-4902


> -----Original Message-----
> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 11:23 AM
> To: Paul Jakma
> Cc: idr@ietf.org List; sidr@ietf.org
> Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
>
> On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma <paul@jakma.org> wrote:
> > On Tue, 10 Apr 2012, Jakob Heitz wrote:
> >
> >> I agree with Robert. Today, there are many tools that interact with BG=
P
> >> messages. If the AS_PATH disappears, they will all break.
> >
> >
> > Indeed. If mandatory, well-known attributes are removed, then the BGP
> > protocol version number needs to be bumped.
> >
> > There's near-0-cost in doing that for those interested in implementing =
the
> > new functionality, and it avoids a world of hurt for all the various to=
ols
> > (sometimes in-house/home-grown) out there that believe they know what
> > they're getting when the version says 4.
>
> "if you don't ask for the 'bgpsec capability' then ... you get what
> you get today."
>
> also
>
> "if you ask for the 'bgpsec capabiltiy' then ... you get (and can
> presumably handle) the changes"
>
> so, everything you do today, ought to just keep right on working, or
> that's the plan.

[WEG] Why *are* we so resistant to incrementing the BGP version? I think th=
at there's some merit to the idea that this suite of things represents a si=
gnificant enough change to BGP that a change in version number might be a c=
leaner way to do the capability negotiation, perhaps even incorporating oth=
er secondary capabilities so that there isn't so much individual capability=
 negotiation for all of the things that we've tacked onto BGP4 over the yea=
rs. In other words, if you support BGPv5, you support the a list of capabil=
ities (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to b=
e negotiated separately. Even if we move directly from version 4 to 6 as it=
 seems we are wont to do, I think this bears some consideration (by IDR, of=
 course) ;-)

Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From wesley.george@twcable.com  Thu Apr 12 05:08:36 2012
Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A8521F865A; Thu, 12 Apr 2012 05:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.464
X-Spam-Level: 
X-Spam-Status: No, score=-0.464 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368,  RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSjGIvM2gCam; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74521F85C2; Thu, 12 Apr 2012 05:08:35 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="366668114"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:07:10 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 12 Apr 2012 08:07:44 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Jakob Heitz <jakob.heitz@ericsson.com>
Date: Thu, 12 Apr 2012 08:07:43 -0400
Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
Thread-Index: Ac0YADE6kaxr3F1XQ5+wa5TqtHNd3QAOgBhg
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAC@PRVPEXVS03.corp.twcable.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
In-Reply-To: <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 12:08:36 -0000

> From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> Christopher Morrow
> Sent: Wednesday, April 11, 2012 12:29 PM
> To: Jakob Heitz
> Cc: idr@ietf.org List; sidr@ietf.org
> Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSE=
C
> intradomain ?)
>
> On Wed, Apr 11, 2012 at 12:17 PM, Jakob Heitz <jakob.heitz@ericsson.com>
> wrote:
> > Confeds are out of scope.
>
> how are confeds out of scope?
> if you want path validation for ibgp/originated-by-you routes and the
> originating router is in one of the confed sub-ases you have that
> router sign with the confed-external/public asn, no? I'm fairly
> certain we planned to support this sort of activity... though I could
> be missing the part which is out-of-scope?
>

[WEG] There was discussion on the SIDR list on November 12 (subject line "v=
arious") specifically regarding private ASNs and confeds and their discussi=
on in the bgpsec-ops draft. I am writing offline and therefore can't provid=
e a more specific pointer to the message itself nor confirm (as memory of t=
he more previous versions that I've reviewed fails) that the product of tha=
t discussion has made it to an updated version, but I'm pretty sure that it=
 has. I'd encourage you to look back at this and see if you have additional=
 feedback regarding in/out of scope and implementation.

FWIW, confeds being truly out of scope may make BGPSec a no-op in my networ=
k, as I can't guarantee that confeds will be gone (unless you are suggestin=
g that they should be deprecated a la AS_SETs). My earlier recommendation i=
s that we have to be specific about how BGPSec handles signing and strippin=
g to manage an ASPath including confeds, whether it only signs at the exter=
nal side and previous signatures (if exist) are dropped, or if it is capabl=
e of handling something like this:

Origin ASN (public) -> Transit ASN1 (public) -> [confed ASN(s) (private)] -=
> confed ASN42 (public) -> confed ASN55 -- in that example, if the entire p=
ath is BGPSec capable, what does ASN42 send as the signed path? You have se=
veral ASNs that maybe need path count 0 in their signature so that they are=
 signed but don't interfere with the externally-visible path, or the Transi=
t ASN1 has to forward sign its updates as if they are directly connected to=
 confed ASN42 (public), meaning that we are potentially allowing it to tran=
sit multiple ASNs within the confed unsigned. Randy had said previously tha=
t confed ASNs shouldn't sign towards each other, so maybe that answers that=
 question, but since it has come back up, please give it some thought.

Thanks
Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From wesley.george@twcable.com  Thu Apr 12 05:31:59 2012
Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013F521F8663; Thu, 12 Apr 2012 05:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.385
X-Spam-Level: 
X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkEXY90G1kka; Thu, 12 Apr 2012 05:31:58 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8D21F865B; Thu, 12 Apr 2012 05:31:57 -0700 (PDT)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,410,1330923600"; d="scan'208";a="350188953"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 08:31:03 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 12 Apr 2012 08:31:45 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: "idr@ietf.org List" <idr@ietf.org>
Date: Thu, 12 Apr 2012 08:31:44 -0400
Thread-Topic: [sidr] [Idr]  No BGPSEC intradomain ?
Thread-Index: Ac0X9vKgDybfDBfvSGCdfgxGGidh+AAQtH5AABuNe1A=
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AEE@PRVPEXVS03.corp.twcable.com>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 12:31:59 -0000

Trying again without the signature block. Sorry about that, hit send too so=
on. *blush*
>
> > -----Original Message-----
> > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of
> > Christopher Morrow
> > Sent: Wednesday, April 11, 2012 11:23 AM
> > To: Paul Jakma
> > Cc: idr@ietf.org List; sidr@ietf.org
> > Subject: Re: [sidr] [Idr] No BGPSEC intradomain ?
> >
> > On Wed, Apr 11, 2012 at 10:12 AM, Paul Jakma <paul@jakma.org> wrote:
> > > On Tue, 10 Apr 2012, Jakob Heitz wrote:
> > >
> > >> I agree with Robert. Today, there are many tools that interact with =
BGP
> > >> messages. If the AS_PATH disappears, they will all break.
> > >
> > >
> > > Indeed. If mandatory, well-known attributes are removed, then the BGP
> > > protocol version number needs to be bumped.
> > >
> > > There's near-0-cost in doing that for those interested in implementin=
g the
> > > new functionality, and it avoids a world of hurt for all the various =
tools
> > > (sometimes in-house/home-grown) out there that believe they know what
> > > they're getting when the version says 4.
> >
> > "if you don't ask for the 'bgpsec capability' then ... you get what
> > you get today."
> >
> > also
> >
> > "if you ask for the 'bgpsec capabiltiy' then ... you get (and can
> > presumably handle) the changes"
> >
> > so, everything you do today, ought to just keep right on working, or
> > that's the plan.
>
> [WEG] Why *are* we so resistant to incrementing the BGP version? I think =
that
> there's some merit to the idea that this suite of things represents a
> significant enough change to BGP that a change in version number might be=
 a
> cleaner way to do the capability negotiation, perhaps even incorporating =
other
> secondary capabilities so that there isn't so much individual capability
> negotiation for all of the things that we've tacked onto BGP4 over the ye=
ars.
> In other words, if you support BGPv5, you support the a list of capabilit=
ies
> (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to be
> negotiated separately. Even if we move directly from version 4 to 6 as it
> seems we are wont to do, I think this bears some consideration (by IDR, o=
f
> course) ;-)
>
> Wes George
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely =
for
> the use of the individual or entity to which it is addressed. If you are =
not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may=
 be
> unlawful. If you have received this E-mail in error, please notify the se=
nder
> immediately and permanently delete the original and any copy of this E-ma=
il
> and any printout.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From robert@raszuk.net  Thu Apr 12 06:52:26 2012
Return-Path: <robert@raszuk.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706DC21F85CE for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 06:52:22 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pWF3h5+rMEG for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 06:52:21 -0700 (PDT)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E504621F85A1 for <sidr@ietf.org>; Thu, 12 Apr 2012 06:52:18 -0700 (PDT)
Received: (qmail 17535 invoked by uid 399); 12 Apr 2012 13:52:18 -0000
Received: from unknown (HELO ?172.20.31.168?) (pbs:robert@raszuk.net@64.197.120.3) by mail1310.opentransfer.com with ESMTPM; 12 Apr 2012 13:52:18 -0000
X-Originating-IP: 64.197.120.3
Message-ID: <4F86DE1D.4020505@raszuk.net>
Date: Thu, 12 Apr 2012 15:52:29 +0200
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>,  Paul Jakma <paul@jakma.org>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 13:52:26 -0000

I very much agree with both Paul and Wes that new BGP version number or 
at least new set of AFIs would be the best way to smoothly migrate 
unsecure BGP to secure one.

I have not seem anyone resisting that idea yet with real technical 
arguments against it ;)

Rgs,
R.

> [WEG] Why*are*  we so resistant to incrementing the BGP version? I
> think that there's some merit to the idea that this suite of things
> represents a significant enough change to BGP that a change in
> version number might be a cleaner way to do the capability
> negotiation, perhaps even incorporating other secondary capabilities
> so that there isn't so much individual capability negotiation for all
> of the things that we've tacked onto BGP4 over the years. In other
> words, if you support BGPv5, you support the a list of capabilities
> (eg 4-byte ASN, GR, route refresh, etc), and they no longer have to
> be negotiated separately. Even if we move directly from version 4 to
> 6 as it seems we are wont to do, I think this bears some
> consideration (by IDR, of course);-)
>
> Wes George


From tim@ripe.net  Thu Apr 12 07:38:11 2012
Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A1321F865F for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 07:38:11 -0700 (PDT)
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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txlUsXwPXtGc for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 07:38:10 -0700 (PDT)
Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF021F865E for <sidr@ietf.org>; Thu, 12 Apr 2012 07:38:09 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SIL9x-0007L5-3s; Thu, 12 Apr 2012 16:38:06 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-182.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SIL9x-0001Cc-05; Thu, 12 Apr 2012 16:38:05 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-3--548000082
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <CAL9jLab8TAJkm8_kbu4nfM-9n2fQdRk1z0kcvELy5ST_Q=5yBQ@mail.gmail.com>
Date: Thu, 12 Apr 2012 16:38:05 +0200
Message-Id: <290492F2-CBC6-4760-A8AC-8E28632092F7@ripe.net>
References: <4F85BDD1.20500@ops-netman.net> <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net> <CAL9jLab8TAJkm8_kbu4nfM-9n2fQdRk1z0kcvELy5ST_Q=5yBQ@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE           BODY: HTML included in message
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d317b6df6ab8add3651bf958b9be72e3
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr wg <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 14:38:11 -0000

--Apple-Mail-3--548000082
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

On 12 Apr 2012, at 04:16, Christopher Morrow wrote:

> On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <aservin@lacnic.net> =
wrote:
>> Chris,
>>=20
>>        For the agenda item: "Deployment Discussion -> Discuss the =
need, and publication location/method, for documentation that details =
rollout of SIDR technologies in an operational network." Are we going to =
discuss what Tim suggested in his e-mail on March 30th (subject:  rpki =
repository and validation issues). I think he pointed out three valid =
points to discuss (at least start with the first 2 as he suggested):
>>=20
>=20
> Actually no, Tim wanted to be able to present/be-in-person so the next
> time he can do that is the coincident meeting with IETF in Vancouver,
> BC.

Indeed, I can't make the 30 April interim meeting (not even remote). And =
it's also too short notice to bring more real measurements and =
experience (& measurements) from piloting possible alternatives to the =
table.


I agree with Randy (if I understand his point correctly) that =
measurements are needed to substantiate any discussion about the =
problems and possible alternatives. So... we actually plan to work on =
this over the following weeks (after the RIPE meeting):

- Add an automated feedback feature to our validator so that we can get =
statistics from wherever people run it (if they enable the feature). =
We're thinking of measuring:
   =3D average time to validate enabled TAs
   =3D frequency of rsync repositories being unavailable
   =3D frequency of validation corner cases occurring because we get a =
repo *while it is being updated* (eg mft out-of-sync with some object)
   =3D I am open to suggestions of other stuff to measure..

- Do a quick pilot implementation of some ideas:
   =3D Use an rss like notification mechanism to alert RPs of updates
   =3D Use http to fetch *consistent* deltas
   =3D And then do the same measurements as above and possibly more we =
can think of (like some controlled load stressing)

Of course there are lots of details involved here that are interesting =
to discuss with other RP implementers, RPKI publishers and the sidr wg =
at large, but... we feel that at this stage we want to mature and try =
out our ideas first so that when we bring this to the table we'll have a =
reasonable idea of whether it actually works in real code and helps to =
solve the real issues that we see. In short: we want to invest some =
energy in trying it out first, and then discuss more, rather than the =
other way around..

Planning can always change, but it looks like we should be able to do =
this without spending too many of our resources and in time to report =
about it in Vancouver.

For the time being we will use the list of problems and requirements =
that I formulated as a guideline for this pilot, but I am well aware =
that that list is subject to change when it's discussed in more detail =
in sidr on-list or at a meeting..


Tim=

--Apple-Mail-3--548000082
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
">Hi,<div><br><div><div>On 12 Apr 2012, at 04:16, Christopher Morrow =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><span class=3D"Apple-style-span" style=3D"border-collapse: =
separate; font-family: Monaco; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">On Wed, Apr =
11, 2012 at 5:25 PM, Arturo Servin &lt;<a =
href=3D"mailto:aservin@lacnic.net">aservin@lacnic.net</a>&gt; =
wrote:<br><blockquote type=3D"cite">Chris,<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">&nbsp; &nbsp; =
&nbsp; &nbsp;For the agenda item: "Deployment Discussion -&gt; Discuss =
the need, and publication location/method, for documentation that =
details rollout of SIDR technologies in an operational network." Are we =
going to discuss what Tim suggested in his e-mail on March 30th =
(subject: &nbsp;rpki repository and validation issues). I think he =
pointed out three valid points to discuss (at least start with the first =
2 as he suggested):<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br>Actually no, Tim wanted to be able to =
present/be-in-person so the next<br>time he can do that is the =
coincident meeting with IETF in =
Vancouver,<br>BC.<br></span></blockquote></div><br><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">Indeed, I can't make the =
30 April interim meeting (not even remote). And it's also too short =
notice to bring more real measurements and experience (&amp; =
measurements) from piloting possible alternatives to the =
table.</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">I agree with Randy (if I understand his point =
correctly) that measurements are needed to substantiate any discussion =
about the problems and possible alternatives. So... w</font><span =
class=3D"Apple-style-span" style=3D"font-family: Helvetica; ">e actually =
plan to work on this over the following weeks (after the RIPE =
meeting):</span></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">- Add an automated feedback feature to our validator =
so that we can get statistics from wherever people run it (if they =
enable the feature). We're thinking of measuring:</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D average =
time to validate enabled TAs</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D frequency =
of rsync repositories being unavailable</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D frequency =
of validation corner cases occurring because we get a repo *while it is =
being updated* (eg mft out-of-sync with some =
object)</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">&nbsp; &nbsp;=3D I am open to suggestions of other =
stuff to measure..</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">- Do a quick pilot implementation of some =
ideas:</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">&nbsp; &nbsp;=3D Use an rss like notification =
mechanism to alert RPs of updates</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D Use http =
to fetch *consistent* deltas</font></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: Helvetica; ">&nbsp; =
&nbsp;=3D And then do the same measurements as above and possibly more =
we can think of (like some controlled load =
stressing)</span></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">Of course there are lots of details involved here =
that are interesting to discuss with other RP implementers, RPKI =
publishers and the sidr wg at large, but... we feel that at this stage =
we want to mature and try out our ideas first so that when we bring this =
to the table we'll have a reasonable idea of whether it actually works =
in real code and helps to solve the real issues that we see. In short: =
we want to invest some energy in trying it out first, and then discuss =
more, rather than the other way around..</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">Planning can always =
change, but it looks like we should be able to do this without spending =
too many of our resources and in time to report about it in =
Vancouver.</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">For the time being we will use the list of problems =
and requirements that I formulated as a guideline for this pilot, but I =
am well aware that that list is subject to change when it's discussed in =
more detail in sidr on-list or at a meeting..</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" =
face=3D"Helvetica">Tim</font></div></div></body></html>=

--Apple-Mail-3--548000082--

From jhaas@slice.pfrc.org  Thu Apr 12 07:50:34 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6655E21F8683; Thu, 12 Apr 2012 07:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.74
X-Spam-Level: 
X-Spam-Status: No, score=-101.74 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uogph6M2NH+H; Thu, 12 Apr 2012 07:50:34 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0389221F8681; Thu, 12 Apr 2012 07:50:33 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 9BCAE1703CC; Thu, 12 Apr 2012 10:50:33 -0400 (EDT)
Date: Thu, 12 Apr 2012 10:50:33 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Message-ID: <20120412145033.GA9700@slice>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com> <4F86DE1D.4020505@raszuk.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4F86DE1D.4020505@raszuk.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "idr@ietf.org List" <idr@ietf.org>, Paul Jakma <paul@jakma.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]    No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 14:50:34 -0000

On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> I very much agree with both Paul and Wes that new BGP version number
> or at least new set of AFIs would be the best way to smoothly
> migrate unsecure BGP to secure one.

If it's not backward compatible, sure.

> I have not seem anyone resisting that idea yet with real technical
> arguments against it ;)

See my migration comments earlier.  If you think you can get a given SP that
might be willing to install BGPSEC at the edges also willing to upgrade
every other BGP speaker inside their AS... you're more optimistic than I.

-- Jeff

From jhaas@slice.pfrc.org  Thu Apr 12 07:53:02 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC321F8647; Thu, 12 Apr 2012 07:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.415
X-Spam-Level: 
X-Spam-Status: No, score=-101.415 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zxFCVVhiMLb; Thu, 12 Apr 2012 07:53:00 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8B21F8666; Thu, 12 Apr 2012 07:52:58 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 1D9A31703E7; Thu, 12 Apr 2012 10:52:58 -0400 (EDT)
Date: Thu, 12 Apr 2012 10:52:58 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
Message-ID: <20120412145258.GB9700@slice>
References: <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com> <20120411194809.GE1283@slice> <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "sidr@ietf.org" <sidr@ietf.org>, "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 14:53:02 -0000

On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote:
> > Functionally, confed segments are stripped prior to the global AS being
> > added to the path. ?The box performing this function is the one that needs
> > to amend the BGPSEC signature, not some box in the middle of the
> > confederation.
> 
> I suppose you could re-sign... the case I was thinking of was
> attempting to validate inside your domain a prefix supposedly
> originated by an iBGP speaker inside your domain.

If you don't trust your own boxes to originate, I think you have a  bigger
problem. :-)

That said, there's little stopping you from using RPKI (perhaps with a local
view) data to provide prefix sanity checking.  Internally the signature
piece is probably excessive.

-- Jeff

From christopher.morrow@gmail.com  Thu Apr 12 08:28:45 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30021F867E; Thu, 12 Apr 2012 08:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.088
X-Spam-Level: 
X-Spam-Status: No, score=-103.088 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5RStd6tcy9l; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9721F8671; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so3329695obb.31 for <multiple recipients>; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hr5zUVX4GZKT/9tTMUi5wSC8Q912tWbZRggxPRExLYM=; b=fwgjKJDIFkq2i8qTX48CHat6aBnGq8yUbahL5WKjORhx19PJz5dHZ9IOmOuTyJEePT vbrW15D2t1XnOq2ic6io6n8UdP0O2xR5FoZpsunc6oWdvTpZlcx7skS+dWHCUMIRYNId oC2LoaG2Ycm2VV0VHfovafitFiA9iCh6RH+7IWshQZbjgO4LtBlmmKgOYn3oZWKCJG/1 KOcIUFbje92HEvL0GNaB3GZa/0Qq+rn9baHDx6H9u3Qsm1XkJYKvAQNKmh/ZbGA7yBj1 gSgL4BsOdgVodLPPfHz3lGK9PyPRalGaQpKfhuCaYu3Jz7ph0rZeGC+xegVtmdrsbiz7 0Htw==
MIME-Version: 1.0
Received: by 10.182.52.104 with SMTP id s8mr3534355obo.59.1334244524079; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Thu, 12 Apr 2012 08:28:44 -0700 (PDT)
In-Reply-To: <20120412145258.GB9700@slice>
References: <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com> <20120411194809.GE1283@slice> <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com> <20120412145258.GB9700@slice>
Date: Thu, 12 Apr 2012 11:28:44 -0400
X-Google-Sender-Auth: Sjm6YHY2tdr7taJbOTJ54y5oOc4
Message-ID: <CAL9jLaYRsr5mJMzk76wHrvGSN9hc04yWFoBBGCz99_eDPoRXng@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 15:28:45 -0000

On Thu, Apr 12, 2012 at 10:52 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> On Wed, Apr 11, 2012 at 03:53:29PM -0400, Christopher Morrow wrote:
>> > Functionally, confed segments are stripped prior to the global AS bein=
g
>> > added to the path. ?The box performing this function is the one that n=
eeds
>> > to amend the BGPSEC signature, not some box in the middle of the
>> > confederation.
>>
>> I suppose you could re-sign... the case I was thinking of was
>> attempting to validate inside your domain a prefix supposedly
>> originated by an iBGP speaker inside your domain.
>
> If you don't trust your own boxes to originate, I think you have a =A0big=
ger
> problem. :-)

yes... where's that box in $HOSTILE_COUNTRY ? are we SURE that no one
has tampered with it during the recent 'unscheduled power outage' ? :(
darned crapblarghistan and it's ongoing power grid problems!

> That said, there's little stopping you from using RPKI (perhaps with a lo=
cal
> view) data to provide prefix sanity checking. =A0Internally the signature
> piece is probably excessive.

this is all from another frequent-poster to this list (the requirement
I mean)... I'm just parroting it back for the record. (though I do see
a valid case to sign on origination as well, and check internally)

you don't seem to disagree that the functionality could be there, so
... 'violent agreement'!

-chris

From jhaas@slice.pfrc.org  Thu Apr 12 08:39:21 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4721F864D; Thu, 12 Apr 2012 08:39:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.422
X-Spam-Level: 
X-Spam-Status: No, score=-101.422 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcrBQ6fsmV26; Thu, 12 Apr 2012 08:39:21 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 282AD21F8666; Thu, 12 Apr 2012 08:39:21 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 2B6E1170413; Thu, 12 Apr 2012 11:39:16 -0400 (EDT)
Date: Thu, 12 Apr 2012 11:39:16 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
Message-ID: <20120412153916.GC9700@slice>
References: <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE934B5@EUSAACMS0701.eamcs.ericsson.se> <CAL9jLaZjXHBSXmuQ6p53o+0aPkfudTUm60xY2qTSbRu8+wLmMg@mail.gmail.com> <20120411194809.GE1283@slice> <CAL9jLaaqcTtpTbjiRCCDWSRvqfZPAP3DB9Uv9h+eA8Uc9hOYRQ@mail.gmail.com> <20120412145258.GB9700@slice> <CAL9jLaYRsr5mJMzk76wHrvGSN9hc04yWFoBBGCz99_eDPoRXng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAL9jLaYRsr5mJMzk76wHrvGSN9hc04yWFoBBGCz99_eDPoRXng@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "sidr@ietf.org" <sidr@ietf.org>, "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 15:39:21 -0000

On Thu, Apr 12, 2012 at 11:28:44AM -0400, Christopher Morrow wrote:
> you don't seem to disagree that the functionality could be there, so
> ... 'violent agreement'!

I think what I'd be saying is "if you want this to be done at point of
origination", there's significant work to be done.

- Jeff

From wesley.george@twcable.com  Thu Apr 12 10:07:40 2012
Return-Path: <wesley.george@twcable.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B309021F86A4; Thu, 12 Apr 2012 10:07:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.734
X-Spam-Level: 
X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AWL=0.729,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAuf3tV2rPL8; Thu, 12 Apr 2012 10:07:40 -0700 (PDT)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0600D21F865C; Thu, 12 Apr 2012 10:07:39 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.75,411,1330923600"; d="scan'208";a="366874950"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Apr 2012 13:07:05 -0400
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 12 Apr 2012 13:07:38 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Robert Raszuk <robert@raszuk.net>
Date: Thu, 12 Apr 2012 13:07:38 -0400
Thread-Topic: [Idr] [sidr]   No BGPSEC intradomain ?
Thread-Index: Ac0Yu52Sb0fgrDVUQ3i/YwnZDhisQwAEHdgA
Message-ID: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5F1E@PRVPEXVS03.corp.twcable.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com> <4F86DE1D.4020505@raszuk.net> <20120412145033.GA9700@slice>
In-Reply-To: <20120412145033.GA9700@slice>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, Paul Jakma <paul@jakma.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]    No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 17:07:40 -0000

> -----Original Message-----
> From: Jeffrey Haas [mailto:jhaas@pfrc.org]
> Sent: Thursday, April 12, 2012 10:51 AM
> To: Robert Raszuk
> Cc: George, Wes; Paul Jakma; idr@ietf.org List; sidr@ietf.org
> Subject: Re: [Idr] [sidr] No BGPSEC intradomain ?
>
> On Thu, Apr 12, 2012 at 03:52:29PM +0200, Robert Raszuk wrote:
> > I very much agree with both Paul and Wes that new BGP version number
> > or at least new set of AFIs would be the best way to smoothly
> > migrate unsecure BGP to secure one.
>
> If it's not backward compatible, sure.
[WEG] that's sort of the point -- there are a lot of factors to consider wh=
en determining what "backward compatible" truly means as far as BGPSec is c=
oncerned, especially when it comes to monitoring tools and other things tha=
t need to know the data but not necessarily make routing decisions on it.
>
> > I have not seem anyone resisting that idea yet with real technical
> > arguments against it ;)
>
> See my migration comments earlier.  If you think you can get a given SP t=
hat
> might be willing to install BGPSEC at the edges also willing to upgrade
> every other BGP speaker inside their AS... you're more optimistic than I.

[WEG] I'm not totally sure which message you're referring to, but I think t=
hat may be a red herring. I'm not seeing how incrementing the BGP version a=
utomatically means that all routers in an ASN must upgrade to it. This isn'=
t exactly the same flag day sort of driver as the move between v3 and v4. B=
GP speakers that support BGPv5 also SHOULD support BGPv4, and would determi=
ne which they should use on initial capability negotiation. Same way as the=
y would do if BGPSec (and any other option) is a standalone capability to n=
egotiate. Even if you look at this from a scaling perspective (the BGPv5 sp=
eaker would have to craft and send out two different versions of update) we=
've already sort of said that this is acceptable collateral damage because =
of the fact that it can't send the same updates to neighbors of multiple di=
fferent ASNs because it has to sign them all differently.
What am I missing?

Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From jhaas@slice.pfrc.org  Thu Apr 12 11:21:34 2012
Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAAB21F8610; Thu, 12 Apr 2012 11:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.87
X-Spam-Level: 
X-Spam-Status: No, score=-101.87 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEF9GY0Rkr0U; Thu, 12 Apr 2012 11:21:25 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id CBB9F21F8625; Thu, 12 Apr 2012 11:21:23 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 776501703EA; Thu, 12 Apr 2012 14:21:23 -0400 (EDT)
Date: Thu, 12 Apr 2012 14:21:23 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "George, Wes" <wesley.george@twcable.com>
Message-ID: <20120412182123.GE9700@slice>
References: <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5AAB@PRVPEXVS03.corp.twcable.com> <4F86DE1D.4020505@raszuk.net> <20120412145033.GA9700@slice> <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5F1E@PRVPEXVS03.corp.twcable.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DCC302FAA9FE5F4BBA4DCAD465693779173DCB5F1E@PRVPEXVS03.corp.twcable.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: "idr@ietf.org List" <idr@ietf.org>, Paul Jakma <paul@jakma.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]    No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 18:21:35 -0000

On Thu, Apr 12, 2012 at 01:07:38PM -0400, George, Wes wrote:
> [WEG] I'm not totally sure which message you're referring to, but I think that may be a red herring. I'm not seeing how incrementing the BGP version automatically means that all routers in an ASN must upgrade to it.

Fish aside, given prior statements that once you leave a BGPSEC domain that
you stop doing BGPSEC, then it seems reasonable that you can't have bgp-4
inside of bgpsec.

I suspect that's not what some people are meaning by BGPSEC domains or
versions or what have you.  But this is all fall-out of what does it mean to
do BGPSEC in an AS that won't have some number of routers that can do it.

The original model discussed was BGPSEC signature operations at eBGP
borders.  In that model, iBGP considerations are largely irrelevant to the
signatures.  Where they become important is the edge cases where iBGP may
alter AS_PATH data. 

If iBGP speakers are expected to participate in signature operations, we
need to figure out what that means.  Chris M. suggests signing at
origination - signing to what exactly?  When there's confederations, is
there signing?  What do those certs look like in the RPKI especially when AS
numbers are re-used (private ASes)?  How do you handle confederation AS
stripping signature-wise?

If you don't believe each router in an AS needs an upgrade, you obviously
have protocol behavior in mind.  Write it down, please.  Keep in mind the
answer will change based on whether BGPSEC operations are done in iBGP or
not.

> This isn't exactly the same flag day sort of driver as the move between v3 and v4. BGP speakers that support BGPv5 also SHOULD support BGPv4, and would determine which they should use on initial capability negotiation.

If you can do the work via capability negotiation, I'd argue you don't
really need a new version number.

-- Jeff

From paul@jakma.org  Thu Apr 12 12:01:45 2012
Return-Path: <paul@jakma.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F30221F86AD for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 12:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuOz9em-2RKn for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 12:01:43 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 76E7721F8681 for <sidr@ietf.org>; Thu, 12 Apr 2012 12:01:43 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5005706wib.13 for <sidr@ietf.org>; Thu, 12 Apr 2012 12:01:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type:x-gm-message-state; bh=FshmqROHKowpPK1oxX4Z5nGKnu6iGvElPHr2NRblDJQ=; b=lKC5hUGIxCHb9EmVefPWlFxz1sXvGcqnqIT9hwMHxvHGZA6ZgpJ2Rqf7YFZwegJH8d J2lnBCWBHXyEMGPet6WoUs0YtCbIdY0NClXC+MRkMC31ZfGUm/QIROeKMgoscEVGwSJD TXBebjv+WNSbic5KvceQp8cshf2lO6TrbNYiBqk7vZ3qr9CtQzSU/OBHMjN7JjC7u5ii bmKr2C/jkXUlBhkFuwD+AAB4EMLwRiiFBwt1aDlu68vCvtV/0sKePD+F48bwVZhawC55 dl00nKWoiMcFMOQH49UEJwWRiMruvbg5VSbeCX4WBwBEgPXTA1rF8UrLOpPg9HBdd0Ph LAqQ==
Received: by 10.180.86.132 with SMTP id p4mr8426541wiz.15.1334257302550; Thu, 12 Apr 2012 12:01:42 -0700 (PDT)
Received: from stoner.gla.jakma.org (stoner.jakma.org. [81.168.24.42]) by mx.google.com with ESMTPS id ff9sm54179234wib.2.2012.04.12.12.01.40 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 12:01:40 -0700 (PDT)
Date: Thu, 12 Apr 2012 20:01:37 +0100 (BST)
From: Paul Jakma <paul@jakma.org>
To: Christopher Morrow <morrowc.lists@gmail.com>
In-Reply-To: <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
Message-ID: <alpine.LFD.2.02.1204121855400.3748@stoner.jakma.org>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <7309FCBCAE981B43ABBE69B31C8D21391B3EE03F77@EUSAACMS0701.eamcs.ericsson.se> <alpine.LFD.2.02.1204111507190.22591@jamaica.dcs.gla.ac.uk> <CAL9jLaZDwpje4NtHHMUpzJaHDJLMY-f8gzDUVe3pEKwSqvsm_w@mail.gmail.com>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Gm-Message-State: ALoCoQnLq554nUDaKnLCMGyyhElvolZpze5Lfpmnqxe6yjQpq3MQysuwjmvSo3UlZqwWEgQa2eYH
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  No BGPSEC intradomain ?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2012 19:01:45 -0000

On Wed, 11 Apr 2012, Christopher Morrow wrote:

> "if you don't ask for the 'bgpsec capability' then ... you get what
> you get today."

> so, everything you do today, ought to just keep right on working, or
> that's the plan.

Capability negotiation does not mean everything keeps on working. It means 
the session between the BGP speakers keeps working, sure. However, that's 
_not_ everything.

The BGP UPDATE message is no longer context-complete (wrt to the 
well-known attributes at least). If a 3rd-party wishes to be able to 
validate the message as cortrect (in the case of missing attributes) or 
even decode it correctly (in the case where well-known attributes are 
incompatibly redefined in syntax, like AS_PATH has been), it has to have 
seen the opening negotiation - which may have happened days or weeks or 
more before - or it has to be manually configured or make intelligent 
guesses.

It should be quite possible to keep BGP as completely parse-able at the 
message granularity - it just needs a modicum of care. It's a shame that 
ever more proposals are coming along that are overloading message formats, 
dependent on context that may only be exchanged very infrequently...

regards,
-- 
Paul Jakma	paul@jakma.org	@pjakma	Key ID: 64A2FF6A
Fortune:
static from plastic slide rules

From aservin@lacnic.net  Thu Apr 12 17:00:02 2012
Return-Path: <aservin@lacnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E869321F8638 for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 17:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.911
X-Spam-Level: 
X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3PdTLL9H7qn for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 17:00:01 -0700 (PDT)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8BD21F85B7 for <sidr@ietf.org>; Thu, 12 Apr 2012 17:00:00 -0700 (PDT)
Received: from [192.168.1.101] (r186-50-168-156.dialup.adsl.anteldata.net.uy [186.50.168.156]) by mail.lacnic.net.uy (Postfix) with ESMTP id AAB6730844D; Thu, 12 Apr 2012 21:00:09 -0300 (UYT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2507664B-6D9F-45C2-BD81-03241D597802"
From: Arturo Servin <aservin@lacnic.net>
In-Reply-To: <290492F2-CBC6-4760-A8AC-8E28632092F7@ripe.net>
Date: Thu, 12 Apr 2012 20:59:56 -0300
Message-Id: <180A9225-0F38-4269-A75B-E5C1A64BF755@lacnic.net>
References: <4F85BDD1.20500@ops-netman.net> <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net> <CAL9jLab8TAJkm8_kbu4nfM-9n2fQdRk1z0kcvELy5ST_Q=5yBQ@mail.gmail.com> <290492F2-CBC6-4760-A8AC-8E28632092F7@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.1257)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck: 
X-LACNIC.uy-MailScanner-From: aservin@lacnic.net
Cc: Chris Morrow <morrowc@ops-netman.net>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>, sidr wg <sidr@ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 00:00:02 -0000

--Apple-Mail=_2507664B-6D9F-45C2-BD81-03241D597802
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


	There has been a lot of discussion about different topics =
related, I wasn't sure what we were going to discuss.

	Thanks for clearing this out.

Regards,
as

On 12 Apr 2012, at 11:38, Tim Bruijnzeels wrote:

> Hi,
>=20
> On 12 Apr 2012, at 04:16, Christopher Morrow wrote:
>=20
>> On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <aservin@lacnic.net> =
wrote:
>>> Chris,
>>>=20
>>>        For the agenda item: "Deployment Discussion -> Discuss the =
need, and publication location/method, for documentation that details =
rollout of SIDR technologies in an operational network." Are we going to =
discuss what Tim suggested in his e-mail on March 30th (subject:  rpki =
repository and validation issues). I think he pointed out three valid =
points to discuss (at least start with the first 2 as he suggested):
>>>=20
>>=20
>> Actually no, Tim wanted to be able to present/be-in-person so the =
next
>> time he can do that is the coincident meeting with IETF in Vancouver,
>> BC.
>=20
> Indeed, I can't make the 30 April interim meeting (not even remote). =
And it's also too short notice to bring more real measurements and =
experience (& measurements) from piloting possible alternatives to the =
table.
>=20
>=20
> I agree with Randy (if I understand his point correctly) that =
measurements are needed to substantiate any discussion about the =
problems and possible alternatives. So... we actually plan to work on =
this over the following weeks (after the RIPE meeting):
>=20
> - Add an automated feedback feature to our validator so that we can =
get statistics from wherever people run it (if they enable the feature). =
We're thinking of measuring:
>    =3D average time to validate enabled TAs
>    =3D frequency of rsync repositories being unavailable
>    =3D frequency of validation corner cases occurring because we get a =
repo *while it is being updated* (eg mft out-of-sync with some object)
>    =3D I am open to suggestions of other stuff to measure..
>=20
> - Do a quick pilot implementation of some ideas:
>    =3D Use an rss like notification mechanism to alert RPs of updates
>    =3D Use http to fetch *consistent* deltas
>    =3D And then do the same measurements as above and possibly more we =
can think of (like some controlled load stressing)
>=20
> Of course there are lots of details involved here that are interesting =
to discuss with other RP implementers, RPKI publishers and the sidr wg =
at large, but... we feel that at this stage we want to mature and try =
out our ideas first so that when we bring this to the table we'll have a =
reasonable idea of whether it actually works in real code and helps to =
solve the real issues that we see. In short: we want to invest some =
energy in trying it out first, and then discuss more, rather than the =
other way around..
>=20
> Planning can always change, but it looks like we should be able to do =
this without spending too many of our resources and in time to report =
about it in Vancouver.
>=20
> For the time being we will use the list of problems and requirements =
that I formulated as a guideline for this pilot, but I am well aware =
that that list is subject to change when it's discussed in more detail =
in sidr on-list or at a meeting..
>=20
>=20
> Tim


--Apple-Mail=_2507664B-6D9F-45C2-BD81-03241D597802
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><br></div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>There has been a lot of =
discussion about different topics related, I wasn't sure what we were =
going to discuss.</div><div><br></div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Thanks for clearing this =
out.</div><div><br></div><div>Regards,</div><div>as</div><br><div><div>On =
12 Apr 2012, at 11:38, Tim Bruijnzeels wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; ">Hi,<div><br><div><div>On 12 Apr =
2012, at 04:16, Christopher Morrow wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Monaco; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">On Wed, Apr =
11, 2012 at 5:25 PM, Arturo Servin &lt;<a =
href=3D"mailto:aservin@lacnic.net">aservin@lacnic.net</a>&gt; =
wrote:<br><blockquote type=3D"cite">Chris,<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><blockquote type=3D"cite">&nbsp; &nbsp; =
&nbsp; &nbsp;For the agenda item: "Deployment Discussion -&gt; Discuss =
the need, and publication location/method, for documentation that =
details rollout of SIDR technologies in an operational network." Are we =
going to discuss what Tim suggested in his e-mail on March 30th =
(subject: &nbsp;rpki repository and validation issues). I think he =
pointed out three valid points to discuss (at least start with the first =
2 as he suggested):<br></blockquote><blockquote =
type=3D"cite"><br></blockquote><br>Actually no, Tim wanted to be able to =
present/be-in-person so the next<br>time he can do that is the =
coincident meeting with IETF in =
Vancouver,<br>BC.<br></span></blockquote></div><br><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">Indeed, I can't make the =
30 April interim meeting (not even remote). And it's also too short =
notice to bring more real measurements and experience (&amp; =
measurements) from piloting possible alternatives to the =
table.</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">I agree with Randy (if I understand his point =
correctly) that measurements are needed to substantiate any discussion =
about the problems and possible alternatives. So... w</font><span =
class=3D"Apple-style-span" style=3D"font-family: Helvetica; ">e actually =
plan to work on this over the following weeks (after the RIPE =
meeting):</span></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">- Add an automated feedback feature to our validator =
so that we can get statistics from wherever people run it (if they =
enable the feature). We're thinking of measuring:</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D average =
time to validate enabled TAs</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D frequency =
of rsync repositories being unavailable</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D frequency =
of validation corner cases occurring because we get a repo *while it is =
being updated* (eg mft out-of-sync with some =
object)</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">&nbsp; &nbsp;=3D I am open to suggestions of other =
stuff to measure..</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">- Do a quick pilot implementation of some =
ideas:</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">&nbsp; &nbsp;=3D Use an rss like notification =
mechanism to alert RPs of updates</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">&nbsp; &nbsp;=3D Use http =
to fetch *consistent* deltas</font></div><div><span =
class=3D"Apple-style-span" style=3D"font-family: Helvetica; ">&nbsp; =
&nbsp;=3D And then do the same measurements as above and possibly more =
we can think of (like some controlled load =
stressing)</span></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">Of course there are lots of details involved here =
that are interesting to discuss with other RP implementers, RPKI =
publishers and the sidr wg at large, but... we feel that at this stage =
we want to mature and try out our ideas first so that when we bring this =
to the table we'll have a reasonable idea of whether it actually works =
in real code and helps to solve the real issues that we see. In short: =
we want to invest some energy in trying it out first, and then discuss =
more, rather than the other way around..</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica">Planning can always =
change, but it looks like we should be able to do this without spending =
too many of our resources and in time to report about it in =
Vancouver.</font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica"><br></font></div><div><font class=3D"Apple-style-span" =
face=3D"Helvetica">For the time being we will use the list of problems =
and requirements that I formulated as a guideline for this pilot, but I =
am well aware that that list is subject to change when it's discussed in =
more detail in sidr on-list or at a meeting..</font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" face=3D"Helvetica"><br></font></div><div><font =
class=3D"Apple-style-span" =
face=3D"Helvetica">Tim</font></div></div></div></blockquote></div><br></bo=
dy></html>=

--Apple-Mail=_2507664B-6D9F-45C2-BD81-03241D597802--

From christopher.morrow@gmail.com  Thu Apr 12 17:03:18 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB34C21F869A for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 17:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.472
X-Spam-Level: 
X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu3dTykwJ39y for <sidr@ietfa.amsl.com>; Thu, 12 Apr 2012 17:03:17 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3726221F8688 for <sidr@ietf.org>; Thu, 12 Apr 2012 17:03:17 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so3920714obb.31 for <sidr@ietf.org>; Thu, 12 Apr 2012 17:03:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c0SaRchpm+xKj7HqkQ+hFHcfcgHu7TdJQmaMFRWLQaU=; b=P8By2akC7IalSWp4tXrGZ2HizWEmu26pnt8X8mi4v7YjQOm30DkI+CnxgaQlVQJfiR figJrBwO0Abb7EoK7atKJhzvufPGn38Uhv3JaG4gjjAwJgMl8qTtDgO8KGUUf7Jyi2Ih Dsfv4uGTeh4srvAMcS6ZHAVaQS0e1YdYHxKONH4si2SDnRYMIFztlSr0HjQsiR338NXd lZpg9kVMlPxsguKaTu5EAquP6H3rvtlP6NxgtdvAypmu/8JynPxApG6qUWw5Zl5dGfi/ wfK5R/zeKpz8iuUvkMhiRh8qOFTHMtxwAVmndMEzIWA/wZGxrNp2v9XZBAI3jkE8xKbN EzJg==
MIME-Version: 1.0
Received: by 10.182.74.4 with SMTP id p4mr111700obv.79.1334275394775; Thu, 12 Apr 2012 17:03:14 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Thu, 12 Apr 2012 17:03:14 -0700 (PDT)
In-Reply-To: <180A9225-0F38-4269-A75B-E5C1A64BF755@lacnic.net>
References: <4F85BDD1.20500@ops-netman.net> <90187F98-F21B-4FB9-ABE7-461416524809@lacnic.net> <CAL9jLab8TAJkm8_kbu4nfM-9n2fQdRk1z0kcvELy5ST_Q=5yBQ@mail.gmail.com> <290492F2-CBC6-4760-A8AC-8E28632092F7@ripe.net> <180A9225-0F38-4269-A75B-E5C1A64BF755@lacnic.net>
Date: Thu, 12 Apr 2012 20:03:14 -0400
X-Google-Sender-Auth: DW4phmrBH3fFQxUst8eNImK4QsY
Message-ID: <CAL9jLaaxRvnBnt=PmSx8KK6xYoNVwYGcA3xb4sqOs8D9nJAZ_g@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Arturo Servin <aservin@lacnic.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Chris Morrow <morrowc@ops-netman.net>, sidr wg <sidr@ietf.org>, "sidr-chairs@tools.ietf.org" <sidr-chairs@tools.ietf.org>
Subject: Re: [sidr] Interim Meeting Notes / Participation modes / wiki updated
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 00:03:18 -0000

On Thu, Apr 12, 2012 at 7:59 PM, Arturo Servin <aservin@lacnic.net> wrote:
>
> There has been a lot of discussion about different topics related, I wasn=
't
> sure what we were going to discuss.

hoping to actually get a running list started of 'topics that need
time for discussion', perhaps on the wiki even :)

> Thanks for clearing this out.

trying my best :)

> Regards,
> as
>
> On 12 Apr 2012, at 11:38, Tim Bruijnzeels wrote:
>
> Hi,
>
> On 12 Apr 2012, at 04:16, Christopher Morrow wrote:
>
> On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <aservin@lacnic.net> wrote=
:
>
> Chris,
>
>
> =A0 =A0 =A0 =A0For the agenda item: "Deployment Discussion -> Discuss the=
 need, and
> publication location/method, for documentation that details rollout of SI=
DR
> technologies in an operational network." Are we going to discuss what Tim
> suggested in his e-mail on March 30th (subject: =A0rpki repository and
> validation issues). I think he pointed out three valid points to discuss =
(at
> least start with the first 2 as he suggested):
>
>
>
> Actually no, Tim wanted to be able to present/be-in-person so the next
> time he can do that is the coincident meeting with IETF in Vancouver,
> BC.
>
>
> Indeed, I can't make the 30 April interim meeting (not even remote). And
> it's also too short notice to bring more real measurements and experience=
 (&
> measurements) from piloting possible alternatives to the table.
>
>
> I agree with Randy (if I understand his point correctly) that measurement=
s
> are needed to substantiate any discussion about the problems and possible
> alternatives. So... we actually plan to work on this over the following
> weeks (after the RIPE meeting):
>
> - Add an automated feedback feature to our validator so that we can get
> statistics from wherever people run it (if they enable the feature). We'r=
e
> thinking of measuring:
> =A0 =A0=3D average time to validate enabled TAs
> =A0 =A0=3D frequency of rsync repositories being unavailable
> =A0 =A0=3D frequency of validation corner cases occurring because we get =
a repo
> *while it is being updated* (eg mft out-of-sync with some object)
> =A0 =A0=3D I am open to suggestions of other stuff to measure..
>
> - Do a quick pilot implementation of some ideas:
> =A0 =A0=3D Use an rss like notification mechanism to alert RPs of updates
> =A0 =A0=3D Use http to fetch *consistent* deltas
> =A0 =A0=3D And then do the same measurements as above and possibly more w=
e can
> think of (like some controlled load stressing)
>
> Of course there are lots of details involved here that are interesting to
> discuss with other RP implementers, RPKI publishers and the sidr wg at
> large, but... we feel that at this stage we want to mature and try out ou=
r
> ideas first so that when we bring this to the table we'll have a reasonab=
le
> idea of whether it actually works in real code and helps to solve the rea=
l
> issues that we see. In short: we want to invest some energy in trying it =
out
> first, and then discuss more, rather than the other way around..
>
> Planning can always change, but it looks like we should be able to do thi=
s
> without spending too many of our resources and in time to report about it=
 in
> Vancouver.
>
> For the time being we will use the list of problems and requirements that=
 I
> formulated as a guideline for this pilot, but I am well aware that that l=
ist
> is subject to change when it's discussed in more detail in sidr on-list o=
r
> at a meeting..
>
>
> Tim
>
>

From jakob.heitz@ericsson.com  Thu Apr 12 20:59:35 2012
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE95621F871E; Thu, 12 Apr 2012 20:59:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.1
X-Spam-Level: 
X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[AWL=-0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rn6wLPicctaA; Thu, 12 Apr 2012 20:59:35 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 382A221F86F4; Thu, 12 Apr 2012 20:59:34 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q3D3xXeR000623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Apr 2012 22:59:34 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.55]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 12 Apr 2012 23:59:33 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: Jeffrey Haas <jhaas@pfrc.org>, Warren Kumari <warren@kumari.net>
Date: Thu, 12 Apr 2012 23:59:30 -0400
Thread-Topic: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
Thread-Index: Ac0X7mp45WFSp501Qb+tTgo50fNyTwBOdhVg
Message-ID: <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice>
In-Reply-To: <20120411142053.GA1283@slice>
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"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 03:59:35 -0000

On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:

> In the case where the paths are not congruent (which shouldn't happen
> unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across
> other BGP), we probably have some sort of hard error case.  One
> reasonable assumption is=20
> that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP
> speaker doing path manipulations for policy.  IMO, the proper
> behavior here is to *not* propagate the route at a BGPSEC ASBR
> boundary; any BGP speaker that manipulates the AS_PATH in such a way
> as to break the congruency of ASes between AS_PATH and signature MUST
> be a BGPSEC speaker.=20
>=20
> The above still doesn't deal with common deployment considerations
> such as as-override, replace-as and remove-private.

This just highlights the semantic difference between the BGPSEC
path and the AS_PATH.

They may be different legitimately. This is why we need both.

A receiver can make its own decision whether the difference
between the paths should cause path invalidation or not.
If a sender is legitimately manipulating an AS_PATH, then the
receiver should know about it and use this knowledge to help
in the decision.

--=20
Jakob Heitz.=

From ietfc@btconnect.com  Fri Apr 13 04:35:37 2012
Return-Path: <ietfc@btconnect.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE6921F8763; Fri, 13 Apr 2012 04:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vFTqaSaZ8TZ; Fri, 13 Apr 2012 04:35:36 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6243F21F875C; Fri, 13 Apr 2012 04:35:35 -0700 (PDT)
Received: from mail85-db3-R.bigfish.com (10.3.81.235) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 11:35:34 +0000
Received: from mail85-db3 (localhost [127.0.0.1])	by mail85-db3-R.bigfish.com (Postfix) with ESMTP id 89B2A2607CD; Fri, 13 Apr 2012 11:35:34 +0000 (UTC)
X-SpamScore: -32
X-BigFish: PS-32(zz9371I936eK542M1432N98dK7605jzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24h304l)
X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail85-db3 (localhost.localdomain [127.0.0.1]) by mail85-db3 (MessageSwitch) id 1334316933109976_4110; Fri, 13 Apr 2012 11:35:33 +0000 (UTC)
Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.245])	by mail85-db3.bigfish.com (Postfix) with ESMTP id 0C98E3C004A; Fri, 13 Apr 2012 11:35:33 +0000 (UTC)
Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 11:35:32 +0000
Received: from AMSPRD0104HT027.eurprd01.prod.exchangelabs.com (157.55.11.7) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.57.1; Fri, 13 Apr 2012 11:35:31 +0000
Message-ID: <014e01cd1960$f007a4c0$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, <sidr@ietf.org>, <sidr-chairs@ietf.org>, Sean Turner <turners@ieca.com>
References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> <CAL9jLaYXtePEJ1FyhxkKuRwFBiLPRN8pqT2va97-YG15Fqznvw@mail.gmail.com>
Date: Fri, 13 Apr 2012 12:33:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.55.11.7]
X-OriginatorOrg: btconnect.com
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 11:35:37 -0000

----- Original Message -----
From: "Christopher Morrow" <morrowc.lists@gmail.com>
To: <sidr@ietf.org>; <sidr-chairs@ietf.org>; "Sean Turner" <turners@ieca.com>;
"t.petch" <ietfc@btconnect.com>
Sent: Wednesday, March 28, 2012 2:33 PM
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt


Sean/Tom,
Tom had some comments on the previous (I believe) version of this
draft, are they addressed to your satisfaction Tom?

<tp>
Not really; it still says

"    o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in
      Section 3.9.5."
but the I-D has no section 3.9.5 so it is unclear what is meant.

And I [still] find it hard to parse
' The validation procedure used for BGPSEC Router Certificates is
   identical to the validation procedure described in Section 7 of
   [RFC6487] except that where "this specification" refers to [RFC6487]
   in that profile in this profile "this specification" is this
   document.'
{a bit like those brain teasers where a single sentence has 13 consecutive
'and's but lacks punctuation}

Tom Petch
</tp>


Sean, if Tom's ok with the changes, should we move this along?

-Chris
<cochair>

On Mon, Dec 5, 2011 at 1:20 PM,  <internet-drafts@ietf.org> wrote:
>
> 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 : A Profile for BGPSEC Router Certificates, Certificate Revocation
Lists, and Certification Requests
> Author(s) : Mark Reynolds
> Sean Turner
> Steve Kent
> Filename : draft-ietf-sidr-bgpsec-pki-profiles-01.txt
> Pages : 11
> Date : 2011-12-05
>
> This document defines a standard profile for X.509 certificates for
> the purposes of supporting validation of Autonomous System (AS) paths
> in the Border Gateway Protocol (BGP), as part of an extension to that
> protocol known as BGPSEC. BGP is a critical component for the proper
> operation of the Internet as a whole. The BGPSEC protocol is under
> development as a component to address the requirement to provide
> security for the BGP protocol. The goal of BGPSEC is to design a
> protocol for full AS path validation based on the use of strong
> cryptographic primitives. The end-entity (EE) certificates specified
> by this profile are issued under Resource Public Key Infrastructure
> (RPKI) Certification Authority (CA) certificates, containing the AS
> Identifier Delegation extension, to routers within the Autonomous
> System (AS). The certificate asserts that the router(s) holding the
> private key are authorized to send out secure route advertisements on
> behalf of the specified AS. This document also profiles the
> Certificate Revocation List (CRL), profiles the format of
> certification requests, and specifies Relying Party certificate path
> validation procedures. The document extends the RPKI; therefore,
> this documents updates the RPKI Resource Certificates Profile (draft-
> ietf-sidr-res-cert-profile).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr




From turners@ieca.com  Fri Apr 13 05:19:22 2012
Return-Path: <turners@ieca.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E19B521F8741 for <sidr@ietfa.amsl.com>; Fri, 13 Apr 2012 05:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.012
X-Spam-Level: 
X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1nqewIdzm6d for <sidr@ietfa.amsl.com>; Fri, 13 Apr 2012 05:19:22 -0700 (PDT)
Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.66.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4250A21F86E2 for <sidr@ietf.org>; Fri, 13 Apr 2012 05:19:22 -0700 (PDT)
Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id C51E633DC5463; Fri, 13 Apr 2012 07:19:21 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id B9FE233DC5438 for <sidr@ietf.org>; Fri, 13 Apr 2012 07:19:21 -0500 (CDT)
Received: from [71.191.2.177] (port=42032 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <turners@ieca.com>) id 1SIfTC-0006fT-U4; Fri, 13 Apr 2012 07:19:20 -0500
Message-ID: <4F8819C5.30507@ieca.com>
Date: Fri, 13 Apr 2012 08:19:17 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>
References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> <CAL9jLaYXtePEJ1FyhxkKuRwFBiLPRN8pqT2va97-YG15Fqznvw@mail.gmail.com> <014e01cd1960$f007a4c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <014e01cd1960$f007a4c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-71-191-2-177.washdc.east.verizon.net (thunderfish.local) [71.191.2.177]:42032
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 9
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 12:19:23 -0000

Tom,

Responses inline.

spt

On 4/13/12 6:33 AM, t.petch wrote:
> ----- Original Message -----
> From: "Christopher Morrow"<morrowc.lists@gmail.com>
> To:<sidr@ietf.org>;<sidr-chairs@ietf.org>; "Sean Turner"<turners@ieca.com>;
> "t.petch"<ietfc@btconnect.com>
> Sent: Wednesday, March 28, 2012 2:33 PM
> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>
>
> Sean/Tom,
> Tom had some comments on the previous (I believe) version of this
> draft, are they addressed to your satisfaction Tom?
>
> <tp>
> Not really; it still says
>
> "    o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in
>        Section 3.9.5."
> but the I-D has no section 3.9.5 so it is unclear what is meant.

So this has been there for a while :(  It should be pointing to the EKU 
defined in s3.1.3.1.  It's an just an OID you stick in the EKU extension.

> And I [still] find it hard to parse
> ' The validation procedure used for BGPSEC Router Certificates is
>     identical to the validation procedure described in Section 7 of
>     [RFC6487] except that where "this specification" refers to [RFC6487]
>     in that profile in this profile "this specification" is this
>     document.'
> {a bit like those brain teasers where a single sentence has 13 consecutive
> 'and's but lacks punctuation}

I'm trying to avoid copying all the text from 6487 over in to this 
draft.  I would just point there, but I can see somebody doing something 
silly like not understanding that the restrictions on the validation 
procedure are in bgpsec-pki-profiles draft.  So how about this:

   The validation procedure used for BGPSEC Router Certificates is
   identical to the validation procedure described in Section 7 of
   [RFC6487].  The exception is that the constraints applied come
   from this specification (e.g., in step 3: the certificate
   contains all the field that must be present - refers to the
   fields that are required by this specification).

> Tom Petch
> </tp>
>
>
> Sean, if Tom's ok with the changes, should we move this along?
>
> -Chris
> <cochair>
>
> On Mon, Dec 5, 2011 at 1:20 PM,<internet-drafts@ietf.org>  wrote:
>>
>> 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 : A Profile for BGPSEC Router Certificates, Certificate Revocation
> Lists, and Certification Requests
>> Author(s) : Mark Reynolds
>> Sean Turner
>> Steve Kent
>> Filename : draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>> Pages : 11
>> Date : 2011-12-05
>>
>> This document defines a standard profile for X.509 certificates for
>> the purposes of supporting validation of Autonomous System (AS) paths
>> in the Border Gateway Protocol (BGP), as part of an extension to that
>> protocol known as BGPSEC. BGP is a critical component for the proper
>> operation of the Internet as a whole. The BGPSEC protocol is under
>> development as a component to address the requirement to provide
>> security for the BGP protocol. The goal of BGPSEC is to design a
>> protocol for full AS path validation based on the use of strong
>> cryptographic primitives. The end-entity (EE) certificates specified
>> by this profile are issued under Resource Public Key Infrastructure
>> (RPKI) Certification Authority (CA) certificates, containing the AS
>> Identifier Delegation extension, to routers within the Autonomous
>> System (AS). The certificate asserts that the router(s) holding the
>> private key are authorized to send out secure route advertisements on
>> behalf of the specified AS. This document also profiles the
>> Certificate Revocation List (CRL), profiles the format of
>> certification requests, and specifies Relying Party certificate path
>> validation procedures. The document extends the RPKI; therefore,
>> this documents updates the RPKI Resource Certificates Profile (draft-
>> ietf-sidr-res-cert-profile).
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
>

From ietfc@btconnect.com  Fri Apr 13 11:35:13 2012
Return-Path: <ietfc@btconnect.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54121F8546; Fri, 13 Apr 2012 11:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx2rKk-Wj0tT; Fri, 13 Apr 2012 11:35:12 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 99E2B21F854A; Fri, 13 Apr 2012 11:34:52 -0700 (PDT)
Received: from mail110-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 13 Apr 2012 18:34:51 +0000
Received: from mail110-va3 (localhost [127.0.0.1])	by mail110-va3-R.bigfish.com (Postfix) with ESMTP id B16AF2A0699; Fri, 13 Apr 2012 18:34:51 +0000 (UTC)
X-SpamScore: -33
X-BigFish: PS-33(zzbb2dI9371I936eK542M1432N98dK7605jzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24h304l)
X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT007.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
Received: from mail110-va3 (localhost.localdomain [127.0.0.1]) by mail110-va3 (MessageSwitch) id 1334342090603731_13578; Fri, 13 Apr 2012 18:34:50 +0000 (UTC)
Received: from VA3EHSMHS019.bigfish.com (unknown [10.7.14.243])	by mail110-va3.bigfish.com (Postfix) with ESMTP id 8D359240272; Fri, 13 Apr 2012 18:34:50 +0000 (UTC)
Received: from DB3PRD0702HT007.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS019.bigfish.com (10.7.99.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 13 Apr 2012 18:34:47 +0000
Received: from CH1PRD0302HT002.namprd03.prod.outlook.com (157.55.61.146) by pod51017.outlook.com (10.3.4.168) with Microsoft SMTP Server (TLS) id 14.15.57.1; Fri, 13 Apr 2012 18:34:28 +0000
Message-ID: <002901cd199b$7708c0a0$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Sean Turner <turners@ieca.com>
References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> <CAL9jLaYXtePEJ1FyhxkKuRwFBiLPRN8pqT2va97-YG15Fqznvw@mail.gmail.com> <014e01cd1960$f007a4c0$4001a8c0@gateway.2wire.net> <4F8819C5.30507@ieca.com>
Date: Fri, 13 Apr 2012 19:32:48 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.55.61.146]
X-OriginatorOrg: btconnect.com
Cc: sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 18:35:13 -0000

----- Original Message -----
From: "Sean Turner" <turners@ieca.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Christopher Morrow" <morrowc.lists@gmail.com>; <sidr@ietf.org>;
<sidr-chairs@ietf.org>
Sent: Friday, April 13, 2012 2:19 PM

> Tom,
>
> Responses inline.
>

Sean

yes, that looks fine

Tom



> spt
>
> On 4/13/12 6:33 AM, t.petch wrote:
> > ----- Original Message -----
> > From: "Christopher Morrow"<morrowc.lists@gmail.com>
> > To:<sidr@ietf.org>;<sidr-chairs@ietf.org>; "Sean Turner"<turners@ieca.com>;
> > "t.petch"<ietfc@btconnect.com>
> > Sent: Wednesday, March 28, 2012 2:33 PM
> > Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
> >
> >
> > Sean/Tom,
> > Tom had some comments on the previous (I believe) version of this
> > draft, are they addressed to your satisfaction Tom?
> >
> > <tp>
> > Not really; it still says
> >
> > "    o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in
> >        Section 3.9.5."
> > but the I-D has no section 3.9.5 so it is unclear what is meant.
>
> So this has been there for a while :(  It should be pointing to the EKU
> defined in s3.1.3.1.  It's an just an OID you stick in the EKU extension.
>
> > And I [still] find it hard to parse
> > ' The validation procedure used for BGPSEC Router Certificates is
> >     identical to the validation procedure described in Section 7 of
> >     [RFC6487] except that where "this specification" refers to [RFC6487]
> >     in that profile in this profile "this specification" is this
> >     document.'
> > {a bit like those brain teasers where a single sentence has 13 consecutive
> > 'and's but lacks punctuation}
>
> I'm trying to avoid copying all the text from 6487 over in to this
> draft.  I would just point there, but I can see somebody doing something
> silly like not understanding that the restrictions on the validation
> procedure are in bgpsec-pki-profiles draft.  So how about this:
>
>    The validation procedure used for BGPSEC Router Certificates is
>    identical to the validation procedure described in Section 7 of
>    [RFC6487].  The exception is that the constraints applied come
>    from this specification (e.g., in step 3: the certificate
>    contains all the field that must be present - refers to the
>    fields that are required by this specification).
>
> > Tom Petch
> > </tp>
> >
> >
> > Sean, if Tom's ok with the changes, should we move this along?
> >
> > -Chris
> > <cochair>
> >
> > On Mon, Dec 5, 2011 at 1:20 PM,<internet-drafts@ietf.org>  wrote:
> >>
> >> 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 : A Profile for BGPSEC Router Certificates, Certificate Revocation
> > Lists, and Certification Requests
> >> Author(s) : Mark Reynolds
> >> Sean Turner
> >> Steve Kent
> >> Filename : draft-ietf-sidr-bgpsec-pki-profiles-01.txt
> >> Pages : 11
> >> Date : 2011-12-05
> >>
> >> This document defines a standard profile for X.509 certificates for
> >> the purposes of supporting validation of Autonomous System (AS) paths
> >> in the Border Gateway Protocol (BGP), as part of an extension to that
> >> protocol known as BGPSEC. BGP is a critical component for the proper
> >> operation of the Internet as a whole. The BGPSEC protocol is under
> >> development as a component to address the requirement to provide
> >> security for the BGP protocol. The goal of BGPSEC is to design a
> >> protocol for full AS path validation based on the use of strong
> >> cryptographic primitives. The end-entity (EE) certificates specified
> >> by this profile are issued under Resource Public Key Infrastructure
> >> (RPKI) Certification Authority (CA) certificates, containing the AS
> >> Identifier Delegation extension, to routers within the Autonomous
> >> System (AS). The certificate asserts that the router(s) holding the
> >> private key are authorized to send out secure route advertisements on
> >> behalf of the specified AS. This document also profiles the
> >> Certificate Revocation List (CRL), profiles the format of
> >> certification requests, and specifies Relying Party certificate path
> >> validation procedures. The document extends the RPKI; therefore,
> >> this documents updates the RPKI Resource Certificates Profile (draft-
> >> ietf-sidr-res-cert-profile).
> >>
> >>
> >> A URL for this Internet-Draft is:
> >>
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> This Internet-Draft can be retrieved at:
> >>
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
> >>
> >> _______________________________________________
> >> sidr mailing list
> >> sidr@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidr
> >
> >
> >
> >
>



From turners@ieca.com  Fri Apr 13 11:49:39 2012
Return-Path: <turners@ieca.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863C011E8098 for <sidr@ietfa.amsl.com>; Fri, 13 Apr 2012 11:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.682
X-Spam-Level: 
X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfMDycdjBgE4 for <sidr@ietfa.amsl.com>; Fri, 13 Apr 2012 11:49:38 -0700 (PDT)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.247.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4D80811E80C1 for <sidr@ietf.org>; Fri, 13 Apr 2012 11:49:38 -0700 (PDT)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 9D83D33F16468; Fri, 13 Apr 2012 13:49:37 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 90BE033F16448 for <sidr@ietf.org>; Fri, 13 Apr 2012 13:49:37 -0500 (CDT)
Received: from [96.231.121.181] (port=37281 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <turners@ieca.com>) id 1SIlYu-0007O1-EZ; Fri, 13 Apr 2012 13:49:37 -0500
Message-ID: <4F88753F.5030607@ieca.com>
Date: Fri, 13 Apr 2012 14:49:35 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>
References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> <CAL9jLaYXtePEJ1FyhxkKuRwFBiLPRN8pqT2va97-YG15Fqznvw@mail.gmail.com> <014e01cd1960$f007a4c0$4001a8c0@gateway.2wire.net> <4F8819C5.30507@ieca.com> <002901cd199b$7708c0a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <002901cd199b$7708c0a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-96-231-121-181.washdc.east.verizon.net (thunderfish.local) [96.231.121.181]:37281
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 11
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 18:49:39 -0000

Tom,

Okay posting new version shortly.

spt

On 4/13/12 1:32 PM, t.petch wrote:
> ----- Original Message -----
> From: "Sean Turner"<turners@ieca.com>
> To: "t.petch"<ietfc@btconnect.com>
> Cc: "Christopher Morrow"<morrowc.lists@gmail.com>;<sidr@ietf.org>;
> <sidr-chairs@ietf.org>
> Sent: Friday, April 13, 2012 2:19 PM
>
>> Tom,
>>
>> Responses inline.
>>
>
> Sean
>
> yes, that looks fine
>
> Tom
>
>
>
>> spt
>>
>> On 4/13/12 6:33 AM, t.petch wrote:
>>> ----- Original Message -----
>>> From: "Christopher Morrow"<morrowc.lists@gmail.com>
>>> To:<sidr@ietf.org>;<sidr-chairs@ietf.org>; "Sean Turner"<turners@ieca.com>;
>>> "t.petch"<ietfc@btconnect.com>
>>> Sent: Wednesday, March 28, 2012 2:33 PM
>>> Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>>
>>>
>>> Sean/Tom,
>>> Tom had some comments on the previous (I believe) version of this
>>> draft, are they addressed to your satisfaction Tom?
>>>
>>> <tp>
>>> Not really; it still says
>>>
>>> "    o BGPSEC Router Certificates MUST include the BGPSEC EKU defined in
>>>         Section 3.9.5."
>>> but the I-D has no section 3.9.5 so it is unclear what is meant.
>>
>> So this has been there for a while :(  It should be pointing to the EKU
>> defined in s3.1.3.1.  It's an just an OID you stick in the EKU extension.
>>
>>> And I [still] find it hard to parse
>>> ' The validation procedure used for BGPSEC Router Certificates is
>>>      identical to the validation procedure described in Section 7 of
>>>      [RFC6487] except that where "this specification" refers to [RFC6487]
>>>      in that profile in this profile "this specification" is this
>>>      document.'
>>> {a bit like those brain teasers where a single sentence has 13 consecutive
>>> 'and's but lacks punctuation}
>>
>> I'm trying to avoid copying all the text from 6487 over in to this
>> draft.  I would just point there, but I can see somebody doing something
>> silly like not understanding that the restrictions on the validation
>> procedure are in bgpsec-pki-profiles draft.  So how about this:
>>
>>     The validation procedure used for BGPSEC Router Certificates is
>>     identical to the validation procedure described in Section 7 of
>>     [RFC6487].  The exception is that the constraints applied come
>>     from this specification (e.g., in step 3: the certificate
>>     contains all the field that must be present - refers to the
>>     fields that are required by this specification).
>>
>>> Tom Petch
>>> </tp>
>>>
>>>
>>> Sean, if Tom's ok with the changes, should we move this along?
>>>
>>> -Chris
>>> <cochair>
>>>
>>> On Mon, Dec 5, 2011 at 1:20 PM,<internet-drafts@ietf.org>   wrote:
>>>>
>>>> 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 : A Profile for BGPSEC Router Certificates, Certificate Revocation
>>> Lists, and Certification Requests
>>>> Author(s) : Mark Reynolds
>>>> Sean Turner
>>>> Steve Kent
>>>> Filename : draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>>> Pages : 11
>>>> Date : 2011-12-05
>>>>
>>>> This document defines a standard profile for X.509 certificates for
>>>> the purposes of supporting validation of Autonomous System (AS) paths
>>>> in the Border Gateway Protocol (BGP), as part of an extension to that
>>>> protocol known as BGPSEC. BGP is a critical component for the proper
>>>> operation of the Internet as a whole. The BGPSEC protocol is under
>>>> development as a component to address the requirement to provide
>>>> security for the BGP protocol. The goal of BGPSEC is to design a
>>>> protocol for full AS path validation based on the use of strong
>>>> cryptographic primitives. The end-entity (EE) certificates specified
>>>> by this profile are issued under Resource Public Key Infrastructure
>>>> (RPKI) Certification Authority (CA) certificates, containing the AS
>>>> Identifier Delegation extension, to routers within the Autonomous
>>>> System (AS). The certificate asserts that the router(s) holding the
>>>> private key are authorized to send out secure route advertisements on
>>>> behalf of the specified AS. This document also profiles the
>>>> Certificate Revocation List (CRL), profiles the format of
>>>> certification requests, and specifies Relying Party certificate path
>>>> validation procedures. The document extends the RPKI; therefore,
>>>> this documents updates the RPKI Resource Certificates Profile (draft-
>>>> ietf-sidr-res-cert-profile).
>>>>
>>>>
>>>> A URL for this Internet-Draft is:
>>>>
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> This Internet-Draft can be retrieved at:
>>>>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-01.txt
>>>>
>>>> _______________________________________________
>>>> sidr mailing list
>>>> sidr@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sidr
>>>
>>>
>>>
>>>
>>
>
>
>

From internet-drafts@ietf.org  Fri Apr 13 12:03:05 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE421F85F1; Fri, 13 Apr 2012 12:03:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1lpwjMGeBPV; Fri, 13 Apr 2012 12:03:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4921F85CE; Fri, 13 Apr 2012 12:03:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120413190305.19914.96099.idtracker@ietfa.amsl.com>
Date: Fri, 13 Apr 2012 12:03:05 -0700
Cc: sidr@ietf.org
Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-pki-profiles-03.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 19:03:06 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Secure Inter-Domain Routing Working G=
roup of the IETF.

	Title           : A Profile for BGPSEC Router Certificates, Certificate Re=
vocation Lists, and Certification Requests
	Author(s)       : Mark Reynolds
                          Sean Turner
                          Steve Kent
	Filename        : draft-ietf-sidr-bgpsec-pki-profiles-03.txt
	Pages           : 11
	Date            : 2012-04-13

   This document defines a standard profile for X.509 certificates for
   the purposes of supporting validation of Autonomous System (AS) paths
   in the Border Gateway Protocol (BGP), as part of an extension to that
   protocol known as BGPSEC.  BGP is a critical component for the proper
   operation of the Internet as a whole.  The BGPSEC protocol is under
   development as a component to address the requirement to provide
   security for the BGP protocol.  The goal of BGPSEC is to design a
   protocol for full AS path validation based on the use of strong
   cryptographic primitives.  The end-entity (EE) certificates specified
   by this profile are issued under Resource Public Key Infrastructure
   (RPKI) Certification Authority (CA) certificates, containing the AS
   Identifier Delegation extension, to routers within the Autonomous
   System (AS).  The certificate asserts that the router(s) holding the
   private key are authorized to send out secure route advertisements on
   behalf of the specified AS.  This document also profiles the
   Certificate Revocation List (CRL), profiles the format of
   certification requests, and specifies Relying Party certificate path
   validation procedures.  The document extends the RPKI; therefore,
   this documents updates the RPKI Resource Certificates Profile (RFC
   6487).


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.=
txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.t=
xt


From christopher.morrow@gmail.com  Fri Apr 13 13:16:36 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6211E80F1; Fri, 13 Apr 2012 13:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.478
X-Spam-Level: 
X-Spam-Status: No, score=-103.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zByHQ6qubzgM; Fri, 13 Apr 2012 13:16:36 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9DB11E80E2; Fri, 13 Apr 2012 13:16:36 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so5271887obb.31 for <multiple recipients>; Fri, 13 Apr 2012 13:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=exaOfubMW7taYYKf0BLpbjJzvIa8EUFvT8PAq4VghII=; b=KSBW899pzkZxle4JSh/m1/EPAZS1OjMUW/8F/mXFrJGTK+dkLX2i7mUfYO7Q87/J1N mN9Rv66zSzRdlHfjHIk4yY9Yt9gnTp/ELYo57OaCe/O8yUhFxiWxJBYRiISF+jLzP0e2 3UwQlMLPoOsHiBsW2nzFxBE8P5Uiha5h3cawzZpV8rlsGb+26Mf1pT3Ol+waPuj8UAgx Cuw4BINh4dMPq2LcY8qZ5dHC/SN4YEEJZ1HFOxtyxV+njnzi+GSUKxyKbKIQDloirjGh a9e40ubn2MGVnw8MCjuS9zr/gyDGCVWZYdl4NZBa6i1FW1V+jl8uOY7UCgvT0qnx3Uez r26g==
MIME-Version: 1.0
Received: by 10.182.54.114 with SMTP id i18mr4125136obp.49.1334348195807; Fri, 13 Apr 2012 13:16:35 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.153.34 with HTTP; Fri, 13 Apr 2012 13:16:35 -0700 (PDT)
Date: Fri, 13 Apr 2012 16:16:35 -0400
X-Google-Sender-Auth: 2x9rMh-n15rDmFO3TL0-NQJQuwQ
Message-ID: <CAL9jLaZ6y7TAGx844e65ReJsaUFW5sOGNKKMUth3G4VMZV8Z8g@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: sidr@ietf.org, sidr-chairs@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 20:16:37 -0000

Helo WG peoples,
The following update posted today. Sean and Tom have come to agreement
on their differences, I believe this closes the last open items on
this document.

Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012

Thanks!
-Chris
<co-chair>

On Fri, Apr 13, 2012 at 3:03 PM,  <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the Secure Inter-Domain Routing Working=
 Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Profile for BGPSEC Router Ce=
rtificates, Certificate Revocation Lists, and Certification Requests
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mark Reynolds
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sean Turner
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Steve Kent
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-pki-profi=
les-03.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-13
>
> =A0 This document defines a standard profile for X.509 certificates for
> =A0 the purposes of supporting validation of Autonomous System (AS) paths
> =A0 in the Border Gateway Protocol (BGP), as part of an extension to that
> =A0 protocol known as BGPSEC. =A0BGP is a critical component for the prop=
er
> =A0 operation of the Internet as a whole. =A0The BGPSEC protocol is under
> =A0 development as a component to address the requirement to provide
> =A0 security for the BGP protocol. =A0The goal of BGPSEC is to design a
> =A0 protocol for full AS path validation based on the use of strong
> =A0 cryptographic primitives. =A0The end-entity (EE) certificates specifi=
ed
> =A0 by this profile are issued under Resource Public Key Infrastructure
> =A0 (RPKI) Certification Authority (CA) certificates, containing the AS
> =A0 Identifier Delegation extension, to routers within the Autonomous
> =A0 System (AS). =A0The certificate asserts that the router(s) holding th=
e
> =A0 private key are authorized to send out secure route advertisements on
> =A0 behalf of the specified AS. =A0This document also profiles the
> =A0 Certificate Revocation List (CRL), profiles the format of
> =A0 certification requests, and specifies Relying Party certificate path
> =A0 validation procedures. =A0The document extends the RPKI; therefore,
> =A0 this documents updates the RPKI Resource Certificates Profile (RFC
> =A0 6487).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-0=
3.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03=
.txt
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

From brian.peter.dickson@gmail.com  Fri Apr 13 14:26:54 2012
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2401A11E8128; Fri, 13 Apr 2012 14:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.441
X-Spam-Level: 
X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.157,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3XRsX6zDEfg; Fri, 13 Apr 2012 14:26:53 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1D6911E8123; Fri, 13 Apr 2012 14:26:52 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5930001wib.13 for <multiple recipients>; Fri, 13 Apr 2012 14:26:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7veVTsum3hoUeEQ2X33U2Aviq+MZfFaRiOtsPfX2OyU=; b=lRmzAiqR2QNL4B9ih/3jgyxYS69/JngBkVLPTx+12td8GfL8tf/tcQwTXt6xhG5GUi 9fy5JuIb5TDWKCGyE10vGYy3q58dEy4zvlEESDEtsmg9gv2XXxf+loji2FHqgrsHmJVi O7LuV6+gU3U3U9+014FnzQNWRPNG0Qo6k0kjc+m2HjrWzoj12WNsv6elSZgm4RxQ5O8p mdeObXeJEc9hTAc/nxV+MWs9TgULNss8Shvx5dom6WsWINhESNmiT+Yip9YrGlrPSNsk tJXBY6lmRRUK7rkU5kw1eb91WYjR4UG/miJ2obwBkAmRCdz70S6I9tjXZaa3LWHw4Lcl MFDg==
MIME-Version: 1.0
Received: by 10.180.100.230 with SMTP id fb6mr9217635wib.3.1334352411855; Fri, 13 Apr 2012 14:26:51 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Fri, 13 Apr 2012 14:26:51 -0700 (PDT)
In-Reply-To: <CAL9jLaZ6y7TAGx844e65ReJsaUFW5sOGNKKMUth3G4VMZV8Z8g@mail.gmail.com>
References: <CAL9jLaZ6y7TAGx844e65ReJsaUFW5sOGNKKMUth3G4VMZV8Z8g@mail.gmail.com>
Date: Fri, 13 Apr 2012 17:26:51 -0400
Message-ID: <CAH1iCir2HQXtkNuRqHunAXYwt-VkTF8Yfhn7hNNyFsgGomda9g@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>
Content-Type: multipart/alternative; boundary=f46d041824ee838b2a04bd96211b
Cc: sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 21:26:54 -0000

--f46d041824ee838b2a04bd96211b
Content-Type: text/plain; charset=ISO-8859-1

While I think the document may be pretty solid currently, the meta-issue of
the tail wagging the dog exists.

I.e. There still exists the potential for additional requirements to
surface,
related to the design and implementation of the bgpsec protocol, which have
the potential to "inform" additional requirements for the EE certs, and/or
other (new) cert types.

So, even if it passes WGLC intact, I'm of the opinion that it should be
kept in the "hold" buffer,
until the other work goes through more substantial development and review
cycles.

Brian

On Fri, Apr 13, 2012 at 4:16 PM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> Helo WG peoples,
> The following update posted today. Sean and Tom have come to agreement
> on their differences, I believe this closes the last open items on
> this document.
>
> Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012
>
> Thanks!
> -Chris
> <co-chair>
>
> On Fri, Apr 13, 2012 at 3:03 PM,  <internet-drafts@ietf.org> wrote:
> >
> > 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           : A Profile for BGPSEC Router Certificates,
> Certificate Revocation Lists, and Certification Requests
> >        Author(s)       : Mark Reynolds
> >                          Sean Turner
> >                          Steve Kent
> >        Filename        : draft-ietf-sidr-bgpsec-pki-profiles-03.txt
> >        Pages           : 11
> >        Date            : 2012-04-13
> >
> >   This document defines a standard profile for X.509 certificates for
> >   the purposes of supporting validation of Autonomous System (AS) paths
> >   in the Border Gateway Protocol (BGP), as part of an extension to that
> >   protocol known as BGPSEC.  BGP is a critical component for the proper
> >   operation of the Internet as a whole.  The BGPSEC protocol is under
> >   development as a component to address the requirement to provide
> >   security for the BGP protocol.  The goal of BGPSEC is to design a
> >   protocol for full AS path validation based on the use of strong
> >   cryptographic primitives.  The end-entity (EE) certificates specified
> >   by this profile are issued under Resource Public Key Infrastructure
> >   (RPKI) Certification Authority (CA) certificates, containing the AS
> >   Identifier Delegation extension, to routers within the Autonomous
> >   System (AS).  The certificate asserts that the router(s) holding the
> >   private key are authorized to send out secure route advertisements on
> >   behalf of the specified AS.  This document also profiles the
> >   Certificate Revocation List (CRL), profiles the format of
> >   certification requests, and specifies Relying Party certificate path
> >   validation procedures.  The document extends the RPKI; therefore,
> >   this documents updates the RPKI Resource Certificates Profile (RFC
> >   6487).
> >
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt
> >
> > _______________________________________________
> > sidr mailing list
> > sidr@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>

--f46d041824ee838b2a04bd96211b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

While I think the document may be pretty solid currently, the meta-issue of=
 the tail wagging the dog exists.<br><br>I.e. There still exists the potent=
ial for additional requirements to surface,<br>related to the design and im=
plementation of the bgpsec protocol, which have<br>
the potential to &quot;inform&quot; additional requirements for the EE cert=
s, and/or other (new) cert types.<br><br>So, even if it passes WGLC intact,=
 I&#39;m of the opinion that it should be kept in the &quot;hold&quot; buff=
er,<br>
until the other work goes through more substantial development and review c=
ycles.<br><br>Brian<br><br><div class=3D"gmail_quote">On Fri, Apr 13, 2012 =
at 4:16 PM, Christopher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:morr=
owc.lists@gmail.com">morrowc.lists@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Helo WG peoples,<br>
The following update posted today. Sean and Tom have come to agreement<br>
on their differences, I believe this closes the last open items on<br>
this document.<br>
<br>
Let&#39;s start a WGLC for this, ending: 4/27/2012 or 27/4/2012<br>
<br>
Thanks!<br>
-Chris<br>
&lt;co-chair&gt;<br>
<br>
On Fri, Apr 13, 2012 at 3:03 PM, =A0&lt;<a href=3D"mailto:internet-drafts@i=
etf.org">internet-drafts@ietf.org</a>&gt; wrote:<br>
&gt;<br>
&gt; A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories. This draft is a work item of the Secure Inter-Domain Routing Work=
ing Group of the IETF.<br>
&gt;<br>
&gt; =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : A Profile for BGPSEC Router=
 Certificates, Certificate Revocation Lists, and Certification Requests<br>
&gt; =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Mark Reynolds<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sean Turner<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Steve Kent<br>
&gt; =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sidr-bgpsec-pki-pr=
ofiles-03.txt<br>
&gt; =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 11<br>
&gt; =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-04-13<br>
&gt;<br>
&gt; =A0 This document defines a standard profile for X.509 certificates fo=
r<br>
&gt; =A0 the purposes of supporting validation of Autonomous System (AS) pa=
ths<br>
&gt; =A0 in the Border Gateway Protocol (BGP), as part of an extension to t=
hat<br>
&gt; =A0 protocol known as BGPSEC. =A0BGP is a critical component for the p=
roper<br>
&gt; =A0 operation of the Internet as a whole. =A0The BGPSEC protocol is un=
der<br>
&gt; =A0 development as a component to address the requirement to provide<b=
r>
&gt; =A0 security for the BGP protocol. =A0The goal of BGPSEC is to design =
a<br>
&gt; =A0 protocol for full AS path validation based on the use of strong<br=
>
&gt; =A0 cryptographic primitives. =A0The end-entity (EE) certificates spec=
ified<br>
&gt; =A0 by this profile are issued under Resource Public Key Infrastructur=
e<br>
&gt; =A0 (RPKI) Certification Authority (CA) certificates, containing the A=
S<br>
&gt; =A0 Identifier Delegation extension, to routers within the Autonomous<=
br>
&gt; =A0 System (AS). =A0The certificate asserts that the router(s) holding=
 the<br>
&gt; =A0 private key are authorized to send out secure route advertisements=
 on<br>
&gt; =A0 behalf of the specified AS. =A0This document also profiles the<br>
&gt; =A0 Certificate Revocation List (CRL), profiles the format of<br>
&gt; =A0 certification requests, and specifies Relying Party certificate pa=
th<br>
&gt; =A0 validation procedures. =A0The document extends the RPKI; therefore=
,<br>
&gt; =A0 this documents updates the RPKI Resource Certificates Profile (RFC=
<br>
&gt; =A0 6487).<br>
&gt;<br>
&gt;<br>
&gt; A URL for this Internet-Draft is:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-=
pki-profiles-03.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/=
draft-ietf-sidr-bgpsec-pki-profiles-03.txt</a><br>
&gt;<br>
&gt; Internet-Drafts are also available by anonymous FTP at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:=
//ftp.ietf.org/internet-drafts/</a><br>
&gt;<br>
&gt; This Internet-Draft can be retrieved at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-p=
ki-profiles-03.txt" target=3D"_blank">ftp://ftp.ietf.org/internet-drafts/dr=
aft-ietf-sidr-bgpsec-pki-profiles-03.txt</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; sidr mailing list<br>
&gt; <a href=3D"mailto:sidr@ietf.org">sidr@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/sidr</a><br>
_______________________________________________<br>
sidr mailing list<br>
<a href=3D"mailto:sidr@ietf.org">sidr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/sidr</a><br>
</blockquote></div><br>

--f46d041824ee838b2a04bd96211b--

From brian.peter.dickson@gmail.com  Fri Apr 13 15:05:47 2012
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBF311E8132; Fri, 13 Apr 2012 15:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.12
X-Spam-Level: 
X-Spam-Status: No, score=-3.12 tagged_above=-999 required=5 tests=[AWL=-0.321,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFHDaEJAbDVT; Fri, 13 Apr 2012 15:05:46 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6168B11E8130; Fri, 13 Apr 2012 15:05:45 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so5946771wib.13 for <multiple recipients>; Fri, 13 Apr 2012 15:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dfeaOQ2ILu+gazCrOKxXaLJNognTO5oRcfIyNK86Q/U=; b=ajYof+ZQo1A19O3N3Ad081KYFat1YHzVhN5UI4XyU5OLgUYHg1i7G9/FgnjhS9mX9f TrEx5d75tih+ecQVpPp2ry4Akdi7jhT/ZCkxvPdW6OKGnMWJCv+awMhuwUTaDdOIwaBJ WuBWo872tkqO60a4g0rXeFuNIxfbAQ81JM2iGN6QZJ48s6v5bK4aY8xAlpog92yYIM7h JnVCTXvs+so3Kg1IcqzqQZ4ZtwZJeLV6GguOVo9/XsuXaE0ZFmylvZQNbgx0Opji6Krj QsKAgoTnCcUWBNcJp1uIzi0okDzxLEbVvXBqrkEaUftMrmT4ONI1pPFCdjwbdahmCrnR phiA==
MIME-Version: 1.0
Received: by 10.180.95.129 with SMTP id dk1mr8528114wib.3.1334354744598; Fri, 13 Apr 2012 15:05:44 -0700 (PDT)
Received: by 10.223.88.212 with HTTP; Fri, 13 Apr 2012 15:05:44 -0700 (PDT)
In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se>
References: <D7A0423E5E193F40BE6E94126930C4930B96182E71@MBCLUSTER.xchange.nist.gov> <4F828D6D.10907@raszuk.net> <D7A0423E5E193F40BE6E94126930C4930B96C507DA@MBCLUSTER.xchange.nist.gov> <4F830E75.70606@raszuk.net> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F1533@Hermes.columbia.ads.sparta.com> <4F832F5E.9030903@raszuk.net> <0BD03B75-CA3A-4CBA-BBF4-E2100AFA64E4@kumari.net> <4F846121.2050408@raszuk.net> <CAL9jLaYF-MW1cJ2n28BiV1mi+tpPS2ECKB2UxhFMQ=NXxbihCg@mail.gmail.com> <D7CF4F8F-AF93-43F2-BC0D-26E072307B4F@kumari.net> <20120411142053.GA1283@slice> <7309FCBCAE981B43ABBE69B31C8D21391B3EE94001@EUSAACMS0701.eamcs.ericsson.se>
Date: Fri, 13 Apr 2012 18:05:44 -0400
Message-ID: <CAH1iCiqDMocKtyFSHH70jmBTRvw=1unQqzW3C3Pzy=bDswEaag@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: Jakob Heitz <jakob.heitz@ericsson.com>
Content-Type: multipart/alternative; boundary=f46d0444ee2d8e634304bd96ac1a
Cc: "idr@ietf.org List" <idr@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] [Idr]  iBGP, BGPSEC and incremental deployment (was No BGPSEC intradomain ?)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 22:05:47 -0000

--f46d0444ee2d8e634304bd96ac1a
Content-Type: text/plain; charset=ISO-8859-1

At the risk of opening a can of worms (or at least seeing a cylindrical
hollow metal labeled "Caution: contains worms")...

I believe the larger issue is, that Authentication is orthogonal to
Authorization.

As it currently stands, only Authentication has been given any
consideration, per se.

The two things being Authenticated are:
o  Origination (prefix + ASN, and maybe other identifying elements such as
IP addresses of routers), and
o   ASNs in the AS_PATH.

What is not explicitly being discussed, is, the question of "What is $foo
Authorized to do?".

E.g. The implicit assumption is, Only ASN==X is allowed to originate
prefixes whose AS_PATH "starts" (ends) with X.
And, the other implicit assumption is, the only thing any ASN is permitted
to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more
times.

However, it may be worth considering all the other things that are done by
ASNs currently:
o   Private ASNs being stripped (private leaf ASNs)
o   Confederations
o   Route Servers
o   ECMP and friends
o   other vendor-specific or multi-vendor stuff being done to the AS-Path
(replace-as, as-sets, etc.)

Rather than dogmatically ignoring these issues, or declare them "out of
scope!!!",
I would prefer to see a rational discussion on whether there is a suitable
place in the system,
to facilitate some way of handling these cases, in a way that does not
weaken the security model.

Basically, rather than just say, "Okay, if you want to do this, turn off
BGPSEC", I think there is
value in saying, "To do this, you need to add $X to $Y to authorize this
activity", so that
RPs are able to reconcile what they receive, with what the RPKI-encoded
data says they
should expect.

For example:
Say that ASs A, B, and C, exchange routes via a route-server AS S.
Each of A, B, and C encode something that says, roughly:
"I am okay with NLRIs I send to S, have S omitted from the AS_PATH", and,
"I am okay with S sending me NLRIs that have S omitted, so long as the
immediate AS after S, also allows S to omit itself".
So, a signature block "R B S C Q" can be reconciled with an AS_PATH of "R B
C Q", by seeing the S sig,
and the rules for C->S and S->B allow this, established respectively by all
of C, S, and B.

The difference between this, and the whole "pCount==0" thing, is that the
above is an explicit policy encoded in the RPKI,
which can be validated more than one hop away from S.

The "pCount==0" logic is only truly verifiable by the immediate recipient,
and then only by the operator's personal implementation for enforcing local
policy (which itself be weak or faulty).

A recipient of an BGPSEC_Signatures_Block which has any pCount==0 in the
middle, currently has no way of ascertaining the legitimacy of that
occurrence.
The Signature Block (AS/N) of "R/1 B/1 S/0 C/1 Q/1" is consistent with an
AS_PATH of "R B C Q", but there is no way to know if this is in fact
sensible.

For other examples:
Private ASNs are, by definition, not unique.
However, it would still be nice to be able to identify their owners, e.g.
by IP address, and validate ASN substitutions by RPKI, based on
Origination/Signature data.

Proxy Origination would also be nice to have Authorization of Delegation
(to sign), possibly chained.
E.g. A delegates signature_origination to B, who delegates
signature_origination to C.
Prefixes assigned to A, could be signed by C, but would validate only if
the signed AS_PATH was "C B A".

I'm sure there are plenty of other use cases, which match up with actual
operator practices today.

If the mechanics of this can be done in a scalable and secure manner, this
will greatly enhance deployment likelihood, and ease deployment itself.

(This is where the IETF in general, can redeem itself for its past sins.
Don't ignore real needs, regardless of how tempting it is to keep designs
"pure".)

IMHO.

Brian

P.S. This kind of complex stuff really begs face-to-face meeting time. It
is hard to convey intent via messages. Oh, the irony...

On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heitz <jakob.heitz@ericsson.com>wrote:

> On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas <> wrote:
>
> > In the case where the paths are not congruent (which shouldn't happen
> > unlike the AS4_PATH case in RFC 4893 - we don't tunnel bgpsec across
> > other BGP), we probably have some sort of hard error case.  One
> > reasonable assumption is
> > that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP
> > speaker doing path manipulations for policy.  IMO, the proper
> > behavior here is to *not* propagate the route at a BGPSEC ASBR
> > boundary; any BGP speaker that manipulates the AS_PATH in such a way
> > as to break the congruency of ASes between AS_PATH and signature MUST
> > be a BGPSEC speaker.
> >
> > The above still doesn't deal with common deployment considerations
> > such as as-override, replace-as and remove-private.
>
> This just highlights the semantic difference between the BGPSEC
> path and the AS_PATH.
>
> They may be different legitimately. This is why we need both.
>
> A receiver can make its own decision whether the difference
> between the paths should cause path invalidation or not.
> If a sender is legitimately manipulating an AS_PATH, then the
> receiver should know about it and use this knowledge to help
> in the decision.
>
> --
> Jakob Heitz.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

--f46d0444ee2d8e634304bd96ac1a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

At the risk of opening a can of worms (or at least seeing a cylindrical hol=
low metal labeled &quot;Caution: contains worms&quot;)...<br><br>I believe =
the larger issue is, that Authentication is orthogonal to Authorization.<br=
>
<br>As it currently stands, only Authentication has been given any consider=
ation, per se.<br><br>The two things being Authenticated are:<br>o=A0 Origi=
nation (prefix + ASN, and maybe other identifying elements such as IP addre=
sses of routers), and <br>
o=A0=A0 ASNs in the AS_PATH.<br><br>What is not explicitly being discussed,=
 is, the question of &quot;What is $foo Authorized to do?&quot;.<br><br>E.g=
. The implicit assumption is, Only ASN=3D=3DX is allowed to originate prefi=
xes whose AS_PATH &quot;starts&quot; (ends) with X.<br>
And, the other implicit assumption is, the only thing any ASN is permitted =
to do, is to prepend its own ASN to the AS_PATH, (zero or) one or more time=
s.<br><br>However, it may be worth considering all the other things that ar=
e done by ASNs currently:<br>
o =A0 Private ASNs being stripped (private leaf ASNs)<br>o =A0 Confederatio=
ns<br>o =A0 Route Servers<br>o =A0 ECMP and friends<br>o =A0 other vendor-s=
pecific or multi-vendor stuff being done to the AS-Path (replace-as, as-set=
s, etc.)<br>
<br>Rather than dogmatically ignoring these issues, or declare them &quot;o=
ut of scope!!!&quot;,<br>I would prefer to see a rational discussion on whe=
ther there is a suitable place in the system,<br>to facilitate some way of =
handling these cases, in a way that does not weaken the security model.<br>
<br>Basically, rather than just say, &quot;Okay, if you want to do this, tu=
rn off BGPSEC&quot;, I think there is<br>value in saying, &quot;To do this,=
 you need to add $X to $Y to authorize this activity&quot;, so that<br>
RPs are able to reconcile what they receive, with what the RPKI-encoded dat=
a says they<br>should expect.<br><br>For example:<br>Say that ASs A, B, and=
 C, exchange routes via a route-server AS S.<br>Each of A, B, and C encode =
something that says, roughly:<br>
&quot;I am okay with NLRIs I send to S, have S omitted from the AS_PATH&quo=
t;, and,<br>&quot;I am okay with S sending me NLRIs that have S omitted, so=
 long as the immediate AS after S, also allows S to omit itself&quot;.<br>
So, a signature block &quot;R B S C Q&quot; can be reconciled with an AS_PA=
TH of &quot;R B C Q&quot;, by seeing the S sig,<br>and the rules for C-&gt;=
S and S-&gt;B allow this, established respectively by all of C, S, and B.<b=
r>
<br>The difference between this, and the whole &quot;pCount=3D=3D0&quot; th=
ing, is that the above is an explicit policy encoded in the RPKI,<br>which =
can be validated more than one hop away from S.<br><br>The &quot;pCount=3D=
=3D0&quot; logic is only truly verifiable by the immediate recipient, and t=
hen only by the operator&#39;s personal implementation for enforcing local =
policy (which itself be weak or faulty).<br>
<br>A recipient of an BGPSEC_Signatures_Block which has any pCount=3D=3D0 i=
n the middle, currently has no way of ascertaining the legitimacy of that o=
ccurrence.<br>The Signature Block (AS/N) of &quot;R/1 B/1 S/0 C/1 Q/1&quot;=
 is consistent with an AS_PATH of &quot;R B C Q&quot;, but there is no way =
to know if this is in fact sensible.<br>
<br>For other examples:<br>Private ASNs are, by definition, not unique.<br>=
However, it would still be nice to be able to identify their owners, e.g. b=
y IP address, and validate ASN substitutions by RPKI, based on Origination/=
Signature data.<br>
<br>Proxy Origination would also be nice to have Authorization of Delegatio=
n (to sign), possibly chained.<br>E.g. A delegates signature_origination to=
 B, who delegates signature_origination to C.<br>Prefixes assigned to A, co=
uld be signed by C, but would validate only if the signed AS_PATH was &quot=
;C B A&quot;.<br>
<br>I&#39;m sure there are plenty of other use cases, which match up with a=
ctual operator practices today.<br><br>If the mechanics of this can be done=
 in a scalable and secure manner, this will greatly enhance deployment like=
lihood, and ease deployment itself.<br>
<br>(This is where the IETF in general, can redeem itself for its past sins=
. Don&#39;t ignore real needs, regardless of how tempting it is to keep des=
igns &quot;pure&quot;.)<br><br>IMHO.<br><br>Brian<br><br>P.S. This kind of =
complex stuff really begs face-to-face meeting time. It is hard to convey i=
ntent via messages. Oh, the irony...<br>
<br><div class=3D"gmail_quote">On Thu, Apr 12, 2012 at 11:59 PM, Jakob Heit=
z <span dir=3D"ltr">&lt;<a href=3D"mailto:jakob.heitz@ericsson.com">jakob.h=
eitz@ericsson.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Wednesday, April 11, 2012 7:21 AM, Jeffrey Haas &lt;&g=
t; wrote:<br>
<br>
</div><div class=3D"im">&gt; In the case where the paths are not congruent =
(which shouldn&#39;t happen<br>
&gt; unlike the AS4_PATH case in RFC 4893 - we don&#39;t tunnel bgpsec acro=
ss<br>
&gt; other BGP), we probably have some sort of hard error case. =A0One<br>
&gt; reasonable assumption is<br>
&gt; that a non-BGPSEC speaker mucked with the AS_PATH - perhaps an iBGP<br=
>
&gt; speaker doing path manipulations for policy. =A0IMO, the proper<br>
&gt; behavior here is to *not* propagate the route at a BGPSEC ASBR<br>
&gt; boundary; any BGP speaker that manipulates the AS_PATH in such a way<b=
r>
&gt; as to break the congruency of ASes between AS_PATH and signature MUST<=
br>
&gt; be a BGPSEC speaker.<br>
&gt;<br>
&gt; The above still doesn&#39;t deal with common deployment considerations=
<br>
&gt; such as as-override, replace-as and remove-private.<br>
<br>
</div>This just highlights the semantic difference between the BGPSEC<br>
path and the AS_PATH.<br>
<br>
They may be different legitimately. This is why we need both.<br>
<br>
A receiver can make its own decision whether the difference<br>
between the paths should cause path invalidation or not.<br>
If a sender is legitimately manipulating an AS_PATH, then the<br>
receiver should know about it and use this knowledge to help<br>
in the decision.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Jakob Heitz.<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
Idr mailing list<br>
<a href=3D"mailto:Idr@ietf.org">Idr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_blank">htt=
ps://www.ietf.org/mailman/listinfo/idr</a><br>
</div></div></blockquote></div><br>

--f46d0444ee2d8e634304bd96ac1a--

From internet-drafts@ietf.org  Mon Apr 16 17:07:09 2012
Return-Path: <internet-drafts@ietf.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A5011E80EC; Mon, 16 Apr 2012 17:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiv+q3Tv2yhw; Mon, 16 Apr 2012 17:07:09 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D3111E8075; Mon, 16 Apr 2012 17:07:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120417000709.10790.50966.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2012 17:07:09 -0700
Cc: sidr@ietf.org
Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-05.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Apr 2012 00:07:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Secure Inter-Domain Routing Working G=
roup of the IETF.

	Title           : BGP Prefix Origin Validation
	Author(s)       : Pradosh Mohapatra
                          John Scudder
                          David Ward
                          Randy Bush
                          Rob Austein
	Filename        : draft-ietf-sidr-pfx-validate-05.txt
	Pages           : 11
	Date            : 2012-04-16

   To help reduce well-known threats against BGP including prefix mis-
   announcing and monkey-in-the-middle attacks, one of the security
   requirements is the ability to validate the origination AS of BGP
   routes.  More specifically, one needs to validate that the AS number
   claiming to originate an address prefix (as derived from the AS_PATH
   attribute of the BGP route) is in fact authorized by the prefix
   holder to do so.  This document describes a simple validation
   mechanism to partially satisfy this requirement.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-05.txt


From kent@bbn.com  Wed Apr 18 09:57:10 2012
Return-Path: <kent@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA621F84D1 for <sidr@ietfa.amsl.com>; Wed, 18 Apr 2012 09:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.581
X-Spam-Level: 
X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb3A60ccNYa6 for <sidr@ietfa.amsl.com>; Wed, 18 Apr 2012 09:57:10 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 43EAB21F8484 for <sidr@ietf.org>; Wed, 18 Apr 2012 09:57:10 -0700 (PDT)
Received: from dhcp89-089-239.bbn.com ([128.89.89.239]:49250) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SKYBS-000AVF-95; Wed, 18 Apr 2012 12:56:46 -0400
Mime-Version: 1.0
Message-Id: <p06240805cbb4a2a7de03@[128.89.89.239]>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB7D7@Hermes.columbia.ads.sparta.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F6CB7D7@Hermes.columbia.ads.sparta.com>
Date: Wed, 18 Apr 2012 12:57:01 -0400
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: "draft-ietf-sidr-cps-irs@tools.ietf.org" <draft-ietf-sidr-cps-irs@tools.ietf.org>, "draft-ietf-sidr-cps-isp@tools.ietf.org" <draft-ietf-sidr-cps-isp@tools.ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] status of draft-ietf-sidr-cps-irs and draft-ietf-sidr-cps-isp
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Apr 2012 16:57:10 -0000

At 5:38 PM +0000 3/28/12, Murphy, Sandra wrote:
>These two drafts have been expired for a good while now.  Do the 
>authors intend to pick them up now that the CP document is published?
>
>The wg should take a look at these and see if there is still 
>interest in pursuing them.
>
>--Sandy, speaking as wg co-chair

We anticipate creating a single CPS, to replace the two docs.  But
we do not have time to resume  work at this point, so it may be a while ...

Steve

From stbryant@cisco.com  Fri Apr 20 09:31:46 2012
Return-Path: <stbryant@cisco.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9E21F864D; Fri, 20 Apr 2012 09:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.547
X-Spam-Level: 
X-Spam-Status: No, score=-110.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pECdiAylQTU; Fri, 20 Apr 2012 09:31:46 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C930821F856F; Fri, 20 Apr 2012 09:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=469; q=dns/txt; s=iport; t=1334939506; x=1336149106; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=4etiABmUb2tqdKUgnPIE6fN+Ku2DBiPKk6GUl56SL/c=; b=DpSS+vR6EQSfjyX6xrHV+bD1/ALllpLwrDe6Bk/jBeuXat9Vt1sbxOmL yGKaebx0yo/e20wWKqLvsIpQDaH8TRV95lfMKcqmHj2U1hxBWxbRUwT86 bGpPpQseR3Sye2+as3bssfOuaHjnJO+7Wy/NOQ4gHhWMb2z2+1Zc8Dl5R Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av4EAGuOkU+Q/khM/2dsb2JhbABEsTiBB4IiAQIjQAE8FhgDAgECAUsNAQUCAQEeh22aWIM/EIFOmxiQZwSVeY5UgQJngmg
X-IronPort-AV: E=Sophos;i="4.75,454,1330905600"; d="scan'208";a="135796299"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2012 16:31:44 +0000
Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3KGViQb001318; Fri, 20 Apr 2012 16:31:44 GMT
Received: from stbryant-mac2.local (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q3KGVfv6008443; Fri, 20 Apr 2012 17:31:42 +0100 (BST)
Message-ID: <4F918F6D.4080309@cisco.com>
Date: Fri, 20 Apr 2012 17:31:41 +0100
From: Stewart Bryant <stbryant@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: sidr wg list <sidr@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Chris Morrow <morrowc@ops-netman.net>, "iesg@ietf.org" <iesg@ietf.org>
Subject: [sidr] Alexey  Melnikov - third SIDR Chair
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stbryant@cisco.com
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 16:31:47 -0000

I have decided to appoint Alexey  Melnikov
<alexey.melnikov@isode.com> as an additional
chair of the SIDR Working Group.

I have asked Alexey to initially focus on the process
aspects of running the SIDR WG, leaving Sandy
and Chris with more time to focus on the
technology aspects of the WG.

I appreciate the considerable contribution that
Sandy and Chris make to the SIDR WG and thank
Alexey for being prepared to help with the
workload.

- Stewart

From Sandra.Murphy@sparta.com  Thu Apr 26 12:41:10 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AC221E8192 for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 12:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJNH6F6AQ2Tm for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 12:41:10 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F96321E8194 for <sidr@ietf.org>; Thu, 26 Apr 2012 12:41:06 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3QJf6Bd007187 for <sidr@ietf.org>; Thu, 26 Apr 2012 14:41:06 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3QJf2Ca011917 for <sidr@ietf.org>; Thu, 26 Apr 2012 14:41:02 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 15:41:02 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: agenda and reminder for Apr 30 (Monday) meeting.
Thread-Index: Ac0j49e9VMw8072LQ9mDsUw+UpafNQ==
Date: Thu, 26 Apr 2012 19:41:01 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F704435@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.137]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sidr] agenda and reminder for Apr 30 (Monday) meeting.
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 19:41:10 -0000

There has been a rearrangement of the agenda items to help out some speaker=
s' time restrictions.=0A=
=0A=
The new agenda moves the pfx-validate discussion to the first thing on the =
agenda.=0A=
=0A=
The agenda is  posted at http://trac.tools.ietf.org/wg/sidr/trac/wiki/Inter=
imMeeting20120430=0A=
=0A=
0900-0910 Agenda bashing, note well, blue sheets, etc=0A=
0910-1010 Prefix Validate Discussion=0A=
1010-1200 Deployment Discussion (walkthrough/document/discuss deployment sc=
enarios)=0A=
1300-1400 Deployment Discussion (walkthrough/document/discuss deployment sc=
enarios)=0A=
1400-1700 Router / Prefix / ROA / CRL - RPKI Repository Data Freshness=0A=
=0A=
The location is also noted on the wiki page: =0A=
=0A=
"The interim SIDR meeting will be held at an office:=0A=
=0A=
    1818 Library St Suite 400 Reston, VA 20190"=0A=
=0A=
=0A=
--Sandy, speaking as wg co-chair=

From Sandra.Murphy@sparta.com  Thu Apr 26 13:01:37 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8110021F8753 for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 13:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFjzMHgfrdU7 for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 13:01:36 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CA05421F8751 for <sidr@ietf.org>; Thu, 26 Apr 2012 13:01:36 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3QK1aiB007461 for <sidr@ietf.org>; Thu, 26 Apr 2012 15:01:36 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3QK1Z7j012660 for <sidr@ietf.org>; Thu, 26 Apr 2012 15:01:36 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 26 Apr 2012 16:01:35 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: attendees at interim 30 Apr meeting
Thread-Index: AQHNI+dTs2w0WyZoiEm2jooiJ4YsUg==
Date: Thu, 26 Apr 2012 20:01:34 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F70444F@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sidr] attendees at interim 30 Apr meeting
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 20:01:37 -0000

The attendees who have registered for the sidr interim meeting on Mon Apr 3=
0 are recorded at:=0A=
=0A=
http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430-attende=
es=0A=
=0A=
If you believe that you did register, and do not see your name on this list=
, please forward your original registration message to the registration add=
ress sidr-chairs+reg04302012@ietf.org.=0A=
=0A=
The room capacity is getting tight, so if  you no longer plan to attend in =
person, please also send that info to the chairs.=0A=
=0A=
--Sandy, speaking as wg co-chair=

From wwwrun@rfc-editor.org  Thu Apr 26 14:13:51 2012
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D6D11E80B1 for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 14:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.207
X-Spam-Level: 
X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IilAyZoQJlLS for <sidr@ietfa.amsl.com>; Thu, 26 Apr 2012 14:13:51 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5637411E80B0 for <sidr@ietf.org>; Thu, 26 Apr 2012 14:13:51 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 41631B1E002; Thu, 26 Apr 2012 14:12:20 -0700 (PDT)
To: mlepinski@bbn.com, achi@bbn.com, kent@bbn.com, stbryant@cisco.com, adrian@olddog.co.uk, alexey.melnikov@isode.com, Sandra.Murphy@sparta.com, morrowc@ops-netman.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120426211220.41631B1E002@rfc-editor.org>
Date: Thu, 26 Apr 2012 14:12:20 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, sidr@ietf.org
Subject: [sidr] [Editorial Errata Reported] RFC6488 (3203)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2012 21:13:52 -0000

The following errata report has been submitted for RFC6488,
"Signed Object Template for the Resource Public Key Infrastructure (RPKI)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6488&eid=3203

--------------------------------------
Type: Editorial
Reported by: David Mandelberg <dmandelb@bbn.com>

Section: Table of Con

Original Text
-------------
                  2.1.6.7. unsigneAttrs ...............................8

Corrected Text
--------------
                  2.1.6.7. unsignedAttrs ..............................8

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6488 (draft-ietf-sidr-signed-object-04)
--------------------------------------
Title               : Signed Object Template for the Resource Public Key Infrastructure (RPKI)
Publication Date    : February 2012
Author(s)           : M. Lepinski, A. Chi, S. Kent
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From wwwrun@rfc-editor.org  Fri Apr 27 11:55:23 2012
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1202221F875A for <sidr@ietfa.amsl.com>; Fri, 27 Apr 2012 11:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.343
X-Spam-Level: 
X-Spam-Status: No, score=-102.343 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9trIw943dPOZ for <sidr@ietfa.amsl.com>; Fri, 27 Apr 2012 11:55:22 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A89D21F8749 for <sidr@ietf.org>; Fri, 27 Apr 2012 11:55:22 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4D4BFB1E002; Fri, 27 Apr 2012 11:53:48 -0700 (PDT)
To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, stbryant@cisco.com, adrian@olddog.co.uk, alexey.melnikov@isode.com, Sandra.Murphy@sparta.com, morrowc@ops-netman.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20120427185348.4D4BFB1E002@rfc-editor.org>
Date: Fri, 27 Apr 2012 11:53:48 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, sidr@ietf.org
Subject: [sidr] [Technical Errata Reported] RFC6487 (3205)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2012 18:55:23 -0000

The following errata report has been submitted for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3205

--------------------------------------
Type: Technical
Reported by: David Mandelberg <dmandelb@bbn.com>

Section: 5

Original Text
-------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed.

Corrected Text
--------------
   An RPKI CA MUST include the two extensions, Authority Key Identifier
   and CRL Number, in every CRL that it issues.  RPs MUST be prepared to
   process CRLs with these extensions.  No other CRL extensions are
   allowed. The extensions mentioned above MUST NOT appear more than once
   each.

Notes
-----


Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From christopher.morrow@gmail.com  Fri Apr 27 13:14:56 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6695121E8011; Fri, 27 Apr 2012 13:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.554
X-Spam-Level: 
X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCz35IJdIe7l; Fri, 27 Apr 2012 13:14:55 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88AF321F864F; Fri, 27 Apr 2012 13:14:55 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1705335obb.31 for <multiple recipients>; Fri, 27 Apr 2012 13:14:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=s1GzZ7GyNHBECayxNpF2T5MYm1JSkXr0k4rl84M+Rs0=; b=qwYkeuGfbxU54a/tCKWzplq5wOgAxA1L6c86Uk4eHmZ6bHfHB4HJG7gBNq7ccS+Qbd P9Y+Bh7KXkMP/32l8sBXr0xNhIBbxf8l5ZGLufGWACzloJG3QFnI+Ard9WrxCc3EU+FO e5JLp1s5wIeTcP4UY4+lgc5SDlO74wdX1Mov5xeeyxg24d7C+3tH1c1XtjhKrZGTCLV6 rfmQbufFu1v/Hvmi3mw/bAgJyrvO63odlK2HuQIglw/zkI+LNguAoPcaqpgHsldDmk6p YcM674JW37+5DXUYS0gs+44PrL9cnoukIn2mE97kCHe3EWjsax7HrsDKxyNGm/KXcKR4 9mcw==
MIME-Version: 1.0
Received: by 10.60.25.162 with SMTP id d2mr16999285oeg.30.1335557695120; Fri, 27 Apr 2012 13:14:55 -0700 (PDT)
Received: by 10.182.155.39 with HTTP; Fri, 27 Apr 2012 13:14:55 -0700 (PDT)
Date: Fri, 27 Apr 2012 16:14:55 -0400
Message-ID: <CAL9jLaZZL5=61aoKvu6codi7K=o+WOjj5g-Xrmx42wvmf3ZcSw@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
To: sidr@ietf.org, sidr-chairs@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [sidr] Notes for Monday Interim meeting
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2012 20:14:56 -0000

Howdy sidr folk, especially those attending in person:
1) no more space is available, all people post 04/27/2012 16:13 EDT
are going to have to be actually virtual (see webex details on wiki)
2) if you are on the agenda to present please send slides NOW... or
very soon to NOW.
3) see you all there (virtually or physically) we should have people
available to navigate you to a seat at ~8:30am.

-chris
<co-chair-2 of 3>

From Sandra.Murphy@sparta.com  Fri Apr 27 13:27:57 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C3421F866A for <sidr@ietfa.amsl.com>; Fri, 27 Apr 2012 13:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.564
X-Spam-Level: 
X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd6I4Iq0gJX1 for <sidr@ietfa.amsl.com>; Fri, 27 Apr 2012 13:27:56 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 17DD921F864F for <sidr@ietf.org>; Fri, 27 Apr 2012 13:27:55 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3RKRsSp017102 for <sidr@ietf.org>; Fri, 27 Apr 2012 15:27:54 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3RKRp2D011244 for <sidr@ietf.org>; Fri, 27 Apr 2012 15:27:51 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 27 Apr 2012 16:27:51 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: date/time/logistics for Jun meeting in association with nanog
Thread-Index: AQHNJLQ3k8m5ei44xEqRhYx+ajp7cQ==
Date: Fri, 27 Apr 2012 20:27:50 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sidr] date/time/logistics for Jun meeting in association with nanog
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2012 20:27:57 -0000

One of the upcoming sidr interim meetings is scheduled to be held in associ=
ation with NANOG 55 in Vancouver.  The hope was to attract operators from N=
ANOG to attend the sidr meeting.=0A=
=0A=
Originally, there were indications that NANOG might be able to provide meet=
ing room support for an interim sidr meeting on Wednesday afternoon, 6 Jun.=
  For that reason, 6 Jun was chosen as the date for the meeting.=0A=
=0A=
However, it was pointed out on the list that 6 Jun is World IPv6 Launch Day=
 (http://www.worldipv6launch.org/).  Many operators and many sidr members m=
ight have other demands on their hands on that day.=0A=
=0A=
Also, NANOG has just told us that they would be able to provide meeting roo=
m support, but only on Sunday 3 Jun, 0800-1200.=0A=
=0A=
Please respond as to whether you would accept moving the interim meeting to=
 3 Jun.=0A=
=0A=
[Understand that if the wg desires to keep to the original 6 Jun date, othe=
r arrangements will have to be made for meeting space, which may require a =
fee.]=0A=
=0A=
--Sandy, speaking as wg co-chair=

From tim@ripe.net  Sat Apr 28 03:37:00 2012
Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A364521F86CA for <sidr@ietfa.amsl.com>; Sat, 28 Apr 2012 03:37:00 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOZCdkaaCvRr for <sidr@ietfa.amsl.com>; Sat, 28 Apr 2012 03:37:00 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id BEEBE21F86C9 for <sidr@ietf.org>; Sat, 28 Apr 2012 03:36:59 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SO51M-0004NC-79; Sat, 28 Apr 2012 12:36:57 +0200
Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-13.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SO51L-0001LF-S2; Sat, 28 Apr 2012 12:36:56 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F704435@Hermes.columbia.ads.sparta.com>
Date: Sat, 28 Apr 2012 12:36:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7409CFC6-82D2-41EA-B493-2CEE882342A3@ripe.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F704435@Hermes.columbia.ads.sparta.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
X-Mailer: Apple Mail (2.1084)
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120428 clean
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d7dcfc43ab2075c25996235101d195cd
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] agenda and reminder for Apr 30 (Monday) meeting.
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Apr 2012 10:37:00 -0000

Hi,

Unfortunately I cannot attend. So please allow me to briefly sum up what =
I would have liked to contribute to this discussion if I could have been =
there..

On 26 Apr 2012, at 21:41, Murphy, Sandra wrote:
> The agenda is  posted at =
http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430
>=20
> 0900-0910 Agenda bashing, note well, blue sheets, etc
> 0910-1010 Prefix Validate Discussion
> 1010-1200 Deployment Discussion (walkthrough/document/discuss =
deployment scenarios)
> 1300-1400 Deployment Discussion (walkthrough/document/discuss =
deployment scenarios)
> 1400-1700 Router / Prefix / ROA / CRL - RPKI Repository Data Freshness

Most importantly I would really like to see conclusions resulting from =
any of these discussion documented as requirements for the repository =
and retrieval mechanisms and RP tooling.

For example:
=3D I believe that for prefix validate it's not only important that the =
objects are cryptographically valid, but an RP also needs to be sure it =
knows *all* ROAs.
=3D If data is found to be incomplete, ie RP does not have all ROAs, can =
the RP then stick to the last known consistent state for a given CA? (I =
believe this is the only safe bet..)
=3D With regards to stale data, is there a sane limit to *how* stale =
data can be? Days? Hours? Something relative to the intended lifespan of =
the manifest?
=3D Freshness: well obviously the fresher, the better... but are there =
any quantifiable hard limits, like new router certs should propagate to =
all RPs in X hours under normal operations?

New ideas and discussing pilots (like we're planning to do) for =
repository infrastructure improvements are planned for the the interim =
meeting before the Vancouver IETF, so I don't mean to go into too much =
detail on that here and now. Except that concrete input from this =
meeting, phrased as requirements, is very welcome as it will help to =
evaluate if new ideas actually solve the perceived problems adequately.

Cheers
Tim=

From christopher.morrow@gmail.com  Sun Apr 29 13:54:28 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AE321F85B6; Sun, 29 Apr 2012 13:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.561
X-Spam-Level: 
X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMBwcewU5P6N; Sun, 29 Apr 2012 13:54:27 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42EF121F85B5; Sun, 29 Apr 2012 13:54:27 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so63517obb.31 for <multiple recipients>; Sun, 29 Apr 2012 13:54:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lJuVPVx5cK2U5f3KJ8e//gBCHyVVwRXOTvtpI0jYN+M=; b=FDqlQ0vBmeoDMXP47hAm5EikD8hy5KXD0RL0B+9EKK2Nvv+WSfzUg1TeJBu4SPvd59 kR0BOg2Pyk0MbQc4WSVHprXbMLo+rWVlrTxaKdTGPHgM8GHp4pcQJGy7KZabUBJSXcAR pRWmWyqCvC0MSE6x40XA9FZ9L2LK3sJACcnBwvseLwZEJpNO3sixofAz+NjoLzOyshMq BTjkWKqPQAYPubH6MpPSvhB9ALrzrj1/AgpKSG9WHyrAAconumovgT0fQXmaAC4FyzQ2 xyPTm6WbVabh5hc6/Wu3iBd01c0/fIDb8sWTGDpOXAuyYHhWDr2YC2BzboO0AlyQsj1U 7stg==
MIME-Version: 1.0
Received: by 10.182.16.1 with SMTP id b1mr9733078obd.31.1335732866845; Sun, 29 Apr 2012 13:54:26 -0700 (PDT)
Received: by 10.182.155.39 with HTTP; Sun, 29 Apr 2012 13:54:26 -0700 (PDT)
Date: Sun, 29 Apr 2012 16:54:26 -0400
Message-ID: <CAL9jLaZqx5i6FafuKpDjqGupPvwdvsTS06YU9jokDYM4ak=Ojg@mail.gmail.com>
From: Christopher Morrow <christopher.morrow@gmail.com>
To: sidr@ietf.org, sidr-chairs@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [sidr] Apr 30 Interim Meeting final pre-meeting-info
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2012 20:54:28 -0000

Folks that are arriving on-site:
  1) please bring a usb-headset (or whatever flavor you think works
for you, remember this is supposed to be fully virtual a meeting)
  2) webex details are on the WIKI [0]
  3) arrival at ~-08:45am should be good, I ought to be on-site about
then as well
  4) we will have coffee locally in the office, w00t!
  5) jabber details will be updated on the WIKI [0]
      (sidr@jabber.ietf.org)

See you all (virtually even) there tomorrow morning.
-chris
<co-chair-2-of-3>

From morrowc@ops-netman.net  Sun Apr 29 13:58:37 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C6D21F85A8; Sun, 29 Apr 2012 13:58:37 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpbtp-WQv0ic; Sun, 29 Apr 2012 13:58:37 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id EFE2121F85A7; Sun, 29 Apr 2012 13:58:36 -0700 (PDT)
Received: from [192.168.1.125] (c-98-204-226-233.hsd1.va.comcast.net [98.204.226.233]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 1BC153200A1; Sun, 29 Apr 2012 20:58:33 +0000 (UTC)
Message-ID: <4F9DAB79.6030706@ops-netman.net>
Date: Sun, 29 Apr 2012 16:58:33 -0400
From: Chris Morrow <morrowc@ops-netman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: Christopher Morrow <christopher.morrow@gmail.com>
References: <CAL9jLaZqx5i6FafuKpDjqGupPvwdvsTS06YU9jokDYM4ak=Ojg@mail.gmail.com>
In-Reply-To: <CAL9jLaZqx5i6FafuKpDjqGupPvwdvsTS06YU9jokDYM4ak=Ojg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] Apr 30 Interim Meeting final pre-meeting-info
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Apr 2012 20:58:37 -0000

On 04/29/2012 04:54 PM, Christopher Morrow wrote:
> Folks that are arriving on-site:
>    1) please bring a usb-headset (or whatever flavor you think works
> for you, remember this is supposed to be fully virtual a meeting)
>    2) webex details are on the WIKI [0]
>    3) arrival at ~-08:45am should be good, I ought to be on-site about
> then as well
>    4) we will have coffee locally in the office, w00t!
>    5) jabber details will be updated on the WIKI [0]
>        (sidr@jabber.ietf.org)
>
> See you all (virtually even) there tomorrow morning.
> -chris
> <co-chair-2-of-3>

[0]: http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430

From gih@apnic.net  Sun Apr 29 22:14:51 2012
Return-Path: <gih@apnic.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6264821F85D7; Sun, 29 Apr 2012 22:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.929
X-Spam-Level: 
X-Spam-Status: No, score=-99.929 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-LCeSqRf4p5; Sun, 29 Apr 2012 22:14:50 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id DD24821F85D4; Sun, 29 Apr 2012 22:14:48 -0700 (PDT)
Received: from [202.158.221.120] (unknown [202.158.221.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2DBABB685D; Mon, 30 Apr 2012 15:14:47 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <4F9DAB79.6030706@ops-netman.net>
Date: Mon, 30 Apr 2012 15:14:46 +1000
Content-Transfer-Encoding: 7bit
Message-Id: <01B8B7E9-243D-4EBB-BD09-7F547766D369@apnic.net>
References: <CAL9jLaZqx5i6FafuKpDjqGupPvwdvsTS06YU9jokDYM4ak=Ojg@mail.gmail.com> <4F9DAB79.6030706@ops-netman.net>
To: Chris Morrow <morrowc@ops-netman.net>
X-Mailer: Apple Mail (2.1257)
Cc: Christopher Morrow <christopher.morrow@gmail.com>, sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] Apr 30 Interim Meeting final pre-meeting-info
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 05:14:51 -0000

For those virtual folk, 8:45 am in which timezone please?

On 30/04/2012, at 6:58 AM, Chris Morrow wrote:

> 
> 
> On 04/29/2012 04:54 PM, Christopher Morrow wrote:
>> Folks that are arriving on-site:
>>   1) please bring a usb-headset (or whatever flavor you think works
>> for you, remember this is supposed to be fully virtual a meeting)
>>   2) webex details are on the WIKI [0]
>>   3) arrival at ~-08:45am should be good, I ought to be on-site about
>> then as well
>>   4) we will have coffee locally in the office, w00t!
>>   5) jabber details will be updated on the WIKI [0]
>>       (sidr@jabber.ietf.org)
>> 
>> See you all (virtually even) there tomorrow morning.
>> -chris
>> <co-chair-2-of-3>
> 
> [0]: http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
gih@apnic.net





From morrowc@ops-netman.net  Sun Apr 29 22:37:52 2012
Return-Path: <morrowc@ops-netman.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1296021F8562; Sun, 29 Apr 2012 22:37:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbMMo67Qygbo; Sun, 29 Apr 2012 22:37:51 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id A2EDA21F846A; Sun, 29 Apr 2012 22:37:51 -0700 (PDT)
Received: from [IPv6:2001:470:e03a:b00b:2941:d0fc:9c:2396] (unknown [IPv6:2001:470:e03a:b00b:2941:d0fc:9c:2396]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id C0797320089; Mon, 30 Apr 2012 05:37:46 +0000 (UTC)
Date: Mon, 30 Apr 2012 01:37:45 -0400
From: morrowc@ops-netman.net
To: Geoff Huston <gih@apnic.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Message-Id: <20120430053751.A2EDA21F846A@ietfa.amsl.com>
Cc: Christopher Morrow <christopher.morrow@gmail.com>, sidr-chairs@ietf.org, sidr@ietf.org
Subject: Re: [sidr] Apr 30 Interim Meeting final pre-meeting-info
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 05:37:52 -0000

RWR0IEkgdGhvdWdodCB0aGUgd2lraSBzYWlkOygKCg==


From Sandra.Murphy@sparta.com  Mon Apr 30 04:15:41 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8B621F8596; Mon, 30 Apr 2012 04:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.566
X-Spam-Level: 
X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWN-p3tXGCbH; Mon, 30 Apr 2012 04:15:41 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0958D21F8592; Mon, 30 Apr 2012 04:15:40 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3UBFXN8029093; Mon, 30 Apr 2012 06:15:33 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3UBFWCD014974; Mon, 30 Apr 2012 06:15:33 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 07:15:32 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: Geoff Huston <gih@apnic.net>, Chris Morrow <morrowc@ops-netman.net>
Thread-Topic: [sidr] Apr 30 Interim Meeting final pre-meeting-info
Thread-Index: AQHNJkpLzn8dNlIOfUGyRS1UzGat6JayjCaAgACKpACAACFXqg==
Date: Mon, 30 Apr 2012 11:15:31 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F704A54@Hermes.columbia.ads.sparta.com>
References: <CAL9jLaZqx5i6FafuKpDjqGupPvwdvsTS06YU9jokDYM4ak=Ojg@mail.gmail.com> <4F9DAB79.6030706@ops-netman.net>, <01B8B7E9-243D-4EBB-BD09-7F547766D369@apnic.net>
In-Reply-To: <01B8B7E9-243D-4EBB-BD09-7F547766D369@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Christopher Morrow <christopher.morrow@gmail.com>, "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Apr 30 Interim Meeting final pre-meeting-info
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 11:15:41 -0000

Times are in EDT:  UTC-4.

--Sandy

________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Geoff Hust=
on [gih@apnic.net]
Sent: Monday, April 30, 2012 1:14 AM
To: Chris Morrow
Cc: Christopher Morrow; sidr-chairs@ietf.org; sidr@ietf.org
Subject: Re: [sidr] Apr 30 Interim Meeting final pre-meeting-info

For those virtual folk, 8:45 am in which timezone please?

On 30/04/2012, at 6:58 AM, Chris Morrow wrote:

>
>
> On 04/29/2012 04:54 PM, Christopher Morrow wrote:
>> Folks that are arriving on-site:
>>   1) please bring a usb-headset (or whatever flavor you think works
>> for you, remember this is supposed to be fully virtual a meeting)
>>   2) webex details are on the WIKI [0]
>>   3) arrival at ~-08:45am should be good, I ought to be on-site about
>> then as well
>>   4) we will have coffee locally in the office, w00t!
>>   5) jabber details will be updated on the WIKI [0]
>>       (sidr@jabber.ietf.org)
>>
>> See you all (virtually even) there tomorrow morning.
>> -chris
>> <co-chair-2-of-3>
>
> [0]: http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120430
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

--

Geoff Huston
Chief Scientist, APNIC

+61 7 3858 3100
gih@apnic.net




_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr=

From Sandra.Murphy@sparta.com  Mon Apr 30 04:21:34 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6010721F850C for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 04:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.567
X-Spam-Level: 
X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=1.031, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qo+iIAW8C5iu for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 04:21:33 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 25FEA21F84B8 for <sidr@ietf.org>; Mon, 30 Apr 2012 04:21:33 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3UBLWHI029127 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:21:32 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3UBLWnN015045 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:21:32 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 07:21:32 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: Invitation to Web seminar: firstinterimbeforeVancouver
Thread-Index: AQHNGLxtua1kpbzqAEuq4ZBTpV73S5azVFLW
Date: Mon, 30 Apr 2012 11:21:31 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F704A81@Hermes.columbia.ads.sparta.com>
References: <1663656271.20241334242579513.JavaMail.nobody@rva2rmd001.webex.com>
In-Reply-To: <1663656271.20241334242579513.JavaMail.nobody@rva2rmd001.webex.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: multipart/mixed; boundary="_004_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_"
MIME-Version: 1.0
Subject: [sidr] FW: Invitation to Web seminar: firstinterimbeforeVancouver
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 11:21:34 -0000

--_004_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_
Content-Type: multipart/alternative;
	boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_"

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

For those attending remotely, here is the full webex invitation.



--Sandy





________________________________
From: messenger@webex.com [messenger@webex.com]
Sent: Thursday, April 12, 2012 10:56 AM
To: Murphy, Sandra
Subject: Invitation to Web seminar: firstinterimbeforeVancouver

[https://ietf.webex.com/adm0306ld/siteadmin/html/img/header.gif]

Hello sidr members

Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.

Topic: firstinterimbeforeVancouver
Host: Secure Inter-Domain Routing Working Group
Date and Time:
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)
Event number: 649 888 520
Event password: restonva

-------------------------------------------------------
To join the online event
-------------------------------------------------------
1. Click here <https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&t=3D=
a&EA=3Dsandra.murphy%40sparta.com&ET=3D13e4b33025818412b7e2b20f292831c3&ETR=
=3D3c0e7f8bbc278c716edae649ca2f55ac&RT=3DMiMxMQ=3D=3D&p> to join the online=
 event.
Or copy and paste the following link to a browser:
https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&t=3Da&EA=3Dsandra.m=
urphy%40sparta.com&ET=3D13e4b33025818412b7e2b20f292831c3&ETR=3D3c0e7f8bbc27=
8c716edae649ca2f55ac&RT=3DMiMxMQ=3D=3D&p
2. Click "Join Now".


-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 649 888 520

-------------------------------------------------------
For assistance
-------------------------------------------------------
You can contact Secure Inter-Domain Routing Working Group at:
sidr-chairs@tools.ietf.org<mailto:sidr-chairs@tools.ietf.org>

The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://ietf.webex.com/ietf/onstage/systemdiagnosis.php


<https://owa.sparta.com/owa/UrlBlockedError.aspx>

http://www.webex.com

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


[https://ietf.webex.com/adm0306ld/siteadmin/html/img/footer.gif]

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Arial;color: #000000;font-size: 1=
0pt;">
<p>For those attending remotely, here is the full webex invitation.</p>
<p>&nbsp;</p>
<p>--Sandy</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF393595"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>From:</b> messenger@webex.com [messenger@webex=
.com]<br>
<b>Sent:</b> Thursday, April 12, 2012 10:56 AM<br>
<b>To:</b> Murphy, Sandra<br>
<b>Subject:</b> Invitation to Web seminar: firstinterimbeforeVancouver<br>
</font><br>
</div>
<div></div>
<div><img border=3D"0" alt=3D"" src=3D"https://ietf.webex.com/adm0306ld/sit=
eadmin/html/img/header.gif">
<br>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"576">
<tbody>
<tr>
<td><font size=3D"2" face=3D"Arial, Helvetica, sans-serif"><br>
Hello sidr members<br>
<br>
Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.<br>
<br>
Topic: firstinterimbeforeVancouver<br>
Host: Secure Inter-Domain Routing Working Group<br>
Date and Time:<br>
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT&#43;01:00)<br>
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)<br>
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)=
<br>
Event number: 649 888 520<br>
Event password: restonva<br>
<br>
-------------------------------------------------------<br>
To join the online event<br>
-------------------------------------------------------<br>
1. <a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=
=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2=
92831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&am=
p;p" target=3D"_blank">
Click here </a>to join the online event.<br>
Or copy and paste the following link to a browser: <br>
https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=3Da&amp;EA=3D=
sandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f292831c3&amp;ET=
R=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&amp;p<br>
2. Click &quot;Join Now&quot;.<br>
<br>
<br>
-------------------------------------------------------<br>
To join the teleconference only<br>
-------------------------------------------------------<br>
Call-in toll number (US/Canada): &#43;1-408-600-3600<br>
Access code: 649 888 520<br>
<br>
-------------------------------------------------------<br>
For assistance<br>
-------------------------------------------------------<br>
You can contact Secure Inter-Domain Routing Working Group at:<br>
<a href=3D"mailto:sidr-chairs@tools.ietf.org" target=3D"_blank">sidr-chairs=
@tools.ietf.org</a><br>
<br>
The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to
<a href=3D"https://ietf.webex.com/ietf/onstage/systemdiagnosis.php" target=
=3D"_blank">
https://ietf.webex.com/ietf/onstage/systemdiagnosis.php</a> <br>
<br>
<br>
<a href=3D"https://owa.sparta.com/owa/UrlBlockedError.aspx" target=3D"_blan=
k"></a><br>
<br>
<a href=3D"http://www.webex.com" target=3D"_blank">http://www.webex.com</a>=
<br>
<br>
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.
<br>
</font></td>
</tr>
</tbody>
</table>
<br>
<img border=3D"0" alt=3D"" src=3D"https://ietf.webex.com/adm0306ld/siteadmi=
n/html/img/footer.gif">
</div>
</div>
</div>
</body>
</html>

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_--

--_004_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_
Content-Type: application/octet-stream;
	name="firstinterimbeforeVancouver.ics"
Content-Description: firstinterimbeforeVancouver.ics
Content-Disposition: attachment; filename="firstinterimbeforeVancouver.ics";
	size=3125; creation-date="Thu, 12 Apr 2012 14:56:23 GMT";
	modification-date="Thu, 12 Apr 2012 14:56:23 GMT"
Content-ID: <5334312B411CC24FBDCF4A402B5168D2@ads.sparta.com>
Content-Transfer-Encoding: base64

QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg
MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP
TkUKVFpJRDpQYWNpZmljIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEwMTEwMVQwMjAw
MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G
RlNFVEZST006LTA3MDAKVFpPRkZTRVRUTzotMDgwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6
U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEwMDMwMVQwMjAwMDAKUlJVTEU6RlJF
UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDgw
MApUWk9GRlNFVFRPOi0wNzAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ
R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJTYW5kcmEgTXVycGh5
IjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPVRSVUU6TUFJTFRPOnNhbmRyYS5tdXJwaHlAc3Bh
cnRhLmNvbQpPUkdBTklaRVI7Q049IlNlY3VyZSBJbnRlci1Eb21haW4gUm91dGluZyBXb3JraW5n
IEdyb3VwIjpNQUlMVE86c2lkci1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcKRFRTVEFSVDtUWklEPSJQ
YWNpZmljIFRpbWUiOjIwMTIwNDMwVDA2MDAwMApEVEVORDtUWklEPSJQYWNpZmljIFRpbWUiOjIw
MTIwNDMwVDE0MDAwMApMT0NBVElPTjpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvb25zdGFn
ZS9nLnBocD9kPTY0OTg4ODUyMCZ0PWEgClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MApVSUQ6V0VC
RVgtTUVFVElORyBDRU5URVItNi4wNDU2NjgwLTE1MjU5ODc0NwpEVFNUQU1QOjIwMTIwNDEyVDE0
NTYxOVoKREVTQ1JJUFRJT046SGVsbG8gU2FuZHJhIE11cnBoeSxcblxuU2VjdXJlIEludGVyLURv
bWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gYXR0ZW5kIGEgV2ViIHNl
bWluYXIgdXNpbmcgV2ViRXguXG5cblRvcGljOiBmaXJzdGludGVyaW1iZWZvcmVWYW5jb3V2ZXJc
bkhvc3Q6IFNlY3VyZSBJbnRlci1Eb21haW4gUm91dGluZyBXb3JraW5nIEdyb3VwXG5EYXRlIGFu
ZCBUaW1lOlxuTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiAyOjAwIHBtLCBHTVQgU3VtbWVyIFRpbWUg
KExvbmRvbiwgR01UKzAxOjAwKVxuTW9uZGF5LCBBcHJpbCAzMCwgMjAxMiA2OjAwIGFtLCBQYWNp
ZmljIERheWxpZ2h0IFRpbWUgKFNhbiBGcmFuY2lzY28sIEdNVC0wNzowMClcbk1vbmRheSwgQXBy
aWwgMzAsIDIwMTIgOTowMCBhbSwgRWFzdGVybiBEYXlsaWdodCBUaW1lIChOZXcgWW9yaywgR01U
LTA0OjAwKVxuRXZlbnQgbnVtYmVyOiA2NDkgODg4IDUyMFxuRXZlbnQgcGFzc3dvcmQ6IHJlc3Rv
bnZhXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS1cblRvIGpvaW4gdGhlIG9ubGluZSBldmVudFxuLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLVxuMS4gR28gdG8gaHR0cHM6Ly9pZXRmLndl
YmV4LmNvbS9pZXRmL29uc3RhZ2UvZy5waHA/ZD02NDk4ODg1MjAmdD1hJkVBPXNhbmRyYS5tdXJw
aHklNDBzcGFydGEuY29tJkVUPTEzZTRiMzMwMjU4MTg0MTJiN2UyYjIwZjI5MjgzMWMzJkVUUj0z
YzBlN2Y4YmJjMjc4YzcxNmVkYWU2NDljYTJmNTVhYyZSVD1NaU14TVE9PSZwXG4yLiBDbGljayAi
Sm9pbiBOb3ciLlxuXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS1cblRvIGpvaW4gdGhlIHRlbGVjb25mZXJlbmNlIG9ubHlcbi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1cbkNhbGwtaW4g
dG9sbCBudW1iZXIgKFVTL0NhbmFkYSk6ICsxLTQwOC02MDAtMzYwMFxuQWNjZXNzIGNvZGU6IDY0
OSA4ODggNTIwXG5cbi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS1cbkZvciBhc3Npc3RhbmNlXG4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tXG5Zb3UgY2FuIGNvbnRhY3QgU2VjdXJlIEludGVy
LURvbWFpbiBSb3V0aW5nIFdvcmtpbmcgR3JvdXAgYXQ6XG5zaWRyLWNoYWlyc0B0b29scy5pZXRm
Lm9yZ1xuXG5UaGUgcGxheWJhY2sgb2YgVUNGIChVbml2ZXJzYWwgQ29tbXVuaWNhdGlvbnMgRm9y
bWF0KSByaWNoIG1lZGlhIGZpbGVzIHJlcXVpcmVzIGFwcHJvcHJpYXRlIHBsYXllcnMuIFRvIHZp
ZXcgdGhpcyB0eXBlIG9mIHJpY2ggbWVkaWEgZmlsZXMgaW4gdGhlIG1lZXRpbmcsIHBsZWFzZSBj
aGVjayB3aGV0aGVyIHlvdSBoYXZlIHRoZSBwbGF5ZXJzIGluc3RhbGxlZCBvbiB5b3VyIGNvbXB1
dGVyIGJ5IGdvaW5nIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9vbnN0YWdlL3N5c3Rl
bWRpYWdub3Npcy5waHBcblxuXG5cblxuXG5odHRwOi8vd3d3LndlYmV4LmNvbVxuXG5JTVBPUlRB
TlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxs
b3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2Vk
IG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcg
dGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5n
cy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91ciBj
b25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhvc3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSBy
ZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55
IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50
IG9mIGxpdGlnYXRpb24uIFxuClNVTU1BUlk6Zmlyc3RpbnRlcmltYmVmb3JlVmFuY291dmVyClBS
SU9SSVRZOjUKQ0xBU1M6UFVCTElDCkVORDpWRVZFTlQKRU5EOlZDQUxFTkRBUgo=

--_004_24B20D14B2CD29478C8D5D6E9CBB29F60F704A81Hermescolumbiaa_--

From Sandra.Murphy@sparta.com  Mon Apr 30 04:35:06 2012
Return-Path: <Sandra.Murphy@sparta.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B88F21F85D2 for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 04:35:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.618
X-Spam-Level: 
X-Spam-Status: No, score=-103.618 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y411u9MsI6-a for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 04:35:05 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A8DA621F85A5 for <sidr@ietf.org>; Mon, 30 Apr 2012 04:35:04 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q3UBZ4ek029195 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:35:04 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q3UBZ38b015334 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:35:04 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 30 Apr 2012 07:35:03 -0400
From: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: Invitation to Web seminar: firstinterimbeforeVancouver
Thread-Index: AQHNGLxtua1kpbzqAEuq4ZBTpV73S5azVFLWgAAEf98=
Date: Mon, 30 Apr 2012 11:35:02 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1@Hermes.columbia.ads.sparta.com>
References: <1663656271.20241334242579513.JavaMail.nobody@rva2rmd001.webex.com>, <24B20D14B2CD29478C8D5D6E9CBB29F60F704A81@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F704A81@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1Hermescolumbiaa_"
MIME-Version: 1.0
Subject: Re: [sidr] Invitation to Web seminar: firstinterimbeforeVancouver
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 11:35:06 -0000

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1Hermescolumbiaa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The link below looks specific to the first invitee (me), so the link on the=
 wiki page might serve for a general login:



https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&t=3Da





--Sandy



________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa=
ndra [Sandra.Murphy@sparta.com]
Sent: Monday, April 30, 2012 7:21 AM
To: sidr@ietf.org
Subject: [sidr] FW: Invitation to Web seminar: firstinterimbeforeVancouver


For those attending remotely, here is the full webex invitation.



--Sandy





________________________________
From: messenger@webex.com [messenger@webex.com]
Sent: Thursday, April 12, 2012 10:56 AM
To: Murphy, Sandra
Subject: Invitation to Web seminar: firstinterimbeforeVancouver

[https://ietf.webex.com/adm0306ld/siteadmin/html/img/header.gif]

Hello sidr members

Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.

Topic: firstinterimbeforeVancouver
Host: Secure Inter-Domain Routing Working Group
Date and Time:
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)
Event number: 649 888 520
Event password: restonva

-------------------------------------------------------
To join the online event
-------------------------------------------------------
1. Click here <https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&t=3D=
a&EA=3Dsandra.murphy%40sparta.com&ET=3D13e4b33025818412b7e2b20f292831c3&ETR=
=3D3c0e7f8bbc278c716edae649ca2f55ac&RT=3DMiMxMQ=3D=3D&p> to join the online=
 event.
Or copy and paste the following link to a browser:
https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&t=3Da&EA=3Dsandra.m=
urphy%40sparta.com&ET=3D13e4b33025818412b7e2b20f292831c3&ETR=3D3c0e7f8bbc27=
8c716edae649ca2f55ac&RT=3DMiMxMQ=3D=3D&p
2. Click "Join Now".


-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Call-in toll number (US/Canada): +1-408-600-3600
Access code: 649 888 520

-------------------------------------------------------
For assistance
-------------------------------------------------------
You can contact Secure Inter-Domain Routing Working Group at:
sidr-chairs@tools.ietf.org<mailto:sidr-chairs@tools.ietf.org>

The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to https://ietf.webex.com/ietf/onstage/systemdiagnosis.php


<https://owa.sparta.com/owa/UrlBlockedError.aspx>

http://www.webex.com

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent to the recording, discuss your concerns =
with the meeting host prior to the start of the recording or do not join th=
e session. Please note that any such recordings may be subject to discovery=
 in the event of litigation.


[https://ietf.webex.com/adm0306ld/siteadmin/html/img/footer.gif]

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1Hermescolumbiaa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style id=3D"owaParaStyle">P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
P {
	MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle=3D"1" ocsi=3D"0">
<div style=3D"direction: ltr;font-family: Arial;color: #000000;font-size: 1=
0pt;">
<p>The link below looks specific to the first&nbsp;invitee (me), so the lin=
k on the wiki page might serve for a general login:</p>
<p>&nbsp;</p>
<p><u><font color=3D"#0066cc"><a href=3D"https://ietf.webex.com/ietf/onstag=
e/g.php?d=3D649888520&amp;t=3Da">https://ietf.webex.com/ietf/onstage/g.php?=
d=3D649888520&amp;t=3Da</a></font></u></p>
<p><u><font color=3D"#0066cc"></font></u>&nbsp;</p>
<p><u><font color=3D"#0066cc"></font></u>&nbsp;</p>
<p><u><font color=3D"#0066cc">--Sandy</font></u></p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF208461"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>From:</b> sidr-bounces@ietf.org [sidr-bounces@=
ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com]<br>
<b>Sent:</b> Monday, April 30, 2012 7:21 AM<br>
<b>To:</b> sidr@ietf.org<br>
<b>Subject:</b> [sidr] FW: Invitation to Web seminar: firstinterimbeforeVan=
couver<br>
</font><br>
</div>
<div></div>
<div>
<div style=3D"FONT-FAMILY: Arial; DIRECTION: ltr; COLOR: #000000; FONT-SIZE=
: 10pt">
<p>For those attending remotely, here is the full webex invitation.</p>
<p>&nbsp;</p>
<p>--Sandy</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<div style=3D"FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px=
">
<hr tabindex=3D"-1">
<div style=3D"DIRECTION: ltr" id=3D"divRpF393595"><font color=3D"#000000" s=
ize=3D"2" face=3D"Tahoma"><b>From:</b> messenger@webex.com [messenger@webex=
.com]<br>
<b>Sent:</b> Thursday, April 12, 2012 10:56 AM<br>
<b>To:</b> Murphy, Sandra<br>
<b>Subject:</b> Invitation to Web seminar: firstinterimbeforeVancouver<br>
</font><br>
</div>
<div></div>
<div><img border=3D"0" alt=3D"" src=3D"https://ietf.webex.com/adm0306ld/sit=
eadmin/html/img/header.gif">
<br>
<table border=3D"0" cellspacing=3D"0" cellpadding=3D"0" width=3D"576">
<tbody>
<tr>
<td><font size=3D"2" face=3D"Arial, Helvetica, sans-serif"><br>
Hello sidr members<br>
<br>
Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.<br>
<br>
Topic: firstinterimbeforeVancouver<br>
Host: Secure Inter-Domain Routing Working Group<br>
Date and Time:<br>
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT&#43;01:00)<br>
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)<br>
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)=
<br>
Event number: 649 888 520<br>
Event password: restonva<br>
<br>
-------------------------------------------------------<br>
To join the online event<br>
-------------------------------------------------------<br>
1. <a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=
=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2=
92831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&am=
p;p" target=3D"_blank">
Click here </a>to join the online event.<br>
Or copy and paste the following link to a browser: <br>
https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=3Da&amp;EA=3D=
sandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f292831c3&amp;ET=
R=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&amp;p<br>
2. Click &quot;Join Now&quot;.<br>
<br>
<br>
-------------------------------------------------------<br>
To join the teleconference only<br>
-------------------------------------------------------<br>
Call-in toll number (US/Canada): &#43;1-408-600-3600<br>
Access code: 649 888 520<br>
<br>
-------------------------------------------------------<br>
For assistance<br>
-------------------------------------------------------<br>
You can contact Secure Inter-Domain Routing Working Group at:<br>
<a href=3D"mailto:sidr-chairs@tools.ietf.org" target=3D"_blank">sidr-chairs=
@tools.ietf.org</a><br>
<br>
The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to
<a href=3D"https://ietf.webex.com/ietf/onstage/systemdiagnosis.php" target=
=3D"_blank">
https://ietf.webex.com/ietf/onstage/systemdiagnosis.php</a> <br>
<br>
<br>
<a href=3D"https://owa.sparta.com/owa/UrlBlockedError.aspx" target=3D"_blan=
k"></a><br>
<br>
<a href=3D"http://www.webex.com" target=3D"_blank">http://www.webex.com</a>=
<br>
<br>
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.
<br>
</font></td>
</tr>
</tbody>
</table>
<br>
<img border=3D"0" alt=3D"" src=3D"https://ietf.webex.com/adm0306ld/siteadmi=
n/html/img/footer.gif">
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1Hermescolumbiaa_--

From christopher.morrow@gmail.com  Mon Apr 30 06:02:21 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D634421F861F for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 06:02:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.484
X-Spam-Level: 
X-Spam-Status: No, score=-104.484 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLh0Uu+D5wFs for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 06:02:19 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A941A21F8616 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:02:19 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so1463338ghb.31 for <sidr@ietf.org>; Mon, 30 Apr 2012 06:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n1tWHeeJNCa63SKyHRKvqoBmCojzUOo7C2EpbO3DRBg=; b=o6RzWBVJiz0L03gJxiHvNcAbGywBhv6N6WVzoP53aznZZcqzEXY/MdK7yzuZ6+4D57 PuRxb6q65IsoV+sR3DgRsNvv04O6zIF4yFlrpkmafNg2wPMv6alDTaIGUsJN0i7eLohk dgErJp1gF76TmOZjOQ68azJd/rEEnKfzo3AFv74zk4NgIwwbiY6EI8f94ebKeF+lRN6g KpxOOSDoG0X+Aw8mTHl01+82xNyy0oGG+sfIV1b6tHw7Z8NFBCjszw3KBqK02s2XChzM UpFBtbSH90bJz+NYxSh/fj+25Pm1lf4fPEPeixXST8vOzKA0Q6O954w8+9gqrboEWUKo fDpQ==
MIME-Version: 1.0
Received: by 10.60.27.7 with SMTP id p7mr3710967oeg.56.1335790938935; Mon, 30 Apr 2012 06:02:18 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.155.39 with HTTP; Mon, 30 Apr 2012 06:02:18 -0700 (PDT)
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1@Hermes.columbia.ads.sparta.com>
References: <1663656271.20241334242579513.JavaMail.nobody@rva2rmd001.webex.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F704A81@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1@Hermes.columbia.ads.sparta.com>
Date: Mon, 30 Apr 2012 09:02:18 -0400
X-Google-Sender-Auth: ocO2Re_qIKG_fuHuzB-JR1JZszk
Message-ID: <CAL9jLabhjMMYi2OFP96bkosAMae2kjJQwiK=Bp589_SwrcQ7Tw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Content-Type: multipart/alternative; boundary=e89a8f22bb2968d27a04bee51062
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Invitation to Web seminar: firstinterimbeforeVancouver
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 13:02:21 -0000

--e89a8f22bb2968d27a04bee51062
Content-Type: text/plain; charset=ISO-8859-1

and hopefully we'll get the webex started, I apparently don't have the
'event host email address' :(

On Mon, Apr 30, 2012 at 7:35 AM, Murphy, Sandra <Sandra.Murphy@sparta.com>wrote:

>  The link below looks specific to the first invitee (me), so the link on
> the wiki page might serve for a general login:
>
>
>
> *https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a*
>
> **
>
> **
>
> *--Sandy*
>
>
>  ------------------------------
> *From:* sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of
> Murphy, Sandra [Sandra.Murphy@sparta.com]
> *Sent:* Monday, April 30, 2012 7:21 AM
> *To:* sidr@ietf.org
> *Subject:* [sidr] FW: Invitation to Web seminar:
> firstinterimbeforeVancouver
>
>   For those attending remotely, here is the full webex invitation.
>
>
>
> --Sandy
>
>
>
>
>  ------------------------------
> *From:* messenger@webex.com [messenger@webex.com]
> *Sent:* Thursday, April 12, 2012 10:56 AM
> *To:* Murphy, Sandra
> *Subject:* Invitation to Web seminar: firstinterimbeforeVancouver
>
>
>
> Hello sidr members
>
> Secure Inter-Domain Routing Working Group invites you to attend a Web
> seminar using WebEx.
>
> Topic: firstinterimbeforeVancouver
> Host: Secure Inter-Domain Routing Working Group
> Date and Time:
> Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)
> Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco,
> GMT-07:00)
> Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)
> Event number: 649 888 520
> Event password: restonva
>
> -------------------------------------------------------
> To join the online event
> -------------------------------------------------------
> 1. Click here
> <https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a&EA=sandra.murphy%40sparta.com&ET=13e4b33025818412b7e2b20f292831c3&ETR=3c0e7f8bbc278c716edae649ca2f55ac&RT=MiMxMQ==&p>to
> join the online event.
> Or copy and paste the following link to a browser:
>
> https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a&EA=sandra.murphy%40sparta.com&ET=13e4b33025818412b7e2b20f292831c3&ETR=3c0e7f8bbc278c716edae649ca2f55ac&RT=MiMxMQ==&p
> 2. Click "Join Now".
>
>
> -------------------------------------------------------
> To join the teleconference only
> -------------------------------------------------------
> Call-in toll number (US/Canada): +1-408-600-3600
> Access code: 649 888 520
>
> -------------------------------------------------------
> For assistance
> -------------------------------------------------------
> You can contact Secure Inter-Domain Routing Working Group at:
> sidr-chairs@tools.ietf.org
>
> The playback of UCF (Universal Communications Format) rich media files
> requires appropriate players. To view this type of rich media files in the
> meeting, please check whether you have the players installed on your
> computer by going to
> https://ietf.webex.com/ietf/onstage/systemdiagnosis.php
>
>
>  <https://owa.sparta.com/owa/UrlBlockedError.aspx>
>
> http://www.webex.com
>
> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
> and any documents and other materials exchanged or viewed during the
> session to be recorded. By joining this session, you automatically consent
> to such recordings. If you do not consent to the recording, discuss your
> concerns with the meeting host prior to the start of the recording or do
> not join the session. Please note that any such recordings may be subject
> to discovery in the event of litigation.
>
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>

--e89a8f22bb2968d27a04bee51062
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">and hopefully we&#39;ll get the webex started, I=
 apparently don&#39;t have the &#39;event host email address&#39; :(<br><br=
><div class=3D"gmail_quote">On Mon, Apr 30, 2012 at 7:35 AM, Murphy, Sandra=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:Sandra.Murphy@sparta.com" target=
=3D"_blank">Sandra.Murphy@sparta.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">




<div>
<div style=3D"direction:ltr;font-size:10pt;font-family:Arial">
<p>The link below looks specific to the first=A0invitee (me), so the link o=
n the wiki page might serve for a general login:</p>
<p>=A0</p>
<p><u><font color=3D"#0066cc"><a href=3D"https://ietf.webex.com/ietf/onstag=
e/g.php?d=3D649888520&amp;t=3Da" target=3D"_blank">https://ietf.webex.com/i=
etf/onstage/g.php?d=3D649888520&amp;t=3Da</a></font></u></p>
<p><u><font color=3D"#0066cc"></font></u>=A0</p>
<p><u><font color=3D"#0066cc"></font></u>=A0</p>
<p><u><font color=3D"#0066cc">--Sandy</font></u></p>
<p>=A0</p>
<div style=3D"font-size:16px;font-family:Times New Roman">
<hr>
<div style=3D"DIRECTION:ltr"><font face=3D"Tahoma" color=3D"#000000"><b>Fro=
m:</b> <a href=3D"mailto:sidr-bounces@ietf.org" target=3D"_blank">sidr-boun=
ces@ietf.org</a> [<a href=3D"mailto:sidr-bounces@ietf.org" target=3D"_blank=
">sidr-bounces@ietf.org</a>] on behalf of Murphy, Sandra [<a href=3D"mailto=
:Sandra.Murphy@sparta.com" target=3D"_blank">Sandra.Murphy@sparta.com</a>]<=
br>

<b>Sent:</b> Monday, April 30, 2012 7:21 AM<br>
<b>To:</b> <a href=3D"mailto:sidr@ietf.org" target=3D"_blank">sidr@ietf.org=
</a><br>
<b>Subject:</b> [sidr] FW: Invitation to Web seminar: firstinterimbeforeVan=
couver<br>
</font><br>
</div><div><div class=3D"h5">
<div></div>
<div>
<div style=3D"direction:ltr;font-size:10pt;font-family:Arial">
<p>For those attending remotely, here is the full webex invitation.</p>
<p>=A0</p>
<p>--Sandy</p>
<p>=A0</p>
<p>=A0</p>
<div style=3D"font-size:16px;font-family:Times New Roman">
<hr>
<div style=3D"DIRECTION:ltr"><font face=3D"Tahoma" color=3D"#000000"><b>Fro=
m:</b> <a href=3D"mailto:messenger@webex.com" target=3D"_blank">messenger@w=
ebex.com</a> [<a href=3D"mailto:messenger@webex.com" target=3D"_blank">mess=
enger@webex.com</a>]<br>

<b>Sent:</b> Thursday, April 12, 2012 10:56 AM<br>
<b>To:</b> Murphy, Sandra<br>
<b>Subject:</b> Invitation to Web seminar: firstinterimbeforeVancouver<br>
</font><br>
</div>
<div></div>
<div><img src=3D"" alt=3D"" border=3D"0">
<br>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" width=3D"576">
<tbody>
<tr>
<td><font face=3D"Arial, Helvetica, sans-serif"><br>
Hello sidr members<br>
<br>
Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.<br>
<br>
Topic: firstinterimbeforeVancouver<br>
Host: Secure Inter-Domain Routing Working Group<br>
Date and Time:<br>
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)<br>
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)<br>
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)=
<br>
Event number: 649 888 520<br>
Event password: restonva<br>
<br>
-------------------------------------------------------<br>
To join the online event<br>
-------------------------------------------------------<br>
1. <a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=
=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2=
92831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&am=
p;p" target=3D"_blank">
Click here </a>to join the online event.<br>
Or copy and paste the following link to a browser: <br>
<a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=3D=
a&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2928=
31c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&amp;p=
" target=3D"_blank">https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520=
&amp;t=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e=
2b20f292831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=
=3D&amp;p</a><br>

2. Click &quot;Join Now&quot;.<br>
<br>
<br>
-------------------------------------------------------<br>
To join the teleconference only<br>
-------------------------------------------------------<br>
Call-in toll number (US/Canada): <a href=3D"tel:%2B1-408-600-3600" value=3D=
"+14086003600" target=3D"_blank">+1-408-600-3600</a><br>
Access code: 649 888 520<br>
<br>
-------------------------------------------------------<br>
For assistance<br>
-------------------------------------------------------<br>
You can contact Secure Inter-Domain Routing Working Group at:<br>
<a href=3D"mailto:sidr-chairs@tools.ietf.org" target=3D"_blank">sidr-chairs=
@tools.ietf.org</a><br>
<br>
The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to
<a href=3D"https://ietf.webex.com/ietf/onstage/systemdiagnosis.php" target=
=3D"_blank">
https://ietf.webex.com/ietf/onstage/systemdiagnosis.php</a> <br>
<br>
<br>
<a href=3D"https://owa.sparta.com/owa/UrlBlockedError.aspx" target=3D"_blan=
k"></a><br>
<br>
<a href=3D"http://www.webex.com" target=3D"_blank">http://www.webex.com</a>=
<br>
<br>
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.
<br>
</font></td>
</tr>
</tbody>
</table>
<br>
<img src=3D"" alt=3D"" border=3D"0">
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br>_______________________________________________<br>
sidr mailing list<br>
<a href=3D"mailto:sidr@ietf.org">sidr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/sidr</a><br>
<br></blockquote></div><br></div>

--e89a8f22bb2968d27a04bee51062--

From randy@psg.com  Mon Apr 30 07:15:38 2012
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7421F8642 for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 07:15:38 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xiin0oso5pNp for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 07:15:37 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0821F8634 for <sidr@ietf.org>; Mon, 30 Apr 2012 07:15:37 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SOrO4-000DvH-T7 for sidr@ietf.org; Mon, 30 Apr 2012 14:15:37 +0000
Date: Mon, 30 Apr 2012 10:15:36 -0400
Message-ID: <m2ehr55mrb.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: sidr wg list <sidr@ietf.org>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Subject: [sidr] some slides on origin validation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 14:15:38 -0000

http://archive.psg.com/120417.sidr-origin.pdf

From christopher.morrow@gmail.com  Mon Apr 30 07:17:14 2012
Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E16C21F8642 for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 07:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.534
X-Spam-Level: 
X-Spam-Status: No, score=-104.534 tagged_above=-999 required=5 tests=[AWL=1.064, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnJA4Sms86fQ for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 07:17:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C99421F8634 for <sidr@ietf.org>; Mon, 30 Apr 2012 07:17:12 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so1052917obb.31 for <sidr@ietf.org>; Mon, 30 Apr 2012 07:17:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fURVgCnaOdfcvtwYQuUU/et6bQ65ZH2ATv5S5EODSHM=; b=f2t7oRdqjsn0+odR1KJRlxTxJPVKmHGAWPY259TdU+d0s6NgAG64+OxwYPpyZJudb0 LJ2x5+e1OTH+8wRwmWiy/o+V3qot8l7aWdv/gdUHttpZidlXOpDRyDCz14qZ0QccNBhI NyF/J/MclVv2nY6fPxbvZQfQ8U1szbwi6NZ2O4+GLKYzruEw9BhX0XwgPkxCpUz3Z2dK fB8t4y54J0/2MlEPkAL5gBaZHuhAaia6OdwE4FJa5t3Mi1Mh14f9x0VXRYSibLrdGZ2F ayDkYak1BhrLQYDwQRmQQ/Sv/R7s6Ti7MIVpqe91RMc62GBJN7bmIn8ZfVp0BRG/EDUC Rypg==
MIME-Version: 1.0
Received: by 10.182.167.40 with SMTP id zl8mr2561604obb.39.1335795432560; Mon, 30 Apr 2012 07:17:12 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.155.39 with HTTP; Mon, 30 Apr 2012 07:17:12 -0700 (PDT)
In-Reply-To: <CAL9jLabhjMMYi2OFP96bkosAMae2kjJQwiK=Bp589_SwrcQ7Tw@mail.gmail.com>
References: <1663656271.20241334242579513.JavaMail.nobody@rva2rmd001.webex.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F704A81@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F704AA1@Hermes.columbia.ads.sparta.com> <CAL9jLabhjMMYi2OFP96bkosAMae2kjJQwiK=Bp589_SwrcQ7Tw@mail.gmail.com>
Date: Mon, 30 Apr 2012 10:17:12 -0400
X-Google-Sender-Auth: 70XuCdcGPJ0ns7rho6dYPe5JQpw
Message-ID: <CAL9jLaYjc2jJgpTcpxiNCJLTQqtPEEFjFZgPB2cs4WzvyPfPaw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
Content-Type: multipart/alternative; boundary=e89a8f839edf40182504bee61c28
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Invitation to Web seminar: firstinterimbeforeVancouver
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 14:17:14 -0000

--e89a8f839edf40182504bee61c28
Content-Type: text/plain; charset=ISO-8859-1

Current state of the conference/bridge/etc:
 1) calling the webex dialin seems to be working properly:
      Call-in toll number (US/Canada): +1-408-600-3600
      Access code: 649 888 520

  2) using the integrated audio in the webex seems to be failing mostly.
  3) jabber details: sidr@jabber.ietf.org

-chris

On Mon, Apr 30, 2012 at 9:02 AM, Christopher Morrow <morrowc.lists@gmail.com
> wrote:

> and hopefully we'll get the webex started, I apparently don't have the
> 'event host email address' :(
>
> On Mon, Apr 30, 2012 at 7:35 AM, Murphy, Sandra <Sandra.Murphy@sparta.com>wrote:
>
>>  The link below looks specific to the first invitee (me), so the link on
>> the wiki page might serve for a general login:
>>
>>
>>
>> *https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a*
>>
>> **
>>
>> **
>>
>> *--Sandy*
>>
>>
>>  ------------------------------
>> *From:* sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of
>> Murphy, Sandra [Sandra.Murphy@sparta.com]
>> *Sent:* Monday, April 30, 2012 7:21 AM
>> *To:* sidr@ietf.org
>> *Subject:* [sidr] FW: Invitation to Web seminar:
>> firstinterimbeforeVancouver
>>
>>   For those attending remotely, here is the full webex invitation.
>>
>>
>>
>> --Sandy
>>
>>
>>
>>
>>  ------------------------------
>> *From:* messenger@webex.com [messenger@webex.com]
>> *Sent:* Thursday, April 12, 2012 10:56 AM
>> *To:* Murphy, Sandra
>> *Subject:* Invitation to Web seminar: firstinterimbeforeVancouver
>>
>>
>>
>> Hello sidr members
>>
>> Secure Inter-Domain Routing Working Group invites you to attend a Web
>> seminar using WebEx.
>>
>> Topic: firstinterimbeforeVancouver
>> Host: Secure Inter-Domain Routing Working Group
>> Date and Time:
>> Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)
>> Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco,
>> GMT-07:00)
>> Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York,
>> GMT-04:00)
>> Event number: 649 888 520
>> Event password: restonva
>>
>> -------------------------------------------------------
>> To join the online event
>> -------------------------------------------------------
>> 1. Click here
>> <https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a&EA=sandra.murphy%40sparta.com&ET=13e4b33025818412b7e2b20f292831c3&ETR=3c0e7f8bbc278c716edae649ca2f55ac&RT=MiMxMQ==&p>to
>> join the online event.
>> Or copy and paste the following link to a browser:
>>
>> https://ietf.webex.com/ietf/onstage/g.php?d=649888520&t=a&EA=sandra.murphy%40sparta.com&ET=13e4b33025818412b7e2b20f292831c3&ETR=3c0e7f8bbc278c716edae649ca2f55ac&RT=MiMxMQ==&p
>> 2. Click "Join Now".
>>
>>
>> -------------------------------------------------------
>> To join the teleconference only
>> -------------------------------------------------------
>> Call-in toll number (US/Canada): +1-408-600-3600
>> Access code: 649 888 520
>>
>> -------------------------------------------------------
>> For assistance
>> -------------------------------------------------------
>> You can contact Secure Inter-Domain Routing Working Group at:
>> sidr-chairs@tools.ietf.org
>>
>> The playback of UCF (Universal Communications Format) rich media files
>> requires appropriate players. To view this type of rich media files in the
>> meeting, please check whether you have the players installed on your
>> computer by going to
>> https://ietf.webex.com/ietf/onstage/systemdiagnosis.php
>>
>>
>>  <https://owa.sparta.com/owa/UrlBlockedError.aspx>
>>
>> http://www.webex.com
>>
>> IMPORTANT NOTICE: This WebEx service includes a feature that allows audio
>> and any documents and other materials exchanged or viewed during the
>> session to be recorded. By joining this session, you automatically consent
>> to such recordings. If you do not consent to the recording, discuss your
>> concerns with the meeting host prior to the start of the recording or do
>> not join the session. Please note that any such recordings may be subject
>> to discovery in the event of litigation.
>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
>>
>

--e89a8f839edf40182504bee61c28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_extra">Current state of the conference/bridge/etc:<br>=
=A01) calling the webex dialin seems to be working properly: <br>=A0=A0=A0=
=A0=A0 <font face=3D"Arial, Helvetica, sans-serif">Call-in toll number (US/=
Canada): +1-408-600-3600<br>
=A0=A0=A0=A0=A0 Access code: 649 888 520<br><br>=A0 2) using the integrated=
 audio in the webex seems to be failing mostly.<br>=A0 3) jabber details: <=
a href=3D"mailto:sidr@jabber.ietf.org">sidr@jabber.ietf.org</a><br><br>-chr=
is<br></font><br>
<div class=3D"gmail_quote">On Mon, Apr 30, 2012 at 9:02 AM, Christopher Mor=
row <span dir=3D"ltr">&lt;<a href=3D"mailto:morrowc.lists@gmail.com" target=
=3D"_blank">morrowc.lists@gmail.com</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div class=3D"gmail_extra">and hopefully we&#39;ll get the webex started, I=
 apparently don&#39;t have the &#39;event host email address&#39; :(<br><br=
><div class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Apr 30, 2012 at =
7:35 AM, Murphy, Sandra <span dir=3D"ltr">&lt;<a href=3D"mailto:Sandra.Murp=
hy@sparta.com" target=3D"_blank">Sandra.Murphy@sparta.com</a>&gt;</span> wr=
ote:<br>

</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">




<div>
<div style=3D"direction:ltr;font-size:10pt;font-family:Arial">
<p>The link below looks specific to the first=A0invitee (me), so the link o=
n the wiki page might serve for a general login:</p>
<p>=A0</p>
<p><u><font color=3D"#0066cc"><a href=3D"https://ietf.webex.com/ietf/onstag=
e/g.php?d=3D649888520&amp;t=3Da" target=3D"_blank">https://ietf.webex.com/i=
etf/onstage/g.php?d=3D649888520&amp;t=3Da</a></font></u></p>
<p><u><font color=3D"#0066cc"></font></u>=A0</p>
<p><u><font color=3D"#0066cc"></font></u>=A0</p>
<p><u><font color=3D"#0066cc">--Sandy</font></u></p>
<p>=A0</p>
<div style=3D"font-size:16px;font-family:Times New Roman">
<hr>
<div style=3D"DIRECTION:ltr"><font face=3D"Tahoma" color=3D"#000000"><b>Fro=
m:</b> <a href=3D"mailto:sidr-bounces@ietf.org" target=3D"_blank">sidr-boun=
ces@ietf.org</a> [<a href=3D"mailto:sidr-bounces@ietf.org" target=3D"_blank=
">sidr-bounces@ietf.org</a>] on behalf of Murphy, Sandra [<a href=3D"mailto=
:Sandra.Murphy@sparta.com" target=3D"_blank">Sandra.Murphy@sparta.com</a>]<=
br>


<b>Sent:</b> Monday, April 30, 2012 7:21 AM<br>
<b>To:</b> <a href=3D"mailto:sidr@ietf.org" target=3D"_blank">sidr@ietf.org=
</a><br>
<b>Subject:</b> [sidr] FW: Invitation to Web seminar: firstinterimbeforeVan=
couver<br>
</font><br>
</div><div><div>
<div></div>
<div>
<div style=3D"direction:ltr;font-size:10pt;font-family:Arial">
<p>For those attending remotely, here is the full webex invitation.</p>
<p>=A0</p>
<p>--Sandy</p>
<p>=A0</p>
<p>=A0</p>
<div style=3D"font-size:16px;font-family:Times New Roman">
<hr>
<div style=3D"DIRECTION:ltr"><font face=3D"Tahoma" color=3D"#000000"><b>Fro=
m:</b> <a href=3D"mailto:messenger@webex.com" target=3D"_blank">messenger@w=
ebex.com</a> [<a href=3D"mailto:messenger@webex.com" target=3D"_blank">mess=
enger@webex.com</a>]<br>


<b>Sent:</b> Thursday, April 12, 2012 10:56 AM<br>
<b>To:</b> Murphy, Sandra<br>
<b>Subject:</b> Invitation to Web seminar: firstinterimbeforeVancouver<br>
</font><br>
</div>
<div></div>
<div><img src=3D"" alt=3D"" border=3D"0">
<br>
<table border=3D"0" cellpadding=3D"0" cellspacing=3D"0" width=3D"576">
<tbody>
<tr>
<td><font face=3D"Arial, Helvetica, sans-serif"><br>
Hello sidr members<br>
<br>
Secure Inter-Domain Routing Working Group invites you to attend a Web semin=
ar using WebEx.<br>
<br>
Topic: firstinterimbeforeVancouver<br>
Host: Secure Inter-Domain Routing Working Group<br>
Date and Time:<br>
Monday, April 30, 2012 2:00 pm, GMT Summer Time (London, GMT+01:00)<br>
Monday, April 30, 2012 6:00 am, Pacific Daylight Time (San Francisco, GMT-0=
7:00)<br>
Monday, April 30, 2012 9:00 am, Eastern Daylight Time (New York, GMT-04:00)=
<br>
Event number: 649 888 520<br>
Event password: restonva<br>
<br>
-------------------------------------------------------<br>
To join the online event<br>
-------------------------------------------------------<br>
1. <a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=
=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2=
92831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&am=
p;p" target=3D"_blank">
Click here </a>to join the online event.<br>
Or copy and paste the following link to a browser: <br>
<a href=3D"https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520&amp;t=3D=
a&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e2b20f2928=
31c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=3D&amp;p=
" target=3D"_blank">https://ietf.webex.com/ietf/onstage/g.php?d=3D649888520=
&amp;t=3Da&amp;EA=3Dsandra.murphy%40sparta.com&amp;ET=3D13e4b33025818412b7e=
2b20f292831c3&amp;ETR=3D3c0e7f8bbc278c716edae649ca2f55ac&amp;RT=3DMiMxMQ=3D=
=3D&amp;p</a><br>


2. Click &quot;Join Now&quot;.<br>
<br>
<br>
-------------------------------------------------------<br>
To join the teleconference only<br>
-------------------------------------------------------<br>
Call-in toll number (US/Canada): <a href=3D"tel:%2B1-408-600-3600" value=3D=
"+14086003600" target=3D"_blank">+1-408-600-3600</a><br>
Access code: 649 888 520<br>
<br>
-------------------------------------------------------<br>
For assistance<br>
-------------------------------------------------------<br>
You can contact Secure Inter-Domain Routing Working Group at:<br>
<a href=3D"mailto:sidr-chairs@tools.ietf.org" target=3D"_blank">sidr-chairs=
@tools.ietf.org</a><br>
<br>
The playback of UCF (Universal Communications Format) rich media files requ=
ires appropriate players. To view this type of rich media files in the meet=
ing, please check whether you have the players installed on your computer b=
y going to
<a href=3D"https://ietf.webex.com/ietf/onstage/systemdiagnosis.php" target=
=3D"_blank">
https://ietf.webex.com/ietf/onstage/systemdiagnosis.php</a> <br>
<br>
<br>
<a href=3D"https://owa.sparta.com/owa/UrlBlockedError.aspx" target=3D"_blan=
k"></a><br>
<br>
<a href=3D"http://www.webex.com" target=3D"_blank">http://www.webex.com</a>=
<br>
<br>
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a=
nd any documents and other materials exchanged or viewed during the session=
 to be recorded. By joining this session, you automatically consent to such=
 recordings. If you do not consent
 to the recording, discuss your concerns with the meeting host prior to the=
 start of the recording or do not join the session. Please note that any su=
ch recordings may be subject to discovery in the event of litigation.
<br>
</font></td>
</tr>
</tbody>
</table>
<br>
<img src=3D"" alt=3D"" border=3D"0">
</div>
</div>
</div>
</div>
</div></div></div>
</div>
</div>

<br></div></div>_______________________________________________<br>
sidr mailing list<br>
<a href=3D"mailto:sidr@ietf.org" target=3D"_blank">sidr@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/sidr" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/sidr</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>

--e89a8f839edf40182504bee61c28--

From weiler@watson.org  Mon Apr 30 13:33:14 2012
Return-Path: <weiler@watson.org>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C0321F8829 for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 13:33:14 -0700 (PDT)
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9jOeUBKK153 for <sidr@ietfa.amsl.com>; Mon, 30 Apr 2012 13:33:13 -0700 (PDT)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 07E6921F8831 for <sidr@ietf.org>; Mon, 30 Apr 2012 13:33:12 -0700 (PDT)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q3UKXBES098108; Mon, 30 Apr 2012 16:33:11 -0400 (EDT) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q3UKXATc098102; Mon, 30 Apr 2012 16:33:11 -0400 (EDT) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 30 Apr 2012 16:33:10 -0400 (EDT)
From: Samuel Weiler <weiler@watson.org>
To: "Murphy, Sandra" <Sandra.Murphy@sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com>
Message-ID: <alpine.BSF.2.00.1204301632050.97405@fledge.watson.org>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 30 Apr 2012 16:33:11 -0400 (EDT)
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 20:33:14 -0000

On Fri, 27 Apr 2012, Murphy, Sandra wrote:

> Please respond as to whether you would accept moving the interim 
> meeting to 3 Jun.

No, I am not available on 3 June (including for virtual 
participation).  June 6 and 7 work fine for me.

-- Sam