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. Considering the only issue facing SLURM is the file format that Tim and Rudiger mentioned in the MIC, IMHO, if this WG won’t plan to move SLURM to SIDROPS, WGLC is desirable to bring about inputs and comments to conclude this work. Di > 在 2016年12月1日,02:33,Christopher Morrow写道: > > And again, restarting... post meeting and post travel refocusing :) > > On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow > wrote: > Restarting this thread, with some updates :) > > Preparing for Seoul in a few weeks time, with the intent that we do not meet > face-to-face in Chicago, have all current 'protocol' related docs to the > IESG/done and meet instead in sidr-ops if there are agenda items at that time > :) > > Currently we have the following in IESG/pub-request status (13 documents): > draft-ietf-sidr-adverse-actions > draft-ietf-sidr-as-migration > draft-ietf-sidr-bgpsec-algs > draft-ietf-sidr-bgpsec-ops > draft-ietf-sidr-bgpsec-overview > draft-ietf-sidr-bgpsec-pki-profiles > draft-ietf-sidr-bgpsec-protocol > draft-ietf-sidr-delta-protocol (10/26 sent forward) > > draft-ietf-sidr-origin-validation-signaling > draft-ietf-sidr-publication > draft-ietf-sidr-rpki-oob-setup > draft-ietf-sidr-rpki-rtr-rfc6810-bis > > > I had thought I sent validation-reconsidered forward for processing, I'm > doing that today: > draft-ietf-sidr-rpki-validation-reconsidered > > Currently still active documents (6 documents): > > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light > draft-ietf-sidr-rpki-tree-validation > draft-ietf-sidr-rtr-keying > draft-ietf-sidr-slurm > > (this reflects the changes since the last email, included below) > > I believe we're still planning to move (and have agreement from authors): > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light > draft-ietf-sidr-rtr-keying > > draft-ietf-sidr-rpki-tree-validation > > which leaves to be dealt with by Chicago 2 documents: > draft-ietf-sidr-slurm > > I think this is good, I believe (and of course I should be corrected if wrong) > slurm - more work inbound and discussion planned in Seoul > tree-validation - I thought moved to sidr-ops, but don't have docs to back > that up. > > > I still think this is good, I will be sending a request to the OPS-AD folk > today to move: > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light > draft-ietf-sidr-rtr-keying > draft-ietf-sidr-rpki-tree-validation > > to sidr-ops... If there are corrections/additions please send them along :) > > -chris > > -chris > > On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow wrote: > > Howdy SIDR peeps, > (+bonus ops ad) > > Following on the Berlin meeting we were trying to accomplish two > things: > > 1) get all documents related to sidr protocols into wglc and then > publication > > 2) get all documents which are more operationally focused moved > along to an ops group (sidr-ops or something akin to that) > > With that in mind there are 8 documents in the publication queue: > draft-ietf-sidr-as-migration > draft-ietf-sidr-bgpsec-algs > draft-ietf-sidr-bgpsec-ops > draft-ietf-sidr-bgpsec-overview > draft-ietf-sidr-bgpsec-pki-profiles > draft-ietf-sidr-bgpsec-protocol > draft-ietf-sidr-origin-validation-signaling > draft-ietf-sidr-rpki-rtr-rfc6810-bis > > and 11 still in progress. Of the 11 left Sandy and I think they > roughly break down like: > > Documents which should move to the ops group: > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light - authors notified/queried about > this > draft-ietf-sidr-rtr-keying > > documents which should finish out in sidr: > draft-ietf-sidr-delta-protocol > draft-ietf-sidr-publication > draft-ietf-sidr-rpki-oob-setup - pub request in flight > draft-ietf-sidr-rpki-tree-validation > draft-ietf-sidr-rpki-validation-reconsidered > draft-ietf-sidr-slurm - authors recently updated > draft-ietf-sidr-adverse-actions - wglc imminent > > I think if there's no meaningful discussion on change for these > between now and 9/16/2016 (Sept 16th) we will assume this list is > correct. For documents in the 'move' list, if progress to publication > happens 'good!'. For all documents in the 'stays' list: > 1) we aim to have wglc by Seoul > 2) publication requests started on as many as possible > > We plan to meet in Seoul, but not in Chicago (Mar 2017) where we > expect the ops group to exist
Re: [sidr] Current document status && directionz
>> draft-ietf-sidr-bgpsec-ops waiting to rev when iesg and whomever reviews are in. if someone wants an earlier push, shout. >> draft-ietf-sidr-lta-use-cases i thought this was post last call >> draft-ietf-sidr-rtr-keying i thought this was done randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] Current document status && directionz
And again, restarting... post meeting and post travel refocusing :) On Wed, Oct 26, 2016 at 11:35 AM, Christopher Morrow < morrowc.li...@gmail.com> wrote: > Restarting this thread, with some updates :) > > Preparing for Seoul in a few weeks time, with the intent that we do not > meet face-to-face in Chicago, have all current 'protocol' related docs to > the IESG/done and meet instead in sidr-ops if there are agenda items at > that time :) > > Currently we have the following in IESG/pub-request status (13 documents): > draft-ietf-sidr-adverse-actions > draft-ietf-sidr-as-migration > draft-ietf-sidr-bgpsec-algs > draft-ietf-sidr-bgpsec-ops > draft-ietf-sidr-bgpsec-overview > draft-ietf-sidr-bgpsec-pki-profiles > draft-ietf-sidr-bgpsec-protocol > draft-ietf-sidr-delta-protocol (10/26 sent forward) > draft-ietf-sidr-origin-validation-signaling > draft-ietf-sidr-publication > draft-ietf-sidr-rpki-oob-setup > draft-ietf-sidr-rpki-rtr-rfc6810-bis > I had thought I sent validation-reconsidered forward for processing, I'm doing that today: > draft-ietf-sidr-rpki-validation-reconsidered > Currently still active documents (6 documents): > > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light > draft-ietf-sidr-rpki-tree-validation > draft-ietf-sidr-rtr-keying > draft-ietf-sidr-slurm > > (this reflects the changes since the last email, included below) > > I believe we're still planning to move (and have agreement from authors): > draft-ietf-sidr-bgpsec-rollover > draft-ietf-sidr-lta-use-cases > draft-ietf-sidr-route-server-rpki-light > draft-ietf-sidr-rtr-keying > draft-ietf-sidr-rpki-tree-validation > which leaves to be dealt with by Chicago 2 documents: > draft-ietf-sidr-slurm > > I think this is good, I believe (and of course I should be corrected if > wrong) > slurm - more work inbound and discussion planned in Seoul > tree-validation - I thought moved to sidr-ops, but don't have docs to > back that up. > > I still think this is good, I will be sending a request to the OPS-AD folk today to move: draft-ietf-sidr-bgpsec-rollover draft-ietf-sidr-lta-use-cases draft-ietf-sidr-route-server-rpki-light draft-ietf-sidr-rtr-keying draft-ietf-sidr-rpki-tree-validation to sidr-ops... If there are corrections/additions please send them along :) -chris > -chris > > On Fri, Sep 2, 2016 at 4:56 PM, Chris Morrow> wrote: > >> >> Howdy SIDR peeps, >> (+bonus ops ad) >> >> Following on the Berlin meeting we were trying to accomplish two >> things: >> >> 1) get all documents related to sidr protocols into wglc and then >> publication >> >> 2) get all documents which are more operationally focused moved >> along to an ops group (sidr-ops or something akin to that) >> >> With that in mind there are 8 documents in the publication queue: >> draft-ietf-sidr-as-migration >> draft-ietf-sidr-bgpsec-algs >> draft-ietf-sidr-bgpsec-ops >> draft-ietf-sidr-bgpsec-overview >> draft-ietf-sidr-bgpsec-pki-profiles >> draft-ietf-sidr-bgpsec-protocol >> draft-ietf-sidr-origin-validation-signaling >> draft-ietf-sidr-rpki-rtr-rfc6810-bis >> >> and 11 still in progress. Of the 11 left Sandy and I think they >> roughly break down like: >> >> Documents which should move to the ops group: >> draft-ietf-sidr-bgpsec-rollover >> draft-ietf-sidr-lta-use-cases >> draft-ietf-sidr-route-server-rpki-light - authors notified/queried >> about this >> draft-ietf-sidr-rtr-keying >> >> documents which should finish out in sidr: >> draft-ietf-sidr-delta-protocol >> draft-ietf-sidr-publication >> draft-ietf-sidr-rpki-oob-setup - pub request in flight >> draft-ietf-sidr-rpki-tree-validation >> draft-ietf-sidr-rpki-validation-reconsidered >> draft-ietf-sidr-slurm - authors recently updated >> draft-ietf-sidr-adverse-actions - wglc imminent >> >> I think if there's no meaningful discussion on change for these >> between now and 9/16/2016 (Sept 16th) we will assume this list is >> correct. For documents in the 'move' list, if progress to publication >> happens 'good!'. For all documents in the 'stays' list: >> 1) we aim to have wglc by Seoul >> 2) publication requests started on as many as possible >> >> We plan to meet in Seoul, but not in Chicago (Mar 2017) where we >> expect the ops group to exist and meet. We can progress documents in >> SIDR after Seoul, but the WG should close out shortly after the new >> year. (or that's the goal). >> >> Thoughts? >> -chris >> >> ___ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > > ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-10.txt
Updated security section to reflect SecDir and AD review. --John > On Nov 30, 2016, at 12:32 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Secure Inter-Domain Routing of the IETF. > >Title : BGP Prefix Origin Validation State Extended Community >Authors : Pradosh Mohapatra > Keyur Patel > John Scudder > Dave Ward > Randy Bush > Filename: draft-ietf-sidr-origin-validation-signaling-10.txt > Pages : 6 > Date: 2016-11-30 > > Abstract: > This document defines a new BGP opaque extended community to carry > the origination AS validation state inside an autonomous system. > IBGP speakers that receive this validation state can configure local > policies allowing it to influence their decision process. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-10 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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
[sidr] I-D Action: draft-ietf-sidr-origin-validation-signaling-10.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 of the IETF. Title : BGP Prefix Origin Validation State Extended Community Authors : Pradosh Mohapatra Keyur Patel John Scudder Dave Ward Randy Bush Filename: draft-ietf-sidr-origin-validation-signaling-10.txt Pages : 6 Date: 2016-11-30 Abstract: This document defines a new BGP opaque extended community to carry the origination AS validation state inside an autonomous system. IBGP speakers that receive this validation state can configure local policies allowing it to influence their decision process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
Hi! Yes, the text below works for me. And I would assume it works for Tero as well. Thanks!! Alvaro. On 11/30/16, 11:20 AM, "John G. Scudder"> wrote: On Nov 30, 2016, at 9:18 AM, Randy Bush > wrote: section 4.5 of 4593 is relevant, or all of sec 4 Thanks, used in the text below. i am kinda sad that 7132 is not too good on this I looked there first but it's a *path* security threat model so can't really be blamed for not covering this. Candidate new security section below. I'd appreciate an ack from Alvaro that this addresses his concern before I publish. --John 6. Security Considerations Security considerations such as those described in [RFC4272] continue to apply. Since this document introduces an extended community that will generally be used to affect route selection, the analysis in Section 4.5 ("Falsification") of [RFC4593] is relevant. These issues are neither new, nor unique to the origin validation extended community. The security considerations provided in [RFC6811] apply equally to this application of origin validation. In addition, this document describes a scheme where router A outsources validation to some router B. If this scheme is used, the participating routers should have the appropriate trust relationship -- B should trust A either because they are under the same administrative control or for some other reason (for example, consider [I-D.ietf-sidr-route-server-rpki-light]). The security properties of the propagation path between the two routers should also be considered. See [RFC7454] Section 5.1 for advice regarding protection of the propagation path. (all the refs above are in the "informative" section) ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
On Nov 30, 2016, at 9:18 AM, Randy Bushwrote: > section 4.5 of 4593 is relevant, or all of sec 4 Thanks, used in the text below. > i am kinda sad that 7132 is not too good on this I looked there first but it's a *path* security threat model so can't really be blamed for not covering this. Candidate new security section below. I'd appreciate an ack from Alvaro that this addresses his concern before I publish. --John 6. Security Considerations Security considerations such as those described in [RFC4272] continue to apply. Since this document introduces an extended community that will generally be used to affect route selection, the analysis in Section 4.5 ("Falsification") of [RFC4593] is relevant. These issues are neither new, nor unique to the origin validation extended community. The security considerations provided in [RFC6811] apply equally to this application of origin validation. In addition, this document describes a scheme where router A outsources validation to some router B. If this scheme is used, the participating routers should have the appropriate trust relationship -- B should trust A either because they are under the same administrative control or for some other reason (for example, consider [I-D.ietf-sidr-route-server-rpki-light]). The security properties of the propagation path between the two routers should also be considered. See [RFC7454] Section 5.1 for advice regarding protection of the propagation path. (all the refs above are in the "informative" section) ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
> ideally you also backstop that with some protections (tcp-ao, of > course!) and cash will fall from the sky ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
At Wed, 30 Nov 2016 05:37:24 -0800, Randy Bushwrote: > > >>> and stitching back together the tcp session... same effect. > >> > >> Not sure why you have to stitch back together the TCP session? I > >> thought you were supposing the "attacker" was the edge node, it can > >> just apply an export policy towards the core. > > > > say the case is inside your network, between the edge node in NYC and > > the core nodes in BWI, something on the fiber path just removes/adds > > information to the bgp stream. > > < pedantry > > > the point is the tcp 'stream' does not have to be hacked in any way. > the hack is at a layer above. sure. but in the case where you own both sides you'd assume that the goes-inta == goes-outa on a single stream... ideally you also backstop that with some protections (tcp-ao, of course!), but... really. ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
> I guess I will wait for Alvaro to answer, but so far I'm not seeing > the need for anything more than a couple lines that remind the reader > of the basic (in)security properties of BGP, maybe an RFC 4272 > reference. section 4.5 of 4593 is relevant, or all of sec 4 i am kinda sad that 7132 is not too good on this ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
On Nov 30, 2016, at 8:37 AM, Randy Bushwrote: > the point is the tcp 'stream' does not have to be hacked in any way. > the hack is at a layer above. I agree. I also agree with your earlier On Nov 29, 2016, at 8:40 PM, Randy Bush wrote: > none of this is new. I guess I will wait for Alvaro to answer, but so far I'm not seeing the need for anything more than a couple lines that remind the reader of the basic (in)security properties of BGP, maybe an RFC 4272 reference. --John ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] AD Review of sidr-origin-validation-signaling-09
>>> and stitching back together the tcp session... same effect. >> >> Not sure why you have to stitch back together the TCP session? I >> thought you were supposing the "attacker" was the edge node, it can >> just apply an export policy towards the core. > > say the case is inside your network, between the edge node in NYC and > the core nodes in BWI, something on the fiber path just removes/adds > information to the bgp stream. < pedantry > the point is the tcp 'stream' does not have to be hacked in any way. the hack is at a layer above. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr