[sidr] RPSTIR updated

Hi, folks, We RPSTIR team just had the very software updated to support the algorithm specified by Validation Reconsidered (draft-ietf-sidr-rpki-validation-reconsidered-07) . Given the SIDR WG has not reach the agreement whether and how new OIDs should be employed, this release, for the time

Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

+1 As far as we programmed to support Validation Reconsidered by using OPENSSL , a bug was found. For instance, if one calls v3_addr_get_range() in OPENSSEL library to get INR 1::/16 from a RC, one will get a right MAX but a wrong MIN NULL, which should have been 1:: . Di > 在

Re: [sidr] AD Review of draft-ietf-sidr-rpki-validation-reconsidered-07

Speaking as the representative of RPSTIR team, We are working on RPSTIR update in order to make it use the new algorithm to do INR validation. Before RP performs the new validation process, it needs to get the INRs from certificates. And we found a bug of OPENSSL library when using OPENSSL

[sidr] Fwd: I-D Action: draft-ietf-sidr-slurm-03.txt

Hi, all, We authors just updated the SLURM by adding a new ingredient JSON, offered by Tim, to describe the SLURM configuration file format. Looking forwards to seeing your reviews and comments. Thanks very much indeed. Di ZDNS > 下面是被转发的邮件： > > 发件人: internet-dra...@ietf.org > 主题: [sidr]

Re: [sidr] Current document status && directionz

Chris, I would like to take this thread to request for comments on how to move on SLURM. During the Seoul meeting, Tim suggested moving it to SIDROPS since SIDR is being closed. Yet I had the impression that the AD hopes keeping the list/structure going until current work items are done.

Re: [sidr] Agenda Upload

+1. Intriguing! I was considering how inter-chche works. Di > 在 2016年11月8日，13:26，Randy Bush 写道： > > i stil think we should be doing some rigorous interoperability testing, > inter CA, caches and routers, routers applying origin validation, ... > > yes, we should be doing

Re: [sidr] WGLC - draft-ietf-sidr-rpki-validation-reconsidered - ends 10/25/2016

Speaking as an RP software developer, I think this document is ready for the next step. My team is working to make RPSTIR support this algorithm. Di > 在 2016年10月20日，22:18，Christopher Morrow 写道： > > Howdy WG Folks! > > Have we read this document and do we have

Re: [sidr] adverse actions -01 posted

Tim, If a word is synonym of other word, it does’t means they two are semantically equivalent. Synonyms make sense in specific cases, not one-to-one mapping. The term “adverse" doesn’t means “hostile" necessarily. I checked "adverse” with dictionary.com where you had got the explanation

[sidr] Fwd: I-D Action: draft-ietf-sidr-slurm-02.txt

Hi, folks, I just updated the slurm I-D. Thanks go to Tim and Rob for sharing with me their considerations on SLURM file format. The major changes include: 1) Reorganize the layout of the intended content; 2) Rewrite the use cases; 3) Make the motivation unfocused from private INR by

Re: [sidr] Proposal for next steps - chartering sidrops?

Joel, When we are talking about SIDROPS, we are referring to that BGP speakers are resorting to RPKI relying party to get verified INR authorization information, which is created by CA and maintained by repository managers. IMHO, network operators are not the only RPKI role that the community

[sidr] Time frame for changing RPSTIR to the new validation algorithm

Folks, I recall Tim has suggested a schedule for transition to the new validation algorithm during Berlin meeting. His proposal is to mandate RP support for the new all 6 months after the doc is published as an RFC. My team is now responsible for RPSTIR update. I am afraid that the proposal

Re: [sidr] two stranded docuemnts - stake time

> 在 2016年7月28日，22:32，Tim Bruijnzeels 写道： > > Hi, > >> On 22 Jul 2016, at 17:48, Stephen Kent wrote: >> >> It seems preferable to describe the first motivating case without reference >> to a specific RIR. > > Although I appreciate that Randy is trying to

Re: [sidr] two stranded docuemnts - stake time

Sandy & Chris, Thank Steve for recommending me to take over SLURM. With David’s permission, I would be happy to assume responsibility for SLURM. I think SLURM is quite important to RPKI operation in term of local network. SLURM provides a simple way to enable INR holders to establish a

Re: [sidr] New Version Notification for draft-madi-sidr-rp-00.txt

Oleg, Thanks for your detailed comments. > 在 2016年7月13日，23:05，Oleg Muravskiy <o...@ripe.net> 写道： > > Hi Di, > >> On 27 Apr 2016, at 03:46, Declan Ma <madihe...@icloud.com> wrote: >> >> Hi, folks, >> >> Steve Kent and I have generated t

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-tree-validation-01.txt

，16:36，Oleg Muravskiy <o...@ripe.net> 写道： > > Di, > >> On 10 Jul 2016, at 16:08, Declan Ma <m...@zdns.cn> wrote: >> >> Oleg, >> >> I think this version is much better. >> >> Yet I still have a question with Section Security Consi

Re: [sidr] I-D Action: draft-ietf-sidr-rpki-tree-validation-01.txt

Oleg, I think this version is much better. Yet I still have a question with Section Security Considerations: "In contrast, objects whose content hash matches the hash listed in the manifest, but that are not located in the publication directory listed in their CA certificate, will be used

Re: [sidr] rpki-tree-validation vs. madi-sidr-rp

from the RP implementers. Please let us know any improvements that should be made. Di > > Tim > > >> On 30 Jun 2016, at 07:09, Declan Ma <m...@zdns.cn> wrote: >> >> Hi, all, >> >> Speaking as the co-author of ‘Requirements for Resource Public Key

Re: [sidr] rpki-tree-validation vs. madi-sidr-rp

Hi, all, Speaking as the co-author of ‘Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties’, In addition to the clarification made by Steve, I would like to deliver a clear message here that this draft is intended to make the RP requirements well framed, which are

[sidr] Fwd: New Version Notification for draft-madi-sidr-rp-00.txt

Hi, folks, Steve Kent and I have generated this document to try to consolidate RP requirements in one document, with pointers to all the relevant RFCs. As I mentioned in IETF 95 meeting, there is no standards language (e.g., MUST, SHOULD, MAY, ...) in this doc, as it is just POINTING to the

Re: [sidr] BGPSec RFC status

I think BGPsec should be Standards Track. ISPs and router vendors won’t take BGPsec seriously if it is published as an Experimental RFC. We came a long way here from S-BGP and so much time and so many efforts by many have been spent on BGPsec. The community need some real experience. Di

[sidr] adoption of draft-kent-sidr-adverse-actions-02

Hi all, According to the discussions on Adverse Actions draft at IETF Yokohama meeting and the feedback from the WG mailing list, Steve and I have removed the text that caused folks concerns relating to mitigation solutions. I think the updated version of this draft

[sidr] draft-kent-sidr-adverse-actions adoption

Hi all, According to the discussions on Adverse Actions draft at IETF Yokohama meeting and the feedback from the WG mailing list, Steve and I have removed the text that caused folks concerns relating to mitigation solutions. I think the updated version of this draft

Re: [sidr] Validation Reconsidered (again/again) question

> 在 2015年12月2日，18:23，Geoff Huston 写道： > > > > Example 2: > > A CA Cert: 1.0.0.0/24, 2.0.0.0/24 > > issues: > > B CA Cert: 1.0.0.0/24, 2.0.0.0/24, 3.0.0.0/24 > > issues: > > C EE Cert: 1.0.0.0/24, 2.0.0.0/24 > > and signs > > ROA: 1.0.0.0/24 AS1 > > still all good

Re: [sidr] Validation Reconsidered (again/again) question

> 在 2015年12月3日，14:32，Geoff Huston <gih...@gmail.com> 写道： > > >> On 3 Dec 2015, at 5:24 PM, Declan Ma <m...@zdns.cn> wrote: >> >> >>> 在 2015年12月2日，18:23，Geoff Huston <gih...@gmail.com> 写道： >>> >>> >>> >>

Re: [sidr] Validation Reconsidered (again/again) question

> 在 2015年12月2日，08:32，Sandra Murphy 写道： > > (We’ve overloaded “Valid” a couple of different ways valid certs, valid ROAs, > valid origins, valid Signature_Blocks, …) - it might be nice to readers and > users to come up with a different adjective here for the subset of the

Re: [sidr] Validation Reconsidered (again/again) question

Tim, Thanks for your explanations. Yet since the very draft keeps talking about Resource Transfer and deems it as one of the “Operational Considerations” in Section 3, we might pay attention to Steve’s statement as below: So, when folks claim that this alg allows for transfers to not have

Re: [sidr] new agenda uploaded

I agree with Steve. “RPKI Validation Reconsidered” should not be carried on. And I believe that our WG should look at RPKI operation security from a wider perspective and pursue countermeasures according to a deliberate threat model as described in draft-kent-sidr-adverse-actions. Di Ma

Re: [sidr] Validation reconsidered draft status

> 在 2015年11月6日，13:16，Geoff Huston 写道： > > I disagree with the assertions Karen > > >> On 6 Nov 2015, at 7:53 AM, Karen Seo wrote: >> >> Folks, >> >> I think the authors have brought up some pertinent issues which have helped >> inspire other work which

Re: [sidr] Correction re: draft-ietf-sidr-lta-use-cases

Karen, This is indeed a better description. And I believe it would be even better if Randy could describe how a local trust anchor” takes effect on different cases. Declan Ma ZDNS Ltd. 在 2015年4月4日，上午2:18，Karen Seo k...@bbn.com 写道： Folks, Here's a better description of Case 3

Re: [sidr] wg adoption call for draft-tbruijnzeels-sidr-delta-protocol-03

I support the adoption of this draft as a working group item. Declan Ma ZDNS Ltd. 4, South 4th Street, Zhongguancun, Haidian, Beijing 100190, China 在 2015年1月15日，上午4:38，Sandra Murphy sa...@tislabs.com 写道： The authors of draft-tbruijnzeels-sidr-delta-protocol-03 have requested working