From sidr-bounces@ietf.org Fri Jun 08 06:54:07 2007
Return-path: <sidr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Hwc6R-00087s-RP; Fri, 08 Jun 2007 06:53:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwc6P-00087k-Uv
	for sidr@ietf.org; Fri, 08 Jun 2007 06:53:57 -0400
Received: from scygmxsecs1.cygnacom.com ([65.242.48.253])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwc6L-0005QD-7u
	for sidr@ietf.org; Fri, 08 Jun 2007 06:53:57 -0400
Received: (qmail 1714 invoked from network); 8 Jun 2007 10:52:31 -0000
Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with
	EntrustECS-Server-7.4; 08 Jun 2007 10:52:31 -0000
Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7)
	by scygmxsecs1.cygnacom.com with SMTP; 8 Jun 2007 10:52:31 -0000
Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72)
	id <L49PDDBC>; Fri, 8 Jun 2007 06:53:50 -0400
Message-ID: <886F5D4C78AFB14D87261206BFB9612E1D1D094D@scygmxs1.cygnacom.com>
From: Carl Wallace <CWallace@cygnacom.com>
To: sidr@ietf.org
Date: Fri, 8 Jun 2007 06:53:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
Subject: [Sidr] New mailing list and potential BoF: trust anchor management
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0211078009=="
Errors-To: sidr-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============0211078009==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7A9BB.4C128D54"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C7A9BB.4C128D54
Content-Type: text/plain

The ietf-trust-anchor mailing list is for discussing a standard protocol for
trust anchor management.  Many groups within the IETF, including PKIX,
Kerberos, and SIDR, have all stated that trust anchor management is
necessary, but outside the scope of their documents.

This is being proposed as a BoF for Chicago.

Subscription information is at <http://www.vpnc.org/ietf-trust-anchor/>,
along with a draft problem statement.

------_=_NextPart_001_01C7A9BB.4C128D54
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.34">
<TITLE>New mailing list and potential BoF: trust anchor =
management</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The ietf-trust-anchor mailing list is for discussing =
a standard protocol for trust anchor management.&nbsp; Many groups =
within the IETF, including PKIX, Kerberos, and SIDR, have all stated =
that trust anchor management is necessary, but outside the scope of =
their documents.</FONT></P>

<P><FONT SIZE=3D2>This is being proposed as a BoF for Chicago.</FONT>
</P>

<P><FONT SIZE=3D2>Subscription information is at &lt;<A =
HREF=3D"http://www.vpnc.org/ietf-trust-anchor/" =
TARGET=3D"_blank">http://www.vpnc.org/ietf-trust-anchor/</A>&gt;,&nbsp; =
along with a draft problem statement.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7A9BB.4C128D54--


--===============0211078009==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr

--===============0211078009==--




From sidr-bounces@ietf.org Mon Jun 11 17:58:50 2007
Return-path: <sidr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HxruR-0004R5-8v; Mon, 11 Jun 2007 17:58:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HxruP-0004Qz-F3
	for sidr@ietf.org; Mon, 11 Jun 2007 17:58:45 -0400
Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxruO-0003cO-6a
	for sidr@ietf.org; Mon, 11 Jun 2007 17:58:45 -0400
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l5BLugiX014473
	for <sidr@ietf.org>; Mon, 11 Jun 2007 17:56:42 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAAz_a4qC; Mon, 11 Jun 07 17:56:38 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id E755F3F44A; Mon, 11 Jun 2007 17:55:02 -0400 (EDT)
To: sidr@ietf.org
Message-Id: <20070611215502.E755F3F44A@pecan.tislabs.com>
Date: Mon, 11 Jun 2007 17:55:02 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: sandy@tislabs.com
Subject: [Sidr] initial (-00) version deadline for drafts
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=subscribe>
Errors-To: sidr-bounces@ietf.org

The deadline for submitting -00 version internet drafts is July 2, Monday 
by 09:00 ET (13:00 UTC/GMT).

But the secretariat requests that working group chairs alert them to
expect a -00 draft the week before.

The chairs need to send a list of approved internet drafts by
Monday, June 25th at 9:00 AM ET for the upcoming meeting.  Please get
word to Geoff (gih@apnic.net) or to me (sandy@tislabs.com, sandy@sparta.com)
if you believe that you will be submitting a -00 version internet draft
real soon now.

--Sandy

P.S.  Important meeting dates can be seen at:
http://www3.ietf.org/meetings/69-cutoff_dates.html

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr



From sidr-bounces@ietf.org Wed Jun 20 17:23:06 2007
Return-path: <sidr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I17dk-0003OK-MR; Wed, 20 Jun 2007 17:23:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I17dk-0003OF-Bv
	for sidr@ietf.org; Wed, 20 Jun 2007 17:23:00 -0400
Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17dh-0004JG-Uw
	for sidr@ietf.org; Wed, 20 Jun 2007 17:23:00 -0400
Received: (from uucp@localhost)
	by nutshell.tislabs.com (8.12.9/8.12.9) id l5KLKpe1015490
	for <sidr@ietf.org>; Wed, 20 Jun 2007 17:20:51 -0400 (EDT)
Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap
	(V6.0) id srcAAA4Ma4pE; Wed, 20 Jun 07 17:20:47 -0400
Received: by pecan.tislabs.com (Postfix, from userid 2005)
	id 0FCA43F41A; Wed, 20 Jun 2007 17:19:06 -0400 (EDT)
To: sandy@tislabs.com, sidr@ietf.org
Subject: Re: [Sidr] initial (-00) version deadline for drafts
In-Reply-To: <20070611215502.E755F3F44A@pecan.tislabs.com>
Message-Id: <20070620211906.0FCA43F41A@pecan.tislabs.com>
Date: Wed, 20 Jun 2007 17:19:06 -0400 (EDT)
From: sandy@tislabs.com (Sandy Murphy)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: 
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=subscribe>
Errors-To: sidr-bounces@ietf.org

Final reminder.

If you intend to submit a -00 version of a working group draft, you need to
inform Geoff (gih@apnic.net) or me (sandy@tislabs.com, sandy@sparta.com)
real, real soon now.  We are supposed to notify the secretariat by
Monday, June 25th at 9:00 AM ET to OK any new (-00) draft for the sidr
working group.

This applies to working group drafts only, not to individual submissions.

--Sandy

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr



From sidr-bounces@ietf.org Wed Jun 20 22:07:44 2007
Return-path: <sidr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1I1C5I-0004Rq-B7; Wed, 20 Jun 2007 22:07:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1I1C5G-0004Rk-He
	for sidr@ietf.org; Wed, 20 Jun 2007 22:07:42 -0400
Received: from monster.hopcount.ca ([199.212.90.4])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1C5E-0008MU-G2
	for sidr@ietf.org; Wed, 20 Jun 2007 22:07:42 -0400
Received: from yxu1a22.hopcount.ca ([199.212.90.22])
	by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128)
	(Exim 4.67 (FreeBSD)) (envelope-from <jabley@ca.afilias.info>)
	id 1I1C7k-000Fv0-JC
	for sidr@ietf.org; Thu, 21 Jun 2007 02:10:19 +0000
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Transfer-Encoding: 7bit
Message-Id: <B2E2362D-049B-44D1-8712-1C20F39C923C@ca.afilias.info>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: sidr@ietf.org
From: Joe Abley <jabley@ca.afilias.info>
Date: Wed, 20 Jun 2007 22:07:27 -0400
X-Mailer: Apple Mail (2.752.3)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Subject: [Sidr] other means of trusting announcements
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sidr>,
	<mailto:sidr-request@ietf.org?subject=subscribe>
Errors-To: sidr-bounces@ietf.org

Hi all,

I made a comment during the wg meeting in Prague in response to a  
question from the floor (I forget who asked the question; someone  
from Easynet, I think). Sandy and Steve asked me to repeat it on the  
list.

The problem at the time, if I remember correctly, was one of context.  
For many operators in the RIPE region, there is established practice  
for building filters automatically for use as import filters on BGP  
sessions which is common to many operators. In that context, the SIDR  
approach as described in the face-to-face meeting is perplexing. It  
may well be that the documents could benefit from some accommodation  
of this context in the interests of rapid comprehension by operators  
in that region (operators who, I think, have shown the most interest  
in applying import filters to peers and customers).

The RPSL repository operated by the RIPE NCC (the "RIPE database") on  
behalf of RIPE members (and others) incorporates a feature which I  
believe is not available in corresponding services offered by other  
RIRs. The assignment/allocation data from the RIR (in the form of  
RPSL inetnum, aut-num, etc objects) is linked for the purposes of  
authentication with routing data (e.g. route, route6, etc objects).

This linkage is provided by RPSS (Routing Policy System Security).  
RPSS is documented in RFC 2725, but I do not know how accurate that  
document is with respect to the code which is actually running today  
in Amsterdam.

In broad terms (and apologies to those who know the details of this,  
and who are now cringing) it is not possible to register a route  
object in the RIPE database if you are not authorised to manipulate  
the corresponding (covering) inetnum object. This means that the  
presence of a route object with a particular origin attribute implies  
reasonable confidence that the AS specified in the origin is  
authorised to originate the route in question.

[The big hole in this trust dynamic is that for addresses assigned by  
other RIRs, no such linkage exists; in practice anybody can install  
route objects for addresses they have no business announcing in the  
RIPE database so long as those route objects don't already exist, and  
so long as the addresses concerned are not taken from one of the RIPE  
NCC's pools.]

The key point is that it is possible to build a prefix filter based  
on policy expressed in an aut-num or as-set RPSL object using the  
RIPE database and have a reasonable degree of confidence that the  
resulting prefix filter is probably a reasonable one, at least if the  
peers you mainly deal with are European, and acquired their addresses  
from the RIPE NCC.

For an operator in Europe who mainly deals with other European  
networks, it may well appear that confidence in the origination of a  
particular route from a particular AS is a problem which is largely  
solved. In this context, the need for the X.509 approach developed in  
this working group seems unclear, and the practical process by which  
a prefix filter could be constructed with reference to a certificate  
chain is non-obvious.

For operators elsewhere there is no such context, and the idea of a  
solution to the problem "how do I trust this new customer when he  
says he is allowed to announce route X through me" that doesn't  
involve photoshopped letterheads and fax machines is no doubt much  
more obviously attractive.


Joe

_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www1.ietf.org/mailman/listinfo/sidr



