From randy@psg.com Mon Jan 2 00:51:48 2012 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 59CA421F8E95 for ; Mon, 2 Jan 2012 00:51:48 -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 atPomQgiih06 for ; Mon, 2 Jan 2012 00:51:47 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id D518221F8E6D for ; Mon, 2 Jan 2012 00:51:47 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RhdcQ-0000pc-9G for sidr@ietf.org; Mon, 02 Jan 2012 08:51:46 +0000 Date: Mon, 02 Jan 2012 17:51:45 +0900 Message-ID: From: Randy Bush To: sidr wg list References: <20120102084718.30235.85717.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 Subject: [sidr] draft-ymbk-rpki-rtr-impl-00.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, 02 Jan 2012 08:51:48 -0000 the authors would like to request that the sidr wg accept this draft as a wg work item. randy --- A new version of I-D, draft-ymbk-rpki-rtr-impl-00.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-rtr-impl Revision: 00 Title: RPKI Router Implementation Report Creation date: 2012-01-02 WG ID: Individual Submission Number of pages: 18 Abstract: This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. From rogaglia@cisco.com Tue Jan 3 03:23:56 2012 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 C0ED121F84D9 for ; Tue, 3 Jan 2012 03:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glp1F6qK8fyb for ; Tue, 3 Jan 2012 03:23:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6087021F84D2 for ; Tue, 3 Jan 2012 03:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=48342; q=dns/txt; s=iport; t=1325589834; x=1326799434; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/fvkySAe3tQYYiwp9sg13EWE6+prnNNamH/KwgDFb9w=; b=Oaa0CoYCgpQZsLqgKV9KzOC90gVStMEg9AK+0rmCyf5FJPXOHmWa6xIA 1RpW1QRP8MCtQJpbi5mu7jiCfj7arQyHE57koU038PkINoDBe+vCi1MaM mI2pXKYvZKZNj0a6jI3xkrV+W7pgMJTjniBLhpeYQyeoPhtXTKbFw2Za5 w=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAQAMDkAk+tJV2d/2dsb2JhbABEggWqW4EFgXIBAQEDAQEBAQ8BB1QGBQULAgEIEQMBAiEBDQIlCx0IAgQOBQ4Uh1gIln8BnV4EiyxjBI4mgReFRZI0 X-IronPort-AV: E=Sophos;i="4.71,449,1320624000"; d="p7s'?scan'208,217";a="48276699" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 03 Jan 2012 11:23:53 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q03BNrE9021732; Tue, 3 Jan 2012 11:23:53 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.213]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.01.0339.001; Tue, 3 Jan 2012 03:23:53 -0800 From: "Roque Gagliano (rogaglia)" To: Danny McPherson Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-04.txt Thread-Index: AQHMwWLFjG4EG3bWq0+mtC6Ddbyq5ZX7F6cA Date: Tue, 3 Jan 2012 11:23:52 +0000 Message-ID: <61AE0027-3FF1-4FBB-B1F0-E9552004009D@cisco.com> References: <0E9A31B3-0BAF-4942-AAC6-486BCF17394B@tcb.net> <42DEE995-AE41-46EA-A21E-CDFAD31A6401@cisco.com> In-Reply-To: <42DEE995-AE41-46EA-A21E-CDFAD31A6401@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18622.006 x-tm-as-result: No--63.635300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-75--609720550"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: sidr wg list 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: Tue, 03 Jan 2012 11:23:56 -0000 --Apple-Mail-75--609720550 Content-Type: multipart/alternative; boundary=Apple-Mail-74--609724217 --Apple-Mail-74--609724217 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > From: Danny McPherson > Date: December 23, 2011 6:15:54 AM GMT+01:00 > To: > Subject: Re: [sidr] I-D Action: = draft-ietf-sidr-algorithm-agility-04.txt >=20 >=20 > I've reviewed the -04 version of the draft and have the following=20 > comments (most of which persist from the previous version of the=20 > draft, although many were accommodated - thanks). >>=20 >=20 Danny, I want to thank you for your second throughout review. You spot = some new problems with the old and new text. Please see comments inline. Roque >> -danny >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Substantial: >>=20 >> --- >> S 4.4 (&& S 4.6): >>=20 >> I remain concerned that independent publication points for=20 >> product sets for different algorithms are not a mandatory=20 >> requirement. Is there any reason why, for example, this is a=20 >> SHOULD rather than a MUST: >>=20 >> "Suite B product SHOULD be stored at independent publication=20 >> points" >>=20 >> It's precisely the assumptions this introduces in S 4.4 that=20 >> makes me think independent publication points must be a hard=20 >> requirement (i.e., MUST). >=20 (Roque) Having a SHOULD was discuss a while ago when checking pro a cons = of a complete separation from a separation based on the information in = the manifest. The complete separation was preferred but a separation = based on the information in the different manifests while sharing the = same publication points was not ruled out. =20 >=20 >> S 4.6 on same issue: >>=20 >> "Since the Suite B products SHOULD be published at distinct=20 >> publication points, RPs that cannot process Suite B products=20 >> can be expected to revert to the Suite A products that still = exist." >>=20 >> This text to me still assumes interdependence between=20 >> independent publication points, even after you explicitly=20 >> stated that an algorithm that validates under either object=20 >> (which technically, they're independent anyway) should be >> considered valid. It lends itself to the thought that an RP=20 >> should prolly maintain both suites until EOL, which isn't=20 >> necessarily the suggestion, methinks. >=20 (Roque) This new piece of the text is part of a paragraph on how to stop = the transition process at this stage. In the previous paragraph it is = clearly stated that "failure" is defined by local policies. So, at this = stage all product MUST be using both algorithm suites, the RP can decide = to use local policies such as:=20 - validate both repositories and stay with the union of = the validated objects - validate only B and under certain conditions of = number of total valid/invalid objects validate A An RP can decide to continue validating A until EOL. The only policy for = RP that we are requesting is that it MUST be validating Algorithm B at = Twilight and that it MUST stop validating Algorithm C after EOL. >=20 >>=20 >> --- >> S 4.4: >>=20 >> "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." >>=20 >> I know this is in the Phase 1 section, but it may be worth iterating=20= >> here that this is only possible in these early phases of the = transition. >=20 (Roque) The "cancelation" text changes in every phase. I rather not = clarify that this text should be read in the correspondent section.... = :-) >> --- >> S 4.5: >>=20 >> "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." >>=20 (Roque) I guess you are referring here to the SHOULD to be changed for = MUST. See above. >=20 >=20 >> --- >> S 4.6: >>=20 >> "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." >>=20 >> Given that the two algorithm suite product sets are independent and=20= >> 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. >>=20 >=20 (Roque) At this phase the CA MUST use both algorithm suites. The RP have = to chose their local policies. As mentioned before, an RP may decide = that it want to continue validating using the two suites until EOL, but = that is not required. >=20 >=20 >> --- >> S 4.7:=20 >>=20 >> I don't know what this text is aiming to accomplish (i.e., where else >> would they be published)? >>=20 >> "All signed products sets issued using Suite A MUST be published=20 >> at their corresponding publication points, but signed products sets=20= >> issued using Suite C MAY be published at their corresponding=20 >> publication points." >=20 (Roque) s/MAY/MAY NOT So, you MAY create the Suite C products (i.e. provisioning protocol = support) and you MAY publish them. >> --- >> S 4.7: >>=20 >> My previous concerns persist here: >>=20 >> "Also, every RP MUST validate signed product sets using Suite A=20 >> but also MAY validate signed product sets using Suite C. However,=20= >> RPs SHOULD NOT assume the Suite C repository is complete." >>=20 >> If RPs do this and you've got Suite A that validates and Suite C that=20= >> 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=20 >> like this collision probability we're introducing. =20 >>=20 >=20 (Roque) The sentence only says that if you decide to validate a product = set using Suite C and that product validates, it is valid. But you = should not consider that the Suite C repository is complete. I do not = see the collision. >=20 >> --- >> S 6: >>=20 >> Where do we say that both "instances" of such products MUST=20 >> contain the same resources (and what's an "instance")? I don't see=20= >> this requirement earlier in the draft and it seems a REALLY bad=20 >> requirement to be - they MUST be independent: >=20 >=20 (Roque)=20 This text is on the first paragraph: "In this section, we describe the RP behavior when validating instances = of the same signed product but signed with different algorithm suites." We use also the definition of two different files for the same object: "During Phase 1 two (corresponding) files for an object MAY be available = for each signed product, one signed under Algorithm Suite A and one = under Algorithm Suite B." The idea of "same signed product" includes the resources, when relevant = to this object. We kept the text more general as there are a variety of = signed objects. >>=20 >> "Because both instances of such products MUST contain the same=20 >> resources, relying on either instance will yield the same outcome." >>=20 >> For example, this text in the following section itself is in conflict >> with the S 6 requirement: >>=20 >> "As the algorithm migration process mandates the maintenance of=20 >> two parallel certificate hierarchies, revocations requests for each >> algorithm suite MUST be handled independently. A Child CA=20 >> MUST request revocation of a certificate relative to a specific=20 >> algorithm suite." >=20 (Roque) I do not see the conflict. >=20 >>=20 >> --- >> S 7: >>=20 >> I don't understand this revocation requirement, the hierarchies are=20= >> independent and it'd seem perfectly reasonable to revoke something >> in one hierarchy and not in the other: >>=20 >> "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." >=20 (Roque) If the child CA does not do that, your CA stops complying with = the requirement that MUST publish all objects using both algorithm = suites.=20 However, you raised the point that we need to add an exception for key = roll-overs as we are mentioning in the following section that the = processes are independent. >=20 >> --- >> S 11: >>=20 >> This text is also in conflict with earlier requirements of absolute = parity=20 >> across the two independent hierarchies (e.g., CRLs in both, etc..): >>=20 >> "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,=20 >> the RPKI may, at the end of Phase 4, have a smaller number of valid=20= >> signed products than before starting the process." >>=20 >=20 (Roque) That is exactly what we are saying. If a CA does not comply with = the process, there is a risk of ending up with a smaller RPKI. IF the CA = complies with the process, this will not happen. >>=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Nits: >>=20 >> --- >> S 2: >>=20 >> This seems a bit redundant: >>=20 >> "This document does not specify any algorithm suite. This document=20= >> does not specify any algorithm suite per se." >=20 (Roque) ok. >=20 >> --- >> S 3: >>=20 >> Technically, all are changing algorithms suites in this document,=20 >> why are you just indicating this for CA Y? >>=20 >> CA X The CA that issued CA Y's certificate (i.e., CA Y's >> parent), used in examples in this document. >>=20 >> CA Y The CA that is changing keys and/or algorithm suites, >> used in examples this document >>=20 >> CA Z A CA that is a "child" of CA Y, used in examples this >> document >=20 (Roque) ok. >> --- >> S 3: >>=20 >> 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): >=20 (Roque) Can you provide the text? >=20 >>=20 >> 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. >>=20 >> --- >> S 3:=20 >>=20 >> s/conventions use in examples/conventions used in examples/ >=20 (Roque) ok. >=20 >>=20 >> --- >> S 4.1: >>=20 >> s/have re-issued all of its signed/have reissued all of their signed/ >>=20 >> "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." >>=20 >=20 (Roque) ok. >=20 >> --- >> S 4.2: >>=20 >> s/certificate.(X.509/certificate. (X.509/ >=20 (Roque) ok >=20 >>=20 >> s/RPs might be ready/RPs might not be ready/ ? (Roque) ok >>=20 >> "For example, many CAs might not prepared to issue signed >> products under Suite B, or many RPs might be ready to process=20 >> Suite B product sets." >>=20 >> --- >> S 4.4: >>=20 >> s/since Suite B product SHOULD/since Suite B product sets SHOULD/ >>=20 >=20 (Roque) ok. >=20 >> --- >> S 4.5: >>=20 >> s/each signed product sets MUST/each signed product set MUST/ >>=20 >> s/Section 4.2../Section 4.2./ >>=20 >> s/Suite B, SHOULD/Suite B SHOULD/ >>=20 >> s/multiple instance of signed objects/multiple instances of signed = objects/ >=20 (Roque) ok. >=20 >>=20 >> --- >> S 4.7: >>=20 >> "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: >>=20 >> "Suite C (old Suite A)" >>=20 >=20 (Roque) Good catch, one reference is enough.=20 >=20 >> --- >>=20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 --Apple-Mail-74--609724217 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Danny McPherson <danny@tcb.net>
Date: December 23, 2011 = 6:15:54 AM GMT+01:00
Subject: Re: [sidr] I-D = Action: = draft-ietf-sidr-algorithm-agility-04.txt


= 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

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
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).

(Roque) Having a = SHOULD was discuss a while ago when checking pro a cons of a complete = separation from a separation based on the information in the manifest. = The complete separation was preferred but a separation based on the = information in the different manifests while sharing the same = publication points was not ruled out. =  

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.

(Roque) = This new piece of the text is part of a paragraph on how to stop the = transition process at this stage. In the previous paragraph it is = clearly stated that "failure" is defined by local policies. So, at this = stage all product MUST be using both algorithm suites, the RP can decide = to use local policies such as: 
= - validate both repositories and stay with the union of the = validated objects
- validate only B and =  under certain conditions of number of total valid/invalid = objects validate A
An RP can decide to continue = validating A until EOL. The only policy for RP that we are requesting is = that it MUST be validating Algorithm B at Twilight and that it MUST = stop validating Algorithm C after = EOL.


---
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."

(Roque) I guess = you are referring here to the SHOULD to be changed for MUST. See = above.

---
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.



(Roque) At this = phase the CA MUST use both algorithm suites. The RP have to chose their = local policies. As mentioned before, an RP may decide that it want to = continue validating using the two suites until EOL, but that is not = required.

---
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. =  



(Roque) The = sentence only says that if you decide to validate a product set using = Suite C and that product validates, it is valid. But you should not = consider that the Suite C repository is complete. I do not see the = collision.

---
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:



(Roque) 
This text is = on the first paragraph:
"In this section, we describe the RP = behavior when validating instances of the same signed product but signed = with
We use also the definition of two different = files for the same object:
"During Phase 1 = two (corresponding) files for an object MAY be available for = each signed product, one signed under Algorithm Suite A and one under = Algorithm Suite B."

The idea of = "same signed product" includes the resources, when relevant to this = object. We kept the text more general as there are a variety of signed = objects.


"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."


=

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
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."

<= br>
(Roque) = ok.


---
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
=             &n= bsp; parent), used in examples in this document.

=   CA Y        The CA that = is changing keys and/or algorithm suites,
=             &n= bsp; used in examples this document

  CA Z =        A CA that is a "child" of CA = Y, used in examples this
=             &n= bsp; document

<= /div>
---
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
=             &n= bsp; to a subordinate Subject without the involvement of the
=             &n= bsp; Subject.  The public key, resource extensions, and = most
=             &n= bsp; other fields are copied from the current Subject
=             &n= bsp; certificate into the next Subject certificate.  The
=             &n= bsp; Issuer name MAY change, if necessary to reflect the
=             &n= bsp; Subject name in the CA certificate under which the
=             &n= bsp; reissued certificate will be validated.  The validity
=             &n= bsp; interval also MAY be changed.  This action is defined = as
=             &n= bsp; a unilateral certificate re-issuance.

---
S 3: =

s/conventions use in examples/conventions used in = examples/

(Roque) = ok.


---
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
=             &n= bsp; have re-issued all of its signed product set under the
=             &n= bsp; Algorithm B = suite."


(Roque) = ok.

---
S = 4.2:

s/certificate.(X.509/certificate. =  (X.509/

(Roque) = ok


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/


(Roque) = ok.

---
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/

(Roque) = ok.


---
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)"


---



____________________________________= ___________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr


= --Apple-Mail-74--609724217-- --Apple-Mail-75--609720550 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" 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 DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MDMxMTIzNTBaMCMGCSqGSIb3DQEJBDEWBBQ99Rc4YQdCSSbIP06P+kS9+jrmxTCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBg8ZXaYz54S4GlDH38ruAZ9bhtKFb8orOIFWf3chrxYzEA edE0nQc98D3Y85fmTrVX4Or5wr9yFW6QKcRf9mlxkTg6eGfj0RoQFzQhaok1n+VTM0lWgcVgzoqs GE7XAK4H60MwrUjU3z9JCbHFirbEm1jB62RqOnxJPOrzsukSLg86trtrlN80D6cYfVnNI1pRq0NJ tUJPYqYkf+9TK8U8jnNRHoUUZl074kQZqQhFgHIQ5chCyOWurjvYI99Ou2peJQBvR1uL1x5dW8iY vbmlDm9BU9jzZj/VAdbAJD0jeW5NnpI4/D0H8Ox+KABC320TnglrWBBuj3fKxFHi3Yf/AAAAAAAA --Apple-Mail-75--609720550-- From randy@psg.com Sun Jan 8 06:50:01 2012 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 9B95821F854C for ; Sun, 8 Jan 2012 06:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 p4Fqvjx0Xqnb for ; Sun, 8 Jan 2012 06:50:01 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8221F8486 for ; Sun, 8 Jan 2012 06:50:01 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rju4O-000M7F-I1 for sidr@ietf.org; Sun, 08 Jan 2012 14:50:00 +0000 Date: Sun, 08 Jan 2012 09:50:00 -0500 Message-ID: From: Randy Bush To: sidr wg list References: <20120108144831.28045.80870.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 Subject: [sidr] Fwd: New Version Notification for draft-ymbk-rpki-rtr-impl-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: Sun, 08 Jan 2012 14:50:01 -0000 From: internet-drafts@ietf.org To: randy@psg.com Cc: randy@psg.com, keyupate@cisco.com, waehlisch@ieee.org, sra@hactrn.net, hannes@juniper.net Subject: New Version Notification for draft-ymbk-rpki-rtr-impl-01.txt Message-ID: <20120108144831.28045.80870.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2012 06:48:31 -0800 A new version of I-D, draft-ymbk-rpki-rtr-impl-01.txt has been successfully submitted by Randy Bush and posted to the IETF repository. Filename: draft-ymbk-rpki-rtr-impl Revision: 01 Title: RPKI Router Implementation Report Creation date: 2012-01-08 WG ID: Individual Submission Number of pages: 11 Abstract: This document provides an implementation report for RPKI Router protocol as defined in [I-D.ietf-sidr-rpki-rtr]. The editor did not verify the accuracy of the information provided by respondents or by any alternative means. The respondents are experts with the implementations they reported on, and their responses are considered authoritative for the implementations for which their responses represent. Respondents were asked to only use the YES answer if the feature had at least been tested in the lab. The IETF Secretariat From internet-drafts@ietf.org Mon Jan 9 07:11:54 2012 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 6488621F879E; Mon, 9 Jan 2012 07:11: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 M3kU9Ky67uhI; Mon, 9 Jan 2012 07:11:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E1E21F8783; Mon, 9 Jan 2012 07:11:53 -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: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> Date: Mon, 09 Jan 2012 07:11:53 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 09 Jan 2012 15:11: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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-23.txt Pages : 25 Date : 2012-01-09 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-23.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-23.txt From randy@psg.com Mon Jan 9 07:13:52 2012 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 D4FB01F0C3B for ; Mon, 9 Jan 2012 07:13:52 -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.060, 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 YV5t3B9jTZXD for ; Mon, 9 Jan 2012 07:13:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 76BB11F0C36 for ; Mon, 9 Jan 2012 07:13:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RkGv1-000PFD-Id for sidr@ietf.org; Mon, 09 Jan 2012 15:13:51 +0000 Date: Mon, 09 Jan 2012 10:13:51 -0500 Message-ID: From: Randy Bush To: sidr wg list In-Reply-To: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> References: <20120109151153.7946.29762.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 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 09 Jan 2012 15:13:53 -0000 the message does not include a nice bit the authors get Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-23 randy From danny@tcb.net Mon Jan 9 19:33:00 2012 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 39C311F0C3F for ; Mon, 9 Jan 2012 19:33:00 -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 TFD5NYJCOqNe for ; Mon, 9 Jan 2012 19:32:59 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id BF6941F0C3D for ; Mon, 9 Jan 2012 19:32:59 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 00F8F368199; Mon, 9 Jan 2012 20:32:52 -0700 (MST) Received: from new-host-9.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; Mon, 09 Jan 2012 20:32:52 -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=53734; 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: Date: Mon, 9 Jan 2012 22:32:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.1251.1) Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 10 Jan 2012 03:33:00 -0000 If the plan is indeed to employ connection-oriented TCP transport for = rpki-rtr signaling in order to establish prospectively volatile = soft-state in router control planes directly from RPKI-derived blobs -- = i.e., beyond {prefix,origin} bindings to include {ASN, public_key, & = SKI} for each EE certificate in the RPKI, as well as {ASN and associated = IP prefixes} for each ROA in the RPKI then I'm glad these changes were = made and they address my _actionable concerns with this document. =20 Thanks for resolving these specific issues,=20 -danny On Jan 9, 2012, at 10:13 AM, Randy Bush wrote: > the message does not include a nice bit the authors get >=20 > Diff from previous version: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rpki-rtr-23 >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kent@bbn.com Tue Jan 10 17:10:35 2012 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 433E421F8513 for ; Tue, 10 Jan 2012 17:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.092 X-Spam-Level: X-Spam-Status: No, score=-106.092 tagged_above=-999 required=5 tests=[AWL=0.507, 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 B+Dbb8GUVfLO for ; Tue, 10 Jan 2012 17:10:34 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7521F84F8 for ; Tue, 10 Jan 2012 17:10:33 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:35714 helo=[172.20.8.192]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RkmhN-00029w-Oh; Tue, 10 Jan 2012 20:09:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> Date: Tue, 10 Jan 2012 20:09:46 -0500 To: Danny McPherson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 11 Jan 2012 01:10:35 -0000 At 10:32 PM -0500 1/9/12, Danny McPherson wrote: >If the plan is indeed to employ connection-oriented TCP transport >for rpki-rtr signaling in order to establish prospectively volatile >soft-state in router control planes directly from RPKI-derived blobs >-- i.e., beyond {prefix,origin} bindings to include {ASN, >public_key, & SKI} for each EE certificate in the RPKI, as well as >{ASN and associated IP prefixes} for each ROA in the RPKI then I'm >glad these changes were made and they address my _actionable >concerns with this document. > >Thanks for resolving these specific issues, > >-danny I think you have taken the crown from Geoff, emitting the longest sentence on the SIDR list :-). From randy@psg.com Tue Jan 10 18:30:30 2012 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 87BB921F84D0 for ; Tue, 10 Jan 2012 18:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 q-0U6UxJwLoj for ; Tue, 10 Jan 2012 18:30:30 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 21E4E21F84A1 for ; Tue, 10 Jan 2012 18:30:30 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RknxH-0004Sv-Nz; Wed, 11 Jan 2012 02:30:23 +0000 Date: Tue, 10 Jan 2012 18:30:23 -0800 Message-ID: From: Randy Bush To: Stephen Kent In-Reply-To: References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> <6855CE88-68E6-49BE-94D0-EA19ACE07F69@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 list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 11 Jan 2012 02:30:30 -0000 >> If the plan is indeed to employ connection-oriented TCP transport >> for rpki-rtr signaling in order to establish prospectively volatile >> soft-state in router control planes directly from RPKI-derived blobs >> -- i.e., beyond {prefix,origin} bindings to include {ASN, >> public_key, & SKI} for each EE certificate in the RPKI, as well as >> {ASN and associated IP prefixes} for each ROA in the RPKI then I'm >> glad these changes were made and they address my _actionable >> concerns with this document. >> >> Thanks for resolving these specific issues, >> >> -danny > > I think you have taken the crown from Geoff, emitting the longest sentence > on the SIDR list :-). with a little work, i can usually understand geoff's. the above seems to spend all of it's power budget on trying to appear erudite, and the result is quite unintelligible to at least this st00pid geek. but i think danny is happy with the changes. and if danny is happy, i guess i am. randy From danny@tcb.net Tue Jan 10 20:13:21 2012 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 D060211E8083 for ; Tue, 10 Jan 2012 20:13:21 -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 Fbuygu+np3Ry for ; Tue, 10 Jan 2012 20:13:21 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5168D11E8080 for ; Tue, 10 Jan 2012 20:13:21 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id E08CF368199; Tue, 10 Jan 2012 21:13:18 -0700 (MST) Received: from new-host-9.home (pool-98-118-240-226.clppva.fios.verizon.net [98.118.240.226]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Tue, 10 Jan 2012 21:13:18 -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=63352; 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 v1251.1) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: Date: Tue, 10 Jan 2012 23:13:03 -0500 Content-Transfer-Encoding: 7bit Message-Id: <5A64D71D-F778-450A-9BAC-BCC78C93A021@tcb.net> References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> To: Randy Bush X-Mailer: Apple Mail (2.1251.1) Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 11 Jan 2012 04:13:21 -0000 On Jan 10, 2012, at 9:30 PM, Randy Bush wrote: > with a little work, i can usually understand geoff's. the above seems > to spend all of it's power budget on trying to appear erudite, and the > result is quite unintelligible to at least this st00pid geek. Erudite is a fine choice of words here, I was hoping it'd lead to corrections from those more learned. I ask that you please indulge me Randy, I suspect you've already got this all figured out. Let me ask a couple questions, that may help me resolve my confusions with this. Do you foresee rpki-rtr being "augmented" for router on- boarding of additional RPKI-derived data to enable things like those provided in the BGPSEC protocol document, e.g., S.5 of bgpsec-protocol I-D: [snip] 5. Processing a Received BGPSEC Update Validation of a BGPSEC update messages makes use of data from RPKI certificates and signed Route Origination Authorizations (ROA). In particular, to validate update messages containing the BGPSEC_Path_Signatures attribute, it is necessary that the recipient have access to the following data obtained from valid RPKI certificates and ROAs: o For each valid RPKI end-entity certificate containing an AS Number extension, the AS Number, Public Key and Subject Key Identifier are required o For each valid ROA, the AS Number and the list of IP address prefixes [/snip] I labeled these things prospectively [more] volatile than current rpki-rtr "stuff", that may or may not be appropriate. If this is the intention, then have you selected the publication dates for the documents that "augment" this brand new rpki-rtr protocol, I'd like to know when I need to factor those documents as well? A general observation is that while this piecemeal draft progression approach appears well designed to pass IETF publication gates, I'm not sure it's optimal for considering systemic and inter-dependency implications. Alas... > but i think danny is happy with the changes. and if danny is happy, i > guess i am. Excellent... -danny From wwwrun@ietfa.amsl.com Wed Jan 11 12:14:26 2012 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 6824F21F860E; Wed, 11 Jan 2012 12:14:26 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120111201426.6824F21F860E@ietfa.amsl.com> Date: Wed, 11 Jan 2012 12:14:26 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] SIDR Working Group Interim Meeting February 9, 2012, San Diego, CA USA 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, 11 Jan 2012 20:14:26 -0000 This is to announce an interim SIDR face-to-face meeting on Thu Feb 9 following the NANOG54 meeting in San Diego, CA. The interim meeting will focus on two current SIDR topics: replay protection/beaconing and route leaks. Both topics will benefit from extended concentrated focus. Route leaks are not currently in the SIDR charter, and exploring the issues in depth is necessary before considering a future change to the charter. The venue was chosen because many of the WG comments on both topics have been about the operational impact and we might get operators to join in the discussion. The NANOG54 meeting is Mon-Wed Feb 6-8, so we will meet on Thu Feb 9 to provide an opportunity for them to attend. The agenda would be a full day meeting: 0900-1230 Replay protection - beaconing or other solutions 1230-1330 Lunch 1330-1700 Route leaks - firm definition of problem space, requirements, security concern, exposure sensitivity, remote detection, what, when, where, whether, how, who, etc., to solve this. Actual venue is planned to be at or near the NANOG54 venue. Venue and remote participation details will be announced on the SIDR mailing list. From randy@psg.com Thu Jan 12 11:11:46 2012 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 3464321F8577 for ; Thu, 12 Jan 2012 11:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 kkfPp9rLVEaZ for ; Thu, 12 Jan 2012 11:11:45 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB1321F85C6 for ; Thu, 12 Jan 2012 11:11:45 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RlQ3s-0009le-MA; Thu, 12 Jan 2012 19:11:44 +0000 Date: Thu, 12 Jan 2012 11:11:44 -0800 Message-ID: From: Randy Bush To: Danny McPherson In-Reply-To: <5A64D71D-F778-450A-9BAC-BCC78C93A021@tcb.net> References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> <5A64D71D-F778-450A-9BAC-BCC78C93A021@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 list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 12 Jan 2012 19:11:46 -0000 > Do you foresee rpki-rtr being "augmented" for router on- boarding of > additional RPKI-derived data to enable things like those provided in > the BGPSEC protocol document, e.g., S.5 of bgpsec-protocol I-D: i think so, but i am a bit worried as about this waterboarding stuff. > If this is the intention, then have you selected the publication > dates for the documents that "augment" this brand new rpki-rtr > protocol i think the norm is to get some experience with v0 (the protocol version number in the pdus, a la bgp_4_) before going to v1. but, as with most things, i could be wrong. > I'd like to know when I need to factor those documents as well? as i have no idea how to factor a document or how much lead time factoring takes, even if i knew when v1 could be out which i don't, i would not be able to answer. > A general observation is that while this piecemeal draft progression > approach appears well designed to pass IETF publication gates perhaps a focus on engineering, as opposed to mis-guessing and impugning others' motives, would be productive. in the current taxonomy, there are three pieces, the rpki, rpki-based origin validation, and then path validation. rpki-rtr as it stands is part of origin validation, and the docs for origin validation are going through the sausage machine now. path validation is in early to mid design, documents are in high flux or unwritten, and are nowhere near ready to be considered sausage. the semantics of an rpki-rtr pdu needed to support the most recent path validation drafts are obvious. but, as principal author of rpki-rtr, i am already grossly and embarrassingly behind on revisions of at least three other docs (two for origin validation!!), origin-ops, pfx-validate, and bgpsec-reqs. so i have no time to chase document drift in the very drafty path validation specs even if it was appropriate to do so, which imiho it is not. they're drifty enough that an interim is being held just to discuss one tough aspect and see if a very different conceptual area can be understood well enough to be added to the goals. and getting v0 of rpki-rtr through the sausage machine already has consumed a silly amount of wall clock, tyvm. randy From danny@tcb.net Thu Jan 12 17:20:36 2012 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 8280211E8091 for ; Thu, 12 Jan 2012 17:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b5NKwmnSTuP for ; Thu, 12 Jan 2012 17:20:36 -0800 (PST) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAB11E808C for ; Thu, 12 Jan 2012 17:20:35 -0800 (PST) Received: by dog.tcb.net (Postfix, from userid 0) id 37158368199; Thu, 12 Jan 2012 18:20:33 -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, 12 Jan 2012 18:20: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=63498; 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: Date: Thu, 12 Jan 2012 20:20:16 -0500 Content-Transfer-Encoding: 7bit Message-Id: <41DA208B-399F-48A8-8196-49507E86D517@tcb.net> References: <20120109151153.7946.29762.idtracker@ietfa.amsl.com> <6855CE88-68E6-49BE-94D0-EA19ACE07F69@tcb.net> <5A64D71D-F778-450A-9BAC-BCC78C93A021@tcb.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-23.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, 13 Jan 2012 01:20:36 -0000 On Jan 12, 2012, at 2:11 PM, Randy Bush wrote: > > i think so, but i am a bit worried as about this waterboarding stuff. I think simple things like asking that rpki-rtr connection-oriented transport require protections is reasonable in 2012, particularly given that the current specification is unsigned prefix,origin binding data (i.e., otherwise no object or transport protections). > i think the norm is to get some experience with v0 (the protocol version > number in the pdus, a la bgp_4_) before going to v1. but, as with most > things, i could be wrong. This is important. If you just needed origin,prefix bindings in soft-state in the router there are lots of ways you could do that today without a new protocol (to include with BGP itself). If the objective is to use rpki-rtr protocol to onboard actual rpki-rtr data into the router control plane, e.g., to accommodate requirements by BGPSEC, then getting those rpki-derived signed blobs in the router is a much higher frequency function and may well justify some new onboarding protocol. > as i have no idea how to factor a document or how much lead time > factoring takes, even if i knew when v1 could be out which i don't, i > would not be able to answer. Cute... If you were designing rpki-rtr protocol to load rpki data into routers (rtrs) then before standardizing rpki-rtr protocol it would seem to me we should fully consider at least the initial use case that justifies a brand new protocol -- before we 'augment' it with new lego blocks. If not, then I suggest to the WG that we require a proposal from the bgpsec-protocol team for how they intend to accommodate their own requirements to onboard this data before we continue that work. > perhaps a focus on engineering, as opposed to mis-guessing and impugning > others' motives, would be productive. Which portion am I mis-guessing here, can you be specific? Is the BGPSEC design team NOT intending to use rpki-rtr protocol to get RPKI-derived signed blobs on the router in order to enable BGPSEC? Your own presentations in operations fora suggestions your thinking is rather evolved already in this area. Attempting to assemble the legos blocks in sidr land and determine what the implications might be for operations at the end of the day is indeed engineering and architectural in nature, do you disagree? Should we not be considering and questioning the systemic and inter-dependencies these new standards introduce? > in the current taxonomy, there are three pieces, the rpki, rpki-based > origin validation, and then path validation. rpki-rtr as it stands is > part of origin validation, and the docs for origin validation are going > through the sausage machine now. path validation is in early to mid > design, documents are in high flux or unwritten, and are nowhere near > ready to be considered sausage. Perhaps we need to do some architectural work then, and not build blocks that are supposed to be pieced together without some amount of systemic consideration. Let me give you a simple example.. We're saying RPKI needs algorithm agility. If RPKI was fully deployed, and BGPSEC was deployed, and rpki-rtr were used to onboard BGPSEC-required signed blobs as specified in the BGPSEC protocol document, e.g., S.5 of bgpsec-protocol I-D, then during algorithm rollover would the following potentially be required: 1) many more RPKI objects 2) many more RPKI-derived signed blobs the relying parties (routers) potentially need to onboard via rpki-rtr and store in soft-state 3) more BGPSEC signed data in the routing system 4) more churn in all the elements that rely in RPKI data in subsequent periodic updates, "beacon" functions, etc. 5) BGPSEC speakers as relying parties would need to consider algorithm suites from either new or old algorithms when performing validation from independent certificate hierarchies 6) some other stuff, I suspect. I think it's all of the above, but I may very well be wrong and I don't have this all figured out.. I do know that there are systemic implications of many of these things, particularly in concert. I think consideration of these issues, i.e., the systemic implications of a set of assembled lego blocks is within the purview of both the iEtf and this WG. -danny From internet-drafts@ietf.org Thu Jan 12 17:29:54 2012 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 0E04F21F8578; Thu, 12 Jan 2012 17:29:54 -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 oennK6kDW6Zi; Thu, 12 Jan 2012 17:29:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A074D21F854A; Thu, 12 Jan 2012 17:29:53 -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: <20120113012953.14556.93505.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2012 17:29:53 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.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, 13 Jan 2012 01:29: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 : The RPKI/Router Protocol Author(s) : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-24.txt Pages : 25 Date : 2012-01-12 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-24.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-24.txt From randy@psg.com Thu Jan 12 17:33:23 2012 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 9EAFF21F84FE; Thu, 12 Jan 2012 17:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 N2ClC5tLS3ER; Thu, 12 Jan 2012 17:33:23 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AB21F8573; Thu, 12 Jan 2012 17:33:23 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RlW1C-000B12-Hy; Fri, 13 Jan 2012 01:33:22 +0000 Date: Thu, 12 Jan 2012 17:33:22 -0800 Message-ID: From: Randy Bush To: internet-drafts@ietf.org In-Reply-To: <20120113012953.14556.93505.idtracker@ietfa.amsl.com> References: <20120113012953.14556.93505.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@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.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, 13 Jan 2012 01:33:23 -0000 this draft a result of helpful security and routing ad reviews > Title : The RPKI/Router Protocol > Author(s) : Randy Bush > Rob Austein > Filename : draft-ietf-sidr-rpki-rtr-24.txt > Pages : 25 > Date : 2012-01-12 and the tasty bit tools neglects to tell the wg Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24 randy From stbryant@cisco.com Fri Jan 13 01:27:18 2012 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 DEB5921F85AD; Fri, 13 Jan 2012 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.641 X-Spam-Level: X-Spam-Status: No, score=-110.641 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbU04yYXGfyM; Fri, 13 Jan 2012 01:27:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C222F21F851A; Fri, 13 Jan 2012 01:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3894; q=dns/txt; s=iport; t=1326446838; x=1327656438; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=9Q47+TbWj4/vpCVTBKCOCybivfHwd1r1uwrq9YOT/wE=; b=fl/KJ7O1Bmx4JuwvYIPIAe9zC391qE8LgzF+YvWltoNZakw/Ejd3IIPr QwEUQSuzMak4ThRHiXrHV4tjhj9CTM/rp0B3jYm7+YzoNKdZ44SpPYPbp Hfg3CW9hH1vqU6yuHlWf9PJUMrk5p9VOliELateV/88gZbtMGSzyvDfo+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FAIz4D0+Q/khR/2dsb2JhbABCnmSOL4EFgXIBAQEDAQEBAQ8BAgFYCgEFBwQPDQMBAgoWDwkDAgECARUoCAYBDAEFAgEBHodYCJkCAYMyDwGaWIwdBJUOkjw X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; d="scan'208,217";a="126320142" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Jan 2012 09:27:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0D9RBQe025948; Fri, 13 Jan 2012 09:27:14 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q0D9RAiG022309; Fri, 13 Jan 2012 09:27:10 GMT Message-ID: <4F0FF8F2.2080108@cisco.com> Date: Fri, 13 Jan 2012 09:27:14 +0000 From: Stewart Bryant 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, IETF Discussion References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------010405050304030109080003" Cc: draft-ietf-sidr-rpki-rtr@tools.ietf.org, "sidr-chairs@tools.ietf.org" , sec-ads@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: [sidr] draft-ietf-sidr-rpki-rtr-24.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:27:19 -0000 This is a multi-part message in MIME format. --------------010405050304030109080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I believe that version 24 addresses all of the actionable comments that the authors have received and I propose to continue with the publication process by requesting IESG review. Stewart -------- Original Message -------- Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.txt Date: Thu, 12 Jan 2012 17:33:22 -0800 From: Randy Bush To: internet-drafts@ietf.org CC: sidr@ietf.org this draft a result of helpful security and routing ad reviews > Title : The RPKI/Router Protocol > Author(s) : Randy Bush > Rob Austein > Filename : draft-ietf-sidr-rpki-rtr-24.txt > Pages : 25 > Date : 2012-01-12 and the tasty bit tools neglects to tell the wg Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24 randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --------------010405050304030109080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe that version 24 addresses all of the actionable
comments that the authors have received and I propose
to continue with the publication process by requesting IESG
review.

Stewart


-------- Original Message --------
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.txt
Date: Thu, 12 Jan 2012 17:33:22 -0800
From: Randy Bush <randy@psg.com>
To: internet-drafts@ietf.org
CC: sidr@ietf.org 


this draft a result of helpful security and routing ad reviews

> 	Title           : The RPKI/Router Protocol
> 	Author(s)       : Randy Bush
>                         Rob Austein
> 	Filename        : draft-ietf-sidr-rpki-rtr-24.txt
> 	Pages           : 25
> 	Date            : 2012-01-12

and the tasty bit tools neglects to tell the wg

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24

randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
--------------010405050304030109080003-- From eosterweil@verisign.com Tue Jan 17 15:36:55 2012 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 4615E1F0C40 for ; Tue, 17 Jan 2012 15:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eACdeVpAjtNb for ; Tue, 17 Jan 2012 15:36:54 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F21F0C35 for ; Tue, 17 Jan 2012 15:36:53 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTxYGCNkSaZB/ldmyLJz7nOkS5TJheuIl@postini.com; Tue, 17 Jan 2012 15:36:53 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0HNaeoX013293 for ; Tue, 17 Jan 2012 18:36:40 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Jan 2012 18:36:40 -0500 From: Eric Osterweil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jan 2012 18:36:39 -0500 Message-Id: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 17 Jan 2012 23:36:40.0317 (UTC) FILETIME=[DCBA92D0:01CCD570] Subject: [sidr] Key learning procedures in BGPsec? 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, 17 Jan 2012 23:36:55 -0000 Hey everyone, I was walking through the thought exercise of figuring out how BGPsec = might be planning to do its crypto key learning (which I see as a two = pronged problem that I outline below), and I couldn't seem to find any = clear text on this matter in the current drafts. I think I'm up to date = on most of the drafts, but perhaps not? Can someone point me to the the = treatises that clarify: 1 - How are routers in BGPsec going to learn and onboard the crypto = certs (ROAs/AOAs/xOAs?) needed to verify the routing updates that they = receive from peers? These certs are clearly going to need to be = maintained and updated somewhere in each router's extended memory = hierarchy, right? Without these, updates from other ASes can not be = verified... - and - 2 - How do we envision the process of an AS getting its own private key = information installed on all of its routers?* Without _these_, updates = cannot be signed... *Note: I think this is a subtle, but very critical issue. If we = consider (for example) that multinational ASes have routers all over the = world, and that these routers need to be upgraded/replaced/etc = sometimes, and that the ASes' private keys are essentially critical = secrets (which also will change periodically), then how do we envision = addressing the _ongoing_ issue of getting private keys onto routers in = faraway places? For instance, we wouldn't press a private key onto a = CD, give it to a FedEx delivery person, and then let it work its way = through customs in a foreign country that may (or may not) host entities = with a vested interest in acquiring or intercepting such a critical = enabling secret, right? For that matter, what do people think about the = issue that a private key could simply be covertly extracted from an AS' = routers that are deployed in far off lands? Wouldn't this kind of = compromise be a terrifying security threat to most ISPs? afaict, this = threat directly elevates the importance the vulnerability period that = comes between compromise, detection, revocation/reissuing, and the lag = that occurs until other routers throughout the routing system learn of = the changes to certs. fwiw, I don't think we can punt on this and = claim it is anything other than a first order architectural issue, = because of the online nature of BGPsec's signing process. That said, I'm really hoping that I've just missed/misread some text = that addresses these issues. If that's the case, please forgive the = rambling noise, and tia for the pointers... :-} Eric From Sandra.Murphy@sparta.com Tue Jan 17 17:20:25 2012 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 22B311F0C35 for ; Tue, 17 Jan 2012 17:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 N7A-YWFzqast for ; Tue, 17 Jan 2012 17:20:22 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F11F0C4B for ; Tue, 17 Jan 2012 17:20:20 -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 q0I1KJbO006487; Tue, 17 Jan 2012 19:20:19 -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 q0I1KIcZ002821; Tue, 17 Jan 2012 19:20:19 -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.0355.002; Tue, 17 Jan 2012 20:20:06 -0500 From: "Murphy, Sandra" To: Eric Osterweil , "sidr@ietf.org list" Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AQHM1XDuuc3Eip6I+kepCBOaAHZARZYRR5p8 Date: Wed, 18 Jan 2012 01:20:06 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> In-Reply-To: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 01:20:25 -0000 About #1:=0A= =0A= ROAs are used for origin validation. (*) The bgpsec router needs only the = prefix-AS binding in the ROA, not the crypto part, and only for the origin = validation, not the signature attribute validation. The rpki-rtr protocol = is one way to communicate that binding. =0A= =0A= The bgpsec signature attribute validation does need the public keys that ar= e used to validate the signatures. (And the binding to an AS - see previou= s message.) But it is the nature of the public part of a public/private ke= y pair that security concerns are lower for communicating that part of the = pair and exposure is no concern.=0A= =0A= --Sandy=0A= =0A= (*)(Years ago Geoff corrected me about calling ROAs "certs" and I've rememb= ered the lesson. They're just signed objects, not certs.)=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Oster= weil [eosterweil@verisign.com]=0A= Sent: Tuesday, January 17, 2012 6:36 PM=0A= To: sidr@ietf.org list=0A= Subject: [sidr] Key learning procedures in BGPsec?=0A= =0A= Hey everyone,=0A= =0A= I was walking through the thought exercise of figuring out how BGPsec might= be planning to do its crypto key learning (which I see as a two pronged pr= oblem that I outline below), and I couldn't seem to find any clear text on = this matter in the current drafts. I think I'm up to date on most of the d= rafts, but perhaps not? Can someone point me to the the treatises that cla= rify:=0A= 1 - How are routers in BGPsec going to learn and onboard the crypto certs (= ROAs/AOAs/xOAs?) needed to verify the routing updates that they receive fro= m peers? These certs are clearly going to need to be maintained and update= d somewhere in each router's extended memory hierarchy, right? Without the= se, updates from other ASes can not be verified...=0A= - and -=0A= 2 - How do we envision the process of an AS getting its own private key inf= ormation installed on all of its routers?* Without _these_, updates cannot= be signed...=0A= =0A= *Note: I think this is a subtle, but very critical issue. If we consider (= for example) that multinational ASes have routers all over the world, and t= hat these routers need to be upgraded/replaced/etc sometimes, and that the = ASes' private keys are essentially critical secrets (which also will change= periodically), then how do we envision addressing the _ongoing_ issue of g= etting private keys onto routers in faraway places? For instance, we would= n't press a private key onto a CD, give it to a FedEx delivery person, and = then let it work its way through customs in a foreign country that may (or = may not) host entities with a vested interest in acquiring or intercepting = such a critical enabling secret, right? For that matter, what do people th= ink about the issue that a private key could simply be covertly extracted f= rom an AS' routers that are deployed in far off lands? Wouldn't this kind = of compromise be a terrifying security threat to most ISPs? afaict, this t= hreat directly=0A= elevates the importance the vulnerability period that comes between compro= mise, detection, revocation/reissuing, and the lag that occurs until other = routers throughout the routing system learn of the changes to certs. fwiw= , I don't think we can punt on this and claim it is anything other than a f= irst order architectural issue, because of the online nature of BGPsec's si= gning process.=0A= =0A= That said, I'm really hoping that I've just missed/misread some text that a= ddresses these issues. If that's the case, please forgive the rambling noi= se, and tia for the pointers... :-}=0A= =0A= Eric=0A= =0A= =0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From tim@ripe.net Wed Jan 18 01:11:57 2012 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 71CEE21F8773 for ; Wed, 18 Jan 2012 01:11:57 -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 ME2zCrd4V1Ih for ; Wed, 18 Jan 2012 01:11: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 9857821F8762 for ; Wed, 18 Jan 2012 01:11:56 -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 1RnRYe-0001GX-0G; Wed, 18 Jan 2012 10:11:54 +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 1RnRYd-0006VM-Ag; Wed, 18 Jan 2012 10:11:51 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-678359642 From: Tim Bruijnzeels In-Reply-To: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> Date: Wed, 18 Jan 2012 10:11:50 +0100 Message-Id: <1738295B-1B66-432E-9F10-FACC1CDCBCDA@ripe.net> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> To: Eric Osterweil X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a07190c837fbb3da52751707911460d4bdb45 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 09:11:57 -0000 --Apple-Mail-1-678359642 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Jan 18, 2012, at 12:36 AM, Eric Osterweil wrote: > 2 - How do we envision the process of an AS getting its own private = key information installed on all of its routers?* Without _these_, = updates cannot be signed... I don't know for a fact, but I expect that the router key pair is = created on the router itself. The private key never leaves it, but the = public key can be exported so that it can be put on a (EE?) certificate = signed by the holder of the AS. I have to admit though that I am not fully up to speed with all the = bgpsec documents, it's somewhere on my todo list, but my main focus here = has been on publication and validation related matters, not so much bgp = and router.. Tim= --Apple-Mail-1-678359642 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 2 - How do we = envision the process of an AS getting its own private key information = installed on all of its routers?*  Without _these_, updates cannot = be signed...

I don't know = for a fact, but I expect that the router key pair is created on the = router itself. The private key never leaves it, but the public key can = be exported so that it can be put on a (EE?) certificate signed by the = holder of the AS.

I have to admit though that I = am not fully up to speed with all the bgpsec documents, it's somewhere = on my todo list, but my main focus here has been on publication and = validation related matters, not so much bgp and = router..

Tim
= --Apple-Mail-1-678359642-- From kotikalapudi.sriram@nist.gov Wed Jan 18 05:48:59 2012 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 0AE7021F87E0 for ; Wed, 18 Jan 2012 05:48:59 -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 XP1VJggAXL-B for ; Wed, 18 Jan 2012 05:48:58 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 4C50121F86DE for ; Wed, 18 Jan 2012 05:48:57 -0800 (PST) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 18 Jan 2012 08:48:52 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 18 Jan 2012 08:46:45 -0500 From: "Sriram, Kotikalapudi" To: Eric Osterweil , "sidr@ietf.org list" Date: Wed, 18 Jan 2012 08:42:38 -0500 Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AczVcNRPW24BV+twTmSKB+xyWa/SBgAdjcZr Message-ID: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> In-Reply-To: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 13:48:59 -0000 >For that matter, what do people think about the issue that a private key >could simply be covertly extracted from an AS' routers that are deployed >in far off lands? Wouldn't this kind of compromise be a terrifying security >threat to most ISPs? Eric, We (BGPSEC document authors) had considered this problem. It is mitigated by having 'Key per Router' as discussed in: http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-4.5 4.5. Key Per Router (Rouge Router Problem) 4.5.1. Decision Within each AS, each individual BGPSEC router can have a unique pair of private and public keys. 4.5.2. Discussion If a router is compromised, its key pair can be revoked independently, without disrupting the other routers in the AS. Each per-router key-pair will be represented in an end-entity certificate issued under the CA cert of the AS. The Subject Key Identifier (SKI) in the signature points to the router certificate (and thus the unique public key) of the router that affixed its signature, so that a validating router can reliably identify the public key to use for signature verification. Sriram P.S. In case you had not seen the cited document (draft-sriram-bgpsec-design-choices) before, it is a design rationale discussion document and is a companion to draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft submission). From eosterweil@verisign.com Wed Jan 18 07:12:33 2012 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 AF72521F86DE for ; Wed, 18 Jan 2012 07:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.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 woVPvL5Uqi6A for ; Wed, 18 Jan 2012 07:12:33 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6821F86D6 for ; Wed, 18 Jan 2012 07:12:32 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKTxbhUgC3A6yMQN3Brjy2Sw6hXiTi2kRn@postini.com; Wed, 18 Jan 2012 07:12:32 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0IFCGVl011407; Wed, 18 Jan 2012 10:12:16 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 10:12:15 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> Date: Wed, 18 Jan 2012 10:12:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 18 Jan 2012 15:12:15.0500 (UTC) FILETIME=[8FE7BCC0:01CCD5F3] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 15:12:33 -0000 Hey Sandy, On Jan 17, 2012, at 8:20 PM, Murphy, Sandra wrote: > About #1: >=20 > ROAs are used for origin validation. (*) The bgpsec router needs only = the prefix-AS binding in the ROA, not the crypto part, and only for the = origin validation, not the signature attribute validation. The rpki-rtr = protocol is one way to communicate that binding. =20 I think I recall from another recent thread that there was some = contention over whether a router should just take it on faith that the = bindings are legit or if it needs to verify them. Since I don't recall = that thread coming to consensus, rather than recreate that here, I'm = happy to leave this to the other thread if people think that makes = sense. >=20 > The bgpsec signature attribute validation does need the public keys = that are used to validate the signatures. (And the binding to an AS - = see previous message.) But it is the nature of the public part of a = public/private key pair that security concerns are lower for = communicating that part of the pair and exposure is no concern. I think we may not be speaking to the same point. If a router gets a = private key installed on it (presumably one that has been vetted to sign = for an AS/prefix binding), then how do we get that key installed = securely? If the router gets born with a key, how does an AS manage the = lifetime of that key? That is, how do you envision it gets rolled over = to a new key, and how does that key get vetted and installed? Again, I = may just be missing the relevant part of some draft, but I was not able = to find this procedure concisely documented. >=20 > --Sandy >=20 > (*)(Years ago Geoff corrected me about calling ROAs "certs" and I've = remembered the lesson. They're just signed objects, not certs.) Point well taken, thanks. :) Eric= From eosterweil@verisign.com Wed Jan 18 07:14:32 2012 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 55D6521F8766 for ; Wed, 18 Jan 2012 07:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 D5d06sJyIxyV for ; Wed, 18 Jan 2012 07:14:31 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7D51121F8762 for ; Wed, 18 Jan 2012 07:14:31 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKTxbh1QWw+Reku3Tv5pqlvfGaddgXqsgR@postini.com; Wed, 18 Jan 2012 07:14:31 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0IFESne011488; Wed, 18 Jan 2012 10:14:28 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 10:14:28 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: <1738295B-1B66-432E-9F10-FACC1CDCBCDA@ripe.net> Date: Wed, 18 Jan 2012 10:14:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <1738295B-1B66-432E-9F10-FACC1CDCBCDA@ripe.net> To: Tim Bruijnzeels X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 18 Jan 2012 15:14:28.0205 (UTC) FILETIME=[DF00E9D0:01CCD5F3] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 15:14:32 -0000 On Jan 18, 2012, at 4:11 AM, Tim Bruijnzeels wrote: > Hi, >=20 > On Jan 18, 2012, at 12:36 AM, Eric Osterweil wrote: >> 2 - How do we envision the process of an AS getting its own private = key information installed on all of its routers?* Without _these_, = updates cannot be signed... >=20 > I don't know for a fact, but I expect that the router key pair is = created on the router itself. The private key never leaves it, but the = public key can be exported so that it can be put on a (EE?) certificate = signed by the holder of the AS. I think this is one of the things that I was afraid of (though I may = still be in the weeds). If (on one extreme) every router in an AS = creates its own pub/priv key pair, then an AS w/ ~10^3 routers will need = to publish ~10^3 keys, and consuming/verifying routers will need to have = ~10^3 public keys in their extended memory hierarchies to verify any = possible prefix/signature combination. It sounds like we may need = routers to manage key sets on the order of the number of _routers_ in = the global routing system rather than the number of ASes in order to be = able to verify all of crypto sigs that may be encountered on updates... >=20 > I have to admit though that I am not fully up to speed with all the = bgpsec documents, it's somewhere on my todo list, but my main focus here = has been on publication and validation related matters, not so much bgp = and router.. Understood. I have not ruled out the possibility that my confusion = stems from not being current enough with one of the drafts that happens = to address this... Though, I wonder if that is also a point worth = making. Maybe there are just too many drafts, and that needs to be = addressed? ;) Eric= From eosterweil@verisign.com Wed Jan 18 07:26:53 2012 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 BF0D921F86D9 for ; Wed, 18 Jan 2012 07:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 MIvqjx09ImiP for ; Wed, 18 Jan 2012 07:26:53 -0800 (PST) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id DE9DA21F86D6 for ; Wed, 18 Jan 2012 07:26:52 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKTxbkuneIeuwdGVwIszlX8lu2L+qn0XwN@postini.com; Wed, 18 Jan 2012 07:26:52 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0IFQmG2011875; Wed, 18 Jan 2012 10:26:48 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 10:26:47 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Wed, 18 Jan 2012 10:26:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B973EA6-0652-4BD3-9C46-AC9837EA5EB6@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 18 Jan 2012 15:26:47.0480 (UTC) FILETIME=[97A55380:01CCD5F5] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 15:26:53 -0000 Hey Sriram, On Jan 18, 2012, at 8:42 AM, Sriram, Kotikalapudi wrote: >> For that matter, what do people think about the issue that a private = key=20 >> could simply be covertly extracted from an AS' routers that are = deployed=20 >> in far off lands? Wouldn't this kind of compromise be a terrifying = security=20 >> threat to most ISPs? =20 >=20 > Eric, >=20 > We (BGPSEC document authors) had considered this problem. > It is mitigated by having 'Key per Router' as discussed in: > = http://tools.ietf.org/html/draft-sriram-bgpsec-design-choices-01#section-4= .5 >=20 > 4.5. Key Per Router (Rouge Router Problem) >=20 > 4.5.1. Decision >=20 > Within each AS, each individual BGPSEC router can have a unique pair > of private and public keys. >=20 > 4.5.2. Discussion >=20 > If a router is compromised, its key pair can be revoked > independently, without disrupting the other routers in the AS. Each > per-router key-pair will be represented in an end-entity certificate > issued under the CA cert of the AS. The Subject Key Identifier = (SKI) > in the signature points to the router certificate (and thus the > unique public key) of the router that affixed its signature, so that > a validating router can reliably identify the public key to use for > signature verification. Indeed, I knew about this (and even remember a NANOG discussion about it = in Denver, I think). I mentioned one of my concerns surrounding this in = an email, just moments ago:=20 1 - I think this could lead to quite a lot of state that consuming = routers need, in order to verify any possible updates received from an = AS. In the previous email, I gave a more detailed response. - but also - 2 - If there is such a compromise, how is it addressed? In order to get = a new key in there, does someone need to send a whole new router to = replace the old one? Do we envision putting sensitive private key info = on some kind of electronic media and sending it via FedEx, etc? 3 - If new key material is to be shipped in to the same location that = the last one was compromised in (in a new router, on a CD, or whatever) = aren't we just putting the new key signing materials in the same = not-so-secure-environment, and should we give some thought to how easy = it might be to extract this information from a router? >=20 > Sriram >=20 > P.S. In case you had not seen the cited document > (draft-sriram-bgpsec-design-choices) before, > it is a design rationale discussion document and is a companion to > draft-lepinski-bgpsec-protocol-00.txt (our initial individual draft = submission). Yeah, I did see this. I guess I was hoping that there was some kind of = discussion text, intuition, or an explanation of the intricacies that = are inherent to this proposition (re: the comments I made above and in = the last few emails). THanks for the pointer though. I'll re-read this = draft's diffs (as I see it's been updated since Taipei), thanks! :) Eric From kent@bbn.com Wed Jan 18 11:39:15 2012 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 D269621F85F1 for ; Wed, 18 Jan 2012 11:39:15 -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 YFdcs3wOga7K for ; Wed, 18 Jan 2012 11:39:15 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5084421F85EA for ; Wed, 18 Jan 2012 11:39:15 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49309) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnbLd-000E4Y-B0; Wed, 18 Jan 2012 14:39:05 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> Date: Wed, 18 Jan 2012 14:26:23 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 19:39:15 -0000 At 10:12 AM -0500 1/18/12, Eric Osterweil wrote: >Hey Sandy, > >On Jan 17, 2012, at 8:20 PM, Murphy, Sandra wrote: > >> About #1: >> >> ROAs are used for origin validation. (*) The bgpsec router needs >>only the prefix-AS binding in the ROA, not the crypto part, and >>only for the origin validation, not the signature attribute >>validation. The rpki-rtr protocol is one way to communicate that >>binding. > >I think I recall from another recent thread that there was some >contention over whether a router should just take it on faith that >the bindings are legit or if it needs to verify them. Since I don't >recall that thread coming to consensus, rather than recreate that >here, I'm happy to leave this to the other thread if people think >that makes sense. I don't recall that as a point of contention. The model for use of RTR is that the set of routers that subscribe to a server in this protocol all trust the server. If the server is managed by the operator of the AS in which the routers'operate, this is equivalent to the routers trusting the network management node for the AS. > > The bgpsec signature attribute validation does need the public >keys that are used to validate the signatures. (And the binding to >an AS - see previous message.) But it is the nature of the public >part of a public/private key pair that security concerns are lower >for communicating that part of the pair and exposure is no concern. > >I think we may not be speaking to the same point. If a router gets >a private key installed on it (presumably one that has been vetted >to sign for an AS/prefix binding), then how do we get that key >installed securely? If the router gets born with a key, how does an >AS manage the lifetime of that key? That is, how do you envision it >gets rolled over to a new key, and how does that key get vetted and >installed? Again, I may just be missing the relevant part of some >draft, but I was not able to find this procedure concisely >documented. PKIX has defined (CMC and CMP) protocols for cert requests that can be used if the router generates its own key pair. We are in the process of defining a new one that is simpler that than the two cited above. So there are multiple options here. If one chooses to generate a key and insert it into a router, then different protocols would be employed. (CMC is being enhanced to support this mode of operation, see draft-ietf-pkix-cmc-serverkeygeneration. Steve From kent@bbn.com Wed Jan 18 11:43:00 2012 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 6351B11E80AD for ; Wed, 18 Jan 2012 11:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 iVzysVYBPBnz for ; Wed, 18 Jan 2012 11:42:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B64BD11E8073 for ; Wed, 18 Jan 2012 11:42:59 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49310) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RnbPN-000E9j-M5; Wed, 18 Jan 2012 14:42:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> Date: Wed, 18 Jan 2012 14:41:52 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 18 Jan 2012 19:43:00 -0000 At 6:36 PM -0500 1/17/12, Eric Osterweil wrote: >... >2 - How do we envision the process of an AS getting its own private >key information installed on all of its routers?* Without _these_, >updates cannot be signed... BGPSEC allows for a per-AS key pair or a per-router key pair.or anything in between. Thus, if an AS has routers in locations that the AS operator considers physically insecure, it can choose to have those routers be individually keyed, while having a shared key pair for other routers. Yes, this design may require routers to have access to a fairly large number of PUBLIC keys for routers/ASes. Steve From internet-drafts@ietf.org Wed Jan 18 13:09:31 2012 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 C618A11E80B4; Wed, 18 Jan 2012 13:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0yUCFAT4G+5; Wed, 18 Jan 2012 13:09:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C16511E80A6; Wed, 18 Jan 2012 13:09:31 -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: <20120118210931.24709.51494.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2012 13:09:31 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-05.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, 18 Jan 2012 21:09:31 -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 : Algorithm Agility Procedure for RPKI. Author(s) : Roque Gagliano Stephen Kent Sean Turner Filename : draft-ietf-sidr-algorithm-agility-05.txt Pages : 28 Date : 2012-01-18 This document specifies the process that Certification Authorities (CAs) and Relying Parties (RP) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-05.txt From rogaglia@cisco.com Wed Jan 18 13:16:48 2012 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 942A621F850C for ; Wed, 18 Jan 2012 13:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.745, 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 DZc6+9WH7wQz for ; Wed, 18 Jan 2012 13:16:46 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3192821F8501 for ; Wed, 18 Jan 2012 13:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8485; q=dns/txt; s=iport; t=1326921406; x=1328131006; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EgdFGwW2iXeDHtlygkQ+qKs6ESlS7mXsZllpW10leW0=; b=NqIYbx2DN1jhGDsVJxcdMCzBOO9BD7jPoDxouK30D6tNqYJrgiWPAnlp UKO5VCyEaV+YZemfvyQiW5jVwvv11Ok16Hr/jm41QFzHb4951s77brea6 Atp9s9duraaHnGOCkdLMSmaFe5zvwLPr6itNBkEhLPm+7LOos2ALsNIKk s=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL01F0+rRDoJ/2dsb2JhbABErEiBAoEFgXIBAQEDAQEBAQ8BWxsCAQhGAiULJQIEEwkFFIdYCJpAAZ5SiHwCBQQGCAQOCgMBOAEFUxUBAgEBBQMBAQEBAgcQBQ4mDEQQBQuBRRwOFQMVBwsDAQEBAQKCR2MEjjGBGYVKkkg X-IronPort-AV: E=Sophos;i="4.71,531,1320624000"; d="p7s'?scan'208";a="25886286" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 18 Jan 2012 21:16:46 +0000 Received: from xht-rcd-x02-p.cisco.com (xht-rcd-x02-p.cisco.com [173.37.178.213]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0ILGh5S010156 for ; Wed, 18 Jan 2012 21:16:44 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.213]) by xht-rcd-x02-p.cisco.com ([173.37.178.213]) with mapi id 14.02.0247.003; Wed, 18 Jan 2012 13:16:43 -0800 From: "Roque Gagliano (rogaglia)" To: sidr wg list Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-05.txt Thread-Index: AQHM1iZ6MHJaQpYLv0avyEGkq/EATg== Date: Wed, 18 Jan 2012 21:16:43 +0000 Message-ID: <9E1D4306-A091-4B22-A087-48E532CF76FF@cisco.com> References: <20120118210931.24709.51494.idtracker@ietfa.amsl.com> In-Reply-To: <20120118210931.24709.51494.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18654.001 x-tm-as-result: No--44.013700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-115-721850371"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-algorithm-agility-05.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, 18 Jan 2012 21:16:48 -0000 --Apple-Mail-115-721850371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi WG, In this version I incorporated the comments from Danny and some other = editorial nits. The authors believe all comments form WGLC were answered in the mailing = list and addressed in the document when required. Regards, Roque Diff file can be generated using this URL: = http://tools.ietf.org//rfcdiff?url1=3Dhttp://www.ietf.org/id/draft-ietf-si= dr-algorithm-agility-05.txt&url2=3Dhttp://www.ietf.org/id/draft-ietf-sidr-= algorithm-agility-04.txt On Jan 18, 2012, at 10:09 PM, wrote: >=20 > 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. >=20 > Title : Algorithm Agility Procedure for RPKI. > Author(s) : Roque Gagliano > Stephen Kent > Sean Turner > Filename : draft-ietf-sidr-algorithm-agility-05.txt > Pages : 28 > Date : 2012-01-18 >=20 > This document specifies the process that Certification Authorities > (CAs) and Relying Parties (RP) participating in the Resource Public > Key Infrastructure (RPKI) will need to follow to transition to a new > (and probably cryptographically stronger) algorithm set. The = process > is expected to be completed in a time scale of months or years. > Consequently, no emergency transition is specified. The transition > procedure defined in this document supports only a top-down = migration > (parent migrates before children). >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-05.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-algorithm-agility-05.tx= t >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-115-721850371 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" 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 DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MTgyMTE2NDFaMCMGCSqGSIb3DQEJBDEWBBTZgnsOowEcO58GXuvbfpOT+rcTZTCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQAAsaxshcVnH6QGcLYbon5c38Les1H4tEKHbxFMbARjwbC4 6tcv4AhDcXMuCUF12GIFzWFx4Pa+6ah7R6gwjGxeFwfBeYrAOXjUcak0zxN+nsBw1K77r5lzb9Aj ir3jWaLpv3Wi/mbjX+Bvashzj6+I56ksaaZkZvDu4mvVhQW4p/LJsYdElQk3cnEA19wI1qfGVvnK d5XQPmyJkuD3C3xyPjaQX2w89sr3C6bAdXqlaBQqkMop+mC+2s27TnUmlaSZSD/8eXf1Wvxzqtzq 3+EWAnc/ubVUNxTRcDe0SzXuAZI7/yfcD2drWBVSa0ETErLkIFrPOLpS4Rd14/QEs/BZAAAAAAAA --Apple-Mail-115-721850371-- From eosterweil@verisign.com Thu Jan 19 12:08:02 2012 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 4F9D121F8554 for ; Thu, 19 Jan 2012 12:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, 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 dN1ZTWwqIB6J for ; Thu, 19 Jan 2012 12:08:01 -0800 (PST) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 69C2221F854B for ; Thu, 19 Jan 2012 12:08:01 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKTxh4Hd9qwGQhukwGwboDHSek4g3T2JA+@postini.com; Thu, 19 Jan 2012 12:08:01 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0JK7ueq003783; Thu, 19 Jan 2012 15:07:56 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.67]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 15:07:55 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 19 Jan 2012 15:07:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 19 Jan 2012 20:07:55.0955 (UTC) FILETIME=[08741830:01CCD6E6] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 19 Jan 2012 20:08:02 -0000 On Jan 18, 2012, at 2:41 PM, Stephen Kent wrote: > At 6:36 PM -0500 1/17/12, Eric Osterweil wrote: >> ... >> 2 - How do we envision the process of an AS getting its own private = key information installed on all of its routers?* Without _these_, = updates cannot be signed... >=20 > BGPSEC allows for a per-AS key pair or a per-router key pair.or = anything > in between. Thus, if an AS has routers in locations that the AS = operator considers physically insecure, it can choose to have those = routers be individually keyed, while having a shared key pair for other = routers. >=20 > Yes, this design may require routers to have access to a fairly large = number of PUBLIC keys for routers/ASes. Where "fairly large" could approximate a number that is on the order of = the number of all BGPsec routers in the global routing system, right = (~millions)? I would imaging that keeping a coherent cache of these = keys at every ISP would be a major concern, no? That's potentially a = huge challenge when you include churn, revocation, etc, right? Eric= From eosterweil@verisign.com Thu Jan 19 12:08:03 2012 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 3576C21F84FF for ; Thu, 19 Jan 2012 12:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Gb-FnzGMJR4x for ; Thu, 19 Jan 2012 12:08:02 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7E21F854E for ; Thu, 19 Jan 2012 12:08:01 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTxh4HBsVL23PpmxCfRJwZqbdvfe0xMqZ@postini.com; Thu, 19 Jan 2012 12:08:02 PST Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0JK7rES007677; Thu, 19 Jan 2012 15:07:53 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.67]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 15:07:52 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 19 Jan 2012 15:07:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 19 Jan 2012 20:07:52.0721 (UTC) FILETIME=[0686A010:01CCD6E6] Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 19 Jan 2012 20:08:03 -0000 Hey Steve, On Jan 18, 2012, at 2:26 PM, Stephen Kent wrote: > At 10:12 AM -0500 1/18/12, Eric Osterweil wrote: >> Hey Sandy, >>=20 >> On Jan 17, 2012, at 8:20 PM, Murphy, Sandra wrote: >>=20 >>> About #1: >>>=20 >>> ROAs are used for origin validation. (*) The bgpsec router needs = only the prefix-AS binding in the ROA, not the crypto part, and only for = the origin validation, not the signature attribute validation. The = rpki-rtr protocol is one way to communicate that binding.=20 >>=20 >> I think I recall from another recent thread that there was some = contention over whether a router should just take it on faith that the = bindings are legit or if it needs to verify them. Since I don't recall = that thread coming to consensus, rather than recreate that here, I'm = happy to leave this to the other thread if people think that makes = sense. >=20 > I don't recall that as a point of contention. The model for use of RTR = is that > the set of routers that subscribe to a server in this protocol all = trust the > server. If the server is managed by the operator of the AS in which = the routers'operate, this is equivalent to the routers trusting the = network management node for the AS. Like I said, this is not something I (personally) feel the need to = rehash here. If those on the other thread ("[sidr] I-D Action: = draft-ietf-sidr-rpki-rtr-23.txt") were content w/ its resolution, so be = it. But, iirc, there seemed to be some... lingering disagreement, no? >=20 >> > The bgpsec signature attribute validation does need the public keys = that are used to validate the signatures. (And the binding to an AS - = see previous message.) But it is the nature of the public part of a = public/private key pair that security concerns are lower for = communicating that part of the pair and exposure is no concern. >>=20 >> I think we may not be speaking to the same point. If a router gets a = private key installed on it (presumably one that has been vetted to sign = for an AS/prefix binding), then how do we get that key installed = securely? If the router gets born with a key, how does an AS manage the = lifetime of that key? That is, how do you envision it gets rolled over = to a new key, and how does that key get vetted and installed? Again, I = may just be missing the relevant part of some draft, but I was not able = to find this procedure concisely documented. >=20 > PKIX has defined (CMC and CMP) protocols for cert requests that can be = used if the router generates its own key pair. We are in the process of = defining a new one that is simpler that than the two cited above. So = there are multiple options here. If one chooses to generate a key and = insert it into a router, then different protocols would be employed. = (CMC is being enhanced to support this mode of operation, see = draft-ietf-pkix-cmc-serverkeygeneration. I just took a read through that draft, thanks for the pointer! :) OOC, were you all imagining that the CMC authentication for these BGPsec = routers would use a shared secret or a pre-installed certified key o = each remote router? Also, do you happen to know which nation states = require key escrow these days? Thanks! Eric= From kent@bbn.com Thu Jan 19 14:18:37 2012 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 1AA1821F8604 for ; Thu, 19 Jan 2012 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 2M+6c50PT8zV for ; Thu, 19 Jan 2012 14:18:36 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 994FF21F85D5 for ; Thu, 19 Jan 2012 14:18:36 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49333) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ro0JX-000ACr-Jk; Thu, 19 Jan 2012 17:18:35 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> Date: Thu, 19 Jan 2012 17:18:26 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 19 Jan 2012 22:18:37 -0000 At 3:07 PM -0500 1/19/12, Eric Osterweil wrote: >... > >Where "fairly large" could approximate a number that is on the order >of the number of all BGPsec routers in the global routing system, >right (~millions)? I would imaging that keeping a coherent cache of >these keys at every ISP would be a major concern, no? That's >potentially a huge challenge when you include churn, revocation, >etc, right? It's not clear how many different router certs we will see, but I agree that it may be substantial. it will likely be a mix of per-As and per-router certs, spread over all of the participating ASes. Even if there are many fewer certs, inconsistent caches would pose a problem. Unless we're discussing an emergency rekey for a cert, the smart procedure is to post a new cert well before the old one expires, allowing RPs to retrieve the new one in plenty of time. There is not yet an operational guidance doc for router cert management, but I anticipate this sort of guidance will appear there. Steve From kent@bbn.com Thu Jan 19 14:18:37 2012 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 CF1AB21F8604 for ; Thu, 19 Jan 2012 14:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 DgCoK1v2Eb75 for ; Thu, 19 Jan 2012 14:18:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5721F85D5 for ; Thu, 19 Jan 2012 14:18:37 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49333) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Ro0JW-000ACr-NE; Thu, 19 Jan 2012 17:18:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> Date: Thu, 19 Jan 2012 16:45:08 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 19 Jan 2012 22:18:37 -0000 At 3:07 PM -0500 1/19/12, Eric Osterweil wrote: >... > >Like I said, this is not something I (personally) feel the need to >rehash here. If those on the other thread ("[sidr] I-D Action: >draft-ietf-sidr-rpki-rtr-23.txt") were content w/ its resolution, so >be it. But, iirc, there seemed to be some... lingering >disagreement, no? I think there was confusion re this topic, and that the RYR protocol doc could be improved by adding text in the security considerations section to clarify the trust model envisioned by the authors. >... > >I just took a read through that draft, thanks for the pointer! :) you're welcome. >OOC, were you all imagining that the CMC authentication for these >BGPsec routers would use a shared secret or a pre-installed >certified key o each remote router? Also, do you happen to know >which nation states require key escrow these days? This is a local matter, so each ISP can decide what approach they wish to adopt. I personally prefer installing the cert for the CA. When key escrow has been required, it has usually been mandated for keys used for encryption, not for integrity or authentication. Since we're discussing integrity & authentication here, it is not clear that there are any applicable key escrow regulations. Also, the IETF general policy has been to ignore any nation-specific crypto regulations when developing standards. Steve From Sandra.Murphy@sparta.com Thu Jan 19 14:25:35 2012 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 3DBC021F8613 for ; Thu, 19 Jan 2012 14:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzzUKhGz3rwY for ; Thu, 19 Jan 2012 14:25:34 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id A7FD821F85D4 for ; Thu, 19 Jan 2012 14:25:33 -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 q0JMPQYn024779; Thu, 19 Jan 2012 16:25:26 -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 q0JMPOKH029704; Thu, 19 Jan 2012 16:25:25 -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.0355.002; Thu, 19 Jan 2012 17:25:24 -0500 From: "Murphy, Sandra" To: Eric Osterweil , Stephen Kent Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AQHM1XDuuc3Eip6I+kepCBOaAHZARZYS22MAgAGZnQD//7uV+Q== Date: Thu, 19 Jan 2012 22:25:22 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60750C4@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> , <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> In-Reply-To: <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 19 Jan 2012 22:25:35 -0000 About your "all BGPSEC routers in the global routing system" - keep in mind= that the ebgp routers are the ones that need a private key, not all the ro= uters in an AS.=0A= =0A= While we have a lot of info on churn in routing updates, I am not certain h= ow to predict how much church there will be in the keys assigned to routers= .=0A= =0A= To those who operate networks:=0A= can you mention an order of magnitude of the number of e-bgp routers you ha= ve?=0A= can you mention how often you re-key your routers, for whatever secure comm= unication you ordinarily use with the routers? (I presume without proof t= hat operators typically secure the communications to their routers and must= already be doing key management.) =0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Eric Oster= weil [eosterweil@verisign.com]=0A= Sent: Thursday, January 19, 2012 3:07 PM=0A= To: Stephen Kent=0A= Cc: sidr@ietf.org list=0A= Subject: Re: [sidr] Key learning procedures in BGPsec?=0A= =0A= On Jan 18, 2012, at 2:41 PM, Stephen Kent wrote:=0A= =0A= > At 6:36 PM -0500 1/17/12, Eric Osterweil wrote:=0A= >> ...=0A= >> 2 - How do we envision the process of an AS getting its own private key = information installed on all of its routers?* Without _these_, updates can= not be signed...=0A= >=0A= > BGPSEC allows for a per-AS key pair or a per-router key pair.or anything= =0A= > in between. Thus, if an AS has routers in locations that the AS operator = considers physically insecure, it can choose to have those routers be indiv= idually keyed, while having a shared key pair for other routers.=0A= >=0A= > Yes, this design may require routers to have access to a fairly large num= ber of PUBLIC keys for routers/ASes.=0A= =0A= Where "fairly large" could approximate a number that is on the order of the= number of all BGPsec routers in the global routing system, right (~million= s)? I would imaging that keeping a coherent cache of these keys at every I= SP would be a major concern, no? That's potentially a huge challenge when = you include churn, revocation, etc, right?=0A= =0A= Eric=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From eosterweil@verisign.com Thu Jan 19 19:39:11 2012 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 063FE21F8597 for ; Thu, 19 Jan 2012 19:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 vc3qvkqYbDV6 for ; Thu, 19 Jan 2012 19:39:10 -0800 (PST) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6EC21F8594 for ; Thu, 19 Jan 2012 19:39:09 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKTxjhzn0NeKyK82HrxqxkHf1BksqEddmL@postini.com; Thu, 19 Jan 2012 19:39:10 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q0K3cquN019657; Thu, 19 Jan 2012 22:38:52 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.67]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 22:38:52 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 19 Jan 2012 22:38:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Jan 2012 03:38:52.0050 (UTC) FILETIME=[07248F20:01CCD725] Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 20 Jan 2012 03:39:11 -0000 On Jan 19, 2012, at 4:45 PM, Stephen Kent wrote: > At 3:07 PM -0500 1/19/12, Eric Osterweil wrote: >=20 >=20 >> OOC, were you all imagining that the CMC authentication for these = BGPsec routers would use a shared secret or a pre-installed certified = key o each remote router? Also, do you happen to know which nation = states require key escrow these days? >=20 > This is a local matter, so each ISP can decide what approach they wish = to adopt. I personally prefer installing the cert for the CA. Yeah, I see. I agree that it should be a local policy decision, but = then how does this avoid my initial concern about relying on crypto = material that has been dispatched through customs (or some other suspect = medium), where key material could be intercepted and extracted? Also, = is it safe to assume that you would need the CA(s) to restrict access to = just your own routers (so that unknown routers/certs cannot issue KGReqs = that result in KGReses)? >=20 > When key escrow has been required, it has usually been mandated for = keys used for encryption, not for integrity or authentication. Since = we're discussing integrity & authentication here, it is not clear that = there are any applicable key escrow regulations. =20 Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't the = curly braces denote encrypted material? I thought the responses in the = key exchanges where necessarily encrypted in this protocol? Otherwise, = the new private key is sent in the clear. I fully accept the = possibility that I'm confused here, but if the material is encrypted and = needs to be decrypted, would the corresponding keys be subject to escrow = policies? I'm sure someone is about to remind me that this is not a PKIX list, but = I just want to make sure that I understand how we are proposing to use = this protocol. :) > Also, the IETF general policy has been to ignore any nation-specific = crypto regulations when developing standards. I see, I guess I had thought we should be worried about the eventual = operational issues that might arise. I didn't know this was taboo, but = shouldn't we find a way to address these concerns in order to help = ensure the design's operational relevance when it's finished? I'm just = bringing this up in the sprit of making this design more relevant, not = because I think there should be some official linkage to escrow policies = or anything. Eric= From eosterweil@verisign.com Thu Jan 19 19:39:37 2012 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 0605521F85FD for ; Thu, 19 Jan 2012 19:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 aFVjfCiKP4LL for ; Thu, 19 Jan 2012 19:39:36 -0800 (PST) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id C6A7D21F85BE for ; Thu, 19 Jan 2012 19:39:35 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTxjh9eDPW4daxSJQSbVb70m8IQjB/y9a@postini.com; Thu, 19 Jan 2012 19:39:35 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0K3dWUr014736; Thu, 19 Jan 2012 22:39:32 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.1.67]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jan 2012 22:39:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Thu, 19 Jan 2012 22:39:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8A9451E4-35C1-456B-960C-7FD150C0CF4C@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 20 Jan 2012 03:39:32.0677 (UTC) FILETIME=[1F5BBF50:01CCD725] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 20 Jan 2012 03:39:37 -0000 On Jan 19, 2012, at 5:18 PM, Stephen Kent wrote: > At 3:07 PM -0500 1/19/12, Eric Osterweil wrote: >> ... >>=20 >> Where "fairly large" could approximate a number that is on the order = of the number of all BGPsec routers in the global routing system, right = (~millions)? I would imaging that keeping a coherent cache of these = keys at every ISP would be a major concern, no? That's potentially a = huge challenge when you include churn, revocation, etc, right? >=20 > It's not clear how many different router certs we will see, but I = agree that it may be substantial. it will likely be a mix of per-As and = per-router certs, spread over all of the participating ASes. >=20 > Even if there are many fewer certs, inconsistent caches would pose a = problem. Unless we're discussing an emergency rekey for a cert, the = smart procedure is to post a new cert well before the old one expires, = allowing RPs to retrieve the new one in plenty of time. Yeah, I agree with your comment about getting keys out ahead of time. = However, with a corpus of keys that could well order in the millions, I = would worry that the inherent churn and resource requirements are going = to be well more than we are (or at least I was) expecting. > There is not yet an operational guidance doc for router cert = management, but > I anticipate this sort of guidance will appear there. Will it include some discussion about scaling? I think this = key-per-router idea could turn out to be Pandora's box. While having a = key or two per AS or per prefix may allow us to use elements of today's = routing system to give us some idea about how churn and dynamics _may_ = look, I'm kind of worried now that we haven't properly evaluated how = enormous the resource dependencies will be with per-router-keys. Are = there any specific plans to write this up anywhere? Eric= From Sandra.Murphy@sparta.com Fri Jan 20 16:02:32 2012 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 71B9621F8659 for ; Fri, 20 Jan 2012 16:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.219 X-Spam-Level: X-Spam-Status: No, score=-101.219 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_40=-0.185, 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 hvFL2p7e3JbL for ; Fri, 20 Jan 2012 16:02:31 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6521F8644 for ; Fri, 20 Jan 2012 16:02:16 -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 q0L02EhS001706 for ; Fri, 20 Jan 2012 18:02:15 -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 q0L02EKZ025906 for ; Fri, 20 Jan 2012 18:02:14 -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.0355.002; Fri, 20 Jan 2012 19:02:14 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: discusson on nanog of RPKI uses Thread-Index: AQHM140+A39DDfU0hk26VRLslPbWag== Date: Sat, 21 Jan 2012 00:02:12 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60753B6@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] discusson on nanog of RPKI uses 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, 21 Jan 2012 00:02:32 -0000 There's a discussion thread on the nanog mailing list that started out as "= Argus: a hijacking alarm system" and moved to "Why not to use RPKI (Was Re:= Argus: a hijacking alarm system)" (*)=0A= =0A= Some of the messages pointed to tools that are using the RPKI material that= exists now.=0A= =0A= You might want to take a look at:=0A= =0A= http://mailman.nanog.org/pipermail/nanog/2012-January/044127.html=0A= =0A= http://mailman.nanog.org/pipermail/nanog/2012-January/044138.html=0A= =0A= =0A= I think this is good news about the work this working group has accomplish= ed, so kudos to everyone.=0A= =0A= --Sandy=0A= =0A= (*)Note: the person who moved the thread to "Why not to use RPKI" was advoc= ating FOR uses of the RPKI. The subject wording is a bit ambiguous.=0A= =0A= From Sandra.Murphy@sparta.com Fri Jan 20 16:19:24 2012 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 AB7AB21F86EB for ; Fri, 20 Jan 2012 16:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 YmvL4H75ss+L for ; Fri, 20 Jan 2012 16:19:24 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF6921F8587 for ; Fri, 20 Jan 2012 16:19:24 -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 q0L0JNcP001753 for ; Fri, 20 Jan 2012 18:19:23 -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 q0L0JNUj026178 for ; Fri, 20 Jan 2012 18:19:23 -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.0355.002; Fri, 20 Jan 2012 19:19:17 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt Thread-Index: AczX0k8MBLEob/ovShO+j20oxVDgwA== Date: Sat, 21 Jan 2012 00:19:15 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Sat, 21 Jan 2012 00:19:24 -0000 The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.t= xt as a working group draft.=0A= =0A= The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-im= pl.=0A= =0A= Please respond to the list to say whether you accept this draft as a workin= g group draft and are willing to work on it. Remember that you do not need = to accept all content in a draft to adopt, as draft editors are required to= reflect the consensus of the working group.=0A= =0A= This call will end 3 Feb 2012.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= =0A= =0A= From warren@kumari.net Sun Jan 22 14:26:20 2012 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 5925921F858A for ; Sun, 22 Jan 2012 14:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.607 X-Spam-Level: X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_20=-0.74, 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 bWMuQVKN9Wv6 for ; Sun, 22 Jan 2012 14:26:19 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D921221F8589 for ; Sun, 22 Jan 2012 14:26:19 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B23CC1B40680; Sun, 22 Jan 2012 17:26:17 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Date: Sun, 22 Jan 2012 17:26:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Sun, 22 Jan 2012 22:26:20 -0000 On Jan 20, 2012, at 7:19 PM, Murphy, Sandra wrote: > The working group has been requested to adopt = draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. >=20 > Please respond to the list to say whether you accept this draft as a = working group draft and are willing to work on it. Remember that you do = not need to accept all content in a draft to adopt, as draft editors are = required to reflect the consensus of the working group. Support adoption. I think that this is a *really* useful document as it provides evidence = of the "running code" bit of rough consensus and running code. Knowing what / how far along the various implementations are is useful = as it provides insight into what parts of the protocols / documentation = are well developed and which need more work. Also, the fact that the = vendors are supporting it this much means this will actually be = deployable, and so (to my mind) makes all the time and effort = worthwhile=85 Comments: It is unclear (to me) what exactly was mean by "YES" vs "UNIT TEST" vs = "SYS TEST" -- I could make some guesses, but a definition would be nice. W >=20 > This call will end 3 Feb 2012. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From tim@ripe.net Mon Jan 23 01:46:49 2012 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 AC18421F84FF for ; Mon, 23 Jan 2012 01:46:49 -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 ABjLarqhAFuW for ; Mon, 23 Jan 2012 01:46:49 -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 DB36D21F84F4 for ; Mon, 23 Jan 2012 01:46:48 -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 1RpGU8-0003Yf-8D; Mon, 23 Jan 2012 10:46:45 +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 1RpGU7-0008KL-Tc; Mon, 23 Jan 2012 10:46:43 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--1035031135 From: Tim Bruijnzeels In-Reply-To: <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.net> Date: Mon, 23 Jan 2012 10:46:43 +0100 Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.net> To: Warren Kumari X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719a3890b185eb89efea1acb1b9afe113fa Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 09:46:49 -0000 --Apple-Mail-1--1035031135 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Jan 22, 2012, at 11:26 PM, Warren Kumari wrote: > Comments: > It is unclear (to me) what exactly was mean by "YES" vs "UNIT TEST" vs = "SYS TEST" -- I could make some guesses, but a definition would be nice. Speaking for my contribution; the one that mentions "Unit Test": Our 'production' implementation is just the validator, so the cache that = is the server side of the protocol. It is tested using automated unit = and functional testing as well as interop-testing with different client = implementations. We also have test client code that we use for the unit tests. This = client is able to parse and understand PDUs in the table in section 3, = but it's not released as a real production stand-alone, interop-tested, = client. Hence I say "Unit Test". I can live with "Not Applicable" or N/A = instead though. I thought it might be useful to mention "unit test", because fwiw we = don't see problems in the PDU format for these 'client' PDUs. Tim= --Apple-Mail-1--1035031135 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Speaking for my = contribution; the one that mentions "Unit = Test":

Our 'production' implementation is just = the validator, so the cache that is the server side of the protocol. It = is tested using automated unit and functional testing as well as = interop-testing with different client = implementations.

We also have test client code = that we use for the unit tests. This client is able to parse and = understand PDUs in the table in section 3, but it's not released as a = real production stand-alone, interop-tested, client. Hence I say "Unit = Test". I can live with "Not Applicable" or N/A instead = though.

I thought it might be useful to mention = "unit test", because fwiw we don't see problems in the PDU format for = these 'client' = PDUs.

Tim
= --Apple-Mail-1--1035031135-- From achi@bbn.com Mon Jan 23 07:17:31 2012 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 95EC521F8709 for ; Mon, 23 Jan 2012 07:17:31 -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 cZabsOP6A8Pe for ; Mon, 23 Jan 2012 07:17:31 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 116B221F8700 for ; Mon, 23 Jan 2012 07:17:31 -0800 (PST) Received: from [128.89.253.126] (port=56102 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpLeE-000NRu-2U; Mon, 23 Jan 2012 10:17:30 -0500 Message-ID: <4F1D7A08.1000209@bbn.com> Date: Mon, 23 Jan 2012 10:17:28 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 15:17:31 -0000 I support adoption. -Andrew From achi@bbn.com Mon Jan 23 07:22:54 2012 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 B422521F8714 for ; Mon, 23 Jan 2012 07:22:54 -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 eDBSnOhEolEa for ; Mon, 23 Jan 2012 07:22:54 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3D05721F86CA for ; Mon, 23 Jan 2012 07:22:54 -0800 (PST) Received: from [128.89.253.126] (port=56301 helo=[127.0.0.1]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpLjN-000NWx-CZ; Mon, 23 Jan 2012 10:22:49 -0500 Message-ID: <4F1D7B44.5060209@bbn.com> Date: Mon, 23 Jan 2012 10:22:44 -0500 From: Andrew Chi User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tim Bruijnzeels References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 15:22:54 -0000 On 1/23/2012 4:46 AM, Tim Bruijnzeels wrote: > We also have test client code that we use for the unit tests. This > client is able to parse and understand PDUs in the table in section 3, > but it's not released as a real production stand-alone, interop-tested, > client. Hence I say "Unit Test". I can live with "Not Applicable" or N/A > instead though. Our "SYS TEST" is equivalent to Tim's "UNIT TEST", so we can just adopt the same terminology (or N/A). -Andrew From randy@psg.com Mon Jan 23 07:23:16 2012 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 F023321F871E for ; Mon, 23 Jan 2012 07:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 Q-BCFTvlvcLn for ; Mon, 23 Jan 2012 07:23:16 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9482821F86CA for ; Mon, 23 Jan 2012 07:23:16 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RpLjn-000KdQ-B7; Mon, 23 Jan 2012 15:23:15 +0000 Date: Tue, 24 Jan 2012 00:23:14 +0900 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> <041CAC39-1FAE-465F-847B-C8E171CF14EE@kumari.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 list Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 15:23:17 -0000 > Support adoption. thank you > Comments: > It is unclear (to me) what exactly was mean by "YES" vs "UNIT TEST" vs > "SYS TEST" -- I could make some guesses, but a definition would be > nice. while i share your puzzlement (and i am an author!:-), shouldn't this be deferred until we have agreed it is a wg document? [ not meaning to pick on you warren. but i have been shocked at some wgs (e.g. v6ops) months of nit picking of a document which the wg has not even agreed to accept as a work item. ] randy From kent@bbn.com Mon Jan 23 07:33:58 2012 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 DC7D121F86B6 for ; Mon, 23 Jan 2012 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 7CtWaPSUv05m for ; Mon, 23 Jan 2012 07:33:58 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6932821F8683 for ; Mon, 23 Jan 2012 07:33:58 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:34361 helo=[192.168.1.9]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpLu9-000Njw-TW; Mon, 23 Jan 2012 10:33:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Date: Mon, 23 Jan 2012 10:33:48 -0500 To: "Murphy, Sandra" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 15:33:59 -0000 At 12:19 AM +0000 1/21/12, Murphy, Sandra wrote: >The working group has been requested to adopt >draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. > >The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. > >Please respond to the list to say whether you accept this draft as a >working group draft and are willing to work on it. Remember that you >do not need to accept all content in a draft to adopt, as draft >editors are required to reflect the consensus of the working group. > >This call will end 3 Feb 2012. > >--Sandy, speaking as wg co-chair I support adoption of this doc as a WG draft, and am prepared to review it, if it adopted. Steve From tim@ripe.net Mon Jan 23 08:05:11 2012 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 CD13021F87B6 for ; Mon, 23 Jan 2012 08:05:11 -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 wM92uAhvzAIs for ; Mon, 23 Jan 2012 08:05:10 -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 5BB4321F87B1 for ; Mon, 23 Jan 2012 08:05:10 -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 1RpMOI-0002En-Ua; Mon, 23 Jan 2012 17:05:09 +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 1RpMOI-0008Rm-Ek; Mon, 23 Jan 2012 17:05:06 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--1012328271 From: Tim Bruijnzeels In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Date: Mon, 23 Jan 2012 17:05:06 +0100 Message-Id: <9240D84D-3277-4F6A-8789-70EA5F3BB3A5@ripe.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d4a55d5d88744684b3a3d1baeb19c590 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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, 23 Jan 2012 16:05:12 -0000 --Apple-Mail-3--1012328271 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 21, 2012, at 1:19 AM, Murphy, Sandra wrote: > The working group has been requested to adopt = draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. I contributed to the document, so my support is kind of implied I would = expect. I am not sure about the rules, I am not an author... In any case: if it needs to be explicit: I support. Tim= --Apple-Mail-3--1012328271 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The working = group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a = working group draft.

I = contributed to the document, so my support is kind of implied I would = expect. I am not sure about the rules, I am not an = author...

In = any case: if it needs to be explicit: I = support.

Tim= --Apple-Mail-3--1012328271-- From kent@bbn.com Mon Jan 23 16:06:14 2012 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 AD29B21F86BB for ; Mon, 23 Jan 2012 16:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.438 X-Spam-Level: X-Spam-Status: No, score=-105.438 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_05=-1.11, DATE_IN_PAST_03_06=0.044, 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 nS-LtJr4A2wO for ; Mon, 23 Jan 2012 16:06:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 095D821F86AA for ; Mon, 23 Jan 2012 16:06:14 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46528 helo=[172.20.8.192]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpTts-000Fvc-HR; Mon, 23 Jan 2012 19:06:12 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> Date: Mon, 23 Jan 2012 15:28:37 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 24 Jan 2012 00:06:14 -0000 At 10:38 PM -0500 1/19/12, Eric Osterweil wrote: > > > This is a local matter, so each ISP can decide what approach they >wish to adopt. I personally prefer installing the cert for the CA. > >Yeah, I see. I agree that it should be a local policy decision, but >then how does this avoid my initial concern about relying on crypto >material that has been dispatched through customs (or some other >suspect medium), where key material could be intercepted and >extracted? The focus of BGPSEC is improving inter-AS routing security. The operator of any AS may not do a great job of securing the keys associated with some or all of its routers. Other ASes will not, in general, be able to evaluate the operational security of an AS. BGPSEC tries to limit the extent to which an AS can lie about routes that it propagates. Local (within an AS) security errors or poor practices do not undermine this security feature. >Also, is it safe to assume that you would need the CA(s) to restrict >access to just your own routers (so that unknown routers/certs >cannot issue KGReqs that result in KGReses)? A CA issuing certs to routers in an AS must have a way to verify that a cert request is form a legitimate source. There are various ways this can be done and, ultimately, this too is a local matter. > > When key escrow has been required, it has usually been mandated >for keys used for encryption, not for integrity or authentication. >Since we're discussing integrity & authentication here, it is not >clear that there are any applicable key escrow regulations. > >Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't >the curly braces denote encrypted material? I thought the responses >in the key exchanges where necessarily encrypted in this protocol? >Otherwise, the new private key is sent in the clear. I fully accept >the possibility that I'm confused here, but if the material is >encrypted and needs to be decrypted, would the corresponding keys be >subject to escrow policies? Typically no, because the use of the key being issued is for signing. > > Also, the IETF general policy has been to ignore any >nation-specific crypto regulations when developing standards. > >I see, I guess I had thought we should be worried about the eventual >operational issues that might arise. I didn't know this was taboo, >but shouldn't we find a way to address these concerns in order to >help ensure the design's operational relevance when it's finished? >I'm just bringing this up in the sprit of making this design more >relevant, not because I think there should be some official linkage >to escrow policies or anything. In general it is appropriate to worry about operational issues. But, I'd suggest that key escrow is not within scope, based on previous IETF experience in related areas. Steve From kent@bbn.com Mon Jan 23 16:06:15 2012 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 2AFD821F86AA for ; Mon, 23 Jan 2012 16:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.145 X-Spam-Level: X-Spam-Status: No, score=-106.145 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 kiZkzjfWfjzK for ; Mon, 23 Jan 2012 16:06:14 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8936B21F86AF for ; Mon, 23 Jan 2012 16:06:14 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:46528 helo=[172.20.8.192]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RpTtt-000Fvc-SI; Mon, 23 Jan 2012 19:06:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <8A9451E4-35C1-456B-960C-7FD150C0CF4C@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> <8A9451E4-35C1-456B-960C-7FD150C0CF4C@verisign.com> Date: Mon, 23 Jan 2012 15:31:03 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 24 Jan 2012 00:06:15 -0000 At 10:39 PM -0500 1/19/12, Eric Osterweil wrote: >... > > >> Even if there are many fewer certs, inconsistent caches would pose >>a problem. Unless we're discussing an emergency rekey for a cert, >>the smart procedure is to post a new cert well before the old one >>expires, allowing RPs to retrieve the new one in plenty of time. > >Yeah, I agree with your comment about getting keys out ahead of >time. However, with a corpus of keys that could well order in the >millions, I would worry that the inherent churn and resource >requirements are going to be well more than we are (or at least I >was) expecting. speak for yourself :-). > > There is not yet an operational guidance doc for router cert >management, but >> I anticipate this sort of guidance will appear there. > >Will it include some discussion about scaling? I think this >key-per-router idea could turn out to be Pandora's box. While >having a key or two per AS or per prefix may allow us to use >elements of today's routing system to give us some idea about how >churn and dynamics _may_ look, I'm kind of worried now that we >haven't properly evaluated how enormous the resource dependencies >will be with per-router-keys. Are there any specific plans to write >this up anywhere? I anticipate that an operational considerations doc will be written. Steve From bvenkata@cisco.com Mon Jan 23 20:30:25 2012 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 25BDB21F8667 for ; Mon, 23 Jan 2012 20:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.043 X-Spam-Level: X-Spam-Status: No, score=-7.043 tagged_above=-999 required=5 tests=[AWL=-0.444, 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 kylCrxUJBZi5 for ; Mon, 23 Jan 2012 20:30:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9993F21F85F3 for ; Mon, 23 Jan 2012 20:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bvenkata@cisco.com; l=1005; q=dns/txt; s=iport; t=1327379424; x=1328589024; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=UoAqrG73VWkpxHP56aDDdRBVPQZY45pgQy8aSSoJLHw=; b=GagjdfdiQ+ClwcoumfXgOhHQMIS17xejGggnGw+60r94mntut7GgZGsS c2U+iKgzjmspH/uk4JxBgPKCPc4Kk3/eCsspwveOKyhfVxiB4m8gaasMk VPtqaSyYO1xYky4b1dsLdiZWZ6729G7sDaOsW9F1ZCDchlEDpvnfJIV62 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN8yHk+tJXG+/2dsb2JhbABCrimBBYFyAQEBBAEBAQ8BChMKNBsCAQgRAwECCwYYBgEmKAgBAQQTCBqHYpoaAZ44iQqCOWMEiDufSQ X-IronPort-AV: E=Sophos;i="4.71,560,1320624000"; d="scan'208";a="53327447" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 24 Jan 2012 04:30:24 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0O4UOWi000394 for ; Tue, 24 Jan 2012 04:30:24 GMT Received: from xmb-rcd-314.cisco.com ([72.163.63.29]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jan 2012 22:30:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jan 2012 22:30:22 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt Thread-Index: AczX0k8MBLEob/ovShO+j20oxVDgwACZcg0wAAYl48A= References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> From: "Balaji Pitta Venkatachalapathy (bvenkata)" To: X-OriginalArrivalTime: 24 Jan 2012 04:30:23.0935 (UTC) FILETIME=[E3B3C4F0:01CCDA50] Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Tue, 24 Jan 2012 04:30:25 -0000 Support adoption of this doc as work group draft. Regards, Balaji ------ Forwarded Message From: "Murphy, Sandra" Date: Sat, 21 Jan 2012 00:19:15 +0000 To: "sidr@ietf.org" Subject: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. This call will end 3 Feb 2012. --Sandy, speaking as wg co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr ------ End of Forwarded Message From bhavani@cisco.com Mon Jan 23 23:56:08 2012 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 D89A711E8075 for ; Mon, 23 Jan 2012 23:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k4y7Vq7gkwb for ; Mon, 23 Jan 2012 23:56:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4397311E8074 for ; Mon, 23 Jan 2012 23:56:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bhavani@cisco.com; l=2565; q=dns/txt; s=iport; t=1327391768; x=1328601368; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=YRBqFtREfr2xf7li3Wx2cqQZAbMgdMEGTet+fVCBudk=; b=kUR+JPv8z5n3DtuVIhtyXzNJqzodLBDi+a6kFFocQFdjJgTrq7s4yzFs j0A2sFxASSgoegc18dCG2fnA2DNeseV7qZnMb6hev/wvW84AiLI2SV2Bg 09+eLqfJtsHeduBfvw0IZTRdBxxkT5voko1MBOX3Sgnbtz4IQNdSBLj8j k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHBjHk+rRDoJ/2dsb2JhbABDriyBBYFyAQEBBAEBAQ8BClEKEQsEARMJFg8JAwIBAgEVMBMGAgEBHodimhYBnjGJCoMcBIg7jF2FVo0Y X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="scan'208,217";a="26663322" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 24 Jan 2012 07:56:08 +0000 Received: from [10.21.166.144] ([10.21.166.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0O7u5AK021665 for ; Tue, 24 Jan 2012 07:56:07 GMT Message-ID: <4F1E6415.2090101@cisco.com> Date: Mon, 23 Jan 2012 23:56:05 -0800 From: Bhavani Parise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Content-Type: multipart/alternative; boundary="------------090300020409030904020405" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Tue, 24 Jan 2012 07:56:09 -0000 This is a multi-part message in MIME format. --------------090300020409030904020405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit support adoption. regards, Bhavani On 1/20/2012 4:19 PM, Murphy, Sandra wrote: > The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. > > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. > > Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. > > This call will end 3 Feb 2012. > > --Sandy, speaking as wg co-chair > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --------------090300020409030904020405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
support adoption.

regards,
Bhavani

On 1/20/2012 4:19 PM, Murphy, Sandra wrote: 
The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft.

The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl.

Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group.

This call will end 3 Feb 2012.

--Sandy, speaking as wg co-chair




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

--------------090300020409030904020405-- From bertietf@bwijnen.net Tue Jan 24 00:13:17 2012 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 4E96121F850D for ; Tue, 24 Jan 2012 00:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 1K44EwLB-cxF for ; Tue, 24 Jan 2012 00:13:16 -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 350F321F84DA for ; Tue, 24 Jan 2012 00:13:14 -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 1RpbVA-00007m-2r; Tue, 24 Jan 2012 09:13:13 +0100 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1RpbV9-0006zM-TR; Tue, 24 Jan 2012 09:13:12 +0100 Message-ID: <4F1E6817.2010005@bwijnen.net> Date: Tue, 24 Jan 2012 09:13:11 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c05d583338098fd3cedc731207439ef6 Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Tue, 24 Jan 2012 08:13:17 -0000 Support adoption as WG doc. Bert On 1/21/12 1:19 AM, Murphy, Sandra wrote: > The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. > > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. > > Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. > > This call will end 3 Feb 2012. > > --Sandy, speaking as wg co-chair > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rogaglia@cisco.com Tue Jan 24 00:33:38 2012 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 C670021F8587 for ; Tue, 24 Jan 2012 00:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.226 X-Spam-Level: X-Spam-Status: No, score=-8.226 tagged_above=-999 required=5 tests=[AWL=2.373, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 oN47lxmKYkKF for ; Tue, 24 Jan 2012 00:33:38 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C121F8554 for ; Tue, 24 Jan 2012 00:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=7201; q=dns/txt; s=iport; t=1327394018; x=1328603618; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=dTzodfvFdCVeoa4T1udWDPUosHq6/5RZZQDXzkjPar4=; b=GL6O+qj+2weyLkkEPp8VbDrSbHCQ5YOQmCemNXQ2FNjoDhVGq9GlAAaF w8oxbPQGCOAsDXHIXIvOhNuFXpw8/kB+2sKgzC3La0MfEk3w8fnZtT/g1 xK2kfLq/ytCLDE96mxoiYQsBEjp5M/TvrLp36yP/kd8tyMVSICJav1nSv 8=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADBsHk+tJXG9/2dsb2JhbABDriyBBYFyAQEBAwEBAQEPAQpREAsCAQhGAiULJQIEEw4Uh1oImhwBni2LQ2MEjjWBGYVKkk0 X-IronPort-AV: E=Sophos;i="4.71,561,1320624000"; d="p7s'?scan'208";a="53361597" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jan 2012 08:33:37 +0000 Received: from xht-rcd-x01-p.cisco.com (xht-rcd-x01-p.cisco.com [173.37.178.212]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0O8XbNi021454 for ; Tue, 24 Jan 2012 08:33:37 GMT Received: from xmb-rcd-x01-p.cisco.com ([169.254.3.213]) by xht-rcd-x01-p.cisco.com ([173.37.178.212]) with mapi id 14.02.0247.003; Tue, 24 Jan 2012 00:33:37 -0800 From: "Roque Gagliano (rogaglia)" To: "sidr@ietf.org" Thread-Topic: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt Thread-Index: AQHM2nLdZ7z/zh8rHkea3mmniKv/fw== Date: Tue, 24 Jan 2012 08:33:37 +0000 Message-ID: <9E1C06CB-81DE-47A1-BC72-BA95D7D9E2BE@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.37.178.200] x-tm-as-product-ver: SMEX-10.0.0.4211-6.800.1017-18664.001 x-tm-as-result: No--41.706900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-1021--953018609"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Tue, 24 Jan 2012 08:33:38 -0000 --Apple-Mail-1021--953018609 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I support adoption and I am willing to be a reviewer. Roque. On Jan 21, 2012, at 1:19 AM, Murphy, Sandra wrote: > The working group has been requested to adopt = draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. >=20 > Please respond to the list to say whether you accept this draft as a = working group draft and are willing to work on it. Remember that you do = not need to accept all content in a draft to adopt, as draft editors are = required to reflect the consensus of the working group. >=20 > This call will end 3 Feb 2012. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-1021--953018609 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" 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 DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjQwODMzMzZaMCMGCSqGSIb3DQEJBDEWBBTTKPNj+kygaxxijf3QtwbFK8XF6zCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBcqnFMkRa4bzebNEh8PxDuMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQXKpxTJEWuG83mzRI fD8Q7jANBgkqhkiG9w0BAQEFAASCAQBLF8u+p5FR5yiBiugn2c6kS2JBSVKt3cJWe4Yu39/QJTf3 Q4eBk9SppHj/ikkUutgo4aJskrPHWWRBbc+wduUk6LRNnFxNj9N1LdStw7z1hNmkYFTFB2iORgYs zC/cb/zO5lGRCtLnOkGyHZgVMj4tbTP9lLwc/BaIX3p3SlliJoGWMbv/Kky0JDOTzpB13cZm59lu qZvRj8A8QuXmDusO+yDuI9+GKHzTRU16ufCXU+Sdd5w8Mgvfze9jeFjILhXOu9XESXXnSt//BCP2 BoimZNNgrEVbBsRAm1PxJZCDEcNl9XoiI74l/vpAz1rwI0U4NtNAtqUKPXLyBNmO0US3AAAAAAAA --Apple-Mail-1021--953018609-- From ejkern@gmail.com Tue Jan 24 09:57:01 2012 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 E94BA21F84AF for ; Tue, 24 Jan 2012 09:57:01 -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 wExpad-socl3 for ; Tue, 24 Jan 2012 09:57:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44E8D21F856C for ; Tue, 24 Jan 2012 09:57:01 -0800 (PST) Received: by iagf6 with SMTP id f6so6209002iag.31 for ; Tue, 24 Jan 2012 09:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ubTQazM6CV21YWXWVxCr/JRXKdGqX/aKlvnizdirbxc=; b=kUS8GotJ1J17EbZ91dCfgq2eN5orubQl/dMXYuQiqYmFM0CqpT4bM8WJVbkUPFwpa2 3MnTdsSc1a/xr8cRts62YxtEcxEVD/1hjdrspoIQW7JIZdOdXy1Q2kOrE1v4M7yyJIAg bvZ1itG3EOF/TrZoJkxP8RDzveQbpqrUvsNxM= Received: by 10.42.157.133 with SMTP id d5mr12201333icx.46.1327427820753; Tue, 24 Jan 2012 09:57:00 -0800 (PST) Received: from dhcp-171-69-157-229.cisco.com (dhcp-171-69-157-229.cisco.com. [171.69.157.229]) by mx.google.com with ESMTPS id pb6sm30425186igc.5.2012.01.24.09.56.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 09:56:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ed Kern In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Date: Tue, 24 Jan 2012 09:56:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1251.1) Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Tue, 24 Jan 2012 17:57:02 -0000 Support adoption of this document into the wg. Happy to review as well. =20 Although clarifying sys test vs unit test vs beta will be about as much = fun as defining a "route leak". Ed On Jan 20, 2012, at 4:19 PM, Murphy, Sandra wrote: > The working group has been requested to adopt = draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. >=20 > Please respond to the list to say whether you accept this draft as a = working group draft and are willing to work on it. Remember that you do = not need to accept all content in a draft to adopt, as draft editors are = required to reflect the consensus of the working group. >=20 > This call will end 3 Feb 2012. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From eosterweil@verisign.com Tue Jan 24 10:44:02 2012 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 F1D3A21F84C5 for ; Tue, 24 Jan 2012 10:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 5PL5gbATsIgt for ; Tue, 24 Jan 2012 10:44:01 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id DC04E11E8094 for ; Tue, 24 Jan 2012 10:44:00 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTx777ZS/Na/cz4KvpDxFN/yPreATkr3F@postini.com; Tue, 24 Jan 2012 10:44:00 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0OIhtI2025936; Tue, 24 Jan 2012 13:43:57 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 13:43:55 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 24 Jan 2012 13:43:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 24 Jan 2012 18:43:55.0133 (UTC) FILETIME=[1FF472D0:01CCDAC8] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 24 Jan 2012 18:44:02 -0000 On Jan 23, 2012, at 3:28 PM, Stephen Kent wrote: > At 10:38 PM -0500 1/19/12, Eric Osterweil wrote: >>=20 >> > This is a local matter, so each ISP can decide what approach they = wish to adopt. I personally prefer installing the cert for the CA. >>=20 >> Yeah, I see. I agree that it should be a local policy decision, but = then how does this avoid my initial concern about relying on crypto = material that has been dispatched through customs (or some other suspect = medium), where key material could be intercepted and extracted? >=20 > The focus of BGPSEC is improving inter-AS routing security. The = operator of any AS may not do a great job of securing the keys = associated with some or all of its routers. Other ASes will not, in = general, be able to evaluate the operational security of an AS. BGPSEC = tries to limit the extent to which an AS can lie about routes that it = propagates. Local (within an AS) security errors or poor practices do = not undermine this security feature. This seems almost like a self-contradictory statement. How is the = system improving AS security if keys can only be deployed over a = potentially compromised medium, and there is no provision for CAs, = signers, RPs, etc. to express partial trust? With BGPSEC, we are = already assuming some degree of trust imparted by signatures, but your = comment above suggests that there should be some further understanding = that "other ASes" cannot evaluate the trustworthiness of what they are = consuming... If this is the case, I would worry that we are worse off = with this false sense of security... To put it differently, I think this highlights a misalignment between = the design of BGPSEC and what operators are going to have to deal with. = We're not giving any choice to operators that will essentially have to = risk compromise, or not play in this system at all... >=20 >> Also, is it safe to assume that you would need the CA(s) to restrict = access to just your own routers (so that unknown routers/certs cannot = issue KGReqs that result in KGReses)? >=20 > A CA issuing certs to routers in an AS must have a way to verify that = a cert request is form a legitimate source. There are various ways this = can be done and, ultimately, this too is a local matter. Actually, I think this is a "turtles all the way down" issue. I cannot = see any silver bullet here that solves this (which is what I'm trying to = highlight). We can't bootstrap trust in a BGPSEC router's key w/o some = external handshake, but we can't bootstrap that handshake without some = external cert, but we can't bootstrap that without... etc. Deploying a = remote signer with sensitive information (private keys, shared secrets, = etc.) seems to be a serious problem... >=20 >> > When key escrow has been required, it has usually been mandated for = keys used for encryption, not for integrity or authentication. Since = we're discussing integrity & authentication here, it is not clear that = there are any applicable key escrow regulations. >>=20 >> Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't = the curly braces denote encrypted material? I thought the responses in = the key exchanges where necessarily encrypted in this protocol? = Otherwise, the new private key is sent in the clear. I fully accept the = possibility that I'm confused here, but if the material is encrypted and = needs to be decrypted, would the corresponding keys be subject to escrow = policies? >=20 > Typically no, because the use of the key being issued is for signing. But the diagrams show encryption. Are the KGRes private keys to be sent = in the clear then? >=20 >> > Also, the IETF general policy has been to ignore any = nation-specific crypto regulations when developing standards. >>=20 >> I see, I guess I had thought we should be worried about the eventual = operational issues that might arise. I didn't know this was taboo, but = shouldn't we find a way to address these concerns in order to help = ensure the design's operational relevance when it's finished? I'm just = bringing this up in the sprit of making this design more relevant, not = because I think there should be some official linkage to escrow policies = or anything. >=20 > In general it is appropriate to worry about operational issues. But, = I'd suggest that key escrow is not within scope, based on previous IETF = experience in related areas. OK, I suppose my parting thought on this escrow issue, then, is that = having to negotiate key escrow is an issue that operators will be = required to face with this system, and I am worried that our working = group's secure design might be a non-starter for some unless we try to = address this issue it in the design. I really feel like we need to fix = this to keep our design relevant. Eric= From eosterweil@verisign.com Tue Jan 24 10:44:37 2012 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 DABE521F84D1 for ; Tue, 24 Jan 2012 10:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 2CjHwizXXGq8 for ; Tue, 24 Jan 2012 10:44:36 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3C51921F84C5 for ; Tue, 24 Jan 2012 10:44:36 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKTx78EXVg0zOF9CKWoFZU0VWtpIqJQ9Il@postini.com; Tue, 24 Jan 2012 10:44:36 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q0OIiX1e025965; Tue, 24 Jan 2012 13:44:33 -0500 Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.30.33]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 13:44:33 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Eric Osterweil In-Reply-To: Date: Tue, 24 Jan 2012 13:44:32 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <59DDDCF5-4FED-4B66-9739-59BAECD00027@verisign.com> <8A9451E4-35C1-456B-960C-7FD150C0CF4C@verisign.com> To: Stephen Kent X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 24 Jan 2012 18:44:33.0338 (UTC) FILETIME=[36BA11A0:01CCDAC8] Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 24 Jan 2012 18:44:38 -0000 On Jan 23, 2012, at 3:31 PM, Stephen Kent wrote: > At 10:39 PM -0500 1/19/12, Eric Osterweil wrote: >> ... >> > >>> Even if there are many fewer certs, inconsistent caches would pose a = problem. Unless we're discussing an emergency rekey for a cert, the = smart procedure is to post a new cert well before the old one expires, = allowing RPs to retrieve the new one in plenty of time. >>=20 >> Yeah, I agree with your comment about getting keys out ahead of time. = However, with a corpus of keys that could well order in the millions, I = would worry that the inherent churn and resource requirements are going = to be well more than we are (or at least I was) expecting. >=20 > speak for yourself :-). Good one... >=20 >> > There is not yet an operational guidance doc for router cert = management, but >>> I anticipate this sort of guidance will appear there. >>=20 >> Will it include some discussion about scaling? I think this = key-per-router idea could turn out to be Pandora's box. While having a = key or two per AS or per prefix may allow us to use elements of today's = routing system to give us some idea about how churn and dynamics _may_ = look, I'm kind of worried now that we haven't properly evaluated how = enormous the resource dependencies will be with per-router-keys. Are = there any specific plans to write this up anywhere? >=20 > I anticipate that an operational considerations doc will be written. Great, I'd like to request that some form of complexity analysis be = included (even just back of the envelope kinds of explanations). Thanks, Eric= From Sandra.Murphy@sparta.com Thu Jan 26 13:10:14 2012 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 B982C21F86C2; Thu, 26 Jan 2012 13:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.62 X-Spam-Level: X-Spam-Status: No, score=-101.62 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_05=-1.11, 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 viHxiphb3Shb; Thu, 26 Jan 2012 13:10:14 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id CB3C321F8629; Thu, 26 Jan 2012 13:10:13 -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 q0QLABGP009383; Thu, 26 Jan 2012 15:10:11 -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 q0QLAApk009766; Thu, 26 Jan 2012 15:10:11 -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.0355.002; Thu, 26 Jan 2012 16:09:52 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: interim meeting registration Thread-Index: AczcbTK8ywnaQRvNTx2O3rB9fzjAiw== Date: Thu, 26 Jan 2012 21:09:51 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6076C7A@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" Subject: [sidr] interim meeting registration 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, 26 Jan 2012 21:10:14 -0000 Logistics are made for the interim meeting. To register for the meeting, please send a message to interim-sidr@tislabs.= com. There is NO registration fee for this meeting, but please do register= so room arrangements are suitable for the number of attendees. Updates on= meeting logistics will be sent to those who register. =20 Registration will close if the room is filled to capacity. I honestly don'= t think that is likely, unless most of the NANOG attendees decide to come. A wiki page on the tools' site sidr wiki has been created: http://trac.tool= s.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209. The agenda at the mom= ent is just as was announced. Updates to the agenda will be posted to that= wiki page. A list of those registered will be maintained at http://trac.tools.ietf.org= /wg/sidr/trac/wiki/InterimMeeting20120209-attendees. --Sandy= From Sandra.Murphy@sparta.com Thu Jan 26 14:00:30 2012 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 921B821F8639; Thu, 26 Jan 2012 14:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 Yd0VNhDTqMGA; Thu, 26 Jan 2012 14:00:30 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 032C321F862B; Thu, 26 Jan 2012 14:00:29 -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 q0QM0TFs009865; Thu, 26 Jan 2012 16:00:29 -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 q0QM0SbY011266; Thu, 26 Jan 2012 16:00:28 -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.0355.002; Thu, 26 Jan 2012 17:00:16 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: interim meeting registration Thread-Index: AczcbTK8ywnaQRvNTx2O3rB9fzjAiwACHS0Z Date: Thu, 26 Jan 2012 22:00:15 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6076D46@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6076C7A@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6076C7A@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" Subject: Re: [sidr] interim meeting registration 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, 26 Jan 2012 22:00:30 -0000 Forgot to ask: In your registration message, please indicate your affiliation, for the pur= pose of completing the wiki attendee list. Also, the obligatory note that this is --Sandy, speaking as wg co-chair ________________________________________ From: Murphy, Sandra Sent: Thursday, January 26, 2012 4:09 PM To: sidr@ietf.org Cc: sidr-chairs@ietf.org Subject: interim meeting registration Logistics are made for the interim meeting. To register for the meeting, please send a message to interim-sidr@tislabs.= com. There is NO registration fee for this meeting, but please do register= so room arrangements are suitable for the number of attendees. Updates on= meeting logistics will be sent to those who register. Registration will close if the room is filled to capacity. I honestly don'= t think that is likely, unless most of the NANOG attendees decide to come. A wiki page on the tools' site sidr wiki has been created: http://trac.tool= s.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209. The agenda at the mom= ent is just as was announced. Updates to the agenda will be posted to that= wiki page. A list of those registered will be maintained at http://trac.tools.ietf.org= /wg/sidr/trac/wiki/InterimMeeting20120209-attendees. --Sandy= From jgs@bgp.nu Thu Jan 26 14:17:27 2012 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 2E21421F8629 for ; Thu, 26 Jan 2012 14:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, 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 4in2jbsxtdkC for ; Thu, 26 Jan 2012 14:17:26 -0800 (PST) Received: from bgp.nu (bgp.nu [147.28.0.53]) by ietfa.amsl.com (Postfix) with ESMTP id 26DDA21F8489 for ; Thu, 26 Jan 2012 14:17:26 -0800 (PST) Received: from sa-nc-it-73.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 7BB3866D357; Thu, 26 Jan 2012 17:17:25 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Date: Thu, 26 Jan 2012 14:17:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1251.1) Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Thu, 26 Jan 2012 22:17:27 -0000 Support. --John On Jan 20, 2012, at 4:19 PM, Murphy, Sandra wrote: > The working group has been requested to adopt = draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. >=20 > Please respond to the list to say whether you accept this draft as a = working group draft and are willing to work on it. Remember that you do = not need to accept all content in a draft to adopt, as draft editors are = required to reflect the consensus of the working group. >=20 > This call will end 3 Feb 2012. >=20 > --Sandy, speaking as wg co-chair From Sandra.Murphy@sparta.com Thu Jan 26 15:23:00 2012 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 56D8021F8743; Thu, 26 Jan 2012 15:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 Af0OvA4kQwU7; Thu, 26 Jan 2012 15:22:59 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5035F21F873E; Thu, 26 Jan 2012 15:22:59 -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 q0QNMvAU010804; Thu, 26 Jan 2012 17:22:57 -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 q0QNMvHe013697; Thu, 26 Jan 2012 17:22:57 -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.0355.002; Thu, 26 Jan 2012 18:22:57 -0500 From: "Murphy, Sandra" To: "Murphy, Sandra" , "sidr@ietf.org" Thread-Topic: interim meeting registration Thread-Index: AczcbTK8ywnaQRvNTx2O3rB9fzjAiwACHS0ZAAGVS+A= Date: Thu, 26 Jan 2012 23:22:56 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6076E18@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6076C7A@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F6076D46@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6076D46@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.81.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@ietf.org" Subject: Re: [sidr] interim meeting registration 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, 26 Jan 2012 23:23:00 -0000 I should have known that IETF-ers would not be happy with the free format s= pecification I gave below. I have received a couple of requests for clarif= ication. So. The registration request message should have the following: Name: Affiliation: E-mail address: The e-mail address will not be noted on the wiki attendees page. =20 --Sandy, speaking as co-chair =20 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Thursday, January 26, 2012 5:00 PM > To: sidr@ietf.org > Cc: sidr-chairs@ietf.org > Subject: Re: [sidr] interim meeting registration >=20 > Forgot to ask: >=20 > In your registration message, please indicate your affiliation, for the > purpose of completing the wiki attendee list. >=20 > Also, the obligatory note that this is >=20 > --Sandy, speaking as wg co-chair >=20 > ________________________________________ > From: Murphy, Sandra > Sent: Thursday, January 26, 2012 4:09 PM > To: sidr@ietf.org > Cc: sidr-chairs@ietf.org > Subject: interim meeting registration >=20 > Logistics are made for the interim meeting. >=20 > To register for the meeting, please send a message to interim- > sidr@tislabs.com. There is NO registration fee for this meeting, but > please do register so room arrangements are suitable for the number of > attendees. Updates on meeting logistics will be sent to those who > register. >=20 > Registration will close if the room is filled to capacity. I honestly > don't think that is likely, unless most of the NANOG attendees decide to > come. >=20 > A wiki page on the tools' site sidr wiki has been created: > http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209. The > agenda at the moment is just as was announced. Updates to the agenda wil= l > be posted to that wiki page. >=20 > A list of those registered will be maintained at > http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209- > attendees. >=20 > --Sandy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Thu Jan 26 16:30:24 2012 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 7E00A21F8707; Thu, 26 Jan 2012 16:30:24 -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 Eq0BxiVUob0R; Thu, 26 Jan 2012 16:30:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6621F86EB; Thu, 26 Jan 2012 16:30: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: <20120127003023.22893.89987.idtracker@ietfa.amsl.com> Date: Thu, 26 Jan 2012 16:30:23 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-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, 27 Jan 2012 00:30: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 : 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-04.txt Pages : 31 Date : 2012-01-26 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-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-usecases-04.txt From turners@ieca.com Thu Jan 26 16:41:17 2012 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 C0BB021F8682 for ; Thu, 26 Jan 2012 16:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.129, 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 lwukWhwTHwkr for ; Thu, 26 Jan 2012 16:41:17 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.93.164.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5788421F85E0 for ; Thu, 26 Jan 2012 16:41:17 -0800 (PST) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 88680A4BB4AB6; Thu, 26 Jan 2012 18:41:16 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 7A8C3A4BB4A7D for ; Thu, 26 Jan 2012 18:41:16 -0600 (CST) Received: from [96.231.128.155] (port=37397 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqZsR-0007T1-U4; Thu, 26 Jan 2012 18:41:16 -0600 Message-ID: <4F21F2A8.1080003@ieca.com> Date: Thu, 26 Jan 2012 19:41:12 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Murphy, Sandra" References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.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-128-155.washdc.east.verizon.net (thunderfish.local) [96.231.128.155]:37397 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "sidr@ietf.org" Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Fri, 27 Jan 2012 00:41:17 -0000 On 1/20/12 7:19 PM, Murphy, Sandra wrote: > The working group has been requested to adopt draft-ymbk-rpki-rtr-impl-01.txt as a working group draft. > > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr-impl. > > Please respond to the list to say whether you accept this draft as a working group draft and are willing to work on it. Remember that you do not need to accept all content in a draft to adopt, as draft editors are required to reflect the consensus of the working group. > > This call will end 3 Feb 2012. > > --Sandy, speaking as wg co-chair I support adoption and will review it. spt From kotikalapudi.sriram@nist.gov Thu Jan 26 17:04:31 2012 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 94B8421F8663 for ; Thu, 26 Jan 2012 17:04:31 -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 XJX9SxdaxuuK for ; Thu, 26 Jan 2012 17:04:31 -0800 (PST) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D3DDC21F8649 for ; Thu, 26 Jan 2012 17:04:30 -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.355.2; Thu, 26 Jan 2012 20:04:22 -0500 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 26 Jan 2012 20:04:29 -0500 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" Date: Thu, 26 Jan 2012 20:04:29 -0500 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-usecases-04.txt Thread-Index: AczcjZxUKNz+Be3fRu+xIKeTdtK7+A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] I-D Action: draft-ietf-sidr-usecases-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, 27 Jan 2012 01:04:31 -0000 The I-D has been revised to include changes based on Sandy's comments from Dec. 21, 2011. http://www.ietf.org/mail-archive/web/sidr/current/msg03860.html Sandy: Thank you for the careful read and all your comments/suggestions. The following is a summary of the changes incorporated: 1. Corrected the typos/errors in example prefixes in use cases (Sandy: Thanks for the catch). 2. Added new Section 1.2. Documentation Prefixes, and added relevant references to RFCs 5737 and 1918 (per comment from Sandy). 3. Inserted new use case -- 7.1.6. Covering ROA Prefix and the ROA is an AS0 ROA 4. Made sure all example ASNs are used within the range 64496 - 64511 (per RFC 5398). 5. As Sandy pointed out, some of the definitions (in Section 1.3) were ambiguous. Randy suggested we reuse the definitions available in [draft-ietf-sidr-pfx-validate-03]. With permission of the authors, we have reused several of those carefully-worded definitions (thanks to John Scudder, Randy et al.). Some definitions that are new to this document have been retained after adding further clarity. 6. Updated the references (in particular, the AS_SET deprecation I-D which is now RFC 6472). Sriram (with Terry and Russ W) -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, January 26, 2012 7:30 PM To: i-d-announce@ietf.org Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-usecases-04.txt 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 : 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-04.txt Pages : 31 Date : 2012-01-26 This document provides use cases, directions, and interpretations for organizations and relying parties when creating or encountering RPKI object scenarios in the public RPKI. All of the above are discussed here in relation to the Internet routing system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-usecases-04.txt From Sandra.Murphy@sparta.com Fri Jan 27 08:04:54 2012 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 2F6C521F85E3 for ; Fri, 27 Jan 2012 08:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, 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 VJyhDnXWjBel for ; Fri, 27 Jan 2012 08:04:53 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id C86BA21F84F1 for ; Fri, 27 Jan 2012 08:04:51 -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 q0RG4oCF015449 for ; Fri, 27 Jan 2012 10:04:50 -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 q0RG4oJG028703 for ; Fri, 27 Jan 2012 10:04:50 -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.0355.002; Fri, 27 Jan 2012 11:04:49 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt Thread-Index: AczX0k8MBLEob/ovShO+j20oxVDgwAFOoY2Q Date: Fri, 27 Jan 2012 16:04:48 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6077032@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60756D3@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.81.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-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: Fri, 27 Jan 2012 16:04:54 -0000 A suggestion was made at the last wg call, that reminders should be sent ou= t for approaching deadlines. You are hereby reminded that there is an active wg call for adoption, which= ends a week from today. --Sandy, speaking as wg co-chair > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Murphy, Sandra > Sent: Friday, January 20, 2012 7:19 PM > To: sidr@ietf.org > Subject: [sidr] WG adoption call for draft-ymbk-rpki-rtr-impl-01.txt >=20 > The working group has been requested to adopt draft-ymbk-rpki-rtr-impl- > 01.txt as a working group draft. >=20 > The draft is available at http://tools.ietf.org/html/draft-ymbk-rpki-rtr- > impl. >=20 > Please respond to the list to say whether you accept this draft as a > working group draft and are willing to work on it. Remember that you do > not need to accept all content in a draft to adopt, as draft editors are > required to reflect the consensus of the working group. >=20 > This call will end 3 Feb 2012. >=20 > --Sandy, speaking as wg co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Fri Jan 27 20:08:03 2012 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 C808821F8501; Fri, 27 Jan 2012 20:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LWj+J2-YUXXS; Fri, 27 Jan 2012 20:08:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B48521F84E6; Fri, 27 Jan 2012 20:08:03 -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: <20120128040803.17367.76902.idtracker@ietfa.amsl.com> Date: Fri, 27 Jan 2012 20:08:03 -0800 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-25.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, 28 Jan 2012 04:08:04 -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-25.txt Pages : 25 Date : 2012-01-27 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-25.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-25.txt From randy@psg.com Fri Jan 27 20:10:00 2012 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 764BC21F84EF; Fri, 27 Jan 2012 20:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 xF5vqWI91UZm; Fri, 27 Jan 2012 20:09:59 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 74FB921F84E7; Fri, 27 Jan 2012 20:09:59 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rqzbx-000G41-SZ; Sat, 28 Jan 2012 04:09:58 +0000 Date: Sat, 28 Jan 2012 13:09:56 +0900 Message-ID: From: Randy Bush To: internet-drafts@ietf.org In-Reply-To: <20120128040803.17367.76902.idtracker@ietfa.amsl.com> References: <20120128040803.17367.76902.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@ietf.org, i-d-announce@ietf.org Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-25.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, 28 Jan 2012 04:10:00 -0000 > Title : The RPKI/Router Protocol > Author(s) : Randy Bush > Rob Austein > Filename : draft-ietf-sidr-rpki-rtr-25.txt > Pages : 25 > Date : 2012-01-27 > > 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 save you a bit Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-25 randy From kent@bbn.com Mon Jan 30 07:57:39 2012 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 73A7221F848F for ; Mon, 30 Jan 2012 07:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 T-gtXeiZODVb for ; Mon, 30 Jan 2012 07:57:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACF621F85C3 for ; Mon, 30 Jan 2012 07:57:38 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49179) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rrtbt-000Owd-Cw; Mon, 30 Jan 2012 10:57:37 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> Date: Mon, 30 Jan 2012 10:57:35 -0500 To: Eric Osterweil From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 15:57:39 -0000 At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >... > > >> The focus of BGPSEC is improving inter-AS routing security. The >>operator of any AS may not do a great job of securing the keys >>associated with some or all of its routers. Other ASes will not, in >>general, be able to evaluate the operational security of an AS. >>BGPSEC tries to limit the extent to which an AS can lie about >>routes that it propagates. Local (within an AS) security errors or >>poor practices do not undermine this security feature. > >This seems almost like a self-contradictory statement. I guess I should be happy that you included "almost" :-). > How is the system improving AS security if keys can only be >deployed over a potentially compromised medium, and there is no >provision for CAs, signers, RPs, etc. to express partial trust? Trust is subjective, not transitive, and a poor choice for a metric. Each AS operates in whatever way it chooses. This is already true with regard to local routing policy, quality of network management, subscriber service, etc. This same notion extends to the security of its BGPSEC operation. Having an AS assert how well it secures it's BGPSEC router keys is a self-evaluative declaration. It is not very meaningful re the security guarantees that BGPSEC offers. Each AS operator is a CA, but it's not as though relying parties can choose a different CA to attest to the authorization of these routers to represent the AS. The operator is authoritative for this info. One way to think of this is, if you are willing to do business with an AS operator, irrespective of its use of BGPSEC, you should be at least as happy when the operator deploys BGPSEC. Deploying BGPSEC will not make the operator "better" relative to other aspects of its operation; hopefully it also will not make the operator worse. > With BGPSEC, we are already assuming some degree of trust imparted >by signatures, but your comment above suggests that there should be >some further understanding that "other ASes" cannot evaluate the >trustworthiness of what they are consuming... If this is the case, >I would worry that we are worse off with this false sense of >security... I don't belive we are creating a false sense of security, but there may be confusion about the security model for BGPSEC. A major goal of BGPSEC is to limit the extent to which errors/misbehavior by an AS operator, or a successful attack against an AS operator, can adversely affect other ASes (re routing). The RPKI limits the (verifiable) assertions that an AS operator can make about the AS that its routers represent, and the prefixes it can originate. The BGPSEC per-AS-hop sigs limit the assertions the AS can make re what routes have been advertised to it. These guarantees still apply whether the operator does a good or poor job of router key management. >To put it differently, I think this highlights a misalignment >between the design of BGPSEC and what operators are going to have to >deal with. We're not giving any choice to operators that will >essentially have to risk compromise, or not play in this system at >all... I disagree with your characterization of the situation. One anticipates that an operator will prefer signed routes to unsigned routes, although that is still a local choice. You seem to be suggesting that if an operator were to publish the equivalent of a CPS re its router cert secruity management, then other operators could use this info to decide how much to trust signed updates. While I agree that one could imagine this sort of trust model, it becomes very complex very quickly. Experience suggests that users are not good at managing such complex trust models. Also, since the data is self-reported, it's not clear how one ought to weight it. So, we have adopted a much simpler trust model. >... > > A CA issuing certs to routers in an AS must have a way to verify >that a cert request is form a legitimate source. There are various >ways this can be done and, ultimately, this too is a local matter. > >Actually, I think this is a "turtles all the way down" issue. I >cannot see any silver bullet here that solves this (which is what >I'm trying to highlight). We can't bootstrap trust in a BGPSEC >router's key w/o some external handshake, but we can't bootstrap >that handshake without some external cert, but we can't bootstrap >that without... etc. Deploying a remote signer with sensitive >information (private keys, shared secrets, etc.) seems to be a >serious problem... I'm puzzled by your comments above. CAs have used various methods to provision certs to users and to devices for years. Each Cisco VoIP phone has a vendor-installed cert and private key, and this has been true for years. One might image a similar feature for BGPSEC-enabled routers. This cert could be used to bootstrap issuance of a BGPSEC cert. The EST draft explicitly incorporates this notion. This is an elegant approach to cert issuance, but it's not the only option. So, as in many other PKI-based systems, the specific means by which a CA provisions certs will remain a local matter. If a router is in a location that the operator considers risky, it might choose to use a per-router cert for that device, while sharing a cert/key for other routers. That is a per-operator choice. >... > > >> Typically no, because the use of the key being issued is for signing. > >But the diagrams show encryption. Are the KGRes private keys to be >sent in the clear then? The issue is not whether encryption is used at any point in a key provisioning process. The issue, typically, has been what is the purpose of the key that might be subject to an escrow policy. But, in any case, I think key escrow is a red herring. >... > > In general it is appropriate to worry about operational issues. >But, I'd suggest that key escrow is not within scope, based on >previous IETF experience in related areas. > >OK, I suppose my parting thought on this escrow issue, then, is that >having to negotiate key escrow is an issue that operators will be >required to face with this system, and I am worried that our working >group's secure design might be a non-starter for some unless we try >to address this issue it in the design. I really feel like we need >to fix this to keep our design relevant. I see nothing to fix. Let's consider an AS operating in Elbonia. Let's assume that the Elbonian government imposes key escrow on router keys used with BGPSEC. This implies that signed updates from an AS operating in Elbonia might really be bogus, generated by the Elbonia secret police (the notorious ESP). How is this different from the ESP taking over the AS, coercing the operators of the AS to emit bogus updates? Since BGPSEC is employed, the AS cannot emit verifiable routes that have not been sent to them. Thay cannot originate verifiable bogus routes for prefixes not allocated to them. The secruity guarantees provided by BGPSEC are designed to limit the damage that occurs if an AS makes errors, behaves badly, or is compromised. Attacks based on key escrow are just one form of compromise. Steve From brian.peter.dickson@gmail.com Mon Jan 30 10:07:33 2012 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 6125A21F8631 for ; Mon, 30 Jan 2012 10:07:33 -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 EFLb-ubhmPQy for ; Mon, 30 Jan 2012 10:07:32 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 805B321F862A for ; Mon, 30 Jan 2012 10:07:32 -0800 (PST) Received: by wicr5 with SMTP id r5so4221460wic.31 for ; Mon, 30 Jan 2012 10:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V03thfthw24WRft2TWVXIE76/M+VIl81cWgSMXfJ9oo=; b=cF3grONt7G8p/bJHxRpKDHNQevvClExvMU5jVGfgOYGDZzuJj6yS0m5ZblYpcw1/bP +RFHbATEi05iffyoNRFML2XUJTIqWsaozUg8X2+Bl/c0iVA9Vr1laTmectjrg+2y8PAQ SRCXmJrhACpzbeZ/Ez62atOZVrnRaFSVkDgU4= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr36910612wib.3.1327946851787; Mon, 30 Jan 2012 10:07:31 -0800 (PST) Received: by 10.223.3.15 with HTTP; Mon, 30 Jan 2012 10:07:31 -0800 (PST) In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> Date: Mon, 30 Jan 2012 13:07:31 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 18:07:33 -0000 On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: > At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>> =A0The focus of BGPSEC is improving inter-AS routing security. The oper= ator >>> of any AS may not do a great job of securing the keys associated with s= ome >>> or all of its routers. Other ASes will not, in general, be able to eval= uate >>> the operational security of an AS. BGPSEC tries to limit the extent to = which >>> an AS =A0can lie about routes that it propagates. Local (within an AS) >>> security errors or poor practices do not undermine this security featur= e. > A major goal of BGPSEC is to limit the extent to which errors/misbehavior= by > an AS operator, or a successful attack against an AS operator, can advers= ely > affect other ASes (re routing). The RPKI limits the (verifiable) assertio= ns > that an AS operator can make about the AS that its routers represent, and > the prefixes it can originate. > The BGPSEC per-AS-hop sigs limit the > assertions the AS can make re what routes have been advertised to it. This is a stated goal, but how this achieved or achievable relates greatly to key management. See below for why I think there are issues with the current protocol design vs key management. > These > guarantees still apply whether the operator does a good or poor job of > router key management. I disagree with this assertion. Let's consider off-axis risks. Originator O, Relying party R, Weak-operator W, and Bad Actor B. If poor key management on W makes it possible for the private keys of a single router in W's network to be learned by B, then all bets are off for anything advertised via W. Here's why: Presume all the good stuff you want about O, and the RPKI system. Route X, originated by O, is fully validated and legitimate. Topologically, let's say the following BGPSEC sessions and links exist: O--?--W--?--R--?--B--? (All the "?" mean there could be intermediate parties, but none are required for this example to still be applicable.) In order to spoof announcements, B need two things: The private key of a single router (such as the key for a W router), and the data that would be signed by that router (for X). However, since anyone receiving route X which was sent from O via W _must_ contain that data, it is trivial for B to generate false routes for O. The process would be: B sets up a router F ( which claims to be the W router for which the key was compromised). The (W_fake) router F is configured with ASN =3D=3D W. B sets up a BGPSEC session between F and B, and signs the results. Voila, BGPSEC signed routes received by R, that appear to be: O--?--W--B--?--R and this BGPSEC-signed path is fully origin-validatable and fully BGPSEC path-validatable. An error by W, allows B to "pwn" O, without O or R doing anything wrong at = all. There is no (trivial) way for R (or O) to detect or prevent this kind of at= tack. This shows why one or more of the following things needs to be changed in the BGPSEC design: (1) key management requirements (not part of the design) (2) availability of unencrypted signature-input data to off-axis parties (3) ability for a single signature to subvert the validation process (4) absolute trust model for signature chains (all/nothing) (5) ??? Brian From Sandra.Murphy@sparta.com Mon Jan 30 11:32:42 2012 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 3E69C21F8634 for ; Mon, 30 Jan 2012 11:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, 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 iJL5bvMs7VSI for ; Mon, 30 Jan 2012 11:32:41 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F34C21F85E7 for ; Mon, 30 Jan 2012 11:32:40 -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 q0UJWWvj002875; Mon, 30 Jan 2012 13:32:32 -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 q0UJWWnx024083; Mon, 30 Jan 2012 13:32:32 -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.0355.002; Mon, 30 Jan 2012 14:32:28 -0500 From: "Murphy, Sandra" To: Brian Dickson , Stephen Kent Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AQHM33oIuc3Eip6I+kepCBOaAHZARZYlRm6q Date: Mon, 30 Jan 2012 19:32:28 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> , 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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 19:32:42 -0000 Speaking as a regular ol' wg member: Brian says: >If poor key management on W makes it possible for the private keys of >a single router in W's network to be learned by B, then all bets are >off for anything advertised via W. Actually, you can stop with "all bets are off". Any use of cryptography relies on the protection of the keying material. T= he assurance is not that a particular person/entity can do something, but that= the holder of the keying material can do something. So like sharing your password to your bank account means that someone else can appear as you to the bank, sharing your keys lets someone/something els= e act as if they were you. That is why key compromise is a serious issue. This is common to anything that uses cryptography. It is not specific to t= his particular application. Exposing the keys in DNSSEC, exposing the keys in = https, exposing the ssh keys, exposing passwords, etc., will all affect the assura= nce=20 provided by the cryptography. I do not see any requirements here that would make that any different than = any other use of cryptography in any other environment, so I do not see any need for the protocols here to provide solutions. Pointers to operational guidance= =20 elsewhere, where it exists, perhaps. --Sandy, speaking as regular ol' member ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian Dick= son [brian.peter.dickson@gmail.com] Sent: Monday, January 30, 2012 1:07 PM To: Stephen Kent Cc: sidr@ietf.org list Subject: Re: [sidr] Key learning procedures in BGPsec? On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: > At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>> The focus of BGPSEC is improving inter-AS routing security. The operat= or >>> of any AS may not do a great job of securing the keys associated with s= ome >>> or all of its routers. Other ASes will not, in general, be able to eval= uate >>> the operational security of an AS. BGPSEC tries to limit the extent to = which >>> an AS can lie about routes that it propagates. Local (within an AS) >>> security errors or poor practices do not undermine this security featur= e. > A major goal of BGPSEC is to limit the extent to which errors/misbehavior= by > an AS operator, or a successful attack against an AS operator, can advers= ely > affect other ASes (re routing). The RPKI limits the (verifiable) assertio= ns > that an AS operator can make about the AS that its routers represent, and > the prefixes it can originate. > The BGPSEC per-AS-hop sigs limit the > assertions the AS can make re what routes have been advertised to it. This is a stated goal, but how this achieved or achievable relates greatly to key management. See below for why I think there are issues with the current protocol design vs key management. > These > guarantees still apply whether the operator does a good or poor job of > router key management. I disagree with this assertion. Let's consider off-axis risks. Originator O, Relying party R, Weak-operator W, and Bad Actor B. If poor key management on W makes it possible for the private keys of a single router in W's network to be learned by B, then all bets are off for anything advertised via W. Here's why: Presume all the good stuff you want about O, and the RPKI system. Route X, originated by O, is fully validated and legitimate. Topologically, let's say the following BGPSEC sessions and links exist: O--?--W--?--R--?--B--? (All the "?" mean there could be intermediate parties, but none are required for this example to still be applicable.) In order to spoof announcements, B need two things: The private key of a single router (such as the key for a W router), and the data that would be signed by that router (for X). However, since anyone receiving route X which was sent from O via W _must_ contain that data, it is trivial for B to generate false routes for O. The process would be: B sets up a router F ( which claims to be the W router for which the key was compromised). The (W_fake) router F is configured with ASN =3D=3D W. B sets up a BGPSEC session between F and B, and signs the results. Voila, BGPSEC signed routes received by R, that appear to be: O--?--W--B--?--R and this BGPSEC-signed path is fully origin-validatable and fully BGPSEC path-validatable. An error by W, allows B to "pwn" O, without O or R doing anything wrong at = all. There is no (trivial) way for R (or O) to detect or prevent this kind of at= tack. This shows why one or more of the following things needs to be changed in the BGPSEC design: (1) key management requirements (not part of the design) (2) availability of unencrypted signature-input data to off-axis parties (3) ability for a single signature to subvert the validation process (4) absolute trust model for signature chains (all/nothing) (5) ??? Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr= From brian.peter.dickson@gmail.com Mon Jan 30 11:57:28 2012 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 5114521F84D7 for ; Mon, 30 Jan 2012 11:57:28 -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 AAsjlvGgx20T for ; Mon, 30 Jan 2012 11:57:27 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DEDFD21F84CD for ; Mon, 30 Jan 2012 11:57:26 -0800 (PST) Received: by wgbed3 with SMTP id ed3so4149707wgb.13 for ; Mon, 30 Jan 2012 11:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=L3okoCn2umQ1Aioa0xYpCap6z7nHC9zivz/zLruDfRM=; b=H8GqFrBjYwWizzDLYimg9D8Nla+5uSfR/kxkzFYqCphlytJiZGZFEaIL24+nMWuLcb 1Zkxc89CayESxtefWNH9Qa5lOluto8aVxDh4Z7wn90rUexGmLOIoukSUt2hh++v/5WAA CTAnX4Q89h+T4fujy2jJFYyf+07xKE0/Dxp2E= MIME-Version: 1.0 Received: by 10.180.92.71 with SMTP id ck7mr37658608wib.3.1327953445935; Mon, 30 Jan 2012 11:57:25 -0800 (PST) Received: by 10.223.3.15 with HTTP; Mon, 30 Jan 2012 11:57:25 -0800 (PST) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 14:57:25 -0500 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 19:57:28 -0000 On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra wrote: > Speaking as a regular ol' wg member: > > Brian says: > >>If poor key management on W makes it possible for the private keys of >>a single router in W's network to be learned by B, then all bets are >>off for anything advertised via W. > > Actually, you can stop with "all bets are off". > > Any use of cryptography relies on the protection of the keying material. = =A0The > assurance is not that a particular person/entity can do something, but th= at the > holder of the keying material can do something. Correct. My point was, and is, that _this_ particular design, as has been proposed to the WG, is what is placing the requirement for private key material, and the consequent need to protect said material. Without going into details of alternative designs, it is enough to point out, IMHO, the distinctions: signatures - requires signer to possess private key, recipient(s)/validators need public key encryption - requires sender to have the public key(s), and the recipient(s) need their respective private keys. There are other kinds of encryption as well, which involve shared keys, or in case of DH, random session keys with neither party having/needing the other's key material. What I'm saying is, I don't believe enough attention has been paid to the private key on the router requirement, or its implications. The designers of the protocol really need to justify their choice. It is not enough to wave hands at this and say, "operational docs will cover this". > So like sharing your password to your bank account means that someone els= e > can appear as you to the bank, sharing your keys lets someone/something e= lse > act as if they were you. =A0That is why key compromise is a serious issue= . This is an apples vs oranges thing. There is an end-to-end encrypted session (SSL), and there is no requirement for private key distribution. The bank has its SSL private key, which is neither distributed, nor exposed operationally. Then there's all the L8/L9 stuff related to record keeping etc. (SOX etc.) The primary issue is the creation and exposure of private keys. If the protocol requires FIPS-140 (to whatever level/degree) to ensure it does not introduce weakness or risk, that is something that needs to be addressed. Or, it may be a non-starter if that is a requirement, but the WG needs to make an informed decision. This isn't the kind of stuff to be taken lightly - it strongly impacts deployment and operation, and cost of deployment (and/or risks). > This is common to anything that uses cryptography. =A0It is not specific = to this > particular application. =A0Exposing the keys in DNSSEC, exposing the keys= in https, > exposing the ssh keys, exposing passwords, etc., will all affect the assu= rance > provided by the cryptography. DNSSEC uses effectively out-of-band management for securely distributing public keys (which is what DS uses). DNSSEC supports centralized signature models with HSM use being very scala= ble. SSH also uses distribution of public keys and supports encrypted storage of private keys (presumably in physically secure local storage). This would be the first major deployment of private keying material in geographically diverse locations, that I'm aware of, for the protocol to function as described. > I do not see any requirements here that would make that any different tha= n any other > use of cryptography in any other environment, so I do not see any need fo= r > the protocols here to provide solutions. =A0Pointers to operational guida= nce > elsewhere, where it exists, perhaps. I'd say it goes beyond operational guidance, and to the heart of the protocol design. It is not beyond fixing, but IMHO, desperately requires fixing. At least if it stands a chance of being deployed in the real world. Brian (speaking ONLY for myself). > --Sandy, speaking as regular ol' member > > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian Di= ckson [brian.peter.dickson@gmail.com] > Sent: Monday, January 30, 2012 1:07 PM > To: Stephen Kent > Cc: sidr@ietf.org list > Subject: Re: [sidr] Key learning procedures in BGPsec? > > On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: >> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>>> =A0The focus of BGPSEC is improving inter-AS routing security. The ope= rator >>>> of any AS may not do a great job of securing the keys associated with = some >>>> or all of its routers. Other ASes will not, in general, be able to eva= luate >>>> the operational security of an AS. BGPSEC tries to limit the extent to= which >>>> an AS =A0can lie about routes that it propagates. Local (within an AS) >>>> security errors or poor practices do not undermine this security featu= re. >> A major goal of BGPSEC is to limit the extent to which errors/misbehavio= r by >> an AS operator, or a successful attack against an AS operator, can adver= sely >> affect other ASes (re routing). The RPKI limits the (verifiable) asserti= ons >> that an AS operator can make about the AS that its routers represent, an= d >> the prefixes it can originate. > >> The BGPSEC per-AS-hop sigs limit the >> assertions the AS can make re what routes have been advertised to it. > > This is a stated goal, but how this achieved or achievable relates > greatly to key management. > See below for why I think there are issues with the current protocol > design vs key management. > >> These >> guarantees still apply whether the operator does a good or poor job of >> router key management. > > I disagree with this assertion. > > Let's consider off-axis risks. > > Originator O, Relying party R, Weak-operator W, and Bad Actor B. > > If poor key management on W makes it possible for the private keys of > a single router in W's network to be learned by B, then all bets are > off for anything advertised via W. > > Here's why: > > Presume all the good stuff you want about O, and the RPKI system. > Route X, originated by O, is fully validated and legitimate. > > Topologically, let's say the following BGPSEC sessions and links exist: > > O--?--W--?--R--?--B--? > > (All the "?" mean there could be intermediate parties, but none are > required for this example to still be applicable.) > > In order to spoof announcements, B need two things: The private key of > a single router (such as the key for a W router), and the data that > would be signed by that router (for X). > > However, since anyone receiving route X which was sent from O via W > _must_ contain that data, it is trivial for B to generate false routes > for O. > > The process would be: > B sets up a router F ( which claims to be the W router for which the > key was compromised). > The (W_fake) router F is configured with ASN =3D=3D W. > B sets up a BGPSEC session between F and B, and signs the results. > > Voila, BGPSEC signed routes received by R, that appear to be: > > O--?--W--B--?--R > > and this BGPSEC-signed path is fully origin-validatable and fully > BGPSEC path-validatable. > > An error by W, allows B to "pwn" O, without O or R doing anything wrong a= t all. > > There is no (trivial) way for R (or O) to detect or prevent this kind of = attack. > > This shows why one or more of the following things needs to be changed > in the BGPSEC design: > (1) key management requirements (not part of the design) > (2) availability of unencrypted signature-input data to off-axis parties > (3) ability for a single signature to subvert the validation process > (4) absolute trust model for signature chains (all/nothing) > (5) ??? > > Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@sparta.com Mon Jan 30 12:28:00 2012 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 227DE11E80B6 for ; Mon, 30 Jan 2012 12:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 1grfT-iUf16U for ; Mon, 30 Jan 2012 12:27:59 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E011E8091 for ; Mon, 30 Jan 2012 12:27:58 -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 q0UKRnpj003476; Mon, 30 Jan 2012 14:27:49 -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 q0UKRc8j026003; Mon, 30 Jan 2012 14:27:47 -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.0355.002; Mon, 30 Jan 2012 15:27:35 -0500 From: "Murphy, Sandra" To: Brian Dickson Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AQHM33oIuc3Eip6I+kepCBOaAHZARZYlRm6qgABhNYD//7BhKg== Date: Mon, 30 Jan 2012 20:27:34 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com>, 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.137] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 20:28:00 -0000 Speaking as regular ol' member: On Monday, January 30, 2012, Brian Dickson said: >> Any use of cryptography relies on the protection of the keying material.= The >> assurance is not that a particular person/entity can do something, but t= hat the >> holder of the keying material can do something. >Correct. >My point was, and is, that _this_ particular design, as has been >proposed to the WG, >is what is placing the requirement for private key material, and the >consequent need >to protect said material. I reiterate my point: any use of cryptography will require that you are ca= reful with the keying material. Do you have any designs in mind that will NOT use cryptography? --Sandy, speaking as regular ol' member ________________________________________ From: Brian Dickson [brian.peter.dickson@gmail.com] Sent: Monday, January 30, 2012 2:57 PM To: Murphy, Sandra Cc: Stephen Kent; sidr@ietf.org list Subject: Re: [sidr] Key learning procedures in BGPsec? On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra wrote: > Speaking as a regular ol' wg member: > > Brian says: > >>If poor key management on W makes it possible for the private keys of >>a single router in W's network to be learned by B, then all bets are >>off for anything advertised via W. > > Actually, you can stop with "all bets are off". > > Any use of cryptography relies on the protection of the keying material. = The > assurance is not that a particular person/entity can do something, but th= at the > holder of the keying material can do something. Correct. My point was, and is, that _this_ particular design, as has been proposed to the WG, is what is placing the requirement for private key material, and the consequent need to protect said material. Without going into details of alternative designs, it is enough to point out, IMHO, the distinctions: signatures - requires signer to possess private key, recipient(s)/validators need public key encryption - requires sender to have the public key(s), and the recipient(s) need their respective private keys. There are other kinds of encryption as well, which involve shared keys, or in case of DH, random session keys with neither party having/needing the other's key material. What I'm saying is, I don't believe enough attention has been paid to the private key on the router requirement, or its implications. The designers of the protocol really need to justify their choice. It is not enough to wave hands at this and say, "operational docs will cover this". > So like sharing your password to your bank account means that someone els= e > can appear as you to the bank, sharing your keys lets someone/something e= lse > act as if they were you. That is why key compromise is a serious issue. This is an apples vs oranges thing. There is an end-to-end encrypted session (SSL), and there is no requirement for private key distribution. The bank has its SSL private key, which is neither distributed, nor exposed operationally. Then there's all the L8/L9 stuff related to record keeping etc. (SOX etc.) The primary issue is the creation and exposure of private keys. If the protocol requires FIPS-140 (to whatever level/degree) to ensure it does not introduce weakness or risk, that is something that needs to be addressed. Or, it may be a non-starter if that is a requirement, but the WG needs to make an informed decision. This isn't the kind of stuff to be taken lightly - it strongly impacts deployment and operation, and cost of deployment (and/or risks). > This is common to anything that uses cryptography. It is not specific to= this > particular application. Exposing the keys in DNSSEC, exposing the keys i= n https, > exposing the ssh keys, exposing passwords, etc., will all affect the assu= rance > provided by the cryptography. DNSSEC uses effectively out-of-band management for securely distributing public keys (which is what DS uses). DNSSEC supports centralized signature models with HSM use being very scala= ble. SSH also uses distribution of public keys and supports encrypted storage of private keys (presumably in physically secure local storage). This would be the first major deployment of private keying material in geographically diverse locations, that I'm aware of, for the protocol to function as described. > I do not see any requirements here that would make that any different tha= n any other > use of cryptography in any other environment, so I do not see any need fo= r > the protocols here to provide solutions. Pointers to operational guidanc= e > elsewhere, where it exists, perhaps. I'd say it goes beyond operational guidance, and to the heart of the protocol design. It is not beyond fixing, but IMHO, desperately requires fixing. At least if it stands a chance of being deployed in the real world. Brian (speaking ONLY for myself). > --Sandy, speaking as regular ol' member > > > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian Di= ckson [brian.peter.dickson@gmail.com] > Sent: Monday, January 30, 2012 1:07 PM > To: Stephen Kent > Cc: sidr@ietf.org list > Subject: Re: [sidr] Key learning procedures in BGPsec? > > On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: >> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>>> The focus of BGPSEC is improving inter-AS routing security. The opera= tor >>>> of any AS may not do a great job of securing the keys associated with = some >>>> or all of its routers. Other ASes will not, in general, be able to eva= luate >>>> the operational security of an AS. BGPSEC tries to limit the extent to= which >>>> an AS can lie about routes that it propagates. Local (within an AS) >>>> security errors or poor practices do not undermine this security featu= re. >> A major goal of BGPSEC is to limit the extent to which errors/misbehavio= r by >> an AS operator, or a successful attack against an AS operator, can adver= sely >> affect other ASes (re routing). The RPKI limits the (verifiable) asserti= ons >> that an AS operator can make about the AS that its routers represent, an= d >> the prefixes it can originate. > >> The BGPSEC per-AS-hop sigs limit the >> assertions the AS can make re what routes have been advertised to it. > > This is a stated goal, but how this achieved or achievable relates > greatly to key management. > See below for why I think there are issues with the current protocol > design vs key management. > >> These >> guarantees still apply whether the operator does a good or poor job of >> router key management. > > I disagree with this assertion. > > Let's consider off-axis risks. > > Originator O, Relying party R, Weak-operator W, and Bad Actor B. > > If poor key management on W makes it possible for the private keys of > a single router in W's network to be learned by B, then all bets are > off for anything advertised via W. > > Here's why: > > Presume all the good stuff you want about O, and the RPKI system. > Route X, originated by O, is fully validated and legitimate. > > Topologically, let's say the following BGPSEC sessions and links exist: > > O--?--W--?--R--?--B--? > > (All the "?" mean there could be intermediate parties, but none are > required for this example to still be applicable.) > > In order to spoof announcements, B need two things: The private key of > a single router (such as the key for a W router), and the data that > would be signed by that router (for X). > > However, since anyone receiving route X which was sent from O via W > _must_ contain that data, it is trivial for B to generate false routes > for O. > > The process would be: > B sets up a router F ( which claims to be the W router for which the > key was compromised). > The (W_fake) router F is configured with ASN =3D=3D W. > B sets up a BGPSEC session between F and B, and signs the results. > > Voila, BGPSEC signed routes received by R, that appear to be: > > O--?--W--B--?--R > > and this BGPSEC-signed path is fully origin-validatable and fully > BGPSEC path-validatable. > > An error by W, allows B to "pwn" O, without O or R doing anything wrong a= t all. > > There is no (trivial) way for R (or O) to detect or prevent this kind of = attack. > > This shows why one or more of the following things needs to be changed > in the BGPSEC design: > (1) key management requirements (not part of the design) > (2) availability of unencrypted signature-input data to off-axis parties > (3) ability for a single signature to subvert the validation process > (4) absolute trust model for signature chains (all/nothing) > (5) ??? > > Brian > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr= From kent@bbn.com Mon Jan 30 13:46:00 2012 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 652DA11E80BA for ; Mon, 30 Jan 2012 13:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 l-TpRwqKvGZR for ; Mon, 30 Jan 2012 13:45:59 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4C67F11E80B0 for ; Mon, 30 Jan 2012 13:45:59 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49201) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rrz2z-000J7H-Cx; Mon, 30 Jan 2012 16:45:57 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> Date: Mon, 30 Jan 2012 16:37:38 -0500 To: Brian Dickson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 21:46:00 -0000 >... >Let's consider off-axis risks. > >Originator O, Relying party R, Weak-operator W, and Bad Actor B. > >If poor key management on W makes it possible for the private keys of >a single router in W's network to be learned by B, then all bets are >off for anything advertised via W. To put this into perspective you need to say how the secruity problem created by poor key management by W for this router is substantively different from B successfully attacking W's network management system or compromising the router in question to achieve the same goal. >Here's why: > >Presume all the good stuff you want about O, and the RPKI system. >Route X, originated by O, is fully validated and legitimate. > >Topologically, let's say the following BGPSEC sessions and links exist: > >O--?--W--?--R--?--B--? > >(All the "?" mean there could be intermediate parties, but none are >required for this example to still be applicable.) > >In order to spoof announcements, B need two things: The private key of >a single router (such as the key for a W router), and the data that >would be signed by that router (for X). You're example is a bit underspecified, so I'll try to fill in the blanks. - B's goal is to send a route to R, for address space legitimately originated by O, which will attract traffic to B rather than to W, right? - B needs to acquire an update for the target (O), that passed through W, otherwise the forward sig on the BGPSEC update will fail, making the attack fail. - in your example, B will get the BGPSEC update for O, from R, after it has passed through W, which satisfies the criteria above. >The process would be: >B sets up a router F ( which claims to be the W router for which the >key was compromised). >The (W_fake) router F is configured with ASN == W. >B sets up a BGPSEC session between F and B, and signs the results. In many cases, ASes have external info about neighbors to which they are directly connected, e.g., they executed a contract, paid for a link, etc. So, if B tries to claim it's W, based only on having a key from one of W's routers, that often may not work. (It might work if B and R are peers at an IXP and the VLAN at the IXP is not too strong.) I would expect the attack to be: - upon receiopt of the signed update, B strips the sigs applied by W, and by any ASes between W and R, and any ASes between R and B. - using the compromised router key from W, B generates an update that shows O-?-W-B. it signs the update using its (B's) key, and sends it to R, possibly via an intermediate AS ("?"). this way B does not have to pretend to be W. It only asserts that it (B) has a link to W, and that it has the same path to O as W had, plus itself. If there are one or more ASes between W and R, legitimately, then the bogus route is shorter and probably preferable. So, the presence of one or more "?" ASes between W and R is critical, contrary to your assertion. If W is directly connected to R, the bogus route is longer and may not be preferred. You go on to observe that W's poor key management practices allow B to cause O's traffic to be routed through it, even though O and R did nothing wrong. That's true. But it also would be true if B compromised a router or network management computer in W and caused the AS/router to forward traffic destined for O (from R) to B. Or, W may be evil and takes $ from B to send it a copy of traffic from R to O. All of these are ways that the targeted traffic ca be misrouted, due to some bad behavior by W. This is an inherent limitation, in your example; R is dependent on W's secruity, realtive to traffic beign sent to O, because W is between O and R. I don't agree with any of your proposed changes for the design. #1 calls for a level of micromanagement that is not common in IETF standards #2 is not relevant; my detailed attack example did not need to acquire the updates by wiretapping "off axis." #3 suggests multiple sigs per something (AS?, router?) are more secure than a single sig. Absent a lot of unspecified context details, this assertion is not valid. #4, viewed in the context of Eric's message, seems to suggest that if every AS were required to publish self-assertions about key management, then this info would be used as a "trust" value inputs to local routing policy by other ASes. Really? Steve From kent@bbn.com Mon Jan 30 13:59:28 2012 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 25F3E21F8737 for ; Mon, 30 Jan 2012 13:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 f+Z0CU-ykmK1 for ; Mon, 30 Jan 2012 13:59:27 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A206A21F8736 for ; Mon, 30 Jan 2012 13:59:27 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49203) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrzG0-000JE2-9I; Mon, 30 Jan 2012 16:59:24 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 16:52:13 -0500 To: Brian Dickson From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 21:59:28 -0000 At 2:57 PM -0500 1/30/12, Brian Dickson wrote: > >... > >There are other kinds of encryption as well, which involve shared >keys, or in case of DH, random session keys with neither party >having/needing the other's key material. not true. DH key agreement requires that each party receive the public key of the other, in order to compute a shared secret. Steve From brian.peter.dickson@gmail.com Mon Jan 30 14:57:02 2012 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 4E05821F876D for ; Mon, 30 Jan 2012 14:57:02 -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 SKQ34va3KdvL for ; Mon, 30 Jan 2012 14:57:01 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8959F21F8766 for ; Mon, 30 Jan 2012 14:57:01 -0800 (PST) Received: by werm10 with SMTP id m10so4378558wer.31 for ; Mon, 30 Jan 2012 14:57:00 -0800 (PST) Received-SPF: pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.161 as permitted sender) client-ip=10.216.133.161; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.peter.dickson@gmail.com designates 10.216.133.161 as permitted sender) smtp.mail=brian.peter.dickson@gmail.com; dkim=pass header.i=brian.peter.dickson@gmail.com Received: from mr.google.com ([10.216.133.161]) by 10.216.133.161 with SMTP id q33mr9731812wei.46.1327964220765 (num_hops = 1); Mon, 30 Jan 2012 14:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x3ksJWQPhjVPdclcHFUgeDAEms0JsICOUsEJyiVk4CE=; b=ngblSONCS3DG4vpLC7cqwIeXVinhbs8wM8srIXDFAfL7tgxiCZ2LkEHVK6B1NsWTEH 5jrGQaYxhZHQCT1v8NaX6IsPu/CQL9SdKPIcbITg4FToBHgAuOQoZNqNZMxDowo7T+jz 1YuKTpueup79DSeukepnP5oP6RgKWQMWmlDnw= MIME-Version: 1.0 Received: by 10.216.133.161 with SMTP id q33mr8161504wei.46.1327964220657; Mon, 30 Jan 2012 14:57:00 -0800 (PST) Received: by 10.223.3.15 with HTTP; Mon, 30 Jan 2012 14:57:00 -0800 (PST) In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 17:57:00 -0500 Message-ID: From: Brian Dickson To: Stephen Kent Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 22:57:02 -0000 On Mon, Jan 30, 2012 at 4:52 PM, Stephen Kent wrote: > At 2:57 PM -0500 1/30/12, Brian Dickson wrote: >> >> There are other kinds of encryption as well, which involve shared >> keys, or in case of DH, random session keys with neither party >> having/needing the other's key material. > > > not true. DH key agreement requires that each party receive the public > key of the other, in order to compute a shared secret. In DH, each side generates a random (per-session) private key, and computes _a_ public key (which is exchanged), off of that private key . Here's the thing - the "public key" in DH is not pre-published, nor is it re-used. It is a one-use, fire-and-forget object, as are the private key and shared key. This is different from a published (public) key material a la PKI. PKI keys are longer-lived and multiple-use. In DH, neither party has the other's key _before_ they start their DH exchange. That was my point. Sorry for not making that more obvious. Brian From rbarnes@bbn.com Mon Jan 30 15:04:50 2012 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 AA8B721F87AE for ; Mon, 30 Jan 2012 15:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=0.195, 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 IFY1GVNY722e for ; Mon, 30 Jan 2012 15:04:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B803F21F875B for ; Mon, 30 Jan 2012 15:04:49 -0800 (PST) Received: from [128.89.254.25] (port=50645) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rs0HG-000Jge-DS; Mon, 30 Jan 2012 18:04:46 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: Date: Tue, 31 Jan 2012 00:04:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> To: Brian Dickson X-Mailer: Apple Mail (2.1251.1) Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 23:04:50 -0000 On Jan 30, 2012, at 11:57 PM, Brian Dickson wrote: > On Mon, Jan 30, 2012 at 4:52 PM, Stephen Kent wrote: >> At 2:57 PM -0500 1/30/12, Brian Dickson wrote: >>>=20 >>> There are other kinds of encryption as well, which involve shared >>> keys, or in case of DH, random session keys with neither party >>> having/needing the other's key material. >>=20 >>=20 >> not true. DH key agreement requires that each party receive the = public >> key of the other, in order to compute a shared secret. >=20 > In DH, each side generates a random (per-session) private key, and > computes _a_ public key (which is exchanged), off of that private key > . >=20 > Here's the thing - the "public key" in DH is not pre-published, nor is > it re-used. It is a one-use, fire-and-forget object, as are the > private key and shared key. >=20 > This is different from a published (public) key material a la PKI. PKI > keys are longer-lived and multiple-use. >=20 > In DH, neither party has the other's key _before_ they start their DH > exchange. That was my point. I do not think that word (DH) means what you think it means Diffie-Hellman is an algorithm on groups that have hard discrete log = problems. It has nothing to do with key management. I think what you mean to say is DH with *ephemeral* keys. That is not a = necessary property. You can have even DH keys in certificates. = From Sandra.Murphy@sparta.com Mon Jan 30 15:34:22 2012 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 1DBD911E80DB for ; Mon, 30 Jan 2012 15:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 kPs52OODXovE for ; Mon, 30 Jan 2012 15:34:21 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 847BF11E80D7 for ; Mon, 30 Jan 2012 15:34:21 -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 q0UNYKsY005512 for ; Mon, 30 Jan 2012 17:34:20 -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 q0UNYK4K032752 for ; Mon, 30 Jan 2012 17:34:20 -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.0355.002; Mon, 30 Jan 2012 18:34:20 -0500 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: agenda for upcoming interim meeting Thread-Index: AczfpQIdiVQXmcg+Qh++L5mrnG2Cqg== Date: Mon, 30 Jan 2012 23:34:19 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6077A0F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] agenda for upcoming interim meeting 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, 30 Jan 2012 23:34:22 -0000 I have received a couple of requests to present at the upcoming interim mee= ting. This is intended to be a meeting for energetic discussion of the two topic = areas. This may be aided if people make presentations of their view of the= problem or a particular solution. But as the intent is to have energetic = discussion, presentations will be hard limited in time, both individually a= nd in total. =20 If you would like to have the wg consider a view of the problem, please sen= d email to BOTH CHAIRS. I would like to limit this to no more than 10 minutes per speaker and no mo= re than 4 speakers in each 3.5 hour block. More speakers means less time p= er presentation, fewer speakers means less total time for presentations. --Sandy, speaking as wg co-chair.= From brian.peter.dickson@gmail.com Mon Jan 30 15:57:29 2012 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 735A511E80EA for ; Mon, 30 Jan 2012 15:57:26 -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 iNMvJWRoZQSJ for ; Mon, 30 Jan 2012 15:57:24 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE5D11E80E3 for ; Mon, 30 Jan 2012 15:57:23 -0800 (PST) Received: by werm10 with SMTP id m10so4420216wer.31 for ; Mon, 30 Jan 2012 15:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D2kxEgVxShrCsrQMDGCIMfLTSF5yONIDbUpT/LKSIF4=; b=Gt88gWO3xjT1qVBJnWbVIpD/ndDIMpGfqTQUHLi03RP91yjwx0TjjGTgd78jm7fv7x 0n2aQXl2CdJkdNpM/d3bxN/OebYgszgC8LubGMjUQyBt34IdhUJOQ3/80kfGYdKoFosN a2JdVvtGv3JcLG7T3GzOdT5wMyhn/3B0hFgMc= MIME-Version: 1.0 Received: by 10.216.137.142 with SMTP id y14mr8029358wei.38.1327967842587; Mon, 30 Jan 2012 15:57:22 -0800 (PST) Received: by 10.223.3.15 with HTTP; Mon, 30 Jan 2012 15:57:22 -0800 (PST) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 18:57:22 -0500 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 30 Jan 2012 23:57:29 -0000 On Mon, Jan 30, 2012 at 3:27 PM, Murphy, Sandra wrote: > Speaking as regular ol' member: > > On Monday, January 30, 2012, =A0Brian Dickson said: > >>> Any use of cryptography relies on the protection of the keying material= . =A0The >>> assurance is not that a particular person/entity can do something, but = that the >>> holder of the keying material can do something. > >>Correct. > >>My point was, and is, that _this_ particular design, as has been >>proposed to the WG, >>is what is placing the requirement for private key material, and the >>consequent need >>to protect said material. > > I reiterate my point: any =A0use of cryptography will require that you ar= e careful with > the keying material. > > Do you have any designs in mind that will NOT use cryptography? There are two things to consider here. (1) If I can come up with an example design that does not rely on private keys being kept (let alone exposed) on routers, would that be sufficient to justify exploring more options than just my example? I'm fine with someone else coming up with something better than this, and am not married to the particulars of this. However, it can be considered an "existence proof". (2) Do you accept that an example of such a design is intended to prompt the merits of looking for better designs, rather than the example being fodder for dissection/discussion/bashing? I mean for this to be an "okay, fine, clearly there are alternatives, and we should discuss the high-level pros/cons of on-router crypto and key management". Having said that, here's a simple example (with "simple" being in the eye of the beholder, obviously). Each AS maintains a (for lack of a better term) "database" of its BGP neighbors, and known prefixes. Each AS also maintains a single, global "nonce", which it may periodically change. >From these sets of data and the single nonce, each AS publishes a set of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + neighbor_ASN + nonce) tuples. How/where this gets published doesn't matter, but for example could be in a per-ASN DNSSEC zone. Each router, upon receiving a BGPSEC update, adds to the BGPSEC hash-stack, the calculated SHA hash (of prefix + neighbor_ASN + nonce). Each RP looks up each received _hash_ in the corresponding publication location, to determine the validity of that prefix's ASN_X-ASN_Y path element. The RP does _not_ calculate the hash - it is already there. Publishing the hashes in DNSSEC zones scales reasonably well: - The hash values only need to be generated or updated when policy changes (add/remove ASN neighbors) or the nonce gets changed. Thus, caching works well. - Large nonces ensure no collisions occur, and the zone is not enumerable/searchable. A 1024-bit nonce (just a random number, needn't be prime!) makes it completely impractical to try finding matches. - The relationships between ASNs, in addition to being evident in the AS_PATH (and/or AS4_PATH) are also represented _indirectly_ via the published information. - You have to already know the hash to confirm/deny the relationship, and then only for specific prefixes. - The relationships can be validated, but are not themselves exposed. Only the SHA hash is ever used for the validation itself. - Having a nonce is of little or no value, other than for being able to determine specific ASN neighbor relationships. Validation is yes/no based on looking up the literal value from the BGPSEC field (which happens to be an SHA hash), but the RP does not actually calculate anything, only looks up the value. The router sending the update (which includes the hash) doesn't care about who sent it the prefix - the hash remains the same _regardless_ of from whom it was received. The router sending the update is an RP, and only adds the hash if the validation succeeds (for every hash in the hash stack). Caching pre-validated hashes further optimizes update processing. The bottom line on this scheme is, bad actor B can only attempt to spoof routes, where there are entries chained towards B of actual neighbor relationships, and where the originator of the prefix matches the RPKI. In other words, the worst that can be done is to leak "real" routes. There are other suggestions for addressing route leaks, which when combined with this, locks BGP down quite nicely. NB: - This requires no deployed-on-router crypto of any sort. - There is a need for DNSSEC (and large zones at that), but that is centralized and cached. - Memory on commodity servers is cheap enough to not care, and the stateful nature of this scales even better - Depending on response time requirements, SSDs may handle zone size/cache size issues. - Other than occasionally rolling DNSSEC keys and nonces, there is no need for "beaconing" in this model. - DNSSEC signature expiry can trigger cache refresh, without requiring re-signing or route invalidation. Brian, speaking only for himself. > --Sandy, speaking as regular ol' member > > ________________________________________ > From: Brian Dickson [brian.peter.dickson@gmail.com] > Sent: Monday, January 30, 2012 2:57 PM > To: Murphy, Sandra > Cc: Stephen Kent; sidr@ietf.org list > Subject: Re: [sidr] Key learning procedures in BGPsec? > > On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra > wrote: >> Speaking as a regular ol' wg member: >> >> Brian says: >> >>>If poor key management on W makes it possible for the private keys of >>>a single router in W's network to be learned by B, then all bets are >>>off for anything advertised via W. >> >> Actually, you can stop with "all bets are off". >> >> Any use of cryptography relies on the protection of the keying material.= =A0The >> assurance is not that a particular person/entity can do something, but t= hat the >> holder of the keying material can do something. > > Correct. > > My point was, and is, that _this_ particular design, as has been > proposed to the WG, > is what is placing the requirement for private key material, and the > consequent need > to protect said material. > > Without going into details of alternative designs, it is enough to > point out, IMHO, the distinctions: > > signatures - requires signer to possess private key, > recipient(s)/validators need public key > encryption - requires sender to have the public key(s), and the > recipient(s) need their respective private keys. > > There are other kinds of encryption as well, which involve shared > keys, or in case of DH, random session keys with neither party > having/needing the other's key material. > > What I'm saying is, I don't believe enough attention has been paid to > the private key on the router requirement, or its implications. > > The designers of the protocol really need to justify their choice. It > is not enough to wave hands at this and say, "operational docs will > cover this". > >> So like sharing your password to your bank account means that someone el= se >> can appear as you to the bank, sharing your keys lets someone/something = else >> act as if they were you. =A0That is why key compromise is a serious issu= e. > > This is an apples vs oranges thing. There is an end-to-end encrypted > session (SSL), and there is no requirement for private key > distribution. > > The bank has its SSL private key, which is neither distributed, nor > exposed operationally. Then there's all the L8/L9 stuff related to > record keeping etc. (SOX etc.) > > The primary issue is the creation and exposure of private keys. > If the protocol requires FIPS-140 (to whatever level/degree) to ensure > it does not introduce weakness or risk, that is something that needs > to be addressed. > Or, it may be a non-starter if that is a requirement, but the WG needs > to make an informed decision. > > This isn't the kind of stuff to be taken lightly - it strongly impacts > deployment and operation, and cost of deployment (and/or risks). > >> This is common to anything that uses cryptography. =A0It is not specific= to this >> particular application. =A0Exposing the keys in DNSSEC, exposing the key= s in https, >> exposing the ssh keys, exposing passwords, etc., will all affect the ass= urance >> provided by the cryptography. > > DNSSEC uses effectively out-of-band management for securely > distributing public keys (which is what DS uses). > DNSSEC supports centralized signature models with HSM =A0use being very s= calable. > > SSH also uses distribution of public keys and supports encrypted > storage of private keys (presumably in physically secure local > storage). > > This would be the first major deployment of private keying material in > geographically diverse locations, that I'm aware of, for the protocol > to function as described. > >> I do not see any requirements here that would make that any different th= an any other >> use of cryptography in any other environment, so I do not see any need f= or >> the protocols here to provide solutions. =A0Pointers to operational guid= ance >> elsewhere, where it exists, perhaps. > > I'd say it goes beyond operational guidance, and to the heart of the > protocol design. > > It is not beyond fixing, but IMHO, desperately requires fixing. At > least if it stands a chance of being deployed in the real world. > > Brian (speaking ONLY for myself). > >> --Sandy, speaking as regular ol' member >> >> >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian D= ickson [brian.peter.dickson@gmail.com] >> Sent: Monday, January 30, 2012 1:07 PM >> To: Stephen Kent >> Cc: sidr@ietf.org list >> Subject: Re: [sidr] Key learning procedures in BGPsec? >> >> On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: >>> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>>>> =A0The focus of BGPSEC is improving inter-AS routing security. The op= erator >>>>> of any AS may not do a great job of securing the keys associated with= some >>>>> or all of its routers. Other ASes will not, in general, be able to ev= aluate >>>>> the operational security of an AS. BGPSEC tries to limit the extent t= o which >>>>> an AS =A0can lie about routes that it propagates. Local (within an AS= ) >>>>> security errors or poor practices do not undermine this security feat= ure. >>> A major goal of BGPSEC is to limit the extent to which errors/misbehavi= or by >>> an AS operator, or a successful attack against an AS operator, can adve= rsely >>> affect other ASes (re routing). The RPKI limits the (verifiable) assert= ions >>> that an AS operator can make about the AS that its routers represent, a= nd >>> the prefixes it can originate. >> >>> The BGPSEC per-AS-hop sigs limit the >>> assertions the AS can make re what routes have been advertised to it. >> >> This is a stated goal, but how this achieved or achievable relates >> greatly to key management. >> See below for why I think there are issues with the current protocol >> design vs key management. >> >>> These >>> guarantees still apply whether the operator does a good or poor job of >>> router key management. >> >> I disagree with this assertion. >> >> Let's consider off-axis risks. >> >> Originator O, Relying party R, Weak-operator W, and Bad Actor B. >> >> If poor key management on W makes it possible for the private keys of >> a single router in W's network to be learned by B, then all bets are >> off for anything advertised via W. >> >> Here's why: >> >> Presume all the good stuff you want about O, and the RPKI system. >> Route X, originated by O, is fully validated and legitimate. >> >> Topologically, let's say the following BGPSEC sessions and links exist: >> >> O--?--W--?--R--?--B--? >> >> (All the "?" mean there could be intermediate parties, but none are >> required for this example to still be applicable.) >> >> In order to spoof announcements, B need two things: The private key of >> a single router (such as the key for a W router), and the data that >> would be signed by that router (for X). >> >> However, since anyone receiving route X which was sent from O via W >> _must_ contain that data, it is trivial for B to generate false routes >> for O. >> >> The process would be: >> B sets up a router F ( which claims to be the W router for which the >> key was compromised). >> The (W_fake) router F is configured with ASN =3D=3D W. >> B sets up a BGPSEC session between F and B, and signs the results. >> >> Voila, BGPSEC signed routes received by R, that appear to be: >> >> O--?--W--B--?--R >> >> and this BGPSEC-signed path is fully origin-validatable and fully >> BGPSEC path-validatable. >> >> An error by W, allows B to "pwn" O, without O or R doing anything wrong = at all. >> >> There is no (trivial) way for R (or O) to detect or prevent this kind of= attack. >> >> This shows why one or more of the following things needs to be changed >> in the BGPSEC design: >> (1) key management requirements (not part of the design) >> (2) availability of unencrypted signature-input data to off-axis parties >> (3) ability for a single signature to subvert the validation process >> (4) absolute trust model for signature chains (all/nothing) >> (5) ??? >> >> Brian >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr From brian.peter.dickson@gmail.com Mon Jan 30 16:35:37 2012 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 76B3321F873C for ; Mon, 30 Jan 2012 16:35:37 -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 y4bapRUWRr9x for ; Mon, 30 Jan 2012 16:35:36 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE29D21F873A for ; Mon, 30 Jan 2012 16:35:35 -0800 (PST) Received: by wgbed3 with SMTP id ed3so4356109wgb.13 for ; Mon, 30 Jan 2012 16:35:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=zt+F5gwDKmxF8rbW7eCTw4Uq3U4ZXjy/oBAJe+2mT1Y=; b=JPwTaEfDjWOmAlVLOyDnzMrN3s4fngmxvHO18BtE1A06qxAxXyrHWMhIod3dNeG4hh cLZvj1OfKAXAjzTEsGF1RkBLOcqNV70cVLYFcHdzGKX1byhu8ObZXvZNry+61d2AnIka kTwT1StsIwvcsnZGOEsa5b1+OB2P2I+/pTEgY= MIME-Version: 1.0 Received: by 10.180.106.202 with SMTP id gw10mr324338wib.3.1327970134910; Mon, 30 Jan 2012 16:35:34 -0800 (PST) Received: by 10.223.3.15 with HTTP; Mon, 30 Jan 2012 16:35:34 -0800 (PST) In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 19:35:34 -0500 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 31 Jan 2012 00:35:37 -0000 (The dangers of hitting send before double-checking) On Mon, Jan 30, 2012 at 6:57 PM, Brian Dickson wrote: > On Mon, Jan 30, 2012 at 3:27 PM, Murphy, Sandra > wrote: >> Speaking as regular ol' member: >> >> On Monday, January 30, 2012, =A0Brian Dickson said: >> >>>> Any use of cryptography relies on the protection of the keying materia= l. =A0The >>>> assurance is not that a particular person/entity can do something, but= that the >>>> holder of the keying material can do something. >> >>>Correct. >> >>>My point was, and is, that _this_ particular design, as has been >>>proposed to the WG, >>>is what is placing the requirement for private key material, and the >>>consequent need >>>to protect said material. >> >> I reiterate my point: any =A0use of cryptography will require that you a= re careful with >> the keying material. >> >> Do you have any designs in mind that will NOT use cryptography? > > There are two things to consider here. > > (1) If I can come up with an example design that does not rely on > private keys being kept (let alone exposed) on routers, would that be > sufficient to justify exploring more options than just my example? I'm > fine with someone else coming up with something better than this, and > am not married to the particulars of this. However, it can be > considered an "existence proof". > > (2) Do you accept that an example of such a design is intended to > prompt the merits of looking for better designs, rather than the > example being fodder for dissection/discussion/bashing? I mean for > this to be an "okay, fine, clearly there are alternatives, and we > should discuss the high-level pros/cons of on-router crypto and key > management". > > > > Having said that, here's a simple example (with "simple" being in the > eye of the beholder, obviously). > > Each AS maintains a (for lack of a better term) "database" of its BGP > neighbors, and known prefixes. > > Each AS also maintains a single, global "nonce", which it may > periodically change. > > From these sets of data and the single nonce, each AS publishes a set > of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + > neighbor_ASN + nonce) tuples. ... whose DNS _data_ would consist of the neighbor's ASN and prefix, to complete the validation. It would also be the case that doing this for just ASN path data, without the prefix (as either hash input, or as part of the DNS data) would be equally valid, and a heck of a lot smaller and more efficient. > > How/where this gets published doesn't matter, but for example could be > in a per-ASN DNSSEC zone. > > Each router, upon receiving a BGPSEC update, adds to the BGPSEC > hash-stack, the calculated SHA hash (of prefix + neighbor_ASN + > nonce). > > Each RP looks up each received _hash_ in the corresponding publication > location, to determine the validity of that prefix's ASN_X-ASN_Y path > element. The RP does _not_ calculate the hash - it is already there. > > Publishing the hashes in DNSSEC zones scales reasonably well: > > - The hash values only need to be generated or updated when policy > changes (add/remove ASN neighbors) or the nonce gets changed. Thus, > caching works well. > - Large nonces ensure no collisions occur, and the zone is not > enumerable/searchable. A 1024-bit nonce (just a random number, needn't > be prime!) makes it completely impractical to try finding matches. > - The relationships between ASNs, in addition to being evident in the > AS_PATH (and/or AS4_PATH) are also represented _indirectly_ via the > published information. > - You have to already know the hash to confirm/deny the relationship, > and then only for specific prefixes. > - The relationships can be validated, but are not themselves exposed. > Only the SHA hash is ever used for the validation itself. > - Having a nonce is of little or no value, other than for being able > to determine specific ASN neighbor relationships. > > Validation is yes/no based on looking up the literal value from the > BGPSEC field (which happens to be an SHA hash), but the RP does not > actually calculate anything, only looks up the value. > > The router sending the update (which includes the hash) doesn't care > about who sent it the prefix - the hash remains the same _regardless_ > of from whom it was received. > > The router sending the update is an RP, and only adds the hash if the > validation succeeds (for every hash in the hash stack). Caching > pre-validated hashes further optimizes update processing. > > The bottom line on this scheme is, bad actor B can only attempt to > spoof routes, where there are entries chained towards B of actual > neighbor relationships, and where the originator of the prefix matches > the RPKI. In other words, the worst that can be done is to leak "real" > routes. There are other suggestions for addressing route leaks, which > when combined with this, locks BGP down quite nicely. > > NB: > - This requires no deployed-on-router crypto of any sort. > - There is a need for DNSSEC (and large zones at that), but that is > centralized and cached. > - Memory on commodity servers is cheap enough to not care, and the > stateful nature of this scales even better > - Depending on response time requirements, SSDs may handle zone > size/cache size issues. > - Other than occasionally rolling DNSSEC keys and nonces, there is no > need for "beaconing" in this model. > - DNSSEC signature expiry can trigger cache refresh, without requiring > re-signing or route invalidation. > > Brian, speaking only for himself. > >> --Sandy, speaking as regular ol' member >> >> ________________________________________ >> From: Brian Dickson [brian.peter.dickson@gmail.com] >> Sent: Monday, January 30, 2012 2:57 PM >> To: Murphy, Sandra >> Cc: Stephen Kent; sidr@ietf.org list >> Subject: Re: [sidr] Key learning procedures in BGPsec? >> >> On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra >> wrote: >>> Speaking as a regular ol' wg member: >>> >>> Brian says: >>> >>>>If poor key management on W makes it possible for the private keys of >>>>a single router in W's network to be learned by B, then all bets are >>>>off for anything advertised via W. >>> >>> Actually, you can stop with "all bets are off". >>> >>> Any use of cryptography relies on the protection of the keying material= . =A0The >>> assurance is not that a particular person/entity can do something, but = that the >>> holder of the keying material can do something. >> >> Correct. >> >> My point was, and is, that _this_ particular design, as has been >> proposed to the WG, >> is what is placing the requirement for private key material, and the >> consequent need >> to protect said material. >> >> Without going into details of alternative designs, it is enough to >> point out, IMHO, the distinctions: >> >> signatures - requires signer to possess private key, >> recipient(s)/validators need public key >> encryption - requires sender to have the public key(s), and the >> recipient(s) need their respective private keys. >> >> There are other kinds of encryption as well, which involve shared >> keys, or in case of DH, random session keys with neither party >> having/needing the other's key material. >> >> What I'm saying is, I don't believe enough attention has been paid to >> the private key on the router requirement, or its implications. >> >> The designers of the protocol really need to justify their choice. It >> is not enough to wave hands at this and say, "operational docs will >> cover this". >> >>> So like sharing your password to your bank account means that someone e= lse >>> can appear as you to the bank, sharing your keys lets someone/something= else >>> act as if they were you. =A0That is why key compromise is a serious iss= ue. >> >> This is an apples vs oranges thing. There is an end-to-end encrypted >> session (SSL), and there is no requirement for private key >> distribution. >> >> The bank has its SSL private key, which is neither distributed, nor >> exposed operationally. Then there's all the L8/L9 stuff related to >> record keeping etc. (SOX etc.) >> >> The primary issue is the creation and exposure of private keys. >> If the protocol requires FIPS-140 (to whatever level/degree) to ensure >> it does not introduce weakness or risk, that is something that needs >> to be addressed. >> Or, it may be a non-starter if that is a requirement, but the WG needs >> to make an informed decision. >> >> This isn't the kind of stuff to be taken lightly - it strongly impacts >> deployment and operation, and cost of deployment (and/or risks). >> >>> This is common to anything that uses cryptography. =A0It is not specifi= c to this >>> particular application. =A0Exposing the keys in DNSSEC, exposing the ke= ys in https, >>> exposing the ssh keys, exposing passwords, etc., will all affect the as= surance >>> provided by the cryptography. >> >> DNSSEC uses effectively out-of-band management for securely >> distributing public keys (which is what DS uses). >> DNSSEC supports centralized signature models with HSM =A0use being very = scalable. >> >> SSH also uses distribution of public keys and supports encrypted >> storage of private keys (presumably in physically secure local >> storage). >> >> This would be the first major deployment of private keying material in >> geographically diverse locations, that I'm aware of, for the protocol >> to function as described. >> >>> I do not see any requirements here that would make that any different t= han any other >>> use of cryptography in any other environment, so I do not see any need = for >>> the protocols here to provide solutions. =A0Pointers to operational gui= dance >>> elsewhere, where it exists, perhaps. >> >> I'd say it goes beyond operational guidance, and to the heart of the >> protocol design. >> >> It is not beyond fixing, but IMHO, desperately requires fixing. At >> least if it stands a chance of being deployed in the real world. >> >> Brian (speaking ONLY for myself). >> >>> --Sandy, speaking as regular ol' member >>> >>> >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Brian = Dickson [brian.peter.dickson@gmail.com] >>> Sent: Monday, January 30, 2012 1:07 PM >>> To: Stephen Kent >>> Cc: sidr@ietf.org list >>> Subject: Re: [sidr] Key learning procedures in BGPsec? >>> >>> On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: >>>> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>>>>> =A0The focus of BGPSEC is improving inter-AS routing security. The o= perator >>>>>> of any AS may not do a great job of securing the keys associated wit= h some >>>>>> or all of its routers. Other ASes will not, in general, be able to e= valuate >>>>>> the operational security of an AS. BGPSEC tries to limit the extent = to which >>>>>> an AS =A0can lie about routes that it propagates. Local (within an A= S) >>>>>> security errors or poor practices do not undermine this security fea= ture. >>>> A major goal of BGPSEC is to limit the extent to which errors/misbehav= ior by >>>> an AS operator, or a successful attack against an AS operator, can adv= ersely >>>> affect other ASes (re routing). The RPKI limits the (verifiable) asser= tions >>>> that an AS operator can make about the AS that its routers represent, = and >>>> the prefixes it can originate. >>> >>>> The BGPSEC per-AS-hop sigs limit the >>>> assertions the AS can make re what routes have been advertised to it. >>> >>> This is a stated goal, but how this achieved or achievable relates >>> greatly to key management. >>> See below for why I think there are issues with the current protocol >>> design vs key management. >>> >>>> These >>>> guarantees still apply whether the operator does a good or poor job of >>>> router key management. >>> >>> I disagree with this assertion. >>> >>> Let's consider off-axis risks. >>> >>> Originator O, Relying party R, Weak-operator W, and Bad Actor B. >>> >>> If poor key management on W makes it possible for the private keys of >>> a single router in W's network to be learned by B, then all bets are >>> off for anything advertised via W. >>> >>> Here's why: >>> >>> Presume all the good stuff you want about O, and the RPKI system. >>> Route X, originated by O, is fully validated and legitimate. >>> >>> Topologically, let's say the following BGPSEC sessions and links exist: >>> >>> O--?--W--?--R--?--B--? >>> >>> (All the "?" mean there could be intermediate parties, but none are >>> required for this example to still be applicable.) >>> >>> In order to spoof announcements, B need two things: The private key of >>> a single router (such as the key for a W router), and the data that >>> would be signed by that router (for X). >>> >>> However, since anyone receiving route X which was sent from O via W >>> _must_ contain that data, it is trivial for B to generate false routes >>> for O. >>> >>> The process would be: >>> B sets up a router F ( which claims to be the W router for which the >>> key was compromised). >>> The (W_fake) router F is configured with ASN =3D=3D W. >>> B sets up a BGPSEC session between F and B, and signs the results. >>> >>> Voila, BGPSEC signed routes received by R, that appear to be: >>> >>> O--?--W--B--?--R >>> >>> and this BGPSEC-signed path is fully origin-validatable and fully >>> BGPSEC path-validatable. >>> >>> An error by W, allows B to "pwn" O, without O or R doing anything wrong= at all. >>> >>> There is no (trivial) way for R (or O) to detect or prevent this kind o= f attack. >>> >>> This shows why one or more of the following things needs to be changed >>> in the BGPSEC design: >>> (1) key management requirements (not part of the design) >>> (2) availability of unencrypted signature-input data to off-axis partie= s >>> (3) ability for a single signature to subvert the validation process >>> (4) absolute trust model for signature chains (all/nothing) >>> (5) ??? >>> >>> Brian >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr From aservin@lacnic.net Mon Jan 30 16:57:37 2012 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 0473F21F8493 for ; Mon, 30 Jan 2012 16:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Vyn2vJl-3xVe for ; Mon, 30 Jan 2012 16:57:36 -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 6C5BA21F848F for ; Mon, 30 Jan 2012 16:57:36 -0800 (PST) Received: from [192.168.1.100] (r186-48-197-3.dialup.adsl.anteldata.net.uy [186.48.197.3]) by mail.lacnic.net.uy (Postfix) with ESMTP id 0FB00308446; Mon, 30 Jan 2012 22:57:20 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F6077A0F@Hermes.columbia.ads.sparta.com> Date: Mon, 30 Jan 2012 22:57:19 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F6077A0F@Hermes.columbia.ads.sparta.com> To: "Murphy, Sandra" X-Mailer: Apple Mail (2.1084) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "sidr@ietf.org" Subject: Re: [sidr] agenda for upcoming interim meeting 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, 31 Jan 2012 00:57:37 -0000 Is going to be any kind of remote participation (jabber, audio, = etc.)? Thanks, -as On 30 Jan 2012, at 21:34, Murphy, Sandra wrote: > I have received a couple of requests to present at the upcoming = interim meeting. >=20 > This is intended to be a meeting for energetic discussion of the two = topic areas. This may be aided if people make presentations of their = view of the problem or a particular solution. But as the intent is to = have energetic discussion, presentations will be hard limited in time, = both individually and in total. =20 >=20 > If you would like to have the wg consider a view of the problem, = please send email to BOTH CHAIRS. >=20 > I would like to limit this to no more than 10 minutes per speaker and = no more than 4 speakers in each 3.5 hour block. More speakers means = less time per presentation, fewer speakers means less total time for = presentations. >=20 > --Sandy, speaking as wg co-chair. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rossjanderson@googlemail.com Tue Jan 31 00:06:02 2012 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 A312D21F877A for ; Tue, 31 Jan 2012 00:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrgC1YlpzaBj for ; Tue, 31 Jan 2012 00:06:00 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2721F8764 for ; Tue, 31 Jan 2012 00:06:00 -0800 (PST) Received: by iagf6 with SMTP id f6so7852460iag.31 for ; Tue, 31 Jan 2012 00:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tDtgF72BQDmOKGwGhTEehQjruQXM6k+1RcZVTAZ5r/8=; b=ferYqUi4pSaj7QqkgdAhwYMm7VSeHJsxQ3iW86QBFBpkw8VgpoAFIxCArxi7vwKKFw XgMbvU52CFQiWAZj/4heLYaCBlvEzGyCZlAQT7TAAEZjkWtJhvCXYZpJJdQ4fl+u5Ml5 ZnRwk+Cnnqat2GRs0zrNAjGXqqlAXs9Sng1uU= MIME-Version: 1.0 Received: by 10.42.146.202 with SMTP id k10mr17048907icv.13.1327997158762; Tue, 31 Jan 2012 00:05:58 -0800 (PST) Received: by 10.50.163.106 with HTTP; Tue, 31 Jan 2012 00:05:58 -0800 (PST) In-Reply-To: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> Date: Tue, 31 Jan 2012 08:05:58 +0000 Message-ID: From: "Ross.Anderson@cl.cam.ac.uk" To: "sidr@ietf.org list" Content-Type: multipart/alternative; boundary=90e6ba6e8e9ce9285f04b7ce6e97 Cc: "Murphy, Sandra" Subject: Re: [sidr] Key learning procedures in BGPsec? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ross.Anderson@cl.cam.ac.uk List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 08:14:08 -0000 --90e6ba6e8e9ce9285f04b7ce6e97 Content-Type: text/plain; charset=ISO-8859-1 Brian (delurk) As a recovering cryptographer I can think of nits to pick but it's certainly possible to build a robust system using hash chains and hash trees rather than conventional signatures. Declaration of interest: I started this field of study 15 years ago with a paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig and others and turned into systems (TESLA etc) for authenticating digital streams using hash chains. If you want to authenticate a large number of messages from Alice to Bob that all arrive in order then hash chains are great. Here's how it might work. You have a conventional mechanism for initial key setup between routers (maybe a route reflector doing public-key crypto, maybe DNSSEC). Then each router sets up a hash chain with each peer and uses hashes to authenticate routine updates. Steve Kent will point out that routers do in effect have key material, in the sense of not-yet-published hash preimages, and this is almost equivalent to using symmetric keys for MACs (not quite, as you can get some nonrepudiation from hash chains). But having local symmetric keys (or short-lived signature keys) managed by per-AS route reflectors, perhaps with HSMs for the bigger players, is in any case a good strategy to get resilience in the face of occasional compromise. So it might well be worth trying to explore the design options in more detail. The authentication mechanisms had better be cheap and resilient if we want this thing deployed Ross Anderson www.ross-anderson.com On 30 January 2012 23:57, Brian Dickson wrote: > > > Do you have any designs in mind that will NOT use cryptography? > > There are two things to consider here. > > (1) If I can come up with an example design that does not rely on > private keys being kept (let alone exposed) on routers, would that be > sufficient to justify exploring more options than just my example? I'm > fine with someone else coming up with something better than this, and > am not married to the particulars of this. However, it can be > considered an "existence proof". > > (2) Do you accept that an example of such a design is intended to > prompt the merits of looking for better designs, rather than the > example being fodder for dissection/discussion/bashing? I mean for > this to be an "okay, fine, clearly there are alternatives, and we > should discuss the high-level pros/cons of on-router crypto and key > management". > > > > Having said that, here's a simple example (with "simple" being in the > eye of the beholder, obviously). > > Each AS maintains a (for lack of a better term) "database" of its BGP > neighbors, and known prefixes. > > Each AS also maintains a single, global "nonce", which it may > periodically change. > > From these sets of data and the single nonce, each AS publishes a set > of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + > neighbor_ASN + nonce) tuples. > > --90e6ba6e8e9ce9285f04b7ce6e97 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Brian

(delurk) As a recovering cryptographer I can think of nits to = pick but it's certainly possible to build a robust system using hash ch= ains and hash trees rather than conventional signatures.

Declaration= of interest: I started this field of study 15 years ago with a paper on th= e Guy Fawkes protocol. This was then taken up by Adrian Perrig and others a= nd turned into systems (TESLA etc) for authenticating digital streams using= hash chains. If you want to authenticate a large number of messages from A= lice to Bob that all arrive in order then hash chains are great.

Here's how it might work. You have a conventional mechanism for ini= tial key setup between routers (maybe a route reflector doing public-key cr= ypto, maybe DNSSEC). Then each router sets up a hash chain with each peer a= nd uses hashes to authenticate routine updates.

Steve Kent will point out that routers do in effect have key material, = in the sense of not-yet-published hash preimages, and this is almost equiva= lent to using symmetric keys for MACs (not quite, as you can get some nonre= pudiation from hash chains). But having local symmetric keys (or short-live= d signature keys) managed by per-AS route reflectors, perhaps with HSMs for= the bigger players, is in any case a good strategy to get resilience in th= e face of occasional compromise.

So it might well be worth trying to explore the design options in more = detail. The authentication mechanisms had better be cheap and resilient if = we want this thing deployed

Ross Anderson
www.ross-anderson.com


On 30 January 2012 23:57, Brian Dickson = <bria= n.peter.dickson@gmail.com> wrote:

> Do you have any designs in mind that will NOT use cryptography?

There are two things to consider here.

(1) If I can come up with an example design that does not rely on
private keys being kept (let alone exposed) on routers, would that be
sufficient to justify exploring more options than just my example? I'm<= br> fine with someone else coming up with something better than this, and
am not married to the particulars of this. However, it can be
considered an "existence proof".

(2) Do you accept that an example of such a design is intended to
prompt the merits of looking for better designs, rather than the
example being fodder for dissection/discussion/bashing? I mean for
this to be an "okay, fine, clearly there are alternatives, and we
should discuss the high-level pros/cons of on-router crypto and key
management".



Having said that, here's a simple example (with "simple" bein= g in the
eye of the beholder, obviously).

Each AS maintains a (for lack of a better term) "database" of its= BGP
neighbors, and known prefixes.

Each AS also maintains a single, global "nonce", which it may
periodically change.

>From these sets of data and the single nonce, each AS publishes a set
of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix +
neighbor_ASN + nonce) tuples.

--90e6ba6e8e9ce9285f04b7ce6e97-- From rbarnes@bbn.com Tue Jan 31 01:36:54 2012 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 C609F21F875A for ; Tue, 31 Jan 2012 01:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.422 X-Spam-Level: X-Spam-Status: No, score=-106.422 tagged_above=-999 required=5 tests=[AWL=0.177, 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 TKc6OAYmhHhv for ; Tue, 31 Jan 2012 01:36:53 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9A48821F86B4 for ; Tue, 31 Jan 2012 01:36:52 -0800 (PST) Received: from [128.89.253.193] (port=51818) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RsA8w-000LlC-ED; Tue, 31 Jan 2012 04:36:50 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Richard Barnes In-Reply-To: Date: Tue, 31 Jan 2012 10:36:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> To: Brian Dickson X-Mailer: Apple Mail (2.1251.1) Cc: "Murphy, Sandra" , "sidr@ietf.org list" Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 31 Jan 2012 09:36:54 -0000 "As simple as possible, and no simpler" Your proposal is basically BGPSEC with MACs instead of digital = signatures. That doesn't work because another AS on the Internet can, = e.g., poison a route by appending hashes computed with another AS's = nonce. The critical security feature of this system is that resource holders = can only make statements about themselves. In order for that to be the = case, you really do need asymmetric cryptography: digital signatures vs. = MACs/hashes. Otherwise, in order for the world to be able to validate = MACs, the MAC key needs to be published (the "nonce" in your example), = which means that other entities can then generate valid MACs -- making = statements about entities other than themselves. --Richard On Jan 31, 2012, at 12:57 AM, Brian Dickson wrote: > On Mon, Jan 30, 2012 at 3:27 PM, Murphy, Sandra > wrote: >> Speaking as regular ol' member: >>=20 >> On Monday, January 30, 2012, Brian Dickson said: >>=20 >>>> Any use of cryptography relies on the protection of the keying = material. The >>>> assurance is not that a particular person/entity can do something, = but that the >>>> holder of the keying material can do something. >>=20 >>> Correct. >>=20 >>> My point was, and is, that _this_ particular design, as has been >>> proposed to the WG, >>> is what is placing the requirement for private key material, and the >>> consequent need >>> to protect said material. >>=20 >> I reiterate my point: any use of cryptography will require that you = are careful with >> the keying material. >>=20 >> Do you have any designs in mind that will NOT use cryptography? >=20 > There are two things to consider here. >=20 > (1) If I can come up with an example design that does not rely on > private keys being kept (let alone exposed) on routers, would that be > sufficient to justify exploring more options than just my example? I'm > fine with someone else coming up with something better than this, and > am not married to the particulars of this. However, it can be > considered an "existence proof". >=20 > (2) Do you accept that an example of such a design is intended to > prompt the merits of looking for better designs, rather than the > example being fodder for dissection/discussion/bashing? I mean for > this to be an "okay, fine, clearly there are alternatives, and we > should discuss the high-level pros/cons of on-router crypto and key > management". >=20 >=20 >=20 > Having said that, here's a simple example (with "simple" being in the > eye of the beholder, obviously). >=20 > Each AS maintains a (for lack of a better term) "database" of its BGP > neighbors, and known prefixes. >=20 > Each AS also maintains a single, global "nonce", which it may > periodically change. >=20 > =46rom these sets of data and the single nonce, each AS publishes a = set > of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + > neighbor_ASN + nonce) tuples. >=20 > How/where this gets published doesn't matter, but for example could be > in a per-ASN DNSSEC zone. >=20 > Each router, upon receiving a BGPSEC update, adds to the BGPSEC > hash-stack, the calculated SHA hash (of prefix + neighbor_ASN + > nonce). >=20 > Each RP looks up each received _hash_ in the corresponding publication > location, to determine the validity of that prefix's ASN_X-ASN_Y path > element. The RP does _not_ calculate the hash - it is already there. >=20 > Publishing the hashes in DNSSEC zones scales reasonably well: >=20 > - The hash values only need to be generated or updated when policy > changes (add/remove ASN neighbors) or the nonce gets changed. Thus, > caching works well. > - Large nonces ensure no collisions occur, and the zone is not > enumerable/searchable. A 1024-bit nonce (just a random number, needn't > be prime!) makes it completely impractical to try finding matches. > - The relationships between ASNs, in addition to being evident in the > AS_PATH (and/or AS4_PATH) are also represented _indirectly_ via the > published information. > - You have to already know the hash to confirm/deny the relationship, > and then only for specific prefixes. > - The relationships can be validated, but are not themselves exposed. > Only the SHA hash is ever used for the validation itself. > - Having a nonce is of little or no value, other than for being able > to determine specific ASN neighbor relationships. >=20 > Validation is yes/no based on looking up the literal value from the > BGPSEC field (which happens to be an SHA hash), but the RP does not > actually calculate anything, only looks up the value. >=20 > The router sending the update (which includes the hash) doesn't care > about who sent it the prefix - the hash remains the same _regardless_ > of from whom it was received. >=20 > The router sending the update is an RP, and only adds the hash if the > validation succeeds (for every hash in the hash stack). Caching > pre-validated hashes further optimizes update processing. >=20 > The bottom line on this scheme is, bad actor B can only attempt to > spoof routes, where there are entries chained towards B of actual > neighbor relationships, and where the originator of the prefix matches > the RPKI. In other words, the worst that can be done is to leak "real" > routes. There are other suggestions for addressing route leaks, which > when combined with this, locks BGP down quite nicely. >=20 > NB: > - This requires no deployed-on-router crypto of any sort. > - There is a need for DNSSEC (and large zones at that), but that is > centralized and cached. > - Memory on commodity servers is cheap enough to not care, and the > stateful nature of this scales even better > - Depending on response time requirements, SSDs may handle zone > size/cache size issues. > - Other than occasionally rolling DNSSEC keys and nonces, there is no > need for "beaconing" in this model. > - DNSSEC signature expiry can trigger cache refresh, without requiring > re-signing or route invalidation. >=20 > Brian, speaking only for himself. >=20 >> --Sandy, speaking as regular ol' member >>=20 >> ________________________________________ >> From: Brian Dickson [brian.peter.dickson@gmail.com] >> Sent: Monday, January 30, 2012 2:57 PM >> To: Murphy, Sandra >> Cc: Stephen Kent; sidr@ietf.org list >> Subject: Re: [sidr] Key learning procedures in BGPsec? >>=20 >> On Mon, Jan 30, 2012 at 2:32 PM, Murphy, Sandra >> wrote: >>> Speaking as a regular ol' wg member: >>>=20 >>> Brian says: >>>=20 >>>> If poor key management on W makes it possible for the private keys = of >>>> a single router in W's network to be learned by B, then all bets = are >>>> off for anything advertised via W. >>>=20 >>> Actually, you can stop with "all bets are off". >>>=20 >>> Any use of cryptography relies on the protection of the keying = material. The >>> assurance is not that a particular person/entity can do something, = but that the >>> holder of the keying material can do something. >>=20 >> Correct. >>=20 >> My point was, and is, that _this_ particular design, as has been >> proposed to the WG, >> is what is placing the requirement for private key material, and the >> consequent need >> to protect said material. >>=20 >> Without going into details of alternative designs, it is enough to >> point out, IMHO, the distinctions: >>=20 >> signatures - requires signer to possess private key, >> recipient(s)/validators need public key >> encryption - requires sender to have the public key(s), and the >> recipient(s) need their respective private keys. >>=20 >> There are other kinds of encryption as well, which involve shared >> keys, or in case of DH, random session keys with neither party >> having/needing the other's key material. >>=20 >> What I'm saying is, I don't believe enough attention has been paid to >> the private key on the router requirement, or its implications. >>=20 >> The designers of the protocol really need to justify their choice. It >> is not enough to wave hands at this and say, "operational docs will >> cover this". >>=20 >>> So like sharing your password to your bank account means that = someone else >>> can appear as you to the bank, sharing your keys lets = someone/something else >>> act as if they were you. That is why key compromise is a serious = issue. >>=20 >> This is an apples vs oranges thing. There is an end-to-end encrypted >> session (SSL), and there is no requirement for private key >> distribution. >>=20 >> The bank has its SSL private key, which is neither distributed, nor >> exposed operationally. Then there's all the L8/L9 stuff related to >> record keeping etc. (SOX etc.) >>=20 >> The primary issue is the creation and exposure of private keys. >> If the protocol requires FIPS-140 (to whatever level/degree) to = ensure >> it does not introduce weakness or risk, that is something that needs >> to be addressed. >> Or, it may be a non-starter if that is a requirement, but the WG = needs >> to make an informed decision. >>=20 >> This isn't the kind of stuff to be taken lightly - it strongly = impacts >> deployment and operation, and cost of deployment (and/or risks). >>=20 >>> This is common to anything that uses cryptography. It is not = specific to this >>> particular application. Exposing the keys in DNSSEC, exposing the = keys in https, >>> exposing the ssh keys, exposing passwords, etc., will all affect the = assurance >>> provided by the cryptography. >>=20 >> DNSSEC uses effectively out-of-band management for securely >> distributing public keys (which is what DS uses). >> DNSSEC supports centralized signature models with HSM use being very = scalable. >>=20 >> SSH also uses distribution of public keys and supports encrypted >> storage of private keys (presumably in physically secure local >> storage). >>=20 >> This would be the first major deployment of private keying material = in >> geographically diverse locations, that I'm aware of, for the protocol >> to function as described. >>=20 >>> I do not see any requirements here that would make that any = different than any other >>> use of cryptography in any other environment, so I do not see any = need for >>> the protocols here to provide solutions. Pointers to operational = guidance >>> elsewhere, where it exists, perhaps. >>=20 >> I'd say it goes beyond operational guidance, and to the heart of the >> protocol design. >>=20 >> It is not beyond fixing, but IMHO, desperately requires fixing. At >> least if it stands a chance of being deployed in the real world. >>=20 >> Brian (speaking ONLY for myself). >>=20 >>> --Sandy, speaking as regular ol' member >>>=20 >>>=20 >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Brian Dickson [brian.peter.dickson@gmail.com] >>> Sent: Monday, January 30, 2012 1:07 PM >>> To: Stephen Kent >>> Cc: sidr@ietf.org list >>> Subject: Re: [sidr] Key learning procedures in BGPsec? >>>=20 >>> On Mon, Jan 30, 2012 at 10:57 AM, Stephen Kent wrote: >>>> At 1:43 PM -0500 1/24/12, Eric Osterweil wrote: >>>>>> The focus of BGPSEC is improving inter-AS routing security. The = operator >>>>>> of any AS may not do a great job of securing the keys associated = with some >>>>>> or all of its routers. Other ASes will not, in general, be able = to evaluate >>>>>> the operational security of an AS. BGPSEC tries to limit the = extent to which >>>>>> an AS can lie about routes that it propagates. Local (within an = AS) >>>>>> security errors or poor practices do not undermine this security = feature. >>>> A major goal of BGPSEC is to limit the extent to which = errors/misbehavior by >>>> an AS operator, or a successful attack against an AS operator, can = adversely >>>> affect other ASes (re routing). The RPKI limits the (verifiable) = assertions >>>> that an AS operator can make about the AS that its routers = represent, and >>>> the prefixes it can originate. >>>=20 >>>> The BGPSEC per-AS-hop sigs limit the >>>> assertions the AS can make re what routes have been advertised to = it. >>>=20 >>> This is a stated goal, but how this achieved or achievable relates >>> greatly to key management. >>> See below for why I think there are issues with the current protocol >>> design vs key management. >>>=20 >>>> These >>>> guarantees still apply whether the operator does a good or poor job = of >>>> router key management. >>>=20 >>> I disagree with this assertion. >>>=20 >>> Let's consider off-axis risks. >>>=20 >>> Originator O, Relying party R, Weak-operator W, and Bad Actor B. >>>=20 >>> If poor key management on W makes it possible for the private keys = of >>> a single router in W's network to be learned by B, then all bets are >>> off for anything advertised via W. >>>=20 >>> Here's why: >>>=20 >>> Presume all the good stuff you want about O, and the RPKI system. >>> Route X, originated by O, is fully validated and legitimate. >>>=20 >>> Topologically, let's say the following BGPSEC sessions and links = exist: >>>=20 >>> O--?--W--?--R--?--B--? >>>=20 >>> (All the "?" mean there could be intermediate parties, but none are >>> required for this example to still be applicable.) >>>=20 >>> In order to spoof announcements, B need two things: The private key = of >>> a single router (such as the key for a W router), and the data that >>> would be signed by that router (for X). >>>=20 >>> However, since anyone receiving route X which was sent from O via W >>> _must_ contain that data, it is trivial for B to generate false = routes >>> for O. >>>=20 >>> The process would be: >>> B sets up a router F ( which claims to be the W router for which the >>> key was compromised). >>> The (W_fake) router F is configured with ASN =3D=3D W. >>> B sets up a BGPSEC session between F and B, and signs the results. >>>=20 >>> Voila, BGPSEC signed routes received by R, that appear to be: >>>=20 >>> O--?--W--B--?--R >>>=20 >>> and this BGPSEC-signed path is fully origin-validatable and fully >>> BGPSEC path-validatable. >>>=20 >>> An error by W, allows B to "pwn" O, without O or R doing anything = wrong at all. >>>=20 >>> There is no (trivial) way for R (or O) to detect or prevent this = kind of attack. >>>=20 >>> This shows why one or more of the following things needs to be = changed >>> in the BGPSEC design: >>> (1) key management requirements (not part of the design) >>> (2) availability of unencrypted signature-input data to off-axis = parties >>> (3) ability for a single signature to subvert the validation process >>> (4) absolute trust model for signature chains (all/nothing) >>> (5) ??? >>>=20 >>> Brian >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From rja14@cl.cam.ac.uk Tue Jan 31 02:06:47 2012 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 3D84A21F865D for ; Tue, 31 Jan 2012 02:06:47 -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 2cP8Zba-J1jO for ; Tue, 31 Jan 2012 02:06:46 -0800 (PST) Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [128.232.25.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7FBC21F8655 for ; Tue, 31 Jan 2012 02:06:45 -0800 (PST) Received: from ssh-remote-0.cl.cam.ac.uk ([128.232.0.69] helo=cl.cam.ac.uk) by mta0.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1RsAbs-0008Hb-Ao for sidr@ietf.org; Tue, 31 Jan 2012 10:06:44 +0000 To: sidr@ietf.org Date: Tue, 31 Jan 2012 10:06:44 +0000 From: Ross Anderson Message-Id: Subject: [sidr] Key learning procedures in BGPsec? 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, 31 Jan 2012 10:15:23 -0000 Richard You can get nonrepudiation from hash chains. See http://www.ietf.org/rfc/rfc4082.txt http://www.cl.cam.ac.uk/~rja14/Papers/fawkes.pdf Ross On 31 January 2012 09:36, Richard Barnes wrote: > "As simple as possible, and no simpler" > > Your proposal is basically BGPSEC with MACs instead of digital > signatures. That doesn't work because another AS on the Internet can, > e.g., poison a route by appending hashes computed with another AS's > nonce. From Sandra.Murphy@sparta.com Tue Jan 31 07:04:03 2012 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 4243721F85E1 for ; Tue, 31 Jan 2012 07:04:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 KRMQLF5krNWx for ; Tue, 31 Jan 2012 07:04:02 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4221F85DA for ; Tue, 31 Jan 2012 07:04:02 -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 q0VF4100009484; Tue, 31 Jan 2012 09:04:01 -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 q0VF41Pf014640; Tue, 31 Jan 2012 09:04:01 -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.0355.002; Tue, 31 Jan 2012 10:04:00 -0500 From: "Murphy, Sandra" To: Arturo Servin Thread-Topic: [sidr] agenda for upcoming interim meeting Thread-Index: AczfpQIdiVQXmcg+Qh++L5mrnG2CqgAOC7mAABLzls8= Date: Tue, 31 Jan 2012 15:03:59 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6077B2B@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F6077A0F@Hermes.columbia.ads.sparta.com>, 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 Cc: "sidr@ietf.org" Subject: Re: [sidr] agenda for upcoming interim meeting 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, 31 Jan 2012 15:04:03 -0000 I am working with the Secretariat to provide a WebEx session. We will do j= abber (when and if we find a volunteer). A conference phone is arranged. --Sandy, speaking as wg co-chair ________________________________________ From: Arturo Servin [aservin@lacnic.net] Sent: Monday, January 30, 2012 7:57 PM To: Murphy, Sandra Cc: sidr@ietf.org Subject: Re: [sidr] agenda for upcoming interim meeting Is going to be any kind of remote participation (jabber, audio, etc= .)? Thanks, -as On 30 Jan 2012, at 21:34, Murphy, Sandra wrote: > I have received a couple of requests to present at the upcoming interim m= eeting. > > This is intended to be a meeting for energetic discussion of the two topi= c areas. This may be aided if people make presentations of their view of t= he problem or a particular solution. But as the intent is to have energeti= c discussion, presentations will be hard limited in time, both individually= and in total. > > If you would like to have the wg consider a view of the problem, please s= end email to BOTH CHAIRS. > > I would like to limit this to no more than 10 minutes per speaker and no = more than 4 speakers in each 3.5 hour block. More speakers means less time= per presentation, fewer speakers means less total time for presentations. > > --Sandy, speaking as wg co-chair. > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr= From Sandra.Murphy@sparta.com Tue Jan 31 07:06:33 2012 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 DDD0F21F8566 for ; Tue, 31 Jan 2012 07:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyXXgtIe886c for ; Tue, 31 Jan 2012 07:06:33 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id AC8C321F85F0 for ; Tue, 31 Jan 2012 07:06:32 -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 q0VF6O4M009505; Tue, 31 Jan 2012 09:06:24 -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 q0VF6LmI014746; Tue, 31 Jan 2012 09:06:23 -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.0355.002; Tue, 31 Jan 2012 10:06:20 -0500 From: "Murphy, Sandra" To: "Ross.Anderson@cl.cam.ac.uk" , "sidr@ietf.org list" Thread-Topic: [sidr] Key learning procedures in BGPsec? Thread-Index: AQHM33oIuc3Eip6I+kepCBOaAHZARZYlRm6qgABhNYD//7BhKoAAkqoAgACIgwCAABqHrw== Date: Tue, 31 Jan 2012 15:06:19 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6077B1C@Hermes.columbia.ads.sparta.com> References: <13269421-8A36-4628-9F1A-30E02B922AE1@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6074CA8@Hermes.columbia.ads.sparta.com> <12C07EA1-EDC5-4F88-99F7-B57B9AF53C53@verisign.com> <79053E60-25FE-4A84-9391-F451C8F0E720@verisign.com> <24B20D14B2CD29478C8D5D6E9CBB29F6077830@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60778DE@Hermes.columbia.ads.sparta.com> , 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: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F6077B1CHermescolumbiaads_" MIME-Version: 1.0 Subject: Re: [sidr] Key learning procedures in BGPsec? 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, 31 Jan 2012 15:06:34 -0000 --_000_24B20D14B2CD29478C8D5D6E9CBB29F6077B1CHermescolumbiaads_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as regular ol' member On Tuesday, January 31, 2012, Ross.Anderson said: >If you want to authenticate a large number of messages from Alice to Bob t= hat >all arrive in order then hash chains are great. That is not what we are looking for in the sidr work. Authenticating the stream of messages between two adjacent routers is not the sidr focus. Furthermore, there are solutions in hand (TCP AO, IPSEC, pt-pt physical protections, etc.). The sidr work is creating protections for the path - the AS_PATH attribute that is modified by each AS in the path of propagation of the BGP update. A sends an update to B, who adds itsself to the AS_PATH and sends to C, who adds itself and send the update to D, who.... The protections ensure that a recipient can look at an AS_PATH that shows A, B, C, D, ... and know that the update did in fact pass through those sys= tems. And "in order" becomes a more complex idea as well. -Sandy, speaking as regular ol' member ________________________________ From: Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com] Sent: Tuesday, January 31, 2012 3:05 AM To: sidr@ietf.org list Cc: Murphy, Sandra; Brian Dickson Subject: Re: [sidr] Key learning procedures in BGPsec? Brian (delurk) As a recovering cryptographer I can think of nits to pick but it's= certainly possible to build a robust system using hash chains and hash tre= es rather than conventional signatures. Declaration of interest: I started this field of study 15 years ago with a = paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig a= nd others and turned into systems (TESLA etc) for authenticating digital st= reams using hash chains. If you want to authenticate a large number of mess= ages from Alice to Bob that all arrive in order then hash chains are great. Here's how it might work. You have a conventional mechanism for initial key= setup between routers (maybe a route reflector doing public-key crypto, ma= ybe DNSSEC). Then each router sets up a hash chain with each peer and uses = hashes to authenticate routine updates. Steve Kent will point out that routers do in effect have key material, in t= he sense of not-yet-published hash preimages, and this is almost equivalent= to using symmetric keys for MACs (not quite, as you can get some nonrepudi= ation from hash chains). But having local symmetric keys (or short-lived si= gnature keys) managed by per-AS route reflectors, perhaps with HSMs for the= bigger players, is in any case a good strategy to get resilience in the fa= ce of occasional compromise. So it might well be worth trying to explore the design options in more deta= il. The authentication mechanisms had better be cheap and resilient if we w= ant this thing deployed Ross Anderson www.ross-anderson.com On 30 January 2012 23:57, Brian Dickson > wrote: > Do you have any designs in mind that will NOT use cryptography? There are two things to consider here. (1) If I can come up with an example design that does not rely on private keys being kept (let alone exposed) on routers, would that be sufficient to justify exploring more options than just my example? I'm fine with someone else coming up with something better than this, and am not married to the particulars of this. However, it can be considered an "existence proof". (2) Do you accept that an example of such a design is intended to prompt the merits of looking for better designs, rather than the example being fodder for dissection/discussion/bashing? I mean for this to be an "okay, fine, clearly there are alternatives, and we should discuss the high-level pros/cons of on-router crypto and key management". Having said that, here's a simple example (with "simple" being in the eye of the beholder, obviously). Each AS maintains a (for lack of a better term) "database" of its BGP neighbors, and known prefixes. Each AS also maintains a single, global "nonce", which it may periodically change. >From these sets of data and the single nonce, each AS publishes a set of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + neighbor_ASN + nonce) tuples. --_000_24B20D14B2CD29478C8D5D6E9CBB29F6077B1CHermescolumbiaads_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Speaking as regular ol' member

 

On  Tuesday, January 31, 2012, Ross.Anderson = said:

 

>If you want to authenticate a large number of messages from Alice to= Bob that

>all arrive in order then hash chains are great.

That is not what we are looking for in the sidr work.

 

Authenticating the stream of messages between two adjacent routers is no= t

the sidr focus.  Furthermore, there are solutions in hand= (TCP AO, IPSEC,

pt-pt physical protections, etc.).

 

The sidr work is creating protections for the path - the AS_PATH attribu= te

that is modified by each AS in the path of propagation of the BGP update= .

 

A sends an update to B, who adds itsself to the AS_PATH and sends to C,<= /p>

who adds itself and send the update to D, who....

 

The protections ensure that a recipient can look at an AS_PATH that show= s

A, B, C, D, ... and know that the update did in fact pass thro= ugh those systems.

 

And "in order" becomes a more complex idea as well.

 

-Sandy, speaking as regular ol' member


 

From: Ross.Anderson@cl.cam.ac.uk [rossjand= erson@googlemail.com]
Sent: Tuesday, January 31, 2012 3:05 AM
To: sidr@ietf.org list
Cc: Murphy, Sandra; Brian Dickson
Subject: Re: [sidr] Key learning procedures in BGPsec?

Brian

(delurk) As a recovering cryptographer I can think of nits to pick but it's= certainly possible to build a robust system using hash chains and hash tre= es rather than conventional signatures.

Declaration of interest: I started this field of study 15 years ago with a = paper on the Guy Fawkes protocol. This was then taken up by Adrian Perrig a= nd others and turned into systems (TESLA etc) for authenticating digital st= reams using hash chains. If you want to authenticate a large number of messages from Alice to Bob that all= arrive in order then hash chains are great.

Here's how it might work. You have a conventional mechanism for initial key= setup between routers (maybe a route reflector doing public-key crypto, ma= ybe DNSSEC). Then each router sets up a hash chain with each peer and uses = hashes to authenticate routine updates.

Steve Kent will point out that routers do in effect have key material, in t= he sense of not-yet-published hash preimages, and this is almost equivalent= to using symmetric keys for MACs (not quite, as you can get some nonrepudi= ation from hash chains). But having local symmetric keys (or short-lived signature keys) managed by per-AS rou= te reflectors, perhaps with HSMs for the bigger players, is in any case a g= ood strategy to get resilience in the face of occasional compromise.

So it might well be worth trying to explore the design options in more deta= il. The authentication mechanisms had better be cheap and resilient if we w= ant this thing deployed

Ross Anderson
www.ross-anderso= n.com


On 30 January 2012 23:57, Brian Dickson <bria= n.peter.dickson@gmail.com> wrote:

> Do you have any designs in mind that will NOT use cryptography?

There are two things to consider here.

(1) If I can come up with an example design that does not rely on
private keys being kept (let alone exposed) on routers, would that be
sufficient to justify exploring more options than just my example? I'm
fine with someone else coming up with something better than this, and
am not married to the particulars of this. However, it can be
considered an "existence proof".

(2) Do you accept that an example of such a design is intended to
prompt the merits of looking for better designs, rather than the
example being fodder for dissection/discussion/bashing? I mean for
this to be an "okay, fine, clearly there are alternatives, and we
should discuss the high-level pros/cons of on-router crypto and key
management".



Having said that, here's a simple example (with "simple" being in= the
eye of the beholder, obviously).

Each AS maintains a (for lack of a better term) "database" of its= BGP
neighbors, and known prefixes.

Each AS also maintains a single, global "nonce", which it may
periodically change.

>From these sets of data and the single nonce, each AS publishes a set
of SHA-256 hashes (or other SHA hash, as appropriate), over (prefix + neighbor_ASN + nonce) tuples.

--_000_24B20D14B2CD29478C8D5D6E9CBB29F6077B1CHermescolumbiaads_--