Re: [sidr] two stranded docuemnts - stake time

Di, enjoy. You have my permission to take over SLURM. Let me know if there's anything I can do to help. On 07/22/2016 05:48 AM, Declan Ma wrote: > Sandy & Chris, > > Thank Steve for recommending me to take over SLURM. > > With David’s permission, I would be happy to assume responsibility for SL

Re: [sidr] I-D Action: draft-ietf-sidr-slurm-01.txt

Routing of the IETF. Title : Simplified Local internet nUmber Resource Management with the RPKI Author : David Mandelberg Filename: draft-ietf-sidr-slurm-01.txt Pages : 11 Date: 2016-04-13 Abstract: The

Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-algs-12.txt

Thanks, this addresses all the (minor) comments I sent off-list during WGLC. And since I realized I hadn't remembered to publicly support this, I'll do so now: it looks good to me. On 2015-11-02 21:07, Sean Turner wrote: Incorporates comments received during WGLC. Willing to be shouted down o

Re: [sidr] preventing SKI collisions

On 2015-09-16 10:38, Sean Turner wrote: Okay so I think we’re in agreement here that we don’t work on #3 now, but I’m also thinking that we should leave #1 and #2 alone for now. If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then it sounds like it's also good enough for BGPsec.

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

On 2015-09-10 15:09, Stephen Kent wrote: At least initially, sig order was required to match the AS transit order, to ensure that the AS transit order is accurately represented. Is that no longer true? Are you talking about (1) the order of the signatures on the wire, (2) the order of which AS

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

On 2015-09-08 21:07, Rob Austein wrote: Hmm, I would have thought we'd want to keep the chaining, in the sense that non-originating would sign the previous signature. I've no real objection to signing everything else again, it's just removal of the previous signature that I find odd here. The

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

On 2015-08-27 15:23, Borchert, Oliver wrote: If I understand Davids attack vector correct than the attack would look as follows: For the path -> A -> B -> C -> D -> E with A and D conspiring and B and C only signing but not validating: A signs the path to D and not to B but sends it to B. Be

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

On 2015-09-04 13:08, Sriram, Kotikalapudi wrote: 3. In consideration of the above (#2), the document should instead strongly recommend that “if an AS signs an update without verifying first, it SHOULD return to the update at its earliest and verify, and forward a new signed update, if necessar

Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

On 2015-08-26 22:49, Rob Austein wrote: At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote: ... I think this problem might be fixed if we modify the protocol to sign all of the preceding signed data (rather than just the immediate, previous signature). Agreed, assuming this means

[sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees

Hi all, I think I found an issue with draft-ietf-sidr-bgpsec-protocol-13's security guarantees. Apologies that I didn't catch this earlier, before WGLC ended. The security guarantee with the issue is in section 7.1, "For each AS in the path, a BGPsec speaker authorized by the holder of the A

[sidr] draft-dseomn-sidr-slurm adoption

Hi all, As I mentioned at IETF 93, I think SLURM (https://tools.ietf.org/html/draft-dseomn-sidr-slurm-02) is in good shape for working group adoption. It's a relatively simple solution that supports two of the use cases from draft-ietf-sidr-lta-use-cases-03, and it replaces parts of draft-iet

Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt

On 2015-08-04 07:06, Sandra Murphy wrote: Preferences for Richard’s option #2 (allow but do not mandate line breaks) or for Richard’s option #3 (mandate line breaks)? Note that option #3 means we have to settle on a max line length. I have a slight preference for #2 since it probably requires

Re: [sidr] Last Call: (Resource Public Key Infrastructure (RPKI) Trust Anchor Locator) to Proposed Standard

On 2015-07-29 20:52, Richard Hansen wrote: I misread the MIME RFC; it requires line breaks every 76 characters, not every 75. So I think 76 is a better choice. For what it's worth, here are line lengths from an assortment of TALs I had lying around. afrinic.tal: 64 apnic-rpki-root-afrinic-

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

have just submitted a -13 version of the document that pulls out the fields from MP_REACH_NRLI which arent changed in transit (and thus can be safely signed). - Matt Lepinski On Mon, Jun 22, 2015 at 9:21 PM, David Mandelberg wrote: On 2015-06-19 14:00, Sandra Murphy wrote: Anyone who commented

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-06-12 15:34, Rob Austein wrote: At Tue, 17 Mar 2015 00:46:23 -0400, David Mandelberg wrote: The Router Key PDU (section 5.10) uses a fixed-size field for the SKI. What's the plan for algorithm agility, if the size of the SKI changes? if the size of the SKI does not change, bu

Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

On 2015-06-19 14:00, Sandra Murphy wrote: Anyone who commented on draft-ietf-sidr-bgpsec-protocol-11.txt is encouraged to review this version and report if your comments have or have not been addressed. My comments have been addressed, but I have some questions about the way one of them was a

Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-04.txt

On 2015-06-02 14:40, Stephen Kent wrote: Also, I'm curious ton know whether RPs are ignoring LFs or if they assumed the formatting was purely an artifact of RFC publication constraints. All of the TALs I've ever seen have had line breaks in the Base64. I haven't checked if they're CRLF or LF.

[sidr] extensions in RFC6487 but not draft-ietf-sidr-bgpsec-pki-profiles-10

Hi, There's some text in draft-ietf-sidr-bgpsec-pki-profiles-10 sections 3.1 and 3.1.3 that I found confusing. For reference, https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-pki-profiles-10#section-3.1: This profile is also based on [RFC6487] and only the differences between this pro

Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11

On 2015-04-28 15:21, Iljitsch van Beijnum wrote: On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) wrote: It is not an implementation choice, it is by design. If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed. No... Suppose

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-04-01 14:21, Rob Austein wrote: David, I think a simpler way to express the semantics you want is just to consider the protocol version number to be part of the session identifier. That way, a version 0 session can never match a version 1 session, by definition, full stop. Sure, tha

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-04-01 12:39, Randy Bush wrote: The cache MUST maintain a separate session for each protocol version it supports, and a router MUST NOT attempt to reuse session information across multiple protocol versions. why should there ever be two versions running at the same time between a cache

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 04/01/2015 01:38 AM, Randy Bush wrote: > why are you trying to rescue the case where a router (or cache) upgrades > versions in the middle of a session? > o upgrade should be very rare > o reload is relatively cheap > o and you are generating kinky corner cases to patch it > > session res

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-03-25 16:13, Borchert, Oliver wrote: A correction for my previous email, I mixed up session id and serial number. I think to keep it simple for version 0 - 1 switches and future changes, a change Within the session id and version id should trigger a “Cache Reset” by the cache And the

Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt

Hi, While thinking about RRDP (draft-ietf-sidr-delta-protocol-00), I realized that there's a minor conflict between RRDP's push to transition from rsync to http(s), and the TAL format's requirement to use only rsync URIs. I propose the below changes to draft-ietf-sidr-rfc6490-bis-03 to make R

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

Rob and I were talking about rpki-rtr, and I came up with another potential issue with switching between protocol versions. I don't see any text about whether a single session (session id and serial numbers) can be used for both version 0 and 1. If a router has a valid version 0 session, upgrad

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-03-17 14:29, George, Wes wrote: This may be as simple as recommending that in the case where data from multiple caches is held and specific entries conflict with one another, there SHOULD be an odd number of caches so that there is basis for comparison to determine which cache is out o

Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

On 2015-03-06 05:22, Sandra Murphy wrote: Please comment to the list whether you believe that this draft is ready for publication. I reviewed this draft. My substantive comments are below, and I'll send nits to the authors. Other than the below and the comment that Tim B sent to the list, I t

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

On 02/14/2015 02:53 PM, Sriram, Kotikalapudi wrote: > I agree that the solution should not merely rely on the presence of a > validating ROA. > But there is some more detail here that is worth looking into. The path was > fully signed > and assume all signatures are valid. Then clearly the origi

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

All, while coming up with the example below, I realized another issue. The structure in 4.1 doesn't include an Address Family Identifier. Unless I missed something, this means that a signature for 1.2.0.0/16 would be exactly the same as a signature for 102::/16. This would be a much more practical

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

On 2015-02-07 18:28, Sriram, Kotikalapudi wrote: It might be possible for an attacker to take a valid signature of data from the structure in 4.2, and present it as a valid signature of the same bytes interpreted with the structure in 4.1. If you have worked out a concrete example showing how

Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

After reviewing this document, I have one concern below, and some nits that I'll send to the editor. Otherwise it looks good to me. In sections 4.1 and 4.2, there are two different to-be-signed structures. If I understand correctly, the same router keys will be used to sign data from both stru

Re: [sidr] this is possibly Tim Bruijnzeels delta protocol

Yes, I know I'm an author, but I'm going to review this anyway. Section 3.2.3: "The serial attribute must be an unbounded, unsigned positive integer indicating the current version of the repository." On the relying party side, unbounded integers make me a bit nervous. If the serial number is t

Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

On 2014-03-07 06:39, Rob Austein wrote: David can speak for himself, but speaking on my own behalf as a implementer: if we define a canonical order, comparing two PDUs is a simple binary string comparison. If we don't define a canonical order, comparison is more complicated, hence more error-pro

Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

Sorry, one more question on this draft: Does it make sense to mandate an order for the AS Numbers field of the Router Key PDU? Otherwise, what happens if the cache announces a router key with one ordering, and withdraws that router key with the same AS numbers in a different order? ___

Re: [sidr] Updates to rpki-rtr protocol (RFC 6810 bis)

I support adoption, and I have a few comments/questions about the draft: In section 5.8, you mention an "Update Query PDU". Did you mean Reset Query? In section 5.10, could you move the SKI to before the AS numbers so all the fixed-length fields are at the beginning? (nit) In section 10, s/po

Re: [sidr] Man-in-the-middle attack

On 2014-03-03 16:08, Demian Rosenkranz wrote: > ... a EE certificate, the rp software would recognize it, because the > corresponding signed object can't be validated. An EE certificate used for a CMS signed object (e.g., a ROAs) is embedded in the CMS signed object itself. I.e., the EE certific

[sidr] rpstir-0.10 released

Hi all, We just released version 0.10 of our relying party software, rpstir. The biggest changes are beta support for both 64-bit mode and Mac OS X. Full ChangeLog and download link below: * Add beta support for running rpstir in 64-bit mode. * Add beta support for running rpstir

[sidr] Fwd: New Version Notification for draft-dseomn-sidr-slurm-00.txt

Here's the SLURM document that I previously mentioned. Drink up :) On 2014-02-06 13:53, David Mandelberg wrote: I'm working on a new draft called SLURM (Simplified Local internet nUmber Resource Management) that I hope to have out before the cutoff next week. I'm pretty sure i

Re: [sidr] FW: I-D Action: draft-ietf-sidr-lta-use-cases-00.txt

On 2014-02-05 21:12, Randy Bush wrote: The lta-use-cases draft was motivated as a way to start/guide discussion of the Local Trust Anchor Management draft and the Suspenders draft. The question is whether we need both efforts, or only one, and if so, which one. if you accept the three cases

Re: [sidr] WG Adoption: draft-ymbk-lta-use-cases

I support adoption. I think there are some parts of this doc that could use more work (and I'm happy to review). I also think that a use cases document would be helpful and this is a good starting point. On 2013-11-26 20:39, Chris Morrow wrote: Howdy gentle WG folks, The authors of:

[sidr] rpstir-0.7 released

Hi all, We just released version 0.7 of our relying party software, rpstir. This version is primarily a bugfix release with fixes for bugs we found at the relying party testing session at IETF 86. Download: https://sourceforge.net/projects/rpstir/ Contact: rpstir-supp...@bbn.com

Re: [sidr] WGLC: draft-ietf-sidr-cps (end 2013-03-07 - Mar 07, 2013)

Overall this looks good. I found one minor issue and a bunch of nits, and I have some questions: = minor = 4.6.7. Notification of Certificate Issuance by the CA to Other Entities: There is no section 4.4.3. = questions = 1.5.1. Organization administering the document: Should the address and/o

Re: [sidr] WGLC on draft-ietf-sidr-rpki-rtr-impl-01

In section 8: Does RPKI Router protocol implementation support Session ID procedures outlined in Section 5.10 of [I-D.ietf-sidr-rpki-rtr]? I think that should be a reference to section 5.1, not 5.10. ___ sidr mailing list sidr@ietf.org https://ww

[sidr] rpstir-0.4 released

BBN's RPKI relying party software, rpstir, version 0.4 is now available at http://sourceforge.net/projects/rpstir/. Major changes include: * Significant improvements to processing and validation of RPKI objects in conformance with specifications. See below for tests used to improve conformance

Re: [sidr] [Technical Errata Reported] RFC6487 (3174)

saying that CRL AKIs should use SHA-1, but it doesn't say that authorityCertIssuer and authorityCertSerialNumber must be absent. It also doesn't explicitly say what to take the SHA-1 of when generating a CRL AKI. -- David Mandelberg Wed Apr 4 13:07:37 EDT 2012 __

Re: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-04.txt

r could be matched by an added mapping. Shouldn't the two instances of the word 'matched' above be 'covered' instead since covering mappings also affect validation states? -- David Mandelberg Wed Mar 21 13:20:52 EDT 2012 ___ si