Re: [sidr] Current document status && directionz

[Declan Ma]

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

[Randy Bush]

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

[Christopher Morrow]

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

[John G. Scudder]

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

[internet-drafts]

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

[Alvaro Retana (aretana)]

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

[John G. Scudder]

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

[Randy Bush]

> 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

[Chris Morrow]

At Wed, 30 Nov 2016 05:37:24 -0800,
Randy Bush  wrote:
> 
> >>> 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

[Randy Bush]

> 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

[John G. Scudder]

On Nov 30, 2016, at 8:37 AM, Randy Bush  wrote:
> 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

[Randy Bush]

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