From danny@tcb.net Thu Dec 1 17:52:34 2011 Return-Path: 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 DE36C1F0C5F for ; Thu, 1 Dec 2011 17:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-FXAxgkprPM for ; Thu, 1 Dec 2011 17:52:34 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD191F0C5E for ; Thu, 1 Dec 2011 17:52:33 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id BF4003681BC; Thu, 1 Dec 2011 18:52:32 -0700 (MST) Received: from dul1dmcphers-m1.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; Thu, 01 Dec 2011 18:52:32 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=61054; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <4ED64E04.7030408@bbn.com> Date: Thu, 1 Dec 2011 20:51:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.net> References: <4ED64E04.7030408@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1084) Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 01:52:35 -0000 On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote: > The specs leave room for the relying party to decide what to do with = imperfect but not completely invalid objects.=20 Thanks for sharing Andrew. One question and one comment... Is an expired object "completely invalid" or just "imperfect"? Can you=20= explain the difference? In general, I agree with you that this needs to be codified before we = proceed and I agree with Randy that "I see no reason to tolerate useless = incorrectness"=20 in a brand new security system expressly aimed at bringing integrity to = the mix,=20 integrity that is especially important in times of instability and = uncertainty. -danny From tim@ripe.net Fri Dec 2 02:23:28 2011 Return-Path: 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 9E75A21F9309 for ; Fri, 2 Dec 2011 02:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvwiWKMFUlzg for ; Fri, 2 Dec 2011 02:23:27 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B821F930E for ; Fri, 2 Dec 2011 02:23:27 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RWQH4-0003tb-AU; Fri, 02 Dec 2011 11:23:23 +0100 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 ) id 1RWQH3-0005dv-UC; Fri, 02 Dec 2011 11:23:21 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.net> Date: Fri, 2 Dec 2011 11:23:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <224117E2-E6B3-44FD-B1FA-DBBF6947E550@ripe.net> References: <4ED64E04.7030408@bbn.com> <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.net> To: Danny McPherson X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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: 784d7acfe6559f2a0b602ec6519a071994dc1eb4342b3d2eaccccb23e79f6b5d Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 10:23:28 -0000 On Dec 2, 2011, at 2:51 AM, Danny McPherson wrote: >=20 > On Nov 30, 2011, at 10:38 AM, Andrew Chi wrote: >=20 >> The specs leave room for the relying party to decide what to do with = imperfect but not completely invalid objects.=20 >=20 > Thanks for sharing Andrew. One question and one comment... >=20 > Is an expired object "completely invalid" or just "imperfect"? Can = you=20 > explain the difference? I think that here, the term 'stale' is preferred over 'expired'. This is = not about any object type, but manifests and crls in particular.. A manifest is stale "if the current time is after the nextUpdate time": http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4 When a one-time-use EE cert is used in the manifest CMS the validity = time MUST match the 'thisUpdate' and 'nextUpdate' of the manifest = contents: http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-5.1 So note that in this case the 'expired' EE cert should be considered = 'stale' instead as well.. CRLs also have a 'nextUpdate' field, that's typically the same as the = manifest's. Again, these are considered 'stale' not 'expired' after this = time. The reasoning is that an RP may only have old data for some reason: eg. = no updates occurred due to some technical issue, or there is some = problem retrieving new info. In this case it would be a bit rash to = *reject* the manifests and CRLs and all objects that depend on them. = This is the text in = http://tools.ietf.org/html/draft-ietf-sidr-rpki-manifests-16#section-6.4: "All signed objects at the publication point issued by the entity that has published the stale manifest, and all descendant signed objects that are validated using a certificate issued by the entity that has published the stale manifest at this publication point SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy." Current validator implementations differ in how they treat this case: rsynic accepts for indefinite(?) time (warns?)* BBN validator accepts for indefinite(?) time (warns?)* RIPE NCC val. rejects *: Andrew, Rob please comment.. We are now changing our validator to do the same as the other = implementations and accept stale manifests and crls for an indefinite = time, but warn about it.=20 There still is something to say for not accepting 'stale' for too long. = It makes an RP vulnerable to replays and defeats the idea of why the = manifests and crls are there in the first place, in my opinion. So, we = are thinking of adding a configuration setting at some point that allows = the user to indicate something like: "accept stale for a maximum of X = times the intended validity period" -- with a default of 3(?).. so: if a = manifest/crl was issued with an intended 24 hour life time, accept it = for another 72 hours. As a compromise between security and resilience.. = I am open to better suggestions.. Note that if other objects such as CA certificates, or ROAs (by their = EEs) are expired they must be rejected. The validator implementations = agree on this. >=20 > In general, I agree with you that this needs to be codified before we = proceed > and I agree with Randy that "I see no reason to tolerate useless = incorrectness"=20 > in a brand new security system expressly aimed at bringing integrity = to the mix,=20 > integrity that is especially important in times of instability and = uncertainty. >=20 I think corner cases exist where a publisher doesn't follow the = standards strictly, but the offense is not so serious that a publication = point and its descendants should be rejected altogether. For example the = AIA pointer is not really needed to validate the child certificate. = Incorrect key usage bits in an EE cert is another (our old code had this = bug). Other current example: illegal characters in subject names. It's = all incorrect, but none of these case actually make it impossible to = validate a child cert. The AIA pointer is not needed when you're walking = top-down, the key usage bits are an indication of allowed use, but not = used to determine validity (esp. in EEs an entity issued themselves, = it's not their parent allowing/disallowing some use), the subject still = parses in the BBN, openssl (rsynic) and bouncy castle (our validator = uses this) libraries. So.. I would actually prefer to warn instead in cases like this. As an implementer of publishing software I want to fix my code to not = raise any of these warnings. But resource competition means that this = may take time.. Therefore I think that at the very least validators = should *warn* for new corner cases for some time before they start to = reject. There are a number of different implementations out there and = not all corner cases are covered. If validators start checking for more = and more corner cases now, and reject, that would result in very flaky = availability (in terms of acceptance) of the current repositories. Having a list of all these corner cases and their agreed severity can = help prevent nasty surprises. Tim From randy@psg.com Fri Dec 2 05:52:51 2011 Return-Path: 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 423C721F9397 for ; Fri, 2 Dec 2011 05:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 NikHuxW1pwJO for ; Fri, 2 Dec 2011 05:52:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id DDDC921F9396 for ; Fri, 2 Dec 2011 05:52:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RWTXh-000HWE-7h; Fri, 02 Dec 2011 13:52:45 +0000 Date: Fri, 02 Dec 2011 22:53:10 +0900 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.net> References: <4ED64E04.7030408@bbn.com> <968DA738-0BB5-4D66-AA99-173664F60A2F@tcb.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 Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 13:52:51 -0000 > Is an expired object "completely invalid" or just "imperfect"? Can > you explain the difference? the objects of concern here, namely mainifests and crls, do not expire, they just go past their expected refresh date. > In general, I agree with you that this needs to be codified before we > proceed and I agree with Randy that "I see no reason to tolerate > useless incorrectness" are they uselessly incorrect. if the manifest is past it's refresh date, and names a cert C as expected at the pub point, and C is not there, a conservative might suspect an attack which deleted C yet did not have the private key needed to issue a new manifest. > in a brand new security system expressly aimed at bringing integrity > to the mix, integrity that is especially important in times of > instability and uncertainty. integrity is always good. and times are always uncertain. randy From gih@apnic.net Fri Dec 2 13:46:51 2011 Return-Path: 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 2C1D611E812C for ; Fri, 2 Dec 2011 13:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.629 X-Spam-Level: X-Spam-Status: No, score=-97.629 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, MANGLED_DOSE=2.3, 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 9qXfdCeFu1l5 for ; Fri, 2 Dec 2011 13:46:50 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A811E80C9 for ; Fri, 2 Dec 2011 13:46:50 -0800 (PST) Received: from [128.54.62.163] (unknown [128.54.62.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id A4BBFB6767; Sat, 3 Dec 2011 07:46:48 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <4ED64E04.7030408@bbn.com> Date: Sat, 3 Dec 2011 08:46:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ED64E04.7030408@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 21:46:51 -0000 On 01/12/2011, at 2:38 AM, Andrew Chi wrote: >=20 > 2. AIA correctness. Does res-certs require validators to reject a = certificate with a messed up AIA URI, even if top-down traversal is ok? = Having clean AIAs obviously helps bottom-up validators. But validators = capable of bottom-up traversal must already defend against = AIA-wild-goose-chase DoS, e.g. by limiting chase depth. Should we = encourage validators to enforce AIA correctness? res-certs says that there MUST be an AIA and the text says that it = points to the "publication point of the immediate superior certificate". = In the case where a local TA is being used (and in other conceivable = cases) it is possible for multiple CAs to certify a subject. What the = spec does NOT say is that the AIA must point to the publication point of = all such CAs. So it appears to be within the bounds of the res-cert = profile for a certificate hierarchy of the form CA A CA B | | V V CA C Now if the AIA of certificates issued by CA C points to the publication = point of CA A, then if you are performing a validation along the path A = to C then this is NOT "messed up", and things look fine. If you are = performing a validation along the path from B to C then it IS "messed = up", and things look good. So "messed up" in AIA appears to be a little bit in the eyes of the = beholder rather than an objective condition. On what grounds would a validator reject certificates issued by CA C in = this example? regards, Geoff =20= From gih@apnic.net Fri Dec 2 17:44:44 2011 Return-Path: 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 45DFE1F0C49 for ; Fri, 2 Dec 2011 17:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.083 X-Spam-Level: X-Spam-Status: No, score=-99.083 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, MANGLED_DOSE=2.3, RCVD_IN_PBL=0.905, 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 92ki0wk8aw-Y for ; Fri, 2 Dec 2011 17:44:43 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 1060C1F0C38 for ; Fri, 2 Dec 2011 17:44:43 -0800 (PST) Received: from [10.242.25.102] (mba0f36d0.tmodns.net [208.54.15.186]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 3F297B6767; Sat, 3 Dec 2011 11:44:40 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 3 Dec 2011 12:44:38 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ED64E04.7030408@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 01:44:44 -0000 On 03/12/2011, at 8:46 AM, Geoff Huston wrote: >=20 > On 01/12/2011, at 2:38 AM, Andrew Chi wrote: >=20 >>=20 >> 2. AIA correctness. Does res-certs require validators to reject a = certificate with a messed up AIA URI, even if top-down traversal is ok? = Having clean AIAs obviously helps bottom-up validators. But validators = capable of bottom-up traversal must already defend against = AIA-wild-goose-chase DoS, e.g. by limiting chase depth. Should we = encourage validators to enforce AIA correctness? >=20 > res-certs says that there MUST be an AIA and the text says that it = points to the "publication point of the immediate superior certificate". = In the case where a local TA is being used (and in other conceivable = cases) it is possible for multiple CAs to certify a subject. What the = spec does NOT say is that the AIA must point to the publication point of = all such CAs. So it appears to be within the bounds of the res-cert = profile for a certificate hierarchy of the form >=20 > CA A CA B > | | > V V > CA C >=20 > Now if the AIA of certificates issued by CA C points to the = publication point of CA A, then if you are performing a validation along = the path A to C then this is NOT "messed up", and things look fine. If = you are performing a validation along the path from B to C then it IS = "messed up", and things look good. >=20 things _do not_ look good :-) sorry! > So "messed up" in AIA appears to be a little bit in the eyes of the = beholder rather than an objective condition. >=20 > On what grounds would a validator reject certificates issued by CA C = in this example? >=20 > regards, >=20 > Geoff >=20 > _______________________________________________ > 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 randy@psg.com Fri Dec 2 19:44:27 2011 Return-Path: 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 10D931F0C49 for ; Fri, 2 Dec 2011 19:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 ieEUliLSYSPR for ; Fri, 2 Dec 2011 19:44:26 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 55F561F0C38 for ; Fri, 2 Dec 2011 19:44:25 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RWgWR-000L2s-Pg; Sat, 03 Dec 2011 03:44:20 +0000 Date: Sat, 03 Dec 2011 12:44:45 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: References: <4ED64E04.7030408@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 03:44:27 -0000 so are you saying bottom up is just a no-go? randy From gih@apnic.net Fri Dec 2 21:29:54 2011 Return-Path: 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 2D80721F8CBD for ; Fri, 2 Dec 2011 21:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.233 X-Spam-Level: X-Spam-Status: No, score=-100.233 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, 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 cx7gwZoMYcti for ; Fri, 2 Dec 2011 21:29:53 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 4868321F8CBC for ; Fri, 2 Dec 2011 21:29:52 -0800 (PST) Received: from [10.242.58.184] (mcf0f36d0.tmodns.net [208.54.15.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 70759B6767; Sat, 3 Dec 2011 15:29:49 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 3 Dec 2011 16:29:46 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> References: <4ED64E04.7030408@bbn.com> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 05:29:54 -0000 On 03/12/2011, at 2:44 PM, Randy Bush wrote: > so are you saying bottom up is just a no-go? >=20 I believe I am, in that by following the AIA pointers you may be lead to = places that may not match your chosen trust anchors. This is particularly the case for those who want to set up local TAs as = per some draft or another. Geoff From randy@psg.com Fri Dec 2 21:46:49 2011 Return-Path: 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 2B5C521F8D12 for ; Fri, 2 Dec 2011 21:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 2+MKrsIGAynE for ; Fri, 2 Dec 2011 21:46:48 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 621B921F8CFC for ; Fri, 2 Dec 2011 21:46:48 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RWiQu-000LFS-7c; Sat, 03 Dec 2011 05:46:45 +0000 Date: Sat, 03 Dec 2011 14:47:07 +0900 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.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 Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 05:46:49 -0000 >> so are you saying bottom up is just a no-go? > I believe I am, in that by following the AIA pointers you may be lead > to places that may not match your chosen trust anchors. > This is particularly the case for those who want to set up local TAs > as per some draft or another. as at least one validation implementation, bbn, is bottom up, and was done by clueful folk next to some draft or another, i suspect we need to document this in a warning some place. randy From gih@apnic.net Fri Dec 2 21:51:36 2011 Return-Path: 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 E957E21F8D52 for ; Fri, 2 Dec 2011 21:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.808 X-Spam-Level: X-Spam-Status: No, score=-100.808 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, RCVD_IN_PBL=0.905, 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 Erzi8cp+v5vr for ; Fri, 2 Dec 2011 21:51:35 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 4092F21F8D23 for ; Fri, 2 Dec 2011 21:51:35 -0800 (PST) Received: from [10.242.58.184] (mcf0f36d0.tmodns.net [208.54.15.207]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 66EA7B6767; Sat, 3 Dec 2011 15:51:31 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 3 Dec 2011 16:51:25 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 05:51:36 -0000 On 03/12/2011, at 4:47 PM, Randy Bush wrote: >>> so are you saying bottom up is just a no-go? >> I believe I am, in that by following the AIA pointers you may be lead >> to places that may not match your chosen trust anchors. >> This is particularly the case for those who want to set up local TAs >> as per some draft or another. > > as at least one validation implementation, bbn, is bottom up, and was > done by clueful folk next to some draft or another, i suspect we need to > document this in a warning some place. That would be a Good Idea - I've met my personal quota of drafts and writing assignments for this Working Group some time back, but hopefully someone will pick this up and put the necessary caveat into the appropriate documentation spot. Geoff From internet-drafts@ietf.org Sat Dec 3 09:25:10 2011 Return-Path: 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 5AE1021F9309; Sat, 3 Dec 2011 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 J2nKtz7USxZA; Sat, 3 Dec 2011 09:25:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D211021F930B; Sat, 3 Dec 2011 09:25:05 -0800 (PST) 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: 3.64 Message-ID: <20111203172505.5294.23033.idtracker@ietfa.amsl.com> Date: Sat, 03 Dec 2011 09:25:05 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2011 17:25:10 -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 : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark Reynolds Stephen Kent Filename : draft-ietf-sidr-ltamgmt-03.txt Pages : 28 Date : 2011-12-03 This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-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-ltamgmt-03.txt From internet-drafts@ietf.org Sun Dec 4 12:32:54 2011 Return-Path: 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 A96CD21F86D0; Sun, 4 Dec 2011 12:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 0nV9P-h8ISO7; Sun, 4 Dec 2011 12:32:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3987121F84C3; Sun, 4 Dec 2011 12:32:54 -0800 (PST) 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: 3.64 Message-ID: <20111204203254.1087.96249.idtracker@ietfa.amsl.com> Date: Sun, 04 Dec 2011 12:32:54 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ltamgmt-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 20:32:54 -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 : Local Trust Anchor Management for the Resource Public Ke= y Infrastructure Author(s) : Mark Reynolds Stephen Kent Filename : draft-ietf-sidr-ltamgmt-04.txt Pages : 28 Date : 2011-12-04 This document describes a facility to enable a relying party (RP) to manage trust anchors (TAs) in the context of the Resource Public Key Infrastructure (RPKI). It is common to allow an RP to import TA material in the form of self-signed certificates. The facility described in this document allows an RP to impose constraints on such TAs. Because this mechanism is designed to operate in the RPKI context, the relevant constraints are the RFC 3779 extensions that bind address spaces and/or autonomous system (AS) numbers to entities. The primary motivation for this facility is to enable an RP to ensure that resource allocation information that it has acquired via some trusted channel is not overridden by the information acquired from the RPKI repository system or by the putative TAs that the RP imports. Specifically, the mechanism allows an RP to specify a set of bindings between public key identifiers and RFC 3779 extension data and will override any conflicting bindings expressed via the putative TAs and the certificates downloaded from the RPKI repository system. Although this mechanism is designed for local use by an RP, an entity that is accorded administrative control over a set of RPs may use this mechanism to convey its view of the RPKI to a set of RPs within its jurisdiction. The means by which this latter use case is effected is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ltamgmt-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-ltamgmt-04.txt From internet-drafts@ietf.org Mon Dec 5 10:20:57 2011 Return-Path: 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 BDCF211E80CA; Mon, 5 Dec 2011 10:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 HjrkkEpA+X5h; Mon, 5 Dec 2011 10:20:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C611E80C8; Mon, 5 Dec 2011 10:20:57 -0800 (PST) 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: 3.64 Message-ID: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2011 10:20:57 -0800 Cc: sidr@ietf.org Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:20:58 -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-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.t= xt From internet-drafts@ietf.org Mon Dec 5 10:21:17 2011 Return-Path: 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 9B5B611E80D5; Mon, 5 Dec 2011 10:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 TdMs654zHixK; Mon, 5 Dec 2011 10:21:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4186A11E80D1; Mon, 5 Dec 2011 10:21:17 -0800 (PST) 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: 3.64 Message-ID: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2011 10:21:17 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:21:17 -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 Algorithms, Key Formats, & Signature Formats Author(s) : Sean Turner Filename : draft-ietf-sidr-bgpsec-algs-01.txt Pages : 7 Date : 2011-12-05 This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size and signature format used in BGPSEC (Border Gateway Protocol Security). This document updates the Profile for Algorithms and Key Sizes for use in the Resource Public Key Infrastructure (draft-ietf-sidr-rpki-algs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-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-algs-01.txt From turners@ieca.com Mon Dec 5 10:24:10 2011 Return-Path: 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 B833E11E80B1 for ; Mon, 5 Dec 2011 10:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.433, 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 s2gmBJ6aUvKl for ; Mon, 5 Dec 2011 10:24:10 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.243.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3437B11E8082 for ; Mon, 5 Dec 2011 10:24:10 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 2668A632BA95B; Mon, 5 Dec 2011 12:24:09 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 17A00632BA91E for ; Mon, 5 Dec 2011 12:24:09 -0600 (CST) Received: from [96.231.123.20] (port=38193 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RXdCy-0005xw-Dw for sidr@ietf.org; Mon, 05 Dec 2011 12:24:09 -0600 Message-ID: <4EDD0C45.3020103@ieca.com> Date: Mon, 05 Dec 2011 13:24:05 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> In-Reply-To: <20111205182057.9350.73900.idtracker@ietfa.amsl.com> 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-123-20.washdc.east.verizon.net (thunderfish.local) [96.231.123.20]:38193 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:24:10 -0000 This version adds an ASN.1 module. It still needs the official oids (one for the module and one for the EKU), but I figure we shouldn't ask for those until we're sure we're done. spt On 12/5/11 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 Mon Dec 5 10:24:56 2011 Return-Path: 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 72D8C11E80B1 for ; Mon, 5 Dec 2011 10:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.894 X-Spam-Level: X-Spam-Status: No, score=-101.894 tagged_above=-999 required=5 tests=[AWL=0.371, 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 8mM0HVqP5ASO for ; Mon, 5 Dec 2011 10:24:56 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.195.29]) by ietfa.amsl.com (Postfix) with ESMTP id CE4F511E8082 for ; Mon, 5 Dec 2011 10:24:55 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id CA3CD80C6A41; Mon, 5 Dec 2011 12:24:54 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id BEB4A80C6A0A for ; Mon, 5 Dec 2011 12:24:54 -0600 (CST) Received: from [96.231.123.20] (port=40594 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RXdDi-0006Bq-Fh for sidr@ietf.org; Mon, 05 Dec 2011 12:24:54 -0600 Message-ID: <4EDD0C76.5020106@ieca.com> Date: Mon, 05 Dec 2011 13:24:54 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> In-Reply-To: <20111205182117.8883.99030.idtracker@ietfa.amsl.com> 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-123-20.washdc.east.verizon.net (thunderfish.local) [96.231.123.20]:40594 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:24:56 -0000 This version swaps the DSS reference with a reference to RFC 6090. spt On 12/5/11 1:21 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 : BGP Algorithms, Key Formats,& Signature Formats > Author(s) : Sean Turner > Filename : draft-ietf-sidr-bgpsec-algs-01.txt > Pages : 7 > Date : 2011-12-05 > > This document specifies the algorithms, algorithms' parameters, > asymmetric key formats, asymmetric key size and signature format used > in BGPSEC (Border Gateway Protocol Security). This document updates > the Profile for Algorithms and Key Sizes for use in the Resource > Public Key Infrastructure (draft-ietf-sidr-rpki-algs). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-algs-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-algs-01.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From alexb@ripe.net Mon Dec 5 14:02:36 2011 Return-Path: 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 69F801F0C85 for ; Mon, 5 Dec 2011 14:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 fdDMEPAVfL8w for ; Mon, 5 Dec 2011 14:02:35 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9221F0C47 for ; Mon, 5 Dec 2011 14:02:34 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RXgcJ-0002Eq-Rr for sidr@ietf.org; Mon, 05 Dec 2011 23:02:33 +0100 Received: from mandrill.ripe.net ([193.0.1.209] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RXgcJ-00058q-Me for sidr@ietf.org; Mon, 05 Dec 2011 23:02:31 +0100 From: Alex Band Content-Type: multipart/alternative; boundary="Apple-Mail=_D37338E3-7AC9-4ACE-B821-273EBA879969" Date: Mon, 5 Dec 2011 23:02:31 +0100 Message-Id: To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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: ddd0bbf11d1e21354000f5f053f5ae69cef36877863a6c0fb064f98fb8eb50a3 Subject: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:02:36 -0000 --Apple-Mail=_D37338E3-7AC9-4ACE-B821-273EBA879969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The RIPE NCC launched a Resource Certification platform on 1.1.2011, = where members can choose to set up a certificate listing their address = blocks. They can run RPKI software themselves, or use a hosted platform = in our web portal. So far 715 out of our ~7500 members have done this. = Out of the top 100 largest LIRs in our region, 28 have a certificate set = up. About half of the enabled members have the certificate solely to get = validatable proof of holdership of the address space they hold (for = now?), the rest use it for BGP origin validation.=20 By the latter group, 416 Route Origin Authorization (ROA) objects have = been created, covering the equivalent of 230,000 /24 prefixes and 8,600 = /32 IPv6 prefixes. MaxLength in ROAs is sorely misunderstood, lots of = education is needed there. Most leave the field blank, causing more = specific announcements to be invalid. Lately though, there lots of activity with regards to tooling and = testbeds. EuroTransit have set up a testbed with Randy/Rob's tools, as = well as the NCC's:=20 http://rpki01.fra2.de.euro-transit.net/documentation.html They also made two public RPKI capable Juniper routers available. You = can log into them using telnet with these details: IPs: 193.34.50.25 and 193.34.50.26 user: rpki password: testbed You can run commands such as "show validation database" , "show = validation statistics", "show validation session", "show bgp neighbor", = "show bgp summary" and lastly "show route protocol bgp = validation-state", followed by the state (valid, invalid, unknown or = unverified) I'm curious to hear what you think. Cheers, Alex Band RIPE NCC P.S. Here you can grab a pre-release of the NCC Validation tool that = they run there (requires *NIX w/ Java, rsync): = https://certification.ripe.net/content/public-repo/releases/net/ripe/rpki-= validator/rpki-validator-app/1.0.14/rpki-validator-app-1.0.14-bin.zip= --Apple-Mail=_D37338E3-7AC9-4ACE-B821-273EBA879969 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://= rpki01.fra2.de.euro-transit.net/documentation.html

=
They also made two public RPKI capable Juniper routers = available. You can log into them using telnet with these = details:

IPs: 193.34.50.25 and = 193.34.50.26
user: rpki
password: = testbed

You can run commands such as "show = validation database" , "show validation statistics", "show validation = session", "show bgp neighbor", "show bgp summary" and lastly "show route = protocol bgp validation-state", followed by the state (valid, invalid, = unknown or unverified)

I'm curious to = hear what you = think.

Cheers,

Alex = Band
RIPE NCC

P.S. Here you can grab = a pre-release of the NCC Validation tool that they run there (requires = *NIX w/ Java, rsync):
= --Apple-Mail=_D37338E3-7AC9-4ACE-B821-273EBA879969-- From waehlisch@ieee.org Mon Dec 5 14:39:52 2011 Return-Path: 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 0EE8D21F85DB for ; Mon, 5 Dec 2011 14:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 KrqgBOkT7ur9 for ; Mon, 5 Dec 2011 14:39:51 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id E88AB21F85D1 for ; Mon, 5 Dec 2011 14:39:50 -0800 (PST) Envelope-to: sidr@ietf.org Received: from [12.14.62.2] (helo=mw-PC.Hilton.com) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RXhCP-000HfB-D0; Mon, 05 Dec 2011 23:39:49 +0100 Date: Mon, 5 Dec 2011 16:39:46 -0600 (Mittelamerikanische Normalzeit) From: Matthias Waehlisch To: Alex Band In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr@ietf.org Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:39:52 -0000 Hi Alex, great! Also the extended RPKI Validator web interface. Just for completeness: As mentioned at the last IETF meeting, we also provide a public RTR origin server instance. You can connect via unprotected TCP or SSH: * http://rpki.realmv6.org/wiki/Usage#ChooseanRTR-ServerImplementation It currently runs rtr-origin but as soon as NCC Validation tool is released we will also set such a cache server up. Using both, rpki01.fra2.de.euro-transit.net and rpki.realmv6.org, allows to test failover. Overall, nice playground! Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Mon, 5 Dec 2011, Alex Band wrote: > The RIPE NCC launched a Resource Certification platform on 1.1.2011, where members can choose to set up a certificate listing their address blocks. They can run RPKI software themselves, or use a hosted platform in our web portal. So far 715 out of our ~7500 members have done this. Out of the top 100 largest LIRs in our region, 28 have a certificate set up. About half of the enabled members have the certificate solely to get validatable proof of holdership of the address space they hold (for now?), the rest use it for BGP origin validation. > > By the latter group, 416 Route Origin Authorization (ROA) objects have been created, covering the equivalent of 230,000 /24 prefixes and 8,600 /32 IPv6 prefixes. MaxLength in ROAs is sorely misunderstood, lots of education is needed there. Most leave the field blank, causing more specific announcements to be invalid. > > Lately though, there lots of activity with regards to tooling and testbeds. EuroTransit have set up a testbed with Randy/Rob's tools, as well as the NCC's: > > http://rpki01.fra2.de.euro-transit.net/documentation.html > > They also made two public RPKI capable Juniper routers available. You can log into them using telnet with these details: > > IPs: 193.34.50.25 and 193.34.50.26 > user: rpki > password: testbed > > You can run commands such as "show validation database" , "show validation statistics", "show validation session", "show bgp neighbor", "show bgp summary" and lastly "show route protocol bgp validation-state", followed by the state (valid, invalid, unknown or unverified) > > I'm curious to hear what you think. > > Cheers, > > Alex Band > RIPE NCC > > P.S. Here you can grab a pre-release of the NCC Validation tool that they run there (requires *NIX w/ Java, rsync): > https://certification.ripe.net/content/public-repo/releases/net/ripe/rpki-validator/rpki-validator-app/1.0.14/rpki-validator-app-1.0.14-bin.zip From achi@bbn.com Tue Dec 6 08:20:08 2011 Return-Path: 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 E5C8D21F8BDE for ; Tue, 6 Dec 2011 08:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 JbaK3FeC5CkJ for ; Tue, 6 Dec 2011 08:20:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12021F8BDC for ; Tue, 6 Dec 2011 08:20:08 -0800 (PST) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:51520 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RXxkR-000I20-Nm; Tue, 06 Dec 2011 11:20:03 -0500 Message-ID: <4EDE40B0.8090903@bbn.com> Date: Tue, 06 Dec 2011 11:20:00 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Bush References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:20:09 -0000 On 12/3/2011 12:47 AM, Randy Bush wrote: >>> so are you saying bottom up is just a no-go? >> I believe I am, in that by following the AIA pointers you may be lead >> to places that may not match your chosen trust anchors. >> This is particularly the case for those who want to set up local TAs >> as per some draft or another. > > as at least one validation implementation, bbn, is bottom up, and was > done by clueful folk next to some draft or another, i suspect we need to > document this in a warning some place. > > randy BBN's validator does have both top-down and bottom-up capability (currently, both run by default). This was intended to handle any future use cases where a child is somehow obtained before its parent. As it turns out, all use cases that we've tested so far only require top-down. And the bottom-up capability only leads us to old, abandoned data. Note that Local TA is unaffected; that "tree" is shallow, locally managed, and processed in a manner that doesn't require AIAs. As others have mentioned, bottom-up introduces complexity with (1) stray AIA pointers, and (2) multiple issuers if AIAs must be strict. We have a countermeasure for 1, and currently we aren't strict about 2. But if no bottom-up use cases ever come up, we will default the BBN validator to run top-down only. -Andrew From achi@bbn.com Tue Dec 6 08:48:29 2011 Return-Path: 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 2EC0921F8A55 for ; Tue, 6 Dec 2011 08:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, 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 07KJcBms8sNM for ; Tue, 6 Dec 2011 08:48:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37221F893C for ; Tue, 6 Dec 2011 08:48:28 -0800 (PST) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:51561 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RXyBv-0007jA-Pa; Tue, 06 Dec 2011 11:48:27 -0500 Message-ID: <4EDE4758.30603@bbn.com> Date: Tue, 06 Dec 2011 11:48:24 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Randy Bush References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> <4EDE40B0.8090903@bbn.com> In-Reply-To: <4EDE40B0.8090903@bbn.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:48:29 -0000 On 12/6/2011 11:20 AM, Andrew Chi wrote: > Note that Local TA is unaffected; that "tree" is shallow, locally > managed, and processed in a manner that doesn't require AIAs. I wrote that quickly and might have been unclear. The AIA for every paracert points to the Local TA publication point. Thus, that tree has height 1. If you trust the local trust anchor, then you have already have it, and there's no need to "chase upward" to go looking for it. From tim@ripe.net Tue Dec 6 08:55:08 2011 Return-Path: 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 E76BB21F8B0B for ; Tue, 6 Dec 2011 08:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4OPK8TV-urP for ; Tue, 6 Dec 2011 08:55:08 -0800 (PST) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 1986721F8AD8 for ; Tue, 6 Dec 2011 08:55:08 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RXyIL-0006Xh-E0; Tue, 06 Dec 2011 17:55:06 +0100 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 ) id 1RXyIL-0001G6-86; Tue, 06 Dec 2011 17:55:05 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: <4EDE40B0.8090903@bbn.com> Date: Tue, 6 Dec 2011 17:55:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> <4EDE40B0.8090903@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: ---- X-RIPE-Spam-Report: Spam Total Points: -4.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 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: 784d7acfe6559f2a0b602ec6519a07195492d968e8de334a6b0419e369fa5068 Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 16:55:09 -0000 On Dec 6, 2011, at 5:20 PM, Andrew Chi wrote: > On 12/3/2011 12:47 AM, Randy Bush wrote: >>>> so are you saying bottom up is just a no-go? >>> I believe I am, in that by following the AIA pointers you may be = lead >>> to places that may not match your chosen trust anchors. >>> This is particularly the case for those who want to set up local TAs >>> as per some draft or another. >>=20 >> as at least one validation implementation, bbn, is bottom up, and was >> done by clueful folk next to some draft or another, i suspect we need = to >> document this in a warning some place. >>=20 >> randy >=20 > BBN's validator does have both top-down and bottom-up capability = (currently, both run by default). This was intended to handle any = future use cases where a child is somehow obtained before its parent. As = it turns out, all use cases that we've tested so far only require = top-down. And the bottom-up capability only leads us to old, abandoned = data. >=20 > Note that Local TA is unaffected; that "tree" is shallow, locally = managed, and processed in a manner that doesn't require AIAs. >=20 > As others have mentioned, bottom-up introduces complexity with (1) = stray AIA pointers, and (2) multiple issuers if AIAs must be strict. We = have a countermeasure for 1, and currently we aren't strict about 2. = But if no bottom-up use cases ever come up, we will default the BBN = validator to run top-down only. Our command line validator supports ad-hoc bottom-up validation at this = time, meaning: - it will follow the AIA pointers up to a self-signed cert, the FIRST = rsync pointer is used. - insist that the self-signed cert matches (one of) your chosen trust = anchor(s) - perform a top-down validation for this chain only But it needs some work. We are thinking of this: - from the next release of our validator we will start supporting doing = top-down validation, and most importantly re-validation, as a background = service - when asked to do bottom-up validation (in a future release): - we check if we have seen an exact binary match for the object = content from a previous top-down run - if not we follow pointers up and fetch missing certificates = until we find a pointer to something in our cache - I would define a match as a CA certificate with the correct = subject (matching issuer) and public key, publication point may differ - The big assumption here is that people use unique key pairs, = but I should hope that's a safe bet I think bottom-up validation has a use for manual validation of objects = that disappeared from the rpki (but may still be valid). And possibly in = future for other (non-sidr even) object types that an address holder may = not necessarily want to publish in the global rpki, but send directly to = any RP for validation instead. In that case, assuming a CMS is used with = an embedded EE with an AIA pointer to the normal CA cert for this = holder, it's just one hop up into the 'known territory'. Tim= From kotikalapudi.sriram@nist.gov Wed Dec 7 14:28:50 2011 Return-Path: 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 13D1C11E808B for ; Wed, 7 Dec 2011 14:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Tj8K6zl0Df5f for ; Wed, 7 Dec 2011 14:28:49 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 6588D11E8073 for ; Wed, 7 Dec 2011 14:28:49 -0800 (PST) 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.339.1; Wed, 7 Dec 2011 17:28:41 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 7 Dec 2011 17:28:06 -0500 From: "Sriram, Kotikalapudi" To: Alex Band , "sidr@ietf.org" Date: Wed, 7 Dec 2011 17:28:46 -0500 Thread-Topic: [sidr] A quick note from RPKI in the wild Thread-Index: AcyzmYVobC6J6eNTRdORolgc0x0dDgBe9UnA Message-ID: References: In-Reply-To: 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 Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 22:28:50 -0000 >By the latter group, 416 Route Origin Authorization (ROA) objects have been created, covering the equivalent of 230,000 /24 prefixes and 8,600 /32 IPv6 prefixes. >MaxLength in ROAs is sorely misunderstood, lots of education is needed there. Most leave the field blank, causing more specific announcements to be invalid. Alex, Can you comment if (a) the more specifics are announced from the same AS as seen in the ROA, or (b) they are announced from a different AS (e.g., customer AS)? If it is the latter, then even the ROA creation (for the less specific) is possibly in violation of: "Before issuing a ROA for a super-block, an operator MUST ensure that any sub-allocations from that block which are announced by other ASs, e.g. customers, have correct ROAs in the RPKI." from the origin-ops doc. http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-13#section-3 As for education, the origin-ops document as well as the use-cases document (Sections 3, 7) http://tools.ietf.org/html/draft-ietf-sidr-usecases-03 can be referred. Sriram From waehlisch@ieee.org Wed Dec 7 20:36:25 2011 Return-Path: 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 4133211E80A2 for ; Wed, 7 Dec 2011 20:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 kPltmVVkF-54 for ; Wed, 7 Dec 2011 20:36:24 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1A611E8099 for ; Wed, 7 Dec 2011 20:36:24 -0800 (PST) Envelope-to: sidr@ietf.org Received: from 75-148-178-225-houston.hfc.comcastbusiness.net ([75.148.178.225] helo=mw-PC.globalsuite.net) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RYViY-0006Yy-H8; Thu, 08 Dec 2011 05:36:23 +0100 Date: Wed, 7 Dec 2011 22:36:20 -0600 (Mittelamerikanische Normalzeit) From: Matthias Waehlisch To: "Sriram, Kotikalapudi" In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 04:36:25 -0000 Hi Sriram, I'm not sure if I understand your quote correctly: Do you only consider the case where the super-block encloses the sub-allocations (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no MaxLength violation, right?. If the super-block does not enclose the announced prefix but there is an incorrect origin AS, you cannot easily decide about the primary reason for the invalidation (i.e., whether the ROA has been created without considering sub-allocations or the origin AS has been announced by mistake). Anyhow, for the measurements we presented last IETF, 80% of the invalid announcements are due to invalid origin ASes. The remaining 20% are due to obvious MaxLength violation (i.e., same origin AS in BGP update and ROA, but longer prefix length in BGP update). Regarding the announcements with incorrect origin AS, for approx. 85% of these BGP updates there exists at least one ROA with a longer MaxLength value compared to the prefix length announced (i.e., the ROA encloses the incorrectly announced prefix). ... Maybe it makes sense to investigate this case in more detail. For example, looking if there is a direct peering between the ROA origin AS and the origin AS within the BGP update. Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net On Wed, 7 Dec 2011, Sriram, Kotikalapudi wrote: > >By the latter group, 416 Route Origin Authorization (ROA) objects > >have been created, covering the equivalent of 230,000 /24 prefixes > >and 8,600 /32 IPv6 prefixes. MaxLength in ROAs is sorely > >misunderstood, lots of education is needed there. Most leave the > >field blank, causing more specific announcements to be invalid. > > Alex, > > Can you comment if (a) the more specifics are announced from the same AS as seen > in the ROA, or (b) they are announced from a different AS (e.g., customer AS)? > If it is the latter, then even the ROA creation (for the less specific) > is possibly in violation of: > "Before issuing a ROA for a super-block, an operator MUST ensure that > any sub-allocations from that block which are announced by other ASs, > e.g. customers, have correct ROAs in the RPKI." from the origin-ops doc. > http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-13#section-3 > > As for education, the origin-ops document as well as the use-cases > document (Sections 3, 7) > http://tools.ietf.org/html/draft-ietf-sidr-usecases-03 > can be referred. > > Sriram > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From kotikalapudi.sriram@nist.gov Thu Dec 8 05:26:55 2011 Return-Path: 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 53ED821F893C for ; Thu, 8 Dec 2011 05:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 HNkBzIq8lfXW for ; Thu, 8 Dec 2011 05:26:54 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 937D521F8A62 for ; Thu, 8 Dec 2011 05:26:54 -0800 (PST) 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.339.1; Thu, 8 Dec 2011 08:26:36 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 8 Dec 2011 08:26:42 -0500 From: "Sriram, Kotikalapudi" To: Matthias Waehlisch Date: Thu, 8 Dec 2011 08:26:00 -0500 Thread-Topic: [sidr] A quick note from RPKI in the wild Thread-Index: Acy1Ytl/0kYQangnQEOQqSlPD7aJVAAQQWik Message-ID: References: , In-Reply-To: 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@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 13:26:55 -0000 Hi Matthias: Thanks. My responses inline. Sriram ________________________________________ >From: Matthias Waehlisch [waehlisch@ieee.org] >Sent: Wednesday, December 07, 2011 11:36 PM >I'm not sure if I understand your quote correctly: Do you only consider the case where the super-block encloses the sub-allocations (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no MaxLength violation, right?. KS: No. I am taking about something different. If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16 and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and has NOT created a ROA yet, then the customer's announcement will be Invalid. The same effect happens whether ISP A's ROA is: {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16) or, {ROA: x.y.0.0/16, AS A, maxLength = 24} or, {ROA: x.y.0.0/16, AS A, maxLength = 18}. With any of the above ROAs, Cust. B's announcement is Invalid because it doesn't have a ROA yet for its sub-allocation. KS: The BCP I quoted from origin-ops requires that ISP A MUST register its ROA only after the customer sub-allocation ROAs have been created (or, register all necessary ROAs simultaneously). In the above example: ISP A can create a ROA for Customer B along with its own ROA as follows: {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B} That ensures that Customer B is not in trouble. This is the bottom up approach for ROA creation. Question is: Do the ISP's (or super-block owners) in your measurement data seem to be compliant with said BCP. >Anyhow, for the measurements we presented last IETF, 80% of the invalid announcements are due to invalid origin ASes. The remaining 20% are due to obvious MaxLength violation (i.e., same origin AS in BGP update and ROA, but longer prefix length in BGP update). Regarding the announcements with incorrect origin AS, for approx. 85% of these BGP updates there exists at least one ROA with a longer MaxLength value compared to the prefix length announced (i.e., the ROA encloses the incorrectly announced prefix). ... Maybe it makes sense to investigate this case in more detail. For example, looking if there is a direct peering between the ROA origin AS and the origin AS within the BGP update. KS: Exactly. That is the info I was requesting. Well, it may not be just the directly peering ASs that you look for. There can be customer's customers, etc. That is, children, grand children, great grand children kind of sub-allocations each with its own AS. Please see Slide 8 of this presentation http://www.ietf.org/proceedings/82/slides/sidr-2.pdf for measurements on customer cone structure (i.e., # prefixes originated vs. their depth in AS path length) for several real ISPs. Sriram From waehlisch@ieee.org Thu Dec 8 09:11:05 2011 Return-Path: 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 8133221F8A7B for ; Thu, 8 Dec 2011 09:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 qBMGJmKnhIn3 for ; Thu, 8 Dec 2011 09:11:00 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id D990D21F85CE for ; Thu, 8 Dec 2011 09:10:59 -0800 (PST) Envelope-to: sidr@ietf.org Received: from 75-148-178-225-houston.hfc.comcastbusiness.net ([75.148.178.225] helo=mw-PC.globalsuite.net) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RYhUP-0005W8-ND; Thu, 08 Dec 2011 18:10:34 +0100 Date: Thu, 8 Dec 2011 11:10:32 -0600 (Mittelamerikanische Normalzeit) From: Matthias Waehlisch To: "Sriram, Kotikalapudi" In-Reply-To: Message-ID: References: , X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 17:11:05 -0000 Hi Sriram, On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote: > >I'm not sure if I understand your quote correctly: Do you only > consider the case where the super-block encloses the sub-allocations > (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no > MaxLength violation, right?. > > KS: No. I am taking about something different. > If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16 > and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and > has NOT created a ROA yet, then the customer's announcement will be Invalid. > The same effect happens whether ISP A's ROA is: > {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16) > or, {ROA: x.y.0.0/16, AS A, maxLength = 24} > or, {ROA: x.y.0.0/16, AS A, maxLength = 18}. > With any of the above ROAs, Cust. B's announcement is Invalid > because it doesn't have a ROA yet for its sub-allocation. > definitely agree. > KS: The BCP I quoted from origin-ops requires that ISP A MUST > register its ROA only after the customer sub-allocation ROAs > have been created (or, register all necessary ROAs simultaneously). > In the above example: ISP A can create a ROA for Customer B > along with its own ROA as follows: > {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B} > That ensures that Customer B is not in trouble. > > This is the bottom up approach for ROA creation. > Question is: Do the ISP's (or super-block owners) in your > measurement data seem to be compliant with said BCP. > My point was that it is not too easy to decide if the ISPs are compliant with the BCP. But I think I got your point: If the origin AS in the Update has (somehow) a *customer* relationship with the ROA AS it is more likely that the ISP's ROA creation is in violation of the BCP. In our last IETF presentation, we identified for the incorrect origin ASes that there exists a ROA Origin that is 1 hop away (ignoring prepending) from the announced origin AS in 90% of the cases. Coming back to your question: Yes, most of the announcements are invalid probably due to the violation of the BCP but I will try to verify in more detail. Cheers matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From carlosm3011@gmail.com Thu Dec 8 12:01:04 2011 Return-Path: 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 49E7321F8B20 for ; Thu, 8 Dec 2011 12:01:04 -0800 (PST) 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 gvuH5WjQFOkv for ; Thu, 8 Dec 2011 12:01:03 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E25D21F8B14 for ; Thu, 8 Dec 2011 12:00:54 -0800 (PST) Received: by laah2 with SMTP id h2so103158laa.31 for ; Thu, 08 Dec 2011 12:00:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=lOToqplEQriSF/uMIxJ+l1L7u6rRcR+yRNnKnKhF5lM=; b=ASLvsfmTaSsiJIEzk6s+7VzbSRub4SXboOoQiuF3P4aRZqjrG5phOufMLIs5XdR86s G7iot+mkez5KwVKllvfx2+YB/kqTJfNkAQjugUlocIqF4LDem5fys8erQ465NkfGVtE2 vcX4jZx9XE3cmcbtIWju9gTQ0Nh1mXUwWQqK8= MIME-Version: 1.0 Received: by 10.152.104.47 with SMTP id gb15mr3013633lab.9.1323374453219; Thu, 08 Dec 2011 12:00:53 -0800 (PST) Received: by 10.152.10.197 with HTTP; Thu, 8 Dec 2011 12:00:53 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Dec 2011 18:00:53 -0200 Message-ID: From: Carlos Martinez-Cagnazzo To: sidr@ietf.org, Arturo Servin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:01:04 -0000 A few numbers we gathered with Arturo. After processing yesterday's RIPE RIS dump from the PTT Metro Sao Paulo sensor, we detected - ~5300 invalid prefixes - ~2800 valid prefixes Out of the invalid prefixes we have: - ~ 3100 invalids due to bad maxLen - ~ 2200 invalids due to wrong origin AS I fully agree with Alex that maxLen is currently badly misunderstood by the community at large. A lot of work is badly needed in order to improve this situation. However, surprisingly enough, many people do not know which AS should originate their own prefixes. Out of the collected data it looks like large companies with operations in different countries are the "worst offenders" in this case. We have put online a little tool to play with this data: http://www.labs.lacnic.net/rpkitools/looking_glass/ The database is refreshed once a day (7 am GMT-2). All feedback is of course welcome. Beware that it is pretty crude at this point and be warned that it can blow up in your face without warning :-) We are working on: - including more queries - allowing CSV downloads of result sets - RESTful-like interface - WHOIS interfacing for richer display Warm regards, Carlos On Thu, Dec 8, 2011 at 3:10 PM, Matthias Waehlisch wro= te: > Hi Sriram, > > On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote: > >> =A0>I'm not sure if I understand your quote correctly: Do you only >> consider the case where the super-block encloses the sub-allocations >> (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no >> MaxLength violation, right?. >> >> KS: No. I am taking about something different. >> If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16 >> and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and >> has NOT created a ROA yet, then the customer's announcement will be Inva= lid. >> The same effect happens whether ISP A's ROA is: >> {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength =3D 16) >> or, {ROA: x.y.0.0/16, AS A, maxLength =3D 24} >> or, {ROA: x.y.0.0/16, AS A, maxLength =3D 18}. >> With any of the above ROAs, Cust. B's announcement is Invalid >> because it doesn't have a ROA yet for its sub-allocation. >> > =A0definitely agree. > >> KS: The BCP I quoted from origin-ops requires that ISP A MUST >> register its ROA only after the customer sub-allocation ROAs >> have been created (or, register all necessary ROAs simultaneously). >> In the above example: ISP A can create a ROA for Customer B >> along with its own ROA as follows: >> {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B} >> That ensures that Customer B is not in trouble. >> >> This is the bottom up approach for ROA creation. >> Question is: Do the ISP's (or super-block owners) in your >> measurement data seem to be compliant with said BCP. >> > =A0My point was that it is not too easy to decide if the ISPs are > compliant with the BCP. But I think I got your point: If the origin AS > in the Update has (somehow) a *customer* relationship with the ROA AS it > is more likely that the ISP's ROA creation is in violation of the BCP. > > =A0In our last IETF presentation, we identified for the incorrect origin > ASes that there exists a ROA Origin that is 1 hop away (ignoring > prepending) from the announced origin AS in 90% of the cases. Coming > back to your question: Yes, most of the announcements are invalid > probably due to the violation of the BCP but I will try to verify in > more detail. > > > Cheers > =A0matthias > > -- > Matthias Waehlisch > . =A0Freie Universitaet Berlin, Inst. fuer Informatik, AG CST > . =A0Takustr. 9, D-14195 Berlin, Germany > .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl > :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://cagnazzo.name =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From waehlisch@ieee.org Thu Dec 8 13:15:27 2011 Return-Path: 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 B3E7221F8B92 for ; Thu, 8 Dec 2011 13:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 RTLclwqxQYzh for ; Thu, 8 Dec 2011 13:15:27 -0800 (PST) Received: from mail2.rz.htw-berlin.de (mail2.rz.htw-berlin.de [141.45.10.102]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1D21F8B87 for ; Thu, 8 Dec 2011 13:15:26 -0800 (PST) Envelope-to: sidr@ietf.org Received: from [12.14.62.2] (helo=mw-PC.Hilton.com) by mail2.rz.htw-berlin.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1RYlJM-000C8n-Kv; Thu, 08 Dec 2011 22:15:26 +0100 Date: Thu, 8 Dec 2011 15:15:25 -0600 (Mittelamerikanische Normalzeit) From: Matthias Waehlisch To: carlos@lacnic.net In-Reply-To: Message-ID: References: X-X-Sender: mw@mail2.rz.fhtw-berlin.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-HTW-SPAMINFO: this message was scanned by eXpurgate (http://www.eleven.de) X-HTW-DELIVERED-TO: sidr@ietf.org Cc: sidr@ietf.org Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 21:15:27 -0000 Hi Carlos, On Thu, 8 Dec 2011, Carlos Martinez-Cagnazzo wrote: > However, surprisingly enough, many people do not know which AS should > originate their own prefixes. Out of the collected data it looks like > large companies with operations in different countries are the "worst > offenders" in this case. > regarding the first sentence: Have you verified by discussions with operators? Thanks matthias -- Matthias Waehlisch . Freie Universitaet Berlin, Inst. fuer Informatik, AG CST . Takustr. 9, D-14195 Berlin, Germany .. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl :. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net From randy@psg.com Thu Dec 8 14:30:33 2011 Return-Path: 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 A506421F8B1E for ; Thu, 8 Dec 2011 14:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 7wXpRgR0Rr+Y for ; Thu, 8 Dec 2011 14:30:33 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6221F8B09 for ; Thu, 8 Dec 2011 14:30:33 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RYmU2-000DWM-4S; Thu, 08 Dec 2011 22:30:30 +0000 Date: Fri, 09 Dec 2011 07:30:29 +0900 Message-ID: From: Randy Bush To: Matthias Waehlisch In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:30:33 -0000 > My point was that it is not too easy to decide if the ISPs are > compliant with the BCP. actually, test versions of the GUIs are now telling you if a roa you are asking to create stomps on anything in the real routing table. randy From aservin@lacnic.net Thu Dec 8 14:38:27 2011 Return-Path: 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 9BBED11E809A for ; Thu, 8 Dec 2011 14:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.845 X-Spam-Level: X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[AWL=-1.755, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, 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 HJI4WfHgaPMA for ; Thu, 8 Dec 2011 14:38:25 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65711E8097 for ; Thu, 8 Dec 2011 14:38:25 -0800 (PST) Received: from [192.168.1.102] (r186-48-211-134.dialup.adsl.anteldata.net.uy [186.48.211.134]) by mail.lacnic.net.uy (Postfix) with ESMTP id 3127C308427; Thu, 8 Dec 2011 20:38:09 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Thu, 8 Dec 2011 20:38:07 -0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Randy Bush X-Mailer: Apple Mail (2.1251.1) 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: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:38:27 -0000 Randy, How do you know what is the invalid data, the roa or the route? Regards, as On 8 Dec 2011, at 20:30, Randy Bush wrote: >> My point was that it is not too easy to decide if the ISPs are >> compliant with the BCP. > > actually, test versions of the GUIs are now telling you if a roa you are > asking to create stomps on anything in the real routing table. > > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Dec 8 14:45:41 2011 Return-Path: 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 BE34C1F0C49 for ; Thu, 8 Dec 2011 14:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 3T53IJqlv76r for ; Thu, 8 Dec 2011 14:45:41 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2761F0C38 for ; Thu, 8 Dec 2011 14:45:41 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RYmif-000DaL-JS; Thu, 08 Dec 2011 22:45:37 +0000 Date: Fri, 09 Dec 2011 07:45:36 +0900 Message-ID: From: Randy Bush To: Arturo Servin In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:45:41 -0000 > How do you know what is the invalid data, the roa or the route? >>> My point was that it is not too easy to decide if the ISPs are >>> compliant with the BCP. >> >> actually, test versions of the GUIs are now telling you if a roa you are >> asking to create stomps on anything in the real routing table. did i say "invalid data?" please do not insert words into my keyboard. randy From Sandra.Murphy@sparta.com Thu Dec 8 14:50:55 2011 Return-Path: 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 E8A9021F85EF for ; Thu, 8 Dec 2011 14:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q63nzrOeCjVO for ; Thu, 8 Dec 2011 14:50:55 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1917E21F85CE for ; Thu, 8 Dec 2011 14:50:55 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id pB8Mor8m019583 for ; Thu, 8 Dec 2011 16:50:53 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pB8Morxi013896 for ; Thu, 8 Dec 2011 16:50:53 -0600 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0339.001; Thu, 8 Dec 2011 17:50:53 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt Thread-Index: AQHMrrp5bZfB/UFGd0WzEB9RYHg47ZXSmaWU Date: Thu, 8 Dec 2011 22:50:52 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60370E2@Hermes.columbia.ads.sparta.com> References: <20111129171026.13083.85070.idtracker@ietfa.amsl.com>, <54B2A2BE-451F-4EF8-BE9A-11BA454B3712@cisco.com> In-Reply-To: <54B2A2BE-451F-4EF8-BE9A-11BA454B3712@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.61.24] Content-Type: multipart/mixed; boundary="_003_24B20D14B2CD29478C8D5D6E9CBB29F60370E2Hermescolumbiaads_" MIME-Version: 1.0 Subject: [sidr] FW: Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:50:56 -0000 --_003_24B20D14B2CD29478C8D5D6E9CBB29F60370E2Hermescolumbiaads_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG,=0A= =0A= Roque mentions below that the authors believe that all comments have been a= ddressed.=0A= =0A= It would help the process and the chairs if those of you who made comments = say whether you believe that your comments have been adequately or acceptab= ly addressed.=0A= =0A= ----Sandy, speaking as wg chair=0A= =0A= =0A= =0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque Gagl= iano [rogaglia@cisco.com]=0A= =0A= Sent: Tuesday, November 29, 2011 12:14 PM=0A= =0A= To: sidr wg list=0A= =0A= Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-algorithm= -agility-04.txt=0A= =0A= =0A= =0A= =0A= =0A= =0A= Dear WG, =0A= =0A= =0A= =0A= We just submitted a new version of the agility draft, where we believe we a= ddressed all the comments during WGLC.=0A= =0A= =0A= =0A= Particularly:=0A= - Decoupling the documents to be updated in two, one signaling the algorith= ms and another one (BCP) with the specific dates.=0A= - Adding a roll-over mechanism for the process.=0A= - Several text improvements and editorial nits=0A= =0A= =0A= =0A= Regards,=0A= Roque=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Begin forwarded message:=0A= =0A= =0A= =0A= From: internet-drafts@ietf.org=0A= =0A= =0A= =0A= Date: November 29, 2011 6:10:26 PM GMT+01:00=0A= =0A= =0A= =0A= To: rogaglia@cisco.com=0A= =0A= =0A= =0A= Cc: turners@ieca.com,=0A= =0A= rogaglia@cisco.com, =0A= kent@bbn.com=0A= =0A= =0A= =0A= Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-04.= txt=0A= =0A= =0A= =0A= =0A= A new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has been suc= cessfully submitted by Roque Gagliano and posted to the IETF repository.=0A= =0A= =0A= =0A= Filename: draft-ietf-sidr-algorithm-agility=0A= =0A= Revision: 04=0A= =0A= Title: Algorithm Agility Procedure for RPKI.=0A= =0A= Creation date: 2011-11-29=0A= =0A= WG ID: sidr=0A= =0A= Number of pages: 29=0A= =0A= =0A= =0A= Abstract:=0A= =0A= This document specifies the process that Certification Authorities=0A= =0A= (CAs) and Relying Parties (RP) participating in the Resource Public=0A= =0A= Key Infrastructure (RPKI) will need to follow to transition to a new=0A= =0A= (and probably cryptographically stronger) algorithm set. The process=0A= =0A= is expected to be completed in a time scale of months or years.=0A= =0A= Consequently, no emergency transition is specified. The transition=0A= =0A= procedure defined in this document supports only a top-down migration=0A= =0A= (parent migrates before children).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= The IETF Secretariat=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= --_003_24B20D14B2CD29478C8D5D6E9CBB29F60370E2Hermescolumbiaads_ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Description: smime.p7s Content-Disposition: attachment; filename="smime.p7s"; size=4389; creation-date="Tue, 29 Nov 2011 17:15:20 GMT"; modification-date="Tue, 29 Nov 2011 17:15:20 GMT" Content-ID: <086585A0B6BD85449C0F10BC3754E64C@ads.sparta.com> Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEFyqcUyRFrhvN5s0SHw/EO4wDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTA1MTAwMDAwMDBaFw0x MjA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxIp28SUiJ/fiFYD/Nct8MUbG WJuPqSnhkfBYMFbbWfDDrHR8OXzK2LkWIuHY5aeAo1nalAQCO40oeTYt0cp9W++a7USNCEDQzgVN Rg0YMYL27YSQoVJnecO3u9wi0jjwhJGblWWxphaztdaMbqiChgND1PHqf7dcs4UjeUOhhKFk0/61 mTmduV721jrxj6ABIlUHAc7nXhKANtDbKdBZzEhM4dbzp6STKq65EQ3xRLVFIuapTgNVckvXtc1e Cyu4xLOLZgaD2aLq9JzBn9y/rFRMtf2euP/Nmzl7QRjAUjpPdo1n6NXWGDtNyR0lUrcJ/x1leccZ Gfj0eaqe+tpJmQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAsvqKrlga/tU0vyBtnBOj 4miDAZxou0/fN2wVEK7dRLzIQLYEJD35sELVhiP8v8wVHtgOeVHz9FyBEVqXmJ0RKy4kMC7gdQxj +t1MlqSTDShEaPMmiwaK6M1iJ9jpBL4JvoiirpHnQYGukkgvTUeqITWZ5ecg03nB3QHuab91Gc+n RZ1OKL4D4p5IkvzWhRlIAlxW9yGZyB8r9V6iu3+1SYEpPPUN3AYCxXeXrn8fJjkOoEodybRiGyfW pMpShpTZg2tHB7ZX162Ti3sRvwA2mktDMnBtEm1pXo15z7yieDUPmjVybMA4byV7AQcbIrjQj0eq c/biBsueC2KWoJY7TDCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRIfD8Q7jAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTEx MjkxNzE1MDJaMCMGCSqGSIb3DQEJBDEWBBTFhvfAM5WLOh7uJu5FWr/KuKsKQDCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBcDBKEAx2+XalyWlq0AMM8wEIN+XJmZs1koYP8EZHozjTj ezafEqMbfBRNdDlawoXPkuchnjlzy7BgBgXhDVZJ5yXBRNQc2MNClQBx4e0TF/UWrre9ab1f8p+n tIhOxmj+A+cy+Xv5yR5IIbcOpAL9BZN43oKLdYDTsaTHNGBkrCme1AvF7Sh3KZoQVC6vDfIxtleY JmUWK+nqCmcIK0JiutQ4WVZtRnG/X3Z3lTQLeoiAV7IYgwN+TLPmB8BPeVSd+q0ooBheooIvTFnA lx0l2eAvXYRJ7xl8OCndIT5YLxeFvUlarGZab2+4e9oSp0YjI3fGdesYHWxyghInMVIwAAAAAAAA --_003_24B20D14B2CD29478C8D5D6E9CBB29F60370E2Hermescolumbiaads_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Tue, 29 Nov 2011 17:15:20 GMT"; modification-date="Tue, 29 Nov 2011 17:15:20 GMT" Content-ID: <2DB3546C62C04D469B80F2B6B364E921@ads.sparta.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpZHIgbWFp bGluZyBsaXN0DQpzaWRyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpZHINCg== --_003_24B20D14B2CD29478C8D5D6E9CBB29F60370E2Hermescolumbiaads_-- From aservin@lacnic.net Thu Dec 8 14:59:08 2011 Return-Path: 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 8160C21F84A0 for ; Thu, 8 Dec 2011 14:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.032 X-Spam-Level: X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_DIALUP=0.862, 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 2ydvG1wkKp9m for ; Thu, 8 Dec 2011 14:59:07 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3121F8487 for ; Thu, 8 Dec 2011 14:59:07 -0800 (PST) Received: from [192.168.1.102] (r186-48-211-134.dialup.adsl.anteldata.net.uy [186.48.211.134]) by mail.lacnic.net.uy (Postfix) with ESMTP id 94CEE308432; Thu, 8 Dec 2011 20:58:56 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: Date: Thu, 8 Dec 2011 20:58:55 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: <897B5B41-A89B-4472-AB76-B94637321279@lacnic.net> References: To: Randy Bush X-Mailer: Apple Mail (2.1251.1) 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: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 22:59:08 -0000 Well, I assumed that if a warning showed up it was because = something was not correct somewhere and the error/warning messages gave = you a hint of why. I imagine then that it just warns that the roa does not match = the routing table and it is up to roa-creator to figure out what the = error is (the roa or the route). Regards, as On 8 Dec 2011, at 20:45, Randy Bush wrote: >> How do you know what is the invalid data, the roa or the route? >>>> My point was that it is not too easy to decide if the ISPs are=20 >>>> compliant with the BCP. >>>=20 >>> actually, test versions of the GUIs are now telling you if a roa you = are >>> asking to create stomps on anything in the real routing table. >=20 > did i say "invalid data?" please do not insert words into my = keyboard. >=20 > randy From tim@ripe.net Fri Dec 9 02:08:05 2011 Return-Path: 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 4C72021F854D for ; Fri, 9 Dec 2011 02:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_UNSUB35=0.431] 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 F+OQHvjihvA9 for ; Fri, 9 Dec 2011 02:08:04 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 03C3021F8549 for ; Fri, 9 Dec 2011 02:08:04 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RYxN3-0003JN-3l; Fri, 09 Dec 2011 11:08:02 +0100 Received: from timbru.vpn.ripe.net ([193.0.21.62]) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1RYxN2-0005DX-Qa; Fri, 09 Dec 2011 11:08:00 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--626786697 From: Tim Bruijnzeels In-Reply-To: <897B5B41-A89B-4472-AB76-B94637321279@lacnic.net> Date: Fri, 9 Dec 2011 11:08:00 +0100 Message-Id: <7B9A2E5E-CF62-4870-8D01-7F2F210D445A@ripe.net> References: <897B5B41-A89B-4472-AB76-B94637321279@lacnic.net> To: Arturo Servin X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: --- X-RIPE-Spam-Report: Spam Total Points: -3.7 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.4 SARE_UNSUB35 BODY: SARE_UNSUB35 -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: 784d7acfe6559f2a0b602ec6519a071900370d1da53479df3d225741317166ee Cc: "Sriram, Kotikalapudi" , "sidr@ietf.org" Subject: Re: [sidr] A quick note from RPKI in the wild X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 10:08:05 -0000 --Apple-Mail-1--626786697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Dec 8, 2011, at 11:58 PM, Arturo Servin wrote: > I imagine then that it just warns that the roa does not match the = routing table and it is up to roa-creator to figure out what the error = is (the roa or the route). Speaking for the implementation in the RIPE NCC hosted pilot service = (managed CA hosted by us, UI in member portal), and validator.... On the portal page where members can manage their ROAs we also check the = announcements that we see(*) for their certified address space, against = their ROAs. Yes, this is a warning only. It is up to the member to make = the judgement what is right and configure things accordingly. Note that = our members can not, at this time, certify their own clients for part of = their address space. So if a client of a member uses a prefix then it's = up the member to ensure that the ROAs for this prefix are set up = correctly. Members can also subscribe to 'roa-alerts'. If they do they get a daily = email about unknown and invalid announcements that we see for them. This = is not real-time alerting of course. We're actually also thinking about = that, but it would require a very different technical solution and we're = focusing on other stuff first... at this stage I think this is mainly = useful for members to make sure that their ROAs actually keep matching = their announcements. Although if some rogue announcement is happening = continuously it will show up. We have also received some feedback where = someone mentioned: "oh... I forgot that we were doing that announcement = there.. I'd better fix it..". I am not sure if that was based on the UI = or the mailing though.. All this was added fairly recently so we actually have quite a lot of = ROAs that were created before this functionality was there. We are = planning to do a one-time mailing soon where we alert members to = announcements invalidated by their ROAs. I am not keen on spamming = people, but with thousands of announcements being invalidated, = presumably largely because the ROAs are wrong -- not the = announcements... I don't see operators trusting this. So, data quality = and fixing this is important. We also compare validated ROAs to the announcements we see in the new = version of our validator. And yes, it's showing a *lot* of invalids. = This is the RP side of course, so changing those ROAs is not really an = option ;) We do provide knobs in the validator though to ignore ROAs for = certain prefixes and add your own ASN, prefix, maxLength entries as = though ROAs existed for them, but managing this doesn't scale to = thousands...=20 An official release announcement is scheduled for Tuesday, but it's = already available for download, and your feedback is appreciated: = https://certification.ripe.net/content/public-repo/releases/net/ripe/rpki-= validator/rpki-validator-app/2.0.0/rpki-validator-app-2.0.0-bin.zip Regards, Tim *: We use the 8-hourly aggregate of routes seen by RIS Route Collectors. = Published here: http://www.ris.ripe.net/dumps/= --Apple-Mail-1--626786697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I imagine = then that it just warns that the roa does not match the routing table = and it is up to roa-creator to figure out what the error is (the roa or = the route).
Speaking for the = implementation in the RIPE NCC hosted pilot service (managed CA = hosted by us, UI in member portal), and = validator....

On the portal page where members = can manage their ROAs we also check the announcements that we see(*) for = their certified address space, against their ROAs. Yes, this is a = warning only. It is up to the member to make the judgement what is = right and configure things accordingly. Note that our members can not, = at this time, certify their own clients for part of their address space. = So if a client of a member uses a prefix then it's up the member to = ensure that the ROAs for this prefix are set up = correctly.

Members can also subscribe to = 'roa-alerts'. If they do they get a daily email about unknown and = invalid announcements that we see for them. This is not real-time = alerting of course. We're actually also thinking about that, but it = would require a very different technical solution and we're focusing on = other stuff first... at this stage I think this is mainly useful for = members to make sure that their ROAs actually keep matching their = announcements. Although if some rogue announcement is happening = continuously it will show up. We have also received some feedback = where someone mentioned: "oh... I forgot that we were doing that = announcement there.. I'd better fix it..". I am not sure if that was = based on the UI or the mailing though..

All = this was added fairly recently so we actually have quite a lot of ROAs = that were created before this functionality was there. We are planning = to do a one-time mailing soon where we alert members to announcements = invalidated by their ROAs. I am not keen on spamming people, but with = thousands of announcements being invalidated, presumably largely because = the ROAs are wrong -- not the announcements... I don't see operators = trusting this. So, data quality and fixing this is = important.


We also compare = validated ROAs to the announcements we see in the new version of our = validator. And yes, it's showing a *lot* of invalids. This is the RP = side of course, so changing those ROAs is not really an option ;) We do = provide knobs in the validator though to ignore ROAs for certain = prefixes and add your own ASN, prefix, maxLength entries as though ROAs = existed for them, but managing this doesn't scale to = thousands... 

An official release = announcement is scheduled for Tuesday, but it's already available for = download, and your feedback is appreciated:




Regards,
Tim


*: We use the 8-hourly = aggregate of routes seen by RIS Route Collectors. Published = here: http://www.ris.ripe.net/dumps/=
= --Apple-Mail-1--626786697-- From kotikalapudi.sriram@nist.gov Fri Dec 9 06:04:09 2011 Return-Path: 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 6FCD021F848F for ; Fri, 9 Dec 2011 06:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 b85PK8T4rR9c for ; Fri, 9 Dec 2011 06:04:09 -0800 (PST) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id B1B9F21F8488 for ; Fri, 9 Dec 2011 06:04:08 -0800 (PST) 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.339.1; Fri, 9 Dec 2011 09:03:59 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Fri, 9 Dec 2011 09:03:25 -0500 From: "Sriram, Kotikalapudi" To: "Murphy, Sandra" , "Murphy, Sandra" , Chris Morrow Date: Fri, 9 Dec 2011 09:03:25 -0500 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt Thread-Index: AcyaSuKRcnlkVgQhS5SrduUD6Rt3gAcLAjn/ Message-ID: References: <20111031232022.26304.78773.idtracker@ietfa.amsl.com> , <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.net> In-Reply-To: <6BE70B4B-E585-459D-ACCF-56B6F800E430@kumari.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: "sidr@ietf.org list" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:04:09 -0000 Sandy, Chris, The WGLC on this doc ended 09/22/2011. We (the authors) submitted a substantially revised version on October 31, 2011, taking into careful consideration all comments that were received during the WGLC. Please see Warren's note (attached below). The authors feel that this document is now ripe and ready for wrapping up the WGLC. Thanks. Sriram ________________________________________ From: Warren Kumari [warren@kumari.net] Sent: Thursday, November 03, 2011 1:06 PM To: Sriram, Kotikalapudi Cc: Warren Kumari; Randy Bush; sidr@ietf.org list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-03.txt On Oct 31, 2011, at 7:56 PM, Sriram, Kotikalapudi wrote: > In this revised version, we (authors) have made changes with careful consideration > of all the comments (mostly of editorial nature) received from Warren and Randy. > > http://www.ietf.org/mail-archive/web/sidr/current/msg03349.html > http://www.ietf.org/mail-archive/web/sidr/current/msg03306.html > http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html > http://www.ietf.org/mail-archive/web/sidr/current/msg03304.html > > We have also made many other edits throughout the doc to improve > clarity and readability. Thank you. I support this moving forward (which is just a formality, I supported it before as well, this all just makes it (IMO) better).. W > > Sriram > ________________________________________ > > Title : Use Cases and Interpretation of RPKI Objects for Issuers and Relying Parties > Author(s) : Terry Manderson > Kotikalapudi Sriram > Russ White > Filename : draft-ietf-sidr-usecases-03.txt > Pages : 30 > Date : 2011-10-31 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-03.txt > From achi@bbn.com Fri Dec 9 07:25:31 2011 Return-Path: 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 8A82C21F852E for ; Fri, 9 Dec 2011 07:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 FkL6T7FzRLW3 for ; Fri, 9 Dec 2011 07:25:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id AEB3D21F84ED for ; Fri, 9 Dec 2011 07:25:30 -0800 (PST) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:64134 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RZ2KE-000FwD-5g; Fri, 09 Dec 2011 10:25:27 -0500 Message-ID: <4EE22863.6020000@bbn.com> Date: Fri, 09 Dec 2011 10:25:23 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Tim Bruijnzeels References: <4ED64E04.7030408@bbn.com> <1BADD28A-5808-48BB-A85D-275ED141D2D8@apnic.net> <4EDE40B0.8090903@bbn.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr wg Subject: Re: [sidr] RPKI validator testing summary X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:25:31 -0000 On 12/6/2011 11:55 AM, Tim Bruijnzeels wrote: > And possibly in future for other (non-sidr even) object types that an address holder may not necessarily want to publish in the global rpki, but send directly to any RP for validation instead. Let's clarify the terminology. 1. Certification path validation is always top down (rfc5280) 2. Path *discovery* is not covered by rfc5280. AIA is for #2, discovery. Based on the preceding discussion, the global rpki appears to need only top-down discovery(?). Tim has given an example where bottom-up discovery could be useful -- data sent directly to an RP rather than published in the global rpki. -Andrew From terry.manderson@icann.org Tue Dec 13 03:29:12 2011 Return-Path: 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 3686421F8801 for ; Tue, 13 Dec 2011 03:29:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.479 X-Spam-Level: X-Spam-Status: No, score=-106.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 qGN-rDSPsXjA for ; Tue, 13 Dec 2011 03:29:11 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78921F858C for ; Tue, 13 Dec 2011 03:29:11 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 13 Dec 2011 03:29:11 -0800 From: Terry Manderson To: "Murphy, Sandra" , "sidr@ietf.org" Date: Tue, 13 Dec 2011 03:29:09 -0800 Thread-Topic: [sidr] FW: Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt Thread-Index: AQHMrrp5bZfB/UFGd0WzEB9RYHg47ZXSmaWUgAcdwps= Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60370E2@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] FW: Fwd: New Version Notification for draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 11:29:12 -0000 I can accept this document as suitable to move on. Cheers, Terry On 9/12/11 8:50 AM, "Murphy, Sandra" wrote: > Dear WG, >=20 > Roque mentions below that the authors believe that all comments have been > addressed. >=20 > It would help the process and the chairs if those of you who made comment= s say > whether you believe that your comments have been adequately or acceptably > addressed. >=20 > ----Sandy, speaking as wg chair >=20 >=20 >=20 > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Roque > Gagliano [rogaglia@cisco.com] >=20 > Sent: Tuesday, November 29, 2011 12:14 PM >=20 > To: sidr wg list >=20 > Subject: [sidr] Fwd: New Version Notification for > draft-ietf-sidr-algorithm-agility-04.txt >=20 >=20 >=20 >=20 >=20 >=20 > Dear WG, >=20 >=20 >=20 > We just submitted a new version of the agility draft, where we believe we > addressed all the comments during WGLC. >=20 >=20 >=20 > Particularly: > - Decoupling the documents to be updated in two, one signaling the algori= thms > and another one (BCP) with the specific dates. > - Adding a roll-over mechanism for the process. > - Several text improvements and editorial nits >=20 >=20 >=20 > Regards, > Roque >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Begin forwarded message: >=20 >=20 >=20 > From: internet-drafts@ietf.org >=20 >=20 >=20 > Date: November 29, 2011 6:10:26 PM GMT+01:00 >=20 >=20 >=20 > To: rogaglia@cisco.com >=20 >=20 >=20 > Cc: turners@ieca.com, >=20 > rogaglia@cisco.com, > kent@bbn.com >=20 >=20 >=20 > Subject: New Version Notification for draft-ietf-sidr-algorithm-agility-0= 4.txt >=20 >=20 >=20 >=20 > A new version of I-D, draft-ietf-sidr-algorithm-agility-04.txt has been > successfully submitted by Roque Gagliano and posted to the IETF repositor= y. >=20 >=20 >=20 > Filename: draft-ietf-sidr-algorithm-agility >=20 > Revision: 04 >=20 > Title: Algorithm Agility Procedure for RPKI. >=20 > Creation date: 2011-11-29 >=20 > WG ID: sidr >=20 > Number of pages: 29 >=20 >=20 >=20 > Abstract: >=20 > This document specifies the process that Certification Authorities >=20 > (CAs) and Relying Parties (RP) participating in the Resource Public >=20 > Key Infrastructure (RPKI) will need to follow to transition to a new >=20 > (and probably cryptographically stronger) algorithm set. The process >=20 > is expected to be completed in a time scale of months or years. >=20 > Consequently, no emergency transition is specified. The transition >=20 > procedure defined in this document supports only a top-down migration >=20 > (parent migrates before children). >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu Dec 15 15:56:47 2011 Return-Path: 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 6DDD111E808A for ; Thu, 15 Dec 2011 15:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 IL6zvG2HXZBU for ; Thu, 15 Dec 2011 15:56:46 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3211E8098 for ; Thu, 15 Dec 2011 15:56:46 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RbLAL-000Azh-7J; Thu, 15 Dec 2011 23:56:45 +0000 Date: Thu, 15 Dec 2011 15:56:44 -0800 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: References: <20111129225106.25323.811.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Last Call: (The RPKI/Router Protocol) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 23:56:47 -0000 [ people whacked me to resend to sidr list ] I am not sure if this is an architectural misunderstanding V a red herring. As you say, NetConf is for *configuring* routers. RPKI-rtr is not used for router configuration, but rather dynamic data, a la IS-IS or BGP. In fact, the RPKI-rtr payload data go into the same data structure as the BGP data. Of course, the configuration of the RPKI-rtr relationship to cache(s) is router configuration, similar to configuring BGP peers, and presumably can be done by NetConf on those platforms which support NetConf. Bottom line: NetConf 'replaces' the CLI, not BGP. FWIW, two or three years ago, not wanting to reinvent the wheel, we looked at NetConf-style payload packaging. After all, Bert and I chartered NetConf back in the day. I still owe a dinner to the two NetConf folk who helped try. Unfortunately the mismatch was non-trivial, though nowhere near the mismatch of DNSsec, at which we also looked (as the Tonys and I had published in 1998, Lutz in 2006, etc., of which I presume you are unaware). When we evaluated the data bloat for NetConf-style packaging we were not cheered. While probably not important for a CLI replacement, for a continuous dynamic protocol the overhead of unpacking XML and decoding the contained ASCII payload drew unhappy whining from the router hackers. NetConf is not ideal for a long-session back-and-forth protocol, with RPKI-rtr's serial number exchange which leaves the router in control of the exchanges and enables incremental update of the data. You *really* do not want the cache to send the full data set to the router every time. And you definitely do not want a cache trying to keep track of the state of O(100) router clients which may or may not still think they are its friend. And, sadly, NetConf is not available on significant platforms where RPKI-rtr is already running today. So, all in all, being lazy, of course we tried. But it was not a good fit. Of course, if you want to have a go at it, I am sure we would be willing to at least kibitz. But first you might want to talk to the vendors who have already implemented RPKI-rtr to see if they would be willing to re-code. randy From achi@bbn.com Fri Dec 16 20:44:54 2011 Return-Path: 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 3E22611E8080 for ; Fri, 16 Dec 2011 20:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 T07uqUsFDVfB for ; Fri, 16 Dec 2011 20:44:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6821F8514 for ; Fri, 16 Dec 2011 20:44:53 -0800 (PST) Received: from dhcp89-089-139.bbn.com ([128.89.89.139]:59639 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Rbm8f-000GXm-Og for sidr@ietf.org; Fri, 16 Dec 2011 23:44:49 -0500 Message-ID: <4EEC1E39.8070306@bbn.com> Date: Fri, 16 Dec 2011 23:44:41 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr wg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] RPSTIR v0.1 (BBN validator) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 04:44:54 -0000 Greetings, We've released the BBN validator code on Sourceforge under the BSD 3-clause license. The current v0.1 reflects the stable version used for testing in Taipei. An update will arrive next week with the work we've been doing recently: RTR-server and syntax conformance diagnostics. Relying Party Security Technology for Internet Routing (RPSTIR, pronounced rip-ster) http://sourceforge.net/projects/rpstir/ We finally named it :) Please feel free to email me if you have any questions, or if you prefer a pre-installed vm. -Andrew From alexb@ripe.net Sat Dec 17 01:30:57 2011 Return-Path: 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 7969E21F8BC5 for ; Sat, 17 Dec 2011 01:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 p7rQpyNQYXLT for ; Sat, 17 Dec 2011 01:30:56 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id AB66121F8BBC for ; Sat, 17 Dec 2011 01:30:56 -0800 (PST) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1RbqbT-0007Fh-Hg; Sat, 17 Dec 2011 10:30:52 +0100 Received: from tel-sslvpn-1.ripe.net ([193.0.20.232] helo=vpn-14.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RbqbT-0001Z2-9q; Sat, 17 Dec 2011 10:30:51 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alex Band In-Reply-To: <4EEC1E39.8070306@bbn.com> Date: Sat, 17 Dec 2011 10:30:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EEC1E39.8070306@bbn.com> To: Andrew Chi X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: ----- X-RIPE-Spam-Report: Spam Total Points: -5.1 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.2 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: ddd0bbf11d1e21354000f5f053f5ae6927ec50d4de2097ba963a3b84ade986d9 Cc: sidr wg Subject: Re: [sidr] RPSTIR v0.1 (BBN validator) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 09:30:57 -0000 Great, I'll make sure a link to it is added here: = http://www.ripe.net/lir-services/resource-management/certification/tools-a= nd-resources On 17 Dec 2011, at 05:44, Andrew Chi wrote: > Greetings, >=20 > We've released the BBN validator code on Sourceforge under the BSD = 3-clause license. The current v0.1 reflects the stable version used for = testing in Taipei. An update will arrive next week with the work we've = been doing recently: RTR-server and syntax conformance diagnostics. >=20 > Relying Party Security Technology for Internet Routing > (RPSTIR, pronounced rip-ster) >=20 > http://sourceforge.net/projects/rpstir/ >=20 > We finally named it :) Please feel free to email me if you have any = questions, or if you prefer a pre-installed vm. >=20 > -Andrew >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From internet-drafts@ietf.org Sat Dec 17 01:50:52 2011 Return-Path: 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 C6F5921F8C07; Sat, 17 Dec 2011 01:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdwL3x8JCKAb; Sat, 17 Dec 2011 01:50:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88921F8AF0; Sat, 17 Dec 2011 01:50:52 -0800 (PST) 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: 3.64p1 Message-ID: <20111217095052.26118.95151.idtracker@ietfa.amsl.com> Date: Sat, 17 Dec 2011 01:50:52 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-21.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 09:50:52 -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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-21.txt Pages : 25 Date : 2011-12-17 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-21.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-rpki-rtr-21.txt From warren@kumari.net Mon Dec 19 06:21:32 2011 Return-Path: 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 5E58721F8B87; Mon, 19 Dec 2011 06:21:32 -0800 (PST) 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 hXmHI20B0Cnp; Mon, 19 Dec 2011 06:21:31 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 81ABE21F8B86; Mon, 19 Dec 2011 06:21:31 -0800 (PST) Received: from dhcp-172-29-46-50.her.corp.google.com (unknown [74.202.225.33]) by vimes.kumari.net (Postfix) with ESMTPSA id 23CCA1B40429; Mon, 19 Dec 2011 09:21:31 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <20111129225106.25323.811.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2011 09:21:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5E2B64CA-8431-46C0-9E5D-992509AF16BD@kumari.net> References: <20111129225106.25323.811.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1084) Cc: IETF-Announce , sidr@ietf.org Subject: Re: [sidr] Last Call: (The RPKI/Router Protocol) to Proposed Standard X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:21:32 -0000 On Nov 29, 2011, at 5:51 PM, The IESG wrote: >=20 > The IESG has received a request from the Secure Inter-Domain Routing = WG > (sidr) to consider the following document: > - 'The RPKI/Router Protocol' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-12-13. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Support. I have (carefully) read and reviewed this document and support = publication=85. W >=20 > Abstract >=20 >=20 > In order to formally validate the origin ASs of BGP announcements, > routers need a simple but reliable mechanism to receive RPKI > [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This > document describes a protocol to deliver validated prefix origin = data > to routers. >=20 >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce >=20 From christopher.morrow@gmail.com Mon Dec 19 09:29:19 2011 Return-Path: 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 CB1DD21F8AB9; Mon, 19 Dec 2011 09:29:19 -0800 (PST) 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 xc7tLWu7EifG; Mon, 19 Dec 2011 09:29:19 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2651921F8AB8; Mon, 19 Dec 2011 09:29:15 -0800 (PST) Received: by ghbg18 with SMTP id g18so514139ghb.31 for ; Mon, 19 Dec 2011 09:29:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=LH1A6jVzRFVptgcKg0y0Zn9nz62PZIh8JNFLYzVu90c=; b=j3mzactNToD/LKIrc7DaPJxPJzWzdmDxd3bHHQUec8lmdSmmk8tOK12JzbDVk0DWnS iQYNJE445ucbxABTu6VrLccVSOm99VPz/PmXt0aDysJB3Dk7r7vFtsS704BRi6kRx8U5 FBTSM1GPI9bTw0yIBp6z3iJ09kmif8qnbi7+s= MIME-Version: 1.0 Received: by 10.50.220.162 with SMTP id px2mr413011igc.17.1324315755425; Mon, 19 Dec 2011 09:29:15 -0800 (PST) Received: by 10.231.193.143 with HTTP; Mon, 19 Dec 2011 09:29:15 -0800 (PST) Date: Mon, 19 Dec 2011 12:29:15 -0500 Message-ID: From: Christopher Morrow To: sidr@ietf.org, sidr-chairs@ietf.org, draft-ietf-sidr-rpki-rtr@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sidr] belated IETF list forward X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:29:19 -0000 Howdy, Apparently I didn't send along the IETF announce/discuss call for: Which is at version 21 these days... The note to the IETF is: apologies for not doing this sooner, there's been some discussion on ietf-discuss (starting): Please have a gander and add your support/non-support/etc if you have a chance. -Chris From internet-drafts@ietf.org Mon Dec 19 19:30:55 2011 Return-Path: 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 6F21221F84F5; Mon, 19 Dec 2011 19:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 gh+51zJkfHsL; Mon, 19 Dec 2011 19:30:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E721F84A4; Mon, 19 Dec 2011 19:30:54 -0800 (PST) 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: 3.64p1 Message-ID: <20111220033054.29409.63124.idtracker@ietfa.amsl.com> Date: Mon, 19 Dec 2011 19:30:54 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-22.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 03:30:55 -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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-22.txt Pages : 25 Date : 2011-12-19 In order to formally validate the origin ASs of BGP announcements, routers need a simple but reliable mechanism to receive RPKI [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This document describes a protocol to deliver validated prefix origin data to routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-rtr-22.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-rpki-rtr-22.txt From Sandra.Murphy@sparta.com Wed Dec 21 13:46:24 2011 Return-Path: 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 6A72E21F8B08 for ; Wed, 21 Dec 2011 13:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1PMFbgPtzm0 for ; Wed, 21 Dec 2011 13:46:23 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8865821F8B06 for ; Wed, 21 Dec 2011 13:46:23 -0800 (PST) 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 pBLLkLpM003572 for ; Wed, 21 Dec 2011 15:46:21 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pBLLkKVY027666 for ; Wed, 21 Dec 2011 15:46:20 -0600 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; Wed, 21 Dec 2011 16:46:15 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: Acxt4oVbqqx666ZTSlCfUhKlXxFTtxSQ5bBp Date: Wed, 21 Dec 2011 21:46:14 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> References: In-Reply-To: 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: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 21:46:24 -0000 Review and comment in the last call period was rather limited. The authors= produced a revised version and not all commenters have responded to the re= vised version to say they are satisfied.=0A= =0A= I reviewed the document to see if comments were addressed. I have comments= - see below. =0A= =0A= I have communicated the comments to the authors and they are producing a re= vised draft.=0A= =0A= Note that some of these comments are due to errors in the facts of the use = cases. Certainly just typos, but in the use cases themselves, so in the ve= ry subject of the draft. Many of these have been in the draft for a while = - so there is reason to believe that the wg has not been paying attention.= =0A= =0A= (One process question to the authors - I think it is likely that we will be= asked questions as to why the examples do not use the documentation blocks= as supplied by rfc5737. This has come up before and mentioning the reason= ing in the draft might ease process.)=0A= =0A= =0A= --Sandy, speaking as wg chair=0A= =0A= =0A= I believe the use case in section 3.7 is incorrect. The example is attempt= ing to restrict the 10.1.128.0/17=0A= prefix from being announced, and uses an AS0 ROA to do that. But due to th= e max length in the ROA for 10.1.0.0/16, the 10.1.128.0/17 would already be= considered invalid. OK, that's not actually an error, it is just an odd e= xample - the AS0 ROA is not needed. Would it be difficult to construct an = example where the AS0 ROA was necessary in order to prevent advertisement?= =0A= =0A= 6.2 and 6.3 talk about 10.1.0.0/ 8. By my understanding, 10.1.0.0/8 is the= same as 10.0.0.0/8 - bits beyond the mask have no effect.=0A= =0A= The following from 7.2.* are all based on my understanding of the "/22" typ= e notation and what it means to be a covering ROA.=0A= =0A= 7.2.3 says that 10.1.0.0/22 is a parent of 10.1.4.0/24. That is not true.= =0A= =0A= 7.2.4 says that a route 10.1.4.0/24 is valid when a ROA for 10.1.0.0/22 wit= h a matching AS exists. Same problem - I don't think the ROA covers the ro= ute.=0A= =0A= 7.2.5 says a route 10.1.4.0/24 is Unknown if the only covering ROA is 10.1.= 0.0/22 and it expires. Same problem.=0A= =0A= 7.2.6 seems to get it right. (Parent is 10.1.4.0/22, which *DOES* cover 10= .1.4.0/24.)=0A= =0A= 7.2.7 says that 10.1.0.0/22 is a parent of 10.1.4.0. Same problem.=0A= =0A= 7.2.8 says that the route to 10.1.4.0/24 is OK when a covering ROA expires = because there is a ROA for 10.1.0.0/22. Same problem.=0A= =0A= The problem is repeated often and no one has complained about this. And it= was the same way in the previous version, so this has been around for awhi= le.=0A= =0A= My other source of complaints is the definitions section. English Nazi ale= rt, skip rest of message if such bores you.=0A= =0A= Why do we need definitions of aggregate, covering aggregate, and covering p= refix? I do not see a significant source of difference between the text of= definitions - although I also find the text for the definitions rather odd= , see below.=0A= =0A= The definition of "specific prefix" sounds like "more specific prefix" to m= e.=0A= =0A= There are many terms used in the document that are undefined. "less specif= ic", "more specific", subprefix, "covering ROA". There's an equivalence in= the use of allocation and prefix, so for example parent is defined as "an = allocation from which the subject prefix is a child" and child is defined a= s "a Sub-allocation that has resulted from an Allocation" (their capitaliza= tion), without ever saying that allocations are a set of prefixes.=0A= =0A= The wording of the definitions is a bit odd:=0A= =0A= Specific route - A route that has a longer prefix mask length in the=0A= presence of another route with a smaller mask length.=0A= =0A= Aggregate route - A route that has a shorter prefix mask length in=0A= the presence of a specific route.=0A= =0A= Covering Aggregate - A route that has a shorter prefix mask length=0A= relative to a route in consideration.=0A= =0A= What does "in the presence of" mean? I imagine it means something like "in= comparison to".=0A= =0A= >From this definition, 12.0.0.0/8 is an aggregate of 192.7.0.0/16 - the defi= nition is given in terms of only the mask length without mentioning the nec= essary match in the common mask bits.=0A= =0A= In the definition of aggregate route, does "specific route" have the meanin= g as defined directly above? In which case, what is the "another route" wh= ose presence determines the specific route? Given that the definition of s= pecific route is itself circular, I suspect that these two definitions are = circular - specific means longer prefix than the aggregate, aggregate means= a shorter prefix than the specific.=0A= =0A= But that means that "aggregate route" is a relation between routes, not an = absolute. But then why do we need both "aggregate route" and "covering agg= regate"? Does the difference lie in the use of "relative to a route in con= sideration" instead of "in the presence of a specific route"?=0A= =0A= The terms used in the text are used as I understand them, so likely those w= ho understand these terms will ignore the definitions section. But those w= ho do not already understand the terms might be really confused by these de= finitions. IMHO.=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Christophe= r Morrow [christopher.morrow@gmail.com]=0A= Sent: Thursday, September 08, 2011 12:48 AM=0A= To: sidr@ietf.org; sidr-chairs@ietf.org=0A= Subject: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt=0A= =0A= Hello work-group-readers,=0A= The authors did some significant work on this doc, it seems to have=0A= settled into a groove, could we get some input on where this stands?=0A= This is a WGLC for the document which should end: 09/22/2011 (Sept 22,=0A= 2011 for those with the other flavor of clocks).=0A= =0A= document link: =0A= =0A= The abstract:=0A= "This document provides use cases, directions, and interpretations for=0A= organizations and relying parties when creating or encountering RPKI=0A= object scenarios in the public RPKI in relation to the Internet=0A= routing system."=0A= =0A= Please have a final read/comment and let's move things along.=0A= =0A= Thanks!=0A= -Chris=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From randy@psg.com Wed Dec 21 14:31:05 2011 Return-Path: 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 3C57A11E80C9 for ; Wed, 21 Dec 2011 14:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3hOX5+eksMp for ; Wed, 21 Dec 2011 14:31:04 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BD1CA11E80C0 for ; Wed, 21 Dec 2011 14:31:04 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RdUgf-0004yE-PH; Wed, 21 Dec 2011 22:31:03 +0000 Date: Wed, 21 Dec 2011 17:30:59 -0500 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 22:31:05 -0000 > Specific route - A route that has a longer prefix mask length in > the presence of another route with a smaller mask length. > > Aggregate route - A route that has a shorter prefix mask length in > the presence of a specific route. > > Covering Aggregate - A route that has a shorter prefix mask length > relative to a route in consideration. jgs worked hard on this in pfx-validate in order to get a nice set of syntax and semantics. might be wise to steal. randy From gih@apnic.net Wed Dec 21 16:56:25 2011 Return-Path: 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 EC49B21F8AC9 for ; Wed, 21 Dec 2011 16:56:25 -0800 (PST) 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 wOM6ydbuaMQZ for ; Wed, 21 Dec 2011 16:56:25 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 61B4621F889A for ; Wed, 21 Dec 2011 16:56:24 -0800 (PST) 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 7F335B6760; Thu, 22 Dec 2011 10:56:22 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> Date: Thu, 22 Dec 2011 11:56:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> To: sidr wg X-Mailer: Apple Mail (2.1251.1) Cc: Sandra Murphy Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 00:56:26 -0000 And why not use the documentation prefix(es) and documentation AS(es) in = this draft. rather than 10/8 etc. That's what they are there for. Geoff On 22/12/2011, at 8:46 AM, Murphy, Sandra wrote: > Review and comment in the last call period was rather limited. The = authors produced a revised version and not all commenters have responded = to the revised version to say they are satisfied. >=20 > I reviewed the document to see if comments were addressed. I have = comments - see below. =20 >=20 > I have communicated the comments to the authors and they are producing = a revised draft. >=20 > Note that some of these comments are due to errors in the facts of the = use cases. Certainly just typos, but in the use cases themselves, so in = the very subject of the draft. Many of these have been in the draft for = a while - so there is reason to believe that the wg has not been paying = attention. >=20 > (One process question to the authors - I think it is likely that we = will be asked questions as to why the examples do not use the = documentation blocks as supplied by rfc5737. This has come up before = and mentioning the reasoning in the draft might ease process.) >=20 >=20 > --Sandy, speaking as wg chair >=20 >=20 > I believe the use case in section 3.7 is incorrect. The example is = attempting to restrict the 10.1.128.0/17 > prefix from being announced, and uses an AS0 ROA to do that. But due = to the max length in the ROA for 10.1.0.0/16, the 10.1.128.0/17 would = already be considered invalid. OK, that's not actually an error, it is = just an odd example - the AS0 ROA is not needed. Would it be difficult = to construct an example where the AS0 ROA was necessary in order to = prevent advertisement? >=20 > 6.2 and 6.3 talk about 10.1.0.0/ 8. By my understanding, 10.1.0.0/8 = is the same as 10.0.0.0/8 - bits beyond the mask have no effect. >=20 > The following from 7.2.* are all based on my understanding of the = "/22" type notation and what it means to be a covering ROA. >=20 > 7.2.3 says that 10.1.0.0/22 is a parent of 10.1.4.0/24. That is not = true. >=20 > 7.2.4 says that a route 10.1.4.0/24 is valid when a ROA for = 10.1.0.0/22 with a matching AS exists. Same problem - I don't think the = ROA covers the route. >=20 > 7.2.5 says a route 10.1.4.0/24 is Unknown if the only covering ROA is = 10.1.0.0/22 and it expires. Same problem. >=20 > 7.2.6 seems to get it right. (Parent is 10.1.4.0/22, which *DOES* = cover 10.1.4.0/24.) >=20 > 7.2.7 says that 10.1.0.0/22 is a parent of 10.1.4.0. Same problem. >=20 > 7.2.8 says that the route to 10.1.4.0/24 is OK when a covering ROA = expires because there is a ROA for 10.1.0.0/22. Same problem. >=20 > The problem is repeated often and no one has complained about this. = And it was the same way in the previous version, so this has been around = for awhile. >=20 > My other source of complaints is the definitions section. English = Nazi alert, skip rest of message if such bores you. >=20 > Why do we need definitions of aggregate, covering aggregate, and = covering prefix? I do not see a significant source of difference = between the text of definitions - although I also find the text for the = definitions rather odd, see below. >=20 > The definition of "specific prefix" sounds like "more specific prefix" = to me. >=20 > There are many terms used in the document that are undefined. "less = specific", "more specific", subprefix, "covering ROA". There's an = equivalence in the use of allocation and prefix, so for example parent = is defined as "an allocation from which the subject prefix is a child" = and child is defined as "a Sub-allocation that has resulted from an = Allocation" (their capitalization), without ever saying that allocations = are a set of prefixes. >=20 > The wording of the definitions is a bit odd: >=20 > Specific route - A route that has a longer prefix mask length in the > presence of another route with a smaller mask length. >=20 > Aggregate route - A route that has a shorter prefix mask length in > the presence of a specific route. >=20 > Covering Aggregate - A route that has a shorter prefix mask length > relative to a route in consideration. >=20 > What does "in the presence of" mean? I imagine it means something = like "in comparison to". >=20 > =46rom this definition, 12.0.0.0/8 is an aggregate of 192.7.0.0/16 - = the definition is given in terms of only the mask length without = mentioning the necessary match in the common mask bits. >=20 > In the definition of aggregate route, does "specific route" have the = meaning as defined directly above? In which case, what is the "another = route" whose presence determines the specific route? Given that the = definition of specific route is itself circular, I suspect that these = two definitions are circular - specific means longer prefix than the = aggregate, aggregate means a shorter prefix than the specific. >=20 > But that means that "aggregate route" is a relation between routes, = not an absolute. But then why do we need both "aggregate route" and = "covering aggregate"? Does the difference lie in the use of "relative = to a route in consideration" instead of "in the presence of a specific = route"? >=20 > The terms used in the text are used as I understand them, so likely = those who understand these terms will ignore the definitions section. = But those who do not already understand the terms might be really = confused by these definitions. IMHO. >=20 >=20 > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Christopher Morrow [christopher.morrow@gmail.com] > Sent: Thursday, September 08, 2011 12:48 AM > To: sidr@ietf.org; sidr-chairs@ietf.org > Subject: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt >=20 > Hello work-group-readers, > The authors did some significant work on this doc, it seems to have > settled into a groove, could we get some input on where this stands? > This is a WGLC for the document which should end: 09/22/2011 (Sept 22, > 2011 for those with the other flavor of clocks). >=20 > document link: = >=20 > The abstract: > "This document provides use cases, directions, and interpretations for > organizations and relying parties when creating or encountering RPKI > object scenarios in the public RPKI in relation to the Internet > routing system." >=20 > Please have a final read/comment and let's move things along. >=20 > Thanks! > -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 -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih@apnic.net From randy@psg.com Wed Dec 21 19:32:30 2011 Return-Path: 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 A369811E80EE for ; Wed, 21 Dec 2011 19:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQr6U-P8rtHx for ; Wed, 21 Dec 2011 19:32:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 36B8211E80EB for ; Wed, 21 Dec 2011 19:32:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RdZON-0009hQ-EH; Thu, 22 Dec 2011 03:32:27 +0000 Date: Wed, 21 Dec 2011 22:32:07 -0500 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.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: Sandra Murphy , sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 03:32:30 -0000 > And why not use the documentation prefix(es) and documentation AS(es) > in this draft. rather than 10/8 etc. That's what they are there for. the draft in $subject uses 10/8. i think sandy was pointing out that the ips and asns in rfc 5737 might be more appropriate. is the latter what you mean by "documentation xxx?" so what is it you are suggesting? i suspect you are agreeing with sandy but can not parse. my error, likely, too much good theater and food. randy From gih@apnic.net Wed Dec 21 19:37:51 2011 Return-Path: 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 71C6811E8097 for ; Wed, 21 Dec 2011 19:37:51 -0800 (PST) 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 nlPgRurpEQ3e for ; Wed, 21 Dec 2011 19:37:51 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id D52AC11E8096 for ; Wed, 21 Dec 2011 19:37:50 -0800 (PST) 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 B5E52B6768; Thu, 22 Dec 2011 13:37:48 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Thu, 22 Dec 2011 14:37:48 +1100 Content-Transfer-Encoding: 7bit Message-Id: <95FA4465-53B7-40D8-89A8-063EE4A1C1F4@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.net> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 03:37:51 -0000 On 22/12/2011, at 2:32 PM, Randy Bush wrote: >> And why not use the documentation prefix(es) and documentation AS(es) >> in this draft. rather than 10/8 etc. That's what they are there for. > > the draft in $subject uses 10/8. i think sandy was pointing out that > the ips and asns in rfc 5737 might be more appropriate. is the latter > what you mean by "documentation xxx?" > > so what is it you are suggesting? i suspect you are agreeing with sandy > but can not parse. my error, likely, too much good theater and food. > > randy I think the set is RFC5737, RFC3849, and RFC5398. That is what I am suggesting. Geoff From randy@psg.com Wed Dec 21 20:10:14 2011 Return-Path: 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 B68C01F0C50 for ; Wed, 21 Dec 2011 20:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydWNgWcP-AdS for ; Wed, 21 Dec 2011 20:10:13 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9B1F0C38 for ; Wed, 21 Dec 2011 20:10:13 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RdZyi-0009l3-M2; Thu, 22 Dec 2011 04:10:00 +0000 Date: Wed, 21 Dec 2011 23:09:59 -0500 Message-ID: From: Randy Bush To: Geoff Huston In-Reply-To: <95FA4465-53B7-40D8-89A8-063EE4A1C1F4@apnic.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.net> <95FA4465-53B7-40D8-89A8-063EE4A1C1F4@apnic.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: Sandra Murphy , sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 04:10:15 -0000 > I think the set is RFC5737, RFC3849, and RFC5398. > That is what I am suggesting. thanks. seems great to me, for the little that's worth. i should not try to think at this hour, especially working while jabbering with a generous friend being remote hands in ashburn colo. randy From terry.manderson@icann.org Wed Dec 21 22:00:05 2011 Return-Path: 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 DA1F221F8B0E for ; Wed, 21 Dec 2011 22:00:05 -0800 (PST) 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 nvHKPxq9aC8Q for ; Wed, 21 Dec 2011 22:00:05 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6516121F847A for ; Wed, 21 Dec 2011 22:00:05 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 21 Dec 2011 22:00:04 -0800 From: Terry Manderson To: Randy Bush , Geoff Huston Date: Wed, 21 Dec 2011 21:59:57 -0800 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: AczAWmUYBB3kmbnqQF6OQl1/Onu3qQAFImQS Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Sandra Murphy , sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 06:00:06 -0000 The draft uses RFC1918 address space as there are only three(3) IPv4 blocks made available by RFC 5737 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3). Given that the key part of the use cases really revolves around the prefix length and MaxLen - the bit= s that make up the address part are meaningless. So if we were to construct the use cases around /24s, and then sub-allocate/assign /25's and /26's in the document, I posit the document would be less meaningful to a reader. (I don't see too many cases of /26's in BGP, yes from time to time, but not in numbers and not routinely) I feel more comfortable saying that using 10/8 provides deeper and more meaningful examples. As for the ASNs, I originally started writing the draft using ASNs from RFC5398, however a few ASNs from outside the range 64496 - 64511 crept in. They can be cleaned up easily enough without having to rejig the document. There are no use cases using IPv6 and its documentation prefix from RFC3849= . A quick discussion between authors wayback suggested a KISS principle. Cheers Terry On 22/12/11 1:32 PM, "Randy Bush" wrote: >> And why not use the documentation prefix(es) and documentation AS(es) >> in this draft. rather than 10/8 etc. That's what they are there for. >=20 > the draft in $subject uses 10/8. i think sandy was pointing out that > the ips and asns in rfc 5737 might be more appropriate. is the latter > what you mean by "documentation xxx?" >=20 > so what is it you are suggesting? i suspect you are agreeing with sandy > but can not parse. my error, likely, too much good theater and food. >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@sparta.com Thu Dec 22 07:13:54 2011 Return-Path: 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 E7C4521F8B37 for ; Thu, 22 Dec 2011 07:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw4+Evr8Qt2d for ; Thu, 22 Dec 2011 07:13:51 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id B70CC21F84E5 for ; Thu, 22 Dec 2011 07:13:50 -0800 (PST) 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 pBMFDicT008693; Thu, 22 Dec 2011 09:13:44 -0600 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id pBMFDhIV011394; Thu, 22 Dec 2011 09:13:43 -0600 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; Thu, 22 Dec 2011 10:13:43 -0500 From: "Murphy, Sandra" To: Geoff Huston , Randy Bush Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: Acxt4oVbqqx666ZTSlCfUhKlXxFTtxSQ5bBpABIVMgAABW/rgAAAMtAAAA13yBM= Date: Thu, 22 Dec 2011 15:13:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6062106@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.net> , <95FA4465-53B7-40D8-89A8-063EE4A1C1F4@apnic.net> In-Reply-To: <95FA4465-53B7-40D8-89A8-063EE4A1C1F4@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: sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:13:55 -0000 I agree that using the standard documentation prefixes would be best, but I= was actually pointing to the previous discussion of the use of documentati= on prefixes.=0A= =0A= On 8 Sep, Randy (http://www.ietf.org/mail-archive/web/sidr/current/msg03304= .html) said:=0A= =0A= >look at rfc 5737 IPv4 Address Blocks Reserved for Documentation=0A= =0A= and on 8 Sep, Terry (http://www.ietf.org/mail-archive/web/sidr/current/msg0= 3305.html) replied:=0A= =0A= >From time to time authors choose to use non rfc5737 address blocks as the= =0A= >examples can't often be adequately described or remain uniform with the=0A= >documentation prefixes.=0A= =0A= I was suggesting that the authors make the argument that the documentation = prefixes are insufficient for this draft's purpose *in the draft* to avoid = making the same argument as the document progresses. =0A= =0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: Geoff Huston [gih@apnic.net]=0A= Sent: Wednesday, December 21, 2011 10:37 PM=0A= To: Randy Bush=0A= Cc: sidr wg; Murphy, Sandra=0A= Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt=0A= =0A= On 22/12/2011, at 2:32 PM, Randy Bush wrote:=0A= =0A= >> And why not use the documentation prefix(es) and documentation AS(es)=0A= >> in this draft. rather than 10/8 etc. That's what they are there for.=0A= >=0A= > the draft in $subject uses 10/8. i think sandy was pointing out that=0A= > the ips and asns in rfc 5737 might be more appropriate. is the latter=0A= > what you mean by "documentation xxx?"=0A= >=0A= > so what is it you are suggesting? i suspect you are agreeing with sandy= =0A= > but can not parse. my error, likely, too much good theater and food.=0A= >=0A= > randy=0A= =0A= =0A= I think the set is RFC5737, RFC3849, and RFC5398.=0A= =0A= That is what I am suggesting.=0A= =0A= Geoff=0A= =0A= From randy@psg.com Thu Dec 22 07:15:45 2011 Return-Path: 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 87A6421F8B4E for ; Thu, 22 Dec 2011 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oSqpyH5HCn9 for ; Thu, 22 Dec 2011 07:15:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF5321F8B37 for ; Thu, 22 Dec 2011 07:15:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RdkMt-000B4N-Pc; Thu, 22 Dec 2011 15:15:40 +0000 Date: Thu, 22 Dec 2011 10:15:37 -0500 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6062106@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6061027@Hermes.columbia.ads.sparta.com> <3D3E64A7-83E9-4982-B383-AEA42B8521E7@apnic.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 Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 15:15:45 -0000 > I was suggesting that the authors make the argument that the > documentation prefixes are insufficient for this draft's purpose *in > the draft* to avoid making the same argument as the document > progresses. ! From terry.manderson@icann.org Thu Dec 22 15:41:45 2011 Return-Path: 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 817CA21F86A0 for ; Thu, 22 Dec 2011 15:41:45 -0800 (PST) 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=[AWL=0.000, 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 w-ABmwcDPsFH for ; Thu, 22 Dec 2011 15:41:45 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1859221F84B2 for ; Thu, 22 Dec 2011 15:41:45 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 22 Dec 2011 15:41:44 -0800 From: Terry Manderson To: "Murphy, Sandra" , Geoff Huston , Randy Bush Date: Thu, 22 Dec 2011 15:41:42 -0800 Thread-Topic: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt Thread-Index: Acxt4oVbqqx666ZTSlCfUhKlXxFTtxSQ5bBpABIVMgAABW/rgAAAMtAAAA13yBMAEhm39Q== Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6062106@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg Subject: Re: [sidr] WGLC: draft-ietf-sidr-usecases-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 23:41:45 -0000 >=20 > and on 8 Sep, Terry > (http://www.ietf.org/mail-archive/web/sidr/current/msg03305.html) replied= : >=20 >> From time to time authors choose to use non rfc5737 address blocks as th= e >> examples can't often be adequately described or remain uniform with the >> documentation prefixes. >=20 > I was suggesting that the authors make the argument that the documentatio= n > prefixes are insufficient for this draft's purpose *in the draft* to avoi= d > making the same argument as the document progresses. >=20 And that seems like a perfectly reasonable thing to do :-) Cheers Terry From danny@tcb.net Thu Dec 22 21:16:01 2011 Return-Path: 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 A135E1F0C51 for ; Thu, 22 Dec 2011 21:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3rMnfCQc-rr for ; Thu, 22 Dec 2011 21:16:00 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDBD1F0C3B for ; Thu, 22 Dec 2011 21:16:00 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 04CA1268063; Thu, 22 Dec 2011 22:16:00 -0700 (MST) Received: from new-host-7.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; Thu, 22 Dec 2011 22:15:59 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=98.118.240.226; client-port=51037; 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=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Danny McPherson In-Reply-To: <20111129171024.13083.74762.idtracker@ietfa.amsl.com> Date: Fri, 23 Dec 2011 00:15:54 -0500 Content-Transfer-Encoding: 7bit Message-Id: <0E9A31B3-0BAF-4942-AAC6-486BCF17394B@tcb.net> References: <20111129171024.13083.74762.idtracker@ietfa.amsl.com> To: sidr@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 05:16:01 -0000 I've reviewed the -04 version of the draft and have the following comments (most of which persist from the previous version of the draft, although many were accommodated - thanks). -danny =============================================== Substantial: --- S 4.4 (&& S 4.6): I remain concerned that independent publication points for product sets for different algorithms are not a mandatory requirement. Is there any reason why, for example, this is a SHOULD rather than a MUST: "Suite B product SHOULD be stored at independent publication points" It's precisely the assumptions this introduces in S 4.4 that makes me think independent publication points must be a hard requirement (i.e., MUST). S 4.6 on same issue: "Since the Suite B products SHOULD be published at distinct publication points, RPs that cannot process Suite B products can be expected to revert to the Suite A products that still exist." This text to me still assumes interdependence between independent publication points, even after you explicitly stated that an algorithm that validates under either object (which technically, they're independent anyway) should be considered valid. It lends itself to the thought that an RP should prolly maintain both suites until EOL, which isn't necessarily the suggestion, methinks. --- S 4.4: "If the Suite B algorithm is deemed unsuitable, the algorithm transition timeline and the algorithm specification documents MUST be replaced. CAs MUST cease accepting requests for certificates under Suite B, and Suite B certificates that have been issued MUST be revoked." I know this is in the Phase 1 section, but it may be worth iterating here that this is only possible in these early phases of the transition. --- S 4.5: "An RP that validates all signed product sets using both Algorithm Suite A or Algorithm Suite B, SHOULD expect the same results. However, an object that validates using either Algorithm Suite A or Algorithm Suite B MUST be considered valid. A detailed analysis on the validation of multiple instance of signed objects is included in Section 6." --- S 4.6: "Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites and all RPs MUST be able to validate them using either suite. An object that validates using either Algorithm Suite A or Algorithm Suite B MUST be considered valid. It is RECOMMENDED that, in preparation for Phase 4, RPs utilize Suite B as the first and preferred option for validation throughout this phase. Thus, for example, an RP SHOULD try to validate the sets of signed products retrieved from the Algorithm Suite B repository first. If this effort fails (relative to the local validation policy), the RP SHOULD revert to using the Algorithm Suite A repository." Given that the two algorithm suite product sets are independent and use different publication points there may be a place where "all signed product sets" are NOT available using both algorithm suites, no? Else what if they aren't what would you do anyway? Phase 6 says there must be parity as well, particularly during Phase 2 & 3, and it's not really the case is it? It's a darn good idea, but that's a different issue. --- S 4.7: I don't know what this text is aiming to accomplish (i.e., where else would they be published)? "All signed products sets issued using Suite A MUST be published at their corresponding publication points, but signed products sets issued using Suite C MAY be published at their corresponding publication points." --- S 4.7: My previous concerns persist here: "Also, every RP MUST validate signed product sets using Suite A but also MAY validate signed product sets using Suite C. However, RPs SHOULD NOT assume the Suite C repository is complete." If RPs do this and you've got Suite A that validates and Suite C that does not then what is the behavior? It really has to be just as in earlier phases, where valid in either is valid, period, no? That's why I don't like this collision probability we're introducing. --- S 6: Where do we say that both "instances" of such products MUST contain the same resources (and what's an "instance")? I don't see this requirement earlier in the draft and it seems a REALLY bad requirement to be - they MUST be independent: "Because both instances of such products MUST contain the same resources, relying on either instance will yield the same outcome." For example, this text in the following section itself is in conflict with the S 6 requirement: "As the algorithm migration process mandates the maintenance of two parallel certificate hierarchies, revocations requests for each algorithm suite MUST be handled independently. A Child CA MUST request revocation of a certificate relative to a specific algorithm suite." --- S 7: I don't understand this revocation requirement, the hierarchies are independent and it'd seem perfectly reasonable to revoke something in one hierarchy and not in the other: "During phase 2 and phase 3, the two parallel certificate hierarchies are designed to carry identical information. Consequently, a child CA requesting the revocation of a certificate during these two phases MUST perform that request for both algorithm suites (A and B). A non-leaf CA is NOT required to verify that its child CAs comply with this requirement." --- S 11: This text is also in conflict with earlier requirements of absolute parity across the two independent hierarchies (e.g., CRLs in both, etc..): "If a CA does not complete its migration to the new algorithm suite as described in this document (after the EOL of the "old" algorithm suite), its signed product set will no longer be valid. Consequently, the RPKI may, at the end of Phase 4, have a smaller number of valid signed products than before starting the process." =============================================== Nits: --- S 2: This seems a bit redundant: "This document does not specify any algorithm suite. This document does not specify any algorithm suite per se." --- S 3: Technically, all are changing algorithms suites in this document, why are you just indicating this for CA Y? CA X The CA that issued CA Y's certificate (i.e., CA Y's parent), used in examples in this document. CA Y The CA that is changing keys and/or algorithm suites, used in examples this document CA Z A CA that is a "child" of CA Y, used in examples this document --- S 3: I think linking in this "unilateral" re-issuance function and employing the term you've defined here would be of benefit (e.g., in S 4.1): Certificate re-issuance (unilateral) A CA MAY reissue a certificate to a subordinate Subject without the involvement of the Subject. The public key, resource extensions, and most other fields are copied from the current Subject certificate into the next Subject certificate. The Issuer name MAY change, if necessary to reflect the Subject name in the CA certificate under which the reissued certificate will be validated. The validity interval also MAY be changed. This action is defined as a unilateral certificate re-issuance. --- S 3: s/conventions use in examples/conventions used in examples/ --- S 4.1: s/have re-issued all of its signed/have reissued all of their signed/ "CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST have re-issued all of its signed product set under the Algorithm B suite." --- S 4.2: s/certificate.(X.509/certificate. (X.509/ s/RPs might be ready/RPs might not be ready/ ? "For example, many CAs might not prepared to issue signed products under Suite B, or many RPs might be ready to process Suite B product sets." --- S 4.4: s/since Suite B product SHOULD/since Suite B product sets SHOULD/ --- S 4.5: s/each signed product sets MUST/each signed product set MUST/ s/Section 4.2../Section 4.2./ s/Suite B, SHOULD/Suite B SHOULD/ s/multiple instance of signed objects/multiple instances of signed objects/ --- S 4.7: "old Suite A"? Isn't that now "Algorithm Suite C" by definition? You do nearly the same thing in S 4.8 as well, but you add a qualifier: "Suite C (old Suite A)" --- From internet-drafts@ietf.org Wed Dec 28 12:38:23 2011 Return-Path: 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 B89FA21F86A5; Wed, 28 Dec 2011 12:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 l2uExnsjJhcR; Wed, 28 Dec 2011 12:38:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C20821F8508; Wed, 28 Dec 2011 12:38:23 -0800 (PST) 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: 3.64p1 Message-ID: <20111228203823.26393.65132.idtracker@ietfa.amsl.com> Date: Wed, 28 Dec 2011 12:38:23 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-ghostbusters-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 20:38:24 -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 : The RPKI Ghostbusters Record Author(s) : Randy Bush Filename : draft-ietf-sidr-ghostbusters-16.txt Pages : 9 Date : 2011-12-28 In the Resource Public Key Infrastructure (RPKI), resource certificates completely obscure names or any other information which might be useful for contacting responsible parties to deal with issues of certificate expiration, maintenance, roll-overs, compromises, etc. This draft describes the RPKI Ghostbusters Record containing human contact information which may be verified (indirectly) by a CA certificate. The data in the record are those of a severely profiled vCard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-ghostbusters-16.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-ghostbusters-16.txt